在上一期技术视点中，我们分析了 CounterFactual 状态通道的定义，并从中总结出：等价性、公平性和一致性等属性。接下来，我们继续分析 CF 状态通道的三个定义，思考 CounterFactual 状态通道的应用边界。

01 CF 状态通道定义分析

第一个定义中的等价性要求。由于等价性具备双向的特征，状态通道内智能合约的执行环境必须是状态通道和区块链的交集。

这一点要求：

1. 状态通道内所有操作 X 的输入信息只能来自操作 X 本身

对应的智能合约只能依赖于智能合约内部状态，而不可以依赖于任何区块链相关的信息（比如：区块链高度和区块时间等）。

同时要求：在创建和初始化 CF 状态通道时，必须完成相关依赖信息的初始化。因为 CF 状态通道运行过程独立于区块链，由于区块链上智能合约的状态可能随时变化，CF 状态通道无法和链上交易一样锚定和访问链上任意数据，而只能访问链上状态中的不可变数据。

2. 区块链和 CF 状态通道内对于操作 X 的处理方式必须一致

这是软件工程中需要特别注意的一点。由于智能合约平台可能存在缺陷和区块链软件的历史难以篡改，区块链平台只能采用分叉的方式升级平台软件，这将会给 CF 状态通道带来一些小麻烦。在区块链平台软件升级过程中，必须细心处理，或采用即时关闭 CF 状态通道的运维处理方式，以保证 CF 状态通道与链上的等价性。

第二个定义中的公平性要求。在 CF 状态通道中的每个操作引起的状态更新对于所有参与人都必须可见和可验证。第一点首先定义 CF 状态通道为参与者固定，并且参与人的数目相对较少。因此，CF 状态通道不是通过区块链中 permissionless 方式通过大量节点验证实现 trustless，而是通过所有参与人自己完成每个操作的状态更新的独立验证，通过参与人全部参与验证的方式实现 trustless。

这一点要求所有参与 CF 状态通道的用户必须自己运行状态通道验证服务，相比当前区块链用户要求略有提高，但是状态通道智能合约通常计算量很小，可以通过增强当前的区块链客户端程序实现。

第三个定义中的一致性和终局性要求。CF 状态通道中的所有操作必须是一致的和即时终局的。在 CF 状态通道设计中，任何违反协议的用户行为都可以被惩罚，因此状态通道中的任何状态更新需要得到所有参与者的共同签名，以实现即时终局性。这一点要求所有参与者必须保持在线状态，以维护状态通道的运行。这一点对于简单应用或者短时应用不会有太大影响，但是对于复杂的涉及较多参与者的应用或者运行时间较长的应用，将不得不采用类似代理节点或者守护节点的方式运行。

虽然我们目前只对 CF 状态通道的定义做出一些分析，但可以总结出 CF 状态通道对其运行的智能合约和对状态通道参与者的要求。基于此，区块链应用开发者可以判断自己的应用是否更适合于 CF 状态通道的链外运行方式。

02 CF 状态通道带给我们什么

不止如此，CF 状态通道虽然是一个区块链链外扩容的解决方案，我们更应该学习其中的设计方法。首先，从 CF 状态通道的协议中，我们可以清晰的看到 crypto-economics 系统设计要素。更重要的是，CounterFactual 让我们看到了一种新的密码学应用方式。从更大的角度来看，每个区块链可以认为是现实世界的一个 CF 状态通道，所有参与到区块链的人在现实世界中锁定资产，参与到区块链网络的建设和验证；从更小的角度看，如何设计区块链应用以更好地将区块链和业务需求更好地融合在一起，甚至基于 CounterFactual 的思路有没有全新的业务模式？

03 后记

CF 状态通道设计是一个非常具有启发性的设计，带给我们一种全新的区块链系统设计方法。在以后的本体技术视点中，我们将对 CounterFactual 的设计思想进一步推广，和大家一起思考 CounterFactual 给其它区块链设计带来的变化。

来源：本体Ontology