Block 9226 has no Next slot hash, but links to previous block 9225
Block 9227 links to previous block 9225 as well.
So 9226 is unknown to blockchain (there are no references to it in other blocks) but it still exists, and moreover even contain some transactions.
What happened here? Another feature I am not aware about?
Looks like a temporary fork / disagrement. The transactions were reversed* and then included in this block https://cardanoexplorer.com/slot/ac0c6b6f5bf1244eb5b723c46dfb5acb95b527776be0ca21aa85dbe80cbeecc5
*At 1:35 this videos shows how the protocol handles such things automatically:
Searching for epoch 120 slot 9226 also yields no results.
How do you know that they were reserved?
But search by hash is. And it bothers me
I edited the post, because “reversed” is maybe a confusing term. The feature is called “chain selection” so after the rule is applied it’s technically not reversed it’s more like it never happend.
They have 5 or 7 private nodes and still have syncing problems. What will happen when there be 1000 nodes?
I don’t know how many nodes there are, but you are right. Such things will happen and this is totally fine. We are talking about one block fork here.
I see now. Transactions in 9226 and 9232 have same hashes, so basically they were resubmitted to network.
But still I can see block 9226 through api and there are no signs or notes that it was orphaned from chain. Should “cbsNextHash”: null be treated as orphaned block?
It becomes challenging to run services like rich list, charts and etc. at AdaScan with such chain behaviour. There are no way to tell which block will be orphaned(deleted) from chain and which one won’t.
I hope devs will work on syncing issues. This is 4th or 5th time such stuff happens during last 8 months.
Without a next block the block is orphaned, but I don’t think this is a good idea tho. Because, it could be that the fork was one block before (two orphaned blocks in total) and then the chain selection happend. This means only the very last block has no next block, but the block before (with the hash to the very last one) is still orphaned.
From my understanding, this is not an issue that can be fixed. It works as intended. You can’t assume in a decentralized network that every node has always a connection to all other nodes.
When a network is split (for whatever reason) every part will continue their work. (producing blocks) When the separated networks are back together a decision must be made: which one is the right chain?
I’ve checked it with IOHK and they say this answer is correct.
Thank you.
Just today I was looking about this issue in particular, and found this video explaining how Ouroboros is ought to work:
towards the end of the video it explains clearly how is possible that forks exist and how these are reconciled. I agree with @adatainment, it’s completely normal for this things to happen to a distributed network, the interesting bit is how these are handled and not if you can prevent them from happening in the first place.
