[miguelrochefort]

Consensus Is Not Necessary (2021)

All problems stem from the misconception that consensus is necessary. When you realize that it's not, everything becomes much easier:

- Democracy vs Contractualism

- Bitcoin vs Holochain

- Censorship vs Filters

The same way prediction markets don't expect consensus on the interpreted state of the future, description markets shouldn't expect consensus on the interpreted state of the past.

Understand that objective reality is interpreted through a subjective lens.

Allow disagreements. Allow contradicting information to coexist. Allow people to be wrong.

We don't need to share the same perspective of the world. Embrace the filter bubble.

[FridgeSeal]

I don’t know whether you’re just making a statement or you weren’t aware, but this is about consensus in the technical sense; which is a case in which it is often necessary.

Social consensus is a whole different kettle of fish.

Predictive markets don’t need consensus, because they can be wrong. We have certain correctness expectations for other systems, and for those, reconciliation/fixing-it-after-the-fact can be more pain and effort than it’s worth.

[bob1029]

Consensus is not typically necessary.

Consider a global scale e-commerce application. You may have a handful of operations that absolutely need to pull consensus across the entire system (i.e. adding/removing nodes, creating new accounts, authenticating and creating sessions).

Everything else could be left to a per-node basis without compromising the integrity of sensitive transactions.

If you look at this from a physics perspective, I think it gets really simple. You want to minimize your user request latency. More consensus = more participants = more latency.

If the grain of your consensus mechanism is your datastore and everything in your business requires pulling a majority of votes over the cluster, you cannot leverage this philosophy. I think the biggest mistake out there right now is trying to abstract this stuff under the datastore and not allowing the business logic to access it directly. Whether or not something needs to pull consensus should be a business question, not a technical question.

[FridgeSeal]

> Whether or not something needs to pull consensus should be a business question, not a technical question

By its nature it’s a technical question with some crossover into business realm. The problem of consensus is technical, hard, full of strange hard-to-reason-about occurrences and second/third order effects. The decision to be made is whether some business thing needs those guarantees is still a technical decision.

> he biggest mistake out there right now is trying to abstract this stuff under the datastore and not allowing the business logic to access it directly

I think the issue with this is that there’s not a lot to be gained by allowing this, it’s incredibly complex as very easy to get subtly wrong-and I’ve seen very competent and very average devs get stuck on things that are comparatively far easier. Consensus is really hard. A similarity might be when NoSQL databases were all the rage and everyone was throwing away relational databases and ACID, only to recreate them at app level from first principles, but worse. Putting it in a db doesn’t solve the problem for all cases of course, but I can understand why it’d solve a lot of them.