Aleo’s Record Model: Building a More Secure, Efficient Blockchain

At the core of Aleo’s technology lies a groundbreaking cryptographic protocol called ZEXE (Zero-Knowledge EXecution), introduced in 2018. ZEXE was built to bring stronger privacy and security to decentralized systems and was the first to introduce the record model. Unlike traditional models, the record model extends the UTXO (Unspent Transaction Output) model, enabling the storage and encryption of arbitrary data such as user assets and application states — going beyond simple token values.

The record model’s privacy-focused structure allows Aleo to shield critical data aspects like inputs (messages), outputs (state changes), users, and functions, with the sole exception of private functions. Initially, Aleo aimed for function privacy as well (as outlined in the original ZEXE paper), but found that it impacted performance and extended proving times. In this article, we explore how Aleo’s record model works to maintain privacy, how it compares to other state models, and why Aleo relies on it.

Comparing UTXO, Account, and Record Models

Blockchain networks typically use either the UTXO model, popularized by Bitcoin, or the account model introduced by Ethereum. Aleo, however, has adapted the UTXO model into the record model to better meet privacy and security goals.

In Ethereum’s account model, for example, each application’s state is linked to a specific address, making it easy for anyone to monitor account activities by simply tracking the address. Aleo’s record model, however, goes a step further by encrypting the application state and its owner’s information, enhancing privacy.

How the Record Model Works

In Aleo’s record model, application states and ownership details are encrypted and stored on the blockchain. A record serves as a fundamental data structure containing any arbitrary payload, encoding user assets or application states. These records make up the global state on-chain, such as a user’s credit balance represented by multiple records tied to their address.

An Aleo record is serialized in the following format:

{
  "owner": "aleo13ssze66adjjkt795z9u5wpq8h6kn0y2657726h4h3e3wfnez4vqsm3008q.private",
  "amount": "100u64.private",
  "_nonce": "5861592911433819692697358191094794940442348980903696700646555355124091569429group.public"
}

The owner field specifies the account authorized to spend the record, and the amount field carries the data payload, encoding relevant application information. Additionally, a serial number nonce acts as a unique identifier, generated by evaluating the address secret key and serial number.

For a practical demonstration of an Aleo record, visit Aleo’s developer documentation.

How the Record Model Updates State

In Aleo’s model, applications update state by consuming records with the old state and generating new records with the updated state. Once a record is consumed, it’s marked as spent and cannot be reused. This process occurs within a transition function. A single Aleo transaction can contain up to 32 transitions, with one designated for transaction fees.

Why Aleo Uses the Record Model

In the account model, like Ethereum’s, application data is stored persistently in a location tied to an account, with updates made directly to this stored data. For instance, a token transfer transaction reduces the balance of User A and increases that of User B in a table indexed by user account addresses.

When aiming for privacy in the account model, this approach becomes limiting. Although it’s possible to hide transaction values, user identities remain visible, as account addresses cannot be encrypted. Furthermore, achieving user privacy would require updating all account commitments in the table, which can become inefficient as the user base grows. Additionally, the account model lacks concurrency, limiting it to one user accessing and updating the program state at a time.

Aleo’s record model resolves these issues by using program IDs to uniquely identify applications rather than account addresses. This approach enhances privacy, supports internal program states, and enables concurrency, allowing multiple users to interact with the program state simultaneously.

The record model is ideal for Aleo’s goals of programmable privacy and scalability. By enhancing the UTXO model to encode arbitrary data, the record model introduces a level of programmable privacy not achievable in traditional account-based systems.

Ready to build on Aleo? Dive into our GitHub repository and check out our recently updated developer documentation to start creating on the Aleo network.