비트코인 풀노드는 받은 블록과 거래를 자체 합의 규칙으로 검증하고 유효한 체인만 받아들이는 소프트웨어입니다. 다른 서버가 ‘유효하다’고 말한 결과를 신뢰하는 대신 입력·서명·UTXO·작업증명을 직접 확인하지만, 올바른 소프트웨어와 초기 동기화·네트워크 연결·운영 보안은 여전히 필요합니다.
풀노드는 장부를 복사하는 서버가 아니다
새 블록을 받으면 헤더의 작업증명과 이전 블록 연결, 거래 구조, 입력이 가리키는 미사용 출력, 서명, 금액 보존, 스크립트 규칙을 검증한다. 규칙을 어긴 블록은 작업량이 커 보여도 받아들이지 않는다.
Bitcoin Core About은 Bitcoin Core가 블록체인을 완전히 검증하는 full-node 소프트웨어와 지갑을 포함한다고 설명한다. 풀노드의 핵심은 데이터를 많이 저장한다는 사실보다 자신이 실행한 규칙으로 유효성을 판정한다는 데 있다.
채굴자는 후보 블록을 만들고 작업증명을 수행하지만 풀노드가 그 블록을 받아 줄 의무는 없다. 지갑은 키와 거래 생성을 담당할 수 있지만 원격 노드만 쓰면 체인 정보의 일부를 그 서버에 의존한다.
| 구성요소 | 주요 역할 | 직접 검증 범위 |
|---|---|---|
| 풀노드 | 블록·거래 검증·중계 | 합의 규칙 전체 |
| 채굴자 | 후보 블록 구성·작업증명 | 자신의 노드 검증도 필요 |
| 지갑 | 키 관리·거래 생성 | 연결 방식에 따라 다름 |
| 탐색기 | 주소·거래 조회 UI | 운영자 인덱스 결과 제공 |
| SPV/light client | 헤더·포함 증명 중심 | 전체 거래 규칙 직접 검증 아님 |
초기 블록 다운로드에서 무엇을 확인하나
IBD 동안 노드는 제네시스부터 헤더와 블록을 받아 순서대로 검증하고 현재 UTXO 집합을 만든다. 단순히 최신 데이터베이스 파일을 다운로드하는 것과 다르다. CPU, 디스크 읽기·쓰기, 네트워크가 오래 사용될 수 있다.
assumevalid 같은 최적화는 알려진 과거 블록의 일부 오래된 서명 검증을 생략해 속도를 높일 수 있지만 블록 구조와 작업증명, 이후 규칙 검증을 없애는 것이 아니다. 어떤 설정이 신뢰 가정을 바꾸는지 공식 버전 문서에서 확인한다.
pruned 노드도 풀 검증 노드인 이유
pruning은 블록을 검증해 UTXO 상태를 만든 뒤 오래된 원본 블록 파일을 삭제해 저장 공간을 줄인다. 초기 검증 과정과 새 블록 검증 규칙은 유지된다. 그러나 과거 블록을 다른 피어에게 제공하거나 오래된 지갑을 재스캔하는 기능은 제한된다.
archival과 full validation을 같은 뜻으로 쓰면 혼동된다. 운영 목적이 개인 거래 검증인지, 탐색기 인덱싱인지, 다른 노드 부트스트랩 제공인지에 따라 보관 모드를 선택한다.
내 노드를 써도 네트워크 프라이버시는 자동 완성되지 않는다
지갑이 자신의 노드에만 블록·거래를 묻으면 제3자 API에 주소 묶음을 노출하는 일을 줄일 수 있다. 하지만 거래 전파 시 피어가 최초 발신 IP를 추정하거나, Tor 설정과 피어 구성이 잘못될 수 있다. 지갑과 노드 연결이 실제 로컬인지 확인한다.
원격 RPC를 인터넷에 공개하면 지갑 정보와 노드 제어가 노출될 수 있다. rpcbind, 방화벽, 인증 파일, TLS 또는 안전한 터널을 최소 권한으로 설정하고 RPC 자격증명을 공유하지 않는다.
- 공식 배포 서명과 해시로 설치 파일 확인
- IBD 완료와 검증 진행률 확인
- 지갑이 실제 내 노드 RPC·P2P를 쓰는지 확인
- prune·txindex 목적에 맞게 설정
- RPC 공개 범위와 백업·업데이트 절차 점검
SPV와 제3자 탐색기의 증거 경계
비트코인 백서는 헤더 체인과 머클 포함 증명으로 결제를 확인하는 단순화 방식을 설명하면서, 공격자가 네트워크를 압도하는 동안 잘못된 거래에 속을 수 있는 한계를 언급한다. 자주 결제를 받는 사업자는 더 독립적인 검증을 위해 자체 노드를 고려할 수 있다고 적는다.
Bitcoin whitepaper의 이 구분은 HTTP 200 응답이나 탐색기 ‘confirmed’ 표시가 내 합의 검증과 같지 않다는 점을 보여 준다. 서비스 표시는 유용하지만 서버 운영자와 인덱스의 정확성에 의존한다.
직접 검증은 데이터를 직접 본다는 뜻보다 규칙 위반을 스스로 거부한다는 뜻에 가깝다.
JOBCOIN 해설
내 노드의 상태를 확인하는 최소 절차
getblockchaininfo에서 chain, blocks, headers, verificationprogress, initialblockdownload, pruned를 확인한다. blocks와 headers가 가깝고 IBD가 끝났더라도 시스템 시간이 맞는지, 피어가 충분한지, 오류 로그가 없는지 본다.
getnetworkinfo와 getpeerinfo로 연결 수와 네트워크 다양성을 확인하되 피어 수가 많다고 합의 안전성이 자동 증가하는 것은 아니다. 버전이 지원되는지 릴리스 공지와 대조하고 업그레이드 전 지갑·설정 백업을 확인한다.
노드가 반환한 거래를 다른 탐색기와 비교하는 것은 진단에 도움 되지만 최종 판단 기준은 노드의 검증 결과다. reorg나 아직 메모풀 상태인 거래는 서비스마다 다르게 보일 수 있으므로 블록 해시와 확인 수를 기록한다.
자주 묻는 질문
풀노드를 돌리면 채굴 보상을 받나요?
풀노드 검증만으로 채굴 보상이 생기지 않습니다. 채굴은 별도 작업증명과 블록 생산 활동입니다.
pruned 노드는 풀노드가 아닌가요?
과거 블록 보관을 줄이지만 받은 블록을 합의 규칙으로 검증합니다. 다만 과거 데이터 제공·재스캔 기능이 제한됩니다.
탐색기와 내 노드 결과가 다르면 무엇을 보나요?
체인·블록 높이·동기화 상태를 먼저 확인하세요. 직접 검증 목적이라면 정상 동기화된 내 노드의 합의 결과가 기준입니다.
