Alphabill

Public Token Infrastructure

Alphabill 1 2023
Contents:

1. Introduction ..........................................................................................................................4

2. Design Goals ......................................................................................................................5

2.1 Scalability of production............................................................................................5

2.2 Scalability of verifiction.............................................................................................6

2.3 Fast Deterministic Settlement Finality ........................................................................6

3. Decomposition Theory ......................................................................................................7

4. Transaction Units ............................................................................................................... 8

5. State Tree ..............................................................................................................................9

5.1 Recursion: State Evolution Over Time.....................................................................11

5.2 Certificates...................................................................................................................13

5.3 State Tree Splits..........................................................................................................14

5.4 Auto-sharding..............................................................................................................16

5.5 Transaction Orders......................................................................................................17

5.6 Double Spending.........................................................................................................18

6. Network Architecture........................................................................................................18

7. Alphabill Consensus Protocol......................................................................................... 19

7.1 Steps in the Consensus Protocol ......................................................................... 21

7.2 Alphabill Trust and Shared Security Model .......................................................22

7.3 A comparison with federated blockchains. .......................................................25

7.4 A comparison with layer two scaling solutions ............................................... 26

8. User Token Partition: Object Oriented Design............................................................27

8.1 Fungible and Non Fungible Tokens........................................................................29

8.2 Token Mutability: Implementing State Machines.............................................29

Alphabill 2 2023
9. Atomicity Partition: Decentralized Exchange ..................................................................31

10. Governance Partition ............................................................................................................31

11. Verifiable Data Partition........................................................................................................32

12. Alphabill User Contracts.......................................................................................................33

13. Application Specific Partitions ..........................................................................................34

13.1 Account-based Smart Contract Platforms ..............................................................34

13.2 Centralized Legacy Applications ...............................................................................35

14. Public Token Infrastructure.................................................................................................35

Alphabill 3 2023
1. Introduction
Historically, all blockchains have been designed using UTXOs or accounts as transaction
units. As every transaction, by definition, will involve at least two transaction units, the
ledger is interconnected and the history of each asset in the ledger is dependent on
other assets. These choices severely limit the achievement of performance goals. Either
the chain gets congested or additional layers, such as rollups or federated consensus
instances are introduced which result in compromises in security, performance, settle-
ment finality etc.

Alphabill is the first permissionless, censorship resistant public blockchain where all
assets are independent - there are no cross dependencies between assets that require
a global ordering of transactions to achieve deterministic execution. Every transaction
updates only a single unit. This allows for perfect parallelism i.e., all assets can be up-
dated and verified independently, and global state can be partitioned and managed by
clusters of machines (validators) operating independently in parallel.

A useful analogy is physical cash. Physical cash transactions exhibit perfect parallelism of
settlement and verification. Cash transactions can settle independently, and users can
independently verify that the cash in their wallet is both available and valid (not-counter-
feit). The goal of Alphabill is to replicate these properties using public blockchain.

This introduction is optimized for explanatory clarity. Technically precise descriptions,

academic papers, security proofs and specifications are available at www.alphabill.org.

Alphabill 4 2023
2. Design Goals
2.1 Scalability of production

Figure 1. Scaling through more powerful machines or many machines

There are two ways to scale a system; a) “vertical scaling”, using a more powerful
machine or b) “horizontal scaling” using parallel decomposition such that the work is split
between many machines. Developers are attempting to use both approaches to scale
blockchains today. Solana is an example of the former where a single powerful “leader”
machine orders and validates transactions and other machines confirm the results. This
approach has a hard limit on scalability (the power of a single machine) and limits decen-
tralization as the computational requirements limit accessibility. Horizontal scaling is at-
tempted by numerous layer one protocols (Polkadot, Cosmos, ICP, AVAX, Near etc.) how-
ever these resemble a system of federated chains with separate consensus instances
and additional chains, called relays, beacons, hubs etc. providing cross-chain settlement.

A design goal of Alphabill is to have practical unlimited throughput1 with a single con-
sensus instance that provides linear scalability, without sacrificing security, decentraliza-
tion, or performance.

1 Practical means supply can scale to meet all human and machine demand. We recognize the finiteness of the Universe

Alphabill 5 2023
2.2 Scalability of verification
Scalability of verification is as important as scalability of applications for real-world appli-
cations. In all existing protocols, to independently verify a single transaction a large set
of related transactions must be verified. Due to this requirement, many users choose
to sacrifice the benefits of decentralization by using “light clients” which rely on trusted
intermediaries.

Figure 2. Ledger decomposability

The above figure on the left is the current model of blockchains. There is a single Proof
of Uniqueness (whether generated by Proof of Work, Proof of Stake or some other
mechanism) for the ledger created once per block.

A design goal of Alphabill is parallel decomposition, i.e., each token in the system (either
Alphabill native currency tokens or the equivalent of ERC20 user generated tokens) can
be independently updated and verified in parallel.

2.3 Fast Deterministic Settlement Finality

In Alphabill, certificates (proof of uniqueness, proof of unit state, proof of transaction
execution, proof of transaction non-execution) are created on-chain and potentially
used off-chain. Probabilistic finality has the potential to re-organize the blockchain
which would invalidate a certificate issued during the re-organization. As this would be
problematic for external users relying on a certificate a design requirement for Alpha-
bill is fast deterministic finality.

Alphabill 6 2023
3. Decomposition Theory
Alphabill is based on a theory of decomposition2 . There is no bottleneck in the network
and computational resources can be added indefinitely – the system as a whole scales
linearly (production and verification) without sacrificing security or performance.

Figure 3. Parallel Decomposition

To implement this design Alphabill introduces four innovations:

1. A New Transaction Unit: UTXOs and accounts do not allow parallel decomposi-
tion. The Alphabill blockchain is based on bills (similar to physical cash bills). The state
tree in Alphabill is implemented with new data structures that allow for assets to be
updated and verified in parallel.
2. State Tree Recursion: The state tree is built recursively allowing for independently
verifiable blockchains to be extracted for each individual token. This allows tokens
minted on the blockchain to be verifiable and actionable off-chain in the real world.
3. A New Consensus Protocol: Alphabill has a single consensus instance across the
network such that deterministic finality is achieved across the network within one
block.
4. A New Computational Model: assets can be locked using predicates similar to
Bitcoin locking scripts and a certified messaging model is used to allow users to pass
proofs across different parts of the network.

2 https://www.techrxiv.org/articles/preprint/A_Unifying_Theory_of_Electronic_Money_and_Payment_Systems/14994558/3

Alphabill 7 2023
4. Transaction Units
All existing blockchain protocols use either UTXOs or accounts as transaction units.

Figure 4. UTXOs and Accounts require coordination between monetary units

If the accounts or UTXOs are on different machines, then coordination is needed be-
tween the machines in order to atomically execute a transaction. For accounts this is
obvious (they are on different machines and the machines need to communicate so
that one account balance goes down and the other goes up). The same principle applies
to UTXOs. If a user wishes to pay 100 units and has two UTXOs on different machines
each worth 50 units then the two UTXOs on different machines need to be marked as
spent and a new UTXO needs to be created with a value of 100. This process requires
coordination across the different machines.

In Alphabill we use the principle of a bill-based money scheme.

Figure 5. bill-based money schemes can execute transactions in parallel.

Alphabill 8 2023
In a bill-based money scheme, such as physical cash, the only thing that changes during
a payment is the ownership of the bill. As no checks or coordination is needed, the bills
can be on different machines and processed independently in parallel.

Potential limitations of bill schemes are a) atomicity - how to ensure multiple bill transac-
tions are atomic i.e., there is not a situation where only a subset of bills are transferred
during a multi-bill payment, and b) precise payments - if a user has a bill worth 100 units
how do they make a payment of 50 units?

In the next section we will introduce data structures that allow for atomic precise
payments within a single block through state tree splits.

5. State Tree
Historically different blockchain platforms have tried different approaches to repre-
sent the state of managed assets. Bitcoin for example stores UTXOs in the chainstate,
a levelDB database. Ethereum uses a Merkleized Patricia Trie to represent accounts
i.e., each leaf of the tree is either an account or a smart contract serialized by its leaf
address.

Figure 6. Alphabill State Tree

Alphabill 9 2023
In Alphabill we use a count-certified authenticated Adelson-Velsky and Landis
(AVL) tree where the nodes of the tree are either tokens or smart contracts. Tokens are
first-class citizens in that each token in the system (whether native Alphabill currency
tokens or user defined tokens) is serialized by its identifier in the state tree.

Figure 7. Ethereum uses a state tree of accounts. Alphabill uses a state tree of tokens

Ethereum uses accounts which are represented as leaves of the state tree. Tokens are
then created by smart contracts and those tokens exist as variables inside the smart
contract. In Alphabill tokens are created directly on the state tree and a transaction
order in Alphabill will change the ownership of the token.

The main advantage of over accounts is sharded parallelism of production and

verification.

Figure 8. Parallel execution of token transfers

Alphabill 10 2023
The state tree is split into sub-trees or shards each of which manages a set of tokens.
A transaction involves only a change in the ownership of a token, validated based on
local context: the token's previous state and transaction order only. This implies that the
sub-trees can be processed in parallel without any synchronization or coordination with
other sub-trees.

To understand scalability of verification and explain how individual ledgers for tokens
can be verified in parallel we need to understand how the state tree evolves over time.

5.1 Recursion: State Evolution Over Time

Figure 9. State evolution over time.

The figure above shows the state tree for four different rounds. The red hash values
are the Merkle Roots for the state tree for four different rounds from B0 to B3. At each
successful round a Unicity Certificate is generated via the Proof of Stake algorithm that
proves the uniqueness of the state tree.

The state tree is built recursively i.e., the leaf node hash-value for the current block is
the hash-value of the leaf-node of the previous block hashed together with the hash
value of the transaction order for the specific token. This is shown above in the dotted
lines. The blue hash-values represent the state hashes for an individual token ledger,
which can then be extracted and verified with the same proof of uniqueness as the en-
tire state tree.

In order to build and extract a ledger for each token one more data structure is needed.

Alphabill 11 2023
Figure 10. Hash chain for leaf node at Block B3

The yellow hash-values shown above represent the hash chain that cryptographically
links the leaf node state hash to the state tree root.

With the above data structures, we can show how to build a sub-blockchain for a
specific token.

Figure 11. Token Blockchain

Each block in the blockchain consists of the transaction order, the hash chain and the
leaf hash value, which is the hash value of the transaction order and the previous block
hash value.

When the token blockchains are combined we have the Alphabill blockchain.

Alphabill 12 2023
Figure 12. Decomposability of the Alphabill Blockchain

This ability to decompose the ledger into token sub-ledgers allows a recipient of a trans-
action to independently verify without trusted parties that they are the new owner of
a token without needing the full ledger3. A user of the blockchain only needs to care
about the verification of the tokens that they own. This is similar to physical cash tokens.
A user cares about the bills in their wallet, not those of anyone else. Independent veri-
fication can be done on mobile devices, or even offline, without the need to trust third
parties as in the case of having to rely on traditional “light clients”.

5.2. Certificates
A certificate is a data structure used within Alphabill that contains elements that enable
an interested party to verify proofs such as proof of uniqueness, proof of ownership,
proof of transfer etc. The design of the Alphabill state tree allows for different types of
certificates to be created.

• Unicity certificate — proof that the ledger is unique. In the above case this will
be the group signature generated by the validators in the Proof of Stake consensus
protocol after completing all necessary consistency checks. These checks will include
whether the validators in a shard are in coherence, whether they extend the previ-
ously finalized block, and aggregate checks for the specific transaction system in each
partition. (for example in currency partitions the money invariance is also checked)

3 Technically, what is useful as a proof of payment is a “proof of transaction execution” which applies to a single transaction only, without the full
transaction and token history.

Alphabill 13 2023
• Transaction execution certificate — a proof that a transaction t is in the block
B of the blockchain. In the above example the transaction certificate will include the
yellow hash values.
• Unit certificate — a proof that the unit (e.g., a token or a smart contract) has
certain attributes, for example ownership, in the state tree.
• Transaction non-execution certificate — a transaction is not in a certain block.

5.3 State Tree Splits

It would be inefficient to have to allocate space in the state tree for every token. For
example, the equivalent of an ERC20 smart contract may require the issuance of billions
of tokens. Fortunately, creating state space for all individual tokens is not necessary as,
upon issuance, there are a limited number of owners. In this section we show how the
state tree can be expanded and contracted through transaction orders.

Consider the equivalent of an ERC20 token called AToken, the total issuance of which
will be 100 billion tokens. Initially, there will be a single owner (the issuer) who will own
all 100 billion tokens.

Figure 13. User created token at issuance

When a transfer of one token occurs to a new owner the tree is split and the original
token is replaced with a node with child leaves, which represent the new fractions of the
token.

Alphabill 14 2023
Figure 14. User created token after first split

The Alphabill AVL tree is count certified so that each parent node maintains the total
sum of created parts.

Figure 15. User created token after second split

After a second transfer of one token the state tree looks like above4.

The same bill-splitting principle can be applied to any fungible token. For example, the
figure below shows a user who wishes to make payment of 34 cents using a “Alpha-USD”
stable coin but only has one single Alpha-USD dollar.

4 In reality the AVL tree is self-balancing. For a precise description please see Alphabill yellow paper.

Alphabill 15 2023
Figure 16. Precise payment of 0.34 Alpha-USD

Allowing for splits in this way also allows for precise atomic payments within a single
block. Joins are also possible however they are not available as part of transaction
orders. Instead, a user may make a “dust collection” swap request such that small val-
ue tokens may be consolidated into a single token. The dust collection procedure is
executed independently during the creation of a new block.

5.4 Auto-sharding

Figure 17. Auto-sharding

If the computational load on a single shard becomes too high for a machine to process,
then the tree can be split. This is handled by a decentralized governance process.

Alphabill 16 2023
5.5 Transaction Orders

Figure 18. Simplified layout of a Transaction Order

The bill identifier is the token serial number i.e., the shard identifier and address of the
token in the state tree.

Amount is the amount to be transferred. In the event that the amount is less than the
value of the bill then the bill will be split.

Payee predicates are similar to Bitcoin locking scripts and describe how the next owner
can gain access. Predicates are used in locking conditions for stateful smart contracts
and to enable fine-grained control over rights and limitations for token transfers. For
example, they can be used to require two private keys, or a combination of several keys
to create the next transaction, or that the recipients present proofs that they are in
compliance with specified policies (KYC etc.)

Ownership Proof can be for example a digital signature of the payor or a Zero
Knowledge proof.

Alphabill 17 2023
5.6 Double Spending
Double spending is impossible by design in the Alphabill model. Each token has a unique
address and there can only be one proof of uniqueness per round, assuming the hash
function used is collision resistant.

6. Network Architecture
The Alphabill state tree is operated by a network of machines which is decomposed into
Partitions which operate sub-trees of the overall state tree. Partitions share a common
framework of unicity certification, organized by the Root Chain.

Figure 19. Network representation of the state tree.

Root Chain

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

• network orchestration providing randomness and timing references (liveness)
• enforcement of transaction system rules in partitions
• enforcement of consensus (safety)
• proofs of uniqueness (unicity certificates)
The Root Chain does not store transaction data or validate transactions.

Alphabill 18 2023
Partitions

Partitions are logical divisions of the state tree. Examples include the Governance Par-
tition, Alphabill Native Currency Partition, Atomicity Partition, Verifiable Data Partition,
User Token Partition and Application Specific Partitions. Each partition implements a
transaction system that complies with the Alphabill Transaction Framework. Section 8
describes the functionality of each partition.

Shards

Shards are sets of validators, all of which have the same validation rules used to process
and store subledger blocks. All machines in all shards participate in a single consensus
instance in coordination with validators on the Root Chain. The shards provide bulk
transaction validators, state-keeping, ledger handling and smart contract execution.

7. Alphabill Consensus Protocol

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

Longest Chain Rule (e.g., Bitcoin): blocks are proposed; if the next block chains from
this block and then some more valid blocks chain continue the chain, then the block can
be considered as final (with probability depending on chain length).

Collecting Confirmations (e.g., Solana): a block is proposed; it is eventually finalized

when reaching a required number of signed confirmations.

Deterministic Finality (e.g., Tendermint): nodes run a consensus protocol (in the
narrower sense of "consensus" from distributed systems research5 ) to reach agree-
ment on and finalize every block.

5 See for example Chapter 5 of "Introduction to Reliable and Secure Distributed Programming" by Christian Cachin, Rachid Guerraoui, Luís Rodrigues.
Springer, 2011. DOI: 10.1007/978-3-642-15260-3

Alphabill 19 2023
Alphabill is similar to Tendermint as it provides deterministic finality. The low-level con-
sensus protocol is based on Hotsuff 6 optimized for latency not throughput (as the Root
Chain does not need to validate client transactions)

Figure 20. Validator Virtualization

A virtualization layer is operated by the Governance Partition validators, such that vali-
dators 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 incentiv-
ized based on equalization and stabilization rules, ensuring balance and security across
different shards.

Figure 21. A single consensus instance

6 https://arxiv.org/abs/1803.05069

Alphabill 20 2023
The Root Chain is based on Delegated Proof of Stake but with massively reduced com-
putational load. Instead of client transactions, the Root Chain validators only need to
validate and process aggregate summaries from shards. They effectively check the re-
sults of the shard validators and confirm they are in coherence. The Root Chain gener-
ates Unicity Certificates for identified partitions as described above.

Importantly the set of validators on a shard do not participate in a shard-level consen-

sus protocol. Each validator cannot create a valid block unless it has received a Unicity
Certificate from the Root Chain.

7.1 Steps in the Consensus Protocol

1. Client wallets send encrypted transaction requests to a shard. (Wallets know which
shard as the identifier of the token encodes both the shard identifier and token ad-
dress.) The same principle applies to smart contracts. Encryption is used to prevent
any information being revealed that could allow a block proposer to front run or
otherwise censor transactions.
2. Validators within a shard receive encrypted transaction requests from client wallets
and forward them to parallel block proposers, based on round-specific mapping.
3. Block proposers order the encrypted transactions and broadcast the ordered set
of transactions to other validators in the shard. Validators collectively decrypt trans-
actions using threshold decryption, validate them, 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 valida-
tors in shards do not participate in independent consensus protocols. They simply
validate transactions and send a summary of the result to validators in the Root
Chain.
5. Each Root Chain validator confirms that received summaries from shards are in co-
herence (this is a defined majority agreement depending on the requirements of
each partition). Unanimous 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
(Unicity Certificate) as the final step of the ledger consensus protocol, governed by
Delegated Proof of Stake rules.

Alphabill 21 2023
7. This proof is returned to each shard validator which then adds it to its block to final-
ize it and the process repeats.
8. The next round is started, parameterized by the recent input from the Root Chain.

Figure 22. Simplified message flow of a consensus protocol round.

7.2 Alphabill Trust and Shared Security Model

The parallelism of Alphabill allows for different trust models to be selected by users.
Every user can independently audit the individual token histories that they have own-
ership of. They can store not just the private key that controls transfer of the token but
also the token ledger itself. This is similar to physical cash – consumers care only about
the verifiability of the cash inside their wallets – not that of everyone else in the econo-
my. This independent verification at the token level opens up new methods to ensure
data availability and detection of malicious activity.

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

a. The first layer happens during the block production process. Validators on a shard
independently send an aggregate summary of their transactions to the set of Root
Validators. On a partition level basis, the required level of agreement between the Val-
idators can be selected through a partition management governance process to deter-
mine 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.

b. 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 mali-
cious activity through the validation of transactions. If malicious activity is detect-
ed 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 securi-
ty 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. Hidden,
or observer validators, can join a shard and participate in securing the network.

c. The third layer is crypto-economic security. Here, the underlying assumption

is that validators are malicious, but economically rational actors. The cost of los-
ing rewards and potential slashing outweighs the economic gain of malicious ac-
tivity. It is still possible that a malicious actor behaves irrationally, for e.g., fame,
but it is very unlikely that a majority of validators behave in self-sacrificing way.

d. The fourth layer of security is applied post block production. Here the underlying
assumption is that all validators in a shard are potentially malicious, adaptively col-
lude and hidden validators have not detected malicious transactions. Users can earn
“audit rewards” by volunteering to participate in a crowd-sourced verification of the
ledger by sharing the work of auditing every block in every shard in every partition.
The work is split up amongst the volunteering pool of wallets using a random sorti-
tion process. If an inconsistent block is discovered a fraud resolution process is initi-
ated with potential slashing of offending validators. This function has the additional
benefit of confirming data availability of the ledger.

Alphabill 23 2023
e. 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 decomposability, a user can do this
independent verification at the token level i.e. users do not need to rely on valida-
tor-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 all historic transactions associated with that token have been executed
correctly.

d) and e) are unique to Alphabill due to decomposability introducing the possibility of

parallel verification.

The most important aspect of security is the property of non-forking: both at unit level
(no double-spending) and at partition level (no alternative hidden histories of partitions).
In order to fork, an attacker must compromise both Root Chain and partition validators,
that is, the Root Chain is offering “shared security” to partitions.

In the original Bitcoin blockchain there is no requirement for users to trust anyone.
A user can download the entire blockchain can go through the ledger transaction by
transaction to independently verify its correctness. However, as the system scales, this
approach inevitably leads to centralization. For example, at 1M transactions per second
the Bitcoin blockchain would be in the order of one Exabyte of data, making it beyond
reach of individual users to conduct independent verification.

Alphabill 24 2023
7.3 A comparison with federated blockchains.
It is informative to compare the Alphabill approach with other approaches to
partitioning.

Figure 23. Parallelizable vs Federated Blockchains

Previous attempts have taken a federated approach (Polkadot, Avalanche, etc.), where
multiple blockchains operate semi-independently, each with their own consensus pro-
tocols 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.

Alphabill 25 2023
7.4 A comparison with layer two scaling solutions
Layer two solutions are proposed as solutions to the scalability limits of layer one proto-
cols however these either sacrifice security (Optimistic Rollups) or performance (ZK Rol-
lups). Due to the state commitments in the layer one, they improve throughput by using
centralized components, before hitting a hard limit. 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.

Alphabill 26 2023
8 User Token Partition: Object Oriented Design
Alphabill supports user-defined tokens as first-class citizens (each token created occu-
pies unique space in the User Token Partition state, not as a variable in a smart contract)
offering a flexible framework for defining custom token types, creating tokens of these
types, and transacting with such tokens. This system uses a system of predicates or
clauses to control access to different actions. The main action that tokens can perform
is for ownership to be transferred. The predicate that controls ownership is the “bearer
predicate,” or “bearer condition.” Alphabill predicates work similarly to bitcoin unlock
scripts. They are simply functions that accept a number of arguments and return true
or false.

For example, a “spend” transaction supplies arguments to the current bearer predicate
and a contains a new bearer predicate, which is to be installed upon success i.e. If the
arguments result in the function returning true, then that transaction succeeds, and the
new bearer predicate replaces the old one. During execution of the predicate code, the
interpreter has access to information which depends on the runtime, such as the cur-
rent block height, and the identifier of the token on which the predicate is installed. The
predicate does not contain any mutable state and can only be replaced, not modified.

Figure 24. Token predicate example

Alphabill provides for a system of type inheritance which can be used to describe a rich
ontology for tokens, based on an object-oriented design. A new data structure called a
“token type” is introduced that is similar to a regular token in that it has its own unique

Alphabill 27 2023
state in the User Token partition. A token type can be created by anyone but unlike
regular tokens, token types cannot be transferred – only inherited from. Token types
have additional predicates that the token type creator can use to define different as-
pects of inheritance. This is distinct from the ALPHA tokens in the money partition which
have only one bearer predicate.

The first three additional predicates are as follows:

1. subtype: this predicate must be satisfied in order to create a new inherited token
type. This can be used to define the conditions under which new token types can
inherit from this type. This can be used to create controllable hierarchies of token
types.
2. mint: This predicate must be satisfied in order to create tokens of a given token type.
3. inherit bearer: this predicate defines additional conditions of transfer imposed by
the token type. This predicate must be satisfied in additionto the main bearer predi-
cate, defined above. Unlike the main bearer predicate the inherit bearer predicate is
immutable so it can be used to provide a mechanism for token designers to impose
transfer restrictions for tokens that are derived from the original token type. The in-
herit bearer predicate applies to any tokens of the defined type and any tokens that
belong to type that inherit from the defined type.

Since it's possible to inherit many levels deep, there may be many, chained, inherit bear-
er clauses that must all be satisfied in order to transfer a token. There are numerous
reasons that this might be useful, including:

1. Licensing of popular token types.

2. Creation of token hierarchies.
3. Establishing provenance of tokens.
4. Implementing fine-grain roles and permissions.
5. Creating whitelists or blacklists of owners.
6. Many others, still to be explored.

Alphabill 28 2023
8.1 Fungible and Non-Fungible Tokens

The most important property of a fungible token is the amount or value that it rep-
resents. A fungible token can be split into several smaller tokens of the same type so
that the sum of the values of the resulting tokens is equal to the value of the original
token. Conversely, several fungible tokens of one type can be joined into one larger to-
ken of the same type so that the value of the resulting single token is equal to the sum
of the values of the input tokens. In both cases the source tokens are consumed in the
process, to ensure that neither of these operations create or destroy value.

The main characteristic of non-fungible tokens is that they have distinct identities and,
in general, even two tokens of the same type are not interchangeable, even though they
may share some characteristics as a result of inheritance. Because of that, non-fungible
tokens cannot be split or joined.

An example of inheritance in a healthcare context, could be that a non-fungible token

is used to represent the right to view some of a patient’s healthcare records, say the
results of medical tests. A consent token might be a base type for this NFT, and it might
provide for common characteristics, such as an access expiration time or access limited
to an accredited medical professional. All Healthcare Consent Tokens inherit these re-
strictions, but a specific subclass might be further restricted so that it can only be used
to view medical test results, not other kinds of medical records. Additionally, and finally,
a specific instance of the subclass of NFT might also specify the individual healthcare
provider or test type that the consent applies to. Thus, NFT’s and carefully arranged
restrictions and a system of inheritance can be used to create a rich system of tokens,
which is applicable, not only in healthcare, but in a myriad of other ecosystems, where
the original creators are able to exert some, but not total control over the incentives
and economics of the tokens they create.

8.2 Token Mutability: Implementing State Machines

User tokens have an additional "data" field. This mutable data can be changed, based
on satisfying an additional predicate called the data update predicate. This works in a
similar way to other predicates: a user sends a transaction order, which supplies argu-
ments to the predicate, and new data that should replace the old data. If the predicate
returns true, then the data is changed as a result of the transaction.

Alphabill 29 2023
Importantly, the data update predicate does not need to be the same as the bearer
predicate. This means that the owner of the token is able to give other users permission
to change the data on a token they own.

Another key concept is that the current contents of the data field itself, as well as the
proposed new contents of the data field are both available during the evaluation of the
data update predicate. This predicate can be considered a function where the user sup-
plied arguments, the previous data field, and proposed new data field are all within the
scope of the function body.

An example of a use case where this might be useful could be in trade finance. A token
could represent a shipment. The URI could point to immutable documentation about
the contents, original ownership, and tax and regulatory information about the ship-
ment. The data field could be used to implement a state machine, which describes the
transfer and responsibility for the goods, along the supply chain. The ownership of the
token itself can represent ownership of the goods being shipped, and lending - either
through a centralized or decentralized lending platform - can take place using the token
as collateral.

Finally, the data update clause is also an inheritable feature. NFT token types have an
additional predicate called the "inherit data” predicate It works the same way as the oth-
er inheritance predicates, in that it is defined as part of the token type, and all tokens of
that type inherit it. It is also subject to the same sub-typing rules as the "inherit bearer"
predicate, so parent inherit data predicates are inherited by all child token types, and all
tokens that are minted from them.

Putting together the features of inheritance and mutability allows users to create a rich
ecosystem of useful tokens that can be used by companies, individuals, and govern-
ments to represent real world processes and use cases. Tokens can be directly used
for the exchange of digital rights, goods and services, and they can be programmed to
follow business processes that meet enterprise and regulatory requirements in an au-
tomated decentralized manner.

Alphabill 30 2023
9. Atomicity Partition: Decentralized Exchange
In a sharded blockchain system it is useful to provide native support for atomic transac-
tions. These can be in the form of multi-token atomic transfers or atomic swaps between
different token types (e.g., for Delivery versus Payment where assets are exchanged for
currency). In a single machine model this is straightforward; smart contracts such as
Uniswap have access to the entire global state and can ensure atomicity – either the
contract succeeds, and multiple tokens are swapped, or the contract fails, and no own-
ership is changed. In Uniswap, the smart contract provides both exchange and settle-
ment services - these aspects of trading are typically separated in traditional financial
applications for reasons of scalability and specialization.

In Alphabill a dedicated atomicity partition provides this functionality, allowing decen-

tralized exchanges to be separate from the settlement operations.

10. Governance Partition

The role of this partition is sixfold:

a. On-chain governance: voting on governance proposals
b. Partition Management: adding and removing new partitions
c. Validator Assignment: managing validator life cycles and reputations
d. Network Capacity Management: approving dynamic sharding proposals
e. Validator Reward Handling: unlocking “common good” rewards, staking rewards,
Root Validator and Transaction Validator rewards
f. Software Certification: approving updates to transaction system specific validation
software and coordinating software updates

Latency in this partition is not critical as the operations performed here happen over a
longer timescale than actual transactions. As such the block time can be much longer
than other partitions, enabling mass participation.

Alphabill 31 2023
11. Verifiable Data Partition
There are many examples of use cases for tokens where double spending is not a
requirement. For example, consider a college diploma. In this case it does not make
sense to transfer ownership of the token – it is non-fungible and non-transferrable. If
a token is not transferrable then not only should double spending be impossible but
also “single spending” As such, this partition simply receives and stores hash-values and
associated meta-data such as identity information of the submitter. It does not need to
prevent double spending and does not require a sub-ledger for every token.

Figure 25. Disaggregation of blockchain proofs

This partition is designed to disaggregate the proofs that the blockchain can provide – if
a developer requires proof of integrity, provenance, integrity, time, identity these proofs
can be generated separately. If the token can be transferred, then proof of uniqueness
is a must to prevent double spending and the User Token Partition should be used.

Alphabill 32 2023
12. Alphabill User Contracts
Solidity and the Ethereum Virtual Machine (EVM) were hugely significant contributions
to the community. It is possible to celebrate these inventions while recognizing their
limitations. Ethereum’s implementation of smart contracts has one major limitation – it
is based on shared memory i.e., it assumes a shared global state. This enables compos-
ability of smart contracts but comes at the cost of scalability. Since the state is global,
it must be able to be stored, and manipulated, in its entirety, on every validator. This
implies that the overall global state can never grow larger than can be processed by a
single machine, and that computation cannot take place in parallel.

Figure 26. Smart Contract Composability

In Alphabill, we can take advantage of the shared security model and Unicity Certificate
framework to allow a common root of trust across shards. The Unicity Certificate, gener-
ated by the Root Chain, provides for the creation of a proof of a contract's internal state,
and this proof can then be transported across shard boundaries, interpreted, and acted
upon by smart contracts on different shards.

Alphabill 33 2023
Smart Contracts are composable, in that multiple smart contracts can be chained to-
gether the output of one contract being used as the input to the next contract. The first
step is to transfer ownership of a token to the smart contract. This is done using pred-
icates, where a user sends a transaction order to a token address assigning ownership
to a smart contract, together with a timeout period so that if the contract fails owner-
ship is reverted back to the original owner. Once the new predicate has been registered
in the token ledger the data and proof can be sent, by the user, to the smart contract
address.

13. Application Specific Partitions

The advantage of separating execution from asset settlement is that different types of
applications can be plugged into the Alphabill framework.

Figure 27. Application Specific Partitions

13.1 Account-based Smart Contract Platforms

For an account based smart contract platform a user will transfer tokens into a state
which gives specific control to a smart contract. The smart contract will then credit its in-
ternal account structure, execute and redistribute value amongst its internal accounts.
If a user wishes to withdraw tokens from the smart contract they can request a with-

Alphabill 34 2023
drawal, the smart contract will debit the user’s account and then generate a proof that
can be used by the user to reclaim ownership of the token on the token partition.

This separation of execution from settlement has a strong security feature as a broken
smart contract cannot arbitrarily claim ownership of tokens.

13.2 Centralized Legacy Applications

The Application Specific Partitions do not need to be decentralized. For example, it
could be an existing enterprise application. The application can request a partition ID,
receive, and verify tokens and then generate proofs to reallocate those tokens based
on the application logic. The application can produce an immutable log of token actions
which can be verified in a decentralized way. This is similar to Ethereum layer 2 logic
but enables any type of application, including existing enterprise and Web services to
participate in the framework.

14. Public Token Infrastructure

Alphabill can support any of the traditional use cases of public blockchain with the ex-
ception of those that require a shared global state – flash loans and MEV for example
are impossible. Here we want to focus on the use cases that Alphabill can do uniquely
– those that take advantage of the decomposability and native parallelism.

Figure 28. Token Potability

Alphabill 35 2023
In Alphabill tokens can be minted on-chain then verified and acted upon off-chain, even
offline. This allows us to consider blockchain not only as a ledger for managing owner-
ship of assets but also a “token-generation” machine as an evolution of Public Key Infra-
structure (PKI) digital signatures.

verifiable data and information supply chains

Instead of just securing data in motion the opportunity for a new Internet is to enable
every piece of data, from an event in a log file to a configuration file in a 5G router to be
“tokenized” i.e, similar to digital signatures data can be presented with cryptographically
verifiable properties such as integrity, time, provenance, and identity, all without the
reliance on centralized trust authorities.

Figure 29. Blockchain as a token generation machine

Protecting data with conventional cryptographic mechanisms like digital signatures,

message authentication codes, encryption schemes etc. has limitations due to key man-
agement which have greatly limited adoption; the percentage of data at rest that is ver-
ifiable today using PKI digital signatures is essentially zero.

Effectively Alphabill is blockchain as public token infrastructure – a censorship resis-

tant machine for the creation and ownership transfer of tokens. Those tokens can be
fungible, non-fungible, non-transferrable or programmable based on predicates. Devel-
opers can choose what type of cryptographic properties they want for those tokens and
those tokens can be used in real world applications or in any smart contract platform.

Alphabill 36 2023
peer-to-peer transfer and exchange of digital rights

The inventors of the Internet were thinking about how to exchange data in a decen-
tralized network that would remain resistant to nuclear attack. They succeeded in their
mission, however their initial design choices have led to centralized gatekeepers and
monetization of users - the consumer has become the product.

A modern Internet can be much more than peer-to-peer exchange of data – it can
be extended to peer-to-peer exchange of digital rights. The blockchain acts as an im-
mutable ledger for encoding those rights and enabling users to transfer and exchange
those rights in a censorship resistant and trustless way. Transferring the ownership of
value is just one example. Everything we do on the Internet – from sending an email to
agreeing to share our data with a social media company can be thought of as a transfer
or exchange of digital rights.

Bitcoin has shown that it is possible to transfer value (ownership rights of digital assets)
across the Internet peer-to-peer without centralized authorities. Every protocol on the
Internet today can be redesigned with digital rights in mind. Email is an example of a
protocol where digital rights are not encoded – hence spam, phishing and a multi-bil-
lion-dollar fraud industry.

verifiable credentials

The inventors of the Internet weren’t thinking about identity – “no one knows you’re a
dog on the Internet”. Anonymity is essential for a modern Internet but not sufficient –
we lack a universally available digital identity system that lets individuals store and pres-
ent any credentials in any context they want, to whomever they want, whenever they
want without the reliance on third parties managing access.

Alphabill is purpose-built with scalability, performance, and censorship resistance to

enable billions of users, applications, and machines to exchange rights in-real time with
almost zero friction.

Alphabill 37 2023
Alphabill 38 2023