Thread by @fuserleer

Throughout the day a few folks have correctly noted that there are indeed hybrid consensus platforms such as $dot #symbol #eth2 & others.

However there's a subtle but important difference in #cassandra that perhaps warrants "hybrid" as the incorrect term.

Clarification then...

https://twitter.com/fuserleer/status/1375812655697563650

As far as I understand, these solutions are essentially two separate consensus mechanisms.

Probabilistic to perform state transitions, with deterministic to finalise the best version of the former.

It works & does the job required, so why is #cassandra different?

....

Think of a hybrid car. There is a petrol engine & electric motor working together to move the car.

They are 2 separate systems & are open loop, one way. The engine if needed can generate electricity for the motor, but the motor doesn't produce anything useful for the engine...

#cassandra is #petric (or #electrol whatever) & is not two system, but one with the best of both in the true sense. It also NEEDS to be as will become clear which hopefully results in a nuanced #headplosion on the realisation.

So what's going on?

First we need to understand what a typical transaction flow looks like.

1. A transaction is presented
2. The transaction is executed
3. The transaction is final (whether success or failure)

The produced primitives are state & atom certificates, remember these!

...

Our transaction is in the network & validators are producing a tree of blocks. They are also voting on the best branch of that tree. The blocks contain atoms & atom certificates.

When a branch has 2/3 vote power it is committed. Here is the first subtle difference...

Say our transaction is in block 2 of a 4 block branch being committed. No state referenced by our transaction has changed yet. It has simply been agreed that the network will attempt to process the state transitions in our transaction.

Let's call this consensus step A

...

Step B is where the state transitions are executed & produce state certificates. State certificates are formed from the state output votes from validators. A state certificate also needs 2/3 agreement.

Step B is super special as we'll see later.

...

At step C our transaction is executed & an atom certificate is formed from all the state certificates.

At the point of atom certificate creation there exists a contradiction proof which ensures safety (important later) but our transaction is NOT final yet... Why?

Remember blocks contain atoms AND atom certificates. The atom certificate for our transaction isn't yet in a block, nor can it be considered committed even though there are 2/3 agreement.

Let's assume that the certificate is included in block 6...

Upon there being 2/3 agreement on block 6, aside from that being an agreement of which atoms to process, it also provides evidence that 2/3 of all validators have seen our atom certificate and will commit to the state transitions.

...

As you can see, the probabilistic phase (generating blocks) & the deterministic phases (agreement on things) are dependent closed loops. Which makes #cassandra a very different beast.

So why all this effort? I refer back to step B & the state certificates.

...

In a sharded ledger state will live in different shards & until it is agreed in the local shard what will be processed next, the local validators don't know what state they will need.

Further, because other shards may be latent or currently busy, step B MUST be asyncronous

...

Other shards will also be sending state certificates to each other at step B & an atom certificate can not be created by any shard until all state certificates are received.

Step B is where #cerberus lives.

#headplosion right?

Wait there's more...

The fact that step B is asyncronous & that there exists a contradiction proof for atom certificates means that all shards can commit the atom certificate at step A at different times but remain atomic.

Pheew!