对于容量扩展方案，状态通道可以视为最容易实现的。它可以完成小额支付，区块链游戏和代币交换，确保安全的交流和其他许多事情。

通用状态通道是应用程序通道的统一框架。它可以使系统构建更容易。只要把逻辑契约加到框架里，就可以完成了。而且更新是免费的。

现在我们有两个非常有趣的问题。其中一个侧重于支付通道，一个状态通道分支侧重于支付。这个设计提供了用哈希时间锁定的支付，也就是闪电网的集成。你真的需要这个来付咖啡钱吗？也许蓑衣网小编2022我们可以通过使用TCP/UDP/IP传输数据来转移资金。

另一个问题是普遍性。现在我们有了一个状态渠道系统，我们想升级一个子渠道合同。用户如何信任一份新合同？

广义状态通道架构，是构建用户之间链下资产转移的方式。人们可以安全地转移资金，而不是使用同一个区块链。既然我们已经整理了代码并添加了一些测试，现在我们可以展示我们的框架部署了。

代码在machinomy/mc2数据库中。这是一个标准的合约部署，具有类似的布局：/build、/contracts、/migrations和其他代码。实际上是支付通道合约的一个分叉。主要内容在/contracts和/test的文件中。

状态通道的建设首先要从Multisig合同的部署开始。这意味着如果每个人都同意，那么转会就可以在区块链完成。我们的多份合同仅限于两个人。对于复杂的情况，还可以使用更高级的多重签名契约Gnosis Safe。

Multisig契约有三种方式：

函数do调用(address destination，uint256value，bytes data，bytes sender sig，bytes receiver SIG)；函数doDelegate(地址目的地，字节数据，字节发蓑衣网小编2022 送器Sig，字节接收器SIG)；函数isUnanimous(bytes32 _hash，bytes _senderSig，bytes _receiverSig)公共视图返回(bool)；

doCall将调用目的地址。DoDelegate将执行delegatecall。后者将用于从Multisig到子状态契约的复杂资产转移，就像同时向用户转移资金一样。Multisig使用一个独立的契约作为传输逻辑。例如，DistributeToken合约自动向双方转让ERC20代币。

合作案例

在一个成功的案例中，参与者只需要这样做：从Multisig分发资金。同意资产分配完成后，转账将进入Multisig进行资金分配。协同测试用例将按照以下流程写入代码：

1。创建Multisig；2.将资产转移到Multisig；3.签署Multisig转账，以便将资金转出Multisig4。执行契约

然而这种行为往往是徒劳的。我们必须加强诚信保证，让作弊的成本非常高。这个框架已经考虑到了这一点。

争议

在真正的行为能够发生之前，参与者将放置一个争议解决机制。这包括创建子渠道合同。在我们的争议场景中，有一个双向以太网传输子通道。为了使事情看起来更简单，我们将整个过程视为两次转移，而不是一次。

1。部署双向通道，2。将资金从Multisig转移到双向渠道，以及3 .完成双向转移。

这两项转让已经签署，但尚未部署到区块链。如果出现这样的需求，就会出现这种情况。随着时间的推移，相同设置的用户可以支持多个频道。防止重放攻击的最好方法是线性多重签名随机数。经过几轮状态通道的打开和关闭，恶意参与者可以通过允许的multisignnonce部署错误的传输信息。为了防止这一点，我们将修复阵容转移的这一部分。

它存储了merkleRoot的转移列表。然后，如果转移信息在merkleRoot的列表上，有人可以有条件地执行转移。

所以，整个准备过程是：

1。部署阵容，2。有条件部署双向通道，3。有条件地将资金向双向渠道转移；4 蓑衣网小编2022.完成双向转移。

现在，参与者可以通过信托将资产转移到Multisig。对于有争议的案件，阵容和双向合同都将部署到区块链。然后，各方将根据其转移状态更新双向合同的状态。毕竟，双向子渠道将分配这些资金，因此解决这一争端。

结论

完美的和有争议的解决方案都包括在内。但是，如果有人查看测试代码，他会发现状态管理是多么复杂。这就像遵循口译员的模式。所以，在下一次迭代中，把每一个事务都包装在某种命令函数中，并不是一件好事。解释器然后解析命令中的内容，然后将其部署到区块链，或者在本地计算最终结果。在那个阶段，很容易提供一个基于这个架构的第三方API，它也会包含一个基于TCR的升级机制。