AleoVM Specification

Aleo is a decentralized platform enabling private computations over encrypted data using zero-knowledge proofs, introducing novel techniques to improve efficiency by maintaining data privacy while forgoing function privacy.

This innovation allows for scalable, privacy-preserving decentralized applications by enhancing computational efficiency and reducing overhead, directly impacting users and developers who require both privacy and performance in blockchain environments.

Aleo introduces a Decentralized Private Computation (DPC) scheme that strategically relaxes function privacy to eliminate the need for recursive zero-knowledge proofs, significantly enhancing performance. By introducing state transitions within transactions, Aleo supports complex function compositions in a single transaction, reducing network overhead. It utilizes universal and updatable Structured Reference Strings (SRS) to allow deterministic derivation of circuit-specific keys, simplifying deployment and enhancing scalability. Aleo also introduces a finalize scope to enable on-chain execution within a privacy-preserving context.

Aleo addresses the limitations of existing ledger-based private computation systems, such as Zexe, by relaxing the requirement of function privacy. This relaxation allows Aleo to eliminate recursive proof constructions, which are computationally intensive due to the need for cycles of pairing-friendly elliptic curves in recursive SNARKs. By making the function identities publicly visible but keeping the input and output data private, Aleo significantly reduces the computational overhead associated with proof generation and verification.

Aleo introduces state transitions within transactions, enabling multiple function executions within a single transaction and supporting complex computations and function compositions. This reduces network traffic and improves efficiency. The use of universal SNARKs with an updatable SRS allows for deterministic derivation of circuit-specific keys without additional trusted setups. The finalize scope feature provides a mechanism for on-chain execution, enabling functions to interact with globally persistent ledger states while maintaining data privacy.

Decentralized Private Computation (DPC) Schemes: DPC schemes are cryptographic protocols that allow users to perform computations on encrypted data and produce succinct, publicly verifiable proofs attesting to the correctness of these computations without revealing the underlying data. They are essential for enabling privacy-preserving smart contracts and decentralized applications on blockchain platforms.

In traditional DPC schemes like Zexe, both data privacy and function privacy are maintained, meaning that neither the inputs and outputs of the computation nor the function being executed are revealed. However, this comes with significant computational overhead due to the need for recursive SNARKs to hide the function logic.

A DPC scheme is a tuple of algorithms:

• Setup: Generates the necessary public parameters and keys for the system.
• Execute: Allows a user to compute a function over private inputs and produce a proof of correctness.
• Verify: Enables any party to verify the proof without learning anything about the private inputs or outputs.

Detailed Workflow

1. Setup Phase:

• Parameter Generation: A trusted or semi-trusted setup procedure generates the common reference string (CRS) or structured reference string (SRS) required for the zero-knowledge proofs. In some systems, a universal and updatable SRS is used to enhance security and flexibility.

1. Record Creation: Users create records by committing to their private data using cryptographic commitments and associating them with their public keys. Each record has a unique serial number derived from a secret key and a nonce, ensuring uniqueness and unlinkability.
2. Computation Execution: Users perform computations locally on their private inputs, possibly consuming existing records and producing new ones. The computations correspond to functions within an allowed class.
3. Proof Generation: Users generate a zero-knowledge proof  that attests to the correctness of the computation. The proof demonstrates that the new records are correctly derived from the consumed records according to the function  f , without revealing the private inputs.
4. Transaction Formation: The proof, along with the commitments to the new records and serial numbers of the consumed records, is packaged into a transaction. The transaction may also include public inputs or metadata as required.
5. Transaction Submission and Verification: Transactions are submitted to the network for inclusion in the ledger. Network nodes (validators) verify the zero-knowledge proofs and check for protocol compliance (e.g., no double-spending, correct record consumption).
6. Ledger Update: Validated transactions are appended to the ledger. The global state is updated to reflect the creation of new records and the consumption of old ones.

Aleo’s Innovations in DPC Schemes:

Aleo builds upon the foundational work of Zexe and addresses its limitations through several key innovations:

1. Relaxation of Function Privacy:

Rationale: By making the identity of the function public, Aleo eliminates the need for recursive proofs, significantly improving performance.

Benefits: Performance Gains: Reduces computational complexity in proof generation and verification.

Simpler Cryptographic Requirements: Avoids the need for complex elliptic curve chains.

1. Modified Records Nano-Kernel (RNK): Simplification: Removes birth and death predicates from records, as function identities are public and can be directly verified.

Record Structure:

Records contain: Visibility mode, program ID, owner’s address, data payload, nonce, and randomness.

Serial Numbers and Commitments: Generated using standard cryptographic primitives without embedded predicates.

1. State Transitions within Transactions:

Flexible Transaction Structure: Allows variable numbers of inputs and outputs, enabling complex computations within a single transaction.

Proof Batching: Facilitates batching of proofs within a transaction, improving verification efficiency.

1. Deterministic Circuit Key Generation:

Universal SNARKs: Utilizes universal and updatable SRS to derive circuit-specific proving and verification keys deterministically.

Public Availability: Circuit keys can be made public since function privacy is relaxed, simplifying key management.

1. Finalize Scope for On-Chain Execution:

Hybrid Model: Introduces a finalize scope within program functions, allowing certain outputs to be public and interact with on-chain state.

Use Cases: Supports applications requiring both private computations and public state updates (e.g., decentralized exchanges).

Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs): zk-SNARKs are cryptographic proof systems that allow a prover to convince a verifier that a statement is true (e.g., a computation was performed correctly) without revealing any additional information beyond the validity of the statement. They are succinct, meaning the proofs are very small (e.g., a few hundred bytes), and verification is efficient.

In the context of DPC schemes, zk-SNARKs are used to prove the correctness of computations over encrypted data. Recursive zk-SNARKs allow for proofs of proofs, enabling complex computations to be verified succinctly. However, recursive proofs are computationally expensive, especially when cycles of pairing-friendly elliptic curves are required.

Universal and Updatable Structured Reference Strings (SRS): A Structured Reference String (SRS) is a set of public parameters required for certain zk-SNARK constructions. A universal SRS can be used for any computation up to a certain size, and an updatable SRS allows participants to contribute to the randomness of the SRS in a way that if at least one participant is honest, the entire SRS remains secure.

In Aleo, the use of a universal and updatable SRS allows for the deterministic derivation of circuit-specific proving and verification keys from the universal parameters, removing the need for per-circuit trusted setups or multi-party computation ceremonies. This enhances scalability and ease of deployment for new applications.

Function Privacy vs. Data Privacy: Function privacy ensures that the function being executed remains hidden, while data privacy ensures that the inputs and outputs of the computation are kept confidential. Maintaining function privacy requires additional cryptographic mechanisms, such as recursive zk-SNARKs, which introduce significant computational overhead.

Aleo strategically forgoes function privacy to eliminate this overhead, allowing the function identities to be publicly visible while keeping the data private. This trade-off significantly improves performance and makes the system more practical for real-world applications that can tolerate the exposure of function identities.

Recursive SNARKs and Pairing-Friendly Elliptic Curves: Recursive SNARKs require special elliptic curve cycles where one curve’s scalar field matches another curve’s base field. Constructing such cycles (e.g., a 2-chain of elliptic curves) is complex and results in less efficient curves (e.g., Cocks-Pinch curves), leading to higher computational costs for proof generation and verification.

By eliminating the need for recursive proofs, Aleo avoids these inefficiencies, enabling the use of more efficient elliptic curves and simplifying the cryptographic construction.

State Transitions and Transactions: In traditional blockchain systems, each transaction corresponds to a state change. In Zexe, complex computations might require multiple transactions due to limitations on the number of inputs and outputs per transaction, increasing network overhead.

Aleo introduces state transitions within transactions, allowing multiple function executions (state transitions) to be included within a single transaction. This supports complex function compositions and reduces the number of transactions required for multi-step computations, enhancing efficiency and reducing network load.

Finalize Scope for On-Chain Execution: Aleo introduces a finalize scope within program functions to enable on-chain execution, allowing functions to interact with globally persistent ledger states. This is crucial for applications that require certain data to be publicly visible or need to maintain global state, such as decentralized exchanges or token contracts.

The finalize scope operates by executing finalize commands that can update global mappings on the ledger, similar to state variables in smart contracts. This feature provides flexibility for developers to balance privacy and functionality according to the needs of their applications.

Howard Wu: Co-founder and Chief Scientist at Aleo, specializing in zero-knowledge proofs and decentralized systems.

Michael Beller: Co-founder and CEO of Aleo, focusing on bringing privacy-preserving technologies to mainstream blockchain applications.

1. How does the exposure of function identities impact the security model, and what are the potential risks in scenarios when function logic needs to remain confidential? ZKLim: To access the risks we have to first look at the needs. The use cases of function privacy are trade secrets and proprietary algorithms such as AI models trained for highly sensitive use cases like military strategy. Without function privacy the adversaries can anticipate and counter the strategies derived from the AI models.
2. What are the measurable improvements in proof generation and verification times compared to systems that retain function privacy, and how does this impact overall network performance? ZKLim: To put it in a simpler way, less works need to be done to hide function identities which is proofs recursion in this case hence better performance.

1. https://developer.aleo.org/specs/aleovm.pdf
2. https://ieeexplore.ieee.org/document/9152634I think the focus should be more on DPC compared to function privacy because that is the core idea of Aleo while function privacy is just a part that is important in ZEXE but Aleo choose to forgo it for better performance_Marked as resolved__Re-opened_how is this @zklimLooks better! But please remove the team information, the company management roles have changedMight need some help to understand this lol. Seems quite criticalFunction privacy means hiding even the function itself, to do that in an efficient way as it's being described in ZEXE paper, requires recursion to prove the proofs generated from both birth and death predicates that are used in preventing malicious function in a hiding setting.does this have to be assessed by the devs?To access the risks we have to first look at the needs. The use cases of function privacy are trade secrets and proprietary algorithms such as AI models trained for highly sensitive use cases like military strategy. Without function privacy the adversaries can anticipate and counter the strategies derived from the AI models.chatgpt gave this answer: 

Aleo’s elimination of recursive proofs leads to significant reductions in computational overhead. Without recursive SNARKs, proof generation times decrease due to simpler circuits and more efficient elliptic curves. Verification times are also reduced, enabling higher transaction throughput. Empirical benchmarks would be necessary to quantify these improvements precisely.To put it in a simpler way, less works need to be done to hide function identities which is proofs recursion in this case hence better performance.