用 dfuse Lifecycle 保证你的交易被推送上链
Alex 描述了开发人员应该如何以及为什么要使用 dfuse 提供的 push_transaction 保障。 跟踪您的交易，只在您需要时获得反馈，并保持与您的应用程序的风险承受能力的一致。
点击查看视频
文字转录：
今天我们聊一聊 dfuse Lifecycle。什么是 dfuse Lifecycle？我们想象一下。你把交易发送到区块链上。它被接受了吗？它入块了吗？你还不知道呢。你拿到的是跟你交互的第一个边缘节点的预期执行信息。它会去尝试执行它，它会拒绝，并告诉你如果它拒绝了会发生什么。如果它接受了，也并不意味着下一个节点会接受它并将其入块。你没准在一个黑名单中，这个交易也没准由于网络问题或其他原因不再出现在链上，所以它是没有100％的入块保证的。
但作为开发人员，你需要确定交易是否入块。你把它提交上去，你得得到个确认信息。那你应该怎么做的？ dfuse 平台提供设置好了的端点。它可以直接替代
nodeos中的push_transaction端点它是由 dfuse 的平台支持的，还会监听所有流过的信息。它把交易提交给网络，然后它将开始监听节点出的块，如果你的交易进入了其中一个块，我们将读取执行痕迹，并将它们发送给您，就好像它们是被边缘节点执行了一样。他就像是有超能力的边缘节点。你可以用
in-block，是你需要放进代码的一个小 header，就是说：“我想验证它是否在块内”。我们还可以帮你验证它是否从一个节点传递到下一个节点了。这给你什么样的保障呢？这样微分叉带来的的风险就比较小了。
因为微分叉经常出现在在从节点1到节点2的交接中。这个节点会开始在之前的区块上开始出块，因为他没有看到之后这些。如果您想了解更多细节，请查看我们关于微分叉的视频。但基本上，如果你想收到（交易执行的）痕迹，或者你想只在节点交替后，交易还在链上的时候，收到
push_transaction的反馈，那么你可以用handoff:1。这就会给你更高级别的确定性。你也可以设成handoffs:2，handoffs:3，给你更大的把握说你的交易入块了，你就以更快地做出决策。比如让你的 UI 更具响应性，等待不可逆性。而且你也有
irreversible这个选项，是push_transaction中的另一个参数。调用它会等待不可逆，就是说你的 REST 命令会带着你的交易的有效负载调用push_transaction，它会等着你的交易不仅入块，而且还通过了不可逆，然后你可以返回到你的 UI 上，给这个交易旁边放个大锁似的图标，祝贺你的用户 “您刚购买的价值1600万美元的电视已经落户”。这就是我们的
push_transaction端点。在我们的下一个视频中，我会给你介绍一个提供细致的交易生命周期的端点。
关注微信公众号 dfuse ，获取免费 API key，加入开发者群