每晚八点，我们在社区分享知识，等你。
NervosFans 微信公号：Nervosfans
入群请加乐乐微信：sensus113 美果大冰微信：xj73226
备注入群，谢谢！
Hello everyone，今天来介绍一个L4过去几个月一直在研究的通用状态通道框架。
Medium上发布了一则面向非技术人群的介绍性博文：https://medium.com/statechannels/counterfactual-generalized-state-channels-on-ethereum-d38a36d25fc6
技术paper见：https://counterfactual.com/statechannels.
本文主要对通用状态通道比较创新的地方做些说明，特别呼应下论坛上进行的各类通道有关的讨论。希望本文能够与现有研究进行比较，并为讨论提供一个良好的起点。
时延
有关通道的讨论中，重点专注的是其作为提高交易吞吐量的一种手段，但我们认为降低时延同样有诸多益处。通道建立之后，其中进行的交互仅凭借链下的消息交换，因此实现交互的即时完成，我们的方案中提供了类似的网络响应时间。这就与非通道化（比方说直接在以太坊或Plasma上）交互不同，原因是非通道化交互通常必须等待“确认”（或者其他一些终结度量，比如Casper中的最终块）。通道是唯一能提供即时finality保证的技术。
特殊用途通道、通用状态通道、反事实实例化及多重签名
依照我们自己的理解，特殊用途状态通道运行特定应用程序（比方说支付通道或国际象棋通道），且须部署链上交易才能使用特定应用程序。相反，通用状态通道指将新应用程序与功能安装到现有通道而无需任何链上交易，且安装新应用程序的用户可体验安装的即时finality。
通用状态通道中，参与方仅通过消息交换即可‘进入’合约（即受合约条款约束）。我们把被合约约束的过程称为“合约的反事实实例化”。
详情见技术文件4.1.3、5.3节。
4.1.3 通用状态通道。我们通过引入反事实实例化以及基于合约的设计框架等新技术对现有状态通进行了通用处理。与当前的特殊用途状态通道相比，终端用户能感受到最明显的区别在于新功能的通道化安装，因此通用状态通道便宜（无交易）、即时且保护隐私。Perun[24]独立开发并实施了类似的“链下实例化”（4.3.4节中有讨论）
5.3 反事实实例
以太坊借助智能合约为开发人员提供通用的计算平台。类似地，状态通道中的参与者应该也可以借助智能合约的状态通道内反事实实例化，在没有任何链上操作的情况下将新功能（譬如通道建立后开发的游戏）安装到状态通道。反事实实例化之后，用户受反事实实例化合约条款的约束。
一般来说，链上智能合约只有在控制有价值的链上状态时才有用。由于并未链上部署反事实实例化的合约，因此不直接对链上资产有所有权。参与者必须向状态押金持有人签署承诺，以便执行过程能以某种方式使用反事实实例化合约。因此，部分状态押金被指定给反事实实例化合约。作为执行杠杆的一部分，参与者必须能够单方面实例化链上的反事实实例化合约，使合约对如何支出状态存款能够进行控制。
多重签名
这个反事实通道构造中，单个状态通道的唯一链上组件是多重签名钱包。由于反事实实例化，这是可行的，并具有隐私和可升级的优势。
详情见技术文件5.4节。
5.4 链上功能与状态最小化
反事实实例化支持链下实例化特殊用途智能合约，同时也可以将其抽象化为一种将功能与状态移至链下的技术。因此，还可以反事实实例化争议解决功能（譬如挑战/超时）。状态押金持有人可以是n/n多重签名钱包，且必须为每个附加支付通道链上部署的唯一组件。我们认为这是链上功能和状态的底线，状态押金持有人必须是实施操作以全体一致为基础的实体，而多重签名钱包恰好有效满足这一条件。因此，本文最为重要的一个见解（之一）可归纳为：
足够强大的多重签名钱包完全可以胜任状态押金持有人的角色。
多重签名钱包方案不仅可行，更提供了两方面的好处：
1. 隐私。状态通道参与人可选择不分享自己签署的承诺，这种情况下，外部观察员只能看到链上多重签名钱包；想要隐藏状态通道的参与人可以使用“所有链上多重签名钱包集”作匿名集。
2. 可升级性。争议解决代码中，或者多重签名钱包外的任意状态通道代码中发现错误时，可双方合作在链下进行替换。
使用标准多重签名钱包作为状态押金持有人还有个其他的好处是，任何使用多重签名钱包支持所有权的资产都可以由状态通道自动控制。譬如，类似“设置ENS名称的权利”之类的抽象资产可以放在状态押金中。
反事实术语
反事实术语非新功能，而是一种考虑状态通道及其他L2技术时有效的思路。对于任何链上操作X，认为“反事实X”有效的前提是：
1. X可在链上发生，但没有
2. 执行机制允许任何参与者单方面使X发生
3. 参与者的活动以X已发生的假设为前提
即便在现有支付通道中，这个术语也非常有用。譬如，X可能是“从支付通道智能合约转出4ETH到Alice的账户，6ETH到Bob的账户”，则反事实X就是‘双方都有最新签署的副本，Alice的余额记为4，Bob记为6’这个状态。
我们使用这个术语来讨论反事实实例化、反事实状态、反事实状态迁移和反事实对象。该定义也适用于Plasma的相关讨论。
面向对象
通用状态通道可以同时运行多个应用程序或同一应用程序的多个实例。具体来说，是通过“面向对象的方法”将状态与功能结合，这一点类似以太坊合约。
详情见技术文件5.4、5.7节
5.7 面向对象的方法
我们将状态通道组织方法描述为反事实对象，每个反事实对象都包含自己的功能和反事实状态。
5.7.1 有条件支付。我们提倡使用有条件支付反事实对象对支付逻辑和应用逻辑进行分离。有条件支付反事实对象具有观察另一个反事实对象的功能（通过解析反地址并执行消息调用），并根据结果支付指定的状态押金。被观察对象实现特定用途功能，且多个有条件支付对象可以观察到相同的反事实对象（比如，MKR和REP的原子交换中，MKR和REP的反事实支付对象应该观察相同的对象）。这种设计有两个优点：
1.局部风险。假设有条件支付对象中没有其他错误，应用程序逻辑中的软件错误只会将指定给有条件支付对象的值置于风险中。这么做是很有用的，原因是支付逻辑会受到严格审查，写出数量与种类更多的应用逻辑，且应尽可能地控制住其中的错误。
2.无限制状态押金。多重签名钱包能持有的任何东西都可以作为状态押金指定给有条件付款的反事实对象。假设未来提出了一个ERC2000规范，代表可替代通证，但与ERC20不兼容；现有用户完全可以使用ERC2000通证作状态押金。
5.7.2 即时提现与充值。面向对象的方法支持即时提现和充值，意思是附加状态可以存入（链上）通道或提出，无需挑战期。比方说即时提现：首先，将部分ETH指定给一个反事实对象，（反事实对象的）状态依赖于多重签名钱包余额；然后，提现交易以原子方式将资金从状态通道中移出并减少指定给状态通道内提现接收方的余额，同时充值交易以原子方式将资金转移到状态通道并增加指定给（通道）资助者的余额。
图7：典型状态通道的结构。实线箭头表示“依赖”关系，虚线箭头表示“观察”关系。
5.7.3 优势。我们相信这种面向对象的方法通过以下优势实现模块性及灵活性。
1. 功能的可组合性。单个反事实对象可在状态通道中以多种方式相互“插入”。譬如，扑克游戏反事实对象编写完毕后，可以在有任意类型实体组织（只需有适当类型的有条件支付通道查看其），任意随机源（让扑克对象查看随机游戏反事实对象）的状态通道中使用。应用编写者只需指定扑克游戏规则即可，可以不精通ERC20通证界面或随机游戏。
2. 重复使用链上设计技术。由于以太坊状态也是以面向对象的方式组织的（将功能和状态结合的智能合约），因此对EVM进行了针对性的优化，其实开发者可以从这种链上应用的设计技术中受益。譬如，常见的技术是让广泛使用的合约通过代理契约来共享功能（而非状态），那么状态通道中也可以使用完全相同的技术。
2. 争议Merkel树。Alice和Bob需要在链上对象棋游戏提出异议时，没有理由拖无关的原子交换对象上链。如此，还通过对撤回到有条件支付通道的内容进行限制来控制应用程序逻辑（错误等）中的风险。
未完待续。
https://ethresear.ch/t/counterfactual-generalized-state-channels/2223
网友评论