Initial Block Download

집에서 Full Node를 실행한다고 생각해 보세요. Bitcoin 블록과 거래를 독립적으로 검사하는 프로그램입니다. 블록은 공동 기록에 추가하는 거래 묶음입니다. 다른 참여자에게는 긴 역사가 쌓여 있지만 새 노드는 아직 그것을 갖고 있지 않습니다. 먼저 블록들을 연결하는 짧은 기록인 헤더를 받습니다. 헤더에는 계산 작업의 증거인 Proof of Work도 들어 있습니다. 채굴자는 계산을 반복해 이 증거를 찾으며, 다른 참여자는 찾아낸 결과를 빠르게 확인할 수 있습니다. 헤더 목록은 책의 목차와 비슷합니다. 길잡이가 되지만 목차를 받았다고 모든 페이지를 읽고 확인한 것은 아닙니다. [1] [7]

이웃 노드들이 서로 다른 역사 분기를 제시해도 다수결로 정하지 않습니다. 헤더를 통해 누적된 계산 작업량을 비교하고 추가로 검증할 유력한 후보를 고릅니다. 블록 수가 많다고 작업량도 반드시 많은 것은 아닙니다. 작업량이 아무리 커도 유효하지 않은 거래가 규칙을 면제받지는 않습니다. 선택한 분기의 내용은 여전히 검사해야 합니다. [1] [2] [6]

노드는 여러 이웃에게서 블록을 동시에 받아 한 발신자의 속도에만 의존하지 않을 수 있습니다. 하지만 검증된 역사에 연결하려면 이전 상태를 알아야 합니다. 결제의 입력은 이번에 사용하려는 이전 금액을 가리킵니다. 노드는 그 금액이 존재하고 아직 사용되지 않았는지 확인해야 합니다. 그래서 나중 블록을 이미 받았어도 앞선 블록이 처리되기를 기다릴 수 있습니다. 데이터 다운로드와 동기화 완료가 같지 않은 이유입니다. [1] [2]

노드는 블록 내용을 헤더 안의 거래 지문과 비교합니다. 이 지문은 Merkle Tree라는 구조로 만들어집니다. 자금이 사용된 순서와 채굴자 보상이 허용된 금액을 넘지 않는지도 검사합니다. 이때는 역사상 해당 시점에 유효했던 규칙을 적용합니다. 디지털 서명은 비밀 숫자 값인 개인 키로 결제 승인을 증명하며, 키 자체는 공개하지 않습니다. 오래된 서명과 다른 사용 조건의 검사에는 아래에서 설명할 assumevalid라는 별도 설정이 있습니다. 헤더나 믿을 만해 보이는 이웃의 파일이 이 검사 전체를 대신하지는 않습니다. [2] [3]

블록을 처리할 때마다 사용된 출력은 제거하고 새 출력을 추가합니다. 출력은 나중에 사용할 조건이 붙은 구체적인 금액입니다. 아직 사용되지 않은 출력은 UTXO라고 부릅니다. 이들의 집합이 있으면 다음 결제를 검사할 때마다 전체 역사를 처음부터 다시 읽지 않아도 됩니다. 은행 계좌 목록도 아니고 과거 모든 거래의 복사본도 아닙니다. [2] [3]

특정 조건에서 Bitcoin Core는 오래된 스크립트 검사, 즉 서명과 다른 사용 조건의 검사를 생략할 수 있습니다. assumevalid 설정은 그 역사가 외부에서 검증된 알려진 블록을 지정합니다. 조상 관계, 충분한 작업량, 깊이도 조건에 해당합니다. 다른 필수 검사는 유지하지만 검증 결과의 일부를 전제로 받아들이는 것입니다. 따라서 잘못된 전제에 위험이 없는 것은 아닙니다. assumevalid=0은 이 최적화를 끄는 대신 컴퓨터가 더 많은 작업을 하게 합니다. [2]

Pruned Node는 오래된 블록 파일을 처리한 뒤 삭제하고 현재 UTXO와 필요한 다른 데이터를 보관합니다. 일반적인 IBD에서는 여전히 역사를 받아 처리합니다. 전체를 영구 보관하지 않을 뿐입니다. 줄어드는 것은 디스크 공간이며 첫 다운로드의 데이터량이 자동으로 줄어드는 것은 아닙니다. 나중에 삭제한 블록이 필요한 작업을 하면 다시 받아야 할 수 있습니다. [2] [7]

Bitcoin Core v29.0은 최근 받아들인 블록의 시점, 최소 누적 작업량, 로딩 상태 등을 고려합니다. 이 동작용 표시가 한 번 false(초기 동기화 종료)가 되면 같은 실행 중에는 true(초기 동기화 진행 중)로 돌아가지 않습니다. 프로그램 동작을 안내할 뿐, 세상 어디에도 더 새로운 블록이 없다는 증거가 아닙니다. 이후 연결이 끊어져도 항상 최신 상태임을 알려 주는 신뢰할 만한 지표가 되지는 않습니다. [2] [5]

빠른 연결은 도움이 되지만 컴퓨터는 계산과 디스크 기록도 해야 합니다. 프로세서, 메모리, 저장장치, 연결 가능한 이웃이 소요 시간에 영향을 줍니다. getblockchaininfo의 기술 출력에서 verificationprogress는 검증 진행 상황의 추정치입니다. 남은 분 수를 약속하지도, 단순히 다운로드한 바이트의 비율을 뜻하지도 않습니다. 정상 종료 후 다시 실행하면 저장한 지점에서 이어갈 수 있어 매번 처음부터 시작할 필요가 없습니다. [5] [7]

AssumeUTXO는 지원되는 UTXO 스냅샷, 즉 특정 블록 시점에 저장한 상태를 사용할 수 있게 합니다. 소프트웨어는 내용을 예상한 지문과 대조한 뒤 그 상태에서 더 일찍 현재를 따라잡을 수 있으며, 동시에 뒤에서 과거를 처리합니다. 이후 역사 검증으로 얻은 상태도 비교합니다. 낯선 사람이 준 임의의 데이터베이스를 받아들이거나 과거를 영원히 검증하지 않는 방법은 아닙니다. 일찍 사용할 수 있는 단계와 역사 검증이 끝난 단계는 서로 다릅니다. [4] [8]