頻繁進行交易以推進以太坊虛擬機器是不必要的昂貴和緩慢。今天大多數使用以太坊的應用程式都透過更新鏈上合約的儲存變數來工作，使用者為此支付交易費用並花長時間等待區塊確認。
為了使用應用程式，我們強迫使用者手動將資料庫更新提交給世界上最安全，分散和無信任的環境。
透過將一些功能轉移到客戶端程式碼上，而不是單獨依靠以太坊為我們做所有事情，我們可以編寫完全安全的應用程式。通常我們將這些稱為“layer2”技術。
大多數“以太坊應用都不可伸縮！”的敘述並不是因為底層的區塊鏈不合適。更準確地說，這是因為開發人員很難使用狀態通道等Layer2層技術。我們需要在以太坊之上擁有更好的開發人員工具，這將使以高效方式編寫應用程式變得更加容易。
Counterfactual是一個開源專案，正致力於解決這個問題。我們的目標是使開發人員易於使用以太坊上的狀態通道來構建應用程式。
為什麼現在很難使用狀態通道？
今天，如果開發人員希望使用以太坊編寫分散式應用程式，他們可能要實現以下每一項：
1. 公共API-合約上的public或extenal函式
2. 授權邏輯（Authorization logic）-通常透過檢查msg.sender
3. 解決邏輯（Resolution logic）-決定如何分配資金
在大多數情況下，這是開發人員在設計分散式應用程式時要考慮的一個很好的抽象層次。 去年，我們已經看到成千上萬的開發人員使用這種模式使用以太坊構建應用程式，所以最好不要徹底改變它。
從這種角度考慮狀態通道會給應用程式開發人員產生更多共鳴。在大多數情況下，嘗試設計狀態通道應用程式時，您會遇到各種障礙，例如：
不清楚應該如何編寫公共API，因為您不再簽署Ethereum事務，而是簽署通用狀態物件
授權邏輯（Authorization logic）要求狀態通道的每個使用者為每個更新簽署一個物件，並使用ecrecover驗證這些簽名。
由於每次提交新狀態時都有一個內建的“挑戰”或“爭議”階段，因此現在的解決邏輯（Resolution logic）更加複雜。
最糟糕的是，對於整個狀態通道協議，沒有任何既定的標準，這使得框架或公共庫很難出現。
我們可以做些什麼來簡化它？
使狀態通道應用程式更易於推理的最重要的第一步是標準化通用狀態通道功能，使狀態通道解析邏輯與應用程式邏輯完全分離以與狀態通道相容的格式編寫應用程式應該儘可能簡單，理想情況下，應該感覺像是在編寫常規的智慧合約程式碼。
實現此目的的一種方法是將應用程式建模為狀態機。強制移動遊戲框架就是其中的一個示例，通常EVM已基於狀態機的基本思想構建，狀態機基於事務執行來更新每個區塊的狀態。
那麼，普通智慧合約和相容狀態通道的智慧合約有什麼區別？本質上可以歸結為以下事實：無論公共API的實現如何，我們都需要一種標準方法來與應用程式的狀態轉換進行互動。簡而言之，我們需要一個入口點函式來計算狀態轉換。
一個例子-井字遊戲
假設我們要編寫一個井字遊戲應用程式。我們可能會編寫一個智慧合約，該合約具有帶有placeX和placeO函式的公共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) { ... }
}
}
用Solidity編寫的井字遊戲智慧合約示例。
將這個遊戲建模為一個狀態機，我們可以看到在它們之間有5種狀態和2種有效的轉換型別。
井字遊戲應用程式的狀態機示例。 如果是X的回合，X可以採取行動贏得比賽，以平局結束比賽，或者只是放下棋子並將其傳遞給O進行回合。
回到用於更新應用程式狀態的標準介面的想法，我們想建立一個函式，該函式接受狀態機的某些先前狀態（例如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;
}
functionreduce(AppState state, Action action)
public
view
returns (AppState)
{
if (action.actionType == ActionTypes.PLACE_X) {
require(state.stateType == StateTypes.X_TURN);
return onPlaceX(state, action);
} elseif (action.actionType == ActionTypes.PLACE_O) {
require(state.stateType == StateTypes.O_TURN);
return onPlaceO(state, action);
} else {
revert("Invalid action type");
}
}
functiononPlaceX(AppState state, Action action) internalreturns (AppState) { ... }
functiononPlaceO(AppState state, Action action) internalreturns (AppState) { ... }
}
一個井字遊戲應用程式，它具有一個用於處理PLACE_X和PLACE_O動作的reduce函式而不是多個名為placeX和placeO的函式。reducer功能將動作“分派”到helper函式。
有了這個，我們現在有了一種計算狀態更新的方法，可以透過一個公共介面——reduce介面對應用程式進行更新。在考慮必須保護狀態通道的攻擊型別時，這非常有用。
但是狀態通道合約中需要做什麼呢？
當然，狀態通道物件應該使用應用程式邏輯來確定轉換是否有效。核心狀態通道功能可以存在於通用協定中，該協定處理可能的各種攻擊情形，但會為其狀態機的特定轉換規則委派給應用程式。
狀態通道可以使用App邏輯作為確定有效轉換的手段，但是根據App邏輯提供給它的資訊來處理授權和解析邏輯本身。
有兩種主要情況需要處理。如果我們使用Alice和Bob相互交換訊息的常見示例，則可以將它們構造為：
1、如果Bob提交過時的狀態呢？
合約必須能夠實現一個超時期，以便Alice有時間提交比Bob提交的狀態更新的狀態。如果Bob提交的狀態可以證明是超時的，那麼Bob應該受到懲罰。
2、如果Bob停止響應怎麼辦？
合約必須使Alice能夠提交她從Bob那裡收到的最新簽名狀態，以便將她的錢取出（在超時期限過去之後）。在某些情況下，Alice可能會“採取行動”以改善應用程式的狀態機，因此在這種情況下，她必須能夠使用應用程式的reducer。
為此，合約需要公開一個基本的API。請注意，這實際上是處理爭議案件的API。狀態通道的使用者可以使用一組函式呼叫來確保他們正在簽名的鏈下狀態更新具有重要意義。
這個API大致包括：
建立爭議案件。
一方提交狀態的最新簽名副本，並可選地對應用程式執行操作，該操作將在邏輯上將狀態提升到下一個狀態。
進行爭議。
一方透過對已提交的狀態採取行動來回應另一方的爭議。
取消爭議。
雙方同意取消爭議並恢復正常。
資金存放在哪裡？
這就是本文中描述的許多特性變得有用的地方。我們將這些資金放在一個通用的多簽名錢包中，並將其用作根據狀態通道的結果作出分配資金承諾的主要智慧合約。
一個簡單的應用程式使用狀態通道而不使用反事實例項化，而只是使用常規的智慧合約引用。
這給了我們很多有益的好處。最好的方法之一是利用反事實例項化技術的能力，本文也對此進行了詳細介紹。當我們將其新增到組合中時，我們可以使狀態通道合約和應用程式邏輯合約保持鏈下狀態。
與上述相同的設定，但是這次狀態通道合約和應用程式邏輯合同是反事實的-僅在發生糾紛時才需要在鏈上進行部署。
設定之後，我們得到了另一個非常強大的特性：用於安裝和解除安裝應用程式的零鏈上事務。
當我們使用反事實時，新增和刪除應用程式是免費且即時的。
實際上，由於我們可以從多簽名錢包進行無限次數的有條件轉賬，因此這些commitments可以用於任何數量的應用程式。
下一步
在以後的帖子，講座和討論中，我們將概述對將用於合約層之上的軟體的願景。要在生產環境中使用的狀態通道，將需要整個生態系統的大量協調。我們目前正在一些具體領域應用，並希望與其他領域進一步合作：
1. 標準化研究術語，分享見解，並在狀態通道和第2層縮放中跟進其他有趣的研究問題。
2. 將廣義狀態通道模式整合到現有的狀態通道系統和基於非鏈式正規化的應用程式。
3. 與web3框架合作，使鏈外關注點在開發人員api的未來開發中廣為人知。
4. 與錢包提供者一起工作，幫助提供清晰的協議規範和標準，說明狀態通道可以在其域中如何存在。
描下方二維碼新增我，拉您進入技術交流群
掃碼
關注我們
獲得
更多精彩
