Background

Equilibrium started working on Aleo back in 2020 when ZKPs were still mostly a theoretical concept and programmable privacy in blockchains was in its infancy.

We deeply cared about improving privacy in blockchains and wanted to help bring the ambitious vision behind ZEXE to life.

While we started with just one person, over time the team grew to five people working on various elements of the stack simultaneously. More than four years later and after several twists and turns, Aleo is finally live on mainnet!

Considering that most blockchain interactions today are still fully public, Aleo’s mainnet launch is a huge step forward for programmable privacy in blockchains (with several other teams building towards this shared vision). Developers that want to incorporate some privacy guarantees into their application no longer need to implement cryptography from scratch or create an entirely new (application-specific) blockchain.

Working on Aleo for the past four years has been a true privilege. While in many ways, this is only the beginning and there is still a lot of work ahead, we wanted to take a moment to reflect on the journey thus far and highlight some of our key contributions on the engineering side.

Equilibrium’s Key Contributions To Aleo

SnarkVM

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

Our main contributions here relate to finding and implementing optimizations that led to several significant performance improvements. Some of these include:

You can find a full list of our contributions to SnarkVM here.

SnarkOS

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.

We’ve contributed to multiple iterations of snarkOS as it evolved across 3 testnets to mainnet, and more closely to the networking and consensus protocol (more details on these below).

You can find a full list of our contributions to SnarkOS here.

Networking Stack

The networking stack is responsible for peer-to-peer (P2P) communication between nodes.

We designed and implemented a custom modular networking stack for Aleo which is robust and performant (low resource use). A modular structure for the networking stack allows for:

  • More flexibility and easier upgradability
  • Faster network-only tests (isolated testing) and larger-scale tests related to the network (e.g. peering).
  • Simplicity

If you want to explore the networking stack further, you can find the GitHub repo here.

Consensus Protocol (AleoBFT)

Aleo was initially planning to go with a Proof of Work (PoW) consensus model but pivoted* after testnet 2 due to risk of network centralization. Instead, it was decided to implement a Proof of Stake (PoS) consensus model based on Narwhal-Bullshark (NB) - a DAG based byzantine fault tolerant (BFT) consensus model. It’s split into two parts: Narwhal (Data dissemination) and Bullshark (Ordering of transactions and blocks).

We were involved in both the design and implementation phase:

  • Following the decision to change to PoS consensus in early 2023, we researched different options and ultimately recommended Bullshark BFT (which was new at the time).
  • In the implementation phase, we supported the Aleo team on integrating the Bullshark BFT to the rest of the protocol (snarkOS and snarkVM) along with testing and optimizing the protocol.

*There is still a PoW element in Aleo through the Coinbase Puzzle which aims to accelerate ZK hardware, but it’s separate from consensus.

Fuzzing and Testing

Fuzzing is a systematic approach to testing the input space of a particular program or function that aims to uncover bugs, vulnerabilities, and edge cases. A naive example would be a function that adds two numbers, in which case a fuzzer will generate random inputs to that function and aim to find edge cases as a result of exploring the entire input space.

Using structure-aware and grammar-based fuzzing, we fuzzed snarkVM execute calls for Leo programs at the Aleo instruction level. In other words, generated random yet syntactically and semantically valid programs that were inserted into the VM to test for edge cases. We used AFL++ which is a combination of tricks and generic algorithms to refine the input space. In our case, the input was Leo programs (rather than two numbers as in the naive example above).

We also leveraged AFL and libfuzzer to fuzz different network messages, revealing issues that were later patched. This didn’t require structure or grammar awareness though. Additionally, we introduced property tests to verify properties like invertibility of the BFT protocol message codecs.

What’s next?

Our commitment to advancing the adoption of privacy in blockchains remains as strong as before, if not stronger.

While we’ll continue to work on Aleo post the mainnet launch, we are also looking for new challenges and other ways to contribute in the privacy space. If you are building something novel or have a crazy idea that you’d like to get some input on - we’d love to hear from you!

Finally, if you’d like to join our small team of engineers, cryptographers and economists to help make the vision of a more open, private, and distributed internet a reality - we are hiring.

P.S. To learn more about Aleo, you can take a look at our deep-dive article from last year (some parts are a bit outdated, but most of it is still relevant).