以太坊团队备战ETH 2首次硬分叉
摘要: 研发不懂以太坊怎么办?
如果不及早解决,MEV这项顽疾必将给未来的eth2带来严重影响。
2020 年 12 月 1 日,eth2 的第 0 阶段终于登陆主网,这也成为我们整个职业生涯中最值得纪念的一天。我们非常清楚,这时我们的工作才正式进入正轨。为此,我们决定将 Q1 设定为一段专注于优化、提升稳定性并改进用户体验的修复性时期。社区中的每一条批评意见,都将成为我们推进 eth2 更上一层楼的重要助力。
我们坚信,Prysm 终将达到“发布之后、自行运作”的良好态势。验证机制本身高度稳定,除安全相关软件更新之外几乎无需任何额外干预,借此尽可能降低其“存在感”。我们承认,Prysm 在发布之初仍有大量优化问题需要解决,必须保证它能够随验证方数量的增长而持续发展。下面来看年初至今 Prysm 达成的几项小小成果:
-
持续对证明聚合进行优化,保证 Prysm 不断提升资源利用效率与盈利能力
-
对拥塞及证明处理做出重大优化,最大程度降低利益相关方忽略验证方提案或投票的可能性
-
高度关注稳定性与文档记录,并保证 Prysm 始终“正常运行”。未来的发展道路还很漫长,但与最初发布的主网相比,我们对当前最新版本的稳定性已经抱有极强的信心。
-
进一步关注 P2P 网络、入口点、对等管理与链同步层面的安全性与健壮性。
-
改进代码库中各重要组件,保证其经受得住时间的考验。具体涵盖 slasher、slashing 保护,并建立起能够适应全部实现需求的 eth2.0 api 标准
在 Chainstack 的开发者活动报告中,Prysm 占据了相当比例的篇幅。这份报告着重介绍了我们项目的贡献情况与 repo 发展态势,成功吸引到不少新的外部贡献力量。
2021 Eth2 客户发展报告,来源:Chainstack
从 Q2 开始,我们的团队将加大工作力度,将每位成员对以太坊项目的发展愿景变为现实。下一阶段,我们主要将重点关注以下几个方面。
我们已经在 eth 2 的分片部分上完成大量工作。但很明显,社区仍然高度重视未来项目将如何由 eth 1 合并至 eth 2,确保发挥权益证明机制的一切潜能。
作为其中一种方法选项,我们打算将智能合约、交易、EVM、钱包以及大家所熟悉并喜爱的其他各类元素转移至权益证明引擎之下。各区块将按 12 秒固定时间周期在区块链内生成,证明机制则不再由矿工们实现,而是被权益证明方提供的证据所代替。要顺利完成这项工作,负责维护 go-ethereum 等 eth1 客户端的开发者与 eth2 开发团队必须建立起紧密的协同合作关系。
目前,我们主要关注两大“合并”实现提案,二者也都要求在 eth1 与 eth2 节点之间建立通信。之所以选择二者兼容,是因为双方并非简单的彼此替代、而更该说是各擅胜场:eth2 节点处理权益证明与验证方注册表,而 eth1 节点则处理交易及 EVM。如此一来,我们就可以利用对 eth1 核心协议的充分理解显著加快“合并”速度。
来源:https://notes.ethereum.org/m9IX3OkkTveXCCOSzGkUiw
我们同时也关注 Vitalik 提出的第二项提案,即快速合并,也被称为共识交换。Mikhail 曾提交过一项相关 pull 请求,在社区中获得了大量支持与积极反馈。客户端团队正在研究这项提案,并快速进行概念验证。在 Prysm 方面,我们已经开始对快速合并选项的工作量与资源预算进行评估。下面来看其中几项要点:
-
应用载荷处理。当信标节点接收到信标区块时,将对该区块中的 eth1 组件进行验证。接下来,该信标节点面向对应的 eth1 节点调用 eth2_insert_block。
-
应用载荷生成。当信标节点生成信标区块时,会调用 eth2_produce_block 以接收来自 eth1 节点的应用载荷。此应用载荷随后将被打包至信标区块当中。
-
在信标状态端,我们将为应用状态 root 与 block 哈希添加两个字段,用以验证应用载荷。
-
在信标区块端,我们将添加应用载荷与交易字段。
-
我们需要使用帮助程序将各类具体类型统一格式化为十六进制字符串,以便以 json 的形式通过 rpc 与 eth1 节点通信。
今年夏季,我们还有另一项重要的网络升级计划:Altair。此升级将极大简化现有协议,通过更好的数据结构计算 eth 2 中各时段验证方的参与、奖励与惩罚活动。此外,本轮升级还将向 eth2 light 客户敞开大门。考虑到这是我们的首次升级,因此团队一直在认真思考如何调整 Prysm repo 以适应后续升级,并保证不对代码质量造成损害。
我们首先从一项跟踪问题起步,研究 Prysm 中的新型信标状态 Altair 软件包。上游 ethereumapi repo 则负责定义大部分新型数据结构,例如同步委员会、信标区块以及 Altair 中的更多数据结构。目前核心处理逻辑已经基本完成,我们只需将其与新的信标状态 Altair 合并即可。我们还将同步引入 Altair 规范测试以保证升级工作的全面合规。除了 Q2 的硬分叉之外,还有更多更新值得大家期待。
我们已经意识到,矿工可提取价值(Miner Extractable Value,简称 MEV)已经成为以太坊当前面临的头号难题之一。
如果不及早解决,这项顽疾必将给未来的 eth2 带来严重影响。这里稍做解释,MEV 导致共识参与者在下令向以太坊中添加大宗交易区块方面拥有不公平的优势。换句话说,目前的矿工们有权在必要时,在以太坊上重组并先于他人执行交易,这显然会影响以太坊的声誉与吸引力,同时也将进一步扩大现已存在的“付费插队”市场。
“付费插队”市场规模图,来源:Flasbots 团队
Flashbots 小组目前正全力研究 MEV 问题。在 eth 2 当中,这种动态权力将从矿工转向验证方,但其中的激励措施仍然保持不变。考虑到 eth 2 将采用权益证明机制,且协议中包含强大的“链最终性”概念,我们必须认真考虑可能引发的开放性问题。
目前,我们团队正在与 Flashbots 合作,确定如何在 eth2 上妥善解决 MEV 隐患,进而改善以太坊的未来使用体验。
Slashing 机制已经成为以太坊权益证明中不可或缺的必要保障方法。目前,Prysm slasher 已然拥有不错的效果,但仍可能在遭遇网络不稳定及最终性停滞时导致数据丢失。但很明显,这个时段才是捕捉数据以实现事后取证的关键阶段。
必须承认,我们的初版 Slasher 在很多重要设计考量上都缺乏关注。过去一个季度以来,我们投入大量时间来设计、修改并编写能够在新 Slasher 实现中带来提升的高质量代码。在参考了 Protolambdagithub.com/protolambda/eth2-surround 说明文档与 Sigma Prime 在 Rust 上构建的 Slasher 成果之后,我们决定以相同的第一原理为基础设计 Prysm Slasher。相关测试将在几周内快速启动。
在 mainnet 之前,我们曾发布过 Prysm Web UI,希望让不熟悉命令行的用户们也能轻松访问 eth2 并享受持币生息收益。
在“测试版”的发布公告(https://medium.com/prysmatic-labs/prysm-eth2-client-web-interface-now-live-feb278f4aa15)当中,我们发布了可通过 -web 标记运行 Prysm 的选项,大家可以通过小型 Web 应用执行验证程序中的一系列重要任务,例如导入验证密钥、查看近期性能并检查关于网络的某些特定信息。但在此之后,面对优化、安全性及稳定性等其他高优先级事务的压力,我们始终腾不出手来进一步改善用户体验。
在不久的将来,我们将着手发布 Prysm Web UI 的 1.0 版本,其将在功能方面与 Prysm 验证程序 CLI 保持一致。也就是说,您之前使用验证程序通过命令行执行的所有操作,届时都可以通过 Web UI 顺利完成!
这套 Web UI 的目标是全面替代 CLI 实现 Prysm 与验证程序管理。但请注意,目前它还不能算是区块浏览器。我们当前的目标是不断提升其实用性,主要强调其中验证程序软件的操作流程;查看网络统计信息暂时只是附加功能。Prysm Web V1 计划于今年第二季度内正式发布。
整个以太坊团队的核心开发理念,并非掌握大量专业术语或者晦涩的知识表达,而更多强调良好的问题解决能力与团队合作能力。在加入 Prysmatic Labs 之前,当前团队中的不少成员根本不熟悉以太坊。没关系,我们拥有相当深厚的软件设计与开发专业知识积累,足以为协议编写出良好的代码成果。
我们的日常工作主要集中在为 eth2 设计底层架构方面。我们坚信,只要能够通过全面的开发者 Wiki 提供关键 Prysm 知识,每个人都能更好地为开源项目服务。Wiki 提供简单易读的素材,可帮助大家快速了解 Prysm 中的各类设计决策与实现流程。Wiki 还将包含 repo 中某些特定部分的设计讨论与会议记录。
我们计划将文档门户网站 https://docs.prylabs.network 转换为 Prysm 的规范参考平台,后续还会将其设置为团队代码组件的交流枢纽。在开发者 Wiki 的指引下,相信新朋友们能够更好地理解如何加入项目贡献、以及我们怎样解决项目中最为棘手的种种难题。
作者简介:
Raul Jordan,Prysmatic Labs 联合创始人
原文链接:
https://medium.com/prysmatic-labs/eth2-march-development-update-prysmatic-labs-f6c72b9e0dda
作者:区块链前哨;来自链得得内容开放平台“得得号”,本文仅代表作者观点,不代表链得得官方立场凡“得得号”文章,原创性和内容的真实性由投稿人保证,如果稿件因抄袭、作假等行为导致的法律后果,由投稿人本人负责得得号平台发布文章,如有侵权、违规及其他不当言论内容,请广大读者监督,一经证实,平台会立即下线。如遇文章内容问题,请发送至邮箱:linggeqi@chaindd.com
评论(0)
Oh! no
您是否确认要删除该条评论吗?