Skip to main content

FAQs

What is the Aleo Public API endpoint?​

The Aleo Testnet API is organized around REST.

To query the network, make a request to Aleo Testnet public API by Provable.

URL
https://api.explorer.provable.com/v1/{network}

Simply replace {network} in the base URL with either testnet or mainnet to query the desired network.

For example, you can retrieve the current block height.

Do applications in Aleo function similarly to ZK rollups?​

Differences between Aleo applications and ZK rollups:

AspectZK RollupAleo Application
Information visibilityAll information is publicCan make some inputs private, using the zero-knowledge property of zkSNARK
Proof generationRollup coordinator generates the proof and submits it in the rollup-transactionUsers generate the proof themselves and submit it as part of the transaction
BatchingBatches multiple transactionsCan batch multiple transitions into the same transaction
zkSNARK usageUses the succinct property to prove correct execution of a batch of transactionsCan use rollup-like architecture with added privacy features

Similar to batching multiple transactions in a zk-rollup, Aleo has a way to batch multiple transitions into the same transaction.

How does the network of provers work, including their incentives and the consensus mechanism?​

Aleo is SNARK-based and uses the Marlin-proving algorithm to generate program proofs. The cryptography and proof generation are handled by SnarkVM. Aleo program proofs can currently be generated locally by the user or delegated to a third-party prover. These involve tradeoffs between performance and privacy:

tradeoff

Local proof generating is the most trust-minimized solution since it doesn’t require sharing private inputs with anyone else. However, the performance is limited to your hardware.

For more complex proofs - users can/may delegate to third-party provers with specialized hardware. While outsourcing proof generation leads to better performance, it sacrifices privacy as users need to share some data used in the computation to enable the prover to compute the zero-knowledge proof.

In the Aleo Network, provers use specialized hardware to generate proofs and solve puzzles that help secure the Network. They generate proofs for a given block and earn pro rata portions of the coinbase reward (a subset of the total block reward) based on how many above-target proofs they submit. Talking about the network and reward share among the provers:

Proof difficulties are set by a version of the algorithm created by the Bitcoin Cash team called ASERT. When a proof exceeds the current difficulty limit, a coinbase reward is shared among all provers who contributed. The computational work done by provers includes Multi-Scalar multiplication and fast-Fourier transforms.

How do Aleo Tokens work?​

Aleo Tokens are used in two main ways:

  1. Secure the network: Validators stake Aleo Tokens to propose blocks and secure the network, and receive Aleo Tokens as a reward for validation. This is standard for PoS blockchains.
  2. Purchase zero-knowledge compute: Applications that need zkSNARK-proving use Aleo credits to pay provers to generate the proofs.

How does Proof of Succint Work (PoSW) operate for provers in Aleo?​

Aleo is not a purely Proof-of-Stake network. Aleo consensus is a combination of mining and staking called Proof-of-Succinct Work (PoSW). Aleo’s proprietary consensus algorithm is called AleoBFT. The staking portion of consensus is based on DiemBFT, created by the Diem blockchain team once housed at Meta. DiemBFT is organized into rounds, with a leader first proposing a block. Validators then vote for the leader of the next round. Once a vote quorum is reached, the next round’s leader creates a quorum certificate and includes it in its next block proposal.

The provers solve puzzles through generating zk-SNARK proofs that are then included in blocks that Aleo validators finalize. So instead of mining doing meaningless work, provers directly contribute to the privacy of the network. Provers run software like SnarkOS on GPUs or other specialized hardware to solve more puzzles and increase chances of winning Aleo Coinbase rewards (block reward and txn fees).

How is the record model in Aleo designed, and how does it compare to the account and UTXO models?​

Aleo supports both the UTXO like model with Records and account like-models with mapping. In the record model, a decentralized ledger tracks every record via a global state.

We still have users with addresses but instead of running a transaction in an application on a bunch of inputs, we actually execute the transaction locally on a bunch of records and provide these transitions within the transaction with the proof that I have actually executed these records correctly. And in this manner when the network updates the program is no longer a global store of encrypted states, it’s now an abstraction over records. Essentially splitting up the state in a more proficient manner.

record model

Record model is very similar to the UTXO model (of Bitcoin). The addition on top of the UTXO model is that the content of the UTXO can be as per the program needs and not baked into the protocol level and all the content is encrypted by default.

From the blockchain dilemma triangle perspective, which aspect, if any, did Aleo compromise on?​

Aleo doesn’t compromise on the trilemma and in fact addresses it in totality. This is possible because of Aleo’s consensus algorithm and ZK Snarks.

Aleo enables Account privacy: The decentralized ledger indexes the global state based on program IDs.

Efficient state updates: Record abstraction: helps you segment/compartmentalize your information from others. Predicates essentially only consume program records being updated.

Concurrency: Simultaneous updates to the program states are achieved through records and the ledger ensures that the program records are not double spent. If we look at the records, we have a Merkle tree of all these leaves, leaves are usually entries. How’s concurrency achieved? Because we can have the network effectively take all these record updates, and then in one go, update a Merkle tree with everybody's deltas, everybody's diffs, and then subsequently linearize that and patch up to a Merkle group and put that into the block header. And so this fundamentally gives us the ability to get back the feature that we had in the previous account model now in this record model, but with concurrency.

How does Aleo prevent double spending, and what are the implications for transaction finality and fees?​

Since Aleo supports both the UTXO-model with records and account model with mappings, the double-spending is prevented in different ways:

For UTXO model:

Each record has a serial number and a corresponding commitment. When spending the record, you publicly create an inclusion proof verifying that the record is in a tree of commitments and the serial number is used to verify that the same record has not been used previously. If we try to spend the same record it fails.

Commitments are a cryptographic way to ensure that the information provided is valid and hasn't been tampered with. They allow protecting sensitive information while still enabling verification and trust. Commitments are also essential for implementing smart contracts on Aleo, as they enable the verification of contract conditions and ensure that the contract's execution adheres to the specified rules without exposing the underlying data

Generating a transaction involves creating commitments to new records as well as computing the unique serial number for consumed records. Commitments are part of proof generation at both the transition and transaction level.

For account models:

The account is updated globally in a mapping. So everytime the transfers happen, the amount is subtracted from the sender’s account and added to the receiver’s account (similar to Ethereum and other public chains). Since the information is global, you cannot make transfers of the amount that you do not have in your account. For transactions that update the mapping, one still requires the proofs (unlike the signatures for authorization of transfer) and the proof is based on a stateRoot. If there has been an update in the mapping by some prev transaction, the stateRoot changes and the proof will fail.

What is the purpose and functionality of Aleo instructions?​

Aleo instructions is the intermediate representation of Aleo programs. All Leo programs compile to Aleo instructions which compile to bytecode. Aleo instructions are compiled into AVM opcodes that can be executed by the Aleo Virtual Machine.

To generate the zero-knowledge proof, arithmetic circuits are used. Developers on the EVM ecosystem write these circuits using Circom, Zokrates which are later used to generate the proving and verifying keys to generate the proofs. Aleo instructions are the way to write these circuits.

If we have a leo program to add two u32 variables:

leo example

The Aleo instructions would look something like this (very similar to assembly language):

ai example

Why was Leo created, and how does it differ from other smart contract languages like Solidity?​

To generate the zero-knowledge proof, arithmetic circuits are used. Developers on the EVM ecosystem write these circuits using Circom, Zokrates which are later used to generate the proving and verifying keys to generate the proofs. Writing circuits can be a bit daunting.

So Leo abstracts that away and makes it easier for developers to write their logic in higher level language called Leo (files with .leo extension) instead of Aleo (files with .aleo extension) circuits.

How does Aleo's approach to off-chain computation differ from other solutions like ZK-Coprocessor, and what are the privacy implications of outsourcing proving tasks?​

The approach is very similar. Each transition on Aleo can have an additional finalize block. The logic of the transition block is verified with the ZK-proof and the logic in the finalized block is re-executed by all the nodes on the network to update the state stored in the mapping.

In this sense the logic inside transition acts like the computations sent to the ZK-processor which requires a fixed transaction cost (no matter the size of the logic) and the logic inside the finalize block is similar to the on-chain execution of other public blockchains like Ethereum.

Right now, on Aleo, you have the option to delegate proof generation to a remote server. This will speed up proof generation but disclose the transaction details to a trusted server. For some applications and users, this makes sense but for some applications where privacy is of utmost importance, users still have the option to generate the proof themselves.

Private proof delegation would be the holy grail but we aren’t there (yet).

Learn more about the state of outsourcing proving tasks here.

How does Aleo compare to Bitcoin and Ethereum in terms of its core design and functionality?​

aleo advantage

From the above slide from The Aleo advantage perfectly answers the question.

Bitcoin is public money. It is not programmable and all of the user’s transactions are public.
Ethereum introduced programmability but still didn’t offer privacy.
Some projects like ZCast offered privacy but didn’t provide programmability.
Aleo provides both privacy and programmability.

Where can I watch talks and videos?​

What are the Aleo's social accounts?​

👾 | Discord ~ https://discord.gg/aleo

🐦 | X (Twitter) ~ @AleoHQ ~ https://twitter.com/AleoHQ

🤝 | Community X (Twitter) ~ @aleocommunity ~ https://twitter.com/aleocommunity

🐙 | GitHub ~ https://github.com/AleoNet

✍️ | Community Blog ~ https://medium.com/@aleohq

Are there more useful resources?​

🏎️ | A curated list of Aleo & Leo code and resources ~ https://github.com/howardwu/awesome-aleo

📜 | A starter guide to build applications on Aleo ~ https://github.com/AleoNet/workshop