本文澄清了以太坊开发者的常见误解：天然气、交易和智能合约等

整理出以太坊程序员的七个常见误解。

原题：以太坊程序员常见误解介绍

最近，我看到一篇题为“程序员对时区的误解”的文章，这篇文章让我笑了。这篇文章让我想起了程序员在其他方面的误解，比如人们的名字和时间，所以我开始寻找关于以太坊的任何信息。然而，我别无选择，只能尽力。

对煤气的误解

调用estimategas返回事务消耗的气体量

调用estimategas确实返回气体消耗量，但这是事务在当前状态下打包时将花费的气体量。区块链的当前状态可能与您需要交易上线时完全不同。因此，当您的事务被有效地打包成块时，可能会采用不同的代码路径，并且消耗的气体量可能完全不同。

如果执行相同的代码，我的事务将消耗相同数量的gas。

不正确。即使使用相同的参数来执行相同的指令，汽油的成本也可能不同。例如，如果您写入一个新的存储位置，则sstore的成本远高于已经具有非零值的存储位置的成本（请参见eip2200）。这意味着，如果您将两个ERC20代币传输发送到一个新地址，则第一个事务的成本远高于第二个事务的成本，即使代码相同。

如果状态完全相同，我的交易所消耗的汽油量也是一样的

通常情况下，是的，除非你不幸遇到了一个导致某些操作重新定价的硬分叉。这听起来很复杂，但说白了，你不能安全地针对DAPP中事务的gas cap进行硬编码，除非你决心在每次发生硬分叉时都发布DAPP更新。

如果代码是一样的，状态是一样的，没有硬叉，我能相信estimategas的返回值吗？

现在你可以相信estimategas的返回值就是你的交易所需要消耗的气体量，但是你不知道交易是否会如你所愿。所谓gas估计就是节点用不同的gas值来尝试您的事务，并返回**的gas值，以确保您的事务不会失败。但是，节点将只查看您的事务，而不是事务的内部调用。这意味着，如果您调用的合约代码有一个try/catch块，并且在内部调用发生后无法撤销，那么您获得的gas估计值对于调用契约来说是足够的，但是对于被调用的契约来说不够。

在多签名钱包中，这种情况经常发生：即使在事务失败的情况下，大多数多签名钱包都会将操作标记为已执行，这意味着它们无法撤消最外层的事务。因此，本机gas估计返回的值对于多符号代码可能足够，但对于实际要运行的操作不一定足够。有一种评估Gnos安全性的具体方法。

请注意，这就是为什么很难检测到由于气体不足而导致的操作故障。由于分配的气体太少，内部调用可能会耗尽气体，而事务本身可能有大量可用的气体。这意味着，查看交易的气体使用量和气体上限并不是检测气体错误的可靠方法。

不管是什么，我每次都会加点油

在大多数情况下，这种方法是有效的。但请记住，合同可以查看交易中收到的天然气。所以写一份合同很容易，如果你收到太多的汽油，交易就会失败。但我怀疑，除了证明这一点外，这样做没有任何意义。

对交易的误解

只要节点接受事务，事务就会被挖矿出来

我认为是这样。以太坊网络的拥塞会导致汽油价格大幅波动，因此您的交易可能会被逐出内存池。如果油价飙升，你需要重新发送协议。

我可以提高一点汽油价格，然后重新提交交易

只要您将天然气价格提高到与之交互的节点所需的**值（请参见txpool.pricebump)那就没有问题了，否则还是会被拒绝的。

矿工总是选择天然气价格**的行业

不一定。矿工可以随意选择。他们可以为自己的利益插入自己的事务，甚至为满足自己需求的用户打开协议外通道来打包事务。

然而，即使他们根据收入来决定包装的优先级，如何以**的方式填充这些块也是一个背包问题。由于交易不能分成几个部分，即使500万天然气交易的天然气价格低于600万天然气交易的价格，将两个500万天然气交易打包，而不是一个600万天然气交易，可能会更有利可图。

如果我以更高的天然气价格发送同一笔交易，矿工会选择后一笔交易来取代前一笔交易吗

替换交易必须在旧交易在链上之前发送给矿工。也就是说，如果您发送了一个替换事务，您仍然需要监视在您之前发送的同一nonce下所有事务的哈希值。

关于当前的误解

我可以通过gettransactioncount获取下一个事务的nonce

这取决于您使用的块参数。如果基于**的数据块查询交易计数，则将忽略未打包的交易，并进一步导致您意外覆盖其中一个未打包的交易。

我可以通过gettransactioncount（’pending’）获取下一个事务的nonce

尽管这在大多数情况下都是有效的，但是您不能保证所有未打包的事务都在您查询的节点的MemPool中。如果您有许多未打包的事务，则与您通信的节点可能已丢弃其中一些事务，但这些事务可能仍存在于其他地方！

关于原木的误解

我可以通过连续调用getlogs来有效地监视事件

虽然这是一个非常有用的方法（是的，轮询！）但在连锁重组方面，会出现问题。如果您要轮询**块上的新日志，则不会收到有关块重组的通知，并且您不知道您看到的事件是否需要重新调整。

我可以通过安装过滤器来有效地监视事件

直到两周前，这还不是一个常见的选择，因为infra不支持基于HTTP的过滤器。Metamask默认使用基于HTTP的过滤器，这意味着99%的DAPP用户使用这个过滤器（注意：我可能会夸大这一点）。除了新事件外，过滤器还会通知您由于块重组而删除的事件。但是，这需要与您交互的基础设施和节点保持在线。如果它们碰巧丢失了筛选器的状态，则可能会错过重组事件。

我可以通过websocket订阅有效地监视事件

杰出的！这样，除了相信您的节点将保持在线，您还应该相信您将保持在线，并且您和节点之间的连接是可靠的。我想知道你这周在zoom的电话线下掉了多少次？

现在，我不得不承认我有点迷恋这个话题，我在Devcon5上做了一次闪电式的演讲。如果您想了解更多，eip234演示了这些挑战的基本原理，以太坊 blockstream解决了这个问题。

对合同的误解

智能合约是不变的

兄弟，如果你还这么想的话，你真的出局了。我在一篇30页的文章中解释了这一点，这篇文章真的很长。

不包含任何delegatecall的智能合约是不可变的

实际上，契约可以周期性地调用变量地址，并将结果用作计算的一部分，或者作为更改状态的指令，从而更改正在运行的代码。

不包含任何delegatecall或call的智能合约总是不可更改的，对吗？

还有staticcall。别忘了staticcall！

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

您还必须排除通过create2部署此智能合约的情况，在其initcode中动态加载运行时，并且可以自毁。在这种情况下，所有者可以销毁合同并在同一地址用不同的代码重新创建合同。

不包含任何调用且未通过create2部署的智能合约是不可更改的

还有一种情况需要排除：这个契约是通过create2部署的契约来部署的。因此，您需要跟踪整个部署链，并找到最初创建契约的以太坊的外部帐户，以确保没有可疑之处，也没有自毁操作。本文对这一问题进行了深入的探讨。

对ERC20代币的误解

我不想开始。本主题更适合撰写完整的文章。当与代币交互时，使用openzeppelin的safeERC20（您可以在本文中阅读更多有关它的信息）。请记住，接收方收到的代币不一定等于发送方在转让时扣除的代币。让我们看下一部分。

关于以太坊的误解

以太坊总供应量只会增加

众所周知，有许多以太是无法使用的。有的是因为外挂账户私钥丢失，有的是意外发送到所有零地址，有的是因为卡在合同中，无法处理（对不起，我帮不了）。总之，以太坊的这一部分仍然存在，但无法访问。

然而，有一种方法可以摧毁以太坊。如果你指示一个合同自毁并指定自己为资金的接收者，合同中的所有以太将被销毁。这意味着，只要你愿意摧毁更多的以太而不是阻止奖励，你就可以缩小以太网。

我可以写一份合同，可以拒绝任何以太坊的转让

你可能知道，如果你不申报任何应付方法，坚固性将拒绝所有发送到你的合同以太坊转移，防止资金陷入合同。但是，我们也可以向合同发送资金，而不触发任何代码：指定合同为自毁操作奖励的接收人或区块奖励的接收人。正如@gorgos在评论中指出的，可以提前计算合同部署地址，并且ETHerum可以在合同部署之前发送到该地址。

也就是说，如果您跟踪发送给您的合同的所有以太坊转移，您的总余额可能大于您处理的所有转账的总和。