以太坊网络就像所有的公地一样，也存在许多维护上的问题：状态数据的不断膨胀、日益变长的同步时间、全节点的热度也越来越小。如果放任不管，这些问题会给以太坊 1.x 的未来带来严重威胁。
这些问题一开始得到核心开发者和社区开发者的严肃对待是在 Devcon4 的时候，而对当前以太坊协议升级方向的研究被冠以 “以太坊 1.x” 的代号。但最近，1.x 的研究陷入停滞，因为越来越多人把兴趣转移到以太坊 2.0 上——这也是可以理解的，Eth2.0 毕竟更迷人。
但是，以太坊 2.0（Serenity 宁静）还要再等 2～3 年才能完全实现，其中 Phase 0 和 Phase 1 会在 1～2 年实现，而 Phase 2 可能要 2022 年才会到来。
同时，状态数据膨胀、同步时间变长、网络健康度下降等问题，都是 很迫切的。此外，迄今为止仍未有将当前的以太坊链迁移成为 Eth2.0 的一个执行环境的明确计划。
今年在大阪跟一些客户端开发者会面之后，我和其他人深入讨论了这些问题，而且我们无一例外都同意，1.x 的研究和升级都是有意义的。
我们一起确定了一个新的方向和计划，希望能在奔向宁静的同时保证以太坊 1.0 链的存活和健康。
我们准备：
这是一项复杂的工作，无疑需要许多团队的合作。但在本周一次破冰视频会议之后，我们怀着一腔孤勇揭开了以太坊 1.x 研究的新篇章。
起因
故事还要从 2018 年年头、Trinity 客户端的第一次发布说起。Trinity 是一款用 Python 写成的以太坊客户端。因为 Python 是一门解释性语言，跟 Go 或者 Rust 这样的同侪在性能上竞争时是不可能胜出的；但是它有一些很好的特性。在第一个试用版发布之后，我们在实现区块链数据快速同步上花了不少功夫，但只得到一个令人沮丧的结论：这款客户端的性能看来是永远做不到让人们去用它了，没人愿意花几周的时间等待他们的节点同步完成。“快速同步” 行不通以后，我们开始找新事情做。在接下来的 9 个月里，我们基于 “能不能完全回避掉这个问题” 的想法不断迭代。要是真能回避掉这个问题，我们就能很快让客户端上线工作了，而同步完成、上线工作这个活动在过去是要花好几个时间甚至几天来完成的。2019 年 9 月的某一天，我们做出了一个原型，我们叫它 “beam sync（主梁同步）”。Beam sync 不为别的，只是想提升客户端的用户体验。我们希望客户端能尽可能快递启动并开始运行——即使硬件条件理想，“快速同步” 也快不到在 4 小时内完成同步。Beam sync 受到 “无状态客户端” 概念的启发：使用一部分叫做 “区块见证（block witness）” 的数据，beam sync 在同步时不会像 “快速同步” 那样下载完整的状态，只会传入完成状态变换需要用到的数据。渐渐地，随着同步过程触及到越来越多的状态，客户端就能重建出完整的区块链状态，并切换到完全同步模式。因为只提取那些执行区块需要用到的数据，并且立即予以执行，使用主梁同步的节点可以几乎即时地启动并开始运行（虽然还远未达到最优状态，但非正式测试证明：下载完所有区块头后只需约 5 分钟就能开始运行）。因为 beam sync 背后的概念得到为完全的验证，Trinity 团队已经从悄悄地研究转向搞出一个可用测试版的实验。我们计划在 2020 年第二季度发布 beta 版。
从 Beam Sync 到无状态客户端
Alexey Akhunov 花了很多时间在尝试解决状态爆炸问题上。最近，他得出结论，认为无状态客户端是最可行的办法，可以摒弃更具争议性的方向比如状态租金。（编者注：请参看文末超链接）而 Beam sync 本质上也是从一个无状态的模式开始，随着区块逐渐下载到本地数据库而逐渐过渡到富状态模式。有了 Beam sync 在线，我们很快就能勾勒出一条清晰的路径、实现一个善于提供无状态客户端所需原料的网络。而且无状态客户端在理论上是兼容于当前的客户端模式的，这就意味 Alexey 的研究现成就能派上用场，它只会给网络带来一些增量上的改进，而不需要大规模的、有争议的协议层改进。
从 1.x 到 2.0
一个无状态的 1.x 网络对以太坊 2.0 来说也是很重要的：验证者会被混洗到不懂的分片上，所以他们得能够非常快速地重建出一个分片的最新状态——无状态的执行环境看起来是最可行的跨分片验证方案。正因如此，能够可靠地运行在无状态客户端上，可能会变成以太坊 1.x 网络迁移成 2.0 某个分片的前提条件。所以，致力于以太坊 1.x 的无状态执行方案，我们也是在为 1.x 的平滑迁移做必要的准备工作。换句话来说：今日的无状态性，日后的宁静。
正式化 1.x 研究
在 Devcon 的最后一天，我置身于一场讨论，关于如何让 1.x 的研究工作再度启动。在场的每个人都知道还有问题，并都表示有兴趣解决问题。这是最后一件让我高兴的事。如果 Trinity 和其他客户端团队能够提升客户端的组网元件并支持 beam sync，我们就完全能让以太坊网络实现无状态模式。以太坊 1.x 的无状态客户端，反过来，也会在葡萄成熟时，为协议迁移成以太坊 2.0 上的一个执行环境做好准备。从开发以太坊 2.0 客户端的 9 支（及更多）团队上得到启示，我们希望在不同团队间实现深度的合作、形成一个清晰的、高远的 Eth1.x 愿景，而且是可以切分成具体成果的愿景。我们会形成定期的视频会议，而且接下来这个春天我们会组织一个以太坊 1.x 研究峰会。当下，加入这场运动的最好办法就是参与 etherum research 论坛上以太坊 1.x 板块上的讨论。如果你有兴趣加入 1.x 研究复兴工作，请介绍你自己，要求我们拉你进 telegram 群，然后加入到我们下一次视频会议中来（暂时计划是从本文发布开始每两周一次会议）。以太坊 1.x 长长久久！
（完）
微信扫一扫 
