查看原文
其他

干货 | 2018年3月以太坊的扩展现状

Georgios 以太坊爱好者 2019-07-11



从2018年3月8日到10日,来自世界各地的以太坊专业人士、研究人员、投资者和爱好者涌入巴黎来参加以太坊社区会议(EthCC)。


EthCC 是由一家法国的非盈利组织 Asseth 筹备组织的。Asseth 自2016年初以来,一直在推广和分享以太坊及其生态系统方面的知识。


会议一共有超过800人参加(当然咯,我也是!)。


-关于“扩展 EthCC ”的最后一次讲座中的人数指标-


在三天的会议期间举行了超过100个讲座,主题范围从管理、安全和隐私到 DApp 开发、游戏和去中心化交易等。

如果我仔细描述每一个讲座的话,这篇文章就会太长了。所以既然我们在 Loom Network 的关注点在于可扩展性,在这篇文章中,我们将重点介绍 EthCC 的可扩展性讲座。


Plasma, Plasma Cash & 分片


在第二天, Karl Floersch 展示了 Plasma & 分片的最新进展。这个讲座是他上周上传的解释Plasma视频的稍微更多细节版本。



这应该是我最喜欢的讲座了,主要是由于 Karl 对他描述的概念所表现的能量和热情。 目前,Plasma是为代币转移(ERC20 / Eth)而设计的,但它可以扩展到更复杂的代币,如ERC721或甚至更通用的状态转换。


应该明白,Plasma不是一个协议,它是一种设计模式、一种技术。 最主要的要求是Plasma链必须(几乎)像根链一样安全。


Plasma 技术背后的主要安全机制是“ Plasma 出口”,该过程允许参与 Plasma 链的用户停止参与链并将他们的资金转移回根链。 每个 Plasma 链也由其自己的“ Plasma 操作员”管理。


在用户在 Plasma 链中进行交易并且想要将其资金转移到主链的情况下,他们提交一个“退出交易”(即他们的交易历史的默克尔(Merkle)证明,以证明他们拥有一定数量的资金)。 那一刻,就会产生一个“挑战期”。


挑战机制在大多数链下解决方案中都能看到。 从本质上讲,你允许任何人通过提交证明你的声明无效的证据(在 Plasma 中这可以是交易历史的 Merkle 证明,在支付通道中这可以是来自另一方的签署消息)来挑战你的声明。

另外,在进行可能会受到挑战的交易时,你还需要附加一笔小额奖金,以激励人们在如果他们认为你的行为是恶意的时候挑战你。 这就像你试图偷东西,并说“如果你能抓到我,我会付你5美元”。


在正常情况下,如果 Bob 想要将5个 PETH(Plasma ETH)转移回根链,他会提交一个“退出交易”(加上赏金作为抵押品),如果它没有被挑战,Bob 就可以在根链领取 5ETH。 如果 Bob 的“退出交易”成功受到挑战,它将被取消,挑战者将获得赏金。




-Alice 注意到 Sam 试图退出并挑战他。 在这个例子中,Sam 的退出是具有欺诈性的,因此它被取消了,以及 Alice 收到了 Sam 的抵押品-


更危险的情况是,当 Plama 操作员想要退出他们的链。 下面所描述的攻击矢量图涉及 Plasma 操作员开发一个区块,获得任意数量的 PETH,然后尝试退出,并将所有ETH锁定在自己的智能合约中。 在这个例子中,Sam 和 Alice 的 PETH 比 Plasma 操作员的 PETH 更早铸造。



-Sam 和 Alice 注意到操作员的恶意行为并提交了“退出交易”(他们的会在操作员的之前被处理)-


为了“榨干” Plasma 合约,如果 Plasma 操作员提交“退出”,Sam 和 Alice 注意到了然后他们也提交“退出”。 较早的交易会首先被处理,这意味着他们可以首先安全地将他们的 PETH 兑换为 ETH,然后当 Plasma 操作员的“退出”得到处理时,它是无效的,因为合约现在是空的了。


Karl 讲座的第二部分是 Plasma Cash,将在下面 Vitalik 的讲座中介绍。


最后一部分是关于分片,0期和1期。


分片0期:

  1. 无硬分叉

  2. 验证经理合约与一组分片验证程序,最多100个以太坊分片以及数据可用性保证


分片1期:

  1. 帐户抽象化 [1] [2] [3]

  2. eWASM


如上所述,分片中有3种实体:

  1. 用户:发送交易的实体

  2. 区块提议者:计算状态转换以及提议区块

  3. 验证者:验证区块以及确保数据可用性


想了解有关提议区块的更详细描述,请观看 Karl 的讲座,你会喜欢的。



Minimal Viable(最小可行)Plasma的现状


David Knott 介绍了 Plasma 的 UTXO 模型。 与比特币类似,UTXO 模型涉及一个具有未支出输出的交易总和的用户,以及组成余额的 未支出输出交易(UTXO) 的总和。 这在试图证明时效率不高,因为用户可能有成千上万的UTXO,这会增加证据的大小。 在这种情况下,通过用户将所有的 UTXO 发送给自己,然后将其压缩为一个,来完成模拟帐户的工作。




当用户在 Plasma 合约中存入(锁定)ETH 时,会为此金额生成一个 UTXO。 然后,用户可以在 Plasma 链上进行尽可能多的交易,并且享受快速确认和低费用的好处。 当他们想要退出时,他们将他们的 UTXO 提交给根链的合约,并取回他们锁定的 ETH。


-主链中的Plasma合约是最终仲裁员-


这样设计的目标是让 Plasma 链的 Plasma 链可以拥有不一样的特性。安全性将通过与法院类似的机制来维持。 在发生争议的情况下,将调用下一级权限,直到争议在最坏情况下得到根链的最终解决。



Plasma Cash


最后,Vitalik Buterin在他的“惊喜”讲座中揭晓了 Plasma Cash — — “更少每用户数据检查的Plasma”。与此同时,由于房间完全爆满了,Karl 在外面做了一个即兴的讲座,你可以在这里看。这个讲座也是 ethresear.ch论坛正在进行的讨论 的现场版本。


-图片来源-<https://twitter.com/DistributedFund/status/972233284200607744>


本质上来说,Plasma Cash是具有一个以下修改的Plasma版本 [1]:

  1. 每一单笔存入都相对应有一个唯一的币ID;代币无法分割也无法合并。

  2. 我们不是按照txindex的顺序将交易存储在二进制 Merkle 树中,而是要求它们存储在稀疏简单的 Merkle 树或 Patricia 树中,索引是所用币的ID。


这为币提供了一些不可互换的属性,从而可以优化其历史证明。 通过这种结构,用户只需要验证他们正在观看的币的历史记录(Merkle 路径,遵循 UTXO 模型)。与必须验证所有币的整个交易链相比,这允许了高效的证明。




状态通道


我将重点对状态通道领域的三个主要参与者进行比较:Funfair、SpankChain 和 Raiden Network。


Funfair & Fate 通道


由于这是一个博彩的用例,因此它需要有一个随机性来源。 当玩家与赌场之间的支付通道开放时,RNG 将由玩家和赌场播种,从而确保有一个更安全的熵源。 Fate 通道目前是闭源的,Jez将其描述为保留竞争优势的手段。



FunFair 可以做到“变成完全状态通道”,这与 SpankChain 的可以进行任意状态转换(不同于 Raiden 的仅用于支付)的状态通道类似。


它们需要1笔交易开通通道,需要1笔来结算。 任何数量的中间交易都发生在链下。Fate 通道“生命”也很短暂,意味着它们仅持续一局游戏的时长。


-Fate通道与其他状态通道实现之间的差异(上:支付通道,下:CounterFactural)-


SpankChain & 通用化状态通道


Ameen 概述了 SpankChain 的生态系统,然后 Nathan Ginnever 对 SpankChain 的状态通道实现中做了深入的讲解。 通用化状态通道和“反事实实例化”是由 L4 和 Counterfactual 创造的术语。


其概念就是,参与状态通道的双方签署并分享一个可以随时被部署到区块链的智能合约的字节码。随时可以拉动开关的能力使任何不诚实的行为无利可图,而且足以使双方都在无需部署合约的情况下,遵守合约规则。


这允许在两个客户端按预期行事的情况下进行零链上交易。


-图片来源-<https://youtu.be/qBqnD6_uRGM?t=1627>


如果出现了挑战,情况就不同了:



债券经理合约负责开启和关闭通道。 它持有结合的 ETH/代币 以及由链下客户端诠释的子通道关闭时的最终状态所决定的余额。


Raiden Network & 支付通道


Lefteris Karapetsas 关于 Raiden Network 的讲座是他们进展和路线图的最新消息。你可以把 Raiden 想作是以太坊的 Lightning Network。


运行 Raiden 需要电脑运行以太坊节点并时刻保持在线。这是件困难的事情,因为首先低性能的 IoT(物联网)设备就无法运行以太坊节点。此外,时刻保持在线还因为网络覆盖率和能源上的限制而不可行。


可用性问题依然存在,例如移动客户端无法运行 Raiden 节点。 定位低功耗设备时,还需要额外开销来增加适当的安全性。 当前可用的通信协议(如 whisper)既不可扩展也没有足够低的潜伏期给 Raiden,所以导致它们要使用 Matrix。


他们将代码重构为多个存储库,你可以在 Raiden 的Github上找到。 根据从 μRaiden 学到的,新的智能合约更加注重可读性、安全性和 gas 优化。


-Raiden 正按照10月发布的路线图赶进度-


Minimal Viable Product(最小可行产品)的每个模块即将完成,经过在测试网络上的测试和外部审核后,Raiden 将最终发布到主网。 如果你是一名开发人员,这里有大量文档,你可以通过分叉 Raiden 的任何存储库并提交合并请求(PR)来为 Raiden 作出贡献。


下图应该可以给你提供一个每种状态通道解决方案之间的直观比较:



支付通道Fate 通道通用化状态通道
项目RaidenFunFair TechnologiesSpankChain & CounterFactual
用例付款Gaming任何智能合约
链上交易220-2
主网发布Q?-2018Q2-2018Q2-2018
参与者数量很多22

更多关于状态通道的阅读:[1] [2]



经过验证的链下计算


我觉得关于这方面的讨论还不够。 Oraclize 在任何外部数据源(例如网络API)和区块链应用程序(如以太坊方面的智能合约)之间提供安全的认证通道 [1]。 这可以进一步扩展到链下卸载计算资源,但仍然能够花费60.000 gas验证其在链上的有效性。



Oraclize 在 Devcon3 讲座中对其进行了进一步描述。 你可以在链下执行任何 Solidity 函数,通过 Oraclize 获得结果并验证其真实性。 如果证明通过了,你就节省了很多gas,否则你只能在链上执行交易(这让我想起了 Truebit )。


-链下执行和验证稍微让人想起了 TrueBit-


讲座也有提及关于如何使用 Oraclize 来增强支付通道,但是没有深入描述。



Casper的“建设修正版”,从二元共识到分片


Vlad 的讲座和研究集中于创建明确定义、且可以“通过建设来修正 ”的协议。 这个概念有点与直觉相悖。 传统的方法是首先创建协议,然后再对其进行分析。而 CBC 是先进行分析,然后再创建协议。


“通过建设进行修正”的方式:

  1. 正式地但仅对协议的部分详细说明

  2. 定义协议必须满足的属性和证明

  3. 衍生协议时应增加经过验证可满足的条款


目标是使对协议正确性的证明成为几乎微不足道。


在这种情况下,定义一组数学规则(一些自动机理论可能会在这部分中帮助到你),然后根据这些规则设计协议。


Vlad的讲座从定义规则和术语(如共识安全)开始:


如果两个状态 σ1和 σ2 具有共同的未来协议状态 σ3,则通过使用 σ1 和 σ2 之间的前向安全性以及 σ3 和 σ2 之间的后向一致性,在 σ1 处做出的所有决策将与在 σ2 处做出的决策一致。 这将使 σ1 与 σ2 具有共识安全。


关于共识安全的更深入的解释,请参考这篇论文的定理1。


最后,在讲座中讨论的分片部分,他描述了合并区块,这可以被认为是分片之间共享历史的“检查点”。


-两个分片和一个合并区块-


我强烈推荐你在这里观看讲座(幻灯片),阅读CBC论文,并观看 Vlad 在以太坊柏林聚会上关于 CBC 协议的其他讲座。因为这仍然处于研究阶段,所以还没有主网的预计发布日期。


虽然跟上 Vlad 的讲座思路有些困难,而且往往需要全神贯注地重新观看,但我觉得Vlad 的讲座内容非常丰富,信息量很大,所以你应该花时间尝试理解他的概念。 这是会议中最长的讲座。 CBC Casper和协议设计是一个我觉得很复杂的领域,所以我将在未来的单独一篇文章中尝试讨论它。



那么Loom Network呢?


就我们对可扩展性方向的努力而言,我们正在为用户构建一个软件 SDK,以便让他们能够构建自己的 DApp 链(一种非金融用例的特定侧链)。 在我们最近的博文中了解更多关于 Loom 的 DApp 链的信息:


  1. 百万用户级DApp-介绍应用程序特定侧链

  2. DApp链:通过侧链扩展以太坊DApps(译者注:中译本见文末超链接)


这是一篇很长的博文! 你现在应该对每个可扩展性项目的状态以及进展有更好的概念了。 所有项目都是开源的,所以请去贡献自己的一份力量吧。



原文链接: https://medium.com/loom-network/the-state-of-ethereum-scaling-march-2018-74ac08198a36
作者: Georgios Konstantopoulos
翻译: 知乎账号 LoomNetwork


本文首发于知乎,EthFans 经作者授权后转载。



你可能还会喜欢:

干货 | 理解以太坊的第2层扩展方案
PPT | Plasma 最小实现版
干货 | 图灵完备的状态通道的实现办法, Part-1


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

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