Introduction

Aleo Systems has created a Layer 1 blockchain named Aleo, focusing on privacy achieved through the use of zero-knowledge proofs (ZKPs) and other cryptographic methods. Unlike most popular blockchains, where data used and created by transactions can be viewed by an external observer, Aleo provides the ability to hide such information.

One of the main privacy concerns with blockchain usage is that, although users are anonymized through their addresses, there are many cases where they can still be tracked and identified via their public transaction history. Another issue is that traditional institutions may find it challenging to participate in the Web3 world due to compliance requirements, such as ensuring the privacy of their customers’ data.

What Aleo provides is a solution to the above issues. Function inputs and outputs can be hidden through encryption and privately disclosed to necessary parties at any time. ZKPs are used to ensure the correctness of computation while alleviating the computational bottleneck experienced by other blockchains. These innovations bring in new considerations for smart contract design while also expanding on what is already available.

Blockchain Aspects

Aleo accomplishes privacy through the implementation of ZKPs. To illustrate this, consider how a transaction is executed in a typical blockchain:

1. A user submits a transaction to a node. This transaction propagates to several validator nodes and is stored in their mempool.
2. Each validator node executes the transaction using its copy of the virtual machine and computes state changes as well as transaction outputs.
3. The nodes update their storage due to changes caused by the transaction and notify other nodes, resulting in an update to the overall blockchain ledger.

The reason why privacy is difficult to achieve in current blockchains is due to the second step. Executing the transaction requires information from the user, such as their address and signature for verification checks, and inputs to functions to determine what to compute.

Since a user must provide the above information to unknown nodes for the blockchain ecosystem to function, it is not possible to hide transaction details from everyone.

Now, consider how Aleo executes transactions:

1. A user executes their transaction locally off-chain. This creates a zero-knowledge proof attesting to the correctness of the computation.
2. This proof is then given to validator nodes for verification.
3. Once verified, the blockchain ledger is updated.

The main difference between Aleo and a traditional blockchain is where computation occurs. Current blockchains require validator nodes to compute transactions, whereas in Aleo, the computation can be done by anyone, such as the users themselves. This allows users to hide transaction details that would typically be public, such as inputs to functions.

It is important to note that, as the Aleo ecosystem has matured, users are not always required to perform the computationally intensive proof generation on their own local machines. A dedicated Prover Market has emerged, where users can outsource the task of proof generation to specialized third-party provers. This 'Proof-as-a-Service' (PaaS) model significantly lowers the barrier to entry for using private applications, as users only need to sign the final transaction with their private key before submission.

Aleo requires a fee for sending transactions. This fee deduction can be public or private, allowing the transaction sender to hide themselves from an external observer.

As an example, when an external observer queries transactions on the Aleo blockchain, they may see something like the following:

Some inputs to a function call can be public, allowing the observer to understand exactly what the input was. However, other inputs may be private, which are encrypted ciphertexts that prevent the observer from seeing the corresponding plaintext inputs. Note that, along with function inputs, function outputs can also be made public or private.

These encrypted values can be decrypted by the transaction sender, allowing them to prove to a third party the exact nature of their transaction, which may be necessary during an audit or for regulatory purposes.

Aside from privacy, an additional benefit of Aleo’s design is its ability to change the location of the computational bottleneck. In many current blockchains, executing transactions is done by validator nodes, which can strain resources during resource-intensive transactions. To prevent this situation and denial-of-service (DoS) attacks, there is usually a hard limit on how many resources a transaction can use. In addition, the transaction sender often has to pay for the computational resources used, which serves as a deterrent for computationally-heavy functions.

However, in Aleo, since the execution of a transaction is done off-chain, the transaction sender is able to use their own resources to execute their transaction. At the same time, the time it takes to ZKP remains close to constant. This allows Aleo to offload the computational bottleneck onto its users, opening the door for much more sophisticated programs, such as machine learning (ML) algorithms.

Smart Contract Languages

Programs in the Aleo blockchain are written in Leo, a Rust-based language. They can also be written directly using the Aleo Instructions, an assembly version of Leo. The language is now quite mature, offering full support for advanced data types like arrays, structs, and tuples. While it employs specific programming patterns to handle dynamic datasets, its capabilities are robust enough to build sophisticated applications.

1. Program Name: The name of each program on the Aleo blockchain has to be unique. This means that, if someone deployed a program named “UniswapV2”, then no one else can deploy a program named “UniswapV2”. This also means that, when a program makes an external call to another program, it refers to the other program by name instead of using an address.

It appears that the program’s address is dependent on the program’s name. The underlying reason for this behavior is that a program's unique address is generated from the cryptographic hash of its entire codebase—including its name, imports, records, functions, and more. Therefore, any change to the code, even renaming the program, alters the hash and results in a new, unique Program address.

For example, in internal testing, our program named hello.aleo had a corresponding address of aleo1l3n0pkstha9j943fdcvldnah779mn3n57q98awysgna0wvwluyqqd6ec9y. When the program’s name was changed to bye.aleo, the program’s address changed to aleo1k74whgd7jwe4f0qdrjhr8hascmae2hnnyk8rfx3eess455rq4c8s9lyw46.

2. Storage: Aleo features a dual-track state model with two primary storage types:

• Mappings (Public Storage): As the original text notes, mappings are used for on-chain public storage, where both keys and values are visible to everyone. They are suitable for storing global program state or public registries.

• Records (Private Storage): We will introduce it later.

3. Randomness: There is a built-in method ChaCha::rand_{TYPE} that generates a random value of type TYPE. This is interesting, as traditional blockchains are deterministic, meaning that randomness is not realistic on-chain. Sources of randomness generally had to come from an off-chain or manipulatable source.

4. Transition and Finalize Functions: There are a number of function types in Leo, but two notable ones are transition and finalize functions. Transition functions serve as entry points into a program, callable by transactions. Finalize functions are functions whose execution is done on-chain by validator nodes. In particular, this means that their computation is separate from the zero-knowledge proof created by a transaction and that its inputs are always public. Some purposes of finalize functions are to update mappings in the program as well as to be able to use the ChaCha::rand_{TYPE} method.

5. Variable Visibility: Transition function inputs and outputs have, by default, private visibility. This causes them to appear as encrypted ciphertexts when viewed inside a transaction. If declared public in the program, the values will appear as plaintext in the transaction.

6. Records: To facilitate private data, Aleo has a special data type called record. A record has two essential components: the owner and a nonce. The owner of a record is the only one able to use the record, while the nonce serves as a unique identifier. Various information can be stored inside a record, such as privately minted tokens that would not appear on-chain. The record itself is generally encrypted. Note that the data in a record cannot be changed: when a record is used as an input to a function, it is consumed.

Security Considerations

In the cybersecurity CIA (confidentiality, integrity, availability) triad, auditing smart contracts generally deals with integrity and availability. Confidentiality has rarely been a concern due to the public nature and transparency of blockchains. The most considered is possible private key exposure, which is outside the scope of audits. However, with Aleo, confidentiality becomes an additional layer of smart contract security.

When specific data in a program is meant to be private, there now needs to be consideration of whether the data can be leaked. One notable pattern of how this can occur is if there is a private input and a public output that depends on said input. If the operations to produce the output are reversible or if the output has specific, unique properties depending on the input, then information about the input can be leaked.

An example of the above, unique to Aleo, is when a private input is used in a finalize function. Consider a program with the following:

Note that the amount in the transition function set_balance() is a private variable. In Aleo code, the above is equivalent to:

Notice that all input variables in the finalize function set_balance() are now public. This means that the initial input amount will appear as an encrypted ciphertext but will be in plaintext when used in the finalize function set_balance(). This is indeed what occurs when executing set_balance():

In the above example, the input to the transition function set_balance() is a ciphertext, but we are able to see its plaintext form as 100u64 in the output.

Guarding against information leakage can significantly affect established standards. For example, the ERC20 token standard states that there should be a public method totalSupply() that returns the total number of tokens. This is important for tokenomics as well as in smart contracts like the ERC4626 Tokenized Vault Standard.

Suppose we wish to have a token program on Aleo akin to the ERC20 standard. To take advantage of the private features in Aleo, the program allows the minting and transfer of private tokens, as well as the conversion of public tokens into private tokens. Consider the following design problem: should private tokens be included in the total supply?

If private tokens are included in the total supply, there is a possibility of information leakage by querying the total supply before a private mint and then afterward. This allows one to deduce the number of private tokens minted.

On the other hand, if private tokens are not included in the total supply, then the same idea above can be applied to public-to-private token exchanges to deduce the number of tokens exchanged. Another issue this causes is that, since the total supply of a token affects tokenomics, an unknown supply of private tokens brings financial risk. For example, what if the owner of a token privately minted themselves a large amount of tokens to be dumped if the token price passes a threshold? Such a situation would be challenging to verify before the dump.

Privacy also helps in dealing with established blockchain attacks, such as front-running and sandwich attacks. As inputs to functions and their effects can be unknown to an external observer, it would not be possible to front-run or back-run certain transactions.

Conclusion

The Aleo blockchain adds privacy as another layer to smart contract design, while also opening up the possibility for more complex programs that require greater computational power. This is another example of zero-knowledge proofs pushing the limits of the Web3 world, actively driving privacy to become a standard feature in blockchain.

References

• Aleo Developer Documentation. https://developer.aleo.org/
• The Leo Language Documentation. https://docs.leo-lang.org/
• The Official Aleo Blog. https://aleo.org/blog/
• Awesome Aleo. https://github.com/howardwu/awesome-aleo