AssumeUTXO는 특정 블록의 상태를 저장한 스냅샷을 불러와 Bitcoin 노드를 더 일찍 사용할 수 있게 하는 방법입니다. 소프트웨어에 내장된 해당 상태의 예상 지문에 일시적으로 의존합니다. 이후 직접 거래 기록을 처리하고 결과를 비교하므로, 스냅샷이 그 작업을 대신하는 것은 아닙니다.
페터는 Bitcoin 규칙을 직접 검사하는 프로그램인 첫 Full Node를 시작합니다. 블록은 공동 기록에 추가하는 거래 묶음입니다. 보통은 긴 거래 기록을 먼저 처리해야 합니다. AssumeUTXO를 사용하면 준비된 UTXO set에서 출발할 수 있습니다. 아직 사용되지 않은 거래 출력의 집합으로, 각 출력에는 금액과 사용 조건이 들어 있습니다. 스냅샷은 특정 블록 이후의 상태를 담습니다. 모든 지급의 보관 기록도 아니고, 페터의 컴퓨터가 과거 전체를 이미 검증했다는 증거도 아닙니다. [1] [3]
파일 이름만 보고 스냅샷이 옳다고 할 수는 없습니다. loadtxoutset으로 불러올 때 Bitcoin Core v29.0은 형식, 기준 블록(스냅샷이 나타내는 블록), 지원 매개변수를 확인합니다. 또한 UTXO 내용의 암호학적 지문인 hash를 계산해 활성화 전에 예상값과 비교합니다. 내용이 바뀐 파일은 믿음직한 이름을 붙였다는 이유만으로 검사를 통과하지 못합니다. [2] [3] [6]
스냅샷을 받아들이면 노드는 그 상태에서 이어서 후속 블록을 검증하고 현재 체인 끝에 도달할 수 있습니다. 그대로 믿고 받아들이는 것은 아닙니다. 사용 조건과 허용되는 새 비트코인 발행량 등을 계속 검사합니다. 장점은 현재 활동으로 가는 이 경로가 더 오래된 거래 기록 처리의 완료를 기다리지 않아도 된다는 것입니다. 하지만 과거가 이미 로컬에서 검증되었다는 뜻은 아닙니다. [1] [6]
동시에 과거 블록을 처음부터 스냅샷의 기준점까지 처리하여 두 번째 상태를 만듭니다. 내려받은 목록을 한 번 더 복사하는 것이 아니라, 거래 기록을 바탕으로 독립적으로 계산하는 것입니다. 따라서 한동안 진행도가 다른 두 상태가 존재합니다. 기술 명령 getchainstates로 이를 볼 수 있습니다. 활성 상태가 최신 블록에 도달했다는 사실만으로 백그라운드 작업 완료까지 확인되지는 않습니다. [1] [8]
예상 hash와 지원 기준 블록은 특정 소프트웨어 버전에 포함됩니다. 페터의 노드가 거래 기록을 직접 계산해 마칠 때까지는 이 내장 정보가 옳다는 데 의존합니다. hash를 비교하면 내용의 일치 여부를 확인할 수 있지만, 그것만으로 그 내용이 유효한 거래 기록에서 나왔음을 증명할 수는 없습니다. 예상 상태가 틀렸다면 노드의 조기 사용도 잘못된 가정에 근거하게 됩니다. 그래서 나중의 거래 기록 검증을 불러오기 단계의 파일 검사와 구분해야 합니다. [2] [6]
파일을 다른 운영자에게 받아도 그 사람이 승인될 상태를 정할 권한을 얻는 것은 아닙니다. 중요한 것은 제공자의 약속이 아니라 소프트웨어가 지원하는 값과의 일치입니다. 아무 블록의 아무 스냅샷이나 불러올 수도 없습니다. 지원 여부는 버전과 네트워크에 달려 있습니다. Hash 검사 또한 파일 전달을 보장하지 않으며, 다운로드와 처리에 드는 시간, 대역폭, 디스크 공간을 없애 주지 않습니다. [2] [4] [7]
백그라운드 작업이 같은 기준 블록에 이르면, 노드는 직접 만든 UTXO set의 hash를 계산하여 예상 스냅샷 hash와 비교합니다. 현재 상태와 오래된 사진을 비교하는 것이 아니라, 거래 기록상 같은 시점끼리 비교하는 것입니다. 불일치하면 여기서 설명하는 구현은 노드를 종료하고 스냅샷에서 파생된 상태를 사용하지 않습니다. 차이를 숨기거나 검증 성공으로 보고하지 않습니다. [1] [6]
AssumeUTXO가 주로 바꾸는 것은 노드를 사용할 수 있을 때까지의 시간입니다. 거래 기록 다운로드와 검증은 계속되고, 한동안 두 상태 데이터베이스를 유지합니다. 처리 능력과 디스크 작업이 필요합니다. Pruned Node는 이미 처리한 오래된 블록 파일을 삭제해 공간을 절약하며, 규칙 검사를 생략하는 노드는 아닙니다. Pruned Node도 스냅샷을 사용할 수 있지만 저장 공간 절약에는 별도 제약이 있습니다. 일부 보조 인덱스는 거래 기록을 처음부터 처리해야 하므로, 노드가 먼저 준비되어도 연결된 모든 앱이 즉시 준비되는 것은 아닙니다. [5] [7]
UTXO set에는 미사용 출력 정보가 있을 뿐, 지출을 승인하는 개인 키는 없습니다. 디지털 서명은 비밀 숫자 값인 개인 키로 결제 승인을 증명하며, 키 자체는 공개하지 않습니다. UTXO set은 지갑 백업이 아니며, 해당 방식을 지원하는 지갑의 복구 단어인 Seed Phrase를 잃었을 때 되찾아 주지도 않습니다. 옛 지급이 바로 보이지 않을 수도 있습니다. 이를 찾으려면 스냅샷 이전의 블록이 필요할 수 있기 때문입니다. 키 백업, 내 지갑의 거래 내역 찾기, 네트워크 상태 검증은 서로 다른 작업입니다. [1] [7]
이름이 비슷해 혼동하기 쉽습니다. AssumeUTXO는 불러온 상태에서 시작하고 이전 거래 기록을 백그라운드에서 재구축합니다. 반면 assumevalid는 특정 조건에서 과거 스크립트 검사, 즉 서명을 포함한 사용 조건 검사의 일부를 생략할 수 있습니다. 이는 별도 최적화이며 거래 기록 검증에도 영향을 줄 수 있습니다. AssumeUTXO가 끝났다는 사실만으로 그것이 꺼져 있었다고 알 수는 없습니다. 안내를 읽을 때 노드의 출발점, 실제 검사 항목, 각 검사의 완료 시점을 구분하세요. [5] [6]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Initial Block Download, Pruned Node, Block Propagation, Nakamoto Consensus, Bitcoin, Bitcoin Core. 다음 항목에서도 이 글을 참조합니다 Initial Block Download, Pruned Node, Utreexo.