Comment by zbentley
5 hours ago
Why is cryptographically verifying record sequentiality an important property here?
If I offer my customers a source of ordered records, the "trust" in that system is the fact that they pay me to make sure records are ordered. If I sell a fast or slow log database, approximately zero customers in the world care to verify ordering cryptographically.
Or by "blockchain" do you just mean .... records with sequential IDs? Because sequential, guaranteed IDs surface gappiness/idempotency a lot easier than Markov chains over cryptographic primitives.
That also doesn't address the other core problems in the article: the replication (or data retrieval/polling) protocol is a lot more complex than a blockchain's "I can verify and replicate the entire chain state from the beginning of time to you" single behavior. People want more specificity than that.
Sequential ids isn't enough because multiple owners can each pick the same ID so what do you do when you get distinct updates each of whom think that theirs is number 12?
You need a way to send the writer back to the drawing board so that their conflicting edit never felt official until it ended up in a block. Otherwise you end up with multiple readers all trying to resolve conflicts over undetermined time intervals as described in the article.
Its just less overall work to shift the uncertainty forward and make the writer wait for confirmation. Or use a crdt so you don't have coordination problems at all, but that's sometimes easier said than done.