Different factors can lead to a microfork, and it’s important to ensure that your application can handle these chain reorganizations as they happen. Alex explains what a microfork is, as well as when and why one would occur. Developers who utilize dfuse can have updates about microforks sent to them in real time, ensuring the most up-to-date information is being fed into their application.
Be sure to check out these other resources to further understand how dfuse solves this challenge for you:
- Use dfuse Lifecycle for Reliable Guarantees that your Transaction is On Chain
- Avoid Refreshing – Provide Instant UX With dfuse Streaming Search
- Documentation: GraphQL Subscription – searchTransactionsForward
Microforks. Between different producers.
In this video, we’re going to explain what are microforks and how we can avoid them, what are their cause. So here’s a graph of a microfork. What happens is that you have Producer A producing a few blocks. And Producer B did not receive those blocks in time. So he started producing a block off of that one. He didn’t see this one, and this one, and this one. So he created a chain that eventually was longer than this one.
This means this block here was not paid to Producer A, this one and this one either. So they’re highly incentivized to work together to get better connectivity. Now the reason for that is that with a fast blockchain like EOS, with 0.5 seconds between blocks, it can take some time for a block to traverse the trans-oceanic cables to get to the other side of the world. So if you’re in Montreal and you’re shipping blocks to Taiwan, there’s a little time involved. So we need to have good peering between block producers. Block producers work a lot, tirelessly day and night, to ensure good speed of connectivity.
Now where’s the risk for transactions? It’s that if you have a transaction that was put inside this block here, and you can imagine that it would be put in that block, because it was waiting in the memory for that producer. But what happens if the transaction expired at ‘5’ here? It means it would not be included in ‘6’. So you had confirmation that your transaction was in a block, but boom it’s forked out! And it’s not inside the history anymore. So you need to handle that. That’s a feature of an eventually consistent database.
So the team here is working on some tools, streaming APIs, to give you a clear view and a linear view of what is happening with your transactions so that you can get greater assurance and guarantees out of that streaming data. Check it out, it’s at dfuse.io, there’s a lot of great features, table deltas, we have all the streaming and REST APIs augmented, that and much more, check it out.
And by the way, we released a tool to explore those microforks. Take a look at this at grapher.eoscanada.com. You can punch in the number of blocks and then hit submit and it’s going to generate a nice graph of what really happened. Over here, we’re seeing blocks that were produced in the schedule for EOS New York and then someone has been eating those blocks, coming very late. And then eating that previous block here. And then missing some spots also. So what happened? Maybe nodeos failed, or CPU was too loaded, or something like that? If we take a look at this one here, we see that this one has also eaten a block. Maybe network latency between the end of the schedule – block 12 and 10. So take a look at grapher.eoscanada.com to explore these microforks.
So we saw about microforks, why they happen, what is their affect on the transaction, why
we don’t want them to happen, how block producers are working tirelessly. Recently you might have seen the numbers shrink. They’re working to have great connectivity to have a flawless blockchain.
I hope this helps!