Comment by __MatrixMan__
8 hours ago
If you have two or more services that need to agree about state, and you have some set of rules that govern what state changes are valid, and you don't want to mess around with any of this "what do we do when we miss and update vs when we get two of the same update" nonsense, and the services aren't in a position to query the same database, then you should really consider a permissioned blockchain. Consensus hard, but it's harder if you're not using tools that understand that what they're going for is consensus.
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 lean on the CALM theorem so you don't have coordination problems at all, but that's sometimes easier said than done.
99% of the time (and all 3 times in the blog post), there is only one source of truth for any piece of data, and state transitions are completely arbitrary. Blockchain is almost always the wrong solution.
> Blockchain is almost always the wrong solution.
Especially since in most of the cases where it's not-totally-insane to use, the right solution is still the classic distributed database which already existed. In those, the ledger is kept among a predefined/controlled node-membership... as opposed to a bloated mass of workarounds and limitations to make it barely survive being ungovernable.
I've seen some boosters pivot to saying "private blockchain is good", but that's contradictory buzzword nonsense. It's like selling a blog as "single-user Twitter" or advertising a regular car as "user-controlled autonomous vehicle."