代码解析！如何构建广义状态通道

广义的状态通道就是对于应用通道的统一化框架。可以让系统构建的时候更加容易。只需要把逻辑合约加到框架上，就可以完成。而且更新是免费的。

对于扩容方案，状态通道可以算是最容易实现的了。它可以完成小额支付，区块链游戏和代币兑换，确保交易所安全以及很多其他的事情。

广义的状态通道就是对于应用通道的统一化框架。可以让系统构建的时候更加容易。只需要把逻辑合约加到框架上，就可以完成。而且更新是免费的。

现在我们有两个非常有趣的问题出现了。其中一个是专注于支付通道，状态通道的一个分支专注于支付。这个设计提供了和哈希时间锁定的支付，即闪电网络的整合。你真地需要这个来支付咖啡费用吗？也许我们可以通过现在使用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的升级机制。