Ξ

    Search by

    Eth1与Eth2合并后,以太坊如何发展? (视频)

    Vitalik 分享了合并后他心中以太坊在短期、中期和长期的规划


    VB

    Vitalik Buterin       2021-06-11

    来源 | EthGlobal


    2020 年的 12 月,Eth2 的信标链创世,至今已运行了半年,但它其实还没开始成为以太坊数据的共识层,Eth1 与 Eth2 目前是两条平行运行的链。这样的安排一方面让信标链先健康运行一段时间,修复漏洞,社区可以开发 Eth2 上的应用与生态等,另一方面是证明给社区看 PoS 是真的会发生的。等信标链成熟后,根据现在采用的可执行信标链方案,Eth1 作为执行层 (execution chain),它的状态、执行、交易等都会并入到作为共识层 (consensus chain) 的信标链里,成为 Eth2 的一部分,每个 PoS 区块都将包含执行层的数据,同时,创建新区块时就不再需要 PoW 机制了,也就实现了Eth1 到 Eth2 的过渡。

    关于实现合并的时间,根据第 111 次核心开发者会议,难度炸弹时间定在了 2021 年 12 月,计划实现合并的时间理想情况下是12月,更现实的时间是 2022 年年头。

    那么在实现了 Eth1 到 Eth2 的过渡后,What's next?

    在 4 月 EthGlobal 举办的 Scaling Ethereum 系列活动中,Vitalik 分享了合并后他心中以太坊在短期、中期和长期的规划。ECN 对视频的讲演部分做了双语字幕, Q&A 部分做了不完全文字转译。此外,由于视频涉及内容广泛,我们还对Vitalik的幻灯片内容进行了翻译,提供相关的中英文参考资料,方便读者进一步深入了解。




    讲演部分

    短期规划

    合并后的清理分叉 (03:40)

    post-merge cleanup fork

    • 移除 eth1 的数据投票
    • 添加提款功能
    • 把整个执行链转换为SSZ编码
      • 先添加新的SSZ交易格式,最终淘汰基于RLP的交易格式
    • 商定客户端不再下载合并前 PoW 链的数据?
    • 信标状态访问操作码

    参考资料

    SSZ 编码方法手册

    EIP-2929

    Vitalik: 柏林升级里,EIP-2929 提高 gas 开销有何意义

    柏林硬分叉对 Gas 影响几何?


    共识层的中期规划

    分片!(10:37)

    sharding!

    • 64 个数据分片
    • 每个分片每12秒生成大约 512kB 的区块
    • 一开始是基于委员会的安全性,之后会加上数据可用性采样提供的安全性
    • 理想情况下会加入交错的分片区块,使得rollup可以超快速出块

    参考资料

    详解以太坊2.0信标链

    Vitalik:从技术角度揭秘“分片”的优势

    Vitalik:分片+数据可用性采样

    激励交错地生产分片区块的简单方法


    数据可用性采样 (13:23)

    data availability sampling

    • 每个节点随机下载每个分片区块的一些样本数据
    • 使用多项式承诺对分片区块内容加密,证明其正确性
    • 使数据可用性保证成为可能,即使诚实委员会的大多数假设崩溃了

    参考资料

    Kate polynomial commitments

    Data availability sampling in practice


    更多安全性改善 (16:23)

    more security improvements

    • 单个秘密领导人选举
      • 下一个区块提议者将不再使公共可见,缓解DoS攻击和共谋危机
    • VDFs (可验证延迟函数)
      • 委员会和以太坊应用的随机性是可验证的
    • 托管证明
      • 进一步要求节点保存和验证区块数据的机制

    参考资料

    Provable Single Secret Leader Election

    Verifiable Delay Functions

    Verifiable delay functions and attacks

    A 0.001 bit proof of custody


    执行层的中期规划

    地址扩展(18:24)

    address extension

    • 把地址长度从20个字节扩展到32个字节
    • 有利于长远发展的重要安全性改善 (对于抗合谋来说20个字节不够安全)
    • 为了未来兼容性,添加字节用于版本数
    • 状态有效期提案也有需要

    无状态+状态有效期 (18:55)

    stateless+state expiry

    • 现在增加 gas limit 的主要障碍在于状态大小
    • 目前的可能路径:无状态和状态有效期同时实现 (这实际上比分开实现更简单!)
      • Verkle tree (包括代码默克尔化)
      • 状态有效期 (旧状态会被移出主状态,重新访问它需要见证数据)

    参考资料

    以太坊状态管理诸提议(by EthFans)

    状态膨胀和无状态性(by EthFans)

    一份新的无状态以太坊路线图 (by EthFans)

    弱无状态性以及/或者状态保质期机制:即将到来 (by EthFans)

    Proposed Verkle tree scheme for Ethereum state

    Verkle trie for Eth1 state


    账户抽象 (29:26)

    account abstraction

    • 使智能合约钱包和其他应用的使用更容易
    • 多个路径
      • EIP-2938 或类似的提案
      • Flashbots
      • 以上两者的结合?

    参考资料

    账户抽象化 (EIP-2938) : 为什么&做了什么 (by EthFans)

    账户抽象的动机、历史和分析 (by 因雨成歌)

    Implementing account abstraction as part of eth1.x

    flashbot:

    Flashbots: Frontrunning the MEV crisis


    EVM 的改善 (31:25)

    • EVMX (384比特以及其他模运算)
    • 其他改善?

    长期规划

    CBC Casper (32:22)

    CBC Casper

    • 更加安全,因为与LMD GHOST 有更少的交互条件
    • 最终确定性的阈值更加灵活
    • 仍然需要一些研究工作才能有效实现
    • 现有的最佳成果

    参考资料

    CBC Casper: 什么是共识和确定性?

    CBC Casper: 安全性证明 (一)

    CBC Casper:安全性证明 (二)

    CBC Casper 简要说明


    全方位使用SNARK技术 (33:44)

    snark everything

    • 对信标链进行SNARK加密
    • 对EVM进行SNARK加密
      • 或者对一个更好的虚拟机进行 SNARK 加密,使得EVM代码能编译到这个虚拟机,还在本地更高效
      • 如果想的话,使EVM更容易添加本地执行到分片

    参考资料

    从零开始学习 zk-SNARK 系列 (by 安比实验室)

    zkSNARKs in a nutshell

    An approximate introduction to how zk-SNARKs are possible

    STARK


    量子安全 (35:48)

    • 用 STARKs 取代 SNARKs
    • 用基于 STARK的聚合签名替代 BLS签名
    • 用STARK 加密的默克尔树取代Verkle tree

    Q&A 部分

    Q:为什么无状态和状态有效期方案同时进行会更简单而不是分开来做?有哪些原因?

    A: 状态有效期方案是可行的原因是它不再是只有一个状态树,而是每个 epoch 有一个状态树,这个模型好在这使得更新状态树格式变得更容易。因为如果你更新状态树格式,你只需更新版本,把它应用到新的epoch,就可以了。而当前的模型是,如果你想更新状态树,你必须有非常复杂的协议:首先你需要对当前状态进行快照,然后让每个人都重新计算该状态,记录重新计算时的差量,然后应用新的状态,开始采用该差量,并把它移到你创建的新状态树。这是相当复杂的5步协议。

    而如果我们采用状态有效期方案,它自动给我们带来更新状态树尽可能简单的方法。因为我们需要做的只有,比如一切从epoch 1 开始使用verkle tree 而不是十六进制 patricia tree,如果我们想的话我们可以在epoch 1 开始大概一个月后做一次硬分叉,我们都只需要计算新的 verkle tree 根,即取代epoch 0 的 verckle tree 根,所以只需要做状态转换就可以了,是一次性的。这个模型的状态数更新正好使无状态成为可能。


    Q: Verkle tree 什么时候上线,是“合并”前还是后?

    A: 我在这次分享里讲的内容,包括 Verkle tree,都在“合并”之后。


    Q:为什么合并后是先做数据可用性采样而不是 layer1 killing?

    A: 我们做这个以数据可用性为中心的路线图是因为,首先rollup是实现扩容的第一步,且最接近可以发布的。它们存在不确定性,但其他东西的不确定性更大。而只作数据分片能立即提升它们的扩容能力。第二点,某种程度上,数据分片本身其实是实现执行分片的垫脚石,要先解决数据分片才能解决执行特有的问题。我们其实是在实现执行分片的路上,所以这显然应该成为短期规划的重点。


    Q: “合并”前如何减少技术债?

    A:在我看来,在合并前,相当多技术债是很难被减少的,我想主要原因在于我们要继续遵守这个社会规范——以太坊客户端必须能够处理从创世到现在的一切数据。我认为从长远来看,这个准则需要被移除。在未来,客户端应该只需要能够验证,例如最近一年的历史数据。如果我们做到这点,最近一次硬分叉之前的旧版本协议以后将不再被认为是协议必要代码库。特别地,我们最大的获益是我们决定核心以太坊协议不再需要同步从“合并”前工作量证明的历史数据。因为一旦生效了,我们就不再需要触及工作量证明链的数据,而可以直接使用一条链的数据,这样执行客户端会变得简单很多,你可以完全移除分叉选择代码,把同步代码从执行客户端分离出来。因此,有很多好处。


    Q: EVM和 ewasm

    A:我个人的看法是,我对ewasm越来越不 感兴趣了。我一开始对ewasm感兴趣是它可以是更先进的虚拟机,它具备把现在很多的专业成果变为优化实现。它们甚至可以成为编译器而不是解释器,因此它们的速度会非常快,你可以在上面执行密码学运算,你不需要再做预编译。但研究结果表明,事实不是这样。现实是ewasm编译器会出现最坏情况的漏洞,你可以用最坏情况的代码对它们发起攻击,使它变得非常慢。与EVM相比,编译器并没有改善很多。而且我们可能可以扩展 EVM,把它改善至足以做密码学计算,或者是由两到三个EVM-384组成的小组,我现在把它命名为 EVMX 做大量的密码学计算。因此这是更好的路径。现实的长期虚拟机升级的可能性可能是我提到的,在长期规划里,我们会构造更SNARK友好的虚拟机。那时,EVM可能会引入更多的功能,例如利用更快速的执行而不需要用256比特来处理所有事情。但重要的是它必须可以与EVM向后兼容,它必须由某种从目前的EVM到该EVM的编译路径,因为现有的应用都在使用这个EVM,我们不可能让它们不再运行了。如果我们想让我们的链是可证明的,那些这些东西都必须是可证明的。


    Q: 合并会期望有一个活跃验证者最优数量吗?

    A:我觉得我们现在的验证者数量已经足够多了,当然如果增长到3倍,那也很好。但我不担心验证者数量太少或太多。


    Q:在合并后和分片里,合约可组合性在同步环境里会如何?

    A:合并本身不会影响任何东西,因为合并本身只是共识引擎的改变。我期望我们可以在rollup里学到很多关于同步交互的内容。rollup项目在今年开始要上线了,我们现在已经有zkSync、DeversiFi,并将看到Optimism和Arbitrum上线。在每个这些系统上都会有应用,而且会需要有能轻易在不同系统跳转的互操作性。这是生态系统必须解决的问题。我感觉我们能在rollup世界学到很多,这不是一个问题,而是一次机遇。比如你可以有zone (地带) 的概念,你可以在一个zone里做同步工作,如果你想的话,你可以在不同的zone里轻易跳转。但你不可以直接跨多个zone做秘密的事情。这是我的第一项预测,我们还可以有其他的方案。


    Q:你期待合并后会出现更多面向消费者的用例吗?

    A:在这方面我期待的不是合并,而是rollup和分片。原因是rollup和分片将大大提高扩展性,大幅降低交易费,这点正是我们开启非金融应用之所需。有非常多的非金融应用,比如ENS、NFT、人性证明 (Proof of Humanity)、DAO等。但这些应用要运行起来的话,交易费一定要非常大幅地下降。rollup和分片可以做到,即使是在非常大型的社区、面对高得多的需求的情况下。这是我非常期待的事情。我希望以太坊生态可以成为所有这些很棒的非金融应用部署的平台。


    Q:在长期规划里,你把非常多的重点放在了SNARK和STARK上,这些内容大概会在多久以后实现?

    A:大概三到五年。很重要的一点是,这些内容不能进展地太快,因为要把SNARK做好需要使用SNARK友好的哈希函数,原因是现有的哈希函数 (例如Keccak256) 与SNARK比,其实效率非常低。这些函数需要一定的时间进行风险消除、学术测试、密码学分析等。另外,构建一个SNARK版本的 EVM 是非常复杂的,需要大量的工程和研究工作,这些都需要花大量的时间。所以我自己预期这是需要多年的工作,所以在实现上是低优先级。而状态有效期对于可持续发展、允许gas增长至关重要,所以是高优先级。


    Q:有没有什么很酷的点子是你希望在扩容性相关黑客松上看到的,无论是工具还是应用,任何能显著改善用户体验的且人们还没做到的东西。

    A:第一是在rollup里的社交式可恢复钱包。我很喜欢这个概念,我在我的博客上也有谈到原因。rollup好像是实现它的一个好机会,并让用户形成使用它的习惯。另一个想法是构建用于读取以太坊区块链、以太坊历史、rollup、分片数据的可扩展基础设施。这一点之所以重要是因为我们正往远离“普通用户需要运行处理所有数据的节点”这个方向发展。因为我们谈到的像rollup、纠删码(erasure coding)、数据可用性采样这些技术是安全的,但用户还需要有其他方法来获取所需数据,无论是因为他们需要读取它还是创建事务。所以如果能创建可以替代全节点的去中心化协议或 API ,无须任何个人节点存储任何东西,会是非常有价值的。



    声明:ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源,文章版权归原作者所有,转载须注明原文出处以及ethereum.cn,若需长期转载,请联系eth@ecn.co进行授权。

    Ethereum Community Network
    以太坊社区网络
    Ethereum Community Network
    以太坊社区网络