Ordinals vs Taro: 비트코인 2층 네트워크의 실행 가능성 탐구 - 상편

作者：3P Labs

일, 서론

비트코인(Bitcoin)은 가장 초기이자 가장 안전한 블록체인으로, 사용되는 UTxO 계좌 모델로 인해 이더리움(Ethereum)과 같은 스마트 계약 기능을 지원하기 어려워, 제한된 스크립트 언어 기반 기능만을 지원할 수 있습니다. 그래서 비트코인이 탄생한 15년 동안, 이더리움에서의 다양한 화려한 DeFi 프로토콜이나 NFT를 구현하는 데 사용되지 않고, 주로 P2P 송금과 가치 저장에 사용되었습니다.

2022년 12월 14일에 공식적으로 시작된 오디널스(Ordinals) 프로토콜은 이러한 상황을 바꾸었습니다. 이 프로토콜은 사용자가 체인에 저장해야 하는 메타데이터를 거래 입력에 포함시키고, 서수 이론[\^1]에 기반하여 이러한 "명문(Inscriptions)"을 추적하고 기록하는 프로그램을 구현했습니다. 이러한 "명각"은 정적 메타데이터를 기록하는 것이며, 이더리움 스마트 계약과 같은 동적으로 실행 가능한 체인 상 프로그램이 아닙니다. 이는 "명문"이 비트코인에서 자연스럽게 NFT가 되도록 합니다. 서수 이론에 기반하여 사람들은 이러한 명문 간의 전송 및 거래를 구현하는 거래를 구축할 수 있습니다.

그 후, 2023년 3월 6일, 오디널스를 기반으로 한 BRC-20 프로토콜이 제안되었습니다. 이는 비트코인에서 동질화된 토큰을 구현하는 데 사용되며, 이더리움의 ERC-20 프로토콜에 해당합니다. 이러한 오디널스 기반 프로토콜은 매우 간단하여, JSON 형식으로 토큰의 발행 및 전송 과정을 명문에 기록합니다. 가장 상징적인 비유는 송금 기록이 적힌 종이들로, 회계는 제3자 기관에 맡기는 것입니다.

이러한 BRC-20 프로토콜은 폭력 미학의 미감을 가지고 있으며, 다양한 요소들 간의 타협이기도 합니다. 이전에 비트코인에서도 컬러코인과 같은 동질화된 토큰이 존재했지만, 이는 BRC-20이 실패한 응용이라는 것을 반증하지는 않지만, 아마도 그것이 장기적인 프로토콜이 아닐 수 있음을 나타냅니다. 이제 본문의 주제로 들어가겠습니다. 바로 라이트닝 네트워크 기반의 주근 자산(Taproot Assets)입니다.

이, 라이트닝 네트워크

라이트닝 네트워크는 비트코인 위에 구축된 Layer 2 솔루션으로, 비트코인의 결제 시나리오에서 사용자에게 비용 절감 및 효율성 향상을 돕는 것을 목표로 합니다. 라이트닝 네트워크가 의존하는 아이디어는 매우 간단합니다. 즉, 자금 풀을 구축하는 것입니다. 이러한 자금 풀은 거래 쌍방의 마이크로 결제 채널로도 불립니다. 좀 더 구체적으로, 두 가지 핵심 개념이 포함됩니다:

* Revocable Sequence Maturity Contract (RSMC): 시퀀스 만료 가능 계약
* Hashed Timelock Contract (HTLC): 해시 시간 잠금 계약

RSMC는 거래 쌍방 간에 마이크로 결제 채널이 존재한다고 가정합니다. 양측은 먼저 이 채널에 일부 자금을 예치하며, 초기 상태에서 양측의 분배 계획은 미리 예치된 금액입니다. 거래가 발생할 때마다 양측은 거래 후 발생한 분배 결과를 확인해야 하며, 기존의 분배 계획은 무효화해야 합니다. 이 과정은 여러 개념을 포함하고 있으며, 매우 교묘합니다. 구체적인 내용은 [A Dive into Lightning Network (Part One)][\^14]를 참조하시기 바랍니다. 이 메커니즘의 역할은 라이트닝 네트워크 내에서 양측 간의 결제 채널을 구축하는 것입니다.

HTLC는 이벤트 기반 해시 잠금으로, 특정 당사자가 일정 시간 내에 해시 값 $h=H(m)$의 원형 $m$을 제출해야 특정 UTxO의 사용 권한을 얻을 수 있도록 요구합니다. 이는 라이트닝 네트워크에서 결제 경로를 구축하는 데 사용되며, 구체적인 구현 과정은 [Lightning network in depth, part 2: HTLC and payment routing][\^15]를 참조하시기 바랍니다.

라이트닝 네트워크는 이 두 가지 메커니즘을 통합하여 거래가 라이트닝 네트워크 내의 임의의 두 노드 간에 체인 외에서 완료될 수 있도록 합니다.

삼, Taproot 업그레이드

Taproot는 세 가지 비트코인 개선 제안(BIP)[[BIP-0340 (Schnorr Signature)][[BIP-0341 (Taproot)][[BIP-0342 (TapScript)]의 집합체로, Taro 자산이 구현될 수 있는 기초입니다. 여기서 Taro 자산의 구현에 관련된 MAST에 대해 설명하겠습니다:

MAST

BIP-0341에서는 머클 추상 구문 트리(Merklized Abstract Syntax Tree, MAST)[\^7][\^8][\^9]를 도입하여 UTxO의 지출 조건을 숨기고 정보의 크기를 줄이는 것을 목표로 합니다. 이는 Taproot 업그레이드의 일부로, Taproot 업그레이드는 기존의 P2SH(Pay-to-Script-Hash)와 P2PKH(Pay-to-Public-Key-Hash)를 결합하여 하나의 출력이 개인 키를 통해 직접 사용될 수 있도록 하며, 지출 출력을 위한 스크립트와 머클 증명을 제공할 수 있습니다.

MAST는 추상 구문 트리와 머클 트리를 결합하여, 머클 트리는 블록체인에서 일반적으로 사용되는 데이터 구조로 여기서 더 이상 설명하지 않겠습니다. 추상 구문 트리(AST)는 프로그램을 독립적인 작은 조각으로 나누어 프로그램을 설명하는 방법으로, 이를 통해 프로그램을 쉽게 분석하고 최적화할 수 있습니다. 구체적인 내용은 [Abstract syntax tree](https://en.wikipedia.org/wiki/Abstractsyntaxtree)를 참조하시기 바랍니다. MAST는 AST의 프로그램을 여러 작은 조각으로 나누는 아이디어를 결합하고, 각 조각을 해시하여 머클 해시 트리의 아이디어를 사용하여 이러한 해시 결과를 머클 트리로 구성합니다.

다음과 같은 스크립트를 고려해 보겠습니다[\^9]: 앨리스(Alice)는 언제든지 자신의 비트코인을 사용할 수 있기를 원하지만, 만약 그녀가 연속으로 3개월 동안 사용하지 않으면 그녀의 형제인 밥(Bob)과 찰리(Charlie)가 이 UTxO를 사용할 수 있습니다. 이 스크립트의 구현은 다음과 같습니다.

OPIF \<앨리스의 공개 키> OPCheckSig
OPELSE "3 months" OPCSV OPDROP 2 \<밥의 공개 키> \<찰리의 공개 키> 2 OPCHECKMULTISIG
OP_ENDIF

P2SH 하에서는 이러한 스크립트가 지출 시 거래에 완전히 노출되어야 하며, 앨리스는 이 UTxO를 지출할 때 해당 스크립트와 그 안에 포함된 밥과 찰리의 공개 키를 제공해야 합니다.

MAST가 도입된 후, 해당 스크립트의 두 조건을 나누어 간단한 MAST를 얻을 수 있습니다.

이때 앨리스는 지출할 때 자신의 공개 키 검증 스크립트와 Hash2를 머클 증명으로 제공하기만 하면 되며, Hash 2 아래의 구체적인 스크립트를 노출할 필요가 없습니다. 이 부분의 정보는 체인에 올라가지 않습니다. 이는 유사 거래의 비용을 더욱 줄이는 데 기여합니다. 이는 매우 자연스러운 일로, 전체 스크립트를 제공하는 것보다 스크립트의 해시 값만 제공하는 데이터 양이 항상 적습니다. 이러한 구조는 스마트 계약의 구현 가능성을 제공합니다. 이러한 방식은 EVM의 바이트코드와 유사하며, 실행 전에 입력 데이터의 처음 4바이트에 따라 호출할 함수를 선택할 수 있습니다. 다른 점은, 이러한 스크립트 호출에는 사용자가 구체적인 스크립트와 머클 증명을 제공하여 스크립트의 합법성을 증명해야 한다는 것입니다.

사, 주근 자산

주근 자산(Taproot Assets, 이하 Taro)[\^2][\^3][\^5]은 비트코인에서 자산을 발행할 수 있는 제안 단계의 프로토콜입니다. 이러한 자산은 체인 상의 거래를 통해 비트코인 네트워크에서 전송될 수 있습니다(Ordinals에 의해 NFT의 거래 및 전송이 이미 구현되었습니다). 특히, 동질화된 Taro 자산은 라이트닝 채널에 저장된 후 라이트닝 네트워크에서 더 낮은 수수료로, 더 비공식적으로 전송될 수 있습니다. 이와 유사하게 라이트닝 네트워크에서 스마트 계약을 실행하려는 RGB 프로토콜[\^4]도 있습니다.

Taro는 비트코인 메인넷 또는 2층 라이트닝 네트워크에서 유통될 수 있습니다. 먼저 비트코인 네트워크의 경우를 고려해 보겠습니다. Taro는 거래에 추가된** 해시화된 메타데이터 형태**로, 해시화의 목적은 거래의 공간 점유를 줄여 수수료를 절감하는 것입니다. 이러한** 해시화된 메타데이터 형태**는 Taro의 핵심으로, 이러한 해시 값 하나가 실제로 수백만 번의 거래를 나타낼 수 있습니다. 그 원리는 후속에서 설명하겠습니다.

다음으로 Taro의 라이트닝 네트워크 상황을 살펴보면, 라이트닝 네트워크를 사용하면 동질화된 Taro 자산이 더 빠른 거래 속도를 구현할 수 있습니다. 이는 라이트닝 네트워크를 사용하여 비트코인을 더 빠르고 저렴하게 전송할 수 있는 것과 유사합니다. Taro의 제안에서, 라이트닝 네트워크 자체는 변경할 필요가 없으며, 특정 Taro 자산의 거래를 구현하기 위해서는 전체 결제 경로의 첫 번째 채널과 마지막 채널이 Taro 자산을 인식할 수 있으면 됩니다. 중간의 라우팅 채널은 정상적인 라이트닝 네트워크 송금 방법을 사용하며, 이들은 동등한 비트코인을 송금합니다. 이로 인해 Taro 자산은 일반적으로 네트워크의 가장자리에서 다른 자산과 교환됩니다.

Taro 프로토콜

Taro가 가져올 수 있는 이점을 이해했으니, 이제 그것이 무엇인지, 그리고 어떻게 구현되는지 소개하겠습니다. BRC-20이 제3자 기관에 의해 기록되는 송금 기록이 적힌 종이 조각이라면, ERC-20은 스마트 계약이 기록하고 유지하는 잔액 정보의 문자열입니다. Taro는 자산의 발행 및 전송을 어떻게 구현할까요?

자산 트리

자산 트리는 Taro 내의 이중 머클 트리 구조로, Taro 자산을 나타내는 데 사용됩니다. 첫 번째 수준은 Taro 정보를 잎 노드로 구성한 머클 트리이며, 두 번째 수준은 MS-SMT를 통해 각 계정이 보유한 자산을 나타내는 트리로 구성됩니다. MS-SMT의 아이디어는 간단합니다. 머클 해시 트리가 해시를 기반으로 트리 구조를 구성하는 동시에, 각 노드는 왼쪽과 오른쪽 두 자식 노드의 합을 저장하여 구현됩니다(해시 연산 자체도 일종의 합산으로 간주됩니다). 이러한 자산 트리와 MS-SMT 트리는 Taro의 UTxO를 구축하는 데 사용됩니다.

자산 잎(Aseet Leaf)은 자산 트리의 가장 하위 구조로, 자산 트리 도식에서 연한 파란색 노드로 표현됩니다. 이는 assetScriptKey(자산 스크립트 키는 P2SH 거래에서 거래 스크립트의 해시 값에 비유될 수 있습니다)를 키로 사용합니다. 각 자산 잎은 Taro 자산의 하나의 UTxO를 나타내며, 자산 잎에 포함된 선택적 항목은 [Understanding Taproot Assets Protocol]를 참조하시기 바랍니다.

MS-SMT

머클 총합 희소 트리(Merkle Sum Sparse Merkle Tree)[\^11]는 [bip-tap-ms-smt]에서 정의된 데이터 구조로, 희소 머클 트리의 강화 버전입니다. 현재 bips에서 아직 수용되지 않은 제안입니다. 키(key)가 256비트 길이이므로, 이러한 MS-SMT는 $2^{256}$개의 잎 노드를 가지며, 그 대부분은 비어 있습니다. 따라서 이는 희소 머클 트리입니다.

각 잎은 수량을 포함하고 있으며, 각 분기는 잎의 총량을 제출합니다. 이를 통해 각 자식 트리의 내용을 알지 못한 채로도 분기 내에 포함된 총합을 알 수 있습니다. 일반적인 머클 트리와 마찬가지로, 어떤 잎을 포함하는 잘린 트리는 멤버 존재 증명을 제공할 수 있습니다(이는 암호 누적기에서의 개념으로, 집합 내의 요소가 존재함을 증명하는 "증명"입니다). MS-SMT는 멤버 부재 증명도 지원합니다(이는 존재하지 않는 키의 잎을 None으로 명시적으로 표시하여 구현됩니다). 즉, 이러한 키가 트리에서 None임을 증명하여 존재하지 않음을 증명합니다. 이러한 구조는 트리에서 저장된 값과 분포의 변화 여부를 효율적으로 검증할 수 있습니다.

아래 그림은 머클 총합 트리와 그 변경된 구조를 보여주며, 머클 총합 희소 트리는 희소 트리의 특성을 결합하여 비어 있는 요소 노드를 잘라내고 의미 있는 정보만 저장하며, 비어 있는 노드는 None으로 표시됩니다.

Taro 자산 발행

Taro 자산의 발행에는 식별자가 필요합니다. ERC-20 토큰의 스마트 계약이 주소를 가지듯이, Taro 프로토콜은 식별자 생성 방식을 정의합니다: ID=SHA256(genesisPoint||assetTag||assetMeta) 이는 자산을 발행하는 데 사용되는 거래 출력 정보, 자산 태그(예: 자산 이름의 해시 값), 자산의 메타데이터(이미지, 링크 또는 문서)를 해시하여 식별자를 생성합니다.

Taro 자산의 전송 스크립트는 비트코인 거래와 유사한 입력 및 출력을 가질 수 있으며, 자산을 생성하는 거래는 Taro 자산의 입력을 포함할 필요가 없습니다. 이는 Taro 자산이 비트코인의 UTxO 모델을 따르고 있음을 보여줍니다. 자산의 발행은 Taro 자산 거래를 발행하는 것이며, 입력이 없고 출력만 있습니다.

Taro의 입력과 출력은 자산 트리를 기반으로 구현됩니다. 앞서 언급한 바와 같이, 자산 트리의 첫 번째 수준은 해당 UTxO*에 저장된 Taro 자산이 무엇인지 나타내며, Taro 자산 ID에 해당하는 MS-SMT는 해당 UTxO* 출력의 Taro 자산 정보를 저장합니다.

Taro 자산 발행 거래를 구성하는 과정은 아래 그림과 같이, 비트코인 UTxO를 입력으로 사용하고, 정상적인 비트코인 UTxO와 추가적인 Taro 자산 A의 UTxO*를 출력합니다.**이러한 UTxO\*는 비트코인에서 머클 루트 형태로 나타나며** 체인 외에서는 자산 트리 형태로 나타나고, 자산 트리에는 Taro 자산 A의 assetId와 자산 A에 해당하는 MS-SMT의 기록이 기록됩니다.

Taro 자산 전송

이전 소절에서 자산의 생성 과정을 이해했다면, 자산의 전송 과정을 더 빨리 이해할 수 있습니다. 자산의 전송은 비트코인에서의 거래와 유사하며, 사용 가능한 UTxO를 입력으로 선택한 후, 일련의 UTxO를 출력합니다. Taro 자산에서는 사용 가능한 UTxO*를 입력으로 선택하고, 일련의 UTxO*를 출력합니다.

이 거래에서 A는 자신의 Taro 자산 X를 B에게 전부 전송하며, 분할하지 않습니다. B가 해당 거래를 수신할 때, 자산이 지불 조건을 충족하는지 확인하고, 추가 출력이 발생하지 않았는지 확인해야 합니다.

검증해야 할 조건은 다음과 같습니다:

* B가 생성한 자산 트리에 지불 조건을 충족하는 새로운 UTxO가 포함되어 있는가?
* 입력 UTxO가 이미 업데이트된 A의 자산 트리에서 삭제되었는가?
* 거래에 다른 출력이 있다면, 그것들이 다른 자산 트리를 포함하고 있는가?

이러한 정보는 MS-SMT의 멤버/비멤버 증명 및 Taro 출력의 원형과 증명을 통해 검증할 수 있습니다. 자산의 병합 및 분할은 더 이상 설명하지 않겠습니다. 이들의 과정은 자산 전송 과정과 유사하지만, 출력의 UTxO*에는 분할 증명 또는 병합 증명이 포함되어 있습니다.

Taro 유니버스

유니버스는 자산 소유자에게 자산 정보 및 증명 서비스를 제공하는 것입니다 [\^6]. 그 기능은 비트코인 블록 탐색기[\^13]와 유사하지만, Taro 자산 클라이언트와 함께 체인 외에 저장된 Taproot 자산의 거래 데이터를 표시합니다. 유니버스는 자산 발행자가 직접 운영할 수도 있고, 발행자가 특정 운영자를 임명할 수도 있습니다. 커뮤니티가 운영하는 유니버스는 자산 소유자가 제출한 정보를 집계할 수 있습니다.

오, 결론

이상으로, 우리는 Taro 자산 구현에 기반한 기술과 그 자체의 구현 원리를 간단히 소개했습니다. 다음 편에서는 3P Labs가 오디널스 및 Taro 자산의 발전 현황을 소개할 것입니다.

자료 인용
[\^1]: [Ordinal Theory Handbook]
[\^2]:[What Is Taro in Bitcoin?]
[\^3]:[Taproot Assets]
[\^4]:[A BRIEF INTRODUCTION TO RGB PROTOCOLS]
[\^5]:[Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning]
[\^6]:[Taproot Assets Protocol]
[\^7]:[Merklized Abstract Syntax Tree]
[\^8]:[Merklized Abstract Syntax Tree]
[\^9]:[What is a Bitcoin Merklized Abstract Syntax Tree (MAST)?]
[\^10]:[Understanding Taproot Assets Protocol]
[\^11]:[bip-tap-ms-smt]
[\^12]:[Fixing The Privacy Gap In Proof Of Liability Protocols]

[\^13]:[Blockstream Explorer]
[\^14]:[A Dive into Lightning Network (Part One)]([A Dive into Lightning Network (Part One)]
[\^15]:[Lightning network in depth, part 2: HTLC and payment routing]