Transaction Units

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 are introduced, such as rollups or federated consensus instances, resulting in compromises in security, performance, settlement finality, etc.

Every transaction with UTXOs and accounts involves at least two transaction units.

If the accounts or UTXOs are on different machines, then coordination is needed between the machines 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.

Bill-based money schemes can execute transactions in parallel.

In a bill-based money scheme, such as physical cash, the only thing that changes during a transaction 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.

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-counterfeit). A design goal of Alphabill is to replicate these properties using public blockchain.

Potential limitations of bill schemes are a) atomicity—how to ensure multiple bill transactions are atomic, that is, there is not a situation where only a subset of bills is 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 Alphabill State Tree, we will introduce data structures that allow for atomic precise payments within a single block through state tree splits. This can be achieved in a way that does not break the native parallelism of the bill model.