Alpha支付通道

在我的上一篇博文中，我简单地讨论了状态通道，以及为什么我认为它对于开启以太坊的大规模可用性来说，是至关重要的。在此，我打算通过几篇博文来推进一步，这些博文对 L4 团队用 Countfactual 做了什么，以及这个词到底是什么意思，提供了广泛的概述。在这第一篇博文中，我将要介绍状态通道的始祖 O.G. ——支付通道。

-我坚持要放这张图上来——不过没法让它看起来攻击性弱一些。你们就原谅我吧。-

支付通道

那么，支付通道已经被讨论过一段时间了，可以在比特币闪电网络白皮书中找到很多关于其工作方式的参考。

如果你想寻找一个支付通道的现实世界中的例子，那就想象一下下面的场景：你经常在餐馆用餐，但只用支票付款（因为这对你来说是最方便的）——不过，无论何时兑现，银行都要收取餐馆 5 美元的费用。如果每张支票的平均金额为 15 美元，那就是 33.33% 的交易费。这样一来，我们该怎么办呢？

这种情况和你用支票付给餐馆的情况是一样的，只是你每开一张新支票时，都要把之前开给餐馆的支票额度累加，然后废掉之前开出的支票。这样餐馆就持有一张你所欠金额的总支票，因此餐馆能够通过银行一次性处理多笔交易，也降低了银行的交易费。这看起来有点像下面这张图：

-一个现实世界中支付通道的例子-

在上面的例子中，我们看到，可以通过替换新支票，对旧支票进行结算并作废，来减少交易费。

根据我的背景，我将从以太坊开发者的角度来解释它在区块链领域的工作原理。

在创建支付通道时，双方都要同意将 ETH 存入一个智能合约中（在本例中，Alice 和 Bob 都投了 25ETH）。智能合约有接收多签名交易的能力，并能给双方支付相应的金额。如果双方都签名了最新的离线交易（在本例中 Alice 15ETH，Bob 35ETH），并将最新交易发给智能合约，智能合约就会实时更新并向双方支付。

与每个签名交易有关的 Nonce 是为了进行交易排序的。假设 Alice （向合约）提交了一个交易，Nonce 值为0，但是 Bob 不同意这笔交易，因为两人之间已经发生了一笔更新的交易。因此，如果双方都不同意提交到智能合约的交易，智能合约就会等一段时间（这个就叫挑战期）来等待一笔新交易（或者有一个更高 Nonce 值的交易到来）。每当人们给合约发送一笔交易，合约都会相应开始一段挑战期，等待更新的交易到来。如果没有新交易提交，并且等待期已过，那么智能合约就会立即执行更新，并根据最新交易对双方进行支付。下面有一个例子，说明这种情景是如何发生的：

- Alice 想提交一笔旧的交易-

- Bob 提交了一笔最新的交易-

-智能合约会在挑战期结束后进行支付-

所以，支付通道的主要好处包含：

隐私——在一组完整的交易中，公众只知道链上登载的最后结果；因此，Alice 和 Bob 的隐私在交易过程中是受到保护的

即时生效——Alice 和 Bob 可以立即签署和交换消息，不需要等链上的状态确认——从而获得更好的用户体验。

更低的交易费——Alice 和 Bob 能自由地交换ETH，只需为创建通道和 结算/关闭通道 的链上交易付出手续费即可。

这里要注意的一点是，为了确保发送到链上的交易已经得到了通道各方的同意，每个支付通道在创建时必须有一组定义好的用户。

Part-2：App-Specific State Channels

在我的下一篇博文中，我将深入研究APP特有的状态通道。

如果你在开发利用状态通道的项目，我非常希望看到你的实现以及你开发的方式。如果有什么我可以改进的地方，请在评论部分告诉我。我只不过是个社交媒体的新手。最后，如果你从这篇文章中学到了一些东西，非常感谢你把这个分享到你的社交网络里。这个是分享链接： https://medium.com/@eolszewski/counterfactual-for-dummies-part-1-8ff164f78540

可以在 Twitter 和 GitHub 上找到我。