多方共享的 UTXO：形式與特性

08-30

作者：Anony

“多方共享的 UTXO（sharing UTXO）”（下文縮寫為 “共享 UTXO”），顧名思義，就是讓多個用戶共享對一個 UTXO 的所有權、讓他們的資金寄身於同一個 UTXO 中。這個概念的側重點不是對權限的管理，而是對內部狀態的表達和控制 —— 讓多個用戶的資金容身於一個 UTXO 中，但依然能保證自主保管，而不會被其它用戶侵犯所有權。

對 “共享 UTXO” 這個概念的關注和開發由來已久。從最廣義的角度看，任何超過一方控制 UTXO 的設計，都可算作此類。這個最廣義的定義會將 “閃電通道” 這樣的兩方共享 UTXO 也包含在內。即使我們有意排除這樣的兩方共享 UTXO，只包含三方及以上共享 UTXO 的情形，那麼，於 2018 年提出的 “通道工廠（channel factory）” ^[1] 概念也無疑是共享 UTXO 的一個子集。此外，於 2020 年提出的 “支付池（CoinPool）” ^[2] 概念，以及在討論 “限制條款（covenant）” 提議時 “順帶” 提出的一些設計 ^[3]，都為這個主題增加了內容。

實際上，人們提出的設計是如此多樣，已界臨容易引起困惑和混淆的程度（至少對我自己來說是如此）。這些理解上的障礙，要求我們歸納這些設計的共性、確定一個基礎概念，並基於這個基礎概念以及配套的術語來解釋這些設計。

值得一提的是，一些作者已明確開始這樣做了（將看似不同的概念當成同一概念上的有區別設計） ^[4]；Optech 的主題界面，也將意義相近的 “payment pool” 和 “Coinpool” 都合併到了 “Joinpool” 的名下 ^[5]（但依舊未提出 “Joinpool” 和 “通道工廠” 的基礎概念）。

在這些努力的啟發下，本文嘗試將 “共享 UTXO” 作為基礎概念，討論這個概念要面臨的基礎問題，並解釋常見的一些設計（比如：通道工廠、Statechain、ARK）的形式和特性。

在此之前，我們要先解釋一些更基礎的概念。

基礎概念

承諾交易

在合約式協議（contractual protocol）中，“承諾交易（commitment transaction）” 指的是得到了對手方的簽名（因而有效、可用）、但默認不向外廣播的交易。這些交易可以被當成對手方給出的 “可信承諾”，也是參與者確保自己可以單方面取回自己應得的資金的保證。

比如，在閃電通道中，通道初始化以及每次更新通道狀態的時候，雙方都要交給對手方一個承諾交易；這些承諾交易記錄了兩方在通道內的最新狀態（餘額），一旦被髮送到鏈上確認，就會將通道資金分拆給雙方。

這裡要強調的是承諾交易表達一個合約內部狀態的能力。一個閃電通道在鏈上僅僅表現為一個 UTXO，但它卻能容納兩個用戶的資金在裡面，所依靠的，正是承諾交易的這種能力。

vTXO

在 “共享 UTXO” 的語境下，“vTXO（虛擬的 UTXO）” 指的是寄身於 UTXO 中的用戶資金的最基本單元。提出這個術語是為了分析和表達上的便利。但同時，這樣的稱謂也有嚴格的事實基礎：給定我們以承諾交易的輸出（TXO）來表達用戶的資金，這些資金的動作跟 UTXO 是沒有分別的。

在這裡，我將 vTXO 分成兩種類型：（1）排他性佔有的資金（就像常見的單簽名 UTXO），可稱為 “coin”；（2）閃電通道。這裡之所以分成兩種類型（而不是將閃電通道也當成一種共享 UTXO，從而當作只有前者一種類型），是因為：（1）閃電通道的交易輸出中都留有為實現下文即將提到的 “鏈下更新機制” 而專門設計的裝置，不能算作 coin；（2）排他性佔有的資金與閃電通道在使用體驗上有極大的不同：閃電通道允許發起即時支付（同時，閃電網絡可以放大這種支付能力），而且支付的大小是可以調整的；但在排他性佔有的資金中，這兩者都是做不到的；（3）關於閃電通道的特性，我們已經積累了大量的知識，也有了可以描述這些特性的術語，沒有必要將其表述為一種共享 UTXO、然後用與共享 UTXO 的術語將這些特性重新表述一遍；將它當成一個基本的可分析的單元，會在理解上提供極大的便利。

這種分類，從字面上看當然是不完美的，但卻是有用的。往後我們會看到，從形式上看，一些設計（比如：帶有服務商的單向通道）似乎也符合閃電通道的分類理由，但其實際用法卻更接近於 coin；這種情況下，我依然將其歸類為 coin。

鏈下更新機制

僅僅擁有 “承諾交易”，還不足以構造出閃電通道。設想一下，如果我們只是能讓兩個用戶的資金寄身於同一個 UTXO 中，但每次他們要相互支付時，都依然需要發起一筆鏈上交易，那麼這種構造的實用性是很值得懷疑的。閃電通道的成功之處，就在於設計出了一種可用的、在鏈下更新承諾交易的機制（“LN-Panelty”），從而允許雙方相互支付而無需發起鏈上交易。

在共享 UTXO 的語境下，鏈下更新機制指的是能在 vTXO 之間轉移資金而不需要鏈上確認的機制。

共享 UTXO

在 CoinPool 一文 ^[2] 中，兩位作者歸納了一種重要的特性：“非交互式任意順序取款”，意思是，無論何時退出，用戶總能取回自己應得的資金，並且取款過程不需要他人的幫助。我認為，這一屬性是共享 UTXO 的根本屬性，缺失了這一屬性，就會淪為一種託管方案；不管這種託管方案內部有什麼樣的設計，都不能稱為 “共享 UTXO”。

在技術上，這就意味著，我們需要讓每一方（每一個 vTXO 的持有者），都能否決共享 UTXO 的狀態變更，否則，就有可能出現多數參與者侵犯某個參與者資金所有權的事情。也即，所有可能發生的狀態變更，都必須得到每一位參與者（預先或即時）的同意。

比如，如果有 3 個用戶共享一個 UTXO，那麼不論是甲動用其中的資金向外支付，還是甲希望給乙支付，只要交易以該共享 UTXO 為輸入，都必須保證：沒有丙的簽名同意，這些交易就不能生效。否則，甲和乙就有可能串謀傾吞丙的資金。

然而，在實用性上，這就構成了一種挑戰：一旦某個用戶離線，其它用戶更新狀態的能力就會受到影響（雖然取款能力不受影響）。（類似於在閃電通道中，對手方離線會使你無法操作通道中的資金）。

可以說，所有的共享 UTXO 的設計，都是在應對這個挑戰。

接下來，我們會用一系列的例子，介紹在共享 UTXO 內部表達狀態的形式以及 vTXO 的類型，如何決定離線用戶對共享 UTXO 的影響，並相應影響共享 UTXO 的實用性和使用體驗。

擁堵控制

先考慮一種最簡單的多人共享 UTXO：n 方都在一個 UTXO 內擁有資金（vTXO），並且這些 vTXO 都是排他性控制的；這些 vTXO 都得到了同一筆承諾交易的承諾（每一方都持有同一筆承諾交易，並且都得到了其它所有人的簽名）；一旦這樣的承諾交易得到廣播和區塊確認，就會將這個共享 UTXO 完全分解，即內部狀態完全曝光、每個人都拿回自己原本存放在共享 UTXO 中的資金。如下圖所示：

congestion-control-s

這是一種最簡單的設計：vTXO 使用了最簡單的類型、沒有鏈下更新機制（因此三人無法在鏈下發起內部支付）、任何一個人單方面退出都會導致全體退出。這樣一種構造，到底有什麼用呢？

Jeremy Rubin 根據其使用場景，將這種構造命名為 “擁堵控制（congestion control）”，其用途是：在手續費高漲的時候，將需要發生的許多支付 “存放” 在一個 UTXO 中，等待手續費降低到可接受的水平時，再將這些支付在鏈上展開。比如，在手續費高漲的時候，Alice 三人希望從託管式交易所取款，那麼交易所可以協調三方初始化一個共享的 UTXO，將三人的資金先打到這個共享的 UTXO；等手續費退潮的時候，三人再合作或使用手中的承諾交易取出其中的資金。

如果能保證三人始終在線，那麼這種構造的有用性會大大提高：三人可以進一步協調手續費；也可以不使用自己再承諾交易中使用的收款地址，而是直接向另一個人支付。但在用戶隨機的情況下，這是無法保證的。而在非合作退出的情形中，由於承諾交易已預先鎖定了手續費，希望加速確認的用戶只能使用子交易來追加手續費（即 “CPFP” ^[6]），而不能使用 “手續費替換（RBF）”。

與此相關的，另一個可能受到批評的地方在於其全體退出機制：在非合作情形下，如果某個用戶比其他人更急著退出，而承諾交易預設的手續費率無法做到，那麼 TA 將需要獨自承擔讓所有這些 UTXO 都得到鏈上確認的額外手續費。這意味著，如果擁堵控制 UTXO 中的用戶並不都具有相同的時間偏好和使用模式，其用戶體驗就會打折扣甚至變成災難。

有沒有辦法，能夠只彈出一個 vTXO，而不是讓所有的 vTXO 都展開呢？顯然是有的 —— 僅僅 “只是” 更深度地利用擁堵控制這種構造而已。

改進的擁堵控制

如下圖所示，我們可以這樣初始化一個擁堵控制 UTXO：當 Alice 想要單方取款時，她能夠動用的承諾交易只會彈出屬於她的 vTXO，而將剩餘的資金交回給屬於剩餘參與者的另一個擁堵控制 UTXO（比如下圖中的 “擁堵控制 UTXO-2”），該擁堵控制 UTXO 也被預先簽名了承諾交易，能讓 Bob 和 Carol 可以單方退出。其餘情形也是同理，因此下圖中的 “承諾交易 B” 和 “承諾交易 C” 沒有進一步細化。

high-congestion-control

這種構造可以大大緩解前面提到的額外手續費問題，因為，用戶無論什麼時候取款，都只需多確認一個 UTXO 而已。

而且，假設 Alice 也會給大家分享自己對承諾交易 A 的簽名，那麼該交易也可被其他用戶用作 “排除交易” —— 在 Alice 長時間無響應的時候，將她彈出這個共享的 UTXO，讓剩餘的用戶能享受正常的共享 UTXO 可以給他們帶來的好處。這也可以限制 Alice 的離線給其他用戶帶來的影響。

美中不足的是，這種構造只允許用戶一個一個排隊退出；如果有多個用戶嘗試同時退出，就會發生所謂的 “狀態爭用/競爭進入（race condition）” 問題：這些用戶將發起手續費競賽，以爭奪排隊的次序（優先退出的資格）。因為我們並未安排允許多個用戶同時退出的承諾交易 —— 如果有這樣的承諾交易，就無需爭用。例如，當觀察到 Alice 要退出時，Bob 可以使用準備好的讓三人同時退出的承諾交易，以 RBF 方法讓這筆交易獲得比 Alice 的交易更高的確認優先級（這對 Bob 來說是好事，比等待 Alice 先退出、自己再發起一筆交易要更加便宜）；當 Bob 的交易獲得確認時，三人可以同步退出。

乍看起來，似乎毫無疑問應該增設這種允許多人同時退出的承諾交易。但與此同時，“共享 UTXO” 這個概念也將開始向我們展現它的崢嶸之處：與上述簡單擁堵控制構造相比，改進後的構造在初始化時需要用戶簽名的承諾交易數量大大增加，也即用戶間交互的需求大量增加；而且，它不是隨用戶的數量而線性增加的，而是會出現所謂的 “組合爆炸”；如果再增設這樣的允許多人同時退出的承諾交易，退出的可能性會進一步爆炸（如果因為 3 人的數量太少而使這一點不明顯，讀者可以嘗試畫一個 5 人的共享 UTXO）。

用戶要用哪種通信手段完成這麼多的交互？（當然是互聯網，問題是這些用戶如何找尋彼此呢？）給定一個用戶在初始化過程中失聯就會導致初始化完全失敗、必須從頭再來的可能性，是否應使用某種抗女巫機制？這些都是需要考慮的問題。

那麼，是否有某種中庸之道？

樹形結構

考慮下圖這樣的共享 UTXO：當 Alice 想要退出（或其他人想要排除 Alice）時，Alice 無法直接從共享 UTXO 中彈出，而需要先廣播 “承諾交易 01”，該交易會將原本的共享 UTXO 對半分拆成兩個共享的 UTXO；然後，Alice 廣播下一筆承諾交易，繼續分拆自身所在的共享 UTXO；…… 如此，直至其 vTXO 完全退出。

（熟悉這個領域的讀者想必會脫口而出：“這是一種樹形結構！”沒錯，正是如此。）

tree-sharing

在退出的公平性上，這種構造不如上一節所述的構造：視乎 Alice 退出的先後，她幾乎總是需要額外確認多於 1 個 UTXO。在我們這個例子中，如果她最先退出的話，她需要額外確認 2 個 UTXO。如果是一個 8 人的共享 UTXO，則她需要額外確認 3 個 UTXO。

然而，只要仔細觀察上圖，就可以發現其巨大優點，尤其在參數者數量較多的時候：

（1）需要簽名的承諾交易的數量大大減少（本構造在多出 1 位用戶的前提下，需要簽名的承諾交易數量還比上一種構造少）；這是因為，多個用戶可以共用相同的承諾交易來退出；

（2）它也部分緩解了前述的狀態爭用問題，因為共享的 UTXO 每分裂一次，就多出一個允許訪問的 UTXO，也即允許多一個原來位於不同分支的用戶操作；假設 Alice 和 Carol 都要退出，那麼，在讓 “承諾交易 01” 得到確認之後，他們就可以互不影響地並行操作；

（3）它也讓鏈下更新機制更容易運行（如果有的話）。假設 Alice 離線，在我們前面所述的簡單阻塞控制構造中，鏈下更新機制也會停擺；而在上述改進型構造中，儘管其他人可以更新原本就不包含 Alice 的承諾交易，但需要更新的數量很大，也會給設計帶來難度、增加分析的複雜性；而在本構造中，由於承諾交易的數量大大減少，且不包含 Alice 的承諾交易易於定位和分析，自然就更容易設計出鏈下更新機制。

綜上所述，在這幾節中，我們分析了共享 UTXO 內部的狀態表達方式對其實用性和用戶體驗造成的影響。這三種表達方式可姑且稱之為 “串珠結構”、“星月結構” 和 “樹形結構”。這三種結構最初如何提出已不可考，但我想，肯定有許多開發者思考過這些結構。

我們也在這些分析中瞭解了共享的 UTXO 在其生命週期中可能遇到的諸多挑戰。

接下來，我們進一步分析 vTXO 的類型所帶來的影響。

Coin vs. 閃電通道

看看以下這種形式的共享 UTXO，在特性上，它會跟 “擁堵控制” 構造有什麼區別？

channel-factory-proto

沒錯，它跟擁堵控制使用了完全相同的狀態表達結構，但正因為這些 vTXO 並不是排他式控制的 coin，而是閃電通道，那麼，即使這種共享 UTXO 沒有實現鏈下更新機制（不能允許資金在 vTXO 之間轉移），也不影響這些用戶可以相互支付，因為他們兩兩之間都開設了閃電通道！他們可以相互支付，也可以藉助共享通道中的對手來發起閃電支付和接收閃電支付。唯一他們不能做的事情是調整他們位於這個共享 UTXO 中的通道的大小 —— 這需要發起鏈上交易，更像這個共享的 UTXO 才行。

這個例子說明了 vTXO 的類型對共享的 UTXO 的用戶體驗帶來的影響；也說明了，即使不改變狀態表達結構，也可能在其它方面改善用戶的體驗。當然，這也需要增加用戶在初始化階段需要簽名的承諾交易的數量。

實際上，上圖啟發自一種著名的共享 UTXO 設計 —— 通道工廠。與通道工廠不同的是，我在這裡假設了它不存在鏈下更新機制（而通道工廠有，至少被假設有）。如果有這樣的機制，那麼，這三位用戶就可以調整彼此之間的通道的大小而不需要發起鏈上交易 —— 有顯而易見的用途。

多方的鏈下更新機制

鏈下更新機制可以大大增加共享 UTXO 的實用性：當 vTXO 是排他性控制的資金時，鏈下更新機制允許這些用戶相互支付；當 vTXO 是閃電通道時，鏈下更新機制允許這些通道調節大小。

不過，即使是鏈下更新，也需要讓被更改的狀態會影響到的參與者都在場，才能動用（否則就不安全）。因此，合適的狀態表達結構會有便利與其運作。

最後，儘管鏈下更新機制在某些條件下可以發揮跟閃電通道型 vTXO 相同的效果，但這並不代表我們劃分 vTXO 的類型是多餘的，也不代表將鏈下更新機制作為一個獨立的元素是多餘的。從分析的便利和完整性出發，都要求我們將它們識別為兩個獨立的元素。

接下來，我們要介紹幾種多方鏈下更新機制。（如果你對技術細節不感興趣，可以直接跳到下一個章節。）

在閃電通道中，鏈下的狀態更新機制是通過在承諾交易的輸出中安裝特殊的裝置來實現的：每當要更新狀態、交換新的承諾交易時，雙方就將自己用在上一筆承諾交易中的一個秘密值交給對方。如果某一方將這樣過時的承諾交易廣播出去，對方將可以用對應的秘密值搶先奪走屬於該欺詐（或者粗心）一方的輸出中的價值。這就實現了一種懲罰機制，使雙方都不敢廣播過時的承諾交易。

這樣一種機制，是極難延伸成一種多方鏈下更新機制的。具體來說，當某一方提交過時狀態時，該方的確可被懲罰，但其他方也被回退到了一種舊狀態，而無法馬上按照最新狀態來分割資金。解決辦法是讓每一筆表示舊狀態的承諾交易都可以在一個窗口期內被表示更新狀態的承諾交易花費，以保證總是可以按照最新狀態分割資金並應用懲罰。問題是，這會讓單次更新需要簽名的承諾交易數量隨已發生的狀態更新次數而增長，且需要保存的承諾交易數量會呈階梯式增長。如下圖：

在第 2 次更新狀態時：共享 UTXO --> 承諾交易#0 --> 承諾交易 #01 --> 承諾交易 #012共享 UTXO                --> 承諾交易 #1 --> 承諾交易 #12共享 UTXO                  --> 承諾交易 #2注 1：承諾交易 #0 表達的是初始狀態。注 2：縱向同一位置的承諾交易表達的是相同的狀態。

這樣一來，雖然狀態更新的安全性得到了保證，但參與者的交互和存儲負擔都很大，而且，一旦某個用戶將舊的承諾交易廣播上鍊，為使用最新狀態結算通道，可能就需要在鏈上確認整個交易鏈條（例如，Alice 將承諾交易 #0 上鍊，那麼其他人要繼續廣播 #01 和 #012 上鍊），這就沒什麼可擴展性可言了。

這就是我們想要 “eltoo” 的原因。這一想法在 2018 年提出 ^[7]，它提出了一種新的 SIGHASH 標籤（即 ANYPREVOUT，現已被 BIP-118 ^[8]定義）；使用這種標籤，簽名可以僅指定交易的輸出，而不指定輸入，因此總可以用來花費相同的腳本；再加上遞增承諾交易 nLocktime 字段的數值，就可以實現這樣一種效果 ^[9]：交易鏈條中排在後面的交易可以直接花費自己的任意一個祖先交易，而不論兩者在被簽名的時候中間隔著多少筆交易，同時反之不能成立。也即，當 Alice 將 #0 上鍊的時候，其他人可以直接廣播 #012，跳過中間的 #01（實際上，這時候已經不需要 #012，而只需要 #2 了）。這就大大緩解了參與者的交互和存儲負擔、挽救了可擴展性。

但是，eltoo 需要我們以軟分叉激活 SIGHASH_ANYPREVOUT，所以這種機制，當前是不可用的。

2022 年，John Law 提出了另一種叫做 “可調整懲罰協議（Tunable-Panelty Protocol）” ^[10] 的鏈下更新機制。

Tunable-Panelty

在這種機制中，表示狀態的承諾交易（CT）（帶有相對時間鎖）不僅以共享 UTXO 為輸入，還有額外的一個小額的輸入（Dust），來自某個參與者在共享 UTXO 之外的另一筆資金。當某一個參與者，比如 Alice，嘗試發佈一筆承諾交易的時候，必須先讓這個小額輸入先得到確認，也即需要發佈 ST（“狀態交易”）。而 ST 還有另一個輸出，實際上是一份押金（Stake），因為在更新狀態時，參與者必須給出這個押金的私鑰。

最終的效果是，如果某個參與者嘗試發佈某個舊的承諾交易，必須先將一筆舊的 ST 上鍊，而這就會導致其押金被取走 —— 而此時，共享的 UTXO 還沒有被花費，因此不影響所有用戶使用最新狀態的能力。相等於，TPP 為分割共享 UTXO 設計了一個準備階段，使嘗試欺詐（或者只是粗心）的用戶無法直接操作共享 UTXO，因此避免了前面提到的需要重放交易鏈條的問題。

TPP 的一個重大優點是它無需變更比特幣的底層，現在就可以實現。

實際上，還有一種相當相當簡單的多方更新機制，是基於時間鎖的承諾交易。它脫胎於對兩方通道的研究 ^[11]。

timelock-ct

在這種機制中，承諾交易本身帶有交易層面的時間鎖，而每次更新狀態，參與者都簽名一筆時間鎖更短（因此更快可被髮布、得到確認）的承諾交易。時間鎖自身就防止了承諾交易衝突的問題，因此也無需進一步設計應對這種衝突可能性（某個用戶發佈表示舊狀態的承諾交易）的機制。

這種機制是如此簡單，易於實現，讓上面兩種機制的探討似乎沒有意義。但並非如此。這種機制有個致命的缺陷是，它具有明確的壽命 —— 更新達到一定的次數之後，就只能結算並重新建立一個新的共享 UTXO。儘管可以緩解（比如，緩解辦法之一是在共享 UTXO 與最終表達狀態的承諾交易之間插入多筆中間交易，以倍乘相對時間鎖），但無法從根本上解決。

題外話：與共享 UTXO 相關的限制條款提議

雖然共享 UTXO 常常被關聯起各種可以實現限制條款的軟分叉提議來討論，但到目前為止，我幾乎沒有提到它們。原因在於，雖然這些限制條款提議可被用於協助共享 UTXO 的運行，但它們並不決定共享 UTXO 的根本特徵 —— 而唯有理解了共享 UTXO 的根本特性，我們才能理解這些限制條款在這個場景中到底派什麼用場。

我們在這裡簡單地分析三種提議：OP_TLUV ^[12]、OP_CTV ^[13] 和 OP_EVICT ^[14]。

如前所述，在建構共享 UTXO 時，需要進行大量交互（簽名大量的承諾交易以保證安全性），會阻礙其實用性和用戶體驗。對此，OP_TLUV 的解決思路是，利用 Taproot 的默克爾腳本樹結構，將用戶的狀態承諾到腳本樹的葉子中。在用戶需要單方面退出時，可揭曉這個葉子，並以其中記錄的資金數量退出；TLUV 會驗證資金數量、確保剩餘資金被轉移到了一個新的 taproot 輸出中，且該輸出已不再允許該退出用戶參與 —— 其公鑰已從 taproot 內部公鑰中刪除，其腳本也已經從默克爾樹上摘除。

由於默克爾腳本樹本身可以承諾用戶的資金狀態，用戶也就無需簽名承諾交易，在初始化和交互過程中，只需完全驗證 taproot 輸出的內部公鑰和腳本樹構成即可。這就極大地降低了交互需求。

熟悉本領域其他協議設計的讀者可能會說：這不就是狀態模型下常見的 “狀態樹” 設計嗎？沒錯，正是如此。但從我們前面的結構分類法來看，這種設計應該被歸類為星月結構，而不是樹形結構 —— 它允許單用戶直接退出，並讓其他用戶不受影響，而不是每次都對半分拆共享 UTXO。相應地，我們也可以想象一種使用 OP_TLUV 的樹形結構 —— 被腳本樹承諾的是一半參與者的資金和聚合公鑰。

無獨有偶，OP_CTV 也可以用來支持這種設計。因為，OP_CTV 使得我們可以讓一個腳本僅可以被具備某些特徵的交易花費，這些特徵包括輸出的數額和腳本。因此，我們也可以將用戶的取款交易承諾到默克爾腳本樹的葉子中，允許用戶單方面動用 —— 反正，動用的結果是其資金退出，而剩餘的資金進入一個 UTXO，該 UTXO 也已被我們用合適的內部公鑰和默克爾腳本樹鎖定，允許剩餘的用戶單方面退出。

與 OP_TLUV 相比，在 OP_CTV 的這種用法中，用戶需要驗證的東西更多（需要驗證每一個取款步驟都會將剩餘資金交給正確的腳本樹），但同樣不需要再簽名承諾交易（驗證的數量跟僅使用承諾交易時相同）。

而 OP_EVICT 的想法則是另闢蹊徑。OP_EVICT 的作者 ZmnSCPxj 注意到，在使用 OP_TLUV 的星月結構中，退出交易需要揭曉自身葉子的默克爾樹路徑；而使用樹形結構也需要揭曉類似於默克爾樹路徑的多筆交易。有無辦法避免這種開銷？

OP_EVICT 想法是，讓用戶直接簽名一個輸出（公鑰與數額），並讓這樣的簽名可被 OP_EVICT 操作碼理解、用於驗證當前的某個交易輸出是否與被簽名輸出一致。在驗證完這個簽名和對應的輸出之後，OP_EVICT 會從 taproot 內部公鑰中減去這個簽名公鑰，並要求剩餘公鑰對交易的簽名。如此一來，等於是 taproot 的內部公鑰自身就承諾了參與者的構成，而參與者的資金也無需得到默克爾樹的承諾，只需要公鑰自身的簽名（以及其他用戶的輸出簽名）保護。

OP_EVICT 還有一個重大的優點：它允許多個用戶同時退出。因此，它可以實現一種沒有競爭進入問題的星月結構。（更準確來說，OP_EVICT 的思維模式有所不同，它假設了用戶很少需要單方面退出，相反，難以處理的問題是某個（些）用戶離線造成其他用戶無法正常使用共享 UTXO 的功能。因此，需要的是一種能夠高效將離線用戶排除出去的工具，排除掉離線用戶，剩餘用戶就可以通過合作來更新狀態了。所以，用戶自己退出，並不是這個操作碼的 “正常” 用法。）

與前面兩者相比，由於沒有顯式承諾狀態的方法，它所要求的用戶間交互也將更多，但也顯著少於只使用承諾交易的情形。

綜上，限制條款操作碼在共享 UTXO 場景中的主要用處是減少交互需求，它可以降低某些狀態表達結構的運行開銷，但並不決定我們可以使用哪種結構。對結構的研究也不會因為限制條款的出現而失去意義。

共享 UTXO 設計案例

多方通道

multi-user-channel-1

如上圖所示，這是一種具備鏈下更新機制的擁堵控制 UTXO（vTXO 為 coin、具備鏈下更新機制的串珠結構）。

有時候，下圖這種結構也會被當成一種多方通道。

multi-user-channel-1

與分散的閃電通道（以及下文要介紹的分層通道）相比，多方通道的好處在於更少面臨 “收款額度（入賬流動性）” 的困擾。缺點在於，更難抵抗離線用戶帶來的影響。

分層通道

“分層通道（hierarchical channel）” 是 John Law 在 2023 年提出的想法 ^[15]。它使用樹形結構，vTXO 是閃電通道。同時，作者提議使用 TPP 作為其鏈下更新機制。

hierarchical-channel

通道工廠

通道工廠使用串珠結構，vTXO 為閃電通道（共享 UTXO 的每兩個用戶之間都有閃電通道），使用時間鎖遞減承諾交易作為鏈下更新機制。

Statechain

“Statechain”^[16] 的基本想法是，通過轉移控制一個 UTXO 的私鑰，就可以將這個 UTXO 完全轉移，而不需要發生鏈上交易。為了協助這樣的轉移，兩方（用戶以及服務商）需要共同構造一個公鑰（兩方都只有該公鑰背後的私鑰的一半），並將資金存入這個公鑰（為了保證免信任取款，還需要預先簽名一筆帶有時間鎖的承諾交易）；在支付時，支付者和/或服務商先給接收者展示該 UTXO 鏈下所有權的流轉歷史，證明資金的真實性；然後，支付者交出自己的簽名，表示支付的意願；接收者跟服務商合作生成新的私鑰碎片，並簽名新的一筆帶有更短時間鎖的承諾交易，支付完成。

如果用共享 UTXO 的術語來表述，它是一種使用時間鎖遞減承諾交易來更新狀態的串珠結構；只不過，這個共享 UTXO 只有一個 vTXO，而且 vTXO 的持有者不能分割自己的 vTXO，一旦支付，就必須把整個 vTXO 都轉移過去 —— 任何時刻，vTXO 的合法持有者都只有一個；此外，為了能夠引入新的用戶而不使用鏈上交易，用戶必須信任服務商不會與該 vTXO 的任何一個前任用戶勾結（他們勾結，就可以生成共享 UTXO 私鑰的有效簽名，從而把錢轉走） —— 這是它最大的缺點，也是為什麼在接收支付時，用戶需要執行額外的驗證。

如果用戶想啟用更細粒度的支付，而不是隻能一次性轉移全部資金，那麼可以將 vTXO 轉移給一條閃電通道，在閃電通道內發送支付，這是可以做到的 ^[17]。

ARK 和 ARK v2

“ARK”^[18] 是一種沒有鏈下更新機制的扁平結構。那麼，它跟 “擁堵控制” 的區別在哪裡？在於其 vTXO 並不是純粹的 coin（但也不是閃電通道）。從腳本內容上來說，更像一種 “單向通道”。這種單向通道有兩種花費路徑，一是兩個參與者的多簽名；二是帶有時間鎖的某一用戶單簽名。後者可以用來表明這條單向通道的最終資金歸屬，也可以用來催促某一參與者行動。而前者，則可以在時間鎖還未到期時，啟用多簽名裝置可以支持的功能。在下文描述單向通道時，我會將可以使用時間鎖分支的參與者寫在前面。

用戶在 ARK 中的 vTXO 為 ARK 服務商與用戶的單向通道。而用戶的 vTXO 又通過一筆特殊的承諾交易（Redeem TX），為用戶與 ARK 服務商的單向通道注入資金。

ARK

這套設計被用來支持一種 “非交互的原子化 coinjoin 支付”：當 Alice 嘗試給 David 支付時，她可以用自己跟服務商的單向通道（Alice-Server Coin）表達一種可信承諾：當且僅當你給 David 支付，我這筆錢就屬於你；但如果你沒有在一定時間內做到，我就取走我這筆錢。這確實是可以做到的，因為，作為共享 UTXO，ARK 無法在 Alice 不同意的時候被花費。因此，如果服務商不提供服務，Alice 總可以發佈 the CT 和 Redeem TX#A，然後將 Alice-Server coin 中的錢取走。

相應地，服務商也不擔心 Alice 會賴賬，因為一旦 TA 給 David 支付了，就總是可以讓 Alice-Server coin 確認，然後用 Alice 給出的承諾交易將錢取走。

最終，理想情形是，雙方會合作：服務商給 David 合作，Alice 同意跟服務商一起在鏈上變更 ARK 的狀態。而在這個過程中，Alice 並沒有直接給 David 支付；如果 David 在鏈上接收支付，那麼對於外部觀察者來說，也不知道是這個 ARK 中的誰給他支付的（只有 Alice 的同伴知道）；而如果 David 也使用另一個 ARK 來接收支付，那麼，甚至連 Alice 在這個 ARK 中的同伴，也不知道錢交給了誰（只要這些同伴不是在兩個 ARK 中都有參與）。

此外，這裡的單向通道雖然理論上支持細粒度的支付，但 ARK 並不支持這個特性。跟 statechain 一樣，資金是整個轉移的。

ARK v2 基本上沿用了相同的構造 ^[19]，只是啟用了一些讓服務商能夠更高效地回收資金的設計（也同樣依託於 taproot 的默克爾腳本樹）。但從共享 UTXO 的構造上來說，兩個版本基本上是一樣的。此外，ARK 可以不依賴於限制條款，但 ARK v2 明確依賴於限制條款。

對共享 UTXO 的讚賞和批評

CoinPool 一文很好地勾勒了研究共享 UTXO 的兩個動機，也正是共享 UTXO 有望為人們帶來的好處：

隱私性。當許多人共享一個 UTXO，就可以在鏈上隱匿支付的發起人；而如果接收者也使用共享的 UTXO，還可以隱匿接收者。ARK 就是擁抱這個方向的代表。
可擴展性。可以縮減鏈上 UTXO（鏈上狀態）的數量、減少對區塊空間的需求（比如，可以在共享 UTXO 內使用鏈下更新機制來相互支付）。這方面的代表應屬通道工廠。

而對這個概念的批評主要從實用性角度出發，認為在用戶數量增多時，全體用戶都在線是非常罕見的，這意味著其狀態可能經常卡住而無法更新，因此它是一種脆弱、可用性差的機制。還有一種批評則更加尖銳，來自 Peter Todd：我們假設了要使用這種機制來拓展比特幣的處理能力，即用它來容納經濟條件差、無法負擔得起在鏈上擁有屬於自己的 UTXO 並加以使用的用戶；然而，我們又假設了真的發生什麼事的時候，用戶會主動退出或者被動彈出到鏈上 —— 他們怎麼又突然負擔得起了呢？

這種批評顯然需要更深入的分析，才能找出合理的回應。至少，在目前，出於一些好處，人們不會停止對共享 UTXO 的研究。並且，這些研究已經產生了價值，無論是理論上的（比如 TPP），還是實際上的（比如 statechain 的實現）。