Alex describes how and why a developer should use the
push_transaction guarantees offered by dfuse. Keep track of your transaction and only get a response returned when you want it, keeping in line with your application’s level of risk tolerance.
Today we’re going to talk about dfuse Lifecycle. What is dfuse lifecycle? Let’s paint a picture here. You send a transaction to the blockchain. Is it accepted? Is it in a block? Well you don’t know yet.
What you’ll get is a speculative execution from the first edge node that you’re talking with. It’s going to try it and it’s going to refuse it and tell you what happened if it did refuse it. If it accepts it, it doesn’t mean that the next hop, or the next Producer will accept it and put it in. You might be on a blacklist, you might never see that transaction flow again because of network issues or whatever.
So it’s not 100% guaranteed that it will get in. But as a developer you’re interested in knowing if that transaction made it to the blockchain. You have an intent and you want to have a confirmation of the commit. So how do you do that? The dfuse platform offers an instrumented endpoint.
It’s the same drop-in replacement for the `push_transaction` endpoint from the native `nodeos` except it is powered by the dfuse platform and it listens to all the flow of traffic. And what it will do is that it will submit the transaction to the network, then it is going to start listening to the blocks produced by Block Producers, and if your transaction makes it into one of these blocks we will read the execution trace and send them back to you as if they were executed by the edge node. So it’s sort of an edge node on super powers.
And you can do that for `in-block`, that’s the small header you need to put. I want to verify if it’s inside a block. But we can also do that for you verify that it has passed the handoff from one Producer to the next.
What does that give you as a guarantee? It means that there is less risk of microforks. Because the microforks often occur in a handoff from Producer1 to Producer2. This one will start producing on previous blocks because he hadn’t seen those ones here. Take a look at the microforks video if you want more details.
But basically, if you want to receive the traces or you want the call to `push_transaction` to return only when that handoff occurs and when your transaction is in the chain, well then you can pass on `handoff:1`. And that will give you that higher level of certainty that the block will stick. You can do that with `handoffs:2`, `handoffs:3`. That gives you even greater certainty that your transaction is in and you can take decisions faster.
Make your UI more responsive then waiting for irreversibility, for example. And you also have `irreversible`, that’s another parameter for the header in the `push_transaction` call. That will wait for irreversibility, so that means your REST call that calls `push_transaction` with your transaction payload will wait until the transaction is not only in a block, but also passes the irreversibility barrier. In that case you can return to your UI, change it and put a big padlock, do something and tell your users “Congratulations”. “The 16 Million Dollar TV you just bought has settled in stone”. That was for the `push_transaction`. I’m going to talk about some other endpoints that give you rich lifecycle in another video.