如何在以太坊上使用状态通道构建应用程序

推进以太坊虚拟机的频繁交易既昂贵又缓慢。 如今，大多数使用以太坊的应用程序都通过更新链上合约中存储的变量来工作，用户为此支付交易费用并长时间等待区块确认。

为了使用该应用程序，我们强制用户手动将数据库更新提交到世界上最安全、去中心化和无信任的环境中。

通过将一些功能卸载到客户端代码，而不是仅仅依靠以太坊为我们做所有事情，我们可以编写完全安全的应用程序。 我们通常将这些称为“layer2”技术。

大多数“以太坊应用程序无法扩展！” 叙述不是因为底层区块链不合适。 更准确地说，这是因为开发者很难使用状态通道等 Layer 2 技术。 我们需要在以太坊之上拥有更好的开发人员工具，这将使以高效的方式编写应用程序变得更加容易。

Counterfactual 是一个开源项目，致力于解决这个问题。 我们的目标是让开发人员可以轻松地在以太坊上使用状态通道构建应用程序。

为什么现在很难使用状态通道？

今天，如果开发人员希望使用以太坊编写分布式应用程序，他们可以实现以下各项：

1. 公共API——合约的公共或扩展功能

2.授权逻辑——通常通过检查msg.sender

3.决议逻辑——决定如何分配资金

在大多数情况下，这是开发人员在设计分布式应用程序时要考虑的良好抽象级别。 去年以太坊上多少应用，我们已经看到成千上万的开发人员使用这种模型使用以太坊构建应用程序，因此最好不要对其进行大修。

从这个角度考虑状态通道会引起应用程序开发人员的更多共鸣。 大多数情况下，在尝试设计状态通道应用程序时，您会遇到各种障碍，例如：

1. 不清楚公共 API 应该如何编写，因为你不再签署以太坊交易，而是通用状态对象

2.授权逻辑要求状态通道的每个用户为每次更新签署一个对象，并使用ecrecover验证这些签名。

3. 由于每次提交新状态时都内置了“挑战”或“争议”阶段，因此解决逻辑（Resolution logic）现在更加复杂。

最糟糕的是，整个状态通道协议没有任何既定标准，这使得框架或通用库很难出现。

我们可以做些什么来简化它？

使状态通道应用程序更易于推理的最重要的第一步是标准化公共状态通道功能，以便状态通道解析逻辑与应用程序逻辑完全分离以与状态通道兼容的格式编写应用程序应该尽可能简单，理想情况下接下来，感觉就像编写常规智能合约代码一样。

一种方法是将应用程序建模为状态机。 这方面的一个例子是强制性移动游戏框架，通常 EVM 是基于状态机的基本思想构建的，它根据交易执行更新每个区块的状态。

那么，普通的智能合约和状态通道兼容的智能合约有什么区别呢？ 它本质上归结为这样一个事实，即无论公共 API 的实现如何，我们都需要一种标准的方式来与应用程序的状态转换进行交互。 简而言之，我们需要一个入口点函数来计算状态转换。

一个例子 - 井字游戏

假设我们要编写一个井字应用程序。 我们可能会编写一个智能合约，它有一个带有 placeX 和 placeO 函数的公共 API，并检查 msg.sender 以验证正确的参与者正在行动。

合同 TICTacToe {

地址播放器1；

地址播放器2；

uint8[3][3]板；

uint8 下一回合；

函数 placeX(uint8 x, uint8 y) public {

if (msg.sender == player1) { . . .}

}

函数 placeO(uint8 x, uint8 y) public {

if (msg.sender == player2) { . . .}

}

}

用 Solidity 编写的 Tic Tac Toe 智能合约示例。

将这个游戏建模为状态机，我们可以看到有 5 个状态和它们之间的 2 个有效转换类型。

井字游戏应用程序的示例状态机。 如果轮到 X，X 可以采取行动赢得比赛，以平局结束比赛，或者只是放下棋子并将其交给 O 轮到他。

回到更新应用程序状态的标准接口的想法，我们想要创建一个函数，它接受状态机的一些先前状态（例如 X_TURN）和可以采取的达到新状态的动作（例如 PLACE_X ). 有趣的是，这与当今存在的一些常见 Web 框架如 Redux 完全相同。 他们倾向于将这种功能称为“reducer”。 因此，让我们尝试以这种方式编写井字游戏应用程序：

合同井字棋{

枚举 ActionTypes { PLACE_X, PLACE_O }

枚举 StateTypes { X_TURN, O_TURN, X_WIN, O_WIN, DRAW }

结构动作{

动作类型动作类型；

uint8 x；

uint8 是；

}

结构 AppState {

状态类型 状态类型；

地址播放器1；

地址播放器2；

uint8[3][3]板；

uint8 下一回合；

}

功能减少（AppState状态，动作动作）

上市

看法

回报（应用状态）

{

如果（action.actionType == ActionTypes.PLACE_X）{

要求（状态。stateType == StateTypes。X_TURN）；

返回 onPlaceX（状态，动作）；

} else if (action.actionType == ActionTypes.PLACE_O) {

要求（状态。stateType == StateTypes。O_TURN）；

返回 onPlaceO（状态，动作）；

} 别的 {

revert("无效的操作类型");

}

}

函数 onPlaceX(AppState state, Action action) internal returns (AppState) { . . .}

函数 onPlaceO(AppState state, Action action) internal returns (AppState) { . . .}

}

一个井字游戏应用程序，它具有一个用于处理 PLACE_X 和 PLACE_O 操作的 reduce 函数，而不是多个名为 placeX 和 placeO 的函数。 reducer 函数将操作“分派”给辅助函数。

有了这个，我们现在有一种方法可以通过一个通用接口——reduce 接口来计算应用程序的状态更新。 在考虑必须保护状态通道的攻击类型时，这非常有用。

但是状态通道合约需要做什么呢？

当然，状态通道对象应该使用应用程序逻辑来确定转换是否有效。 核心状态通道功能可以存在于处理可能的各种攻击场景的通用合约中，但将其状态机的特定转换规则委托给应用程序。

状态通道可以使用 App 逻辑作为确定有效转换的方法，但会根据 App 逻辑提供给它的信息自行处理授权和解析逻辑。

有两种主要情况需要处理。 如果我们使用 Alice 和 Bob 相互交换消息的常见示例，它们可以构造为：

1. 如果 Bob 提交了一个过时的状态怎么办？

合约必须能够实现超时期限，以便 Alice 有时间提交比 Bob 提交的更新的状态。 如果 Bob 提交的状态能够被证明超时以太坊上多少应用，那么 Bob 应该受到惩罚。

2. 如果 Bob 停止响应怎么办？

合约必须允许 Alice 提交她从 Bob 收到的最新签名状态，以便取出她的钱（在超时期限结束后）。 在某些情况下，Alice 可能会“采取行动”来改进应用程序的状态机，因此在这种情况下，她必须能够使用应用程序的 reducer。

为此，合约需要公开一个基本的 API。 请注意，这实际上是一个处理争议案例的 API。 状态通道的用户可以使用一组函数调用来确保他们签署的链下状态更新是重要的。

这个API大致包括：

· 创建争议案例。

一方提交状态的最新签名副本，并可选择对应用程序执行操作，逻辑上将状态推进到下一个状态。

· 处理纠纷。

一方通过对承诺状态采取行动来回应另一方的争议。

· 争议取消。

双方同意取消争议，恢复正常。

资金存放在哪里？

这就是本文中描述的许多功能派上用场的地方。 我们将这些资金放在一个通用的多重签名钱包中，并将其作为主要智能合约，根据状态通道的结果做出分配资金的承诺。

使用状态通道的简单应用程序不使用反事实实例化，而只是常规智能合约引用。

这给我们带来了很多有益的好处。 执行此操作的最佳方法之一是利用反事实实例化技术的功能，本文也对此进行了详细介绍。 当我们将其添加到组合中时，我们可以将状态通道合约和应用程序逻辑合约保持在链下。

与上面的设置相同，但这次状态通道合约和应用程序逻辑合约是反事实的——只需要在发生争议时部署在链上。

设置完成后，我们将获得另一个非常强大的功能：用于安装和卸载应用程序的零链上交易。

当我们使用反事实时，添加和删除应用程序是免费且即时的。

事实上，由于我们可以从多重签名钱包进行无限次的有条件转账，因此这些承诺可以用于任何数量的应用程序。

下一步

在未来的帖子、谈话和讨论中，我们将概述我们对将在合约层之上使用的软件的愿景。 对于要在生产中使用的状态通道，需要整个生态系统进行大量协调。 我们目前正在研究一些特定领域的应用程序，并希望与其他人进一步合作：

1. 标准化研究术语，分享见解，并跟进状态通道和第 2 层扩展中其他有趣的研究问题。

2. 将广义状态通道模式集成到现有的基于链下范式的状态通道系统和应用中。

3. 配合web3框架，让off-chain concerns在未来的开发者api开发中广为人知。

4. 与钱包供应商合作，帮助提供明确的协议规范和标准，说明状态通道如何在他们的领域中存在。