学习状态通道，Part-4：账本通道和虚拟通道

Part-1：支付通道
Part-2：App 定制型状态通道
Part-3：多跳交易/中心辐射通道

在开始读本博文之前，我建议你先读中心辐射支付通道（译者注：即同系列 Part-3），因为我们要用到其中的知识。

-我真的不知道该把这张图放在哪儿...-

读了这篇博文后，你会理解如何在中心辐射拓扑的两个节点之间创建一个虚拟通道，然后两个节点就能独立于这个拓扑结构进行通信。下图红色虚线就是虚拟通道的例子。

-红线表示虚拟通道-

账本通道

虚拟通道的实现有赖于账本通道。账本通道是双向支付通道的另一种说法。在下面的例子中，我们有一个 Alice 和 Bob 之间的账本通道，通道中 Alice 持有 5ETH，Bob 持有 3ETH。

打开一个虚拟通道

要打开一个虚拟通道，两个节点必须都与同一个连接点（中心）开通账本通道。（下图中）Ingrid 就是这个共同连接/中心，他分别和 Alice、Bob j建立了账本通道 y 和 z。下面我们展示了 Alice 和 Bob 之间的虚拟通道 X 会有的样子—— Alice 将持有 5ETH，Bob 将持有 3ETH（校对注：注意：红色的虚线代表尚未建立的虚拟通道，灰色的实线表示已经建立的账本通道；另请注意 Ingrid 在两边的余额）。

为了打开这个通道，Alice 和 Bob 都会给 Ingrid 发一个签过名的请求。当 Ingrid 收到双方签署的请求后，Ingrid 会同意这种变更，并更新与双方的账本通道。这个更新过程会将虚拟通道两端所需余额在每一个账本通道的对应端扣减——如下图所示：

-在每一个账本通道中，我们都在左端扣减 5ETH，在右端扣减 3ETH-

为了支持虚拟通道的创建，每一个现有的通道都从左边扣减了 5ETH，右边扣减 3ETH。到这儿，我们就不再需要 Ingrid 了，更新虚拟通道和更新账本通道是一样的（双方签署交换序列化的信息）。

- Alice 同意发给 Bob 1ETH -

- Bob 同意发给 Alice 3ETH（基于起始序列信息的）-

现在我们已经开启了一个虚拟通道，并且基于通道做了交易，下一部分就是设置关闭通道。

关闭虚拟通道

理想情况

为了关闭上面的虚拟通道，Bob 和 Alice 就要向 Ingrid 提交最新双方签名的信息。Ingrid 根据提交的信息更新双方各自的账本通道。注意，在 Alice 和 Bob 利用虚拟通道交互时，Ingrid 和 Alice、Bob 的账本通道是开着的，这就意味着，所有消息交互都不是在链上完成的。

-根据更新，每一个账本通道中都有 2ETH 从右端移到了左端-

离线/恶意破坏

假设 Bob 决定作恶，尝试骗取 Alice 的 ETH，他发了之前他们双方都签过名的消息给 Ingrid。当收到 Bob 发来的消息时，Ingrid 将会验证为这确实是 Alice 最新确认的消息。在 Alice 离线的情况下，Ingrid 将会开启一个争论期，在争论期内，她会提供虚拟通道确实打开的证明（即 Alice 签署的请求），以及虚拟通道中 Bob 提供给她的最新消息，（消息是由 Alice 和 Bob 共同签署的）。如果 Alice 在争论期内仍然不能上线，她和 Ingrid 之间的账本通道将会根据 Bob 提供的较早消息而更新，然后关闭。

-由于 Alice 不能上线，Bob 成功敲诈了 Alice -

监控服务

假如 Alice 预料到了自己会离线，因此把最终和 Bob 签署的消息发给了她的朋友 Carl，Carl 代表 Alice 把这个最终状态发给了 Ingrid ——那么 Carl 实际上就成为了一个提供监控服务的节点。这样虽然不能阻止 Alice 的账本通道被关闭，但可以强制让 Bob 提供一个更新的消息，或者同意 Carl 提交的状态。

-由于 Carl 代表 Alice 提交了最新状态，Bob 骗钱失败-

这种提供收费监管服务（就像 Carl）的策略在社区里很常见。不过我个人并不太喜欢这种方式，因为没有第三方服务也能达到这种效果——下一篇将会介绍。说到这，如果你想了解更多这种第三方的解决方式，我在下一节列出了几个相关文档。

谁在做虚拟通道？

本篇博文是由 Perun Channels 启发而来——他们做的真的是太棒了，并且基于他们的工作，已经产生了很多版本的类似通道。我最熟悉的一个就是“中心支付通道”，SpankChain、Nathan Ginnever（Finality Labs）还有 Arjun Bhuptani（Connext）就在做这些。