乾貨 | 標準化狀態通道的架構與 Counterfactual
頻繁的交易使的以太坊虛擬機器變得越來越慢，交易費也越來越高。當下，大多數建立在以太坊上的應用都是通過更新鏈上合約的儲存變數來實現，使用者需要支付交易費並花一定時間等待區塊確認。
當然，這也是低效的。為了使用應用，我們要求使用者手動將資料庫更新提交至世界上最安全的、分散式的、無需信任的。。。1999 年老式手機（譯者注：意為當前的以太坊就像 1999 年的老式手機）。
值得慶幸的是，有一個更好的方法。
我們可以通過將一些工作轉移到客戶端而不是完全依賴以太坊編寫足夠安全的程式。我們將這類方法統稱為“第二層”區塊鏈技術。在 L4， 我們已經寫了 很多幫助解決這個問題的不同方法。
大多數“以太坊是不可拓展”的觀點不是因為底層區塊鏈不合適。更準確的說，是因為開發人員難以使用像狀態通道這樣的“第二層”區塊鏈技術。我們需要以太坊上有更好的開發者工具，從而使得用有效的方式編寫應用程式變得更加簡單。
Counterfatual 是一個正致力於解決該問題的開源專案。我們的目標是讓開發者在以太坊上輕鬆地使用狀態通道構建應用。你可以在我們的 主頁 上了解更多專案相關資訊，同時可以在 github 上檢視我們的程式碼。
為什麼現在很難使用狀態通道？
當下，如果開發者想要使用以太坊編寫他自己的分散式應用，他們可能需要實現以下內容：
- 一個公共 API ——合約中的公共或外部功能
- 授權邏輯——通常通過檢查 msg.sender 實現
- 解決邏輯——用於決定如何分配資產
在大多數情況下，在開發者設計分散式應用時，這是一種較好的抽象方式。我們已經看到 成千上萬的開發人員在過去一年中使用這種模式在以太坊上構建分散式應用 了，因此最好不要徹底改變它。
從這個角度思考狀態通道可以讓你與應用開發者更加感同身受。大多數情況下，當你嘗試設計狀態通道應用程式時，你會遇到各種各樣的障礙，例如：
- 因為你不再簽署以太坊交易而是簽署通用狀態物件，因此目前我們不太清楚公共 API 應該如何編寫。
- 授權邏輯需要每個狀態通道使用者為每次更新簽署一個物件，並且使用 ecrecover 驗證這些簽名。
- 由於每次新狀態提交時都存在內建的“質詢”或者“爭議”期，因此解決邏輯變的更加複雜。
最糟糕的是，狀態通道協議完全 沒有既定標準 ，這使得框架以及公共庫難以產生。
我們可以做些什麼讓它變的更容易呢？
使狀態通道應用程式更易於實現的最重要的第一步是要 清晰地將狀態通道解析邏輯與應用邏輯分離開來，以此標準化通用狀態通道功能 。應該儘可能簡單地用狀態通道相容的格式編寫應用程式，理想情況下，應該感覺你在編寫常規智慧合約程式碼。
其中一種實現方式就是將應用程式建模成狀態機。 force-move game framework 就是一個例子，通常來說，EVM 就是建立在狀態機的基本思想上——根據交易執行更新區塊狀態。
那麼常規智慧合約和狀態通道相容智慧合約之間的區別是什麼呢？從本質上來說，可以歸納為一句話： 我們需要一種與應用程式狀態轉換互動的標準方法 ，而不管公共 API 如何實現。更簡單的說，我們需要一個入口函式實現狀態轉換。
一個例子——井字遊戲
假設我們想要寫一個井字遊戲程式。我們會寫這樣一個智慧合約：它有 X 和 O 函式的公共 API ，可以檢查 msg.sender 以驗證玩家是否正確的進行遊戲。
contract TicTacToe {
address player1;
address player2;
uint8[3][3] board;
uint8 nextTurn;
function placeX(uint8 x, uint8 y) public {
if (msg.sender == player1) { ... }
}
function placeO(uint8 x, uint8 y) public {
if (msg.sender == player2) { ... }
}
}
將該遊戲建模成一個狀態機，我們可以看到共有 5 種狀態以及 2 種有效的狀態轉換型別。
-
-
回到更新應用狀態的標準介面的想法，我們想要建立一個函式以接受狀態及一些先前狀態（如, X_TURN）以及會導致狀態遷移的操作（如, PLACE_X）。有趣的是，這與現有的一些常見 Web 框架的模式完全相同，比如 Redux 。這種功能常常被稱作“reducer”。讓我們試一下用這種方法編寫井字遊戲吧：
contract TicTacToe {
enum ActionTypes { PLACE_X, PLACE_O }
enum StateTypes { X_TURN, O_TURN, X_WIN, O_WIN, DRAW }
struct Action {
ActionTypes actionType;
uint8 x;
uint8 y;
}
struct AppState {
StateTypes stateType;
address player1;
address player2;
uint8[3][3] board;
uint8 nextTurn;
}
function reduce(AppState state, Action action)
public
view
returns (AppState)
{
if (action.actionType == ActionTypes.PLACE_X) {
require(state.stateType == StateTypes.X_TURN);
return onPlaceX(state, action);
} else if (action.actionType == ActionTypes.PLACE_O) {
require(state.stateType == StateTypes.O_TURN);
return onPlaceO(state, action);
} else {
revert("Invalid action type");
}
}
function onPlaceX(AppState state, Action action) internal returns (AppState) { ... }
function onPlaceO(AppState state, Action action) internal returns (AppState) { ... }
}
有了這些，我們現在有了一種計算狀態更新的方法了：可以通過一個公共介面——reduceinterface 對應用程式進行狀態更新。這一點在保護狀態通道免受各種攻擊時非常有用。
但是狀態通道合約到底需要做什麼呢？
本質上說，狀態通道物件需要 使用 應用邏輯來判斷狀態轉移是否有效。核心狀態功能可以在一個用於處理各種可能攻擊的通用合約中實現，狀態機的具體狀態轉換規則則需要視具體應用而定。
有兩個需要處理的主要場景。如果我們使用 Alice 與 Bob 互相交換資訊這一常見例子，這兩個場景可以被描述為：
-
如果 Bob 提交過時的狀態該怎麼辦？
合約必須能夠實現 超時階段 （timeout period），這樣 Alice 就可以提交比 Bob 提交更新的狀態。如果 Bob 提交的狀態被證明是舊的，那麼 Bob 就要受到懲罰。
-
如果 Bob 停止響應、該怎麼辦？
合約必須讓 Alice 可以提交她從 Bob 那裡收到的最新簽署狀態，以便將她的錢取出來(超時階段後)。在某些情況下，Alice 可能可以推動應用狀態機狀態遷移，因此她必須要能夠在這種情況下使用應用程式的 reducer。
為此，合約需要公開一個基礎 API。請注意，這個基礎 API 的主要作用是處理有爭議的事件。狀態通道使用者可以通過呼叫一組函式來保證他們簽名的離線狀態更新有意義。
這個基礎API包括：
- 建立爭議事件 一方提交最終簽署的狀態副本，並 可選擇 執行一個操作使得邏輯上狀態發生遷移。
- 處理爭議 一方通過對已提交狀態進行操作的方式對另一方建立的爭議 做出反應 。
- 解決爭議 雙方同意解決對應爭議並恢復正常鏈下執行。
資產儲存在哪裡？
這就是 我們的論文 中描述的許多特性非常有用的地方。我們將資產放在一個通用的多簽名錢包中，並將其作為依據狀態通道結果分配資產的主要合約。
這給我們帶來了很多好處。最大的好處之一就是可以利用 counterfatual 例項技術，這一點也在 論文 中詳細描述了。當我們將其新增到組合當中時，可以在鏈下維護狀態通道合約以及應用邏輯合約。
在我們完成這些設定之後，我們又獲得了另一個強大的特性： 安裝和解除安裝應用都可以在鏈下進行。
當我們使用 counterfatual 時，安裝和解除安裝應用都是免費和即時的。由於我們可以從多重簽名錢包中無限呼叫有條件轉移，因此，可以保證任意數量的應用免費且即時的安裝與解除安裝。
接下來的計劃
在以後的帖子、演講以及討論中，我們將概述我們對於合約層之上的軟體的願景。要想在生產生活中應用狀態通道，還需要整個生態系統進行大量的協調。我們當前正在開展並期待與其他人進一步合作的具體領域包括：
- 標準化研究術語，分享見解，並跟蹤狀態通道以及第二層擴充套件領域的其他研究問題。
- 將通用狀態通道模式整合到現有的基於鏈下正規化的狀態通道系統和應用中。
- 與 Web3 框架合作，讓他們未來更關注線下 API 的發展。
- 與錢包提供商合作以幫助提供明確的關於狀態通道在該領域應用的協議規範和標準。
我要怎樣才能學習到更多並作出一定貢獻？
作為一個好的起點，我們建議你檢視 我們共享在 GitHub 上的合約程式碼 ，程式碼包含該技術的參考實現。
我們將繼續與對未來分散式應用開發感興趣的優秀團隊和個人合作，也期望邀請其他人和我們合作。
這只是旅程的開始。為了看到所有使用者均可訪問的通用狀態網路網路，我們需要做的還有很多。
狀態通道將成為用於點對點價值轉移的協議。它們將需要進行標準化從而可以在各種客戶端、錢包以及區塊鏈中使用。
如果你有興趣和我們一起實現這樣的未來，請通過 [email protected] 聯絡我們，或者在 Github 上加入我們。
原文連結: https://medium.com/statechannels/state-channel-applications-1f170e7d542e
作者:Liam Horne
翻譯&校對:Aisling & Elisa