来源 | hackernoon

编译 | Guoxi

责编 | Carol

 

在生活中，诈骗防不胜防。

 

骗子们牢牢抓住受害者的心理活动，假冒公检法的身份来突破受害者的心理防线，再罗织一些罪名就能让受害者乖乖交出自己的钱财，等受害者反应过来，骗子们早已逃之夭夭。

 

作为一种应对策略，各大银行纷纷给出了转账次日到账，期间可撤回的解决方案，给用户反悔的余地。这种操作对于中心化的银行来说并非难事，而在去中心化的区块链上能做到么？

 

乍一想，在区块链上反悔撤回交易就像是天方夜谭，但结果却是可以的！就像鲁迅先生所说：世上本没有路，走的人多了，也便成了路。

 

正是许多用户有着在区块链上撤销交易的需求，所以慢慢地出现了一种通用的撤回方案，但是，这种给用户行的方便却给 DApp 和 DApp 开发者带来了无尽的麻烦。

   

   

你开发的 DApp 是否向用户展示了不正确的信息？不要急着否认，因为很可能会出现这样的情况，而且是在你完全不知情的前提下。

自今年年初以来，有技术团队对主流的 DApp 进行了多达 30 余次的交易可用性审计，其中每次审计都涉及 50 多个定制化的量化指标和定性评估。然而出乎意料的是：我们还没有碰到哪个 DApp 可以很好地处理交易被取消的场景。交易本是每个 DApp 的重中之重，可为什么会出现这样的现象呢？

在我们深入研究交易被取消带来的影响以及为什么大多数的 DApp 都没有解决这个问题之前，你需要了解什么是被取消了的交易。

什么是被取消了的交易？

在以太坊上，取消一笔交易的操作就是用一笔新的交易覆盖即将被处理的这笔交易。需要注意的一点是，这种取消交易的机制并不是以太坊的正式标准，而是人们约定俗成的惯例。

 

新的交易与被取消了的交易相比，通常都具有以下几个特征：

• 拥有一个相同的随机数（ nonce ），

• 由同一个钱包地址发起，

• 都被发送到一个外部帐户（不能是智能合约）中，

• 交易的燃料费用（ Gas ）至少要高出 10％ ，

• 但是交易的金额为 0 ，

• 这笔新的交易在原始交易被区块链确认之前由用户签名并提交。

这种机制为什么会奏效呢？由于矿工会优先处理燃料费用更高的交易，因此在这笔新的交易被确认之后，矿工们才会处理那笔将要被取消的交易，即使那笔交易更早进入到矿工们存放未处理交易信息的交易池中。换句话说，取消交易的机制有点像是一种概率的游戏。

 

 

如何取消一笔交易？

 

大多数（但并不是全部）以太坊钱包都可以帮你取消交易。就比如说，在基于浏览器插件的以太坊轻钱包 MetaMask 中，你可以这样来取消一笔交易：首先先找到这笔待处理的交易，点进去显示交易的详细信息，然后单击“取消交易”按钮。整个操作如下所示：

       

如何在 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 可以很好地处理交易被取消的问题，欢迎在文末留言告诉我们！