查看原文
其他

科普 | 菜鸟学习状态通道,Part-1:支付通道

Erc Olszewski 以太坊爱好者 2019-12-11

 

在我的上一篇博文中,我简单地讨论了状态通道,以及为什么我认为它对于开启以太坊的大规模可用性来说,是至关重要的。在此,我打算通过几篇博文来推进一步,这些博文对 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 上找到我。



原文链接: 

https://medium.com/blockchannel/counterfactual-for-dummies-part-1-8ff164f78540
作者: Erc Olszewski
翻译&校对: 刘艳安 & 阿剑


你可能还会喜欢:

引介 | Counterfactual 项目:广义的以太坊状态通道

引介 | Kleros 研究路线图

干货 | 理解分布式账本技术: 经济学视角


    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存