233 / 736ORPH

Orphan Block

앞 장이 빠진 블록

Jana는 Bitcoin을 검증하는 컴퓨터인 자신의 노드를 운영합니다. 블록 하나가 도착했는데, 노드는 그 블록이 가리키는 이전 블록을 아직 모릅니다. 앞 페이지 없이 책의 다음 페이지를 받은 것과 비슷합니다. 새 글은 있지만 연결이 빠져 있는 것이죠. 좁은 의미의 Orphan Block은 바로 이런 경우입니다. 하지만 기사와 통계 화면에서는 이 말을 이력이 알려져 있으면서 곁가지에 남은 블록에도 자주 씁니다. 이름을 직역하는 것보다 두 상황을 구분하는 것이 중요합니다.

엄밀히 말해 Orphan Block은 특정 노드가 바로 앞 블록을 모르는 블록입니다. 넓은 용법에서는 활성 체인 밖의 Stale Block을 가리키기도 합니다. 어느 이름도 그 자체로 사기나 잘못된 블록을 뜻하지는 않습니다. 먼저 노드가 어떤 데이터를 갖고 있는지, 어떤 뜻으로 쓰였는지 알아야 합니다.

이전 블록을 부모 블록이라고도 부릅니다. 본래 의미의 Orphan Block에서는 Jana의 노드가 부모를 몰라 연결 관계의 검증을 마칠 수 없습니다. 반면 Stale Block은 부모가 알려져 있고 블록 전체도 유효할 수 있습니다. 노드가 다른 가지를 현재 이력으로 따를 뿐입니다. Bitcoin Developer Guide는 이 두 뜻을 명확히 구분합니다. Jana는 블록 탐색기에서 orphan을 보면 이전 블록이 없는 것인지, 단지 주 체인에 남지 못한 것인지 먼저 묻습니다. [1]

Bitcoin Core에서도 이 차이를 볼 수 있습니다. Bitcoin Core는 노드를 운영하는 소프트웨어로, Bitcoin 규칙에 따라 블록과 거래를 검증합니다. Bitcoin Core 29의 AcceptBlockHeader는 이전 블록의 식별용 지문을 참조하는 hashPrevBlock으로 앞 블록을 찾습니다. 색인에 기록이 없으면 prev-blk-not-found를 반환합니다. 부모를 알고 있고 무효로 표시되어 있으면 bad-prevblk를 반환합니다. 전자는 “판단에 필요한 맥락이 없다”, 후자는 “무효인 블록 위에 이어 붙이고 있다”는 뜻입니다. 누락된 이전 블록을 받으면 검사를 계속할 수 있지만, 그것만으로 전체 블록의 승인이 보장되지는 않습니다. [2]

블록에는 식별과 연결을 위한 짧은 정보인 헤더와 거래를 담은 본문이 있습니다. Bitcoin Core 0.10.0은 headers-first 동기화를 도입했습니다. 먼저 헤더를 받고 검증한 다음 여러 블록을 병렬로 내려받을 수 있습니다. 따라서 Jana의 노드는 이전 블록 전체가 디스크에 없어도 그 헤더를 알고 있을 수 있습니다. 블록 본문이 없는 것과 이전 블록이 알려지지 않은 것은 다릅니다. 둘을 혼동하면 평범한 다운로드 과정도 알 수 없는 문제처럼 보일 수 있습니다. [3]

Bitcoin Core 29의 getchaintips 명령은 노드가 어떤 가지의 끝을 알고 있는지 Jana에게 보여 줍니다. active는 활성 체인, valid-fork는 완전히 검증된 비활성 가지입니다. valid-headers는 블록이 모두 있지만 전체 검증을 마치지 않았다는 뜻이고, headers-only는 일부 블록이 없다는 뜻입니다. invalid는 무효인 블록이 포함된 가지를 가리킵니다. 모두 같은 문제를 나열한 목록이 아닙니다. 도움말의 orphaned branches라는 표현도 이 구분을 없애지는 않습니다. [4]

서로 다른 블록 A와 B가 높이 900000에 있다고 가정해 봅시다. 설명용 예시이지 특정 사건의 기록은 아닙니다. 높이는 체인 안의 위치이므로 경쟁하는 블록이 같은 값을 가질 수 있습니다. Jana는 식별용 지문인 hash와 이전 블록 참조인 previousblockhash로 구분합니다. 유효한 가지 중 선택을 결정하는 것은 높이만이 아니라 누적 작업량입니다. 프로그램에 명령하는 RPC 인터페이스는 이를 chainwork라고 부릅니다. 각 블록의 난이도에 해당하는 예상 작업량을 누적한 값입니다. [1] [5]

Jana가 getblock으로 주 체인 밖의 블록을 조회하면 Bitcoin Core 29는 confirmations = -1을 표시할 수 있습니다. 이는 특별한 상태 표시이지 일반적인 확인 횟수가 아닙니다. 카운트다운이나 음수인 체인 재구성 깊이도 아니며, 이전 블록이 없다는 증거도 아닙니다. Jana는 블록의 식별 정보와 가지 상태를 함께 살펴야 합니다. 또한 자신의 노드가 다른 참여자들이 지금까지 본 모든 블록을 갖고 있는 것은 아닐 수 있습니다. [5]

블록 보상은 coinbase라는 특별한 첫 거래에서 만들어집니다. 같은 이름의 거래소와는 관계없습니다. 거래 출력에는 비트코인 금액과 그 금액을 쓰기 위해 충족해야 할 조건이 기록됩니다. Bitcoin Core 29에서 COINBASE_MATURITY는 100입니다. 높이 H에서 만들어진 출력을 처음 쓸 수 있는 곳은 높이 H+100의 유효한 블록입니다. 몇 분이 지났는지가 아니라 높이 차이가 중요합니다. 하지만 이 대기 조건이 활성 체인에 포함되는 것을 대신하지는 않습니다. 보상 블록이 비활성 가지에 있는 동안 그 출력은 미사용 출력을 기록하는 활성 UTXO 집합에 없습니다. 다른 곳에서 블록이 늘어도 그 돈이 저절로 돌아오지는 않습니다. [6] [7] [1] [8]

Jana는 블록 hash, 이전 블록, 가지 상태, 소프트웨어 버전을 기록합니다. getchaintips와 getblock 응답, 그리고 응답을 얻은 시각도 덧붙입니다. 이 시각은 헤더의 time 필드와 따로 기록합니다. 블록의 타임스탬프는 자신의 컴퓨터가 관측한 시각이 아니기 때문입니다. 기록은 이후 관측과 비교하는 데 도움이 되지만, 그 자체로 공격이나 특정 네트워크 장애, 전 세계 orphan 비율을 증명하지는 않습니다. 우선은 한 노드의 특정 순간 상태를 설명합니다. [4] [5]

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Stale Block, Reorg, Block Propagation, Proof of Work, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Stale Block.

DOC · 001Bitcoin Developer Guide — Block height and forks문서 DOC · 002Bitcoin Core 29 — Header acceptance1차 출처 DOC · 003Bitcoin Core 0.10.0 — Headers-first synchronization1차 출처 DOC · 004Bitcoin Core 29 — getchaintips문서 DOC · 005Bitcoin Core 29 — getblock문서 DOC · 006Bitcoin Core 29 — Coinbase maturity1차 출처 DOC · 007Bitcoin Core 29 — Coinbase input validation1차 출처 DOC · 008Bitcoin Developer Guide — Transaction outputs문서
개정일: 1차 출처 우선 · 투자 조언이 아닙니다