電子發(fā)燒友App
頻繁進行交易以推進以太坊虛擬機是不必要的昂貴和緩慢。今天大多數(shù)使用以太坊的應用程序都通過更新鏈上合約的存儲變量來工作，用戶為此支付交易費用并花長時間等待區(qū)塊確認。
為了使用應用程序，我們強迫用戶手動將數(shù)據(jù)庫更新提交給世界上最安全，分散和無信任的環(huán)境。
通過將一些功能轉(zhuǎn)移到客戶端代碼上，而不是單獨依靠以太坊為我們做所有事情，我們可以編寫完全安全的應用程序。通常我們將這些稱為“l(fā)ayer2”技術。
大多數(shù)“以太坊應用都不可伸縮！”的敘述并不是因為底層的區(qū)塊鏈不合適。更準確地說，這是因為開發(fā)人員很難使用狀態(tài)通道等Layer2層技術。我們需要在以太坊之上擁有更好的開發(fā)人員工具，這將使以高效方式編寫應用程序變得更加容易。
Counterfactual是一個開源項目，正致力于解決這個問題。我們的目標是使開發(fā)人員易于使用以太坊上的狀態(tài)通道來構建應用程序。
為什么現(xiàn)在很難使用狀態(tài)通道？
今天，如果開發(fā)人員希望使用以太坊編寫分布式應用程序，他們可能要實現(xiàn)以下每一項：
1. 公共API-合約上的public或extenal函數(shù)
2. 授權邏輯（Authorization logic）-通常通過檢查msg.sender
3. 解決邏輯（Resolution logic）-決定如何分配資金
在大多數(shù)情況下，這是開發(fā)人員在設計分布式應用程序時要考慮的一個很好的抽象層次。 去年，我們已經(jīng)看到成千上萬的開發(fā)人員使用這種模式使用以太坊構建應用程序，所以最好不要徹底改變它。
從這種角度考慮狀態(tài)通道會給應用程序開發(fā)人員產(chǎn)生更多共鳴。在大多數(shù)情況下，嘗試設計狀態(tài)通道應用程序時，您會遇到各種障礙，例如：
1. 不清楚應該如何編寫公共API，因為您不再簽署Ethereum事務，而是簽署通用狀態(tài)對象
2. 授權邏輯（Authorization logic）要求狀態(tài)通道的每個用戶為每個更新簽署一個對象，并使用ecrecover驗證這些簽名。
3. 由于每次提交新狀態(tài)時都有一個內(nèi)置的“挑戰(zhàn)”或“爭議”階段，因此現(xiàn)在的解決邏輯（Resolution logic）更加復雜。
最糟糕的是，對于整個狀態(tài)通道協(xié)議，沒有任何既定的標準，這使得框架或公共庫很難出現(xiàn)。
我們可以做些什么來簡化它？
使狀態(tài)通道應用程序更易于推理的最重要的第一步是標準化通用狀態(tài)通道功能，使狀態(tài)通道解析邏輯與應用程序邏輯完全分離以與狀態(tài)通道兼容的格式編寫應用程序應該盡可能簡單，理想情況下，應該感覺像是在編寫常規(guī)的智能合約代碼。
實現(xiàn)此目的的一種方法是將應用程序建模為狀態(tài)機。強制移動游戲框架就是其中的一個示例，通常EVM已基于狀態(tài)機的基本思想構建，狀態(tài)機基于事務執(zhí)行來更新每個區(qū)塊的狀態(tài)。
那么，普通智能合約和兼容狀態(tài)通道的智能合約有什么區(qū)別？本質(zhì)上可以歸結為以下事實：無論公共API的實現(xiàn)如何，我們都需要一種標準方法來與應用程序的狀態(tài)轉(zhuǎn)換進行交互。簡而言之，我們需要一個入口點函數(shù)來計算狀態(tài)轉(zhuǎn)換。
一個例子-井字游戲
假設我們要編寫一個井字游戲應用程序。我們可能會編寫一個智能合約，該合約具有帶有placeX和placeO函數(shù)的公共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編寫的井字游戲智能合約示例。
將這個游戲建模為一個狀態(tài)機，我們可以看到在它們之間有5種狀態(tài)和2種有效的轉(zhuǎn)換類型。
井字游戲應用程序的狀態(tài)機示例。 如果是X的回合，X可以采取行動贏得比賽，以平局結束比賽，或者只是放下棋子并將其傳遞給O進行回合。
回到用于更新應用程序狀態(tài)的標準接口的想法，我們想創(chuàng)建一個函數(shù)，該函數(shù)接受狀態(tài)機的某些先前狀態(tài)（例如X_TURN）以及可以采取的操作以達到新狀態(tài) （例如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函數(shù)而不是多個名為placeX和placeO的函數(shù)。reducer功能將動作“分派”到helper函數(shù)。
有了這個，我們現(xiàn)在有了一種計算狀態(tài)更新的方法，可以通過一個公共接口——reduce接口對應用程序進行更新。在考慮必須保護狀態(tài)通道的攻擊類型時，這非常有用。
但是狀態(tài)通道合約中需要做什么呢？
當然，狀態(tài)通道對象應該使用應用程序邏輯來確定轉(zhuǎn)換是否有效。核心狀態(tài)通道功能可以存在于通用協(xié)定中，該協(xié)定處理可能的各種攻擊情形，但會為其狀態(tài)機的特定轉(zhuǎn)換規(guī)則委派給應用程序。
狀態(tài)通道可以使用App邏輯作為確定有效轉(zhuǎn)換的手段，但是根據(jù)App邏輯提供給它的信息來處理授權和解析邏輯本身。
有兩種主要情況需要處理。如果我們使用Alice和Bob相互交換消息的常見示例，則可以將它們構造為：
1、如果Bob提交過時的狀態(tài)呢？
合約必須能夠?qū)崿F(xiàn)一個超時期，以便Alice有時間提交比Bob提交的狀態(tài)更新的狀態(tài)。如果Bob提交的狀態(tài)可以證明是超時的，那么Bob應該受到懲罰。
2、如果Bob停止響應怎么辦？
合約必須使Alice能夠提交她從Bob那里收到的最新簽名狀態(tài)，以便將她的錢取出（在超時期限過去之后）。在某些情況下，Alice可能會“采取行動”以改善應用程序的狀態(tài)機，因此在這種情況下，她必須能夠使用應用程序的reducer。
為此，合約需要公開一個基本的API。請注意，這實際上是處理爭議案件的API。狀態(tài)通道的用戶可以使用一組函數(shù)調(diào)用來確保他們正在簽名的鏈下狀態(tài)更新具有重要意義。
這個API大致包括：
· 創(chuàng)建爭議案件。
一方提交狀態(tài)的最新簽名副本，并可選地對應用程序執(zhí)行操作，該操作將在邏輯上將狀態(tài)提升到下一個狀態(tài)。
· 進行爭議。
一方通過對已提交的狀態(tài)采取行動來回應另一方的爭議。
· 取消爭議。
雙方同意取消爭議并恢復正常。
資金存放在哪里？
這就是本文中描述的許多特性變得有用的地方。我們將這些資金放在一個通用的多簽名錢包中，并將其用作根據(jù)狀態(tài)通道的結果作出分配資金承諾的主要智能合約。
一個簡單的應用程序使用狀態(tài)通道而不使用反事實實例化，而只是使用常規(guī)的智能合約引用。
這給了我們很多有益的好處。最好的方法之一是利用反事實實例化技術的能力，本文也對此進行了詳細介紹。當我們將其添加到組合中時，我們可以使狀態(tài)通道合約和應用程序邏輯合約保持鏈下狀態(tài)。
與上述相同的設置，但是這次狀態(tài)通道合約和應用程序邏輯合同是反事實的-僅在發(fā)生糾紛時才需要在鏈上進行部署。
設置之后，我們得到了另一個非常強大的特性：用于安裝和卸載應用程序的零鏈上事務。
當我們使用反事實時，添加和刪除應用程序是免費且即時的。
實際上，由于我們可以從多簽名錢包進行無限次數(shù)的有條件轉(zhuǎn)賬，因此這些commitments可以用于任何數(shù)量的應用程序。
下一步
在以后的帖子，講座和討論中，我們將概述對將用于合約層之上的軟件的愿景。要在生產(chǎn)環(huán)境中使用的狀態(tài)通道，將需要整個生態(tài)系統(tǒng)的大量協(xié)調(diào)。我們目前正在一些具體領域應用，并希望與其他領域進一步合作：
1. 標準化研究術語，分享見解，并在狀態(tài)通道和第2層縮放中跟進其他有趣的研究問題。
2. 將廣義狀態(tài)信道模式集成到現(xiàn)有的狀態(tài)信道系統(tǒng)和基于非鏈式范式的應用程序。
3. 與web3框架合作，使鏈外關注點在開發(fā)人員api的未來開發(fā)中廣為人知。
4. 與錢包提供者一起工作，幫助提供清晰的協(xié)議規(guī)范和標準，說明狀態(tài)通道可以在其域中如何存在。
責任編輯；zl
工商網(wǎng)監(jiān)
評論