Full Node는 Bitcoin 규칙을 스스로 검사하는 프로그램입니다. 컴퓨터에서 실행되며 블록과 트랜잭션을 받아 어떤 것이 유효한 기록에 들어갈 수 있는지 확인합니다. 자신의 노드가 있으면 검증을 채굴자나 외부 서버의 주장에 의존할 필요가 없습니다. 다만 지갑도 이점을 얻으려면 그 노드를 실제 데이터 출처로 사용해야 합니다.
지갑에 받은 결제가 표시된다고 생각해 보세요. 그 트랜잭션이 정말 Bitcoin 기록에 속하고 규칙을 지킨다는 것을 지갑은 어떻게 알까요? 외부 서버에 묻거나 자신의 노드를 사용할 수 있습니다. Full Node는 두 번째 선택을 가능하게 합니다. 받은 데이터가 유효한지 스스로 확인하기 때문입니다. 연결된 컴퓨터의 다수에게 어떻게 판단할지 묻지 않습니다. 규칙을 어긴 블록이 도착하면 거부합니다. 따라서 연결 수는 규칙 검사를 대신할 수 없습니다. 자신의 노드로 결제 판단에 쓰는 데이터를 직접 확인할 수 있습니다. [1] [3]
노드는 블록 연결, 헤더, 그리고 블록에 요구되는 계산 증명인 Proof of Work를 확인합니다. 트랜잭션에 대해서는 참조한 자금이 존재하는지, 두 번 쓰이지 않는지, 사용 조건을 만족하는지 등을 검사합니다. 조건은 작은 프로그램 규칙인 스크립트에 적혀 있습니다. 새로 만들어지는 비트코인 양도 확인합니다. 계속 갱신되는 결과는 미사용 트랜잭션 출력 집합인 UTXO set으로, 아직 사용할 수 있는 구체적인 자금을 기록합니다. 더 큰 누적 작업량이 유효한 두 갈래 중 선택을 정할 수는 있지만 무효 블록을 유효하게 만들 수는 없습니다. [1]
아닙니다. Full Node는 블록과 트랜잭션을 검증하며, 보통의 검증만으로 블록 보상을 받지는 않습니다. 채굴자는 새 블록을 제안하고 조건에 맞는 결과를 찾을 때까지 계산을 반복합니다. 이때 블록 헤더의 디지털 지문인 해시를 사용합니다. 두 역할은 함께할 수 있습니다. 채굴자는 어떤 기록을 잇고 어떤 트랜잭션을 넣어도 되는지 알아야 하기 때문입니다. 그렇다고 모든 노드가 채굴해야 하는 것은 아닙니다. 검증과 다음 블록을 찾는 경쟁은 다른 활동입니다. [5] [1]
새 노드는 먼저 네트워크 기록을 따라잡아야 합니다. 블록을 내려받고 데이터를 처리하는 초기 동기화입니다. 고급 설정에서는 두 가지 가속 방식을 구분해야 합니다. Bitcoin Core의 assumevalid는 정해진 조건에서 과거 스크립트 검사를 생략할 수 있으며 assumevalid=0으로 이 최적화를 끕니다. AssumeUTXO는 특정 블록 시점의 미사용 자금 상태를 저장한 스냅샷을 불러옵니다. 그 지문을 소스 코드에 포함된 값과 비교하고, 이전 기록은 백그라운드에서 검증합니다. 따라서 현재 상태를 쓸 수 있다고 과거 검증까지 끝난 것은 아닙니다. [1] [2]
Full Node는 모든 옛 블록 파일을 영원히 보관할 필요가 없습니다. Pruning은 처리한 파일 일부를 지우면서 현재 UTXO set과 필요한 최근 데이터를 남깁니다. 새 블록 검증은 계속합니다. 보관형 노드는 옛 블록을 유지해 다른 노드에 제공하거나 다시 검색할 수 있습니다. 디스크를 절약하는 것과 간소화된 결제 검증을 하는 SPV 클라이언트는 같지 않습니다. SPV는 모든 트랜잭션과 상태를 Full Node처럼 검사하지 않습니다. 차이는 보관 파일 수만이 아니라 무엇을 검증하느냐에 있습니다. [3]
일반적인 동기화에서는 가지치기 노드도 과거 블록을 내려받아 처리한 뒤 차례로 지웁니다. Pruning은 과거 검증을 건너뛰는 스위치가 아니라 저장 공간을 아끼는 기능입니다. 앞서 설명한 최적화는 별개입니다. assumevalid는 일정 조건에서 옛 스크립트 검사를 생략하고, AssumeUTXO는 기록 검증이 진행되는 동안 스냅샷을 사용할 수 있게 합니다. 노드가 준비됐는지 볼 때는 디스크 크기만 보지 말고 동기화 방식과 실제 진행 상황을 확인하세요. [3] [2]
지갑에는 트랜잭션과 확정 정보가 필요합니다. 외부 서버에서 받는다면 그 서버에 질의를 보내고, 서버는 질의에서 결제에 관한 일부 정보를 추론할 수 있습니다. 자신의 Full Node에 연결하면 외부 서버에 이런 질의를 하지 않고 자신이 검증한 데이터를 사용할 수 있습니다. 하지만 노드를 설치하고 실행한다고 지갑의 연결이 자동으로 바뀌지는 않습니다. 실제로 지원하고 사용하는 데이터 출처가 중요합니다. 자신의 노드가 자동으로 익명성을 보장하지도 않습니다. 다른 네트워크 정보와 지갑 사용 방식도 개인정보 보호에 영향을 줍니다. [3] [4]
노드는 개인 키 없이도 작동합니다. 키는 결제에 서명하고, 노드는 트랜잭션과 블록이 규칙을 지키는지 검사합니다. 같은 장비가 두 작업을 모두 할 필요는 없습니다. 따라서 자신의 노드가 어딘가에서 실행되는지만 보지 말고, 지갑이 어디서 데이터를 읽고 어떤 경로로 트랜잭션을 전파하는지도 확인하세요. 독립 검증은 안전한 키 백업을 대신하지 않으며 네트워크 통신이 드러내는 모든 정보를 없애지도 않습니다. Bitcoin 데이터를 직접 검사한다는 과정의 특정 부분을 맡습니다. [3] [4]
노드에는 서로 다른 두 인터페이스가 있습니다. P2P 연결로는 다른 노드와 블록 및 트랜잭션을 교환합니다. RPC는 애플리케이션이 명령을 내리는 창구이며 경우에 따라 지갑까지 제어할 수 있습니다. 따라서 데이터 교환용 수신 P2P 포트를 여는 것과 낯선 사람에게 RPC를 공개하는 것은 다릅니다. Bitcoin Core는 RPC를 공용 인터넷에 직접 노출하지 않도록 권장합니다. 로컬 접근에는 보통 .cookie 파일의 인증 정보를 사용해 애플리케이션의 권한을 확인합니다. 브라우저의 추적용 쿠키와는 다릅니다. [4]
노드 명령으로 초록색 아이콘보다 많은 것을 확인할 수 있습니다. getblockchaininfo에서 올바른 네트워크인지 살피고, 처리한 블록 수인 blocks, 알려진 헤더 수인 headers, 초기 동기화 상태인 initialblockdownload를 확인하세요. 스냅샷을 쓴다면 getchainstates로 현재 상태와 백그라운드 기록 검증을 구분할 수 있습니다. 연결 수만으로 완전한 검증을 입증할 수는 없습니다. 마지막으로 노드가 오래된 체인 끝에 머물지 않았는지, 지갑이 정말 그 노드의 데이터를 쓰는지 확인하세요. 그래야 독립 검증이 실제 지갑 사용에 도움이 됩니다. [2] [1]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Bitcoin, Timechain / Blockchain, 트랜잭션, UTXO, Proof of Work. 다음 항목에서도 이 글을 참조합니다 Bitcoin, Satoshi Nakamoto, Timechain / Blockchain, Proof of Work.