以太坊下一次分叉的重点，这篇文章看够了吗？

作者| 秦晓峰

编辑| 陆晓明

出品 | Odaily星球日报

在过去的两周里，由于众多核心以太坊开发人员前往多伦多参加扩展会议，每周的电话会议已被取消。 本周五晚上，以太坊核心开发者将继续召开电话会议，重点关注伊斯坦布尔（Istanbul）硬分叉，并决定最终提案（EIP）。

从设计的角度来看，伊斯坦布尔（Istanbul）硬分叉是以太坊走向宁静阶段的最后一次分叉（不会产生新的代币）。 同时，本次分叉的提案涉及到很多问题（Progpow、state leasing、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：在没有脏图的情况下测量 SSTORE 的净 gas 成本

EIP-1344：添加 ChainID 操作码

EIP-1352：为预编译/系统合约指定受限地址范围

EIP-1380：降低自调用的 gas 成本

EIP-1559：改变 ETH 1.0 链的汽油费

EIP-1965：检查 chainID 在特定区块号是否有效的方法

EIP-1702：通用账户版本控制方案

EIP-1706：当 gas 费低时禁用 SSTORE

EIP-1803：重命名操作码

EIP-1829：椭圆曲线线性组合的预编译

EIP-1884：重新定义依赖于 trie-size 的操作码

EIP-1930：gas call标准更严格，gas calls不够可以回收。

EIP-1985：一些 EVM 参数的合理限制

EIP-1959：检查 chainID 是否是 chainID 历史的一部分的新操作码

EIP-1962：EC 算术和与运行时定义的配对（取代 EIP-1829）

EIP-2014：扩展状态预言机

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 算法，称为“Progressive PoW”或 ProgPoW，旨在更好地利用 GPU 特定的计算能力。

此前，开发者在开源赏金平台 Gitcoin 上通过众筹筹集了 50,000 DAI（约合 50,000 美元）作为 ProgPoW 代码审计资金。 但由于该代码至今未经过第三方机构审核，在5月24日的开发者大会上宣布延期。

同样延迟的还有 EIP-1559，这是一项改变以太坊交易手续费模型的提案以太坊分叉是怎么回事，但由于过于复杂而被开发者“放弃”。

在这些方案中，“国有租赁”尤为耀眼。

“状态租赁”的初衷是以太坊的状态规模已经非常大了。 如果它继续以目前的速度增长，以太坊网络将变得极其臃肿。 而我们低估了存储的长期成本，可以近似建模为：字节*时间，所以我们有必要对以太坊目前的状态设计做出改变。

根据以太坊 2.0 的路线图，ETH 2.0 也将部署状态租赁（目前计划在 phase 2）。 是否在ETH1.0上重新开发相信是本周五电话会议的热门话题。

删除提议

上述提案也引起了社区的广泛讨论。 很多开发者质疑，有些提议是多余的以太坊分叉是怎么回事，应该删除。

开发人员 Alex Beregszaszi 说：“我很困惑。我认为应该再次提出冲突的、相邻的、重复的 EIP（有 3 个或 4 个 EIP 都是关于 chainid、重新定价、SWAP 和 DUP）的建议。之前有一些共识。如果他们没有明确定义，那么争论 EIP 就没有意义了。”

截至目前，提案审核流程只进行了很短的时间，核心开发者能否在本周五给出最终答案还有待考证。

Alex认为，有些提案实际上并不需要在硬分叉中进行，可以通过联系以太坊客户端开发者来解决。 “那些（EIP）的作者不应该只是试图自己解决，而是联系一些相关的开发人员，比如客户端开发人员，来审查他们的想法。如果大家等核心开发人员开电话会议来讨论实现，我们会没有足够的时间来讨论所有这些提议。”

针对上述EIP，开发者社区（点击进入）目前正在讨论减量，以减轻核心开发者的工作量，提高效率。

硬分叉时间表

除了关注提案，伊斯坦布尔硬分叉的时机也值得关注。

根据前硬分叉协调员 Afri Schoedon（现已离职）制定的时间表，硬分叉过程分为“固定的九个月周期”。 伊斯坦布尔硬分叉时间表如下：

2019-05-17（星期五）：接受“伊斯坦布尔”提案的截止日期

2019-07-19（周五）：主客户端实现截止

2019-08-14（星期三）：测试网（（Ropsten、Gorli或ad hoc testnet））升级时间

2019-10-16（周三）：主网升级时间（“伊斯坦布尔”）

第一阶段提案征集已经完成，下一步就是“主客户端实现”。 所谓的“主要客户端实现”，将接受的 EPI 合并到现有的以太坊客户端中，类似于将代码放在一起以便对其进行全面测试。

不过，按照以太坊一贯的基调，此次硬分叉“按时”完成的可能性并不高。 在之前的君士坦丁堡分叉中，存在代码漏洞，导致分叉延迟。

以太坊基金会的获得者 Alexey Akhunov 在 Gitter 聊天室中表示，大家应该考虑“截止日期”，不应该在截止日期之前到期，一切都建立在做好工作的基础上。

“我自己也在想这个deadline的目的是什么？” Akhunov 说，“因为这是第一次引入这么多东西（在分叉中），我们来这里是为了确保我们所做的是正当的理由，而不是因为‘有人这么说’。”