Skip to main content

Partitions and Transaction Framework

The use of partitioning allows Alphabill to differentiate the transaction validation rules, to optimize for specific use cases across a wide array of possible partition types. Each partition must implement a transaction system, which have:

  • units u, each unit having a unique identifier, owner predicate and unit data,
  • transactions that delete units, create new units, or change the data of the units.

The Alphabill transaction framework defines a language for describing the functionality of transaction systems: state and transactions (syntax and semantics) as well as provides libraries and toolkits for developing transaction systems. The framework, based on descriptions of transaction systems, registers and assigns identifiers to transaction systems, provides the unicity certificate service for the registered transaction systems: unique root hash h and summary value V for every pair (n;  ), where n is the block number.

Some of the elective features available to developers are listed below.

Censorship Resistance and Fair Ordering

Transactions are encrypted at the client side using per-epoch, per partition public key, and then delivered to partition validators, who order transactions in blind and commit to this ordering. Before validation and execution, each partition validator threshold-decrypts transactions and then they exchange their decryption shares. After combining enough shares, it is possible to obtain transactions in clear and continue as usual. Fee payment is handled by the "double envelope" method.

Alphabill rotates the block proposer role at every round, thus, even without encryption, transactions may be only delayed until accepted by an honest validator.

Private Transactions

In so-called "dark partitions", transactions are accompanied with zero knowledge proof of correctness: input unit is valid, transfer authorized by the owner, other transaction rules satisfied. Validators see opaque transactions orders only, without revealing unit data and transaction counterparties.

ZK Validity Guarantee

The data model of Alphabill allows some partitions to use zero knowledge (ZK) proofs to prove the validity of transaction execution to the Root Chain. This extends the shared security umbrella of Root Chain from safety property to the validity property. Partitioning allows the use of specific ZK friendly cryptographic algorithms in this partition, and to place limits to the complexity of owner predicates, greatly increasing the efficiency (proving speed) of such partitions.

KYC and AML

Know Your Customer (KYC) and Anti-Money Laundering (AML) rules are implemented at the client interface (wallet, crypto exchange) level, while the successful enforcement is checked by partition's ledger rules, whenever required by use-case specific compliance environments.