过去两周,由于众多的以太坊核心开发者奔赴多伦多参加以太坊扩展(scaling)会议,每周一次的电话会议被迫取消。本周五晚,以太坊核心开发者将继续举行电话会议,议题抓要围绕伊斯坦布尔(Istanbul)硬分叉,并决定最终入选的提案(EIP)。

原文标题:《以太坊下次分叉重点,看这篇就够了?》
作者:Odaily 星球日报 秦晓峰
编辑:卢晓明

从设计层面来说,伊斯坦布尔(Istanbul)硬分叉是以太坊将走向 Serenity (宁静)阶段最后的分叉(不会产生新代币)。同时,本次分叉的提案涉及问题众多(Progpow、状态租赁、chainID 等)。如果一些问题在本次分叉中得不到解决,将对以太坊后续生态发展影响重大。另据以太坊 2.0 研究员 Justin Drake 所说,以太坊 2.0 阶段 0 将于 2020 年 1 月 3 日发布。

推迟 ProgPoW,聚焦「状态租赁」

上个月 17 号,伊斯坦布尔硬分叉提案(EIP)征集结束,共收集了 29 个提案。这些提案分别是:

  • EIP-615:EVM 的子程序和静态跳转
  • EIP-663:无限制的 SWAP 和 DUP 指令
  • EIP-1057:ProgPoW,一种程序化的工作证明
  • EIP-1108:降低 alt_bn128 预编译 gas 成本
  • EIP-1109:PRECOMPILEDCALL 操作码(删除预编译合同的 CALL 费用)
  • EIP-1283:没有 dirty maps,测量 SSTORE 的净 gas 成本
  • EIP-1344:添加 ChainID 操作码
  • EIP-1352:为预编译 / 系统合同指定受限制的地址范围
  • EIP-1380:减少自我呼叫的 gas 成本
  • EIP-1559:改变 ETH 1.0 链 gas 费用
  • EIP-1965:检查 chainID 在特定块号处是否有效的方法
  • EIP-1702:广义帐户版本控制方案
  • EIP-1706:当 gas 费用低下时,禁用 SSTORE
  • EIP-1803:重命名操作码
  • EIP-1829:椭圆曲线线性组合( Elliptic Curve Linear Combinations)的预编译
  • EIP-1884:重新定义依赖于 trie-size 的操作码
  • EIP-1930:Gas 呼叫标准严格化,如果没有足够的 gas 调用可以复原。
  • EIP-1985:某些 EVM 参数的合理极限
  • EIP-1959:新的操作码,检查 chainID 是否是 chainID 历史的一部分
  • EIP-1962:EC 算术和与运行时定义的配对(取代 EIP-1829)
  • EIP-2014:扩展状态 Oracle
  • EIP-2026:状态租赁 H - 固定帐户预付款
  • EIP-2027:状态租赁 C - 核算净合同规模
  • EIP-2028:降低 Calldata Gas 成本
  • EIP-2029:状态租赁 A - 状态柜台合约
  • EIP-2031:状态租赁 B--净交易柜台
  • EIP-2035:无状态客户端 - 重新定价 SLOAD 和 SSTORE 以支付块证明
  • EIP-2045:EVM 操作码粒子的 gas 成本
  • EIP-2046:降低对预编译程序进行静态调用的 gas 成本

此前的核心开发者电话会议,临时批准的提案是 EIP 1108 —— 提议对以太坊网络的 Gas 费用进行了微小改动。不过,开发人员强调,该提案虽然获得批准,但需要在之后的核心开发人员会议上提交基准数据。

另外,备受关注提案 EIP-1057 可能被推迟。EIP 1057 提出了一种改进的 PoW 算法,称为「渐进式 PoW」或 ProgPoW,旨在更好地利用 GPU 特定的计算功能。

此前,开发人员通过开源赏金平台 Gitcoin 进行众筹募集了 5 万 DAI (约合 5 万美元),作为 ProgPoW 代码审计资金。但由于该代码至今并未找到第三方机构进行审计,因此在 5 月 24 日的开发者会议上被宣布推迟。

同样被推迟的还有 EIP-1559,该提案旨在改变以太坊交易费模式,但由于过于复杂,被开发者「抛弃」。

在这些提案中,「状态租赁」显得格外耀眼。

「状态租赁」设计初衷是,以太坊的状态大小当前已经是非常庞大了,如果其继续以目前的速度增长,以太坊网络将变得异常臃肿。而我们正在低估存储的长期成本,存储成本可以近似地建模为:字节*时间,因此,我们有必要对当前以太坊的状态设计进行改动。

根据以太坊 2.0 的路线图来看,状态租赁也将在 ETH 2.0 (目前的计划是在阶段 2)进行部署。到底要不要在 ETH1.0 重新耗时费力地开发,相信也会成为本周五电话会议的讨论热点。

删减提案

上述提案也在社群中也引起广泛讨论,不少开发者质疑有些提案内容重复,应该进行删减。

开发者 Alex Beregszaszi 表示:「我很困惑。我认为那些提出相互冲突、相邻、重复的 EIP (有 3 到 4 个 EIPs 都是关于 chainid、重新定价、SWAP 和 DUP 的)的建议应该在再次提出之前达成一些共识。如果他们没有明确规定,那么争论 EIP 就没有什么意义。」

直到目前,提案审计进程仅仅进行了一小段,核心开发者们能否在本周五给出最终答案,仍然悬而未决。

Alex 认为,一些提案其实并不需要在硬分叉中进行,可以联系以太坊客户端开发人员解决。「那些(EIP)作者不应该只是试图自己解决它,而是要联系一些相关的开发人员,比如客户端开发人员来审查他们的想法。如果每个人都等着核心开发者召开电话会议讨论实施,我们将没有足够的时间讨论所有这些提案。」

对于上面的 EIP,开发者社群(点击进入)目前也在讨论进行缩减,以降低核心开发者工作量,提高效率。

硬分叉时间表

除了关注提案,关于伊斯坦布尔硬分叉的时间安排也同样值得关注。

根据前硬分叉协调员 Afri Schoedon (已离开)制定的时间表,硬分叉过程分解为「一个固定的 9 个月周期」。伊斯坦布尔硬分叉时间表如下:

  • 2019-05-17(星期五):接受「伊斯坦布尔」提案截止日期
  • 2019-07-19(星期五):主要客户端实现的截止日期
  • 2019-08-14(星期三):测试网(Ropsten、Gorli 或特设 testnet)升级时间
  • 2019-10-16(星期三):主网升级时间「伊斯坦布尔」

目前已经完成了第一阶段提案收集,接下来要进行的则是「主要客户端实现」。所谓的「主要客户端实现」,即将已接受的 EPI 合并到以太坊现有客户端中,这一步类似于将代码组合在一起,这样就可以对其进行全面测试。

不过,按照以太坊一贯的调性,这次硬分叉「按时」完成的可能性并不高。此前的君士坦丁堡分叉中,就出现了代码漏洞,导致分叉延期。

以太坊基金会的受助人 Alexey Akhunov 在 Gitter 聊天室中说道,每个人都应该考虑「截止日期」,不应该为了截止而截至,一切以做好工作为前提。

「我自己也在思考这个截止日期的目的是什么?」Akhunov 说,「因为这是第一次(在分叉中)引入这么多东西,所以我们来这里是为了确保我们所做的事情是有原因的,而不是因为‘有人这么说’。」

来源链接:www.odaily.com