용어집 / 노드와 소프트웨어
RPC
별칭은 JSON-RPC, Remote procedure call, 원격 프로시저 호출입니다.
- RPC란 무엇입니까?
- RPC는 비트코인 노드가 다른 프로그램에 노출하는 명령 인터페이스로, 지갑이나 거래소 백엔드 또는 사용자의 터미널이 노드에 질문을 하고 지시를 내릴 수 있게 해 줍니다.
비트코인을 자동화하는 모든 것은 이 방식으로 노드와 통신합니다. Bitcoin Core는 JSON을 담은 HTTP 요청을 포트 8332에서 수신하고, 한 번에 한 호출씩 응답하며, 기본적으로 실행 중인 기기에서 오는 연결만 허용합니다. 어떤 서비스가 사용자에게 수수료 추정치를 제시했거나 출금이 확인되었다고 알려 주었다면, 그 답은 어떤 RPC 호출이 만들어 낸 것입니다.
작동 방식
RPC 호출은 본문에 메서드 이름을 지정하고 인수를 나열하는 HTTP POST입니다.
getblockchaininfo를 요청하면 체인 이름, 현재 높이, 검증 진행률, 디스크상 크기가 돌아옵니다. listunspent나 sendtoaddress를 요청하면 노드의 지갑을 조작하는 것입니다. getrawtransaction을 요청하면 바이트를 받습니다. 함께 제공되는 bitcoin-cli 프로그램은 JSON을 만들고 전송한 뒤 응답을 출력하는 얇은 래퍼이므로, 명령줄에서 입력할 수 있는 것은 무엇이든 프로그램이 소켓을 통해 할 수 있습니다.
인증에는 알아 둘 만한 역사가 있습니다. Bitcoin Core는 버전 0.12.0에서 내장 SSL 지원을 제거했기 때문에, 이 인터페이스는 암호화되지 않은 HTTP만 사용합니다. 같은 릴리스에서는 쿠키 파일이 도입되었는데, 이는 시작 시 데이터 디렉터리에 기록되는 무작위 자격 증명으로 재시작할 때마다 교체되며, bitcoin-cli가 비밀번호를 설정한 적 없이도 사용자의 기기에서 작동하는 이유가 여기에 있습니다. 원격 호출자를 위해서는 rpcauth이 있으며, 이는 구성 파일에 평문 비밀 대신 솔트가 적용된 해시를 저장합니다. 전송 계층 암호화는 여전히 없으므로, 네트워크를 넘어 노드에 접근하려면 SSH 터널, VPN 또는 Tor 히든 서비스를 사용해야 하며 다른 방법은 통하지 않습니다.
여러 데몬이 한 기기를 공유할 수 있도록 각 네트워크에는 자체 포트가 있습니다. 메인넷은 8332, testnet3는 18332, testnet4는 48332, signet은 38332, regtest는 18443입니다. 메인넷의 RPC 포트는 피어 간 포트 8333 바로 아래에 있으며, 이 둘을 혼동하는 것은 흔한 초보 실수입니다.
이 방언은 천천히 움직여 왔습니다. Bitcoin Core는 10년이 훨씬 넘는 기간 동안 JSON-RPC 1.0의 느슨한 변형에 응답했고, 버전 28.0에서는 서버가 JSON-RPC 2.0 요청을 인식하고 그 명세를 엄격히 준수하여 응답하도록 했으면서도 이전 방식을 계속 받아들입니다. 지갑별 호출은 경로로 지정되므로, 지갑을 여러 개 보유한 노드는 /wallet/ 뒤에 지갑 이름을 붙인 경로로 이들을 라우팅합니다.
확인할 수 있는 곳
RPC는 비트코인 자체와 그 위에 구축된 모든 제품 사이의 접점입니다.
라이트닝 구현은 노드에 블록을 요청하고 종료 트랜잭션을 노드를 통해 전송합니다. 블록 탐색기, 멤풀 대시보드, BTCPay Server 같은 결제 처리업체는 bitcoind 인스턴스 위에 서서 이를 더 친화적인 무언가로 감쌉니다. 거래소의 출금 시스템은 스택 맨 아래에서 보면 sendrawtransaction 호출의 대기열입니다. 이 사이트의 거래소 리뷰에서 어떤 플랫폼이 출금을 일괄 처리한다고 언급할 때, 그 일괄 처리는 결국 이곳에서 끝나는 코드에서 일어납니다.
자체 호스팅 환경이 침해되는 곳도 바로 이곳입니다. 포트 8332는 끊임없이 스캔되며, 추측 가능한 비밀번호와 자금이 든 지갑을 가진 채 공개 인터넷에 노출된 노드는 자금이 비워질 지갑입니다. 인터페이스를 로컬 기기에 묶어 두고, 다른 곳에서 필요하면 터널로 접속하십시오.
RPC vs RPC 바이트 순서
RPC와 RPC 바이트 순서는 약어만 공유할 뿐 그 외에는 아무것도 공유하지 않으며, 이 때문에 실제 버그가 생깁니다. RPC는 인터페이스입니다. RPC 바이트 순서는 표시 규칙입니다. 블록 및 트랜잭션 해시는 한 방향으로 계산되고 전송되지만 RPC 계층은 이를 역순으로 출력하며, 그래서 블록 탐색기에서 복사한 txid가 원시 트랜잭션 안에 있는 같은 32바이트와 비교하면 거꾸로 읽힙니다. 복사한 txid를 뒤집지 않고 그대로 바이트 수준 파서에 넣으면 조회는 결코 일치하지 않습니다.