Skip to main content

Distributed Machine Architecture

The Alphabill Distributed Machine operates one large state tree distributed across a network of redundant validator nodes in a modular fashion. The state tree is subdivided into partitions which operate subtrees of the overall state tree. Partitions share a common framework of unicity certification, implemented by the Root Chain, a Delegated Proof of Stake Network. The system is decentralized and permissionless due to on-chain Delegated Proof of Stake mechanisms controlling the operational aspects of the network.

Network (validators) and state tree views of the Alphabill machine.

The left-hand side in the above diagram shows the component machines in the network. The right-hand the state tree view, that is, the data structures managed by respective validators. Each partition is a subtree in the overall state tree. The depicted subtree of every partition is replicated across all validators of the respective partition.

Note that we show the machines in the Root Chain connected (the solid lines) and not in the partitions to indicate that there is a single consensus instance, maintaining the partition-wide synchrony of each individual partition.

Root Chain​

The Root Chain is a Delegated Proof of Stake (DPoS) network that provides:

  • Network orchestration providing randomness and timing references (liveness).
  • Enforcement of the safety property (no double-spending, no parallel histories).
  • Enforcement of aggregate transaction system rules.
  • Enforcement of partition-level consensus.
  • Proofs of uniqueness (Unicity Certificates).

The Root Chain does not store transaction data or validate transactions. Its primary purpose is to create Unicity Certificates which are passed down from the Root Chain to each partition below and stored in blocks. The Unicity Certificate includes the group signature generated by the validators in the Root Chain after completing all necessary consistency checks. These checks will include whether the validators in a partition are in coherence, whether they extend the previously finalized block exactly once, and aggregate checks for the specific transaction system in each partition (for example, in currency partitions the money invariance is also checked).

The Unicity Certificate framework allows a common root of trust across partitions, that is, proofs generated in one partition can be verified in another as they share the same root of trust.

Partitions​

Partitions are subtrees of the global state tree split according to function. System-defined partitions include the Governance Partition, Alphabill Native Currency Partition, Atomicity Partition, User Token Partition and the EVM Partition.

Alphabill partitions showing system defined and user defined partitions. User defined partitions can be added in a permissionless way.

Each partition consists of one or multiple shards.

Shards​

Partitions start with a single shard comprised of a set of validators all of which share the same validation rules. A shard provides bulk transaction validation, state-keeping, ledger handling, and smart contract execution.

Alphabill partitions showing a multi-shard User Token Partition.

As capacity grows within a partition and the validators approach capacity, additional shards can be added by splitting the state tree and the subtree splits managed by a different set of validators. Constraints on capacity include the memory constraints due to the size of the state tree, computational power to process transaction orders and network bandwidth.

A partition before and after a shard split from 1 to 2 shards, each with 7 validators.

The figure above shows how the shard state tree is split amongst the existing validators (the black dots). New validators (the red dots) join each shard to ensure that the number of validators per shard stays within defined limits.

The state tree can now continue to grow in each shard until it reaches capacity again at which point another split can occur.

The two shards can now expand their subtrees to meet the increased demand.

Validator machines within a shard participate in a single consensus instance in coordination with validators on the Root Chain—each shard does not have a separate consensus instance.

Stateful and Stateless Validators​

Stateful validators are the machines that store the state tree in memory and update the tree in accordance with ledger rules and transaction orders. Stateful validators that join the network need to synchronize to the current state of the blockchain before they can propose and validate blocks. Decomposition theory makes it efficient to have stateless validators also participate in validating blocks. These validators do not need to synchronize the chain, that is, all the information required to verify block proposals can be included within the proposal itself—no additional state information is required.

Stateless validators verify blocks without needing to synchronize the chain.

Stateless validators allow for massive decentralization. Anyone with additional computational power can join the network and instantly start to earn rewards by verifying block proposals sent by stateful validators.