Comment by __MatrixMan__

If your consumers are going to end up in this position:

> I do not trust the copy I built, and I have no way to know when it’s wrong, so I will re-derive it from scratch every night, forever.

Then guaranteed sequentiality means that they only have to verify each new block rather than fetch the whole thing every night.

Without it, you have this ever growing probability, which resets to 0 each night, that you unknowingly hold an invalid state. You might've acted on that state and so now when the nightly cleanup runs you have add code to go back out the consequences and instead apply the prosequences.

The complexity you think you're avoiding by not having a consensus protocol you're instead embracing as a data cleanup job, except instead of the same code everywhere, each reader has their own separate implementation.

That all goes away if you just don't process inbound data until you're sure nothing else is going to come along and invalidate it.

Sequential ID's work when there is only one writer and their implementation can be trusted but sometimes we get different events which both say they're number 12 and then we have to go call upstream and learn that so-and-so was on vacation and it won't happen again we promise. It takes days to resolve during which the potential of propagating bad state based on the lack of resolution continues to rise.

Ideally you can just avoid coordination delays entirely by keeping things monotonic and leaning on the CALM theorem but when that's not in the cards it's way better to put that delay on the writer's side, which is what blockchains do. Waiting for the consensus protocol to spit out a block before assuming that a write landed saves so many headaches on the reader side.