Alphabill Consensus Protocol

There are several different types of ledger consensus used in blockchain protocols:

• Longest chain rule (for example, Bitcoin): blocks are proposed; if the next block chains from this block and then some more valid blocks continue the chain, then the current block can be considered as final (with probability depending on chain length).
• Probabilistic convergence (for example, Avalanche/Snowball): an optimization of the previous where the validators gossip and stick to the majority until converging to a likely agreement about the next block's content.
• Deterministic finality (for example, Tendermint): nodes run a consensus protocol (in the narrower sense of consensus from distributed systems research) to reach agreement on and finalize every block.

Alphabill is similar to Tendermint as it provides deterministic finality. The Root Chain uses a low-level consensus module based on HotStuff, a BFT consensus protocol specifically optimized for latency not throughput (as the Root Chain does not need to validate client transactions).

Validator virtualization

A virtualization layer is operated by the Governance Partition validators, such that validators who wish to join the network are allocated at random to either the Root Chain or a specific shard on a partition. Validators build a reputation in a shard and are incentivized based on committed stake, equalization, and stabilization rules, ensuring balance and security across different shards.

A single consensus instance

The Root Chain is isolated from the transaction processing load. Instead of client transactions, the Root Chain validators only need to validate and process aggregate summaries of proposed state transfers from shards. They effectively check the results of the shard validators and confirm they are in coherence.

Importantly, the set of validators on a shard validate and execute transactions but do not participate in a shard-level consensus protocol. Shard validators cannot create a valid block unless it has received a Unicity Certificate from the Root Chain.

Steps in the Consensus Protocol

1. Clients send transaction requests to a shard (wallets know which shard as the identifier of the token encodes the relevant information). The same principle applies to smart contracts.

2. Validators within a shard receive transaction orders from clients, check them and forward to parallel block proposers, based on round-specific mapping.

3. Block proposers validate transactions as they arrive, assemble a block proposal, and broadcast it to other validators in the shard. Validators validate the block and update their local state tree.

4. Each shard validator then independently broadcasts an aggregate summary of its proposed state transition to the validators in the Root Chain. Importantly, the validators in shards do not participate in independent consensus protocols. They simply demarcate blocks, validate transactions, and send a summary of the result to validators in the Root Chain.

5. Root Chain validators reach consensus confirming that received summaries from shards are in coherence (this is a defined majority agreement depending on the requirements of each partition) and form valid, safe state transitions extending the previous certified states of shards. Unanimous shard-level agreement would require less validators in a shard to ensure decentralization but at the expense of liveness.

6. The Root Chain validators collectively generate a cryptographic proof of uniqueness or Unicity Certificate (UC) as the final step of the ledger consensus protocol.

7. This UC is returned to each shard validator which then adds it to its block to finalize it, and the process repeats.

8. The next round is started, parameterized by the recent input from the Root Chain.

Simplified message flow of a consensus protocol round

Delegated Proof of Stake Execution

Alphabill is governed by Delegated Proof of Stake (DPoS) rules, as an efficient and environment-friendly alternative to Proof of Work mining. The rules are executed on-chain by the Governance Partition, avoiding the need for centralized parties overseeing the operational aspects of the network. DPoS rules perform permissionless validator assignment into partitions and shards and remunerate the validators and the stakers behind them with block rewards.

DPoS rules prevent "sybil attacks" by requiring that each validator is backed by a possibly delegated but unique stake, which, due to the scarcity of ALPHA tokens, limits the number of candidate validators. Stake is also a tool in the toolbox of crypto-economic security layer. Validators' block rewards correlate to the amount of stake as well as the stability and the amount of usable work performed.

Comparison with Federated Blockchains

It is informative to compare the Alphabill approach with other approaches to partitioning.

Federated vs parallelizable blockchains. Periodic relays vs constant connection.

Previous attempts at horizontal scaling have taken a federated approach, where multiple blockchains operate semi-independently, each with their own consensus protocols run by a distinct set of validators. Federation occurs via "bridges" or "relay chains" that allow communication between the different blockchains. The security model of each blockchain in the federation is distinct and each may only have a small number of validators, and an even smaller number of relay chain or bridge nodes. This approach has uses in decentralized applications, where small applications can be run in separate blockchains, each of which has lower security requirements than what would be needed for a global settlement layer.

In Alphabill's case, the partitions are subtrees of a large, distributed state tree, thus there is no need for periodic relaying of messages or trust anchors, and no inherent security risks. In other words, it is not a periodic process but a constant connection, greatly enhancing performance as well as security.

Comparison with Layer 2 Scaling Solutions

Layer 2 solutions are proposed as solutions to the scalability limits of layer 1 protocols. However, these sacrifice either security (optimistic rollups) or performance (ZK rollups). Due to the state commitments in the layer 1, they improve throughput by using centralized components before hitting a hard limit, improving layer one performance about two orders of magnitude at most. There is also no direct way to settle transactions across rollups—whether that is a simple payment or linking smart contracts together (composability). Another challenge for rollups is censorship resistance—the sequencer is typically a single monolithic server.