來源 | hackernoon
編譯 | Guoxi
責編 | Carol
在生活中，詐騙防不勝防。
騙子們牢牢抓住受害者的心理活動，假冒公檢法的身份來突破受害者的心理防線，再羅織一些罪名就能讓受害者乖乖交出自己的錢財，等受害者反應過來，騙子們早已逃之夭夭。
作為一種應對策略，各大銀行紛紛給出了轉賬次日到賬，期間可撤回的解決方案，給使用者反悔的餘地。這種操作對於中心化的銀行來說並非難事，而在去中心化的區塊鏈上能做到麼？
乍一想，在區塊鏈上反悔撤回交易就像是天方夜譚，但結果卻是可以的！就像魯迅先生所說：世上本沒有路，走的人多了，也便成了路。
正是許多使用者有著在區塊鏈上撤銷交易的需求，所以慢慢地出現了一種通用的撤回方案，但是，這種給使用者行的方便卻給 DApp 和 DApp 開發者帶來了無盡的麻煩。
你開發的 DApp 是否向使用者展示了不正確的資訊？不要急著否認，因為很可能會出現這樣的情況，而且是在你完全不知情的前提下。
自今年年初以來，有技術團隊對主流的 DApp 進行了多達 30 餘次的交易可用性審計，其中每次審計都涉及 50 多個定製化的量化指標和定性評估。然而出乎意料的是：我們還沒有碰到哪個 DApp 可以很好地處理交易被取消的場景。交易本是每個 DApp 的重中之重，可為什麼會出現這樣的現象呢？
在我們深入研究交易被取消帶來的影響以及為什麼大多數的 DApp 都沒有解決這個問題之前，你需要了解什麼是被取消了的交易。
什麼是被取消了的交易？
在以太坊上，取消一筆交易的操作就是用一筆新的交易覆蓋即將被處理的這筆交易。需要注意的一點是，這種取消交易的機制並不是以太坊的正式標準，而是人們約定俗成的慣例。
新的交易與被取消了的交易相比，通常都具有以下幾個特徵：
擁有一個相同的隨機數（ nonce ），
由同一個錢包地址發起，
都被髮送到一個外部帳戶（不能是智慧合約）中，
交易的燃料費用（ Gas ）至少要高出 10％ ，
但是交易的金額為 0 ，
這筆新的交易在原始交易被區塊鏈確認之前由使用者簽名並提交。
這種機制為什麼會奏效呢？由於礦工會優先處理燃料費用更高的交易，因此在這筆新的交易被確認之後，礦工們才會處理那筆將要被取消的交易，即使那筆交易更早進入到礦工們存放未處理交易資訊的交易池中。換句話說，取消交易的機制有點像是一種概率的遊戲。
如何取消一筆交易？
大多數（但並不是全部）以太坊錢包都可以幫你取消交易。就比如說，在基於瀏覽器外掛的以太坊輕錢包 MetaMask 中，你可以這樣來取消一筆交易：首先先找到這筆待處理的交易，點進去顯示交易的詳細資訊，然後單擊“取消交易”按鈕。整個操作如下所示：
圖中的 PENDING（處理中） 表示交易正在處理中，點選交易詳情，其中的 Cancel （取消）按鈕表示取消交易。彈出的對話方塊說明：取消這筆交易需要支付 0.08 美元（約合 0.5 元人民幣）的燃料費用。在這裡點選取消交易並不能保證你原始提交的交易 100 % 取消成功。但如果取消成功了你需要支付上述的燃料費用，要不要試試？
雖然說這個取消交易的功能可能看起來有些廢柴，但事實證明它是使用者在使用那些功能複雜的 DApp 時必不可少的一個工具，因為這些 DApp 中的使用者往往習慣於仔細審查自己的交易並主動管理燃料成本。
【取消交易】就這麼簡單直接？
並不是這樣的！
在取消交易時存在一個致命的問題：你的 DApp 。當使用者參與到你開發的 DApp 中並進行交易時，使用者的取消交易操作只發生在使用者和他的數字錢包之間，也就是說，在這個環節中你的 DApp 完全沒有參與。
如何識別一筆被取消了的交易？
在知曉了被取消交易的特徵之後，你是否能在下圖的第四筆和第五筆交易中發現些什麼？
被取消了的交易示例
在理想的情況下，第五筆交易會覆蓋第四筆交易，也就是說第四筆交易將會被取消。
第四筆和第五筆交易的隨機數是相同的，而且第五筆交易：
繳納了更多的燃料費用。
交易的金額為 0 。
具有與前一筆交易不同的時間戳。
具有與前一筆交易不同的交易雜湊值。
前三項是取消交易機制的核心，而第四項對於 DApp 和 DApp 開發者來說都是一個棘手的問題。
被取消了的交易，將如何影響 DApp 的使用者體驗？
由於原始的交易（被取消了的交易）和之後覆蓋它的新交易具有不同的雜湊值，而且你開發的 DApp 也沒有參與到這筆新交易的建立過程中，所以你的 DApp 並沒有什麼方法來與這筆新交易產生聯絡。
通常情況下，你的 DApp 會認為原始的交易正在被處理，並一直向使用者顯示處理中的狀態，這種說法有一些生硬，接下來我們用一個例子來說明這到底是怎麼一回事，下面是我們團隊最近在審計 DApp 時發現的一個例子：
圖中的第一筆交易已經被取消了
但是 DApp 並不知道，還是將它顯示為“處理中”
事實上，在第一筆交易已經被礦工加入交易池中待處理時，第二筆交易捷足先登，覆蓋並取代了它。
由於 DApp 並沒有與第二筆交易建立聯絡的方法，因而 DApp 永遠也不會知道第一筆交易的狀態是被確認了還是失敗了，相反的是，DApp 只會顯示第一筆交易正在處理中。
隨著以太坊網路的發展，取消交易的操作變得越來越普遍。所以在這裡我們強烈建議所有的 DApp 開發者都構建出可以處理這種情況的前端功能。
如果你使用的 DApp 可以很好地處理交易被取消的問題，歡迎在文末留言告訴我們！
