From 261dbe5c9a8be56e33407893a21a3e0004ab50ff Mon Sep 17 00:00:00 2001 From: Hellblazer Date: Sun, 28 Apr 2024 14:09:30 -0700 Subject: [PATCH] update readme --- choam/README.md | 71 ++++++++++++++++++++++++++++++++++--------------- 1 file changed, 50 insertions(+), 21 deletions(-) diff --git a/choam/README.md b/choam/README.md index 9daf08bac..f0d57a9e1 100644 --- a/choam/README.md +++ b/choam/README.md @@ -34,30 +34,58 @@ 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, @@ -65,7 +93,8 @@ 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