1.1 Aleo Fundamentals

Aleo is about building a ledger with permissionless private programmability, which really just means you can execute arbitrary programs on the blockchain without asking for permission and include private data.

Aleo includes two key pieces to achieve this: SnarkVM and SnarkOS.

SnarkVM is where the magic happens. It's Aleo’s virtual machine, letting you run programs and generate zero-knowledge proofs off-chain of the execution of those programs on some inputs. Think of it as a private execution sandbox: you do all your computations here, produce a proof that you did them correctly, and then share just that proof instead of all the details. That’s how Aleo keeps things private while still making sure everything checks out.

SnarkOS is what keeps the network running. It’s the blockchain node software that powers Aleo’s consensus mechanism, called AleoBFT. This ensures that all network participants agree on the state of the chain securely and efficiently. Once a program has been executed offchain by a user, its proof is shared to the network and verified by peers running SnarkOS (that calls SnarkVM proof verification under the hood).

Put these two together, and you’ve got a system where private transactions and smart contracts execute freely, without central oversight.

From Programs to ZKPs

So, how do we take a regular program, some inputs and turn it into a ZK proof of the correct execution? Here’s how it works, from 5000kms:

• First, we write some code that represents the statement we want to prove. For example, proving someone is over 18 without revealing their actual age. The code takes an input, runs a check, and gives a true or false result.

• The program is transformed into a polynomial represented as its linear factors and the quotient polynomial, following a procedure not explained in detail here but in the vein of:

  • The program gets broken down into basic logic gates (AND, OR, etc.).

  • Each logic gate becomes a constraint that must be met for the proof to be valid. Each constraint in an R1CS is an equation, in the base field, of the form:

    $$(a_0+a_1x_1+...+a_nx_n)(b_0+b_1y_1+...+b_my_m)=(c_0+c_1z_1+...+c_lz_l)$$
  • These constraints get simplified into one unique mathematical equation, that can be verified very quickly.

Following this process, Aleo lets you run private programs that anyone can verify - without exposing sensitive data. That’s how we enable powerful, scalable, and private blockchain applications.

So what makes Aleo permissionless, private, and programmable? It all comes down to architecture. The system is built so that anyone can join, execute logic privately, and broadcast results to the network. No one needs approval, and no one has to expose sensitive data.

Let’s break this down further.

Components in Play

User Users interact with the network. They can check their on-chain state, whether public or private, by querying an Aleo client node. When executing a transaction, they generate a zero-knowledge proof that confirms correctness without revealing sensitive data. For efficiency, they can even delegate proof generation to a third-party proving provider (some wallets offer this service) to speed up processing.

Third-Party Prover This is a specialized service that handles proof generation on behalf of users. It doesn’t touch authorization or signing, just the heavy lifting of computing zero-knowledge proofs. Users outsource this part for better performance, while still maintaining security.

The Aleo Network Architecture

The Aleo blockchain ecosystem is built on two core network layers: the consensus network and the peer-to-peer (P2P) network. Within this framework, three key types of nodes operate: Validators, Provers, and Clients.

Validator: Validators are critical participants in both the consensus and P2P networks. They typically run on port 5000 for consensus and port 4130 for P2P operations. Validators communicate with each other over port 5000 to maintain network consensus. Clients and Provers, however, are not permitted to interact directly with the consensus network.

The primary job of a Validator node is to follow AleoBFT rules to generate new blocks and maintain network integrity. Within the Aleo P2P network, Clients and Provers interact with each other and connect to select Validators to stay updated with the latest blocks.

Client: Clients play a key role by syncing blocks from the consensus network and updating the ledger. Through the Client's RPC, users can access real-time ledger data and broadcast transactions. Once transactions are included in a new block, they are officially confirmed and finalized on the network.

Prover: Prover nodes sync CoinbasePuzzles created by the consensus network. They run algorithms to solve these puzzles according to set criteria. Once a Prover finds a valid solution, it broadcasts it across the P2P network, where it is eventually submitted to the consensus network. If the solution is accepted and added to a block, the Prover receives a CoinbaseReward as an incentive for contributing to network security and computation.

Executing a Private Transaction

1. The user prepares the required inputs.

2. Fetches the relevant program from a node.

3. Runs the necessary function locally using SnarkVM.

4. Generates an output proof and broadcasts it, along with encrypted inputs and outputs, to a client node.

5. The validator verifies the proof, and consensus is reached through AleoBFT.

6. If all checks pass, the transaction is included in a new block on the ledger.

And that’s it, the transaction is finalized, and privacy remains intact.

This process is what allows Aleo to offer true private programmability at scale. The heavy computations happen off-chain, the network only sees and validates proofs, and users stay in control of their data. It’s a system designed for both security and usability, and as we move forward, we’ll explore how to build and deploy real-world applications using these principles.