작가 : 곤도 히로키
출처: https://medium.com/nayuta-engineering-blog-en/understanding-taproot-assets-protocol-e2dfe3fc1e07
Taproot Assets 프로토콜(이전의 "Taro", 이하 "TAP"로 약칭)은 비트코인에서 UTXO 기반 자산을 표현하기 위한 프로토콜입니다. 이 기사는 TAP가 자산을 생성하고 전송하는 방법을 설명하는 데 전념합니다.
전체 프로토콜은 여러 부분으로 나뉩니다. 이 글에서는 주로 bip-tap과 bit-tap-ms-smt에 대해 설명합니다.
Lightning Labs의 구현은 여기에서 확인할 수 있습니다.
탭루트란 무엇인가요?
" Taproot "는 두 가지 유형의 지출 조건, 즉 키 지출( Key Path )과 스크립트 지출( Script Path )을 동시에 지정할 수 있는 새로운 유형의 비트코인 출력입니다.
Key Path 기존 P2PKH 출력과 마찬가지로 공개 키 서명을 사용하여 사용됩니다. Schnorr 서명 키 집계(다중 서명)도 여기 Taproot에서 사용할 수 있습니다.
기존 P2SH와 마찬가지로 Script Path 복잡한 지출 조건을 스크립트 언어로 프로그래밍할 수 있습니다. 그리고 Taproot를 사용하면 동시에 여러 스크립트를 지정할 수도 있습니다. 이러한 스크립트는 Taproot 출력에서 직접 직렬화되지 않지만 Merkle 트리로 구성되어 루트 해시로 압축됩니다. 스크립트를 사용하여 출력을 소비하는 경우 다른 스크립트는 노출하지 않고 해당 스크립트만 노출하면 됩니다.
TAP는 Script Pat ("자산 트리")에 데이터를 포함합니다. 이 데이터는 해시되었기 때문에 비트코인 노드에서 해석하거나 감지할 수 없습니다.
Taproot Assets의 자산 표현
자산 트리
자산 트리는 Taproot Assets 프로토콜을 표현하는 2단계 "Sparse Merkle sum tree" 구조입니다. 하위 수준은 자산의 UTXO("자산 ID( asset_id )"로 식별됨)를 나타냅니다. 상위 레벨은 하위 레벨의 트리를 집계합니다.
상위 Merkle 트리의 루트 해시 값( asset_tree_root) 값은 Taproot의 Script Path 출력에 포함되어 트리 상태에 커밋됩니다.
자산을 양도하면 새 자산 트리도 생성되고 이전 자산 트리가 업데이트됩니다. 이는 기존 자산 트리의 Taproot 출력을 사용하는 새로운 비트코인 거래를 시작함으로써 달성할 수 있습니다. 사양(예: 인플레이션, 중복 호출)을 충족하지 않는 전송은 유효하지 않은 것으로 간주됩니다. *
* 여기서 사용된 방법은 " 클라이언트 검증 "이라는 개념입니다. 비트코인의 놀라운 합의에 익숙한 독자들은 여기서 사양의 정확성에 대한 근거가 궁금할 수 있지만 지금은 그 문제를 무시하겠습니다.
희소 머클 합 트리
"Sparse Merkle sum tree"(이하 "MS-SMT"로 약칭) 는 bip-tap-ms-smt 로 정의된 Merkle 트리의 변형입니다. 키가 256비트이므로 2^256개의 리프가 있습니다. 대부분의 잎은 비어 있습니다.
각 리프에는 수량이 포함되어 있으며 각 분기 노드는 해당 하위 트리의 리프로 표시되는 수량의 합계를 약속합니다. 하위 트리의 내용을 알 수 없더라도 가지 노드만 조사하면 해당 하위 트리에 포함된 총 개수를 알 수 있습니다. 나무의 뿌리는 모든 잎이 대표하는 총량을 약속합니다.
일반적인 머클 트리와 마찬가지로, 목표 잎을 포함하는 가지치기된 나무만으로도 이러한 목표 잎이 나무에 있다는 증거를 제공할 수 있습니다(머클 증명). 그러나 MS-SMT는 "증명 없음"도 지원합니다. 이는 제한 사항에 의해 수행됩니다. 존재하지 않는 키워드를 나타내는 리프 수는 해당 키워드가 존재하지 않음(None)을 나타내는 값으로 명시적으로 설정되어야 합니다(따라서 "None"의 존재는 One에 증거가 포함되어 있지 않음을 의미함). 따라서 기본 MS-SMT에는 "없음"을 나타내는 2^256개의 리프가 있습니다.
자산 리프(자산 UTXO)
자산 트리의 하위 수준 MS-MST에는 키로 asset_script_key 있고 값으로 자산 리프가 있습니다. 각 자산 리프는 자산의 UTXO를 나타내며(단순화를 위해 아래에서는 "UTXO"*로 직접 표현됨) 다음 속성(선택적 속성 포함) 은 "유형-길이-값" 형식 으로 직렬화됩니다.
* 비트코인의 UTXO가 아닙니다 ㅎㅎ.
-
taproot_asset_version -
asset_genesis -
asset_id -
asset_type -
amt -
lock_time -
relative_lock_time -
prev_asset_witnesses
-prev_asset_id
-asset_witness
split_commitment_proof -
split_commitment -
asset_script_version -
asset_script_key -
asset_group_key -
canonical_universe
asset_genesis asset_id 의 원본 이미지를 파생시키는 것입니다.
asset_script_key 자산 리프에 대한 키워드이자 Taproot(비트코인과 독립적인 tap-vm 에 정의됨) 형태의 공개 키이며, 해당 자산 리프가 나타내는 UTXO를 소비하기 위한 조건입니다.
UTXO를 사용할 때 먼저 (외부) 비트코인 지출 조건이 충족되어야 하며, 그런 다음 asset_script_key 및 asset_script_key 에 의해 지정된 (내부) TAP 지출 조건이 prev_asset_id 및 asset_witness 에 의해 충족되어야 합니다. 예를 들어, asset_witness 소비되는 UTXO의 asset_script_key 의 서명입니다.
자산 전송 중에 UTXO가 분할되는 경우 split_commitment 및 split_commitment_proof 도 필요합니다.
split_commitment 분할 후 모든 UTXO를 참조하는 MS-SMT이며(이 의미에서 자산 트리는 실제로 3단계로 구성됨) 루트의 합계 값은 전송된 모든 수량입니다.
split_commitment_proof 는 split_commitment 의 Merkle 증명으로, 분할의 존재를 증명합니다.
모든 분할 중에서 단 하나만 prev_asset_id , asset_witness 및 split_commitment 갖습니다. 다른 모든 분할에는 split_commitment_proof 만 있습니다. 모든 파티션은 prev_asset_id 및 asset_witness 공유합니다.
자산 생성
자산을 생성하려면 비트코인 거래의 Taproot 출력에 새 자산의 UTXO를 포함하는 새 자산 트리를 삽입해야 합니다(거래는 자산의 최초 거래가 됩니다). 자산 ID( asset_id )는 다음 공식에 따라 결정됩니다.
asset_id := sha256(genesis_outpoint || sha256(asset_tag) || asset_meta_hash || output_index || asset_type) genesis_outpoint 는 이 트랜잭션이 소비한 이전 트랜잭션 출력이고, output_index 는 이 자산 트리의 출력을 포함하는 인덱스 번호입니다. 이렇게 하면 asset_id 가 전역적으로 고유하게 됩니다.
새로 생성된 자산 UTXO에는 prev_asset_id 및 asset_witness 생략되어 있습니다.
자산 양도
비트코인 UTXO와 마찬가지로 자산 UTXO는 자산 전송 시 병합되거나 분할될 수 있습니다. 하지만 분할도 병합도 아닌 간단한 예부터 시작해 보겠습니다.
*다음 설명은 다소 단순화되었습니다. 예를 들어 비트코인 거래의 변경 출력은 생략됩니다.
Alice는 10개의 특정 자산을 가지고 있으며 모두 Bob에게 이전됩니다.
Alice는 자산 UTXO가 있는 Taproot 출력을 사용하여 비트코인 거래를 생성하고 브로드캐스트합니다. 이 거래에는 두 개의 Taproot 출력이 있습니다. 하나의 출력에는 10개의 특정 자산을 소유하고 Bob이 제어할 수 있는(예: Bob의 비트코인 공개 키 사용) 새로운 UTXO를 포함하는 새로운 자산 트리가 포함됩니다. 다른 출력에는 Alice가 제어하는 원래 자산 트리에서 해당 자산 잎을 제거하여 형성된 자산 트리가 포함되어 있습니다.
Bob에게 속한 새로운 UTXO는 prev_asset_id 사용하여 Alice의 선주문 UTXO를 인덱싱합니다. asset_witness 에는 전문적인 asset_script_key 의 서명이 있습니다. 이 새로운 UTXO의 asset_script_key 에는 Bob이 미리 제공한 새로운 공개 키가 있습니다.
Bob은 지불 수령을 확인하기 위해 지출 조건이 충족되었는지, 이체 후 자산이 부풀려지지 않았는지 확인해야 합니다.
- Bob이 새로 생성한 자산 트리에는 지출 조건을 충족하는 새로운 UTXO가 포함되어 있습니까?
- 입력 UXTO가 Alice의 업데이트된 자산 트리에서 제거되었습니까?
- 트랜잭션에 다른 Taproot 출력이 있습니까? 다른 자산 트리가 포함되어 있나요? *
- 등.
이는 MS-SMT의 포함/비포함 증거와 Taproot에서 출력된 증거 및 사전 이미지를 증명/검증함으로써 달성됩니다.
* 또 다른 UTXO가 다른 자산 트리(Bob의 자산 트리가 아님)에 추가되고 입력된 UTXO도 소비되면 이중 지출이 됩니다.
UTXO 병합
Alice는 두 잎에 각각 3개와 7개의 특정 자산을 갖고 있으며 이 자산을 모두 Bob에게 전송하려고 합니다.
각 입력 UTXO는 다른 자산 트리에 속하거나 동일한 자산 트리의 다른 키( asset_script_key )에 속할 수 있습니다. Bob의 새 UTXO에는 소비된 두 UTXO에 대한 prev_asset_id 및 asset_witness 포함되어야 합니다.
UTXO 분할
Alice는 특정 자산 중 7개를 보유하고 있으며 3개를 Bob에게 전송할 준비가 되어 있습니다. 따라서 Alice는 3을 갖고 Bob은 7을 갖게 됩니다.
Alice의 변경 UTXO에는 prev_asset_id , asset_witness 및 split_commitment 가 있으며, Bot의 새 UTXO에는 split_commitment_proof *만 있습니다.
UTXO를 병합하고 분할하는 방법을 동시에 설명하지는 않겠습니다.
* 이는 사양 과 약간 다르지만 최신 구현 에서는 이렇게 하는 것 같습니다.
자산 양도
앞에는 볼륨이 없지만 자산 이전을 검증하려면 각 입력 UTXO가 적법한지 검증해야 합니다. 각 입력 UTXO에 대해 자산 생성 트랜잭션부터 현재 입력까지 전체 유통 경로의 모든 트랜잭션이 올바르게 실행되는지 입증/검증해야 합니다.
이 경로는 최초 트랜잭션부터 최신 트랜잭션까지의 복잡한 그래프입니다. 위 그림에서 Tx A 의 경우 모든 파란색 트랜잭션(상위 트랜잭션)을 확인해야 하며 Tx B 의 경우 모든 파란색 및 빨간색 트랜잭션을 확인해야 합니다. 기록이 준기하급수적으로 증가할 것이기 때문에 이는 확장성에 있어 중요한 문제입니다.
또한, 검증에 필요한 사전 이미지와 증거물이 온체인 에 게시되지 않기 때문에 자산의 송신자와 수신자 간에 이를 어떻게 전송할 것인지도 문제가 됩니다.
확장성
기록을 늘리는 것은 중요한 확장성 문제입니다. 여러 가지 솔루션이 제안되었지만 Lightning Network에 대한 지원이 가장 유망한 솔루션입니다. 오프체인 거래는 내역에 추가되지 않습니다.
이 프로토콜 세트는 새로운 것이며 사양이 불완전합니다. 예를 들어, 나는 이전에 이 문제를 지적한 적이 있습니다.
