最近，我偶尔读到了一篇题为《措施员关于时区的误解》的文章，让我爆笑不已。这篇文章让我想到了措施员在其它方面的误解，如人名和时间，于是我开始寻找有没有关于的。怎样寻觅无果，我只得尽本身的绵薄之力。
智能合约是不行变动的
直到两周前，这还不是一种常见选择，因为 Infura 不支持基于 http 的过滤措施，MetaMask 默认利用基于 http 的过滤措施，也就是说你的 dApp 有 99% 的用户都利用这种过滤措施（注：我大概有些夸大）。除了新事件之外，过滤措施还会通知你因区块重组而删除的事件。可是，这就要求你正在与之交互的基本设施和节点保持在线。假如它们可巧丢失了过滤措施的状态，你就有大概错过重组事件。
大都环境下，这个要领是管用的。可是请记着，合约是可以查察它在一笔生意业务中收到的 gas 的。因此，可以垂手可得地将合约编写成，一旦收到过多 gas，生意业务就会失败。不外我猜疑的是，除了证明这一点外，这么做没有任何意义。
实际上，合约可以按期挪用（ CALL）到一个可变地点中，并将功效作为计较的一部门，可能作为变动状态的指令，从而更纠正在运行的代码。
我可以通过安装过滤措施来有效监控事件
我可以通过 getTransactionCount获得我的下一笔生意业务的 nonce
请留意，，这也就是为什么因为 gas 不足而导致操纵失败的环境很难察觉。内部挪用大概会因为被分派到的 gas 太少而将 gas 耗尽，而生意业务自己大概尚有许多 gas 可用。这就意味着，查察生意业务的 gas 利用量和 gas 上限并非检测 gas 错误的靠得住方法。
不包括任何 CALL 的智能合约是不行变动的
关于合约的误解
假如代码沟通，状态也沟通，且没有产生硬分叉，我就可以相信 estimateGas的返回值了吗？
可是，纵然他们依据收益来抉择打包优先级，如何故最优方法填满区块也是一个背包问题（knapsack problem）。由于生意业务无法被支解成几部门，所以，在 gas 上限为 10M 的区块中打包两个 5M gas 生意业务，而不是一个 6M gas 的生意业务，大概更为有利可图，纵然 5M gas 生意业务的 gas 价值低于 6M gas 生意业务。
固然这在大大都环境下可行，可是你不能担保你的所有未打包生意业务都在你所查询的节点的 mempool 中。假如你有许多未打包生意业务，你所通信的节点大概已经扬弃了个中一些生意业务，可是这些生意业务仍有大概存在于其它处所！
关于生意业务的误解
替换生意业务必需在旧生意业务上链之前发送到矿工哪里。也就是说，假如你发送了替换生意业务，你依然需要监控你之前发送的同一个 nonce 下的所有生意业务的哈希值。
我可以通过 getTransactionCount(‘pending’)获得我的下一笔生意业务的 nonce
不包括任何 DELEGATECALL的智能合约就是不行变动的
尚有 STATICCALL。别忘了 STATICCALL！
兄弟，假如你尚有这种想法，你真的 out 了。我在一篇长达 30 页的文章中叙述过这一点，真的很是长。
并不必然。矿工可以随心所欲举办选择。他们大概会为了本身的好处而塞入本身的生意业务，甚至可以开一个协议外通道，为切合本身要求的用户打包生意业务。
差池。纵然你利用沟通的参数来执行沟通的指令，gas 本钱也有大概差异。譬喻，对比已经有非零值的存储位置，假如你要写入新的存储位置，SSTORE（写入存储操纵）的本钱会高得多（拜见 EIP2200）。这就意味着，假如你向一个新地点发送两笔 ERC20 代币转账，第一笔生意业务的本钱会比第二笔高得多，纵然二者执行的代码完全沟通。
我可以写一个能拒绝任何故太币转入的合约
这取决于你所利用的区块参数。假如你按照最新区块来查询你的生意业务记数，就会忽略你的未打包生意业务，并进一步导致你不小心包围你的某笔未打包生意业务。
假如执行的代码沟通，我的生意业务所需耗损的 gas 量也沟通。
那不包括任何 DELEGATECALL或 CALL的智能合约，老是不行变动的了吧？
以太币的总供给量只会增加
尽量这是一个很是管用的要领（没错，说的就是轮询！），可是赶上链重组就会出问题。假如你要轮询最新区块上的新 log，你不会收到关于区块重组的通知，也不知道你所看到的事件是否需要从头调解。
管他呢，我每次多发送点 gas 就好了
还得解除一种环境：这个合约是通过由 CREATE2 陈设的合约陈设的。因此，你需要追溯整个陈设链条，找到最初建设合约的以太坊外部账户，确保没有任何猫腻，并且不存在自毁操纵。这篇文章深入探究了这一问题。
关于以太币的误解
想得美哦。以太坊的网络拥堵会导致 gas 价值颠簸很大，因此你的生意业务大概会被逐出 mempool（期待被挖出的生意业务荟萃）。假如 gas 价值飙升，你就需要从头发送生意业务。
我就不展开了，这个话题更适合写成一篇完整的文章。在与代币交互时，利用 OpenZeppelin 的 SafeERC20（你可以在这篇文章中阅读更多相关内容）就好。请记着，在转账时，吸收者所收到的代币并不必然便是发送者被扣除的代币。我们来看下一部门吧。
不外，有一种要领可以销毁以太币。假如你指令一个合约自毁 selfdestruct 并指定其自身作为资金的吸收方，这个合约内的所有以太币都将被销毁。这就意味着，只要愿意销毁比区块嘉奖更多的以太币，就可以让以太币通缩。
我可以通过 websocket 订阅来有效监控事件
只要你将 gas 价值提高到与你交互的节点所需的最小量（拜见 txpool.pricebump ），那就没什么问题，不然照旧会被拒绝。
挪用 estimateGas 确实会返回一个 gas 淹灭量，但这是该笔生意业务在 当前状态 下被打包会耗费的 gas 量。而的当前状态大概与你需要该笔生意业务上链时的状态截然不同。因此，当你的生意业务被有效打包进区块时，大概会回收差异的代码路径，需要耗损的 gas 量也有大概完全差异。
这下你可以相信 estimateGas 的返回值就是你的生意业务所需耗损的 gas 量了，可是你不知道这笔生意业务是否会如你所愿的那般举办。所谓的 gas 估测，就是节点将利用差异的 gas 值来实验你的生意业务，并返回确保你的生意业务不会失败的最低 gas 值。可是，节点只会看你的生意业务，不会看生意业务的内部挪用。这就意味着，假如你挪用的合约代码有一个 try/catch 块，导致内部挪用产生后无法取消，你得到的 gas 估测值对换用合约来说是够用的，可是对被挪用合约来说就不足了。
关于 Nonce 的误解
在多签名钱包中，这种环境常常产生：纵然是在生意业务失败的环境下，大大都多签钱包会将操纵标志为已执行，也就是说它们无法取消最外层的生意业务（所带来的影响）。因此，一个原生的 gas 估测返回的值大概对多签代码来说是足够的，对你实际想运行的操纵来说不必然足够。这就是为什么 Gnosis Safe 有一个专门的 gas 估测要领。
关于 Log 的误解
挪用 estimateGas 会返回生意业务所需耗损的 gas 量
你还得解除一种环境：这个智能合约是通过 CREATE2 陈设的，会在其初始码（initcode）中动态载入运行时，而且可以自毁。在这种环境下，“所有者” 可以销毁合约，并利用差异的代码在同一个地点上从头建设这个合约。
关于 Gas 的误解
你或者知道，假如你没有声明任何 payable 要领，Solidity 会拒绝所有发送到你的合约的以太币转账，防备资金被卡在合约内。可是，我们也可以在不触发任何代码的环境下，将资金发送到合约内：要么将该合约指定为自毁操纵嘉奖的吸收方，要么将其指定为区块嘉奖的吸收方。正如 @gorgos 在评论中指出的那样，可以预先计较出合约陈设地点，并在合约陈设前将以太币发送到该地点。
假如状态完全沟通，我的生意业务所需耗损的 gas 量也沟通

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。