1. 首页
  2. 资讯
  3. 技术指南

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

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

shutterstock_1044056869-e1523904713468

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

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

但是,这类行为很多时候是徒劳的。我们必须要强制保证诚信,而且还要让欺骗的代价变得很高。这个框架已经考虑到了这点。

争端

在真实的行为可以发生之前,参与者就会将放置争端解决机制。这包含创建一个子通道合约。在我们的争端场景中,存在双向以太转移子通道。为了让事情看起来更简单, 我们把整个过程当做两个转账,而不是一个。

1.部署双向通道,
2.将资金从Multisig 转移到双向通道,
3.完成双向转账。

这两个转账已经签名了,但是还没有部署到区块链上。如果这样的需求产生,这件事就会发生。用户同样的设置,能够随着时间支持多个通道。防止重放攻击最好的方式就是线性的Multisig nonce。在几轮子状态通道的开放和关闭后,恶意的参与者能够通过允许的Multisig nonce,来部署错误的转账信息。为了防止这个,我们会在Lineup上固定这部分转账。

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

所以,整个准备的流程是:

1. 部署Lineup,
2. 有条件地部署双向通道,
3. 有条件地移动资金到双向通道,
4. 完成双向转账。

现在参与者能够信任地将资产转移到Multisig。对于有争议的情况,Lineup和Bidirectional合约都会部署到区块链上。然后各方都会根据他们的转账状态来更新Bidirectional合约的状态。毕竟,Bidirectional子通道会纷发这些资金,因此解决这个争端。

结论

不论完美和充满争议的解决方案都包含了。但是,如果有人看测试代码,他会发现状态管理是多么复杂。这就好像去遵循Interpreter的模式。因此,在下个迭代中,把每一笔交易都包装在某种Command函数中也不是一件好事。Interpreter然后解析Command中的内容,在部署到区块链上,或者在本地进行计算最终结果。在那个阶段,很容易提供基于这个架构的第三方API,那也会包含一个基于TCR的升级机制。

声明:登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。

发表评论

登录后才能评论