用 dfuse Lifecycle 保证你的交易被推送上链

2019-5-16 13:38:21 / 作者 dfuse

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` 端点。在我们的下一个视频中,我会给你介绍一个提供细致的交易生命周期的端点。

话题 Video, EOSIO, dfuse API, dfuse Lifecycle, 用例