P2P 메시지

호출할 중앙 서버가 없으므로, 노드와 네트워크의 관계 전체가 이 대화입니다. Bitcoin Core는 프로토콜 버전 70016을 알리고, 8333번 포트에서 연결을 열며, 전체 어휘는 한 페이지 안에 들어갑니다. 출금이 채굴업자에게 도달하는 것은 한 기계가 다른 기계에 tx를 보내고 그것이 몇 초 안에 수천 번 전달되기 때문입니다.

작동 방식

모든 연결은 핸드셰이크로 시작한 뒤, 반복되는 소수의 교환으로 이어집니다.

양쪽이 가장 먼저 보내는 것은 version이며, 여기에는 자신이 사용하는 프로토콜 번호, 서비스 플래그, 현재 시각, 상대방이 가진 것으로 생각하는 주소, 실수로 자기 자신에게 접속했는지 감지하는 데 쓰이는 무작위 논스, 사용자 에이전트 문자열, 자신이 아는 최선 체인의 높이가 담깁니다. 각 측은 verack으로 응답합니다. 양쪽이 모두 이것을 마치기 전까지는 다른 어떤 것도 처리되지 않습니다.

이 프로토콜 번호는 장식이 아니라 기능의 사다리입니다. 직접 헤더 알림에는 70012가 필요하고, 컴팩트 블록 협상에는 70014가 필요하며, 전체 검증 전에 컴팩트 블록을 알리는 데에는 70015가 필요하고, 위트니스 식별자로 트랜잭션을 중계하는 데에는 70016이 필요합니다. 노드는 상대의 번호를 읽고 상대가 사용할 수 없는 기능을 제공하지 않기로 조용히 결정하며, 이것이 조율된 전환 없이 네트워크가 업그레이드되는 방식입니다.

목적별로 묶으면 어휘는 짧습니다. 피어 찾기: getaddr, addr, 그리고 Tor와 I2P 주소를 담을 수 있는 BIP155의 addrv2 형식입니다. 알림: inv와 headers입니다. 요청: getheaders, getdata, getblocks, mempool입니다. 전달: tx, block, cmpctblock, blocktxn, notfound입니다. 유지 관리: ping, pong, sendheaders, sendcmpct, wtxidrelay, 그리고 feefilter이며, 마지막 것은 상대에게 명시된 수수료율 미만의 트랜잭션은 중계하지 말라고 알려 줍니다.

두 가지 침묵은 의도된 것입니다. 인식되지 않는 명령은 거부되지 않고 무시되며, 이것이 누구도 한꺼번에 업데이트할 수 없는 네트워크에서 새로운 메시지 유형이 점진적으로 배포될 수 있게 합니다. 그리고 상대가 왜 여러분의 트랜잭션을 버렸는지 알려 줄 방법은 없습니다. BIP61의 reject 메시지는 Bitcoin Core 0.18.0에서 기본적으로 비활성화되었고, 0.20.0에서 그 옵션이 완전히 제거되었습니다. 응답이 신뢰할 수 없고 위조하기 쉬웠으며, 권위 있는 것으로 잘못 받아들여지는 일이 잦았기 때문입니다.

확인할 수 있는 곳

P2P 메시지는 여러분의 노드가 하루 종일 하는 일이며, 관찰하기도 쉽습니다.

Bitcoin Core를 -debug=net으로 시작하시면 로그는 메시지가 도착할 때마다 그 이름을 기록합니다. getpeerinfo 호출은 모든 연결에 대해 메시지 유형별로 나눈 송수신 바이트를 보고하며, 이는 피어 하나가 거의 모든 것을 공급하고 나머지는 유휴 상태임을 발견하는 가장 빠른 방법입니다. 자신의 노드를 가리키는 지갑에서 결제를 브로드캐스트하면 알아볼 수 있는 작은 순서가 만들어집니다. inv가 나가고, getdata가 돌아오고, 그에 대한 응답으로 tx가 나갑니다.

P2P 메시지 vs RPC

비트코인에는 두 개의 인터페이스가 있으며 서로 호환되지 않습니다. P2P는 노드 대 노드입니다. 인증이 없고, 양쪽이 v2 전송을 협상하지 않는 한 암호화되지 않으며, 8333번 포트를 사용하고, 어느 단일 참여자도 확장할 수 없는 어휘를 가집니다. RPC는 프로그램 대 노드입니다. 인증이 있고, 기본적으로 로컬이며, 8332번 포트를 사용하고, 릴리스마다 바뀌는 메서드 목록을 가집니다. 여러분이 만드는 결제는 두 가지를 모두 거칩니다. 여러분의 노드에 RPC 호출로 들어가 P2P 메시지로 나가며, 다른 사람의 관심사인 것은 후반부뿐입니다.