跳至主要內容
Change page

狀態通道

狀態通道允許參與者安全地在鏈下進行交易，同時將與以太坊主網的互動降至最低。通道對等節點可以進行任意數量的鏈下交易，而只需提交兩筆鏈上交易來開啟和關閉通道。這實現了極高的交易吞吐量，並為使用者降低了成本。

先決條件

您應該已經閱讀並了解我們關於以太坊擴容和第二層 (L2)的頁面。

什麼是通道？

像以太坊這樣的公有區塊鏈，由於其分散式架構而面臨可擴展性挑戰：鏈上交易必須由所有節點執行。節點必須能夠使用普通的硬體來處理區塊中的交易量，這對交易吞吐量施加了限制，以保持網路的去中心化。區塊鏈通道解決了這個問題，允許使用者在鏈下互動，同時仍然依賴主鏈的安全性進行最終結算。

通道是簡單的點對點協定，允許雙方在彼此之間進行許多交易，然後只將最終結果發佈到區塊鏈上。通道使用密碼學來證明他們產生的摘要資料確實是一組有效中間交易的結果。一個「多方簽名」智能合約確保交易由正確的各方簽署。

透過通道，狀態變更由相關方執行和驗證，從而將以太坊執行層上的運算降至最低。這減少了以太坊上的壅塞，也提高了使用者的交易處理速度。

每個通道都由在以太坊上運行的多方簽名智能合約管理。要開啟通道，參與者在鏈上部署通道合約並將資金存入其中。雙方共同簽署狀態更新以初始化通道的狀態，之後他們就可以在鏈下快速自由地進行交易。

要關閉通道，參與者將最後達成共識的通道狀態提交到鏈上。之後，智能合約根據通道最終狀態中每個參與者的餘額分配鎖定的資金。

點對點通道特別適用於某些預先定義的參與者希望高頻率進行交易而不產生明顯開銷的情況。區塊鏈通道分為兩類：支付通道和狀態通道。

支付通道

支付通道最貼切的描述是由兩位使用者共同維護的「雙向帳本」。帳本的初始餘額是在通道開啟階段鎖定在鏈上合約中的存款總和。支付通道轉帳可以即時執行，除了最初的一次性鏈上建立和最終關閉通道之外，不需要實際區塊鏈本身的參與。

帳本餘額（即支付通道的狀態）的更新需要通道中所有各方的批准。由所有通道參與者簽署的通道更新被視為已定案，就像以太坊上的交易一樣。

支付通道是最早的擴容解決方案之一，旨在將簡單使用者互動（例如 ETH 轉帳、原子交換、微型支付）的昂貴鏈上活動降至最低。只要轉帳的淨總額不超過存入的代幣，通道參與者就可以在彼此之間進行無限量的即時、免手續費交易。

狀態通道

除了支援鏈下支付外，支付通道尚未被證明可用於處理一般狀態轉換邏輯。狀態通道的建立是為了解決這個問題，並使通道可用於擴展通用運算。

狀態通道與支付通道仍有許多共同點。例如，使用者透過交換經過密碼學簽章的訊息（交易）進行互動，其他通道參與者也必須簽署這些訊息。如果提議的狀態更新未經所有參與者簽署，則被視為無效。

然而，除了持有使用者的餘額外，通道還追蹤合約儲存的當前狀態（即合約變數的值）。

這使得在兩位使用者之間在鏈下執行智能合約成為可能。在這種情況下，智能合約內部狀態的更新只需要建立通道的對等節點批准。

雖然這解決了前面描述的可擴展性問題，但它對安全性有影響。在以太坊上，狀態轉換的有效性由網路的共識協定強制執行。這使得不可能對智能合約的狀態提出無效更新或更改智能合約的執行。

狀態通道沒有相同的安全保證。在某種程度上，狀態通道是主網的縮小版。由於執行規則的參與者數量有限，惡意行為（例如提議無效的狀態更新）的可能性會增加。狀態通道的安全性來自於基於的爭議仲裁系統。

狀態通道如何運作

基本上，狀態通道中的活動是涉及使用者和區塊鏈系統的互動會話。使用者主要在鏈下相互通訊，僅在開啟通道、關閉通道或解決參與者之間的潛在爭議時才與底層區塊鏈互動。

以下部分概述了狀態通道的基本工作流程：

開啟通道

開啟通道要求參與者將資金提交給主網上的智能合約。存款也充當虛擬帳單，因此參與者可以自由交易，而無需立即結算付款。只有當通道在鏈上已定案時，各方才會相互結算並提取帳單上剩餘的資金。

這筆存款也作為保證金，以保證每個參與者的誠實行為。如果在爭議解決階段發現存款人有惡意行為，合約將沒收他們的存款。

通道對等節點必須簽署一個他們都同意的初始狀態。這作為狀態通道的創世狀態，之後使用者就可以開始交易。

使用通道

初始化通道狀態後，對等節點透過簽署交易並將其發送給彼此以供批准來進行互動。參與者透過這些交易發起狀態更新，並簽署來自其他人的狀態更新。每筆交易包含以下內容：

  • 一個隨機數，作為交易的唯一 ID 並防止重放攻擊。它還標識了狀態更新發生的順序（這對爭議解決很重要）

  • 通道的舊狀態

  • 通道的新狀態

  • 觸發狀態轉換的交易（例如，Alice 發送 5 ETH 給 Bob）

通道中的狀態更新不會像使用者在主網上互動時那樣在鏈上廣播，這符合狀態通道將鏈上足跡降至最低的目標。只要參與者對狀態更新達成共識，它們就和以太坊交易一樣具有最終性。參與者只有在發生爭議時才需要依賴主網的共識。

關閉通道

關閉狀態通道需要將通道最終達成共識的狀態提交給鏈上智能合約。狀態更新中引用的詳細資訊包括每個參與者的操作次數和已批准交易的清單。

在驗證狀態更新有效（即由所有各方簽署）後，智能合約將通道定案，並根據通道的結果分配鎖定的資金。在鏈下進行的付款將應用於以太坊的狀態，每個參與者將收到其剩餘部分的鎖定資金。

上述情況代表了在理想情況下發生的事情。有時，使用者可能無法達成共識並將通道定案（糟糕的情況）。該情況可能是以下任何一種：

  • 參與者離線且未能提議狀態轉換

  • 參與者拒絕共同簽署有效的狀態更新

  • 參與者試圖透過向鏈上合約提議舊的狀態更新來將通道定案

  • 參與者提議無效的狀態轉換供其他人簽署

每當通道中參與者之間的共識破裂時，最後的選擇是依賴主網的共識來強制執行通道的最終有效狀態。在這種情況下，關閉狀態通道需要在鏈上解決爭議。

解決爭議

通常，通道中的各方會事先同意關閉通道，並共同簽署最後的狀態轉換，然後將其提交給智能合約。一旦更新在鏈上獲得批准，鏈下智能合約的執行就會結束，參與者帶著他們的資金退出通道。

然而，一方可以提交鏈上請求以結束智能合約的執行並將通道定案——而無需等待對方的批准。如果發生前面描述的任何破壞共識的情況，任何一方都可以觸發鏈上合約來關閉通道並分配資金。這提供了無須信任性，確保誠實的各方可以隨時退出其存款，而不管另一方的行為如何。

為了處理通道退出，使用者必須將應用程式的最後一個有效狀態更新提交給鏈上合約。如果這通過了檢查（即它帶有所有各方的簽章），那麼資金將重新分配給他們。

然而，在執行單一使用者退出請求時會有延遲。如果結束通道的請求獲得一致批准，則鏈上退出交易將立即執行。

由於可能存在欺詐行為，延遲會在單一使用者退出時發揮作用。例如，通道參與者可能會試圖透過在鏈上提交較舊的狀態更新來在以太坊上將通道定案。

作為對策，狀態通道允許誠實的使用者透過在鏈上提交通道的最新有效狀態來挑戰無效的狀態更新。狀態通道的設計使得較新的、達成共識的狀態更新勝過較舊的狀態更新。

一旦對等節點觸發鏈上爭議解決系統，另一方就必須在時間限制（稱為挑戰窗口）內做出回應。這允許使用者挑戰退出交易，特別是如果另一方正在應用過時的更新。

無論情況如何，通道使用者始終擁有強大的最終性保證：如果他們擁有的狀態轉換由所有成員簽署並且是最新的更新，那麼它與常規鏈上交易具有同等的最終性。他們仍然必須在鏈上挑戰另一方，但唯一可能的結果是將他們持有的最後一個有效狀態定案。

狀態通道如何與以太坊互動？

雖然它們作為鏈下協定存在，但狀態通道有一個鏈上元件：開啟通道時部署在以太坊上的智能合約。該合約控制存入通道的資產，驗證狀態更新，並仲裁參與者之間的爭議。

與第二層 (L2)擴容解決方案不同，狀態通道不會將交易資料或狀態承諾發佈到主網。然而，與側鏈相比，它們與主網的連接更緊密，這使得它們在某種程度上更安全。

狀態通道依賴以太坊主協定來實現以下功能：

1. 活躍度

開啟通道時部署的鏈上合約負責通道的功能。如果合約在以太坊上運行，那麼通道始終可供使用。相反，即使主網正常運行，側鏈也可能隨時發生故障，從而使使用者資金面臨風險。

2. 安全性

在某種程度上，狀態通道依賴以太坊來提供安全性並保護使用者免受惡意對等節點的侵害。如後續章節所述，通道使用欺詐證明機制，讓使用者可以挑戰試圖使用無效或過時更新將通道定案的行為。

在這種情況下，誠實方將通道的最新有效狀態作為欺詐證明提供給鏈上合約進行驗證。欺詐證明使互不信任的各方能夠進行鏈下交易，而不會在此過程中使其資金面臨風險。

3. 最終性

由通道使用者共同簽署的狀態更新被認為與鏈上交易一樣有效。儘管如此，所有通道內活動只有在以太坊上關閉通道時才能實現真正的最終性。

在樂觀的情況下，雙方可以合作並簽署最終狀態更新並提交到鏈上以關閉通道，之後根據通道的最終狀態分配資金。在悲觀的情況下，如果有人試圖透過在鏈上發佈不正確的狀態更新來作弊，他們的交易在挑戰窗口結束之前不會被定案。

虛擬狀態通道

狀態通道的簡單實作是在兩位使用者希望在鏈下執行應用程式時部署一個新合約。這不僅不可行，而且還抵消了狀態通道的成本效益（鏈上交易成本會迅速累積）。

為了解決這個問題，建立了「虛擬通道」。與需要鏈上交易來開啟和終止的常規通道不同，虛擬通道可以在不與主鏈互動的情況下開啟、執行和定案。使用這種方法甚至可以在鏈下解決爭議。

該系統依賴於所謂的「帳本通道」的存在，這些通道已在鏈上獲得資金。雙方之間的虛擬通道可以建立在現有的帳本通道之上，由帳本通道的擁有者擔任中介。

每個虛擬通道中的使用者透過新的合約實例進行互動，而帳本通道能夠支援多個合約實例。帳本通道的狀態還包含多個合約儲存狀態，允許不同使用者之間在鏈下平行執行應用程式。

就像常規通道一樣，使用者交換狀態更新以推進狀態機。除非發生爭議，否則只需在開啟或終止通道時聯絡中介。

虛擬支付通道

虛擬支付通道的運作理念與虛擬狀態通道相同：連接到同一網路的參與者可以傳遞訊息，而無需在鏈上開啟新通道。在虛擬支付通道中，價值轉移透過一個或多個中介進行路由，並保證只有預期的接收者才能收到轉移的資金。

狀態通道的應用

支付

早期的區塊鏈通道是簡單的協定，允許兩位參與者在鏈下進行快速、低費用的轉帳，而無需在主網上支付高額交易費用。如今，支付通道對於專為交換和存入以太幣及代幣而設計的應用程式仍然有用。

基於通道的支付具有以下優勢：

  1. 吞吐量：每個通道的鏈下交易量與以太坊的吞吐量無關，後者受各種因素影響，特別是區塊大小和區塊時間。透過在鏈下執行交易，區塊鏈通道可以實現更高的吞吐量。

  2. 隱私：因為通道存在於鏈下，參與者之間互動的詳細資訊不會記錄在以太坊的公有區塊鏈上。通道使用者只需在為通道提供資金、關閉通道或解決爭議時才需要在鏈上互動。因此，通道對於希望進行更私密交易的個人很有用。

  3. 延遲：如果雙方合作，通道參與者之間進行的鏈下交易可以即時結算，從而減少延遲。相比之下，在主網上發送交易需要等待節點處理交易、產生包含該交易的新區塊並達成共識。使用者可能還需要等待更多區塊確認，然後才能認為交易已定案。

  4. 成本：狀態通道在某些情況下特別有用，即一組參與者將在很長一段時間內交換許多狀態更新。產生的唯一成本是開啟和關閉狀態通道智能合約；在開啟和關閉通道之間的每次狀態變更都會比上一次更便宜，因為結算成本會相應地分攤。

在第二層 (L2) 解決方案（例如匯總）上實作狀態通道，可能會使它們對支付更具吸引力。雖然通道提供廉價的支付，但在開啟階段在主網上設定鏈上合約的成本可能會變得昂貴——特別是在燃料費用飆升時。基於以太坊的匯總提供較低的交易費用 (opens in a new tab)，並可以透過降低設定費用來減少通道參與者的開銷。

微型支付

微型支付是低價值的付款（例如，低於幾美分），企業在不產生損失的情況下無法處理這些付款。這些實體必須向支付服務提供商付款，如果客戶付款的利潤率太低而無法獲利，他們就無法做到這一點。

支付通道透過減少與微型支付相關的開銷來解決這個問題。例如，網際網路服務供應商 (ISP) 可以與客戶開啟支付通道，允許他們在每次使用服務時串流支付小額款項。

除了開啟和關閉通道的成本外，參與者不會在微型支付上產生進一步的成本（沒有燃料費用）。這是一個雙贏的局面，因為客戶在支付服務費用方面有更大的靈活性，而企業也不會錯失有利可圖的微型支付。

去中心化應用程式

就像支付通道一樣，狀態通道可以根據狀態機的最終狀態進行有條件的支付。狀態通道還可以支援任意狀態轉換邏輯，使其可用於在鏈下執行通用應用程式。

狀態通道通常僅限於簡單的回合制應用程式，因為這使得管理提交給鏈上合約的資金變得更加容易。此外，由於只有數量有限的各方定期更新鏈下應用程式的狀態，懲罰不誠實行為相對簡單。

狀態通道應用程式的效率也取決於其設計。例如，開發人員可能會在鏈上部署一次應用程式通道合約，並允許其他玩家重複使用該應用程式而無需上鏈。在這種情況下，初始應用程式通道作為支援多個虛擬通道的帳本通道，每個虛擬通道都在鏈下運行應用程式智能合約的新實例。

狀態通道應用程式的一個潛在使用案例是簡單的雙人遊戲，其中資金根據遊戲結果進行分配。這裡的好處是玩家不必互相信任（無須信任性），並且由鏈上合約（而不是玩家）控制資金的分配和爭議的解決（去中心化）。

狀態通道應用程式的其他可能使用案例包括 ENS 名稱所有權、NFT 帳本等等。

原子轉帳

早期的支付通道僅限於雙方之間的轉帳，限制了其可用性。然而，虛擬通道的引入允許個人透過中介（即多個 p2p 通道）路由轉帳，而無需在鏈上開啟新通道。

路由支付通常被描述為「多跳轉帳」，它是原子性的（即交易的所有部分要麼全部成功，要麼完全失敗）。原子轉帳使用雜湊時間鎖定合約 (HTLC) (opens in a new tab)來確保僅在滿足特定條件時才釋放付款，從而降低交易對手風險。

使用狀態通道的缺點

活躍度假設

為了確保效率，狀態通道對通道參與者回應爭議的能力設定了時間限制。該規則假設對等節點將始終在線以監控通道活動並在必要時提出挑戰。

實際上，使用者可能會因為無法控制的原因（例如，網路連線不良、機械故障等）而離線。如果誠實的使用者離線，惡意的對等節點可以利用這種情況，向裁決合約提交舊的中間狀態並竊取提交的資金。

某些通道使用「瞭望塔」——代表他人監視鏈上爭議事件並採取必要行動（如提醒相關方）的實體。然而，這可能會增加使用狀態通道的成本。

資料不可用性

如前所述，挑戰無效爭議需要提供狀態通道的最新有效狀態。這是另一個基於假設的規則——使用者可以存取通道的最新狀態。

雖然期望通道使用者儲存鏈下應用程式狀態的副本是合理的，但這些資料可能會因錯誤或機械故障而遺失。如果使用者沒有備份資料，他們只能希望另一方不會使用其擁有的舊狀態轉換來將無效的退出請求定案。

以太坊使用者不必處理這個問題，因為網路強制執行資料可用性規則。交易資料由所有節點儲存和傳播，並在必要時可供使用者下載。

流動性問題

要建立區塊鏈通道，參與者需要在通道的生命週期內將資金鎖定在鏈上智能合約中。這降低了通道使用者的流動性，也將通道限制在那些負擔得起將資金鎖定在主網上的人。

然而，由鏈下服務提供商 (OSP) 營運的帳本通道可以減少使用者的流動性問題。連接到帳本通道的兩個對等節點可以建立一個虛擬通道，他們可以隨時完全在鏈下開啟和定案該通道。

鏈下服務提供商也可以與多個對等節點開啟通道，使其可用於路由支付。當然，使用者必須向 OSP 支付服務費用，這對某些人來說可能是不受歡迎的。

悲痛攻擊

悲痛攻擊（Griefing attacks）是基於欺詐證明系統的常見特徵。悲痛攻擊不會直接使攻擊者受益，但會給受害者帶來悲痛（即傷害），因此得名。

欺詐證明容易受到悲痛攻擊，因為誠實方必須回應每一個爭議，甚至是無效的爭議，否則就有失去資金的風險。惡意參與者可以決定重複在鏈上發佈過時的狀態轉換，迫使誠實方以有效狀態做出回應。這些鏈上交易的成本會迅速累積，導致誠實方在此過程中遭受損失。

預先定義的參與者集合

根據設計，組成狀態通道的參與者數量在其整個生命週期中保持固定。這是因為更新參與者集合會使通道的運作複雜化，特別是在為通道提供資金或解決爭議時。新增或移除參與者還需要額外的鏈上活動，這增加了使用者的開銷。

雖然這使得狀態通道更容易理解，但它限制了通道設計對應用程式開發人員的實用性。這部分解釋了為什麼狀態通道被放棄，轉而支持其他擴容解決方案，例如匯總。

平行交易處理

狀態通道中的參與者輪流發送狀態更新，這就是為什麼它們最適合「回合制應用程式」（例如，雙人西洋棋遊戲）。這消除了處理同時狀態更新的需要，並減少了鏈上合約為懲罰過時更新發佈者而必須做的工作。然而，這種設計的副作用是交易相互依賴，增加了延遲並降低了整體使用者體驗。

某些狀態通道透過使用「全雙工」設計來解決這個問題，該設計將鏈下狀態分為兩個單向的「單工」狀態，允許並行狀態更新。這種設計提高了鏈下吞吐量並減少了交易延遲。

使用狀態通道

多個專案提供了狀態通道的實作，您可以將其整合到您的去中心化應用程式 (dapp) 中：

進一步閱讀

狀態通道

知道有幫助過您的社群資源嗎？編輯此頁面並加入它！