Aleo’s Record Model: Building a more secure, efficient blockchain

At the heart of Aleo lies a revolutionary cryptographic protocol known as ZEXE, or Zero-Knowledge EXecution, which was first introduced in 2018. ZEXE was designed to enhance privacy and security in decentralized systems and was the first to introduce the record model. This model extends the UTXO model from Zcash and enables storing and encrypting arbitrary data such as user assets and application states, rather than just values of specific assets or tokens.

ZEXE specifically focuses on the privacy of inputs (such as messages), outputs (such as state changes), users, and functions. Aleo fulfills all of them except for private functions. Initially, Aleo was aiming for function privacy as well (as detailed in the original ZEXE paper), but decided against it as it would have led to worse performance and longer proving times.

In this article, we’ll discuss how Aleo’s record model works to preserve privacy, compare it to other types of state models, and explain why Aleo uses it.

Comparing UTXO, account model, and record model

There are two main state models used in blockchains - UTXO (unspent transaction output) and the account model (introduced by Ethereum). Aleo uses a variation of the UTXO model - the record model.

In the account model as used in Ethereum, the application state can be found by referencing a particular address. As such, anyone would be able to view the activities of any account, simply with the knowledge of the address.

How does the record model work?

In the record model, the application state, along with its owner are encrypted and stored on the blockchain. Records are a fundamental data structure that can contain any arbitrary payload and are used for encoding user assets or application states. Records represent a fragment of the global state kept on chain. For example, the balance of your credits in a given account is composed by the multiple credit records that have your address as the owner.

An Aleo record is serialized in the following format:

Here's an example record:

{

  owner: aleo13ssze66adjjkt795z9u5wpq8h6kn0y2657726h4h3e3wfnez4vqsm3008q.private,

  amount: 100u64.private,

  _nonce: 5861592911433819692697358191094794940442348980903696700646555355124091569429group.public

}

Owner aleo13ssze66adjjkt795z9u5wpq8h6kn0y2657726h4h3e3wfnez4vqsm3008q

The record owner is an account address, and specifies the party who is authorized to spend the record. The record can encode arbitrary application information and the "amount" key is the data payload that the record carries. The serial number nonce is used to create a unique identifier for each record, and is computed via a PRF evaluation of the address secret key ask of the owner and the record's serial number.

For a practical demonstration of a record in Aleo, see here.

How the record model updates state

In the record model, applications update their state by consuming records containing the old state, and producing new records that contain the updated state. Records that have been used will be marked as spent and cannot be used again.

The consumption and production of records is typically done in a transition function. A transaction in Aleo can contain up to 32 transitions, one of which is reserved for the transaction fee.

Why does Aleo use the record model?

In the account-based model, an application's data is stored in a persistent location tied to the application's account, and updates are made directly to this stored data. For a typical token transfer transaction using this model, user balances would be stored in a table mapping user account addresses to their respective balances. When User A transfers money to User B, A's balance in the table is reduced, and B's balance is increased by the same amount.

If we were to try making the transactions private (hiding the amount transferred and the identities of A and B), instead of storing actual balances, the application can store commitments to these balances. Transactions would then update these commitments rather than the actual balances. However, while this approach hides transaction values, it does not hide user identities. To also hide user identities, every transaction would need to update all commitments in the table, which becomes increasingly inefficient as the number of users grows.

Although the account model is more intuitive for developers, it uses account addresses to index global state. This means that while a private account model can achieve privacy for inputs and outputs, it still compromises user privacy since account addresses cannot be encrypted. Another issue with the private account model is the lack of concurrency, as only one user can access and update the entire program state at a time.

Aleo's record model uses program IDs to uniquely identify programs instead of account addresses. This improves privacy and enables programs to have internal states. This approach is more efficient and solves the concurrency issue.

The record model is ideal for Aleo due to its emphasis on programmable privacy and scalability, which the account-based model lacks. The record model enhances the UTXO model used in Bitcoin by enabling the encoding of arbitrary data, which provides programmable privacy.

Get started building on Aleo today by visiting our GitHub and viewing our recently updated developer documentation.