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