Pluggable consensus and rollbacks

Excellent post, I will come back to it (heading to bed now), but this point is important. These nodes must be penalised, maybe killed.

This part is interesting, we are moving to very simple, but solid consensus/agreement mechanism now. That means we have a consensus where the work is done by the proposer (it means spammers etc. have a hard time and the network always has an easy time).

We need to write this up, but consensus should not be a one size fits all. We have different models. The most basic differences are:

  1. Data that can fork and resolve forks (like document editing, git etc.)
  2. Data that can never fork (like cryptocurencies)

These 2 fundamental types are important to quantify and many networks don’t, they go for one or the other and IMO that is a mistake.

The other part is consensus needs to be simple, so no Dag’s, no weird calculus etc. but simple and solid. The aim is unfailable operations and off-line first ops. We are now at this place and I hope it moves the whole state of the art forward. There is no need for complexity here. In saying that that background thinking (like CRDTs) is hugely complex, but the API/outcomes are simple. We need that simplicity and solidity to make this all come together. If nothing else it will prove that total order/time etc. are not required and also there is no one size fits all consensus algorithm and that should open a lot of eyes. At least I hope it does. This all needs to be simple.

Anyway, I do need to sleep now, but nice post Greg. Thought provoking.

22 Likes