星期五 , 十二月 13 2019
首页 / 区块之心 / 以太坊2.0将加速落地,简化分片方案新鲜出炉

以太坊2.0将加速落地,简化分片方案新鲜出炉

昨天在日本大阪举办的Devcon 5 大会上,ConsenSys创始人透露称以太坊2.0的phase 1-2将提前落地,可能在2020年底就可以推出,而这比原计划要提前近两年的时间。

那这究竟是怎么一回事呢?是开发者们实在太给力,以至于团队能超前完成任务了?

当然不是这个原因,真正的原因是:以太坊2.0原分片方案实施难度太高,为了加快落地,研发团队对其进行了简化。

为此,以太坊创始人Vitalik 刚发布了还热乎的“减少分片数量,加快跨分片通信”的提议。

45

那这个新提议的具体内容有哪些呢?

原文在这里:https://notes.ethereum.org/@vbuterin/HkiULaluS

太懒不看?给你核心要点:

  1. 不再有持续分片链(persistent shard chain)的概念,相反,每个分片区块都是直接的交联(crosslink)。提议人发出提议,交联(crosslink)委员会负责批准,然后完成任务;
  2. 分片数从之前的1024减少到64,分片区块大小从(16目标值,64上限值)kB增加到(128目标值,512上限值)kB,总分片容量为1.3-2.7 MB/s,具体取决于slot时间。如果需要的话,分片数量和区块大小可随时间的推移而增加,比方说10年后最终达到1024个分片,以及1 MB区块。
  3. L1和L2层进行了诸多简化:(i)所需的分片逻辑更少,(ii)不需要layer-2跨分片加速,因为“本地”跨分片通信是在1个slot时间内发生的,(iii)不需要DEX来促进支付跨分片txfee(交易费),(iv) EE(执行环境)可以变得更简单,(v)无需混合序列化(serialization)和哈希;
  4. 主要缺点:(i) 信标链开销会较大,(ii)分片区块时间会变长,(iii)较高的“突发性”带宽需求,但“平均”带宽需求会是较低的。

(注:下面是具体方案描述)

 

序言/根本原因

 

当前的以太坊2.0体系结构过于复杂,特别是在费用市场层面,这是由针对eth2基础层的重大故障所创建的layer-2解决方案引起的:虽然分片内的区块时间是非常低的(3-6s),但分片之间的底层通信时间却是非常高的,这需要1-16个epoch周期,而如果超过1/3的验证者离线,这个时间甚至会更多。这使得“乐观”解决方案成为了必要前提:一个分片内的子系统“假装”提前知道其它分片的状态根,通过某种中等安全的机制(如轻客户端)来学习它们,并通过使用这些(可能,但不确定的)状态根处理交易来计算自己的状态。一段时间后,一个“后卫”进程会遍历所有的分片,检查哪些计算使用了有关其他分片状态的“正确”信息,并丢出所有未使用这些“正确”信息的计算。

而这个过程是有问题的,这是因为,虽然它可有效地模拟很多情况下的超高速通信时间,但是复杂的情况,是由“乐观的”ETH和“真实的”ETH之间的差距引起的。具体而言,我们无法合理地期望区块提议者“知道”乐观ETH,因此,如果分片A上的用户向分片B上的用户发送ETH,则在分片B上的用户拥有协议层ETH(这是唯一可用来发送交易费的东西)之前,会存在一个时间延迟。而要想绕过这一点,要么需要去中心化交易所(它们有自身的复杂性和低效率问题),要么需要中继市场(这引起了人们对垄断中继者审查用户的担忧)。

此外,目前的交联(crosslink)机制增加了大量的复杂性,实际上它需要一整套区块链逻辑,包括奖惩计算、分叉选择规则等,它们需要被纳入分片链中,并作为Phase 1(阶段1)的一部分。

本文档提出了一个彻底的替代方案,它消除了所有这些问题,从而使以太坊2.0能够更快地使用,另外还降低了风险(文档中还记录了一些折衷方案)。

 

方案细节

 

我们把SHARD_COUNT(分片计数)从1024减少到64,并将每个slot的最大分片数从16增加到64。这意味着“最优”工作流现在是在每个信标链区块之间,而之前每个分片会发布一个交联(crosslink)(为了清楚起见,让我们取消“crosslink”一词,因为我们没有“链接”到分片链,而是直接使用“分片区块”一词)。

p1

注意一个关键的细节:现在有一条路径,任何分片的slot-N+1区块都可以知道所有分片的所有slot-N 区块。因此,我们现在有一类的单slot跨分片通信(通过Merkle收据)。

p2

现状(近似图)

p3

新提议

我们改变了证明链接的结构:它不再包含“crosslink”(包括以某种复杂的序列化形式表示许多分片区块的“数据根”),而只包含单个区块内容的数据根,其内容完全由“提议者”决定。分片区块还将包括来自提议者的签名。提议者的计算方法与以前相同,都是基于persistent-committee(常设委员会)的算法,而这是为了鼓励p2p网络的稳定性。如果没有可用的提案,交联委员会成员可投票赞成一个空的“零提案”。

在该状态下,我们像以前一样存储一个map latest_shard_blocks: shard -> (block, slot) ,不同之处在于存储的周期变成了epoch,而不是之前的slot。在“乐观情况下”,我们希望这个map能够更新每个slot。

online_validators定义为活跃验证者(在过去8个epoch周期中的1个,这些验证者至少有一个证明被包含在内)的子集。如果2/3的online_validators(按总余额计算)同意给定分片的同一新区块,则map会进行更新。

如果当前slot是n ,但对于给定分片ilatest_shard_blocks[i].slot < n-1(即前一slot周期该分片出现了一个跳过(skipped)区块),我们需要该分片的证明,以提供范围[latest_shard_blocks[i].slot + 1....min(latest_shard_blocks[i].slot + 8, n-1)]内所有slot的数据根。分片区块仍需指向“先前分片区块”,并且我们仍要强制一致性,因此该协议要求这样的多slot证明是一致的。我们希望委员会使用以下“分叉选择规则”:

  1. 对于每个有效+可用的分片区块B(该区块的祖先区块也必须是有效+可用的),计算最近消息支持B或B后代的验证者的总权重,我们称之为B的“得分”,空分片区块也可以有得分。
  2. latest_shard_blocks[i].slot + 1选择拥有最高得分的分片区块;

latest_shard_blocks[i].slot + k(k > 1)选择拥有最高得分的分片区块;

 

概述

 

发布信标区块N和信标区块N+1之间的过程如下:

  1. 信标区块N被发布;
  2. 对于任何给定的分片i,分片i的提议者提出一个分片区块。此区块的执行可看到信标区块N和旧区块的根(如果需要,我们可以将可见性降低到区块N-1和旧区块,这就允许信标区块和分片区块并行提出);
  3. 映射到分片i的证明者进行证明,其中包括对分片i上的slot N信标区块和slot N分片区块的意见(在特殊情况下,也包括分片i上的旧分片区块);
  4. 信标区块N+1发布,其中包括所有分片的证明,区块N+1的状态转换函数会处理这些证明,并更新所有分片的“最新状态”;

 

开销分析

 

注意,不需要有参与者不断积极地下载分片区块区块数据,相反,提议者在发布提案时,只需在小于3秒的时间内上传最高512 kB的数据(假设有400万个验证者,每个提议者平均每12.8万个slot周期会上传一次),然后委员会只需在小于3秒的时间内下载最高512 kB的数据,即可验证提案(每个验证者将被要求在每个epoch周期执行一次此操作)。

请注意,这低于当前每个验证者的平均负载(即每个epoch周期约2MB)。但是,“突发性”负载会是更高的:之前为3秒内最高64KB,现在改为3秒内最高512KB。

从证明(来自400万验证者)加载的信标链数据更改如下:每个证明大约300字节的固定数据,外加一个位字段(bitfield),即每个epoch周期400万bit,或每个slot 8192 byte。因此,当前方案的最大负载为128 * 300 + 8192 = 46592,尽管平均负载可能更像32 * 300 + 8192 = 17792,甚至可通过压缩来降低(证明包含冗余信息)。

而在该提议中,我们会看到两种负载:

最大负载为128 * 300 + 128 * 200 + 8192 = 72192,平均负载也许为80 * 300 + 10 * 200 + 8192 = 34192。

还要注意,证明聚合在每个分片中每个slot的开销为65536 * 300 / 64 = 307200 字节。这为运行节点的系统提供了一个需求基础,因此使区块数据变得比这小得多也没有什么价值。

从计算上讲,唯一显著增加的开销,是更多的配对(pairing,更具体的说,是更多的 Miller循环),而具体数据是从每个区块最多128增加到最多192,而这将增加大约200ms的区块处理时间。

 

分片“基本操作系统”

 

每个分片都有一个状态,即映射ExecEnvID -> (state_hash, balance)。一个分片区块被分成一组块(chunk),其中每个块(chunk)指定一个执行环境(EE)。块(chunk)的执行以状态根和块(chunk)的内容(即一部分分片区块数据)作为输入,并输出一个 [shard, EE_id, value, msg_hash] 元组列表,每个分片最多只能有一个EE_id(我们添加两个“虚拟”分片:传输到shard -1代表验证者对信标链的存款,传输到shard -2则向提议支付费用)。我们还从EE余额中减去value的和。

在分片区块头中,我们放置了一个“receipt root”(收据根),其中包含一个映射shard -> [[EE_id, value, msg_hash]...] (每个分片最多8个元素)。

分片i上的分片区块,需包含彼此分片的分片 j收据的Merkle分支,该分支位于其它分片的“receipt root”(收据根)(任何分片i都知道任何分片j的收据根)。接受的值被分配给它的EE(执行环境),并且EE 执行可访问msg_hash

P4

这允许在分片间的EE之间即时传输ETH,每个区块的开销为 (32 * log(64) + 48) * 64 = 15360字节。msg_hash可用于减少传递跨分片信息所需验证内容(witness)的大小,因此在一个高度活跃的系统中,15360字节通常是必不可少的。

 

主要的好处:更简单的费用市场

 

我们可按下面的方式修改执行环境(EE):每个分片都有一个状态,其中包含状态根以及执行环境(EE)的余额。执行环境将能够发送收据,因而将币直接发送给其它分片上的相同执行环境。这将使用一个Merkle分支处理机制来完成,每个分片EE状态为其它分片存储一个nonce,以此作为重放保护。EE也可以直接向区块提议者支付费用。

而这种方式,除了提供了足够的功能(允许用户将币存放在分片上,使用这些币发送交易费用,并在分片内轻松地移动这些币)之外,还消除了对中继市场的迫切需求,也消除了执行环境(EE)承担乐观实施跨分片状态的负担。

 

优化证明

 

为了提高效率,我们还进行了以下优化:如前所述,查阅slot n的证明可完整地包含在slot n+1中。然而,如果这样的证明包含在后面的slot中,则必须以“简化形式”包含它,该“简化形式”仅包含信标区块(head, target, source),而不包含任何交联(crosslink)数据。

这种方法不仅减少了数据,而且重要的是,通过强制“旧证明”保存了相同的数据,它减少了验证证明所需的配对(pairing)数量:在大多数情况下,来自同一slot的所有旧证明都可通过单个配对(pairing)进行验证。如果链不分叉,则在最坏情况下,验证旧证明所需的配对数限制为epoch长度的两倍。如果链确实发生了分叉,那么包含所有证明的能力,将取决于更高百分比的提议者(例如是1/32,而不是1/64)是诚实的条件,并且还需要包含更早的证明。

 

保留对轻客户端的支持

 

每天,我们随机选择一个由256个验证者组成的委员会,这些验证者可以在每个区块上签名,其签名可包含在区块n+1中以获得奖励。这样做是为了让低权利的轻客户端也能够工作。

 

其它可能的扩展

 

  1. slot n的分片区块须查询slot n-1(而不是slot n)的信标链区块。这将允许每个slot并行而非串联发生,从而减少slot时间,而其代价是将跨分片通信时间从1个slot时间增加到2个slot时间;
  2. 如果区块提议者希望让区块大于64KB(注:目标是128KB),则其首先要生成64KB的数据,然后让交联(crosslink)委员会对其进行签名,然后,他们可以添加另一部分引用第一个签名的64 kB,依此类推。这将鼓励区块生产者每隔几秒发布其区块的部分完成版本,从而创建预确认;
  3. 加快秘密leader选举的发展(为简单起见,即使是匿名集为8-16的基于环签名技术的版本也会有帮助);

 

而对于这一新的分片方案,也有社区成员发出了自己的疑问,比如Raymond Durk写道:

23

“如果现在这样做,那以后(以太坊2.0)分片数量要扩展到1024,它的实现会复杂吗?”

对此,Vitalik的回复是“并不复杂”。

你的看法是什么呢?

关于 冯先生失眠中

冯先生失眠中
卷而怀之

检查

开发了两年 DApp、二层网络后,我转投了 Substrate 阵营

近来连续参加了三个黑客马拉松, …

发表评论

电子邮件地址不会被公开。 必填项已用*标注