Aleo Blockchain Project: Achieving Privacy Protection and Scalability through zk-SNARKs Technology

Aleo is a privacy-focused Blockchain project that utilizes zk-SNARKs technology (ZKP) to enhance privacy and scalability. The core idea of Aleo is to enable users to authenticate their identity and process data without disclosing personal data.

This article introduces the project overview and latest developments of Aleo, and provides a detailed interpretation of the highly anticipated puzzle algorithm update in the market.

Introduction to the Latest Algorithms

The Aleo network randomly generates a ZK circuit every hour. Miners need to try different nonces as circuit inputs within that hour to compute the witness(, which includes all variables in the circuit. This process is also referred to as synthesize), where they compute the Merkle root of the witness and then check if it meets the mining difficulty requirements. Due to the randomness of the circuit, this mining algorithm is not GPU-friendly and presents significant challenges in computational acceleration.

Financing Situation

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

Project Overview

Privacy

The core of Aleo is zk-SNARKs( technology, which allows transactions and the execution of smart contracts to be carried out while protecting privacy. The 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. The main components include:

1. Leo programming language: Adapted from Rust language, specifically designed for developing zk-SNARKs applications )ZKApps(, reducing the requirements for developers' knowledge of cryptography.

2. snarkVM and snarkOS: snarkVM allows off-chain execution of computations, with only the verification of computation results on-chain, 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 that supports programming interactions between users, organizations, and DAOs.

Aleo also provides an integrated development environment )IDE( and a software development kit )SDK(, allowing developers to quickly write and publish applications. Developers can deploy applications in Aleo's program registry without relying on third parties, thereby reducing platform risk.

) Scalability

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

Consensus Mechanism

Aleo introduces AleoBFT, a consensus mechanism with a hybrid architecture that combines the instant 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. Block finality: AleoBFT ensures that each block is immediately confirmed after generation, enhancing node stability and user experience.

2. Decentralized Assurance: By separating block production from coinbase generation, validators are responsible for generating blocks, while provers perform proof calculations, preventing a few entities from monopolizing the network.

3. Incentive Mechanism: Validators and provers share Block rewards; encouraging provers to become validators by staking tokens, thereby enhancing the network's decentralization and computing power.

Aleo allows developers to create applications that are not subject to gas limits, making it particularly suitable for applications like machine learning that require long-running processes.

Current Progress

Aleo will launch its incentive testnet on July 1st, here are some important updates:

1. ARC-100 vote passed: ARC-100### "Best Compliance Practices for Aleo Developers and Operators" proposal, involving compliance aspects, locking of funds on the Aleo network, and security measures such as delayed crediting, has completed voting and has been approved. The team is making final adjustments.

2. Validator Incentive Program: This program will start on July 1st and aims to validate 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 the rewards, and each validator must earn at least 100 tokens to receive a reward. Specific details have yet to be finalized.

3. Initial Supply and Circulating Supply: The initial supply is 1.5 billion tokens, with an initial circulating supply of approximately 10%( yet to be finalized). These tokens primarily come from Coinbase tasks( 75 million), and will be distributed over the first six months, including rewards for staking, running validators, and validating nodes.

4. Testnet Beta Reset: This is the final 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 target to increase to 50 within the year, and eventually reach 500. Becoming a delegator requires 10,000 tokens, while becoming a validator requires 10 million tokens, and these amounts will gradually decrease over time.

Algorithm Update Interpretation

Recently, Aleo announced the latest news about its testnet while updating the latest version of the puzzle algorithm. The new algorithm no longer focuses on the generation of zk proof results, removing MSM and NTT(, which are computational modules heavily used in the generation of proofs in zk. Previously, testnet participants focused on optimizing the efficiency of this algorithm to enhance mining yields through the calculation of ), emphasizing the generation of intermediate data witnesses before producing proofs. Below is a brief introduction to the latest algorithm.

( Consensus Process

On the consensus protocol level, the prover and validator are responsible for generating the computation result solution and producing blocks and aggregating the solution, respectively. The process is as follows:

1. The Prover computes the puzzle, constructs solutions, and broadcasts them to the network.

2. Validator aggregates transactions and solutions for the next Block, ensuring the number of solutions does not exceed the consensus limit )MAX_SOLUTIONS###

3. The legality of the solution needs to verify that its epoch_hash matches the latest_epoch_hash maintained by the validator, that the calculated proof_target conforms to the latest_proof_target maintained by the validators in the network, and that the number of solutions included in the block is less than the consensus limit.

4. A valid solution can earn consensus rewards.

( Synthesis Puzzle

The latest version of the algorithm core is called Synthesis Puzzle, which is designed to generate a common EpochProgram fixed for each epoch. By constructing R1CS proof circuits for the input and the EpochProgram, it produces the corresponding R1CS assignment ), which is the witness ### mentioned by everyone, and serves as a leaf node 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 calculation is called a nonce, which is constructed from the address receiving the mining reward, 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 calculated.

2. In each epoch, the EpochProgram that all provers in the network need to compute is the same, and it is sampled from the instruction set using the random number generated by the current epoch_hash. The sampling logic is:

   • The instruction set is fixed, and each instruction (instruction) contains one or more computational operations, with each instruction having a preset weight and operation count.
   • When sampling, generate a random number based on the current epoch_hash, obtain instructions from the instruction set combined with weights according to that random number and arrange them in order, and stop sampling after accumulating the operation count to 97.
   • Assemble all instructions into EpochProgram

3. Use nonce as a random seed to generate the input for EpochProgram.

4. Aggregate the R1CS and input corresponding to the EpochProgram, and perform the witness( R1CS assignment) calculation.

5. After calculating all the witnesses, these witnesses will be converted into the corresponding sequence of leaf nodes of the merkle tree. The merkle tree is an 8-depth 8-ary Merkle tree.

6. Calculate the merkle root and convert it to the solution's proof_target, determine if it meets the current epoch's latest_proof_target. If it does, the calculation is successful. Submit the reward address, epoch_hash, and counter needed to construct the input as the solution and broadcast it.

7. The input of EpochProgram can be updated multiple times for solution calculations within the same epoch by iterating the counter.

Changes and Impacts of Mining

After this update, puzzle has shifted from generating proof to generating witness. The calculation logic for all solutions within each epoch is consistent, but there are significant differences in the calculation logic between different epochs.

From the previous testnet, we can see that many optimization methods focused on using GPUs to optimize the MSM and NTT calculations in the proof generation phase, thereby improving mining efficiency. This update completely abandons this part of the computation; at the same time, since the process of generating the witness occurs during the execution of a program that follows epoch changes, there will be some serial execution dependencies among the instructions, so achieving parallelization presents considerable challenges.