頻繁進行交易以推進以太坊虛擬機是不必要的昂貴和緩慢。今天大多數使用以太坊的應用程序都通過更新鏈上合約的存儲變量來工作，用戶爲此支付交易費用並花長時間等待區塊確認。
爲了使用應用程序，我們強迫用戶手動將數據庫更新提交給世界上最安全，分散和無信任的環境。
通過將一些功能轉移到客戶端代碼上，而不是單獨依靠以太坊爲我們做所有事情，我們可以編寫完全安全的應用程序。通常我們將這些稱爲“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以驗證是否有正確的參與者在行動。
用Solidity編寫的井字遊戲智能合約示例。
將這個遊戲建模爲一個狀態機，我們可以看到在它們之間有5種狀態和2種有效的轉換類型。
井字遊戲應用程序的狀態機示例。 如果是X的回合，X可以採取行動贏得比賽，以平局結束比賽，或者只是放下棋子並將其傳遞給O進行回合。
回到用於更新應用程序狀態的標準接口的想法，我們想創建一個函數，該函數接受狀態機的某些先前狀態（例如X_TURN）以及可以採取的操作以達到新狀態 （例如PLACE_X）。 有趣的是，這與當今存在的某些常見Web框架（例如Redux）完全相同。 他們傾向於將這種功能稱爲“reducer”。 因此，讓我們嘗試以這種方式編寫井字遊戲應用程序：
一個井字遊戲應用程序，它具有一個用於處理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. 與錢包提供者一起工作，幫助提供清晰的協議規範和標準，說明狀態通道可以在其域中如何存在。