Cerberus - How Radix achieves infinite linear scalability

while preserving atomic composability

Maintaining a Record of Transactions 14

To wrap up consensus and understand the data that nodes maintain, we revisit our example transaction.

Transaction Tx ( )

Shard Shut own lice’s Token substat

1: d A A e

Shard ring up ob’s Token substate n e

2: B B A [I d x: 0]

We can see that the transaction

Shard 3 Shut own ob’s Token substat
: d B B e

contains all the details needed to

Shard ring up arol’s Token substate n e create each substate in their

4: B C B [I d x: 1]

respective shards...

Shard Shut own arol’s Token substat

5: d C C e

Shard ring up lice’s Token substate n e

6: B A C [I d x: 2]

Signed lice ob aro

: A , B , C l

Tx ID: ... 979

5
3

...and in order to
write the transaction
to the ledger, nodes 1
need some way of Transaction Tx
( )

coming to consensus 6
between validator
sets, across shards. Bring up Carol s ’

Token substate
B

4
2

This is achieved through alidator set

the uni ue braiding
V

q “ ” for Shard 4
design of emergent The merged proposal vertex
Cerberus, where QCs and includes the transaction and
its substates.
vertices for each shard are
shared between all shards,
and chained together with
hashes.

QC 1 QC 1 QC 1 QC 1
✓ Shard 1

Tx 3-chain
QC n QC n QC n QC n
B ecause of this, every node 3-braid
in every validator set has
proof that 2f 1 of vote +
QC 1
Tx
QC 1 QC 1 QC 1 Shard n

weight in every shard QC n QC n QC n QC n 3-chain

approved each phase of

consensus.

merged merged prepare merged pre-commit merged commit

proposal vertex QC vertex QC vertex QC vertex
This design uni uely allows q

validator sets in Cerberus

to come to consensus
across shards either all -

together, or not at all.

B ut so far we ve only covered

’

how nodes verify and vote on

transactions. We haven t ’

covered one of the most

integral parts of their
Nodes store the transaction
and proof that 2f 1 of vote responsibilities maintaining -

weight approved it
+

a record of transactions.

So what data do nodes have

to keep, in order to ful ll this fi

duty ?

QC 1
Tx
QC 1 QC 1 QC 1 N odes store a copy of the
QC n QC n QC n QC n
whole transaction, which
merged proposal
vertex
merged prepare
QC vertex
merged
pre commit QC
merged
commit QC includes all the substates
across all relevant shards.

vertex vertex

They also store proof that

2f 1 of vote weight approved
+

the transaction across every

shard, for every phase of
consensus through the QCs in
each vertex.

Each vertex is chained to the

previous vertex via hashes -

cryptographically tying every

phase of consensus together.
The merged proposal vertex
includes the transaction and
its substates.

The proposal vertices

in the future
transaction will point
back to the commit QC
vertex from our
transaction.

QC 1
Bring up Carol s ’ Shut down Carol s ’
QC n
Tx
Token substate B Token substate
B
merged proposal vertex

Shard 4
Future transaction
Then, if a future transaction ever wants to use
any one of the bring up substates created in our
transaction, it grabs only the substate it needs,
shuts it down by creating a new shut down
substate, and creates new bring up substate(s) Validator set
for Shard 4
in new shards.

Relevant validator sets then come to consensus

on new proposal vertices that point back to the
commit QC vertex from our transaction. The
validator set serving Shard 4 depicted here has
all the data it needs to verify the future
transaction as it has a complete copy of our
transaction, and a complete copy of the future So that’s a wrap on consensus.
transaction.

Now just one last thing - Sybil

And the cycle continues... Resistance Through Proof of
Stake.

The ersion of erberus escribe in this infographic series is sche ule to launch as part of the fully
v C d d d d

shar e Ra i i’an release. Please isit www.ra i lt.co for etails on the Ra i roa ap
d d d x X v d xd m d d x dm .

© Copyright Radix Tokens ( ersey) imite J L d

v1. 0 · J une 2 21 0