Skip to main content

Alphabill Computational Model

There are two computational models in Alphabill, one for computations that require only a single unit and one for computations that operate on multiple units.

Predicates and smart contracts used for single and multi-token computations.

Both models are shown in the above figure. There are two Alphabill partitions shown, a Token Partition and a Smart Contract Partition. Part of the on-chain state of a token is an owner predicate or the conditions that need to be satisfied for a transaction order to be accepted and executed. For multi-unit computations smart contracts are used. Alphabill has a system-defined EVM partition for smart contracts, but in principle any smart contract platform can be used.

Predicates for Single-Unit Programmability​

The most basic form of an owner predicate would be the verification of a digital signature, that is, in order to transfer ownership, the signature on the transaction order needs to be signed by a private key that matches the public key stored as part of the predicate.

Simplified data format for a token

Shared ownership of tokens can be managed through predicates on individual tokens. A predicate might encode a condition saying "next transaction order must be signed by public key A OR B", giving shared ownership semantics. Another example would be a condition saying "next transaction order must be signed by public keys A AND B", giving multisig semantics to ownership. Predicate evaluation is part of the transaction validation rules—all performed locally within a shard, without requiring global ordering of transactions or the existence of shared state. Predicates are described in detail in User Token Partition.

Smart Contracts for Multi-Unit Programmability​

When a computation such as a smart contract requires multiple tokens as inputs, for example, a DEX (decentralized exchange), transactions are used to change the ownership predicates such that only the specified smart contract is capable of furhter transferring ownership.

To allow a smart contract to verify a proof from another partition, we take advantage of the Unicity Certificate framework to allow a common root of trust. The Unicity Certificate, generated by the Root Chain, provides for the creation of a proof of a token's state, and this proof can then be transported across shard boundaries, interpreted, and acted upon by smart contracts on different shards.

The first step is to transfer ownership of a token to a smart contract. This is done using predicates, where a user sends a transaction order to a token address assigning ownership to a smart contract. Once the new predicate has been registered in the token ledger, the data and proof can be sent to the smart contract address. As the smart contract and token share a common unicity framework, the smart contract can verify the correctness of the proof of the token transfer and execute its code accordingly. The smart contract then generates proofs which can be used by a new owner to initiate settlement back on the original token shard.

Smart contract composability

Smart contracts are composable, in that multiple smart contracts on different shards can be chained together such that the output of one contract can be used as the input to the next contract.

Security Advantages of Separating Execution from Settlement​

The advantages of this approach to computation are parallelism and protection from "rugpulls" due to malicious or flawed smart contracts. Settlement (that is, change in ownership of tokens) does not happen within the smart contract. Only after the smart contract executes can the proofs be generated necessary to initiate settlement on the Token Partition. This makes it possible to introduce audit functions or checks post smart contract execution but prior to settlement.

This approach of predicates for single-unit programmability and smart contracts for multi-unit programmability combines the best of both worlds—there is no shared state amongst contracts and developers have the flexibility to use any development environment. Alphabill has its own EVM-based development environment, but any run time can be used including other blockchains, provided the environment has access to the Unicity Certificate generated by the Root Chain in order to verify the proofs it receives as inputs.