Avalanche is a PoS blockchain platform that uses a custom set of consensus algorithms known as Snow*. It focuses on scalability via subnets and fast consensus and finality.
O(sqrt(n))then termination happens with probability
≥ 1 - epsilonand within
nis the total number of nodes
Using an example of achieving consensus on if a user specified the colour "red" or "blue" when there are faulty nodes and byzantine nodes.
All nodes start off in an uncoloured state. A client sends red, (R) to an honest node. That node then is marked as R. Each node in the network executes the following loop,
k(e.g. 20) randomly sampled nodes
knodes receiving the query message respond in the following way depending on their state:
kresponses a node adopts the majority colour if its fraction is greater than the preconfigured ratio (
a ≥ k / 2)
The execution loop is repeated for
m rounds. The node adopts the colour chosen by the end of round
mis chosen high enough, all nodes will be colored identically with high probability
To improve BFT, the Slush algorithm is augmented to keep a counter for the number of sequently successful queries (i.e.
≥ alpha, otherwise the counter gets reset. With this approach there exists an irreversible state after which a decision is inevitable. Correct nodes begin to commit past the irreversible state to adopt the same color with high probability.
To improve robustness an additional per-colour confidence counter is added.
To build a payments system using the Snowball consensus, Avalanche employs an append-only DAG to tie transactions together (instead of a chain like Bitcoin uses).1 Appending a transaction to the DAG begins by including a set of "parents" on the DAG to attach this new tx to. Important to note, the parent transactions have nothing to do with payments, but just a place to anchor the new tx to to commit the transaction. This DAG forms our "consensus graph". The data the graph vertices store (i.e. payments) are spent UTXO (like with Bitcoin).
Transactions that spend the same outputs form a conflicting set. For each conflicting set the Snowball consensus is used to settle the conflict. Transactions that have an "alpha majority" have a boolean flag set on them called a "chit". The confidence of a node is the sum of its progeny (children) chits.
When a vertex is accepted in the conflict set, then the other vertices in the conflict set get rejected along with their disconnects. However, as long as the descendants are valid, they will get re-issued on new parents.
Acceptance/rejection are final and irreversible. Finality occurs within 1-2 seconds.
The Avalanche platform architecture is has two key concepts: VMs and subnets. VMs define the application-level logic (blockchain state, state transition functions, transactions, developer APIs, etc.) Every Avalanche blockchain is an instance of a VM.2
Subnets are dynamic set of validators working together to achieve consensus. Each chain is validated by one subnet, but a single subnet can validate many chains. A key feature of subnets is configurable requirements imposed on validators when joining (e.g. validators must be located in a specific country, pass KYC, etc.) This is esp. useful for making regulatory/compliance manageable.
Avalanche has one default subnet and three chains. All validators must be part of this default subnet.
Platform Chain (P-Chain)
Contract Chain (C-Chain)
Exchange Chain (X-Chain)
Subnets are a dynamic set of validators that validate blocks. Membership requirements can be employed within subnets (e.g. validators must be in a certain country, KYC requirements, etc.)
A validator can be a part of multiple subnets, however all validators must be part of the "Default Subnet" - a set of pre-defined blockchains (including where AVAX coin lives/traded).
The C-Chain is EVM-compatible and has large overlap with Ethereum (as well as some ideas put forth in [ethereum-2]). It supports deploying EVM contracts, follows [eip-1559] (except even the tip is burned), and uses random proposer selection from the P-Chain (similar to Ethereum 2's Beacon Chain selecting the block proposer using RANDAO see [ethereum-2-pos]).
The consensus algorithm ("Snowman") builds on Snowball, but instead of a DAG, uses a linearized chain if totally-ordered blocks.3 Due to this design naturally having a lot of contention (conflict sets), Snowman++ was released on September 22 to address this problem. It works by a "soft proposer mechanism"4 which attempts to select a single proposer with the power to issue a block, but opens up block production to every validator if sufficient time has passed without blocks being generated.
For each block a small list of validators is randomly sampled, which will act as "proposers" for the next block. Each proposer is assigned a submission window: a proposer cannot submit its block before its submission window starts (the block would be deemed invalid), but it can submit its block after its submission window expires (5 seconds), competing with next proposers. If no block is produced by the proposers in their submission windows, any validator will be free to propose a block, as happens in the ordinary Snowman protocol.
Some notes on MEV extraction,