2019 年 1 月 15 日，ChainSecurity 在 Medium 上发表了一篇题为 Constantinople enables new Reentrancy Attack 的文章，文中通过代码示例的方式，阐述了一些智能合约代码在君士坦丁堡升级之后容易受到重入式攻击 (re-entrancy attack)。文章链接：

https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9

文章中阐述道：

即将到来的以太坊君士坦丁堡升级将实现某些 SSTORE 操作从而消耗更少的 gas 费用。但是在 Solidity 智能合约中使用 address.transfer(...) 或 address.send(...) 函数将可能引发重入式攻击。以前，这些函数被认为是可以抵御重入式攻击的，但现在已不同往日。

之后，以太坊核心开发者和以太坊安全社区意识到了这一问题，正在开展相关的漏洞调查工作，并决定推迟君士坦丁堡硬分叉升级。此次升级原定于当以太坊区块高度到达 7,080,000 时进行，预计将于 2019 年 1 月 16 日到达该高度。与此同时，建议所有节点运营商、交易所、矿工和钱包服务提供商等，在区块高度到达 7,080,000 之前，升级至最新的 Geth 或 Parity 版本。

为此，以太坊开发者 Hudson Jameson 发文加以阐述，文章链接：

https://blog.ethereum.org/2019/01/15/security-alert-ethereum-constantinople-postponement/

Hudson 在文章中给出的建议主要包括：

1、如果您只是与以太坊网络进行简单的交互，并不运行节点，则您不需要执行任何操作

2、矿工、交易所和节点运营商：

• 当 Geth 和 / 或 Parity 客户端新版本发布后请及时进行更新；
• 这些新版本尚未发布，发布之后的我们会及时公布更新链接和版本号及其说明；
• 预计之后的 3-4 小时内会发布新版本。

3、Geth 客户端

• 将版本升级至 1.8.21，或者
• 降级至 Geth 1.8.19，或者
• 维持在 1.8.20 版本，但需要使用开关 ‘override.constantinople = 9999999’ 从而实现无限期延迟君士坦丁堡升级。

4、Parity 客户端

• 升级至 Parity Ethereum 2.2.7-stable 稳定版本 (推荐);
• 升级至 Parity Ethereum 2.3.0-beta 测试版本 ;
• 降级至 Parity Ethereum 2.2.4-beta 测试版本 (不推荐)。

5、其他

Ledger、Trezor、Safe-T、Parity Signer、WallEth、Paper
Wallets、MyCrypto、MyEtherWallet 以及其他未通过同步和运行节点来参与到以太坊网络中的用户或代币持有者

• 你不需要做任何事情

6、合约所有者

• 您无需要做任何事情；
• 您可以选择对合约的潜在漏洞进行分析并检查您的合约；
• 但是，您无需做任何事情，因为引发此潜在漏洞的变更将不会被启用。

由于排除风险所需的时间预计将超过君士坦丁堡升级之前声誉的时间，因此以太坊开发者们决定推迟此次硬分叉升级。推迟至何时还尚不明确。

对于此次升级的延迟，以太坊社区成员们是如何看待的呢？我们来看一下 Reddit 上的以太坊社区 r/ethereum 中，社区成员对此此升级推迟的看法：

@CryptoOnly: 推迟升级是明智之举。希望相关漏洞能够尽快解决，但我相信大多数人是愿意等待此次升级在适当的时间执行的。

@millerkm87: 虽然我一直都非常期待此次升级，但推迟升级展现了以太坊社区是非常成熟的。虽有些不幸，但我更感谢漏洞被查出并被公之于众，同时采取了适当的措施来加以应对。感谢开发者们一直以来的孜孜奉献。

@SpacePirateM: 感谢让社区成员能够及时了解这些问题，这有助于减少人们的 FUD(惧惑疑) 心理。我完全相信开发者们能够解决这些小问题。

@sandakersmann: 伙计们，赶紧升级你们的节点！

@stevieyongieg: 在区块链和智能合约领域，没有什么事情是容易实现的。重要的是 ETH 背后有着坚实的团队和基础。现在发现漏洞总比以后发现要好啊。

@UndeadWolf222: 虽然有些失望，但感谢能够在主网升级之前发现 (漏洞)。伙计们，继续加油吧。

@DexVitality: 有些难过，又要推迟了。但鉴于可能存在重入式漏洞，推迟是完全有必要的 ... 我想继续前行的同时 ... 也许他们 (开发者们) 能有更多时间来讨论潜在的将 PoW 改变成 ProgPoW，或者在确定硬分叉日期的时候可能提出其他的 EIP，我的假设是此次推迟有可能将升级延迟至少 1 个月左右。

@superflyj416: 有人能对此次推迟将持续多久做出有根据的猜测吗？需要几周还是几个月？你为什么这么认为呢？

@insomniasexx: 确切的时间将可能于周五确定下来。不可能会延迟很长时间，因为难度炸弹已经被设置好了在某个时间爆炸。因此我觉得此次推迟有可能持续超过 3 天，但短于即将发生的难度炸弹期限，这是我能做出的最好的猜测。

@5chdn: 我认为，延迟可能超过 2 个星期，但不会超过 6 个星期，这是我能做出的最好的猜测。

@neuromancer4867: 我们又要回到 (ETH) 价格只有 $80 的时候了。这是最有可能的结果，但这依旧是一件很糟糕的事情。

@parasitemite：很有可能 (ETH) 价格会上涨到 $200，因为这次事件是一个很好的结果，它向我们展现了以太坊团队不惧于迅速应对问题。

@psswrd12345: 又再次延迟了，真的很难让人保持积极态度。导致这次无限期的推迟的原因，本应该在上一次延期的时候就检测出来。真的很失望。当然最好还是推迟，但现在真的很难保持信念了。这种感觉比当初的 DAO 分叉更灰暗 ...

@Stobie: @psswrd12345 只是推迟几周而已，没那么严重。

@c-i-s-c-o: @psswrd12345 构建去中心化 web 本就不是一朝可以实现的，不可能不存在挫折。要么习惯这些挫折，要么就把精力专注在那些不那么易变的事务上。

@consideritwon: 质量帖。我想问几个问题 ... 其他的操作也可能带来重入式攻击，而这通常是可以通过避免某些模式来加以应对的。一旦确认没有合约会受到影响，是否有意继续部署这个 EIP 并以这种方式处理重入式攻击？或者会重新变更 EIP？其次，关于为何这么久之后才发现这一漏洞。是否有方法能够用来改进自动化检测，以此来发现诸如此类的问题？还是需要手动去检测问题？我们从中能够吸取什么教训呢？

@Xazax310: 恰好我的问题也是，为何之前没有检测出这个问题？很高兴开发者们发现了这个漏洞，并在修复中。这可能只是一个小问题。

@vbuterin：@Xazax310 我们遇到的所有非常讨人厌的问题都涉及到不同组件之间的交互。二次 DoS 攻击结合了 EVM 存储器和调用栈框架或返回和调用栈框架，这可能会增加风险，因为发送中的默认 gas、SSTORE gas 成本和重入式问题之间存在交互。因此，如果你的协议有着 N 个功能，就存在 N 的二次方中方式来攻破这些功能。我想说，我个人从此次事件中学到的就是，需要对我们所编写的不变量 (由协议保障的属性) 要更加清楚明确，这样当事情发生变化时，我们才能更好地检查这些不变量。

@Xazax310：明白了，感谢你的解答。