將這個遊戲建模為一個狀態機，我們可以看到在它們之間有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;
}
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) { ... }
}
一個井字遊戲應用程式，它具有一個用於處理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. 與錢包提供者一起工作，幫助提供清晰的協議規範和標準，說明狀態通道可以在其域中如何存在。
