阅读 860

关于以太坊 "雷电网络" 的思考

作者:林冠宏 / 指尖下的幽灵

掘金:juejin.im/user/178526…

博客:www.cnblogs.com/linguanh/

GitHub : github.com/af913337456…


以太坊是我个人目前很看好的区块链平台。信仰之一。 ---LGH on 2019-3-28

PS:本人技术书籍:《区块链以太坊DApp开发实战》已经出版并可以网购了


对以太坊稍微有些些深入了解的人可能知道,目前它拥有的瓶颈点之一就是交易的完成速度略慢,即使在君士但丁堡版本发布后,更新了的节点们,处理交易的速度依然不是很高。且每一笔交易伴随着手续费。形象地,一笔交易要在以太坊上被打包成功并上链,它要经过下面的一些步骤:

如上图所示,特别地,在整个过程中,1'5' 是所占时间最多的,也是影响TPS的主要原因。前者受限于共识算法,后者受限于P2P的分布式网络环境

当然,交易速度慢,不仅仅是以太坊所面临的瓶颈,也是目前大部分著名公链所面临的。这些问题在一定程度上导致了区块链不能被广泛商用。在以太坊的分片扩容和卡斯帕PoS共识算法技术,它们被应用并落地之前,官方的解决手段可以说是尚还没有。

最近我在写好了一个自己的区块链积分通证协议相关的项目白皮书时,感概在技术层面上,已经从用户体验的角度出发,充分地解决了大部分的问题,却还是受限于链上的积分兑换交易速度较慢。

区块链的去中心化积分系统对比于中心化的积分系统,前者就不能在交易速度上接近或超过后者吗?带着这个问题,我与不同的区块链技术朋友交流过想法,以及在互联网上寻找过解决方案。

在不进行底层重构的前提下,我看到了一个类似于比特币区块链上所提及的闪电网络,这么一个‘链下交易链上结算’的加速交易完成的方案,它就是:

雷电网络

雷电网络对应于以太坊闪电网络对应于比特币。它的技术方案实例后简述如下:

假设 A 和 B 要进行通证T的交易。

  1. 在以太坊区块链上创建一个与 T 通证相关联的智能合约,且称为 T 的通道合约-- C。C 必须包含但不一定要限于下面的功能:
1 通道创建
2 通道关闭 (清算)
3 验签
复制代码
  1. 现在 A 要和 B 进行交易,首先,A 以交易的形式,将携带了双方同意建立通道的签名信息数据,发到链上的C,调用链上 C 的通道创建方法,建立与 B 的通道,在建立通道的时候,会合约会执行一个通证抵押操作,抵押操作详细描述见下文的惩罚机制。创建通道的原因是要在链上先进行信息的保存,这样在后面的通道关闭,清算各自所得的时候,才有凭据。
  2. 创建了通道后,A 转 1 个 T 给 B。A 在应用本地使用私钥签名这笔交易,这笔交易明确地写好了数值等参数。交易发给 B。或发送给中继服务,由中继服务进行第一步的验签再转发给 B 客户端。
  3. B 在收到交易后,确认交易。随后使用自己的私钥签名这笔交易。然后 B 保存这笔已经被双重签名了的交易到自己的客户端本地,再发送回给 A,最后 A 也保存交易到自己的本地,一来一往,这算是一次完整的链下交易。要注意的是,这里的每一次传输,交易双方都是可以验签对方信息的。以及,这条交易信息不需要发到区块链上,只需 A 和 B 保留即可。
  4. A 和 B 之间在链下的每一次双方签名的交易信息,都有一个序列号(Nonce),比如第一次是1,第二次是2,如果要结束通道,即发起清算(假如由A发起,当然B也可以发起),那么A可以将最新的序列号,即MaxNonce对应的交易发送到智能合约,同时提供一个锁定时间,合约验签通过后,并发出一个 Event
  5. 如果在锁定时间到期前,B 提供了一个 Nonce 更大的清算交易,那么说明 A 作弊(比如,A在倒数第二条信息时收到了B的1个以太币,在最后一条信息发给B两个以太币,但A结束通道时,只提交倒数第二条信息),此时合约会惩罚A,惩罚手段有多种,比如有基于抵押机制的扣除抵押币。如果到期时 B 没有异议,合约根据最后这条信息的净增减额计算双方的最终余额发还给双方。

雷电网络的惩罚机制,它的操作是要求在建立通道的时候,要求通道参与者,必须要抵押部分通证,比如锁定以太,由通道合约地址暂为保管。在通道关闭的时候,会归还。对于在交易中出现作弊的一方,作为惩罚,作弊方的通证将会被给到对方。这一操作意味着,交易双方必须要有以太可以被锁,如果某一方没有以太呢?这难免又会是另一个用户体验的问题,甚至会影响到整个链下交易的可信任性。这也是要我们借鉴了雷电网络的思路后要解决的问题之一。

上面的简单描述,明显存在下面的细节问题:

  1. 交易的付款方余额不足时,链下交易如何保证付款方余额是足够的?

:收款方,在每次通道创建前,接收到付款方的签名交易时,可以对付款方的链上资产进行一次检查,余额不足则拒签。

  1. 在链下的交易过程中,如果出现在开始时付款方的余额是充足的,而随着后续的交易,最终付款超出了付款方实际的链上余额,岂不是发生了错误交易?

:是的,的确有这样的情况,它的解决方案和问题 1 是一样的。当然,还可以考虑利用上雷电网络抵押机制

  1. 在 A 和 B 的交易还没清算之前。A 和 D 产生的新交易中所产生的余额变化,交易对:(A和B)于(A和D)之间,如何感知各自的余额变化,例如 A 作为付款方在还没超支链上余额的时候,和B正常链下交易。但如果统计上了和D的交易中所产生的付出,就超支了。

:解决这类问题,必须要依靠抵押机制。首先 A 和 D 会创建一个新的通道,会有新的抵押。每一次通道的创建,A 都会抵押部分通证在智能合约中。这样的话,(A和B)或(A和D)它们之间以抵押值为超支界限即可。付款方如果超出抵押值,那么拒绝交易。

  1. 不同 Nonce 对应的交易记录,是怎样关联到上一个 Nonce 所对应交易记录的?

:每条交易的要记录上一条交易中所发生的通证数量的增减量变化。闪电通道的是记录余额,雷电通道的是记录净增减,比如A原有9个币,B有11个,A再发1个币给B,闪电通道会记录A还有8个,B有12个,但雷电通道会记录A减少1个,B增加1个。

  1. 对于小额通证持有量的双方,是否适合使用雷电网络这种链下交易模式?

:不建议使用,但不影响使用。

  1. 要是例子中的 B 用户离线了,无法在锁定时间内接收到 A 发起的清算 Event 通知。会怎样。

:合约将会以 A 发的清算记录,进行清算。B 存在亏损风险。

  1. 链下交易是否变成了中心化?

:不是,首先用户的私钥可以本地保存即可。如果惧怕交易记录丢失,客户端可以提供和备份私钥一样的备份交易记录的功能。不备份而丢了设备的,资产丢少。

  1. 如果 A 备份了私钥,没备份交易记录。然后丢了手机,交易记录如何清算?

:在 B 不感知的情况下。可以由 B 发起链上交易清算,考虑到惩罚机制,B 一般不会轻易去作弊。

雷电网络 的其它技术点

  • 通道复用。A --> B --> C --> D。
  • 超时通道。打开有时间限制的通道。

综上述雷电网络的交易模式适用于:

  • 含某通证数额值较高的交易双方,小额交易使用。

对于链下通证对实物兑换的落地应用场景的应用改造

我们必须要承认一个点就是:雷电网络的确起到了加速交易的作用。

对于通证在链下对实物兑换的落地应用,还需要解决下面的一些问题:

  1. 抵押机制的优化,让 0 通证持有量的用户也能参与进来。
  2. 实物交易后的退货 与 链上结算 的限制问题,以确保用户不会在清算后,还发起退货。
  3. 通道建立 或 关闭时,用户作为发起方,必须含有 ETH 充当手续费的体验问题。
  4. 通证手续费抵扣机制的拓展。
  5. ...

至此,雷电网络 的完整实现应该是包含两个核心部分的,即:链上智能合约 + 链下中继服务端。如果想基于 雷电网络的技术思想来一起实现一个到一定时机开源的针对 合约通证在链下兑换实物 应用解决方案的项目。可以申请加入我们。

加入的说明要求

  1. 在东西实现之前,不抱盈利之心。实现后,若有机会盈利,论贡献获利。
  2. 参与开发时,无时间要求,无地域要求,纯靠自觉。
  3. 大约均分 Web与移动前端、后端、合约工程师和其它共 20 人。人满则排队。
  4. 要对区块链技术有热衷之心。
  5. 有过实际的区块链相关应用的技术开发最佳,包含但不限于前后端。
  6. 有经验的后端开发请忽略第 3 条。
  7. 加入后,若日渐厌烦无感 或 经久无任何建议性观点或实操的。可自行离群,于我亦如此。
  8. 任何有实际贡献者无论日后还是否在项目团队内,都会被列举到贡献列表中。

团队现状

现有来自一线技术互联网公司的后端和安卓移动端开发人员。包含我在内,对于常见的区块链常见的钱包、交易所、接口中继和合约协议等应用都有丰富的开发经验。

申请方式:

发邮件到: 913337456@qq.com ,邮件中必须要有个人的技术栈简介。

项目设想线路图