Skip to content

Commit

Permalink
update readme
Browse files Browse the repository at this point in the history
  • Loading branch information
Hellblazer committed Apr 28, 2024
1 parent 11e71e6 commit 261dbe5
Showing 1 changed file with 50 additions and 21 deletions.
71 changes: 50 additions & 21 deletions choam/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,38 +34,67 @@ not produce globally visible CHOAM blocks.

## Views

Views go back to the dawn of group communication with ISIS, HORUS and various permutations of such. A View's membership
is defined by taking the View ID. The ID of a view is simply the previous block hash of the assembly. By using a block
hash, this creates a psuedo random function of the Digest byte width. In Apollo, this is at minimum 32 bytes, providing
an enormous amount of entropy. Granted, this could theoretically be gamed, but would require a 2/3's majority
Views go back to the dawn of group communication with ISIS, HORUS, and various permutations of such. A View's membership
is defined by taking the View ID and using this to obtain the successors of that id - digest - across the view's Context
Fireflies
rings. The ID of a view is the XOR of:

* the hash of the previous assembly block
* the consensus View HexBloom diadem determined for that assembly

This creates a psuedo random function of the Digest algorithm byte width. In Apollo, this is at minimum
32 bytes, providing an enormous amount of entropy. Granted, this could theoretically be gamed, but would require a 2/3's
majority
collaboration, so all right-thinking Scotsman will - by design - produce essentially unpredictable block hashes.

## Checkpointing and Bootstrapping
## Asynchronous Joins

_CHOAM_ provides a model for mitigating one of the more serious issues with distributed ledger technology, that is to
say *Bootstrapping*. CHOAM will periodically emit special _Checkpoint_ blocks that checkpoint the current state
of the chain. When these checkpoints are processed, they eliminate the usefulness of the blocks before it that went into
creating this checkpoint state and may thus be discarded. What isn't discarded is the View chain of reconfigurations,
all the way back to genesis, and it is these blocks that prove the provenance of the Checkpoint and thus the state of
the
ledger.
Periodically, CHOAM will change the committee. These committees are selected by the View IDs, as previously described.
The protocol is

1. Determine consensus View
2. Produce Assemble block with consensus view diadem
3. Start block production for current view
4. Await at least a majority of the next View's members to propose their view keys
5. Emit Reconfiguration block and finish

To boostrap a node to an existing chain, a special bootstrap process is initiated in the node. The node waits until a
valid block has been produced by the external consensus. This block is then considered the "anchor" block that the node
uses to securely bootstrap against the current group population. If a checkpoint is available, the node will assemble
that checkpoint through gossip with the rest of the membership. Note that this means that the network load required to
obtain the full checkpoint state is distributed across the membership, rather than punishing particular nodes. Once
assembled, the state of the chain is restored, deferred blocks are processed, and the node is now ready to participate
in
the group.
The block production for each view is blocked until View consensus happens within the current Committee. Once a View has
been selected, the Assemble block provides the signal to the joining members of the next committee to start the Join
process.
CHOAM uses ephemeral keys for each member per view and the Join protocol is the process of collecting these keys from
the next View's members and recording these keys in the corresponding Reconfiguration block produced at the end of the
processing for this view. The emitting of the Reconfiguration block is the end of the current view. The processing
of the Reconfiguration block is the beginning of the processing of the next View.

## Checkpointing and Bootstrapping

_CHOAM_ provides a model for mitigating one of the more serious issues with distributed ledger technology,
*Bootstrapping*.
In the production of work, CHOAM will periodically emit special _Checkpoint_ blocks that will checkpoint the current
state
of the chain. When these checkpoints are processed, they eliminate the usefulness of the previous blocks before it that
went into
creating this checkpoint state and these blocks can be discarded. CHOAM keeps the View chain of reconfigurations
all the way back to genesis, and it is this chain of reconfiguration blocks that prove the provenance of the Checkpoint
and thus the state of the system maintained by the ledger.

To boostrap a node to an existing chain, the node first joins the common broadcast group and a special bootstrap process
is initiated. The node waits until a valid block has been produced by the external consensus. This block is then
considered the "anchor" block that the node uses to securely bootstrap against the current group population. If a
checkpoint is available, the node will assemble that checkpoint through gossip with the rest of the membership.

Note that this means that the network load required to obtain the full checkpoint state is distributed across the
membership, rather than punishing particular nodes. Once assembled, the state of the chain is restored, deferred
blocks are processed, and the node is now ready to participate in the group.

Of course, the full chain state can be gathered and moved to cold storage if desired. Facilities for performing this
archiving of the full, entire chain state will be provided in the future to perform this function in a highly available,
exactly once fashion.

## MVP Status

Currently this module is MVP status. It's now very stable and fast enough to do serious simulations and thus provide the
Currently, this module is MVP status. It's now very stable and fast enough to do serious simulations and thus provide
the
foundation for the next phase of transaction ordering and SQL event generation. Critical features such as view
reconfiguration (periodic, psuedo random committee BFT election), checkpointing, bootstrapping, etc. are currently
provided. The system is stable through a very wide range of parameters, and while it may perform like crap when
Expand Down

0 comments on commit 261dbe5

Please sign in to comment.