TMT观察网_独特视角观察TMT行业

對于擴容方案，狀態通道可以算是最容易實現的了。它可以完成小額支付，區塊鏈游戲和代幣兌換，確保交易所安全以及很多其他的事情。

廣義的狀態通道就是對于應用通道的統一化框架。可以讓系統構建的時候更加容易。只需要把邏輯合約加到框架上，就可以完成。而且更新是免費的。

現在我們有兩個非常有趣的問題出現了。其中一個是專注于支付通道，狀態通道的一個分支專注于支付。這個設計提供了和哈希時間鎖定的支付，即閃電網絡的整合。你真地需要這個來支付咖啡費用嗎？也許我們可以通過現在使用TCP/UDP/IP傳輸數據那樣，來進行貨幣轉賬。

另一個問題是就是通用性問題。我們現在有狀態通道系統了，并且想要升級一個子通道合約。用戶怎么才能相信一個新的合約呢？

廣義的狀態通道架構，是構建用戶間鏈下資產轉移的方式。人們可以很安全地進行轉賬，而不是使用同樣的區塊鏈轉賬。我們現在已經整理好代碼，并且添加了一些測試，現在可以來展示我們的框架部署。

代碼是在machinomy/mc2 數據庫。它是標準的合約部署，其中有相似的布局：/build, /contracts, /migrations以及其他代碼。其實，它是支付通道合約的一個分叉。主要內容是在 /contracts和/test的文件中。

狀態通道的構建首先要從Multisig合約的部署開始。這就說如果大家都同意，那么在區塊鏈上就能完成一筆轉賬。我們的Multisig合約只限于兩個人。對于復雜的案例，也了可以使用更加高級的多重簽名合約，Gnosis Safe。

Multisig合約有三種方式：

function doCall(address destination, uint256 value, bytes data, bytes senderSig, bytes receiverSig);function doDelegate(address destination, bytes data, bytes senderSig, bytes receiverSig);function isUnanimous(bytes32 _hash, bytes _senderSig, bytes _receiverSig) public view returns(bool);

doCall 會調用destination 地址。doDelegate會執行delegatecall。后者會用于從Multisig到子狀態合約的復雜資產轉移，就像同時將資金轉移給用戶。Multisig為轉賬邏輯使用獨立的合約。例如，DistributeToken合約自動將ERC20代幣轉賬給雙方。

合作案例

在一個成功案例中，參與者只需要這樣做：將資金從Multisig分發出去。在得到資產分布已經完成的共識時，轉賬就會進入Multisig來分發資金。合作型的測試案例就會按照以下流程來寫入代碼：

1．創建Multisig；

2.將資產轉移至Multisig；

3.對Multisig進行轉賬簽名，從而將資金轉出Multisig

4.執行合約

但是，這類行為很多時候是徒勞的。我們必須要強制保證誠信，而且還要讓欺騙的代價變得很高。這個框架已經考慮到了這點。

爭端

在真實的行為可以發生之前，參與者就會將放置爭端解決機制。這包含創建一個子通道合約。在我們的爭端場景中，存在雙向以太轉移子通道。為了讓事情看起來更簡單, 我們把整個過程當做兩個轉賬，而不是一個。

部署雙向通道，

將資金從Multisig 轉移到雙向通道，

完成雙向轉賬。

這兩個轉賬已經簽名了，但是還沒有部署到區塊鏈上。如果這樣的需求產生，這件事就會發生。用戶同樣的設置，能夠隨著時間支持多個通道。防止重放攻擊最好的方式就是線性的Multisig nonce。在幾輪子狀態通道的開放和關閉后，惡意的參與者能夠通過允許的Multisig nonce，來部署錯誤的轉賬信息。為了防止這個，我們會在Lineup上固定這部分轉賬。

它存儲了merkleRoot 的轉賬列表。然后，如果轉賬信息在merkleRoot 的列表上，有人就可以有條件地執行轉賬。

所以，整個準備的流程是：

部署Lineup，

有條件地部署雙向通道，

有條件地移動資金到雙向通道，

完成雙向轉賬。

現在參與者能夠信任地將資產轉移到Multisig。對于有爭議的情況，Lineup和Bidirectional合約都會部署到區塊鏈上。然后各方都會根據他們的轉賬狀態來更新Bidirectional合約的狀態。畢竟，Bidirectional子通道會紛發這些資金，因此解決這個爭端。

結論

不論完美和充滿爭議的解決方案都包含了。但是，如果有人看測試代碼，他會發現狀態管理是多么復雜。這就好像去遵循Interpreter的模式。因此，在下個迭代中，把每一筆交易都包裝在某種Command函數中也不是一件好事。Interpreter然后解析Command中的內容，在部署到區塊鏈上，或者在本地進行計算最終結果。在那個階段，很容易提供基于這個架構的第三方API，那也會包含一個基于TCR的升級機制。