APP:一文读懂以太坊交易可能经历的8个状态_DEFI

编者按：本文来自区块链大本营，作者：dfuse，Odaily星球日报经授权转载。在本文中，我们将重点介绍以太坊上复杂的交易生命周期；开发者在这些情况下尝试让dapp提供理想的用户体验的挑战；以及dfuse是如何帮助突破这些挑战的。每当一笔交易提交到以太坊网络上时，它会经历一系列相当复杂的状态，而并非每个状态转换都是向前的——交易可能回滚到较早的状态、可能被另一个交易替换、还可能完全分叉。在dapp中跟踪交易的进程并为用户提供良好的体验是具有挑战性的。如今，许多基于以太坊的dapp都可以提供吸引人但还是相对静态的用户体验：应用能显示某个时间点上的交易状态，但必须通过刷新才能得到信息的更新。市面上有相对更动态的接口，但提供的数据粒度还是不够细，或者/同时以高网络流量为代价，在其底层区块链节点上施加高负载。接下来我们讨论下造成这种情况的原因，以及如何以高效利用网络和服务器的方式、细粒度的交易状态更新在dapp中提供符合现代标准的、流畅的用户体验。当今的Dapp接口

每个dapp都需要向用户显示正在执行的交易的区块链底层信息——无论是Ether转账、代币转账还是智能合约调用，而当下的许多dapp的界面显示这些信息的时候显示的是区块链在单个时间点上的状态。用户在交易过程中经常需要更新信息，因此dapp会在界面上放一个“刷新”按键，或者用户需要直接点击浏览器的刷新按钮来获取更新。有些用户体验更成熟的dapp会向用户显示交易的动态更新。它们会在后台轮询AJAX请求，重复检查其以太坊节点是否有更新，然后将更新发布到前端。这么做是非常复杂的，因为dapp必须进行大量API调用，查询许多不同的数据源，从而才能从头到尾的跟踪交易的生命周期。这种处理方式会有弊端：要么交易的更新不频繁、信息粒度大，导致用户想去重复点击“刷新”而去更快地获取更新；或者dapp必须高频轮询区块链，从而产生大量网络流量，在底层区块链节点上施加高负载。为什么不使用基于链上事件的接口？

对于dapp开发人员，做静态页面或轮询一直是仅可用的两个选项，这反映了以太坊节点提供的API的性质。如果有一个基于链上事件的接口，可以接收推送到链上的交易状态更新并实时反馈用户，dapp才能提供更好的用户体验——而标准的以太坊节点并不提供丰富的实时交易数据。以太坊节点确实提供了链上事件的流读取功能，但功能有限，只能通过使用以太坊的JSON-RPC接口的PUB/SUB功能才可用。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状态：另一笔来自同一发送者且有相同nonce的交易进入了IN_BLOCK状态，或另一笔来自同一发送者且有相同nonce但gas价格高出12％的另一笔交易进入了PENDING状态下图显示了这些状态以及它们之间的过渡。

States转换

如上图所示，状态之间的转换也是有名称定义的。POOLED：处于UNKOWN状态的交易进入等待矿工选择的交易池，被称为POOLED并进入PENDING状态。处于REPLACED状态的交易，如果替换条件不再成立的低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提供的现代化平台

LifecycleAPI只是dfuse平台的重要的一小部分。dfuse为dapp提供了完整的现代化基础架构层，即：快速，可扩展，提供对区块链事件的高度精细的串流监听，支持主动的Webhook形式的回调，具有业内最高的可靠性。

标签：DEFIEFIDAPAPPDeFi FireflyGEFI价格blockchainresearchandapplicationtoro币APP

MATIC热门资讯