如何利用虛擬通道來創建狀態通道網路

在本文中，我們介紹了一種叫作虛擬通道（virtual channel）的新型狀態通道結構。虛擬通道不僅使得付費文件流（點擊此處，查看 demo！）等新型應用場景成為可能，還可以簡化去中心化的 Graph 查詢支付、Filecoin 內容檢索、帶有經濟激勵機制的狀態提供者網路等有趣的應用場景。

動機

讓我們來設計一個免信任的付費文件流支付系統。這個系統中有 seeder（上傳文件者）和 leecher（下載文件者）。leecher 從多個 seeder 那裡付費下載一份文件的不同部分。使用以太坊主網交易來支付費用是不可能的，因為以太坊主網的吞吐量低於每秒 50 筆交易，而且（截至 5月 28 日發稿時）最低轉賬成本也在 2 美元以上。Optimistic Rollup 和 ZK Rollup 可以提高吞吐量並降低交易成本。StarkEx 的 ZK Rollup 可以將吞吐量提高至每秒 3000 筆交易，同時將每筆交易的成本降至 0.03 美元。假設 leecher 願意支付 1 美元下載1GB 大小的文件，且整個文件以 256 KB 為單位切分成了多個部分，leecher 需要支付大約 5000 筆費用。當網速為 20MB/s 時，用戶每秒支付 80 次費用，且每筆費用為 0.0002 美元。Rollup 的吞吐量達不到許多 leacher 的要求，而且交易成本還是太高了。

為了達到交易吞吐量和成本要求，基礎狀態通道是個不錯的選擇。狀態通道創建完成後，leecher 就可以免費進行多筆小額付款，且吞吐量只受 leecher 和 seeder 之間通信信道的帶寬以及二者所使用硬體的影響。基礎狀態通道帶來的挑戰是，leecher 需要提交交易到主網上，與每位擁有他所需文件部分的 seeder 都建立狀態通道。由於 leecher 與多位 seeder 都需要短暫交互，創建多條狀態通道的成本是極其昂貴的。

虛擬通道可以完美解決我們的設計問題。虛擬通道尤其適用於軸輻式拓撲結構。多位參與者先與一個免信任的中間方建立連接，然後任意兩位（或多位）參與者再通過質押的方式創建私密通道。中間方並不知道私密通道內運行的是什麼應用。另外，任何參與者都可以發起鏈上挑戰找回自己的資金，即使通道內的其他參與者和中間方處於離線狀態或作惡。

總的來說，只要 Alice和Bob之間有經過中間方的路徑，無論網路拓撲結構是什麼樣的，虛擬通道都可以讓 Alice 開設與 Bob之間的私密通道。

背景知識

不同的區塊鏈生態系統都將狀態通道視為一種可以讓少數參與者：

• 建立鏈上聯繫（通道）並存入資金；

• 私下交換信息，有條件地在參與者之間轉移資金；

• 關閉鏈上通道，完成各方之間資金結算的方法。

我們之前已經在 statechannels.org 網站上發文介紹了如何構建狀態通道（中文譯本），以及如何通過一個叫作賬本通道（ledger channel）的架構讓一條狀態通道為另一條狀態通道提供資金。這些架構要求通道參與者必須在鏈上建立直接聯繫。換言之，如果 Alice和 Bob 之前從未交互過，現在卻想開通狀態通道，他們必須簽署（鏈下）協議，並將資金存入合約內。

但虛擬狀態通道可以實現以下應用場景：

• Alice與免信任的中間方創建狀態通道。假設這個中間方叫作 Irene。

• Bob 同上。

• 在 Irene 以及創建好的通道的幫助下，Alice 和 Bob 可以創建一條新的私密通道並存入資金。創建這個私密通道不需要通過鏈上交互。我們將 Alice 和 Bob之間的通道叫作虛擬通道。

就付費文件流這個應用場景而言，Alice 先要通過主網交易與中間方 Irene 創建一條通道。接著，她可以通過虛擬方式與任意數量的對等節點相連，只要後者與 Irene 之間也存在鏈上通道。一旦連接成功，Alice 就可以持續支付數據下載費。

我們的協議 Nitro 可以實現以下應用場景：

• 幫助 Alice 和 Bob 創建虛擬通道的中間方 Irene 實際上不在這個虛擬通道內。Irene 只是幫忙創建通道，並在通道關閉時結算資金而已。因此，Alice 和 Bob 之間可以實現完全私密的交流，並將 Irene 排除在這個應用的關鍵路徑之外。更重要的是，Alice 和 Bob 可以在私密通道內運行多個不同的應用，無需 Irene 針對這些應用實現任何新的邏輯。因此，虛擬通道是通用可編程的多跳狀態通道（就像以太坊賦予區塊鏈可編程性那樣），因為每條狀態通道都可以根據自己的一套 「規則」 來創建。Alice 可以向 Bob 付費購買某個文件內容。Bob 也可以向 Alice 付費進行 Graph 查詢。

• 所有 Nitro 通道都是可組合的。因此，獲得資金的通道可以通過遞歸的方式為其它通道提供資金，無論前者是通過何種方式獲得資金的。一旦某條通道（直接通過鏈上合約、賬本通道或虛擬籌資的方式）獲得資金，它就可以運行任何應用或為其它通道提供資金。

Nitro 的替代方案

其它協議（如 Raiden）可以讓兩位參與者無需在鏈上存入額外資金，即可通過中間方創建通道。一個成熟的模式是，使用經過哈希的時間鎖通過中間方將 Alice 的付款路由給 Bob。這個模式有一個很明顯的缺點：所有付款必須通過中間方路由。

一些比較新穎的架構（如 Scalar）可以讓 Alice 和 Bob 通過中間方創建通道後實現點對點付款。然而，這些架構依然需要中間方理解 Alice 和 Bob 所運行的應用，因為通道餘額最終要通過中間方取回。有了 Nitro 虛擬通道，中間方就可以被隔離在 Alice 和 Bob 之間的通道外。

通道內部的資金轉移

本文將深入介紹 Nitro 通道是如何獲得資金的，以及免信任的安全虛擬通道是如何實現的！

Alice 和 Bob之間的 Nitro 通道的資金來自：

1. Alice 和 Bob 聯合簽署鏈下協議，使用特定的初始結果創建通道。

2. Alice 和 Bob 按照初始結果指定的順序存入資金，增加鏈上裁決者（adjudicator）合約中記錄的通道 holdings。

這裡的 「結果」 是一個指示裁決者在通道最終敲定時如何分配資金的結構（查看我們的最新文章！）在 Nitro 中，「結果」 列出了 {目標、數量} 對的優先順序：

{A: 7, B: 3} 命令通道 C 的裁決者先將 7 枚代幣支付給 A（Alice），再將 3 枚代幣支付給 B（Bob），並將 C 的結果歸零。

這麼說有一點不準確：我們其實是按照字典中鍵的順序在為目標分配優先順序。因此，{B: 3, A: 7} 會先付款給 Bob，然後才輪到 Alice。你可以將它看作是 Python 3.7+ 式的有序字典。

上圖顯示了 Alice 和 Bob 是如何根據 {A: 7, B: 3} 這一結果從通道 C 中取走代幣的。根據鏈上裁決者的記錄，通道中共有 10 枚代幣。Alice 或 Bob 將通道結果記錄到鏈上。這個結果記錄下來後，Alice 和 Bob 就可以取走代幣。於是，Alice 的外部賬戶中增加了 7 枚代幣，Bob 的外部賬戶增加了 3 枚代幣。

雖然上述結果暗示目標是用戶賬戶（EOA），但是在 Nitro 中，通道本身也可以是目標。這樣一來，通道 L 也可以充當 「私密賬本」，因為 Nitro 可以讓一次性一次性將資金存入賬本通道，然後為多條子通道提供資金。Nitro 避免了回到 Layer1 的需求，以及由此產生的延遲和成本！例如：

假設 C2 是一條 Nitro 通道，{A: 4, B: 1, C2: 5} 命令裁決者向 Alice 支付 4 枚代幣，再向 Bob 支付 1 枚代幣，然後將 C2 的代幣持有量增加 5 。

以上是一個簡短的介紹。如果你想要深入了解Nitro，請查看我們的相關博客文章！

如何利用保證來實現免信任架構

接下來，我們將介紹當兩位參與者沒有鏈上關係時，如何通過一個安全的架構來創建三方通道。這個架構不僅能讓賬本通道為其它通道提供資金，還能實現虛擬通道。兩位參與者分別是 Alice（A）和 Bob（B），中間方是 Irene（I）。

初始設置：三條獨立通道。

首先要有一對賬本通道 L（位於 Alice 和 Irene 之間）和 L'（位於 Bob和 Irene之間）。通常情況下，L 和 L' 是早就創建好的。這是因為 Irene 存在的目的就是在人們之間建立連接 —— Alice 可以使用 L 來同時連接 Bob、Cheryl、David 和 Eve。如果 L 和 L' 不存在，L 可以使用結果 {A: 4, I: 6} 創建，L' 可以使用結果 {B: 6, I: 4} 創建。L 和 L' 各自在鏈上存儲10枚代幣。

另外還有一條獨立通道 J 是使用結果 {A: 4, B: 6, I: 10} 創建的。請注意，在向通道存入資金之前，參與者必須先就這一結果達成共識。一旦 J 有了資金之後，這條通道就可以用來為 Alice 和 Bob 之間創建的任意一條私密應用通道提供資金。

步驟 1 和 2：賬本通道轉變為向 J 提供資金。

Alice 和 Irene 將 L 的結果轉變為 {J: 10}。Bob 和 Irene 將 L' 的結果轉換成 {J: 10}。

這個設計夠好了嗎？

Alice 必須考慮以下幾點：

1. Bob 和 Irene 是不是可信的？

2. Alice 無法控制 L' 上發生的事。

我們來思考一下步驟 2 之後如何取走 J 的資金。

1. L 和 L' 的結果被記錄到鏈上。

2. L 和 L' 的資金都被轉移到 J。代幣經由轉賬操作從一條通道轉移到另一條通道。J 現在有了 20 枚代幣，可謂資金充足。

3. Alice 可以從 J 中取走 4 枚代幣，Bob 可以從 J 中取走 6 枚代幣。Irene 可以從 J 中取走 10 枚代幣。

漂亮！現在每個人都取走了自己應得的代幣。但是，我們來設想一個場景：Alice 和 Bob 串謀起來欺騙  Irene。假設步驟 1 發生後，Bob 拒絕參與步驟 2。然後就會發生以下情況：

1. L 的結果被記錄在鏈上。現在，J 有了10 個代幣，記錄在鏈上的結果是 {A: 4, B: 6, I: 10}。

2. Alice 和 Bob 分別取走 4 枚和 6 枚代幣。

請注意，Bob 從 J 那裡獲得了 6 枚代幣，儘管他自己根本沒有向 J 轉過代幣。結果變成了：Alice 獲得了 4 枚代幣，Bob 獲得了 6 枚代幣，Irene 什麼也沒有。Irene 被坑慘了！

你可能會想，如果調換一下結果 {A: 4, B: 6, I: 10} 中目標的順序，就可以創建出一個安全的架構。然而，無論怎麼調換順序，總會有人蒙受損失！

保證是如何發揮作用的

在上述場景中，我們使用了轉賬操作在通道之間轉移資金。通過轉賬操作，資金可以從一個通道轉移到目標通道。在本小節中，我們將引入索取（claim）操作來將資金從目標通道轉移至特定的目標地址¹。為了實現索取操作，我們需要保證。

我們先來介紹一個新的數據結構。保證是指定以下的結果：

1. 目標，即，一條通道；

2. 數量；

3. 優先順序，即，目標的優先順序列表。優先順序的作用是指示裁決者如何改變目標通道的結果項的優先順序。

我們來看一下 J 是如何獲得資金的：

初始設置：創建三個獨立的通道。

• 通道 J 是使用結果 {A: 4, B: 6, I: 10} 創建的。

• L 是使用結果 {A: 4, I: 6} 創建的。

• L' 是使用結果 {B: 6, I:4} 創建的。

步驟 1 和 2：賬本通道轉變為向 J 提供資金（沒有先後順序之分）：

1. L 的結果更新為 {J: {amount: 10, priorities: [A, I]}。請注意，我們使用了一種新的符號來表明 L 的結果只有一項，即，包含目標 J、數量和地址優先順序列表的保證。

2. L' 的結果是 {J: {amount: 10, priorities: [B, I]}。

L 和 L' 的結果各自包含一個保證。由於轉賬操作不支持這些保證，我們代之以索取操作。索取操作接受保證以及保證的目標通道作為輸入。

我們來看一下索取操作是如何運作的。假設

• J 的結果 {A: 4, B: 6, I: 10} 被記錄到了鏈上。

• L 的結果 {J: {amount: 10, priorities: [A, I]}} 被記錄到了鏈上。

如果有人請求執行 L 的結果中的保證，則會觸發三個效果：

1. 將 4 枚代幣發送給 A，6枚代幣發送給 I。

2. 因為（1），A 和 I 的餘額在 J 的結果中被調整為 {B: 6, I: 4}。

3. L 的結果被調整為 {}—— 保證被刪除。

在這個操作中，優先順序的目的是告訴裁決者跳過 帶有 B 的結果項，這樣 Irene 就可以拿回她在創建 L 時出的那部分資金。因此，裁決者會先看到保證中優先順序最高的目標 A，並將 4 枚代幣轉給 A，J 的結果會相應更新。然後，裁決者才會看到目標 I。在 J 的結果中，Irene 應該獲得 10 枚代幣，但這時（L 的結果中）只剩下 6 枚代幣。因此，這 6 枚代幣被發送給了 Irene，J 的結果再次更新。請注意，優先順序一定要是 [A, I] 而非 [I, A]。如果優先順序是 [I, A]，Irene 就會通過索取操作獲得 10 枚代幣，Alice 就失去了原本屬於她的 4 枚代幣！

有了索取操作，Alice 和 Bob 再也不能串謀起來騙取 Irene 的資金了。

?最理想的情況

你可能已經注意到了，為了讓 Alice 他們取回資金，總共需要 3 個鏈上操作：將聯合通道和轉賬結果記錄到鏈上，並調用索取 操作。請注意，這是最糟糕的情況。假設 Bob 將 4 枚代幣轉給 Alice 後，Alice 和 Bob 想要關閉 J。如果 Bob 和 Irene 配合的話，則：

1. Alice、Bob 和 Irene 同意以結果 {A: 8, B: 2, I: 10} 敲定 J。

2. Alice 和 Irene 可以更新 L，安全地刪除為 J 提供資金的保證。L 的結果變成了 {A: 8, I: 5}。

3. 現在，Alice 可以使用 L 里的代幣為其它通道提供資金了。Alice 也可以選擇取走資金。

總而言之，在協作式案例中，Alice 可以使用 L 內的資金為多條不同的應用通道提供資金，也可以從這些取走資金，無需進行任何鏈上交易。

虛擬通道

在上一節中，我們已經介紹了如何在兩個參與方不存在鏈上關係的情況下創建三方通道。細心的讀者應該注意到了，更新 J 必須經過中間方簽字。在本文的開頭，我們打算在 A 和 B 之間創建一條私密通道。幸運的是，Nitro 的可組合性讓我們可以創建一條由 J 提供資金的私密應用通道 X。具體架構如下圖所示。你已經掌握理解這個架構所需的一切概念了。不過，如果你有任何問題，歡迎向我們提問！

未來計劃

本文介紹的虛擬通道架構是 Nitro 協議論文中介紹的架構的進化版。最值得一提的是，這個架構不需要創建專門的保證者通道。

Nitro 虛擬通道即將引入另一個更新，免去對聯合通道的需求。有了這個更新，賬本通道 L 和 L' 就可以為應用通道 X 提供資金。

本文由 Mike Kerzhner 和 Andrew Stewart 基於 Tom Close 所著論文《Nitro 協議》撰寫，感謝  Robert Drost、Joseph Chow、George Knee 和 Colin Kennedy 的反饋。

注

1. 我們還可以將索取操作理解成：

1. 將資金從 L 轉入 J，改變 J 的結果。

2. 將資金從 J 轉入目標地址。

如果賬本通道的結果是 {J: {amount: 10, priorities: [A, I]} 且 J 的結果是 {A: 4, B: 6, I: 10}，索取 可以描述成：

1. 將 10枚代幣從 L 轉入 J。

2. J的結果變成 {A: 4, I: 6, B: 6, I: 4}

3. 然後在 J 上調用面向 A 和 I 的轉賬。

冷萃財經原創，作者：Awing，轉載請註明出處：https://www.lccjd.top/2021/07/13/%e5%a6%82%e4%bd%95%e5%88%a9%e7%94%a8%e8%99%9a%e6%8b%9f%e9%80%9a%e9%81%93%e6%9d%a5%e5%88%9b%e5%bb%ba%e7%8a%b6%e6%80%81%e9%80%9a%e9%81%93%e7%bd%91%e7%bb%9c/?variant=zh-tw