引介 | ETH 1.0 需要为 ETH 2.0 提供什么支持？

新的疆域

ETH 2.0 Phase 0（又称 “信标链”）的主网预计将于今年晚些时候上线。眼下，我们应该思考这样一个问题：现有网络可以做些什么来推动新的系统平滑上线？我们可以想象出一些令人振奋的应用场景，可以（在 ETH 1.0 并入 ETH 2.0 之前）利用两个网络之间的互操作性，但是事实表明，如果不能修改 EVM（以太坊虚拟机）来适应 ETH 2.0 系统使用的新密码学元件，这些应用就将受阻。在此我希望为这些新的密码学元件提供概要的说明，并解释为什么将其整合进 EVM 有助于我们在 Eth1 在迁移之前也能利用新系统的功能。

ETH 1.0 少了什么？

以太坊区块链上的所有数据都是公开的，因此我们必须使用密码学签名来确保特定交易反映相关方的诉求。以太坊所使用的签名方案是以椭圆曲线为基础的，使用的是名为 secp256k1 的曲线 。这条曲线上的点被用于名为 ECDSA 的 签名方案 ，为我们的密码学签名赋予我们所期望的属性。

- https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication ，该椭圆曲线的属性提高了 ECDSA 签名方案的安全性-

尽管基于 secp256k1 的 ECDSA 签名方案已经经过了多年的使用测试，但是二者的定义标准分别只有 20 和 10 年左右的历史。ETH 2.0 采用了较为新颖的构造，利用了密码学方面的新进展。ETH 2.0 系统中的验证者（类似 ETH 1.0 的矿工）使用 BLS 签名方案 ，以另一种名为 BLS12-381 的 椭圆曲线 为基础。（请注意，“BLS” 是缩写，这三个字母分别来自三位提出者的名字！）ETH 2.0 之所以采用这种新技术，主要是因为它可以高效地将多个签名聚合到一个签名中，直接促进 ETH 2.0 安全性的参与可行性。欲知更多信息，请参见 Carl Beekhuizen 的 文章 ，了解 ETH 2.0 中签名聚合的重要性（编者注：见文末超链接《Eth2 Staking 指南 #2》）。

虽然 BLS 签名对 Eth2 有很多好处，但是我们遇到的问题是，ETH 1.0 本身并不支持这种新的密码学元件，而且其底层数学逻辑对计算要求很高，致使我们无法在 EVM 中实行 BLS 签名。幸运的是，我们可以将计算逻辑添加为 “预编译” 部分，以此规避 EVM 在性能上的局限性 —— 通过硬编码算法让原生实现在 EVM 解释器之外被智能合约调用。

如何实现预编译？

以太坊协议的预编译部分属于稀缺资源，因此仅留给社区认为重要的计算逻辑。此外，预编译需要通过硬分叉来部署（因为它们会改变 EVM 的语义），因此协调成本很高。幸运的是，在当前的 EIP-2537 草案中，我们可以看到这些 BLS 预编译的相关工作正在推进。 EIP-2537 包括对 BLS12-381 曲线运算的预编译，以及 BLS 算法方案中使用的另一个被称为 “映射至曲线（map to curve）” 的高成本操作。如果你深入研究 BLS 算法方案的数学原理，你会发现需要利用某个机制才能将（你想要签署的）某个消息通过 “映射至曲线” 操作转化为椭圆曲线上的点。

预编译为我们带来了什么？

EIP-2537 预编译会通过提高保证金合约用户体验来帮助 ETH 2.0 上线，并为在 ETH 1.0 内构建 ETH 2.0 轻客户端奠定基础。BLS12-381 曲线本身可用于构建 zk-SNARKs ，连同其他区块链中使用的 BLS 为实现这些网络之间的互操作性铺平道路。

• 保证金合约用户体验

成为 ETH 2.0 信标链验证者的初始方法是，将 ETH 存入 ETH 1.0 上的智能合约（“保证金合约”）。为了节省 Gas 费用并最大程度上降低复杂性，保证金合约的主要功能就是为（在默克尔树上）的某笔存款提供密码学承诺，然后这样一个承诺就能在信标链上用作证明。重要的是，确认保证金所需的 BLS 签名并非在 ETH 1.0 链上验证的。测试网就因为出现漏洞而导致一系列 BLS 签名计算错误，丢失了一部分测试网 ETH 。为了在 ETH 1.0 链上对 BLS 签名进行验证（可以通过 EIP-2537 实现），我们可以编写一个 “转发” 智能合约来获取保证金数据，验证签名然后仅将保证金数据发送至保证金合约。这个功能虽然不是保障保证金合约安全性的必备条件，但它 确实能给那些与保证金合约交互的开发者带来心理上的慰藉。

• 在 EVM 内构建的 ETH 2.0 轻客户端

我们认为，在 ETH 1.0 链上构建 ETH 2.0 轻客户端之前，必须先让 ETH 1.0 “理解” ETH 2.0 采用的密码学技术。这样才有可能在智能合约中实现类似于 BTCRelay 的轻客户端。这种轻客户端一旦实现，将会成为沟通 ETH 1.0 和 ETH 2.0 网络 “桥梁” 的支柱，想想还有点小激动呢。通过这个双向桥梁，ETH 就可以在 ETH 1.0 和 ETH 2.0 网络之间转移，ETH 2.0 分片也可以作为一种具有高度可扩展性的数据层来支撑 ETH 1.0 上的二层架构（例如，optimistic rollups、zk-rollups 等等）。

激动归激动，不过要注意的是，在 EVM 内构建轻客户端来作为一种智能合约（而不是在 ETH 1.0 客户端层面实现轻客户端）或许不是让 ETH 1.0 理解 ETH 2.0 的最佳方法。此外，对 “双向桥梁” 的最新研究表明，考虑到 ETH 1.0 和 ETH 2.0 网络的其他安全参数，这种方法并不可行（还不如将 ETH 1.0 的状态分叉然后放到 ETH 2.0 分片上）。话虽如此，现在打好基础没什么坏处，而且随着后续研究的推进，ETH 1.0 和 ETH 2.0 的合并策略有可能改变。

• zk-SNARKs

创建 BLS12-381 曲线的目的是为了让 ZCash 能够使用更加高效的 zk-SNARKs （若想了解更多关于 BLS12-381 曲线的信息，可以查看上文链接）。此外，将该曲线添加到 EVM 上能够让以太坊验证这类 SNARKs ，通过零知识证明协议来实现具有隐私性和可扩展性的应用。

• 其他网络

一些 “新一代” 区块链（Filecoin、Chia、Cosmos 等等）也打算使用 BLS 签名方案；赋予 EVM 验证这些签名的原生功能，能够解锁更多互操作性用例，就像 ETH 1.0 和 ETH 2.0 之间那样。

宜早不宜迟

EIP-2537 中提议的所有用途都不会阻碍 ETH 2.0 上线。而且，保证金合约的优化方案会带来很好的效果；我们越早为互操作性奠定基础，就能越早开始创建这类应用的原型。该 EIP 有可能会放到接下来的以太坊柏林硬分叉中。如果你也想出一份力的话，可以在你喜欢的客户端上支持 EIP-2537 的实现 :) 。

感谢 Kobi Gurkan 和 Alex Vlasov 的审阅。

（完）

原文链接: https://medium.com/@ralexstokes/what-eth2-needs-from-eth1-over-the-next-six-months-86b01863746 作者: Alex Stokes 翻译&校对: 闵敏 & 阿剑

本文由原作者授权 EthFans 翻译及再出版。