关于 Log 的误解

我可以通过持续调用 getLogs 来有效监控事件

尽管这是一个非常管用的方法（没错，说的就是轮询！），但是遇上链重组就会出问题。如果你要轮询最新区块上的新 log，你不会收到关于区块重组的通知，也不知道你所看到的事件是否需要重新调整。

我可以通过安装过滤程序来有效监控事件

直到两周前，这还不是一种常见选择，因为 Infura 不支持基于 http 的过滤程序，MetaMask 默认使用基于 http 的过滤程序，也就是说你的 dApp 有 99% 的用户都使用这种过滤程序（注：我可能有些夸大）。除了新事件之外，过滤程序还会通知你因区块重组而删除的事件。但是，这就要求你正在与之交互的基础设施和节点保持在线。如果它们碰巧丢失了过滤程序的状态，你就有可能错过重组事件。

我可以通过 websocket 订阅来有效监控事件

太好了！这样下来，除了要相信你的节点会保持在线之外，你还要相信你本人会保持在线，你和节点之间的连接是可靠的。我想知道这周你在参加 Zoom 会议时掉线了几次？

现在，我必须承认，我已经对这个话题有点着迷了，以至于我在 Devcon 5 上就此进行了一场闪电演讲。如果你想了解更多内容，EIP234 很好地阐述了这些挑战的基本原理，ethereumjs-blockstream 则解决了这一问题。

关于合约的误解

智能合约是不可更改的

兄弟，如果你还有这种想法，你真的 out 了。我在一篇长达 30 页的文章中阐述过这一点，真的非常长。

不包含任何 DELEGATECALL 的智能合约就是不可更改的

实际上，合约可以定期调用（ CALL）到一个可变地址中，并将结果作为计算的一部分，或者作为更改状态的指令，从而更改正在运行的代码。

那不包含任何 DELEGATECALL 或 CALL 的智能合约，总是不可更改的了吧？

还有 STATICCALL。别忘了 STATICCALL！

不包含任何 CALL 的智能合约是不可更改的

你还得排除一种情况：这个智能合约是通过 CREATE2 部署的，会在其初始码（initcode）中动态载入运行时，并且可以自毁。在这种情况下，「所有者」可以销毁合约，并使用不同的代码在同一个地址上重新创建这个合约。

不包含任何 CALL 且不通过 CREATE2 部署的智能合约是不可更改的

还得排除一种情况：这个合约是通过由 CREATE2 部署的合约部署的。因此，你需要追溯整个部署链条，找到最初创建合约的以太坊外部账户，确保没有任何猫腻，而且不存在自毁操作。这篇文章深入探究了这一问题。 (责任编辑：admin1)