Overview of Privacy Blockchains & Deep Dive Of Aleo

Thanks to Alex and the team at Aleo, Chris at Anoma/Namada, Nico from Elusiv, Fransesco from Polygon Miden, Dylan from Mina Foundation and Henry from Penumbra for insights and reviews. This post would not be the same without your input!

To talk about anything in the piece, you can reach out to Hannes on X or by email.

Introduction

Zero-knowledge cryptography has seen rapid progress over recent years and is today leveraged for scalability and privacy purposes in blockchains. Breakthroughs in research have made it cheaper and faster to generate proofs, while private funding has provided teams with the financial resources to build applications and infrastructure around it. 

Aleo is one of these teams, having raised more than $200m from investors with the goal of making privacy a default-setting in blockchains. To achieve that goal, Aleo is building a new layer 1 blockchain that is both private and programmable. This makes it significantly easier for developers to build and deploy private and decentralized applications.

Aleo is currently in the final stages of testnets with plans to launch on mainnet later in 2023. Equilibrium Group (Equilibrium Labs and Eiger) has been working with Aleo for more than 3 years. We’ve supported their core engineering team in various efforts, most notably the node infrastructure (SnarkOS), core cryptography and zkVM (SnarkVM), and the proof-of-stake consensus mechanism (Narwhal-Bullshark)

This post serves as a comprehensive overview of the private blockchain space before diving deeper into Aleo. Any future posts will take a closer look at specific parts of the Aleo stack.

Evolution of Blockchains

Ever since Bitcoin introduced the concept of decentralized trust and cryptoeconomic security, blockchains have gone through multiple iterations. Ethereum introduced general-purpose programmability and smart contracts, which spawned a whole ecosystem of applications built on top of Ethereum (DeFi, NFTs, DAOs…), followed by other layer-1 blockchains. 

Following that, development has branched in several directions, each exhibiting its own design choices and trade-offs. Today we see three main themes emerging:

1. Single Shard Scalability = Aims to achieve high throughput and low latency by pushing the monolithic stack to its limits and keeping everything integrated. Heavily relies on hardware acceleration for further performance improvements and decentralization. 

2. Modular Scalability = Aims to achieve scalability and customizability through specialization. Modular blockchains focus on a subset of the typical tasks of a blockchain (execution, settlement, consensus and data availability), with the remaining functions outsourced to other networks. Includes data-availability services, rollups, rollups-as-a-service and much more.

3. Programmable Privacy = Aims to make privacy a default in blockchains and abstract away the complexity of writing private applications. This enables developers to easily integrate privacy into their solution and multiple private applications to exist on the same ledger. Programmable privacy extends existing solutions that offer privacy for specific use cases, such as transfers of value (e.g. Zcash).

Note that this categorization is slightly simplified and could be split into further sub-categories, such as sharded scalability demonstrated by NEAR and more recently Linera. However, we feel that these three are the key themes. The debate today mainly centers around modular vs. monolithic, with programmable privacy as an emergent theme. 

Why Do We Need Privacy?

Most blockchains today are transparent by default, which reveals a lot of sensitive information about users. In addition, the lack of privacy prevents many applications from being deployed on blockchains, such as identity solutions or certain games. No one in their right mind would want their passport or driving license broadcast to the entire network, and playing a game like Battleship is not very exciting when you know the location of your opponent’s ships in advance. 

So while scaling and customisability are important for making blockchains more attractive, privacy is another key requirement for companies and individuals alike:

• Companies require privacy for regulatory, competitive and customer protection reasons. For example, storing customer information on a public blockchain would be highly irresponsible and having contracts publicly available enables competitors to undercut.

• Individuals too should be wary of having sensitive data, such as account balances and transaction history, broadcast across the network and open for anyone to view. This data is not only visible today but retrievable forever due to the immutability of blockchains.

This naturally raises a question: If privacy is so important, why are blockchains transparent today? 

The simple answer is that until now, we’ve lacked the technology to make blockchains private. Even Satoshi was thinking about ways to add privacy to the Bitcoin network, but there was no feasible option at the time.

Transparency is often celebrated as a feat of blockchains, but in reality, it’s just a consequence of most blockchains today operating through on-chain execution. All validators across the network re-execute the computation to verify that it was done correctly. This requires transaction data and related information to be published on-chain. Besides compromising privacy, on-chain execution is also highly inefficient and leads to a lot of redundant work with all validators repeating the same computation.

Thanks to advancements in zero-knowledge cryptography, we can now instead use off-chain execution and zero-knowledge proofs to verify the validity of computation and maintain privacy. Rather than each validator re-executing the computation, they simply verify the proof which is sufficient to convince the validator it was done correctly. Off-chain execution is both more efficient (less “wasted” computation) and quicker (verifying the proof is quicker than executing the program). Privacy is enabled since not all transaction details need to be posted on-chain for validation and proofs can be verified without having to reveal all the inputs.

What is Aleo and How Does It Solve The Problem?

Aleo is a layer-1 blockchain that combines general-purpose programmability with privacy by default. While existing privacy solutions such as Zcash are restricted to a single use-case (private transactions) and in many cases a single asset, Aleo aims to enable developers to create a variety of applications for multiple different assets - all on the same ledger. 

The core idea behind Aleo is ZEXE or zero-knowledge execution. It was initially introduced in a research paper in 2018 and some of the co-authors from that paper went on to build Aleo - the first practical implementation of it.

ZEXE enables different applications to be executed trustlessly, privately, and scalably on the same ledger. The two main concepts introduced in ZEXE are:

• The record model extends the UTXO model from Zcash and enables storing and encrypting arbitrary data (user assets and application states), rather than just values of specific assets or tokens (more details further down).

• Decentralized private computation (DPC) combines zero-knowledge proofs and off-chain execution, which allows validators to verify that the computation was done correctly while keeping the inputs and outputs private from both validators and outside observers (more details further down).

For an in-depth overview of ZEXE, we recommend this blog by Anoma or the three-part series by zkFM.

Key Benefits of Aleo

Aleo brings three main benefits to the table:

1. Privacy by default combined with programmability: Having privacy as a default setting is a way to incentivize users to stay in the shielded set, which increases privacy for individual users. Programmability enables developers to integrate privacy into applications such as identity solutions or games like Battleship, without having to go through the hassle of building a private application-specific chain.

2. Efficiency and scalability by avoiding re-execution: Off-chain execution leads to less redundant computation, as all nodes don’t execute the same transaction. Since the proof is generally smaller than the program being run, both verifying and communicating it is faster. In addition, it also reduces the storage burden as the proof requires less storage space than the related transaction data. While it’s fairly quick to generate proofs for simple transfers, proof generation for larger, more complex circuits is still quite slow and computationally intense. However, it’s an active area of research to reduce this friction.

3. Unlimited runtime for programs: There is no notion of gas in Aleo since off-chain execution doesn’t consume the chain’s resources in the same way as on-chain execution. In addition, the time it takes validators to verify a program proof is not directly linked to the program's runtime, which means a program could (in theory) run for months and in the end boil down to a small proof that’s quick to verify. Unlimited runtime enables more complex computations to be done on blockchains, such as linear regressions.

Privacy Comes In Many Forms

Before we get too deep into the weeds of Aleo and how it aims to achieve privacy, let’s take a step back and think about what privacy means in the context of blockchains. 

We believe there are three aspects that need to be considered when evaluating privacy protocols: 

1. What Is Private - Four different types of privacy that relate to blockchains:

• Private inputs (messages)

• Private outputs (state changes)

• Private counterparties

  • Users 

  • Function or program

The more boxes a solution can tick, the better. The most private solution ticks all four boxes (private inputs, outputs, user and function privacy). In our opinion, this approach is more objective than trying to put the different forms of privacy in order (for example, saying that private inputs > private outputs) since it varies by context.

2. Programmability - What can the privacy be used for?

A spectrum that goes from app-specific chain to full general-purpose programmability (Turing complete) with a private global state. In particular, focus on the programmability of the private computation and where its limitations are:

• Is there composability between private programs? 

• Any interaction between private and public states?

• Infinite runtime due to off-chain execution or finite due to gas?

The last stage - full general-purpose programmability with a private global state - could be reached with a combination of ZKPs, multiparty computation (MPC), and Fully Homomorphic Encryption (FHE). Particularly FHE is interesting, as it allows computation on private data. While there has been development on this front with teams such as Zama, Sunscreen, and Fhenix pushing the space forward, the developer experience is still quite complex and the performance of FHE is not yet attractive enough. However, with more funding flowing into FHE to accelerate the development of both software and hardware, broader adoption might be closer than we think. One noteworthy recent launch was the alpha release of fhEVM from Zama, which enables developers to write private smart contracts in Solidity. fhEVM is used by Fhenix, which currently has a permissioned devnet and is planning to launch a testnet in early 2024.

3. Strength of Privacy Guarantees - How reliable is the privacy and how easily can you extract information from the shielded set? 

Includes things such as: 

• Size of the shielded set? Multichain > Network (L1/L2) > Application > Asset

• Quantum proof? STARKs > SNARKs 

• Does it require a trusted setup? If yes, how many participants did it have? (besides being quantum-proof, STARKs also benefit from not requiring a trusted setup)

• Privacy as default or opt-in? Having privacy as default or using other incentives is a way to maximize the number of interactions within the shielded set. 

This dimension is partly technical (choosing STARK over SNARK) and partly design choices (maximizing the size of the shielded set). Private systems benefit from more people using them - the bigger the shielded set, the more private it becomes for individual users. More transactions within the private set also make it more difficult for on-chain analysts to extract information. For more information on this topic, we recommend reading this blog post by Anoma on which factors affect the privacy of a shielded set.

Where Does Aleo Fit Into The Privacy Framework? 

We can now analyse Aleo through the three-dimensional framework introduced above and see how it fits in:

What Is Private

• Aleo achieves 3/4 forms of privacy: private inputs, outputs and user privacy. With private transactions, an outside observer can only see that a transaction took place, which program was called and the input record serial number (publicly announces which record was spent in order to avoid double-spending). 

• Initially, Aleo was aiming for function privacy as well (as detailed in the original ZEXE paper) but decided against it as it would have led to worse performance and longer proving times. 

• While the default setting is private, users can selectively reveal information through public transactions or by sharing a viewing key (similar to Zcash). A viewing key decrypts the data so that a third-party observer can view your records and computations, but doesn’t authorize them to sign any messages or initiate transactions. Viewing keys could for example be used to give an accountant access to your transaction history while keeping it private from the rest of the network.

Programmability 

• Aleo is asset agnostic and enables programmability for private applications that only require local state updates. It also has unlimited runtime, since there is no notion of gas and applications are executed off-chain.

• However, there is no composability between private applications, which means that one application can’t use the private state from another application as its input. This limits the type of applications that can be built and makes Aleo better suited for applications such as gaming, identity solutions, zkML and P2P transactions. 

• It’s also not optimal for applications that require concurrent state access (i.e. seeing the same state at the same time), so building a public DEX like Uniswap might be better on an account-based blockchain like Ethereum.

• Updating the global state is possible through the Finalize function, which enables the interaction of public and private state. This allows for both entirely new types of applications as well as introducing some privacy to existing applications. One example is a semi-private DEX where the state of the pool is public, but user positions and individual deposits into the pool remain hidden.

Strength of Privacy Guarantees

• Aleo is SNARK-based, which means it’s not quantum-proof and requires a trusted setup.

• Currently, the shielded set on Aleo spans the network, but there are plans to enable bridging to other chains. Connecting Aleo to another privacy chain like Namada with a private bridge would widen the shielded set to multichain and improve user-level privacy. However, this is difficult to do in a fully privacy-preserving manner and for now at least, bridging between two shielded sets requires unshielding to transparent addresses.

• Having privacy as the default is an incentive to maximize the interactions within the shielded set, which increases privacy for individual users 

Overview of the Privacy Landscape

Aleo is not the only team that’s trying to solve the lack of privacy in blockchains. Earlier attempts have included application-specific privacy L1s (Zcash) and privacy applications such as mixers (Tornado Cash). However, both solutions restrict the size of the shielded set and offer limited programmability, which makes it difficult to extend the privacy to other applications (or even other assets). We've also seen hardware-based approaches that rely on trusted execution environments (TEE), such as Secret Network and Oasis. However, these are less flexible for changes (hardware vs. software) and face the risk of backdoor attacks and other exploits.

Newer attempts focus on programmable privacy - general-purpose blockchains (either L1 or L2) that make it easier to build private applications. There are also privacy layers that can be bolted onto existing chains (Elusiv, Nocturne…) which enable private transfers, private swaps, and potentially even more generalized private computation in the future.

Some takeaways and caveats from the table above are: 

• Most solutions achieve about the same amount of privacy (2 or 3).

• Aztec and Polygon Miden both aim to include function privacy, but the final production-ready solution might look different as they are still in the early stages of development. On Miden, the network currently learns of commitments to programs, but the team is working on a new instruction "pcall" which would leak no information about what programs have been executed. Aztec is still in the ideation stage, so it’s unclear how the final solution will look (overview of their design).

• Polygon Miden stands out as the only STARK-based solution.

• Namada and Penumbra both achieve multichain privacy in the sense that assets bridged from other chains share a multi-asset shielded pool. However, full multichain privacy is only feasible with private bridging, which doesn’t exist yet. Penumbra also stands out by only having a shielded pool and hence being private by default.

• Mina stands out as the only general-purpose privacy solution with privacy at an application level instead of at the base level (private ledger). This is because Mina uses the account model rather than a UTXO-type model as the other solutions. While the account model is more intuitive for developers, it also makes privacy at a base layer complicated since it uses account addresses to index the global state. This is a known tradeoff, however. Mina is betting on a simple developer experience to give rise to more private applications for users, rather than aiming for full ledger-level privacy.

• Tornado Cash is not strictly asset agnostic, since it only has shielded pools for mainstream fungible assets (ETH and major ERC20s). Privacy for more obscure ERC20s is limited and there is no privacy at all for NFT transfers.

Finally, there is a big difference in timelines. While Aleo and Mina* are furthest along from the general-purpose privacy solutions with an expected mainnet launch later this year and early next year respectively, Polygon Miden and Aztec don’t even have a public testnet yet. This makes it difficult to compare solutions as a lot can change in a year, especially for the solutions that are still in the idea phase. 

*The Mina mainnet has been live since 2021, but private computation (zkApps) is still in testnet.

Why Build an L1 From Scratch?

Building a new blockchain from scratch gives a clean slate and more freedom to optimise for specific design choices. In the case of Aleo, it’s optimised for making privacy-enhancing cryptography cheap, fast and easy to use in a browser environment.

However, building a new blockchain is by no means an easy feat. Besides developing the actual chain, it also requires bootstrapping the security and a validator set, creating developer tooling, and getting users & developers to migrate over to a new ecosystem. So why did Aleo decide to do it?

While the team initially looked at building a more Ethereum-centric solution, they decided against it due to restrictions on the cryptographic primitives of Ethereum. For example, Ethereum uses a signature scheme called BLS 12-381, which doesn’t translate that well to a ZEXE-type model that Aleo is developing. Instead, Aleo uses: 

• BLS 12-377 which supports fast proof verification.

• Edwards-BLS12 to enable efficient circuit operations. Twisted Edwards curves in general are useful for efficient Pedersen hashes and commitments, as well as signatures.

More generally speaking, Ethereum wasn’t built with zero-knowledge cryptography in mind and hence doesn’t natively support things like hashing functions and elliptic curves. The EVM reasons over 256bit words and operations are bitwise arithmetic and boolean. ZKPs, on the other hand, are field elements where programs are circuits encoded as polynomials and defined over that field. These are two very different things and bitwise operations become very expensive in the context of a SNARK circuit when each bit must be represented by a single constraint. Therefore, the blowup is typically quite large when trying to translate ZK programs into the world of regular computer programs.

In summary: While building on Ethereum might have been possible, it would have required making significant performance-related tradeoffs. Due to these reasons, the team concluded that it was better to build a whole new chain optimized for that, despite the other frictions related to bootstrapping a new network.

How Does Aleo Achieve Privacy? 

The key components that enable Aleo to achieve privacy are:

• The record model allows encrypting arbitrary data, not just token values.

• Commitments ensure that the information provided is valid and hasn’t been tampered with.

• Transactions are executed off-chain and verified using a program proof (ZKP that testifies to the correctness of the computation). This avoids the issue of having to post transaction data on-chain for validators to be able to re-execute.

Record Model

There are two main state models used in blockchains - UTXO (unspent transaction output) and the account model (introduced by Ethereum). 

Aleo uses a variation of the UTXO model - the record model. Of the other protocols in the category (programmable privacy) - Mina uses a private account model, whereas Aztec and Polygon Miden use a combination of the two.

While the account model is more intuitive for developers, it indexes global state using account addresses. This means that although a private account model can achieve privacy for inputs and outputs, it still compromises user privacy since the account address can’t be encrypted. Another issue with the private account model is the lack of concurrency since you have to consume the entire program state in order to update it (only one user can do it at a time). 

There are different ways around these issues. For example, account data in Polygon Miden is stored off-chain which helps with privacy (the network learns that some transaction was made using the account, but nothing about the nature of the transaction). Aleo’s record model uses program IDs as the clustering point (instead of account addresses) to improve privacy and enables programs to have internal states, which is both more efficient and solves the concurrency issue.

Records are a fundamental data structure that can contain any arbitrary payload and are used for encoding user assets or application states. A record represents a certain state of a program in the global state, for example, the balance of an account or your identity document. The key difference to the note model from Zcash is that records also contain information about which program it relates to (program ID). This opens the door to more complex logic and enables encryption of arbitrary payloads (assets, application states..), rather than being limited to simple transfers of value.

Each record contains information about who owns it, the stored value, and its application state:

Records in Aleo are consumed and created through a transition function. A transaction can contain multiple transitions, each responsible for the consumption and creation of its individual records. This enables including multiple state updates within one transaction. Each transaction can contain a maximum of 32 transitions, of which one is reserved for the transaction fee.

The consumption and creation of records don’t need to follow a 1-2-1 relationship (burn one, create one). Examples of when this isn’t the case include:

• A credit transfer where the entire balance isn’t transferred: takes one record as input and outputs two records (remaining unspent balance and transferred balance). 

• Token burn: takes N records as input and outputs none

Commitments

In private computation, the data payload in each record is encrypted and not visible to outside observers. However, we still want to convince someone that we have the information without revealing any of it. If you’re on the receiving end of the transaction, you also want to make sure that the other party follows through on their original promise.

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. This means that commitments are part of proof generation at both the transition and transaction level.

Off-chain Execution and Program Proofs

The final piece of the puzzle is off-chain execution, which gets around the issue of having to post transaction data on-chain. 

This is enabled by decentralized private computation (DPC), which allows proving transaction correctness without publicly revealing details about the user’s actions. DPC combines zero-knowledge proofs and off-chain execution: users execute the computation locally (off-chain) and post a zero-knowledge proof (“program proof”) to the blockchain.

Program proofs are created any time a program is executed and are used to convince validators (and third-party observers) that the computation was done correctly while keeping inputs and outputs private. Aleo is SNARK-based and uses the Marlin-proving algorithm to generate program proofs. The cryptography and proof generation are handled by SnarkVM.

While SNARKs benefit from being small in size (“succinct”) and quick to verify, generating the proof can still be significantly more difficult than running the underlying computation. Especially as ZK applications get more advanced, the complexity of the proof also increases as they require larger arithmetic circuits. 

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:

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

For more complex proofs - users might want to 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.

An active area of research is how to compromise between the two. One example is leveraging multi-party computation (MPC) and a network of multiple provers, where none of the provers sees the complete set of information. This would allow users to retain at least some privacy, while still enabling them to get the advantage of faster proving times through delegation.

At the end of the day, it comes down to user preferences. However, having the option to generate program proofs locally is still valuable since without it you force users to rely on third parties. That goes against both the values of Aleo as well as the general ethos of blockchains (decentralization and permissionless).

Example: Playing Battleship on Aleo

Privacy and applications of zero-knowledge cryptography can often be quite abstract, so let’s look at these concepts through a concrete example to see how this would play out in reality:

Battleship is a game where two players lay their ships into secret configurations on their respective boards (8x8 grids) and then take turns trying to guess the location of their opponent’s ships (“firing”). The game ends when one player has sunk all of the other player's ships.

For the game to work, the location of the ship on the board must be hidden from the other player. This means the game couldn’t be played on a public blockchain. We also want to avoid cheating so certain rules need to be followed. 

Rules

• 4 different ship types with lengths 5, 4, 3 and 2

• Ships must be placed vertically or horizontally (not diagonally)

• Ships can touch, but not overlap

• Players take turns trying to fire at (i.e. guess the location of) their opponent's ship

• The first player to destroy all their opponent’s ships wins

Preparation - Writing and Deploying the Program

The program is written in Leo - the domain-specific language (DSL) that’s used to write applications on Aleo. Leo compiles down to Aleo instructions, and then further to AVM bytecode and circuits, which are used for program execution and proof generation.

Once the code is ready, the program is deployed to a program registry, which functions as a mapping of a program ID to Aleo instructions. Each program has a unique program ID, which is used to indicate the program that was run in the consumption or creation of records.

The program registry lives on-chain and deploying and interacting with programs is permissionless (doesn’t require approval from Aleo or any third parties). Deploying programs on Aleo is comparable to deploying a smart contract on Ethereum.

Playing 

The game starts with one player offering a battleship game, which creates a dummy record. Once the other player accepts, the first dummy record is consumed and a new one is created that assigns the two players to the board.

Both players place their ships on the board and the program verifies that ships are placed according to the rules above. If valid, the board is updated with the location of the ships encrypted and stored in a record called board_state. This enables both keeping the state private (neither player can see the location of their opponent’s ships) and ensuring that players can’t swap their boards mid-game (each board has a flag that indicates whether a game has been started with that board).

Turns during the game are represented with move records, which are consumed every time a player makes a move and a new one is created through a transition. The move records contain encrypted coordinates of previous moves and the transition adds the new coordinate when creating a new record as well as whether the move was a hit or miss. 

To make sure that each player can only move once before the next player, the owner of the record changes with each move. For example, Player A must spend a move record to create a new move record containing their fire coordinate. That new record will be owned by Player B. 

At each transition (i.e. whenever old records are being consumed and new ones are created), the players generate a program proof. This is to verify that the computation was done correctly and according to the rules. The program proof is generated by the player on their own computer (or outsourced to third-party provers). Once done, it gets posted on-chain and verified by validators. If valid - the transition gets included in a block and the game can continue.

End Of The Game

The game ends when one player has successfully guessed all the coordinates of their opponent’s ships, i.e. has a total of 14 hits. This is represented as flipped bits in their hits_and_misses field on their board_state record.

The game is open-source, so you can try playing it yourself. 

Other Features of Aleo

This post is already quite long, but there are many other features that Aleo brings to the table. Below we highlight a few of them:

SnarkOS and SnarkVM

SnarkOS is the node software that forms the backbone of the Aleo network. It handles P2P networking and communication between the nodes, verifying transactions and consensus.

SnarkVM is the zero-knowledge execution environment (zkVM) run by clients and nodes. It includes the core cryptography primitives of Aleo and is responsible for proof generation among other things.

Narwhal-Bullshark Consensus Mechanism (PoS)

Most existing protocols suffer from doing two things at once, namely sharing data and ordering data. Done together, each step limits the other: data can only be shared as fast as it can be ordered and data can only be ordered as quickly as it can be shared. Decoupling these functions is the key paradigm shift that led to modern DAG-based protocols.

Aleo implements the Narwhal-Bullshark (NB) consensus mechanism, which is split into two parts:

1. Narwhal = a DAG-based memory pool that takes in transactions, syncs between validators and orders transactions

2. Bullshark = the consensus model that proposes blocks and decides which one is valid

Separating the memory pool and consensus also improves flexibility. Either one of the components could be replaced with something better in the future without having to overhaul the entire consensus model.

Another benefit of NB over other alternatives such as Tendermint, is reducing the complexity. A more straightforward design and less code to implement means the surface area for mistakes is smaller. All that said, NB is still much less battle-tested than Tendermint and the only live implementation is by Sui.

Incentivised Hardware Development Through Coinbase Puzzles

The proof of work (PoW)-consensus mechanism is a powerful mechanism for economically incentivising advancements in both hardware and software. We saw this clearly with Bitcoin mining, which started out on laptops (CPUs) and 5-6 years later transitioned to purpose-built hardware (ASICs).

Aleo uses Coinbase puzzles (sometimes referred to as Proof of Succinct Work or PoSW) to achieve similar benefits, with the end goal of making zero-knowledge proof generation cheaper and faster. Coinbase Puzzles inherit the same economic incentives from a traditional PoW algorithm with two main differences: 

1. Computation is actually useful: Coinbase puzzle is designed to relate to ZK computing, rather than just solving a menial problem through brute force (e.g. SHA256). The puzzles focus on speeding up two main subcomponents that currently dominate the cost of generating ZK-SNARKs - Multiscalar Multiplication (MSM) and Fast Fourier Transform (FFT).

2. Reward shared proportionally: Instead of a winner-take-all model, PoSW rewards all successful miners proportionally per block. This means that even miners with elementary proving hardware could participate, which leads to a wider distribution of rewards. 

Coinbase puzzles aren’t related to the actual running of Aleo and the network would work perfectly fine without them. Interestingly, however, this is the first time that ZK hardware companies have a predictable revenue stream (Aleo tokens), which changes the incentive for these companies to invest in developing better ZK hardware. In addition, the Coinbase puzzle become increasingly difficult over time, which means that miners/provers have to keep investing in newer equipment to keep earning rewards. 

This will likely be a big factor in driving the whole industry forward and indirectly benefits Aleo as well with faster proving times.

LEO smart contract language

Leo is a domain-specific language (DSL), i.e. a high-level programming language that abstracts lower-level cryptographic concepts. This makes building private applications significantly more intuitive than having to code ZK circuits yourself.

Leo compiles down to Aleo instructions, and then further into circuits and low-level instructions readable by the Aleo virtual machine (AVM). The circuits are used for generating ZK proofs, while AVM instructions are used for program evaluation. Leo is built from scratch by the team at Aleo with a high emphasis on readability. It’s designed to resemble Javascript and Typescript to smoothen the learning curve for developers already familiar with those languages (>12m globally). 

This article by zkValidator provides an overview of the DSL landscape. One big difference to other DSLs is that Leo incorporates a formally verifying compiler. It includes checks to ensure that a program produces the intended output as the code gets converted to lower-level representations (Leo code → Aleo instructions → R1CS). While bugs can still emerge at various stages (programming, auditing, and compilation), this is an attempt to minimize the risk of bugs going unnoticed or being exploited.

Summary

While blockchains today are mainly used for financial applications, privacy could enable more general-purpose computation on blockchains such as identity solutions, zkML, gaming etc. It also opens the doors to new types of users with more strict privacy requirements. However, that doesn’t mean that Aleo and other programmable privacy protocols are the endgame for blockchains. As we saw in the beginning, there are multiple different approaches, each with its own tradeoffs and use cases. 

At least to start off with, Aleo is an isolated ecosystem with weak interoperability and needs to incentivize users and developers to move over. There are also limitations to what can be built on Aleo privately, as some applications require using public inputs and global state updates (applies to all programmable privacy protocols). Finally, client-side proving is still quite slow and expensive for more complex programs, which will limit the performance that Aleo can achieve (affects all applications that use ZKPs).

That said - We believe Aleo is still several years ahead of its closest competitors with a planned mainnet launch later this year. Even though newer projects can benefit by learning from the mistakes of earlier ones, programmable privacy is a complex problem to solve and there are different approaches for achieving it (L1 vs L2, privacy at the application layer vs base layer…). Turning an idea into a production-ready implementation is not a straight road, so it would not be surprising to see delayed timelines for the newer protocols. Case in point - Aleo’s own timeline has been pushed back several times by this point.

One ecosystem-wide benefit from Aleo is the incentivized hardware acceleration through Coinbase puzzles. For the first time, there is an economic incentive for hardware manufacturers to develop ZK hardware, and provers have a predictable revenue stream. This lowers the risk of capital investments and will likely lead to improvements in both proving hardware & software.