Taproot 머클 분기

분기의 각 해시는 taptree의 형제 하나이며, 여러분의 리프에서 위쪽 루트까지 순서대로 나열됩니다. BIP-341은 분기를 128개의 해시, 4,096바이트로 제한하며, 정렬된 트리이기 때문에 분기에는 좌우 방향 비트가 전혀 들어가지 않습니다. 분기 길이는 공개되므로, 리프가 깊을수록 여러분 트리의 최소 깊이가 드러나고 어떤 지갑이 해당 출력을 만들었는지에 대한 단서가 됩니다.

작동 방식

Taproot 머클 분기는 컨트롤 블록 안에 담겨 이동하며, 컨트롤 블록은 앵넥스(있는 경우)를 제거한 뒤 스크립트 경로 지출의 위트니스 스택에서 마지막 항목입니다.

컨트롤 블록은 정해진 구조를 가집니다. 0번째 바이트에는 리프 버전과 출력 키의 Y 좌표 패리티가 들어갑니다. 1번째부터 32번째까지의 바이트에는 내부 공개 키가 들어갑니다. 그 뒤의 전부가 분기입니다: 연속된 32바이트 해시 m개이므로 컨트롤 블록은 33 + 32m바이트가 되며, m은 0부터 128까지의 정수여야 합니다. 다른 길이는 오피코드가 하나라도 실행되기 전에 지출을 실패시킵니다.

검증은 아래에서 시작합니다. 노드는 공개된 스크립트를 TapLeaf 태그로 해시한 다음, 분기의 각 해시를 차례로 TapBranch 태그로 접어 넣으며, 매 단계에서 두 32바이트 값을 사전순으로 비교해 더 작은 값을 먼저 해시합니다. 그 결과로 나오는 것이 taptree 루트이며, 이는 내부 키와 함께 TapTweak 태그로 해시되고 내부 포인트에 더해진 뒤 지출 대상 출력의 32바이트와 대조됩니다.

그 비교가 이 방식의 핵심입니다. BIP-341이 두 자식을 해시하기 전에 정렬하기 때문에, 분기는 형제가 어느 쪽에 있었는지 말하지 않습니다: 검증자가 스스로 알아냅니다. 그 근거는 이유를 분명히 밝히는데, 이 설계는 트리에서 특정 스크립트의 위치에는 관심이 없고 그 스크립트가 실제로 커밋되어 있다는 점만 중요하다고 말합니다.

128이라는 상한은 임의의 제한이 아니라 보안 경계입니다. 최적으로 채운 트리에서 깊이는 리프 확률의 역수의 밑 2 로그에 가까워지므로, 깊이 129는 사용될 확률이 2^128분의 1 미만인 스크립트를 뜻하며, BIP-341은 그런 스크립트는 아마 삭제해도 된다고 말합니다. 다른 쪽 끝에서, 리프가 하나뿐인 taptree는 m이 0이고 분기가 비어 있으며, tapleaf 해시가 이미 루트입니다.

확인할 수 있는 곳

Taproot 머클 분기는 키로 서명하는 대신 스크립트를 공개하여 bc1p 출력을 지출하는 모든 트랜잭션에 나타납니다.

BIP-341은 리프가 다섯 개인 트리에서 예시 하나를 다룹니다. A, B, C, E는 TapLeaf 해시이고 AB는 처음 두 개에 대한 TapBranch 해시입니다. 스크립트 D로 지출하려면 컨트롤 블록에 C, 그다음 E, 그다음 AB가 담깁니다: 해시 세 개, 분기 96바이트, 컨트롤 블록 129바이트입니다. E와 CD가 결합될 때 E가 먼저 해시되는데, E가 사전순으로 더 작기 때문입니다.

계획해야 할 것은 프라이버시 비용입니다. BIP-341의 보안 섹션은 스크립트의 깊이가 트리의 최소 깊이를 드러낸다고 말하는데, 이는 해당 출력을 만든 지갑 소프트웨어를 암시하고 체인 분석이 주소를 묶는 데 도움을 주며, 리프 확률이 주는 트리에서 벗어날 것을 권고합니다. 리프 재사용이 또 다른 함정입니다: 다른 출력을 지출하면 같은 분기 해시가 다시 공개될 수 있어, 32바이트 형제를 공유하는 두 지출은 관련된 것처럼 보입니다.

Taproot 머클 분기 vs 머클 블록

Taproot 머클 분기는 스크립트가 어떤 주소에 속함을 증명하고, 머클 블록은 트랜잭션이 어떤 블록에 속함을 증명합니다. taptree 분기는 합의 규칙에 핵심적이고, 지출을 검증하는 모든 풀 노드가 이를 다시 계산하며, 정렬이 좌우를 표시할 필요를 없앴기 때문에 이 분기는 위치와 무관합니다. 블록의 트랜잭션 트리에 대한 증명은 그 방식을 빌려올 수 없는데, 블록의 머클 루트 아래에서 트랜잭션의 순서가 고정되어 있고 의미가 있기 때문에 해시뿐 아니라 이동 경로도 함께 담아야 합니다.