Aleo is a blockchain project focused on privacy protection, achieving higher privacy and scalability through zero-knowledge proof technology (ZKP). The core idea of Aleo is to enable users to authenticate and process data without disclosing personal information.
This article mainly introduces the project overview and latest developments of Aleo, with a detailed interpretation of the puzzle algorithm update that is of great concern to the market.

Latest Algorithm Preview ;) TLDR

The Aleo network randomly generates a ZK circuit every hour; miners need to try different nonces as inputs to the circuit within that hour, calculate the witness (i.e., all variables in the circuit, a process also called synthesis), and then determine if the Merkle root of the witness meets the mining difficulty requirements. Due to the randomness of the circuit, this mining algorithm is not friendly to GPUs, posing significant challenges in computational acceleration.

Funding Background

Aleo completed a $28 million Series A funding round led by a16z in 2021, and in 2024, it completed a $200 million Series B funding round, with investors including Kora Management, SoftBank Vision Fund 2, Tiger Global, Sea Capital, Slow Ventures, and Samsung Next. This round of financing brought Aleo's valuation to $1.45 billion.

Project Overview

Privacy

At the core of Aleo is zero-knowledge proof (ZKPs) technology, which allows transactions and smart contract execution to be conducted while maintaining privacy. Details of users' transactions, such as the sender and transaction amount, are hidden by default. This design not only protects user privacy but also allows for selective disclosure when necessary, making it very suitable for the development of DeFi applications. Its main components include:

1. Leo programming language: Adapted from Rust, specifically designed for developing zero-knowledge applications (ZKApps), reducing the cryptographic knowledge required from developers.
2. snarkVM and snarkOS: snarkVM allows off-chain execution of computations, with only the verification of results uploaded to the blockchain, thus improving efficiency. snarkOS ensures the security of data and computations and allows permissionless functionality execution.
3. zkCloud: Provides a secure and private off-chain computing environment, supporting programming interactions between users, organizations, and DAOs.
   Aleo also offers an integrated development environment (IDE) and software development kit (SDK) to support developers in quickly writing and deploying applications; additionally, developers can deploy applications in Aleo's program registry without relying on third parties, thus reducing platform risk.

Scalability

Aleo adopts an off-chain processing approach, where transactions are first computed on the user's device, and only the verification results are uploaded to the blockchain. This greatly improves transaction processing speed and system scalability, avoiding network congestion and high fees similar to Ethereum.

Consensus Mechanism

Aleo introduces AleoBFT, a hybrid architecture consensus mechanism that combines the immediate finality of validators with the computational power of provers. AleoBFT not only enhances the decentralization of the network but also improves performance and security.

1. Fast block finality: AleoBFT ensures that each block is immediately confirmed after generation, enhancing node stability and user experience.
2. Decentralization assurance: By separating block production from coinbase generation, validators are responsible for generating blocks, while provers perform proof computations, preventing a few entities from monopolizing the network.
3. Incentive mechanism: Validators and provers share block rewards; provers are encouraged to stake tokens to become validators, thereby enhancing the network's decentralization and computational capacity.
   Aleo allows developers to create applications without gas limits, making it particularly suitable for long-running applications such as machine learning.

Current Progress

Aleo will launch an incentivized testnet on July 1st, and here are some important updates:

1. ARC-100 Voting Passed: The voting for ARC-100 ("Best Compliance Practices for Aleo Developers and Operators," involving compliance aspects, fund locking on the Aleo network, and delayed deposits) has concluded and passed. The team is making final adjustments.
2. Validator Incentive Program: This program will start on July 1st, aimed at validating the new puzzle mechanism. The program will run until July 15th, during which 1 million Aleo points will be allocated as rewards. The percentage of points generated by nodes will determine their share of rewards, with each validator needing to earn at least 100 tokens to qualify for rewards. Specific details are yet to be finalized.
3. Initial Supply and Circulating Supply: The initial supply is 1.5 billion tokens, with an initial circulating supply of about 10% (not yet finalized). These tokens mainly come from Coinbase tasks (75 million) and will be distributed over the first six months, including rewards for staking, running validators, and verifying nodes.
4. Testnet Beta Reset: This is the last network reset, and no new features will be added after completion; the network will be similar to the mainnet. The reset is to add ARC-41 and new puzzle features.
5. Code Freeze: The code freeze was completed a week ago.
6. Validator Node Expansion Plan: The initial number of validator nodes is 15, with a goal to increase to 50 by the end of the year and eventually reach 500. Becoming a delegator requires 10,000 tokens, while becoming a validator requires 10 million tokens; these amounts will gradually decrease over time.

Algorithm Update Interpretation

Recently, Aleo announced the latest testnet news and updated the latest version of the puzzle algorithm. The new algorithm no longer focuses on generating zk proof results, removing the computations of MSM and NTT (both of which are heavily used in zk proof generation, and previous testnet participants optimized these algorithms to enhance mining rewards), and instead focuses on generating the intermediate data witness before producing the proof. After referencing the official puzzle spec and code, we provide a brief introduction to the latest algorithm.

Consensus Process

At the consensus protocol level, the process involves the prover and validator being responsible for generating the computational result solution and producing and aggregating the packaged solution respectively. The process is as follows:

1. Prover computes the puzzle to construct solutions and broadcasts them to the network.
2. Validator aggregates transactions and solutions into the next new block, ensuring that the number of solutions does not exceed the consensus limit (MAX_SOLUTIONS).
3. The validity of the solution needs to be verified against the epochhash maintained by the validator's latestepochhash, and the calculated prooftarget must match the latestprooftarget maintained by validators in the network, while the number of solutions included in the block must be less than the consensus limit.
4. Valid solutions can receive consensus rewards.

Synthesis Puzzle

The core of the latest algorithm is called Synthesis Puzzle, which generates a common EpochProgram fixed for each epoch. By constructing an R1CS proof circuit for the input and EpochProgram, it produces the corresponding R1CS assignment (i.e., the witness mentioned by everyone) and serves as the leaf nodes of the Merkle tree. After calculating all leaf nodes, the Merkle root is generated and converted into the proof_target of the solution. The detailed process and specifications for constructing the Synthesis Puzzle are as follows:

1. Each puzzle computation is called a nonce, constructed from the address receiving mining rewards, epoch_hash, and a random number counter. A new nonce can be obtained by updating the counter each time a new solution needs to be computed.
2. In each epoch, all provers in the network need to compute the same EpochProgram, which is sampled from the instruction set using a random number generated from the current epoch_hash. The sampling logic is:
3. The instruction set is fixed, with each instruction containing one or more computational operations, each having a preset weight and operation count.
4. During sampling, a random number is generated based on the current epoch_hash, and instructions are obtained from the instruction set based on this random number combined with weights, arranged in order, stopping sampling after accumulating the operation count to 97.
5. All instructions are combined to form the EpochProgram.
6. Use the nonce as a random seed to generate the input for the EpochProgram.
7. Aggregate the corresponding R1CS and input of the EpochProgram to perform witness (R1CS assignment) computation.
8. After calculating all witnesses, these witnesses will be converted into the corresponding sequence of leaf nodes of the Merkle tree, which is an 8-depth 8-ary Merkle tree.
9. Calculate the Merkle root and convert it into the prooftarget of the solution, checking if it meets the current epoch's latestprooftarget. If it does, the calculation is successful, and the reward address, epochhash, and counter needed to construct the input are submitted as the solution and broadcasted.
10. Within the same epoch, multiple solution calculations can be performed by iterating the counter to update the input of the EpochProgram.

Changes and Impacts on Mining

After this update, the puzzle has shifted from generating proofs to generating witnesses. The computation logic for all solutions within each epoch is consistent, but there are significant differences in the computation logic between different epochs.
From previous testnets, we can see that many optimization methods focused on using GPUs to optimize the MSM and NTT computations during the proof generation phase to improve mining efficiency; this update completely discards that part of the computation. Additionally, since the process of generating witnesses arises from executing a program that follows epoch changes, there will be some serial execution dependencies among the instructions, making parallelization quite challenging.