比特幣二層網路可行性探討(上):Ordinals vs Taro

一、引言

Bitcoin 作為最早、最安全的區塊鏈,所使用的UTxO 帳戶模型導致它很難支援像Ethereum 的智慧合約功能,只能支援一些有限的基於腳本語言的功能。所以自Bitcoin 誕生的15 年間,它沒有被用來實現像Ethereum 上的各種讓人眼花繚亂的DeFi 協議、NFT,通常被用於點對點轉帳和價值存儲。

2022 年12 月14 日被正式啟動的Ordinals 協定改變了這一切,它將使用者所需存放到鏈上的元資料放入交易輸入中,並基於序數理論[^1]實現了一套程式來追蹤並記錄這些「銘文(Inscriptions)」。這樣的「銘刻」所實現的是記錄了靜態的元數據,而不是如Ethereum 智能合約一樣的可動態執行的鏈上程序。這也使得「銘文」自然地成為了Bitcoin 上的NFT。而基於序數理論,人們也能夠建構交易來實現這些銘文之間的轉移、交易。

此後,在2023 年3 月6 日,基於Ordinals 的BRC-20 協議被提出,它被用於實現Bitcoin 上的同質化代幣,對應了Ethereum 上的ERC-20 協議。而這樣基於Ordinals 的協議很簡單,以Json 的格式將代幣的鑄造、轉移的過程寫到銘文上,最為形象的比喻就是一張張寫上轉賬記錄的紙,而記賬的事情交給第三方機構去做。

比特幣二層網路可行性探討(上):Ordinals vs Taro

這樣的BRC-20 協議頗有暴力美學的美感,也是一種在各種因素下的妥協。在先前Bitcoin 也曾出現過像彩色幣的同質化代幣,這不能證偽BRC-20 是失敗的應用,但似乎也能說明它或許不是一種長久的協議。至此,進入本文的主題,基於閃電網路的主根資產(Taproot Assets)。

二、閃電網絡

閃電網路是建立在Bitcoin 上的Layer 2 解決方案,其目的是在Bitcoin 的支付場景下幫助用戶節省成本、提高效率。而閃電網路所依賴的想法也很簡單,也就是建構資金池,這樣的資金池也被稱為交易雙方的微支付通道。更具體一點,牽涉到兩個核心概念:

· 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 是三個比特幣改進提案(Bitcoin Improvement Proposal, BIP)BIP-0340 (Schnorr 簽名)、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]。 MAST 結合了AST 的將程式劃分為多個小塊的思想,再把程式每個小塊進行哈希,利用默克爾哈希樹的思想把這些哈希結果建構成默克爾樹。

比特幣二層網路可行性探討(上):Ordinals vs Taro

考慮這樣一個腳本[^9]:Alice 希望隨時可以花費她的比特幣,但是如果她連續三個月沒有花費,那麼她的兄弟姐妹Bob 和Charlie 就可以花費這筆UTxO,其腳本實現如下

OP_IF

OP_CheckSig

OP_ELSE

“3 months” OP_CSV OP_DROP

2 2 OP_CHECKMULTISIG

OP_ENDIF

在P2SH 下,這樣的腳本是需要在花費時完全暴露在交易中的,Alice 在花費這筆UTxO 的同時需要提供該腳本,以及包含在其中的Bob 和Charlie 的公鑰。

而在有了MAST 後,對該腳本的兩個條件進行劃分,得到一個簡單的MAST

比特幣二層網路可行性探討(上):Ordinals vs Taro

此時,Alice 在花費的時候只需要選擇提供她的公鑰驗證腳本和Hash2 作為默克爾證明即可,而不需要暴露Hash 2 下的具體腳本,這部分資訊不會上鍊。而這樣也進一步降低了類似交易的開銷,這是很自然的,提供完整的腳本總是比提供腳本的雜湊值的資料量少。而這樣的結構也為智能合約的實作提供了可能,這樣的方式正如EVM 中的字節碼一樣,在運行前可以根據輸入資料的前4 個位元組來選取將要呼叫的函數。不同地方在於,這樣的腳本呼叫需要使用者提供具體的腳本,以及梅克爾證明來證明腳本是合法的。

四、主根資產

主根資產(Taproot Assets,後續簡稱為Taro)[^2][^3][^5]是一種還在提議階段的協議,它可以實現在Bitcoin 上發行資產,這樣的資產可以透過鏈上的交易透過比特幣網路轉移(對NFT 的交易、轉移已經被Ordinals 實現)。特別地,同質化的Taro 資產可以在存入閃電通道後在閃電網路上以更低的手續費、更為隱私地轉移,類似的還有嘗試在閃電網路上運行智慧合約的RGB 協議[^4]。

Taro 可以在Bitcoin 主網或二層的閃電網路上流通。先考慮在Bitcoin 網路的情況,Taro 是附加在交易上的哈希化元資料形式,使用哈希化的目的在於降低交易的佔用空間以節省手續費。而這樣的哈希化元資料形式則是Taro 的核心,這樣的一個哈希值甚至可以代表實際上的數百萬次交易,它的原理會在後續進行介紹。

其次是Taro 在閃電網路上的情況,使用閃電網路可以讓同質化的Taro 資產實現更快的交易速度,這類似於使用閃電網路可以更快、成本更低地轉移比特幣。在Tar​​o 的提議中,閃電網路本身不需要改變,為了實現某種Taro 資產的交易,只需要整個支付路徑的第一個通道和最後一條通道可以識別Taro 資產即可,而中途的路由通道則是正常的閃電網路轉帳方法,它們轉帳等價的比特幣,這也導致Taro 資產通常會在網路的邊緣和其他資產交換。

Taro 協議

既然了解了Taro 所能帶來的好處,那麼接下來需要介紹的是,它是什麼?以及如何實現?正如需要了解BRC-20 就是一堆寫好轉帳記錄需要第三方機構來記帳的紙片,ERC-20 是智能合約所記錄和維護的一串餘額資訊一樣。 Taro 又是如何實現資產的發行、轉移的?

資產樹

資產樹是Taro 中的一種兩級默克爾樹結構,它被用來代表Taro 資產。第一層是由Taro 資訊作為葉子節點而構成的默克爾樹,而第二級則是透過MS-SMT 構成的表示每個帳戶所具有的該資產的樹,MS-SMT 的思想較為簡單,它在默克爾哈希樹基於哈希來構成樹形結構的同時,每個節點也存放了左右兩個子節點的和來實現(進行哈希運算本身也算一種求和),這樣的資產樹和MS-SMT 樹被用來建構Taro 的UTxO。

比特幣二層網路可行性探討(上):Ordinals vs Taro

資產葉(Aseet Leaft)是資產樹中最底層的結構,它表現為資產樹示意圖中的淡藍色節點,它以assetScriptKey (assetScriptKey 可以類比P2SH 交易中對交易腳本的雜湊值)作為鍵。每個資產葉表示Taro 資產的一個UTxO,資產葉中包含的可選項可參見 [Understanding Taproot Assets Protocol]。

MS-SMT

梅克爾總和稀疏樹(Merkle Sum Sparse Merkle Tree)[^11]是在 [bip-tap-ms-smt] 中定義的資料結構,它是稀疏默克爾樹的增強版本,目前是bips 中一個仍未被接收的提案。由於鍵(key)是256 bits 長的,所以這樣的MS-SMT 有$2^{256}$ 個葉子節點,其中的大部分是空的,所以它是稀疏的默克爾樹。

每個葉子包含了一個數量,每個分支向上提交葉子中的總量,這樣可以在不知道每個子樹的內容的情況下知道分支中包含的總和。而和一般的默克爾樹一樣,包含任何葉子的被修剪過的樹可以提供成員存在證明(這是密碼累加器中的一個概念,它是一種「證明」用來證實一個元素在一個集合中)。而MS-SMT 也支持成員不存在證明(它通過明確地指示不存在的鍵的葉子為None 來實現),即證明這樣的鍵在樹中為None 來證實它不存在,這樣的結構可以高效地驗證樹上儲存的數值和分佈是否有改變。

下圖是一個默克爾總和樹以及它發送改變後的結構,而默克爾總和稀疏樹則是結合了稀疏樹的特點,將空元素節點修建掉,只存放有意義的信息,空節點使用None 表示。

比特幣二層網路可行性探討(上):Ordinals vs Taro

Taro 資產發行

Taro 資產的發行需要一個標識符,正如ERC-20 代幣的智能合約會擁有一個地址一樣,Taro 協議定義了標識符的生成方式:ID = SHA256(genesisPoint||assetTag||assetMeta) ,它將鑄造資產所使用的交易輸出資訊、資產標籤(例如資產名稱的哈希值)以及資產的元資料(圖片、連結或文件)進行哈希,從而得到一個識別碼。

Taro 資產的轉移腳本可以有類似比特幣交易的輸入輸出,而創建資產的交易不需要包含任何的Taro 資產的輸入,由此可見,Taro 資產沿用了比特幣的UTxO 模型,資產的發行就是發布一筆Taro 資產的交易,它沒有輸入,只有輸出。

Taro 的輸入和輸出是基於資產樹來實現的,正如前文所述,資產樹的第一級代表了該筆UTxO* (後面會繼續沿用這種寫法,* 表明這樣的結構是在Taro 資產中而非Bitcoin 中)中存放的Taro 資產有哪些,而Taro 資產ID 所對應的MS-SMT 中所存放的是該筆UTxO* 輸出的Trao 資產的資訊。

建構一筆Taro 資產的發行交易如下圖所示,以一筆Bitcoin 的UTxO 作為輸入,輸出一筆正常的Bitcoin UTxO 以及附加的Taro 資產A 的UTxO*。這樣的UTxO* 在Bitcoin 上表現為一個默克爾根的形式,而它在鏈下表現為資產樹的形式,資產樹中記錄了Taro 資產A 的assetId 以及資產A 對應的MS-SMT 中的記錄。

比特幣二層網路可行性探討(上):Ordinals vs Taro

Taro 資產轉移

如果能理解上一小節中資產的創建,那麼就可以更快地理解資產的轉移過程。資產的轉移和Bitcoin 中的一筆交易是類似的,選擇一系列可用的UTxO 作為輸入,然後再輸出一系列的UTxO。在Tar​​o 資產中則是選擇一系列可用的UTxO* 作為輸入,並輸出一系列的UTxO*。

比特幣二層網路可行性探討(上):Ordinals vs Taro

在這筆交易中,A 將自己的Trao 資產X 全部轉移給B,並且不進行拆分。當B 接收到該交易時,需要驗證資產是否滿足支付條件且沒有產生多餘的輸出來確認收到資產。

所需要驗證的條件包括但不限於:

· 為B 所建立的資產樹是否包含符合付款條件的新UTxO?

· 輸入UTxO 是否已經從已經更新了的A 的資產樹中刪除?

· 如果交易中還有其他的產出,那麼它們是否包含另外的資產樹?

這些資訊可以由MS-SMT 的成員/ 非成員證明以及Trproot 輸出的前像以及證明來進行驗證。對資產的合併、拆分不再進行贅述,它們的過程和資產轉移的過程類似,但是在輸出的UTxO* 中包含了拆分證明或合併證明。

Taro Universe

Universe 是一種為資產的持有人提供有關資產資訊以及證明的服務 [^6],其作用類似比特幣區塊瀏覽器[^13],但是它會展示與Taro 資產用戶端一起儲存在鏈下的Taproot 資產的交易資料。 Universe 可以由資產的發行人自己經營,也可以由發行人任命某個運營商,可以想像的是由社區運營的Universe 匯總來資產持有者提交的信息。

五、結束語

上篇到此為止,我們簡單地介紹了Taro 資產實作所基於的技術,以及它本身的實作原理。在下篇中,我們將會介紹Ordinals 及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]

Total
0
Shares
Related Posts