以太坊交易可能经历的8个状态以及 Dapp 如何跟踪状态

在本文中，我们将重点介绍以太坊上复杂的交易生命周期；开发者在这些情况下尝试让 dapp 提供理想的用户体验的挑战；以及 dfuse 是如何帮助突破这些挑战的。

每当一笔交易提交到以太坊网络上时，它会经历一系列相当复杂的状态，而并非每个状态转换都是向前的——交易可能回滚到较早的状态、可能被另一个交易替换、还可能完全分叉。 （下文中会详细描述交易的生命周期。）

跟踪状态的困难

在 dapp 中跟踪交易的进程并为用户提供良好的体验是具有挑战性的。如今，许多基于以太坊的 dapp 都可以提供吸引人但还是相对静态的用户体验：应用能显示某个时间点上的交易状态，但必须通过刷新（点击刷新或 dapp UI 定期刷新页面）才能得到信息的更新。市面上有相对更动态的接口，但提供的数据粒度还是不够细，或者/同时以高网络流量为代价，在其底层区块链节点上施加高负载。

接下来我们讨论下造成这种情况的原因，以及如何以高效利用网络和服务器的方式、细粒度的交易状态更新在 dapp 中提供符合现代标准的、流畅的用户体验。

当今的 Dapp 接口

每个 dapp 都需要向用户显示正在执行的交易的区块链底层信息——无论是 Ether 转账、代币转账还是智能合约调用，而当下的许多 dapp 的界面显示这些信息的时候显示的是区块链在单个时间点上的状态。

用户在交易过程中经常需要更新信息（例如，知道转账什么时候完成了），因此 dapp 会在界面上放一个 “刷新” 按键（或定期自动为用户刷新页面），或者用户需要直接点击浏览器的刷新按钮来获取更新。

有些用户体验更成熟的 dapp 会向用户显示交易的动态更新。它们会在后台轮询 AJAX 请求，重复检查其以太坊节点是否有更新，然后将更新发布到前端。这么做是非常复杂的，因为 dapp 必须进行大量 API 调用，查询许多不同的数据源（包括区块、内存池和网络条件），从而才能从头到尾的跟踪交易的生命周期。

这种处理方式会有弊端：要么交易的更新不频繁、信息粒度大，导致用户想去重复点击“刷新”而去更快地获取更新；或者 dapp 必须高频轮询区块链，从而产生大量网络流量，在底层区块链节点上施加高负载。

为什么不使用基于链上事件的接口？

对于 dapp 开发人员，做静态页面或轮询一直是仅可用的两个选项，这反映了以太坊节点提供的 API 的性质。如果有一个基于链上事件的接口，可以接收推送到链上的交易状态更新并实时反馈用户，dapp 才能提供更好的用户体验——而标准的以太坊节点并不提供丰富的实时交易数据。

以太坊节点确实提供了链上事件的流读取功能，但功能有限，只能通过使用以太坊的 JSON-RPC 接口的 PUB/SUB 功能才可用（在使用 GraphQL 时不可用）。PUB/SUB 接口允许 dapp 接收一些事件类型的通知：

• newHeads——每次新的区块 header 附加到链上
• logs——根据指定的条件过滤匹配包含在新导入的区块中的日志
• newPendingTransactions——进入待处理状态并被节点中可用密钥签名的所有交易的哈希（而这种情况在公共节点上很少见）
• syncing——指示节点何时开始或停止同步

（有关详细信息，请参见此处）

根据这些事件类型获取信息很受限，dapp 无法通过它们跟踪交易的完整生命周期。

以太坊交易生命周期

以太坊交易是有复杂的生命周期的。每个交易都会经过多个的 state （状态），在整个过程中经历各种 state 的变更，可能前进也可能回滚。

交易状态

以太坊交易从提交上链到（在一定的成功几率下）入块，它会经历如下的一系列状态：

• UNKNOWN **（未知）：一个未被网络检测到或未被处理的交易被定义为处于 UNKOWN **状态。
• PENDING （**待处理）：交易在等待矿工拣选和处理，位于我们所称的 *mempool （*内存池）中。矿工通常会首先选择 gas 价格较高的交易，因此 gas 价格较低的交易可能会长期处于 PENDING 状态。Gas 价格最低的交易可能永远都不会被选中，那就会导致它们无限期地处于 PENDING **状态。
• IN_BLOCK（入块）：当矿工成功选择交易并将其处理进入区块，交易将进入IN_BLOCK 状态。如果交易进入 IN_BLOCK 状态，但它所在的区块分叉了，则交易可能回到 PENDING 状态。
• REPLACED**（被替换）：在以下两种情况下，交易可以从 PENDING 状态变为 REPLACED** 状态：

1. 另一笔来自同一发送者且有相同 nonce 的交易进入了 IN_BLOCK 状态，或
2. 另一笔来自同一发送者且有相同 nonce 但 gas 价格高出12％的另一笔交易进入了 PENDING 状态

下图显示了这些状态以及它们之间的过渡。

States（状态）转换

如上图所示，状态之间的转换也是有名称定义的。

• POOLED（入池）：处于 UNKOWN （未知）状态的交易进入等待矿工选择的交易池，被称为 POOLED 并进入 PENDING （待处理）状态。处于 REPLACED（被替换）状态的交易，如果替换条件不再成立（例如：在极少数情况下，处于 IN_BLOCK （入块）的低 gas 价格的交易被分叉，而替代它且具有相同 nonce 和发送者的交易仍在网络上游动），则也有可能再次变为 POOLED 状态。
• MINED （被挖矿）：被挖矿的交易是由矿工处理过的交易，这过程会创建一个区块。一旦被挖，交易就被算做处于 IN_BLOCK （入块）状态。由于以太坊网络的点对点性质，从一个指定节点的角度监测，交易可以从 UNKNOWN （未知）状态直接进入到 IN_BLOCK （入块）状态，无需明显地通过 PENDING （待处理）状态。出于相同的原因，从一个指定节点的角度监测，交易也可以不通过 PENDING （待处理）状态而直接从 REPLACED**（被替换）状态转换为 IN_BLOCK （入块）**状态。
• REPLACED**（被替换）：从 PENDING （待处理）状态进入到 REPLACED 状态的交易也被称为 REPLACED。请参见文中交易状态中列出的 REPLACED **状态。
• FORKED（**被分叉）：当已被挖的交易处于被网络撤消的区块中时，就是产生了被分叉的交易。那个区块内的所有交易将接连被分叉，从 IN_BLOCK （入块）状态转回到 PENDING （待处理）**状态。
• CONFIRMED（已**确认）：处于 IN_BLOCK （入块）**状态的交易会在每次它后续的子区块被挖时而被确认。

如上所述，以太坊上的交易的生命周期是非常复杂的，这使得 dapp 很难去准确的跟踪它并向用户提供无缝式、流畅的更新。

如何跟踪交易状态

dfuse 平台为提供了一个丰富的、能够串流监听的接口，该接口支持实时详细跟踪以太坊交易的生命周期。 dfuse 以太坊交易状态跟踪器 API 使开发人员能够提交以太坊交易，然后在同一数据通道上即刻获取精细的状态更新，跟随交易在其整个生命周期中的进展。

使用 GraphQL，您可以实时监听指定类型交易的变化，同时可以精确指定每次交易发生变化时您想收到的数据。dfuse 平台处理了跟踪交易这项工作的复杂性，并会在事件发生时实时传输给 dapp。

这样一来，您无需撰写和运行复杂的后台逻辑和重复进行轮询，也不会浪费带宽和多次运行同样的查询。简单地监听您所需的更新，然后在界面中把这些更新反馈给用户。

下面的动图展示的是一个经历了这种复杂生命周期的交易——它经历了八个状态转换，最后才被包含在区块中并得到确认。

如果没有使用 dfuse，dapp 则必须一次次的访问区块链以捕获交易经历的所有转换再更新给用户，并且后端代码需要去准备好应对每个状态转换。

使用 dfuse，dapp 仅需要通过单个连接获取串流更新，dfuse 会为您跟踪交易经历的各种曲变化，直到它的命运被最终确定。

为先进的 Dapp 提供的现代化平台

Lifecycle （生命周期） API 只是 dfuse 平台的重要的一小部分。dfuse 为 dapp 提供了完整的现代化基础架构层，即：

• 快速，
• 可扩展，
• 提供对区块链事件的高度精细的串流监听，
• 支持主动的 Webhook 形式的回调，
• 具有业内最高的可靠性。

立即试用 dfuse。如有任何疑问/建议，请在微信或 Telegram 上与我们联系，跟我们分享下您构建以太坊 dapp 的经验——我们也很想知道您是否对我们所提供的服务感到满意。