作者：798.eth

Lightning Labs 聯合創始人 Olaoluwa Osuntokun 最近發布了一套新的比特幣擴容設計，名字叫 LayerTree。

它提出了一個相當激進的設想：讓成千上萬甚至數百萬用戶共享同一個比特幣 UTXO，同時讓每位用戶保留獨立的資金所有權和單方面退出能力。

這聽起來有些矛盾。

一百萬個人分別持有比特幣，通常意味著鏈上需要一百萬個 UTXO。如果把錢集中到交易所，確實可以只保留少量 UTXO，內部轉帳也能瞬間完成，但用戶只能相信交易所的資料庫。

LayerTree 嘗試在兩者之間找到一個新位置。

鏈上只保存一個 UTXO。每個人擁有多少比特幣，記錄在一棵鏈下的 Merkle Sum Tree 中。運營方負責維持日常服務，但不能隨意修改用戶餘額，也不能阻止已有用戶把自己的錢取回鏈上。

一棵樹如何代表所有人的餘額

在 LayerTree 中，每位用戶擁有一個葉節點。

葉節點裡記錄了用戶餘額、所有者公鑰、退出公鑰、租期以及狀態序號。相鄰葉節點不斷向上合併，每個父節點記錄兩個子節點的餘額總和與雜湊，最後形成一個唯一的樹根。

假設樹裡有四個人：

Alice 有 5 BTC，Bob 有 3 BTC，Carol 和 David 各有 1 BTC。

鏈上的共享 UTXO 一共持有 10 BTC。樹根則承諾了四個人分別擁有多少餘額，以及所有餘額加起來正好是 10 BTC。

任何人修改一個葉節點，樹根都會改變。有人試圖憑空增加餘額，根節點的金額校驗就會失敗。

比特幣鏈上不用保存整棵樹，只需要保存這個根，以及與樹中總餘額對應的 UTXO。

這相當於把大量用戶的產權記錄壓縮成了一個密碼學承諾。

用戶如何單獨退出

Alice 想退出時，不需要獲得運營方批准，也不需要其他用戶在線。

她只需要提交自己的葉節點、從葉節點通往樹根的 Merkle 證明，以及自己的簽名。

比特幣腳本會驗證 Alice 確實位於這棵樹中，確認她擁有對應餘額，然後在一筆交易中完成兩件事：

第一，把 Alice 的餘額支付到她指定的退出地址。

第二，刪除 Alice 的葉節點，並把剩餘資金放進承諾新樹根的 UTXO。

無論樹裡有一百人還是一百萬人，Alice 都只需要廣播一筆退出交易。

LayerTree 所說的 O(1) 退出，指的是退出所需的交易數量始終為一筆。Merkle 證明的體積依然會隨著成員數量增加，大約按照 O(log N) 增長。

這種設計把正常狀態下的大量用戶壓縮進一個 UTXO，同時保留了異常狀態下的鏈上逃生通道。

LayerTree 裡的兩種轉帳方式

如果用戶每次轉帳都修改樹根，所有交易仍然要依次上鏈，擴容效果會非常有限。

因此，LayerTree 把日常支付放在鏈下完成，主要提供兩種方式：channel leaf 和 voucher。

Channel leaf：把 Lightning 通道放進葉節點

一個葉節點可以代表用戶與運營方之間的 Lightning 通道。

通道的資金輸出暫時沒有作為單獨 UTXO 出現在鏈上，它被包含在整棵 LayerTree 的共享輸出中。用戶之間付款時，透過運營方轉發普通的 Lightning HTLC。

支付過程中，LayerTree 的樹根不變，也不會產生鏈上交易。

因此，channel leaf 的支付速度可以接近普通 Lightning，通常在幾秒內完成。運營方在這裡承擔路由節點的角色，LayerTree 則負責壓縮通道所需的鏈上 UTXO。

它很像一座大型 Lightning 樞紐，只在鏈上佔用一個輸出。

Voucher：可以拿到鏈上兌現的數位支票

LayerTree 更有創造力的部分是 voucher。

Voucher 可以理解為一張由用戶簽發、由比特幣腳本提供最終執行能力的數位支票。

假設 Alice 的葉節點中有 100,000 sats，她要向 Bob 支付 10,000 sats。

Alice 不需要立即修改整棵樹。她只需要簽署一條訊息，寫明這張 voucher 屬於哪棵 LayerTree、資金來自哪個葉節點、Bob 將獲得什麼樣的新葉節點、支付金額是多少，以及 Alice 葉節點當前的狀態序號。

Alice 把簽名後的 voucher 發給 Bob，鏈下支付便完成了。

這個過程只涉及簽名和網路傳輸，速度可以接近交易所內部轉帳。

關鍵區別在於，Bob 拿到的不只是運營方資料庫裡的一條餘額記錄。他拿到了一條可以交給比特幣腳本執行的支付指令。

如果 Alice 或運營方停止合作，Bob 可以自行把 voucher 提交到鏈上。LayerTree 合約會從 Alice 的葉節點扣除相應金額，同時為 Bob 建立一個新的葉節點。

整個過程叫做 CLAIM。

Alice 無需再次簽字，運營方也無法阻止 Bob 兌現。

一張 voucher 為什麼只能使用一次

每個 LayerTree 葉節點都有一個狀態序號，稱為 seq。

假設 Alice 當前的 seq 是 7，她簽出的 voucher 會明確綁定 seq 7。

當一張 voucher 被兌現後，Alice 的餘額會下降，seq 也會從 7 增加到 8。所有綁定 seq 7 的舊 voucher 隨之失效。

這可以防止同一張支票被重複兌現。

如果 Alice 經常向 Bob 付款，她也不需要每次都建立一張相互獨立的 voucher。

第一次支付 10,000 sats，Alice 可以簽一張累計金額為 10,000 sats 的 voucher。第二次再支付 20,000 sats，她可以重新簽署一張累計金額為 30,000 sats 的 voucher。

Bob 只需要保存最新的一張。

成百上千筆小額支付可以被壓縮成一張代表最終累計餘額的憑證。只要雙方繼續合作，就完全沒有必要把每筆付款寫入比特幣區塊。

Voucher 無法消除信用風險

Voucher 擁有真實簽名，也有鏈上兌現路徑，但它在被兌現之前依然帶有發行人的信用風險。

假設 Alice 的葉節點只有 100,000 sats。

她可以向 Bob 簽發一張 80,000 sats 的 voucher，同時向 Carol 簽發另一張 80,000 sats 的 voucher。

兩張 voucher 上的簽名都是真的，但 Alice 的餘額無法同時覆蓋它們。

比特幣腳本可以阻止超額資金被兌現，卻無法阻止 Alice 在鏈下簽出超過餘額的多張憑證。最終誰能拿到錢，可能取決於誰先完成兌現。

Alice 也可能透過其他合法操作更新自己的葉節點，使 seq 增加。舊狀態上的 voucher 隨後會失效。

因此，一張尚未結算的 voucher 很像傳統支票：

簽名可以證明它由誰簽發，持有人可以嘗試兌現，帳戶餘額卻可能不足，多張支票也可能爭奪同一筆餘額。

收款人需要關注付款人的可用餘額、當前 seq、未結算憑證、葉節點租期，以及付款人的信用狀況。面對陌生人或大額付款，收款人可能選擇立即兌現。長期合作方之間的小額高頻支付，則可以繼續在鏈下累計。

LayerTree 官網也明確表示，收款人在 voucher 兌現或透過其他方式結算以前，應當把它視為 credit。

這種信用風險是 voucher 獲得高效率所付出的代價。

為什麼還要設計 voucher

既然存在信用風險，為什麼不全部使用 Lightning 通道？

因為 voucher 的結構更簡單，也更靈活。

它不需要付款雙方提前建立獨立通道，可以由任何葉節點所有者直接簽發，可以多次累計更新，還可以作為 LayerTree 與 Lightning 之間的結算憑證。

LayerTree 設計了一種 credit leaf，用來接收來自 Lightning 的付款。

運營方收到一筆 Lightning 付款後，可以使用自己提供資金的葉節點，向收款人簽發一張新的累計 voucher。收款人可以繼續持有，也可以在必要時自行上鏈兌現。

基礎流程存在一個短暫的信任窗口：運營方已經收到 Lightning 付款，但尚未向收款人簽發 voucher。論文還設計了 pending pair，透過雜湊鎖、預簽 voucher 和結算窗口，讓收款人先獲得可執行憑證，再釋放 Lightning 支付的 preimage。

在這種結構中，voucher 成為了 Lightning 支付與共享 UTXO 餘額之間的橋樑。

它尤其適合高頻小額支付、工資流、內容付費、長期服務結算，以及運營方定期批量清算的場景。日常狀態只需要交換簽名，鏈上兌現被保留為爭議處理和最終結算工具。

LayerTree 依賴哪些比特幣升級

LayerTree 目前還不能在比特幣主網上運行。

它需要 covenant，也就是讓一個 UTXO 對未來的花費方式施加約束。例如，腳本必須確保用戶退出後，剩餘資金重新進入承諾新樹根的輸出，不能被任意地址拿走。

項目設計了四種操作碼組合。

FULL 版本依賴 BIP 441、BIP 440、OP_TX、BIP 348，以及一組橢圓曲線操作碼。

BIP 441 恢復部分早期被禁用的腳本能力，並支持更靈活的資料與數值處理。BIP 440 為這些可變成本操作提供計算預算。

MID 版本依賴 BIP 347 的 OP_CAT、OP_TX、BIP 348 的 OP_CHECKSIGFROMSTACK，以及 BIP 449 的 OP_TWEAKADD。

OP_CAT 用來拼接腳本中的資料。OP_TX 讓腳本讀取和約束當前交易。OP_TWEAKADD 用來計算承諾新狀態的 Taproot 公鑰。

其中，BIP 348 對 voucher 尤其重要。它允許比特幣腳本驗證一段任意資料上的簽名。沒有這項能力，腳本很難驗證 Alice 在鏈下簽發的那張數位支票。

MIN 版本只依賴 OP_CAT 和 OP_TWEAKADD，但只能實現退出和 SPLIT，無法支持 voucher 與 channel leaf。它更像一項證明 LayerTree 最低能力邊界的實驗。

CCV 版本依賴 BIP 443 的 OP_CHECKCONTRACTVERIFY、OP_TX，以及為 voucher 準備的 BIP 348。

BIP 443 可以讓 UTXO 攜帶動態狀態承諾，並約束新輸出必須繼承更新後的狀態。它與 LayerTree 這種鏈上狀態機非常契合，也是四種方案中退出體積最小的一檔。

不過，這些 BIP 都還沒有在比特幣主網上激活。

「百萬人共享一個 UTXO」還有一個額外前提

LayerTree 宣傳中性能最漂亮的版本，還依賴一個叫做 OP_MERKLESUMUPDATE 的專用操作碼。

它可以驗證 Merkle Sum 證明，並直接計算替換一個葉節點後的新樹根。

有了它，一棵包含 65,536 名成員的 LayerTree，單人退出大約需要 540 vB。成員數量每增加一倍，退出交易只增加約 10 vB。

但 OP_MERKLESUMUPDATE 目前只是項目倉庫中的設計和模擬實現，尚未成為正式 BIP，也沒有進入比特幣升級流程。

如果只使用已經存在的操作碼提案，65,536 人規模下的退出成本約為 908 至 1,473 vB。

所以「一棵樹承載數百萬人」在密碼學結構上成立，它的高效實現仍然依賴比當前 BIP 更進一步的比特幣腳本能力。

它能否解決大規模擠兌

LayerTree 可以大幅壓縮正常狀態下的鏈上佔用，卻無法增加比特幣區塊本身的容量。

同一棵樹的所有狀態更新都要花費並重新建立同一個共享 UTXO，因此單獨退出需要排隊執行。

根據項目自己的測算，如果 65,536 名用戶從同一棵樹中分別退出，大約需要 2,622 個區塊，接近 18 天。

實際部署需要把用戶分散到很多棵較小的樹中，同時使用批量加入、批量結算和批量退出。

這也說明 LayerTree 的設計目標：讓絕大多數正常活動留在鏈下，把有限的鏈上空間留給最終結算和異常處理。

LayerTree 的意義

LayerTree 仍然有一個明確的運營方。

運營方負責接納用戶、維護服務、路由支付和組織批量更新。它可以拒絕新用戶，也可以停止提供即時服務。單棵 LayerTree 因此並非完全去中心化。

它更適合被稱為非託管共享 UTXO 系統。

運營方掌握服務入口，用戶掌握資金退出權。運營方可能關門，也可能拒絕服務，但按照協議設計，它不能隨意拿走用戶葉節點中的餘額。

LayerTree 最值得關注的部分，是它在普通 UTXO、Lightning 通道和託管資料庫之外，展示了另一種資金形態：

一張可以瞬間流轉、持續累計、最終交給比特幣腳本強制兌現的數位支票。

它沒有消除信用風險，也沒有突破區塊空間的上限。

它把信用限制在鏈下支付階段，同時給收款人保留了一條無需許可的鏈上執行路徑。

這是一種相當有創造力的比特幣擴容思路。