伊斯坦布尔
以太坊伊斯坦布尔升级之核心改变：引入 zk-SNARKs 技术
项目 • leek 发表了文章 • 2019-11-21 17:51
据以太坊基金会官网今日发布的消息，以太坊网络将在区块高度达到 9,069,000 时进行升级，预计将于 2019 年 12 月 7 日左右发生（注：确切日期可能会因不同的区块时间和时区而发生变化）。
本次以太坊网络升级的代号是“伊斯坦布尔（Istanbul）” 。恍如昨日，现在仍记得上次的以太坊升级代号为君士坦丁堡。此次以太坊网络升级隶属于 ETH1.0 范围内，同时也预示着我们离 ETH2.0 越来越近！
接下来，我们一起来看一下这次的伊斯坦布尔升级对以太坊网络做了哪些改变。
在完成这次升级之后，以太坊网络将会有一些变化和调整，主要体现在以下4点：
1、使操作码的成本与其计算成本保持一致，并提高拒绝服务攻击的抵抗性；
2、提高基于SNARKs和STARKs的二层（layer 2）解决方案的吞吐量；
3、使以太坊和Zcash能够互操作；
4、允许合约引入更多创造性函数。
伊斯坦布尔实施的变更是使用以太坊改进建议（EIP）定义的，EIP 描述了以太坊平台的标准，包括核心协议规范、客户端 API 和合约标准。考虑到过去一年以太坊社区的发展，这次升级是以太坊历史上社区提案规模最大的一次，有超过 30 个 EIP 被提议纳入这一升级，开发者们对其中的每一个 EIP 都进行了讨论和辩论，经过深思熟虑，其中有 6 个 EIP 被认为是适当的，它们分别是：
1、EIP-152：添加 Blake2 压缩函数“F”预编译
添加在以太坊合约中验证 Equihash PoW 的能力。这将启用 Zcash 和以太坊之间的中继和原子互换交易。
2、EIP-1108：降低 alt_bn128 预编译 gas 成本
这使得 zk-SNARKs 更便宜，允许构建更便宜的扩展和隐私应用。参见 Matter labs、 Aztec Protocol、Rollup 以及 Zether 的示例。
3、EIP-1344: ChainID 操作码
为合约添加一种跟踪其所在以太坊链的方法。
4、EIP-1884：操作码的重新定价
更改一些 EVM 操作码的成本，以防止垃圾交易攻击，并更好地平衡每个区块中的计算量。以太坊中每次操作必须支付的金额，通常与该操作所需的计算量相匹配。这种变化增加了运算密集型操作码（SLOAD、BALANCE 和 EXTCODEHASH）的 gas 开销，而这些操作码目前很便宜。
5、EIP-2028：降低交易数据 gas 成本
通过降低在交易中调用数据的成本，使 zk-SNARKs 和 zk-STARKs 更便宜。这将提高第 2 层解决方案的吞吐量。请参见 Starkware 以获取示例。
6、EIP-2200：SSTORE 操作的净 gas 计量
更改 EVM 中存储的成本计算，并使合约能够引入新函数，包括重入锁（ re-entry locks）和同一合约多次发送（same-contract multi-send）。
根据上述被此次升级采纳的 EIP 内容，我们可以发现：此次升级主要是为以太坊网络引入了 zk-SNARKs（零知识证明）技术，直接提高了以太坊网络的 TPS；同时，也降低了某些运算所需的 gas 费。关于这次的以太坊伊斯坦布尔升级，以太坊生态开发者和 DeFi 用户是非常值得期待的，翘首以待！
伊斯坦布尔升级确实为以太坊生态用户带来了一些显而易见的改变，不仅提高了以太坊网络运行效率，而且还直接或者间接的降低了开发者和用户使用以太坊网络的成本，我们非常高兴这些发生在以太坊网络上面的实质性变化。此外，需要提醒大家的是：作为 ETH 持币人或者以太坊 DeFi 用户，我们无需执行任何操作，静待伊斯坦布尔升级时间的到来就行了！
祝好，以太坊！ 查看全部
本次以太坊网络升级的代号是“伊斯坦布尔（Istanbul）” 。恍如昨日，现在仍记得上次的以太坊升级代号为君士坦丁堡。此次以太坊网络升级隶属于 ETH1.0 范围内，同时也预示着我们离 ETH2.0 越来越近！
接下来，我们一起来看一下这次的伊斯坦布尔升级对以太坊网络做了哪些改变。
在完成这次升级之后，以太坊网络将会有一些变化和调整，主要体现在以下4点：
1、使操作码的成本与其计算成本保持一致，并提高拒绝服务攻击的抵抗性；
2、提高基于SNARKs和STARKs的二层（layer 2）解决方案的吞吐量；
3、使以太坊和Zcash能够互操作；
4、允许合约引入更多创造性函数。
伊斯坦布尔实施的变更是使用以太坊改进建议（EIP）定义的，EIP 描述了以太坊平台的标准，包括核心协议规范、客户端 API 和合约标准。考虑到过去一年以太坊社区的发展，这次升级是以太坊历史上社区提案规模最大的一次，有超过 30 个 EIP 被提议纳入这一升级，开发者们对其中的每一个 EIP 都进行了讨论和辩论，经过深思熟虑，其中有 6 个 EIP 被认为是适当的，它们分别是：
1、EIP-152：添加 Blake2 压缩函数“F”预编译
添加在以太坊合约中验证 Equihash PoW 的能力。这将启用 Zcash 和以太坊之间的中继和原子互换交易。
2、EIP-1108：降低 alt_bn128 预编译 gas 成本
这使得 zk-SNARKs 更便宜，允许构建更便宜的扩展和隐私应用。参见 Matter labs、 Aztec Protocol、Rollup 以及 Zether 的示例。
3、EIP-1344: ChainID 操作码
为合约添加一种跟踪其所在以太坊链的方法。
4、EIP-1884：操作码的重新定价
更改一些 EVM 操作码的成本，以防止垃圾交易攻击，并更好地平衡每个区块中的计算量。以太坊中每次操作必须支付的金额，通常与该操作所需的计算量相匹配。这种变化增加了运算密集型操作码（SLOAD、BALANCE 和 EXTCODEHASH）的 gas 开销，而这些操作码目前很便宜。
5、EIP-2028：降低交易数据 gas 成本
通过降低在交易中调用数据的成本，使 zk-SNARKs 和 zk-STARKs 更便宜。这将提高第 2 层解决方案的吞吐量。请参见 Starkware 以获取示例。
6、EIP-2200：SSTORE 操作的净 gas 计量
更改 EVM 中存储的成本计算，并使合约能够引入新函数，包括重入锁（ re-entry locks）和同一合约多次发送（same-contract multi-send）。
根据上述被此次升级采纳的 EIP 内容，我们可以发现：此次升级主要是为以太坊网络引入了 zk-SNARKs（零知识证明）技术，直接提高了以太坊网络的 TPS；同时，也降低了某些运算所需的 gas 费。关于这次的以太坊伊斯坦布尔升级，以太坊生态开发者和 DeFi 用户是非常值得期待的，翘首以待！
伊斯坦布尔升级确实为以太坊生态用户带来了一些显而易见的改变，不仅提高了以太坊网络运行效率，而且还直接或者间接的降低了开发者和用户使用以太坊网络的成本，我们非常高兴这些发生在以太坊网络上面的实质性变化。此外，需要提醒大家的是：作为 ETH 持币人或者以太坊 DeFi 用户，我们无需执行任何操作，静待伊斯坦布尔升级时间的到来就行了！
祝好，以太坊！ 查看全部
据以太坊基金会官网今日发布的消息，以太坊网络将在区块高度达到 9,069,000 时进行升级，预计将于 2019 年 12 月 7 日左右发生（注：确切日期可能会因不同的区块时间和时区而发生变化）。
本次以太坊网络升级的代号是“伊斯坦布尔（Istanbul）” 。恍如昨日，现在仍记得上次的以太坊升级代号为君士坦丁堡。此次以太坊网络升级隶属于 ETH1.0 范围内，同时也预示着我们离 ETH2.0 越来越近！
接下来，我们一起来看一下这次的伊斯坦布尔升级对以太坊网络做了哪些改变。
在完成这次升级之后，以太坊网络将会有一些变化和调整，主要体现在以下4点：
1、使操作码的成本与其计算成本保持一致，并提高拒绝服务攻击的抵抗性；
2、提高基于SNARKs和STARKs的二层（layer 2）解决方案的吞吐量；
3、使以太坊和Zcash能够互操作；
4、允许合约引入更多创造性函数。
伊斯坦布尔实施的变更是使用以太坊改进建议（EIP）定义的，EIP 描述了以太坊平台的标准，包括核心协议规范、客户端 API 和合约标准。考虑到过去一年以太坊社区的发展，这次升级是以太坊历史上社区提案规模最大的一次，有超过 30 个 EIP 被提议纳入这一升级，开发者们对其中的每一个 EIP 都进行了讨论和辩论，经过深思熟虑，其中有 6 个 EIP 被认为是适当的，它们分别是：
1、EIP-152：添加 Blake2 压缩函数“F”预编译
添加在以太坊合约中验证 Equihash PoW 的能力。这将启用 Zcash 和以太坊之间的中继和原子互换交易。
2、EIP-1108：降低 alt_bn128 预编译 gas 成本
这使得 zk-SNARKs 更便宜，允许构建更便宜的扩展和隐私应用。参见 Matter labs、 Aztec Protocol、Rollup 以及 Zether 的示例。
3、EIP-1344: ChainID 操作码
为合约添加一种跟踪其所在以太坊链的方法。
4、EIP-1884：操作码的重新定价
更改一些 EVM 操作码的成本，以防止垃圾交易攻击，并更好地平衡每个区块中的计算量。以太坊中每次操作必须支付的金额，通常与该操作所需的计算量相匹配。这种变化增加了运算密集型操作码（SLOAD、BALANCE 和 EXTCODEHASH）的 gas 开销，而这些操作码目前很便宜。
5、EIP-2028：降低交易数据 gas 成本
通过降低在交易中调用数据的成本，使 zk-SNARKs 和 zk-STARKs 更便宜。这将提高第 2 层解决方案的吞吐量。请参见 Starkware 以获取示例。
6、EIP-2200：SSTORE 操作的净 gas 计量
更改 EVM 中存储的成本计算，并使合约能够引入新函数，包括重入锁（ re-entry locks）和同一合约多次发送（same-contract multi-send）。
根据上述被此次升级采纳的 EIP 内容，我们可以发现：此次升级主要是为以太坊网络引入了 zk-SNARKs（零知识证明）技术，直接提高了以太坊网络的 TPS；同时，也降低了某些运算所需的 gas 费。关于这次的以太坊伊斯坦布尔升级，以太坊生态开发者和 DeFi 用户是非常值得期待的，翘首以待！
伊斯坦布尔升级确实为以太坊生态用户带来了一些显而易见的改变，不仅提高了以太坊网络运行效率，而且还直接或者间接的降低了开发者和用户使用以太坊网络的成本，我们非常高兴这些发生在以太坊网络上面的实质性变化。此外，需要提醒大家的是：作为 ETH 持币人或者以太坊 DeFi 用户，我们无需执行任何操作，静待伊斯坦布尔升级时间的到来就行了！
祝好，以太坊！
以太坊下次分叉重点，看这篇就够了
项目 • odaily 发表了文章 • 2019-06-20 11:24
过去两周，由于众多的以太坊核心开发者奔赴多伦多参加以太坊扩展（scaling）会议，每周一次的电话会议被迫取消。本周五晚，以太坊核心开发者将继续举行电话会议，议题抓要围绕伊斯坦布尔（Istanbul）硬分叉，并决定最终入选的提案（EIP）。
从设计层面来说，伊斯坦布尔（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操作码（删除预编译合同的 费用）
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说，“因为这是第一次（在分叉中）引入这么多东西，所以我们来这里是为了确保我们所做的事情是有原因的，而不是因为‘有人这么说’。”
作者 | 秦晓峰
编辑 | 卢晓明
出品 | 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操作码（删除预编译合同的 费用）
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说，“因为这是第一次（在分叉中）引入这么多东西，所以我们来这里是为了确保我们所做的事情是有原因的，而不是因为‘有人这么说’。”
作者 | 秦晓峰
编辑 | 卢晓明
出品 | Odaily星球日报 查看全部
过去两周，由于众多的以太坊核心开发者奔赴多伦多参加以太坊扩展（scaling）会议，每周一次的电话会议被迫取消。本周五晚，以太坊核心开发者将继续举行电话会议，议题抓要围绕伊斯坦布尔（Istanbul）硬分叉，并决定最终入选的提案（EIP）。
从设计层面来说，伊斯坦布尔（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操作码（删除预编译合同的 费用）
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说，“因为这是第一次（在分叉中）引入这么多东西，所以我们来这里是为了确保我们所做的事情是有原因的，而不是因为‘有人这么说’。”
作者 | 秦晓峰
编辑 | 卢晓明
出品 | Odaily星球日报
以太坊伊斯坦布尔升级之核心改变：引入 zk-SNARKs 技术
项目 • leek 发表了文章 • 2019-11-21 17:51
据以太坊基金会官网今日发布的消息，以太坊网络将在区块高度达到 9,069,000 时进行升级，预计将于 2019 年 12 月 7 日左右发生（注：确切日期可能会因不同的区块时间和时区而发生变化）。
本次以太坊网络升级的代号是“伊斯坦布尔（Istanbul）” 。恍如昨日，现在仍记得上次的以太坊升级代号为君士坦丁堡。此次以太坊网络升级隶属于 ETH1.0 范围内，同时也预示着我们离 ETH2.0 越来越近！
接下来，我们一起来看一下这次的伊斯坦布尔升级对以太坊网络做了哪些改变。
在完成这次升级之后，以太坊网络将会有一些变化和调整，主要体现在以下4点：
1、使操作码的成本与其计算成本保持一致，并提高拒绝服务攻击的抵抗性；
2、提高基于SNARKs和STARKs的二层（layer 2）解决方案的吞吐量；
3、使以太坊和Zcash能够互操作；
4、允许合约引入更多创造性函数。
伊斯坦布尔实施的变更是使用以太坊改进建议（EIP）定义的，EIP 描述了以太坊平台的标准，包括核心协议规范、客户端 API 和合约标准。考虑到过去一年以太坊社区的发展，这次升级是以太坊历史上社区提案规模最大的一次，有超过 30 个 EIP 被提议纳入这一升级，开发者们对其中的每一个 EIP 都进行了讨论和辩论，经过深思熟虑，其中有 6 个 EIP 被认为是适当的，它们分别是：
1、EIP-152：添加 Blake2 压缩函数“F”预编译
添加在以太坊合约中验证 Equihash PoW 的能力。这将启用 Zcash 和以太坊之间的中继和原子互换交易。
2、EIP-1108：降低 alt_bn128 预编译 gas 成本
这使得 zk-SNARKs 更便宜，允许构建更便宜的扩展和隐私应用。参见 Matter labs、 Aztec Protocol、Rollup 以及 Zether 的示例。
3、EIP-1344: ChainID 操作码
为合约添加一种跟踪其所在以太坊链的方法。
4、EIP-1884：操作码的重新定价
更改一些 EVM 操作码的成本，以防止垃圾交易攻击，并更好地平衡每个区块中的计算量。以太坊中每次操作必须支付的金额，通常与该操作所需的计算量相匹配。这种变化增加了运算密集型操作码（SLOAD、BALANCE 和 EXTCODEHASH）的 gas 开销，而这些操作码目前很便宜。
5、EIP-2028：降低交易数据 gas 成本
通过降低在交易中调用数据的成本，使 zk-SNARKs 和 zk-STARKs 更便宜。这将提高第 2 层解决方案的吞吐量。请参见 Starkware 以获取示例。
6、EIP-2200：SSTORE 操作的净 gas 计量
更改 EVM 中存储的成本计算，并使合约能够引入新函数，包括重入锁（ re-entry locks）和同一合约多次发送（same-contract multi-send）。
根据上述被此次升级采纳的 EIP 内容，我们可以发现：此次升级主要是为以太坊网络引入了 zk-SNARKs（零知识证明）技术，直接提高了以太坊网络的 TPS；同时，也降低了某些运算所需的 gas 费。关于这次的以太坊伊斯坦布尔升级，以太坊生态开发者和 DeFi 用户是非常值得期待的，翘首以待！
伊斯坦布尔升级确实为以太坊生态用户带来了一些显而易见的改变，不仅提高了以太坊网络运行效率，而且还直接或者间接的降低了开发者和用户使用以太坊网络的成本，我们非常高兴这些发生在以太坊网络上面的实质性变化。此外，需要提醒大家的是：作为 ETH 持币人或者以太坊 DeFi 用户，我们无需执行任何操作，静待伊斯坦布尔升级时间的到来就行了！
祝好，以太坊！ 查看全部
本次以太坊网络升级的代号是“伊斯坦布尔（Istanbul）” 。恍如昨日，现在仍记得上次的以太坊升级代号为君士坦丁堡。此次以太坊网络升级隶属于 ETH1.0 范围内，同时也预示着我们离 ETH2.0 越来越近！
接下来，我们一起来看一下这次的伊斯坦布尔升级对以太坊网络做了哪些改变。
在完成这次升级之后，以太坊网络将会有一些变化和调整，主要体现在以下4点：
1、使操作码的成本与其计算成本保持一致，并提高拒绝服务攻击的抵抗性；
2、提高基于SNARKs和STARKs的二层（layer 2）解决方案的吞吐量；
3、使以太坊和Zcash能够互操作；
4、允许合约引入更多创造性函数。
伊斯坦布尔实施的变更是使用以太坊改进建议（EIP）定义的，EIP 描述了以太坊平台的标准，包括核心协议规范、客户端 API 和合约标准。考虑到过去一年以太坊社区的发展，这次升级是以太坊历史上社区提案规模最大的一次，有超过 30 个 EIP 被提议纳入这一升级，开发者们对其中的每一个 EIP 都进行了讨论和辩论，经过深思熟虑，其中有 6 个 EIP 被认为是适当的，它们分别是：
1、EIP-152：添加 Blake2 压缩函数“F”预编译
添加在以太坊合约中验证 Equihash PoW 的能力。这将启用 Zcash 和以太坊之间的中继和原子互换交易。
2、EIP-1108：降低 alt_bn128 预编译 gas 成本
这使得 zk-SNARKs 更便宜，允许构建更便宜的扩展和隐私应用。参见 Matter labs、 Aztec Protocol、Rollup 以及 Zether 的示例。
3、EIP-1344: ChainID 操作码
为合约添加一种跟踪其所在以太坊链的方法。
4、EIP-1884：操作码的重新定价
更改一些 EVM 操作码的成本，以防止垃圾交易攻击，并更好地平衡每个区块中的计算量。以太坊中每次操作必须支付的金额，通常与该操作所需的计算量相匹配。这种变化增加了运算密集型操作码（SLOAD、BALANCE 和 EXTCODEHASH）的 gas 开销，而这些操作码目前很便宜。
5、EIP-2028：降低交易数据 gas 成本
通过降低在交易中调用数据的成本，使 zk-SNARKs 和 zk-STARKs 更便宜。这将提高第 2 层解决方案的吞吐量。请参见 Starkware 以获取示例。
6、EIP-2200：SSTORE 操作的净 gas 计量
更改 EVM 中存储的成本计算，并使合约能够引入新函数，包括重入锁（ re-entry locks）和同一合约多次发送（same-contract multi-send）。
根据上述被此次升级采纳的 EIP 内容，我们可以发现：此次升级主要是为以太坊网络引入了 zk-SNARKs（零知识证明）技术，直接提高了以太坊网络的 TPS；同时，也降低了某些运算所需的 gas 费。关于这次的以太坊伊斯坦布尔升级，以太坊生态开发者和 DeFi 用户是非常值得期待的，翘首以待！
伊斯坦布尔升级确实为以太坊生态用户带来了一些显而易见的改变，不仅提高了以太坊网络运行效率，而且还直接或者间接的降低了开发者和用户使用以太坊网络的成本，我们非常高兴这些发生在以太坊网络上面的实质性变化。此外，需要提醒大家的是：作为 ETH 持币人或者以太坊 DeFi 用户，我们无需执行任何操作，静待伊斯坦布尔升级时间的到来就行了！
祝好，以太坊！ 查看全部
据以太坊基金会官网今日发布的消息，以太坊网络将在区块高度达到 9,069,000 时进行升级，预计将于 2019 年 12 月 7 日左右发生（注：确切日期可能会因不同的区块时间和时区而发生变化）。
本次以太坊网络升级的代号是“伊斯坦布尔（Istanbul）” 。恍如昨日，现在仍记得上次的以太坊升级代号为君士坦丁堡。此次以太坊网络升级隶属于 ETH1.0 范围内，同时也预示着我们离 ETH2.0 越来越近！
接下来，我们一起来看一下这次的伊斯坦布尔升级对以太坊网络做了哪些改变。
在完成这次升级之后，以太坊网络将会有一些变化和调整，主要体现在以下4点：
1、使操作码的成本与其计算成本保持一致，并提高拒绝服务攻击的抵抗性；
2、提高基于SNARKs和STARKs的二层（layer 2）解决方案的吞吐量；
3、使以太坊和Zcash能够互操作；
4、允许合约引入更多创造性函数。
伊斯坦布尔实施的变更是使用以太坊改进建议（EIP）定义的，EIP 描述了以太坊平台的标准，包括核心协议规范、客户端 API 和合约标准。考虑到过去一年以太坊社区的发展，这次升级是以太坊历史上社区提案规模最大的一次，有超过 30 个 EIP 被提议纳入这一升级，开发者们对其中的每一个 EIP 都进行了讨论和辩论，经过深思熟虑，其中有 6 个 EIP 被认为是适当的，它们分别是：
1、EIP-152：添加 Blake2 压缩函数“F”预编译
添加在以太坊合约中验证 Equihash PoW 的能力。这将启用 Zcash 和以太坊之间的中继和原子互换交易。
2、EIP-1108：降低 alt_bn128 预编译 gas 成本
这使得 zk-SNARKs 更便宜，允许构建更便宜的扩展和隐私应用。参见 Matter labs、 Aztec Protocol、Rollup 以及 Zether 的示例。
3、EIP-1344: ChainID 操作码
为合约添加一种跟踪其所在以太坊链的方法。
4、EIP-1884：操作码的重新定价
更改一些 EVM 操作码的成本，以防止垃圾交易攻击，并更好地平衡每个区块中的计算量。以太坊中每次操作必须支付的金额，通常与该操作所需的计算量相匹配。这种变化增加了运算密集型操作码（SLOAD、BALANCE 和 EXTCODEHASH）的 gas 开销，而这些操作码目前很便宜。
5、EIP-2028：降低交易数据 gas 成本
通过降低在交易中调用数据的成本，使 zk-SNARKs 和 zk-STARKs 更便宜。这将提高第 2 层解决方案的吞吐量。请参见 Starkware 以获取示例。
6、EIP-2200：SSTORE 操作的净 gas 计量
更改 EVM 中存储的成本计算，并使合约能够引入新函数，包括重入锁（ re-entry locks）和同一合约多次发送（same-contract multi-send）。
根据上述被此次升级采纳的 EIP 内容，我们可以发现：此次升级主要是为以太坊网络引入了 zk-SNARKs（零知识证明）技术，直接提高了以太坊网络的 TPS；同时，也降低了某些运算所需的 gas 费。关于这次的以太坊伊斯坦布尔升级，以太坊生态开发者和 DeFi 用户是非常值得期待的，翘首以待！
伊斯坦布尔升级确实为以太坊生态用户带来了一些显而易见的改变，不仅提高了以太坊网络运行效率，而且还直接或者间接的降低了开发者和用户使用以太坊网络的成本，我们非常高兴这些发生在以太坊网络上面的实质性变化。此外，需要提醒大家的是：作为 ETH 持币人或者以太坊 DeFi 用户，我们无需执行任何操作，静待伊斯坦布尔升级时间的到来就行了！
祝好，以太坊！
以太坊下次分叉重点，看这篇就够了
项目 • odaily 发表了文章 • 2019-06-20 11:24
过去两周，由于众多的以太坊核心开发者奔赴多伦多参加以太坊扩展（scaling）会议，每周一次的电话会议被迫取消。本周五晚，以太坊核心开发者将继续举行电话会议，议题抓要围绕伊斯坦布尔（Istanbul）硬分叉，并决定最终入选的提案（EIP）。
从设计层面来说，伊斯坦布尔（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操作码（删除预编译合同的 费用）
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说，“因为这是第一次（在分叉中）引入这么多东西，所以我们来这里是为了确保我们所做的事情是有原因的，而不是因为‘有人这么说’。”
作者 | 秦晓峰
编辑 | 卢晓明
出品 | 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操作码（删除预编译合同的 费用）
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说，“因为这是第一次（在分叉中）引入这么多东西，所以我们来这里是为了确保我们所做的事情是有原因的，而不是因为‘有人这么说’。”
作者 | 秦晓峰
编辑 | 卢晓明
出品 | Odaily星球日报 查看全部
过去两周，由于众多的以太坊核心开发者奔赴多伦多参加以太坊扩展（scaling）会议，每周一次的电话会议被迫取消。本周五晚，以太坊核心开发者将继续举行电话会议，议题抓要围绕伊斯坦布尔（Istanbul）硬分叉，并决定最终入选的提案（EIP）。
从设计层面来说，伊斯坦布尔（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操作码（删除预编译合同的 费用）
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说，“因为这是第一次（在分叉中）引入这么多东西，所以我们来这里是为了确保我们所做的事情是有原因的，而不是因为‘有人这么说’。”
作者 | 秦晓峰
编辑 | 卢晓明
出品 | Odaily星球日报
