頻繁進(jìn)行交易以推進(jìn)以太坊虛擬機(jī)是不必要的昂貴和緩慢。今天大多數(shù)使用以太坊的應(yīng)用程序都通過更新鏈上合約的存儲變量來工作，用戶為此支付交易費(fèi)用并花長時間等待區(qū)塊確認(rèn)。

為了使用應(yīng)用程序，我們強(qiáng)迫用戶手動將數(shù)據(jù)庫更新提交給世界上最安全，分散和無信任的環(huán)境。

通過將一些功能轉(zhuǎn)移到客戶端代碼上，而不是單獨(dú)依靠以太坊為我們做所有事情，我們可以編寫完全安全的應(yīng)用程序。通常我們將這些稱為“l(fā)ayer2”技術(shù)。

大多數(shù)“以太坊應(yīng)用都不可伸縮！”的敘述并不是因?yàn)榈讓拥膮^(qū)塊鏈不合適。更準(zhǔn)確地說，這是因?yàn)殚_發(fā)人員很難使用狀態(tài)通道等Layer2層技術(shù)。我們需要在以太坊之上擁有更好的開發(fā)人員工具，這將使以高效方式編寫應(yīng)用程序變得更加容易。

Counterfactual是一個開源項(xiàng)目，正致力于解決這個問題。我們的目標(biāo)是使開發(fā)人員易于使用以太坊上的狀態(tài)通道來構(gòu)建應(yīng)用程序。

為什么現(xiàn)在很難使用狀態(tài)通道？

今天，如果開發(fā)人員希望使用以太坊編寫分布式應(yīng)用程序，他們可能要實(shí)現(xiàn)以下每一項(xiàng)：

1. 公共API-合約上的public或extenal函數(shù)

2. 授權(quán)邏輯（Authorization logic）-通常通過檢查msg.sender

3. 解決邏輯（ResoluTIon logic）-決定如何分配資金

在大多數(shù)情況下，這是開發(fā)人員在設(shè)計(jì)分布式應(yīng)用程序時要考慮的一個很好的抽象層次。 去年，我們已經(jīng)看到成千上萬的開發(fā)人員使用這種模式使用以太坊構(gòu)建應(yīng)用程序，所以最好不要徹底改變它。

從這種角度考慮狀態(tài)通道會給應(yīng)用程序開發(fā)人員產(chǎn)生更多共鳴。在大多數(shù)情況下，嘗試設(shè)計(jì)狀態(tài)通道應(yīng)用程序時，您會遇到各種障礙，例如：

1. 不清楚應(yīng)該如何編寫公共API，因?yàn)槟辉俸炇餎thereum事務(wù)，而是簽署通用狀態(tài)對象

2. 授權(quán)邏輯（AuthorizaTIon logic）要求狀態(tài)通道的每個用戶為每個更新簽署一個對象，并使用ecrecover驗(yàn)證這些簽名。

3. 由于每次提交新狀態(tài)時都有一個內(nèi)置的“挑戰(zhàn)”或“爭議”階段，因此現(xiàn)在的解決邏輯（ResoluTIon logic）更加復(fù)雜。

最糟糕的是，對于整個狀態(tài)通道協(xié)議，沒有任何既定的標(biāo)準(zhǔn)，這使得框架或公共庫很難出現(xiàn)。

我們可以做些什么來簡化它？

使?fàn)顟B(tài)通道應(yīng)用程序更易于推理的最重要的第一步是標(biāo)準(zhǔn)化通用狀態(tài)通道功能，使?fàn)顟B(tài)通道解析邏輯與應(yīng)用程序邏輯完全分離以與狀態(tài)通道兼容的格式編寫應(yīng)用程序應(yīng)該盡可能簡單，理想情況下，應(yīng)該感覺像是在編寫常規(guī)的智能合約代碼。

實(shí)現(xiàn)此目的的一種方法是將應(yīng)用程序建模為狀態(tài)機(jī)。強(qiáng)制移動游戲框架就是其中的一個示例，通常EVM已基于狀態(tài)機(jī)的基本思想構(gòu)建，狀態(tài)機(jī)基于事務(wù)執(zhí)行來更新每個區(qū)塊的狀態(tài)。

那么，普通智能合約和兼容狀態(tài)通道的智能合約有什么區(qū)別？本質(zhì)上可以歸結(jié)為以下事實(shí)：無論公共API的實(shí)現(xiàn)如何，我們都需要一種標(biāo)準(zhǔn)方法來與應(yīng)用程序的狀態(tài)轉(zhuǎn)換進(jìn)行交互。簡而言之，我們需要一個入口點(diǎn)函數(shù)來計(jì)算狀態(tài)轉(zhuǎn)換。

一個例子-井字游戲

假設(shè)我們要編寫一個井字游戲應(yīng)用程序。我們可能會編寫一個智能合約，該合約具有帶有placeX和placeO函數(shù)的公共API，并檢查msg.sender以驗(yàn)證是否有正確的參與者在行動。

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編寫的井字游戲智能合約示例。

將這個游戲建模為一個狀態(tài)機(jī)，我們可以看到在它們之間有5種狀態(tài)和2種有效的轉(zhuǎn)換類型。

井字游戲應(yīng)用程序的狀態(tài)機(jī)示例。 如果是X的回合，X可以采取行動贏得比賽，以平局結(jié)束比賽，或者只是放下棋子并將其傳遞給O進(jìn)行回合。

回到用于更新應(yīng)用程序狀態(tài)的標(biāo)準(zhǔn)接口的想法，我們想創(chuàng)建一個函數(shù)，該函數(shù)接受狀態(tài)機(jī)的某些先前狀態(tài)（例如X_TURN）以及可以采取的操作以達(dá)到新狀態(tài) （例如PLACE_X）。 有趣的是，這與當(dāng)今存在的某些常見Web框架（例如Redux）完全相同。 他們傾向于將這種功能稱為“reducer”。 因此，讓我們嘗試以這種方式編寫井字游戲應(yīng)用程序：

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） { 。.. }

}

一個井字游戲應(yīng)用程序，它具有一個用于處理PLACE_X和PLACE_O動作的reduce函數(shù)而不是多個名為placeX和placeO的函數(shù)。reducer功能將動作“分派”到helper函數(shù)。

有了這個，我們現(xiàn)在有了一種計(jì)算狀態(tài)更新的方法，可以通過一個公共接口——reduce接口對應(yīng)用程序進(jìn)行更新。在考慮必須保護(hù)狀態(tài)通道的攻擊類型時，這非常有用。

但是狀態(tài)通道合約中需要做什么呢？

當(dāng)然，狀態(tài)通道對象應(yīng)該使用應(yīng)用程序邏輯來確定轉(zhuǎn)換是否有效。核心狀態(tài)通道功能可以存在于通用協(xié)定中，該協(xié)定處理可能的各種攻擊情形，但會為其狀態(tài)機(jī)的特定轉(zhuǎn)換規(guī)則委派給應(yīng)用程序。

狀態(tài)通道可以使用App邏輯作為確定有效轉(zhuǎn)換的手段，但是根據(jù)App邏輯提供給它的信息來處理授權(quán)和解析邏輯本身。

有兩種主要情況需要處理。如果我們使用Alice和Bob相互交換消息的常見示例，則可以將它們構(gòu)造為：

1、如果Bob提交過時的狀態(tài)呢？

合約必須能夠?qū)崿F(xiàn)一個超時期，以便Alice有時間提交比Bob提交的狀態(tài)更新的狀態(tài)。如果Bob提交的狀態(tài)可以證明是超時的，那么Bob應(yīng)該受到懲罰。

2、如果Bob停止響應(yīng)怎么辦？

合約必須使Alice能夠提交她從Bob那里收到的最新簽名狀態(tài)，以便將她的錢取出（在超時期限過去之后）。在某些情況下，Alice可能會“采取行動”以改善應(yīng)用程序的狀態(tài)機(jī)，因此在這種情況下，她必須能夠使用應(yīng)用程序的reducer。

為此，合約需要公開一個基本的API。請注意，這實(shí)際上是處理爭議案件的API。狀態(tài)通道的用戶可以使用一組函數(shù)調(diào)用來確保他們正在簽名的鏈下狀態(tài)更新具有重要意義。

這個API大致包括：

· 創(chuàng)建爭議案件。

一方提交狀態(tài)的最新簽名副本，并可選地對應(yīng)用程序執(zhí)行操作，該操作將在邏輯上將狀態(tài)提升到下一個狀態(tài)。

· 進(jìn)行爭議。

一方通過對已提交的狀態(tài)采取行動來回應(yīng)另一方的爭議。

· 取消爭議。

雙方同意取消爭議并恢復(fù)正常。

資金存放在哪里？

這就是本文中描述的許多特性變得有用的地方。我們將這些資金放在一個通用的多簽名錢包中，并將其用作根據(jù)狀態(tài)通道的結(jié)果作出分配資金承諾的主要智能合約。

一個簡單的應(yīng)用程序使用狀態(tài)通道而不使用反事實(shí)實(shí)例化，而只是使用常規(guī)的智能合約引用。

這給了我們很多有益的好處。最好的方法之一是利用反事實(shí)實(shí)例化技術(shù)的能力，本文也對此進(jìn)行了詳細(xì)介紹。當(dāng)我們將其添加到組合中時，我們可以使?fàn)顟B(tài)通道合約和應(yīng)用程序邏輯合約保持鏈下狀態(tài)。

與上述相同的設(shè)置，但是這次狀態(tài)通道合約和應(yīng)用程序邏輯合同是反事實(shí)的-僅在發(fā)生糾紛時才需要在鏈上進(jìn)行部署。

設(shè)置之后，我們得到了另一個非常強(qiáng)大的特性：用于安裝和卸載應(yīng)用程序的零鏈上事務(wù)。

當(dāng)我們使用反事實(shí)時，添加和刪除應(yīng)用程序是免費(fèi)且即時的。

實(shí)際上，由于我們可以從多簽名錢包進(jìn)行無限次數(shù)的有條件轉(zhuǎn)賬，因此這些commitments可以用于任何數(shù)量的應(yīng)用程序。

下一步

在以后的帖子，講座和討論中，我們將概述對將用于合約層之上的軟件的愿景。要在生產(chǎn)環(huán)境中使用的狀態(tài)通道，將需要整個生態(tài)系統(tǒng)的大量協(xié)調(diào)。我們目前正在一些具體領(lǐng)域應(yīng)用，并希望與其他領(lǐng)域進(jìn)一步合作：

1. 標(biāo)準(zhǔn)化研究術(shù)語，分享見解，并在狀態(tài)通道和第2層縮放中跟進(jìn)其他有趣的研究問題。

2. 將廣義狀態(tài)信道模式集成到現(xiàn)有的狀態(tài)信道系統(tǒng)和基于非鏈?zhǔn)椒妒降膽?yīng)用程序。

3. 與web3框架合作，使鏈外關(guān)注點(diǎn)在開發(fā)人員api的未來開發(fā)中廣為人知。

4. 與錢包提供者一起工作，幫助提供清晰的協(xié)議規(guī)范和標(biāo)準(zhǔn)，說明狀態(tài)通道可以在其域中如何存在。