Skip to main content
Version: main branch

Alphabill Trust and Security Model

The parallelism of Alphabill allows for different trust models to be selected by users. Every user can independently audit the individual histories of tokens that they have ownership of. They can store not just the private key that controls transfer of the token but also the token ledger itself. This independent verification at the token level opens up new methods to ensure data availability and detection of malicious activity.

There are effectively five layers of security to detect and mitigate malicious behavior of validators.

  • The first layer happens during the block production process. Validators on a shard independently send an aggregate summary of their transactions to a set of Root Chain validators. On a partition level basis, the required level of agreement between the shard validators can be selected through a partition management governance process to determine the level of safety vs liveness for the partition in question. This layer guarantees security under the assumption that only a limited fraction of validators is malicious.

  • The second layer also happens during the block production process. A single honest validator that is part of the validator set within a shard can detect malicious activity through the validation of transactions. If malicious activity is detected, a fraud proof can be generated and sent to the Root Chain prior to the Unicity Certificate being created and returned to the shard. This layer guarantees security on assumption that there is at least one non-colluding validator observing the invalid block proposal. There is no restriction on the number of validators in a shard, and the settlement time is not impacted as the number increases.

  • The third layer is crypto-economic security. Here, the underlying assumption is that validators are malicious, but economically rational actors. The cost of losing rewards and potential slashing outweighs the economic gain of malicious activity. It is still possible that a malicious actor behaves irrationally, for example for fame, but it is very unlikely that a majority of validators behave in self-sacrificing way.

  • The fourth layer of security is applied post block production. Here, the underlying assumption is that all validators in a shard are potentially malicious and adaptively collude. Stateless validators participate in a crowd-sourced verification of the ledger by sharing the work of auditing every block in every shard in every partition. If an inconsistent block is discovered, a fraud resolution process is initiated with potential slashing of offending validators. This function has the additional benefit of confirming data availability of the ledger.

  • The fifth layer of security relies on users to verify the history of each individual token that they take ownership of. In Alphabill, due to the decomposability, a user can do this independent verification at the token level, that is, users do not need to rely on validator-cluster generated proofs but can instead verify compact token ledgers. In other words, a recipient of a token can verify that a) the token was minted in a valid genesis event and b) all historic transactions associated with that token have been executed correctly. This decomposed verification is unique to Alphabill due to state tree recursion and decomposability.

The analogy with physical cash is relevant. When someone gives you a 20 USD note, you just check the validity of that note. You don't need to run the entire economy through your device and check every other transaction in history to be sure that your 20 USD note is valid.

Breaking down Security into its Components​

The most important aspect of security is the property of safety. This includes non-forking at the token level (no double-spending) and at the partition level (no alternative hidden histories of partitions). In order to fork, an attacker must control a configurable number between 51% and 100% of partition validators AND at least 2/3 of Root Chain validators, that is, the Root Chain is offering "shared security" to partitions.

  • The property of validity (rejecting invalid transactions) is guaranteed by a configurable number between 51% and 100% of partition validators and remains efficiently auditable to token owners (token ledgers) and the world, thanks to unicity guarantee.

  • The property of liveness is guaranteed by between 49% to 0% of partition validators (complement to previous) OR at least 1/3 of the Root Chain validators.

  • Data availability of transactions is provided by a quorum of partition stateful validators.

These honest majority assumptions apply to the first two layers of security encompassing the distributed machine setup (see previous section). All other layers, like the crypto-economic security which works even if all validators are dishonest, are effective in parallel and enforce the overall security.