撰文：spalladino
翻譯 & 校對：閔敏 & 阿劍
最近，我偶然讀到了一篇題為《程式員關于時區的誤解》的文章，讓我爆笑不已。這篇文章讓我想到了程式員在其它方面的誤解，如人名和時間，于是我開始尋找有沒有關于以太坊的，奈何尋覓無果，我只得盡自己的綿薄之力，
關于 Gas 的誤解
呼叫 estimateGas 會回傳交易所需消耗的 gas 量
呼叫 estimateGas 確實會回傳一個 gas 耗費量，但這是該筆交易在當前狀態下被打包會花費的 gas 量。而區塊鏈的當前狀態可能與你需要該筆交易上鏈時的狀態大相徑庭。因此，當你的交易被有效打包進區塊時，可能會采用不同的代碼路徑，需要消耗的 gas 量也有可能完全不同，
如果執行的代碼相同，我的交易所需消耗的 gas 量也相同，
不對。即使你使用相同的引數來執行相同的指令，gas 成本也有可能不同。例如，相比已經有非零值的存盤位置，如果你要寫入新的存盤位置，SSTORE （寫入存盤操作）的成本會高得多（參見 EIP2200）。這就意味著，如果你向一個新地址發送兩筆 ERC20 代幣轉賬，第一筆交易的成本會比第二筆高得多，即使二者執行的代碼完全相同，
如果狀態完全相同，我的交易所需消耗的 gas 量也相同
通常情況下是的，除非你很倒霉地碰上了硬分叉，導致一些操作重新定價。雖然這聽起來很復雜，但說白了就是，你無法針對 dApp 中交易的 gas 上限進行安全的硬編碼，除非你決心在每次發生硬分叉后都發布 dApp 更新，
如果代碼相同，狀態也相同，且沒有發生硬分叉，我就可以相信 estimateGas 的回傳值了嗎？
這下你可以相信 estimateGas 的回傳值就是你的交易所需消耗的 gas 量了，但是你不知道這筆交易是否會如你所愿的那般進行。所謂的 gas 估測，就是節點將使用不同的 gas 值來嘗試你的交易，并回傳確保你的交易不會失敗的最低 gas 值，但是，節點只會看你的交易，不會看交易的內部呼叫。這就意味著，如果你呼叫的合約代碼有一個 try/catch 塊，導致內部呼叫發生后無法撤銷，你獲得的 gas 估測值對呼叫合約來說是夠用的，但是對被呼叫合約來說就不夠了，
在多簽名錢包中，這種情況經常發生：即使是在交易失敗的情況下，大多數多簽錢包會將操作標記為已執行，也就是說它們無法撤銷最外層的交易（所帶來的影響）。因此，一個原生的 gas 估測回傳的值可能對多簽代碼來說是足夠的，對你實際想運行的操作來說不一定足夠。這就是為什么 Gnosis Safe 有一個專門的 gas 估測方法。
請注意，這也就是為什么因為 gas 不夠而導致操作失敗的情況很難察覺，內部呼叫可能會因為被分配到的 gas 太少而將 gas 耗盡，而交易本身可能還有很多 gas 可用，這就意味著，查看交易的 gas 使用量和 gas 上限并非檢測 gas 錯誤的可靠方式，
管他呢，我每次多發送點 gas 就好了
多數情況下，這個方法是管用的。但是請記住，合約是可以查看它在一筆交易中收到的 gas 的。因此，可以輕而易舉地將合約撰寫成，一旦收到過多 gas，交易就會失敗。不過我懷疑的是，除了證明這一點外，這么做沒有任何意義，
關于交易的誤解
只要節點接受了交易，交易就會被挖出
想得美哦，以太坊的網路擁堵會導致 gas 價格波動很大，因此你的交易可能會被逐出 mempool （等待被挖出的交易集合）。如果 gas 價格飆升，你就需要重新發送交易，
我可以略微提高 gas 價格然后重新提交交易
只要你將 gas 價格提高到與你互動的節點所需的最小量（參見 txpool.pricebump ），那就沒什么問題，否則還是會被拒絕。
礦工總選擇 gas 價格最高的交易
并不一定，礦工可以隨心所欲進行選擇。他們可能會為了自己的利益而塞入自己的交易，甚至可以開一個協議外通道，為符合自己要求的用戶打包交易。
但是，即使他們依據收益來決定打包優先級，如何以最優方式填滿區塊也是一個背包問題（knapsack problem）。由于交易無法被分割成幾部分，所以，在 gas 上限為 10M 的區塊中打包兩個 5M gas 交易，而不是一個 6M gas 的交易，可能更為有利可圖，即使 5M gas 交易的 gas 價格低于 6M gas 交易，
如果我以更高的 gas 價格發送相同的交易，礦工會選擇后一個交易來替換前一個交易嗎
替換交易必須在舊交易上鏈之前發送到礦工那里，也就是說，如果你發送了替換交易，你依然需要監控你之前發送的同一個 nonce 下的所有交易的哈希值，
關于 Nonce 的誤解
我可以通過 getTransactionCount 得到我的下一筆交易的 nonce
這取決于你所使用的區塊引數，如果你根據最新區塊來查詢你的交易記數，就會忽略你的未打包交易，并進一步導致你不小心覆寫你的某筆未打包交易，
我可以通過 getTransactionCount('pending') 得到我的下一筆交易的 nonce
雖然這在大多數情況下可行，但是你不能保證你的所有未打包交易都在你所查詢的節點的 mempool 中，如果你有很多未打包交易，你所通信的節點可能已經丟棄了其中一些交易，但是這些交易仍有可能存在于其它地方！
關于 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 部署的合約部署的。因此，你需要追溯整個部署鏈條，找到最初創建合約的以太坊外部賬戶，確保沒有任何貓膩，而且不存在自毀操作。這篇文章深入探究了這一問題。
關于 ERC20 代幣的誤解
我就不展開了，這個話題更適合寫成一篇完整的文章。在與代幣互動時，使用 OpenZeppelin 的 SafeERC20 （你可以在這篇文章中閱讀更多相關內容）就好。請記住，在轉賬時，接收者所收到的代幣并不一定等于發送者被扣除的代幣。我們來看下一部分吧，
關于以太幣的誤解
以太幣的總供應量只會增加
我們都知道，有很多以太幣是無法使用的，有的是因為外部賬戶的私鑰丟失，有的是因為意外發送到全零地址，還有的是因為被卡在合約中無法處理（對不起，我沒忍住）。總而言之，這部分以太幣依然存在，但是無法訪問。
不過，有一種方法可以銷毀以太幣。如果你指令一個合約自毀 selfdestruct 并指定其自身作為資金的接收方，這個合約內的所有以太幣都將被銷毀。這就意味著，只要愿意銷毀比區塊獎勵更多的以太幣，就可以讓以太幣通縮，
我可以寫一個能拒絕任何以太幣轉入的合約
你或許知道，如果你沒有宣告任何 payable 方法，Solidity 會拒絕所有發送到你的合約的以太幣轉賬，防止資金被卡在合約內。但是，我們也可以在不觸發任何代碼的情況下，將資金發送到合約內：要么將該合約指定為自毀操作獎勵的接收方，要么將其指定為區塊獎勵的接收方，正如 @gorgos 在評論中指出的那樣，可以預先計算出合約部署地址，并在合約部署前將以太幣發送到該地址，
也就是說，如果你追蹤所有發送到你的合約的以太幣轉賬，你的總余額可能大于你處理的所有轉賬的總和，
來源鏈接：gist.github.com