免责声明：本文旨在传递更多市场信息，不构成任何投资建议。文章仅代表作者观点，不代表火星财经官方立场。
边肖：记得要集中注意力。
来源：区块链大本营
作者| dfuse
编辑|卡罗尔
出品|区块链大本营(区块链_营地)
在本文中，我们将关注以太坊中复杂的交易生命周期；在这些情况下，开发人员试图让dapp提供理想的用户体验所面临的挑战；以及dfuse如何帮助突破这些挑战。每次向以太坊网络提交事务时，都会经历一系列相当复杂的状态，但并不是每个状态转换都是向前的——事务可能会回滚到更早的状态，被另一个事务取代，或者完全分叉。(交易的生命周期将在下面详细描述。在dapp中跟踪交易的进度并为用户提供良好的体验是一项挑战。如今，许多基于以太坊的dapp可以提供有吸引力但相对静态的用户体验：在应用能显示某个时间点上的交易状态，但必须通过刷新（点击刷新或 dapp UI 定期刷新页面）才能得到信息的更新。,市场上有相对更多的动态接口但提供的数据粒度仍然不够精细，或者/同时，以高网络流量为代价在其底层区块链节点上施加高负载。接下来我们讨论下造成这种情况的原因，以及如何以高效利用网络和服务器的方式、细粒度的交易状态更新在 dapp 中提供符合现代标准的、流畅的用户体验。
当今的 Dapp 接口
每个dapp都需要向用户显示正在执行的交易的区块链的底层信息——无论是以太网传输、令牌传输还是智能合约调用。而当下的许多 dapp 的界面显示这些信息的时候显示的是区块链在单个时间点上的状态。的用户经常需要在交易过程中更新信息(例如，知道转账何时完成)。所以dapp会在界面上放一个“刷新”按钮(或者定期自动为用户刷新页面)，或者用户需要直接点击浏览器的刷新按钮来获取更新。一些用户体验比较成熟的dapp会向用户展示交易的动态更新。他们会在后台轮询AJAX请求，反复检查自己的以太坊节点是否有更新，然后将更新发布到前端。这是非常复杂的，因为dapp要进行大量的API调用，查询许多不同的数据源(包括块、内存池和网络状况)，从而从头到尾跟踪事务的生命周期。要么是这种处理方式会有弊端：交易更新不频繁，信息粒度大，导致用户反复点击“刷新”才能更快获得更新；或者dapp必须以高频率轮询区块链，从而产生大量的网络流量并给底层区块链节点带来高负载。
为什么不使用基于链上事件的接口？
对于 dapp 开发人员，做静态页面或轮询一直是仅可用的两个选项，这反映了以太坊节点提供的 API 的性质.如果有一个基于链事件的接口，可以接收推送到链上的事务状态更新，并实时反馈给用户，dapp可以提供更好的用户体验――而标准的以太坊节点并不提供丰富的实时交易数据。以太坊节点确实提供了链事件的流读取功能，但功能有限，只能通过以太坊的JSON-RPC接口的PUB/SUB功能使用(使用GraphQL时不可用)。PUB/SUB 接口允许 dapp 接收一些事件类型的通知：
每次一个新的块头被附加到链上。
日志-根据指定的条件过滤和匹配新导入的块中包含的日志。
挂起事务-所有进入挂起状态并由节点中的可用密钥签名的事务的哈希(这在公共节点中很少见)。
同步-指示节点何时开始或停止同步。
根据这些事件类型对信息的访问是有限的，dapp无法通过它们跟踪交易的完整生命周期。
以太坊交易生命周期
以太坊交易有一个复杂的生命周期。每一个事务都会经历多个状态，在整个过程中会经历各种状态变化，可能是前滚，也可能是回滚。
交易状态
以太坊交易从提交、链接到(有一定的成功概率)封锁会经历如下一系列状态：
UNKNOWN （未知）:未被网络检测到或未被网络处理的交易被定义为处于未知状态。
PENDING （待处理）:这个交易正等着矿工来挑选和处理，它位于我们称之为mempool的地方。矿工通常会首先选择价格较高的天然气，因此价格较低的天然气可能会在PENDING 长期存在。
状态。Gas 价格最低的交易可能永远都不会被选中，那就会导致它们无限期地处于PENDING状态。IN_BLOCK（入块）：当矿工成功选择交易并将其处理进入区块，交易将进入IN_BLOCK 状态。如果交易进入 IN_BLOCK 状态，但它所在的区块分叉了，则交易可能回到 PENDING 状态。
REPLACED（被替换）：在以下两种情况下，交易可以从PENDING 状态变为REPLACED 状态：
另一笔来自同一发送者且有相同 nonce 的交易进入了 IN_BLOCK 状态，或另一笔来自同一发送者且有相同 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：
https://www.dfuse.io/zh/%E4%B8%BB%E9%A1%B5
