Devnet is now live! This milestone enables private, client-side smart contract execution with robust public verifiability, a massive milestone for Aztec and the Ethereum community.

To celebrate this milestone, we’re launching Alpha Build, a series of three developer sprints with a USD $100,000 prize pool and the opportunity to deploy on the Aztec Network for the first time.

The first Alpha Build will kick off Monday, August 19th with two additional Alpha Builds happening by mid-November. Alpha Build participants will receive expert mentorship, gain direct access to the team, and connect with a growing community of over 300 developers from around the globe. In addition to cash prizes, top builders will be invited to deploy their applications on the Devnet.

Complete the Alpha Build Application to gain access to the Discord server, and download the Aztec Sandbox to get started.

How Did We Get Here?

Devnet is a culmination of all the hard work and iteration over the past 7 years. 

In March 2023, we made a bold commitment to focus on bringing the Aztec Network to life and delivering true programmable privacy. Over the past year and a half, our team has worked tirelessly to bring this vision to life, and their efforts have paid off. 

Today, we’re proud to deliver on that commitment and unveil a live Devnet, realizing the integration of all essential components of the tech stack, including Honk, cutting-edge cryptography, Noir for smart contract development, a private execution environment (PXE) for client-side proof generation, and a sequencer for transaction processing and public execution. 

Together, they enable private, client-side smart contract execution with robust public verifiability, marking a significant leap forward for the Aztec Network.

More on Alpha Build   

Over the next few months, we’ll run three themed Alpha Builds with challenges across the most important use cases in crypto, including payments, gaming, and identity. Privacy expands the design space so you can explore solutions for conditional payments, on and off-chain access control using NFTs stored privately on Aztec, or card games with a shared hidden public state.

The three challenges for Alpha Build One (ab1) will focus on payment use cases with an emphasis on building a UI, Account Abstraction and Fee Abstraction features. If you’re new to Aztec or have been with us from the beginning, ab1 is your chance to dive deep into underexplored problems and designs while contributing to the growing ecosystem. 

Complete the Alpha Build Application to gain access to the Discord server, and download the Aztec Sandbox to get started.

ab1 Challenge Overview

The Alpha Build payment challenges are designed to build upon each other, increasing in complexity as the weeks progress. Here’s what you can expect:

1. Challenge #1: Wallet
   • Develop an interface similar to Daimo/Payy that uses secp256r1 signature verification, similar to FaceID or TouchID.
   • Build a web interface to facilitate smooth user interaction with Aztec.
2. Challenge #2: Programmable Accounts
   • Create custom account contracts with alternative authorization methods than simple digital signatures.
   • Integrate transaction authorization through zkemail.
   • Implement features for spending limits or a multisig account contract.
3. Challenge #3: Programmable Fee
   • Design a system to sponsor transaction fees on behalf of users.
   • Develop a Paymaster capable of handling payments in multiple tokens.

Throughout the challenges, the DevRel Team will provide Discord support and host weekly office hours from 10 a.m. - 11 a.m. ET every Wednesday and Thursday. 

Submission Criteria

All submissions for ab1 are due by Sunday, September 15th, 2024, and must include the following: 

• A link to the GitHub repo of your project 
• A README file that describes how to run and use the applications and or contracts 
• X handle
• Telegram
• Discord username

Let’s Create the Future of Payments, Together  

Don’t miss this opportunity to deploy on the Aztec Network for the first time. 

To get started, fill out the Alpha Build Application. We will review applications and, if selected, invite you to join a private Discord channel for our Alpha Build. 

The Devnet Live Celebration will be on Friday, August 16th, 2024, at 11:30 a.m. ET on X. Join Cat, our Developer Relations Engineer, and President and Co-Founder, Joe Andrews as they dive deep into Alpha Build season, exploring challenges, themes, and innovative ideas. 

Intro

In blockchain narrative, the term “zero knowledge” entered our vocabulary when rollups first emerged. In particular, we’ve heard it a lot in the context of zero knowledge rollups (ZK-rollups). But, zero knowledge technology has existed for years before. The first article on zero knowledge was published back in 1989.

In this blog, we’ll break it down to clarify what zero knowledge (ZK) is and what it ISN’T (the latter might actually be more interesting than the former). We’ll investigate if ZK-rollups have any ZK for real, and if not, why they get to use the term at all, and dive into the difference between ZK as a technology and ZK as a marketing term.

For those who need answers right away:

• ZK-rollup provides a succinct verification mechanism
• But ZK-rollup does NOT provide privacy

*by privacy we mean (i) user privacy (transaction sender and recipient), (ii) data privacy (payload of the transaction, e.g., the asset or value being transacted), and (iii) code privacy (the program logic).

Now let’s dive a bit deeper.

Zero Knowledge Property Outside of Rollups

If we want to discuss ZK in a rollup context, we first need to understand zero knowledge property on its own. As we mentioned above, the concept of ZK was introduced in 1989 (years before the first blockchain was baked) in a paper titled, “The knowledge complexity of interactive proof systems.” It wasn’t until around 2018 that the Ethereum community figured out ZK might be a good fit for a rollup universe.

We usually consider zero knowledge as a property of a proving system. In blockchain, we often say ZKP, meaning zero knowledge proof. But “proof” might mean proof of statement or proof of knowledge. So, in the next section of this article, we will differentiate between the two types of proofs.

Proof of Statement

Proof of statement proves that a statement is true without revealing anything about the statement itself.

Examples of statements:

• z is a square modular n: z = x^2 mod n
• The graphs G and H are non-isomorphic
• The number 638634389........3427 has 3 prime factors

Proof of Knowledge

Proof of knowledge proves that the person making an assertion has some knowledge about the statement.

So, if we look at the examples from the previous paragraph side-by-side:

Proof of StatementProof of Knowledgez is a square modular n: z = x^2 mod n.I know a value x such that z = x^2 (mod n).The graphs G and H are non-isomorphic.I know the isomorphism between two graphs, G and H.The number 638634389........3427 has 3 prime factors.I know the factors of the number 638634389........3427.

One should note that every proof of knowledge is a proof of statement (but not the opposite). For instance, if one proves that they know a value x such that z = x^2 (mod n), this will be proof of knowledge, but it also automatically proves that z is a square modulo n (proof of statement).

Let’s explore one of these examples to see how proof of statement and proof of knowledge can be constructed!

Exploring Examples: the Graph-Isomorphism Problem

Let’s use the graph-isomorphism problem. To do this, we’ll say proof of graph non-isomorphism will be proof of statement, while a proof of graph isomorphism will be proof of knowledge.

What Is the Graph-Isomorphism Problem?

Basically graph isomorphism (denoted by ≅) is the following: two graphs with labeled nodes are isomorphic if they are "the same" up to a permutation of the labels. That is to say, there exists a permutation of the labels of one graph that results in the other graph.

More formally, we say that two graphs G and H are isomorphic if there is a bijective function f between the vertices’ labels of G and H such that there is an edge between the vertices u and v in G if and only if there is an edge between the vertices f(u) and f(v) in H.

An example of two isomorphic graphs:

If there exists no such permutation, we say that the two graphs are non-isomorphic. Now, assume we want to prove that two graphs are non-isomorphic. We only want to prove this single fact; nothing about the graphs themselves, no other knowledge except for the statement that they are non-isomorphic.

Example of A Proof of statement: the Graph-Non-Isomorphism Problem

Proof intuition:

• If there are two non-isomorphic graphs G and H, one randomly chooses a permutation π (re-orders elements in a deterministic way) as well as randomly chooses one of two graphs, and calculates K = π{G or H} that is K is a permutation of either G or H.
• If G and H were isomorphic, anyone else should NOT be able to tell from which of the two graphs K was computed, and could only guess.
• The probability of guessing would be ½. Repeating the protocol enough times makes the probability of guessing negligible.

One round of protocol:

Example of A Proof of Knowledge: Graph Isomorphism

Now, let’s think… What if we want to prove two graphs are isomorphic? In other words, the Prover wants to prove that they know the isomorphism σ such that H = σ(G).

Proof intuition:

• If σ is an isomorphism between two graphs, it means that H = σ(G) and G = σ^{-1}(H) where σ^{-1} is the reverse isomorphism.
• Let π be a permutation randomly chosen by the Prover. Using ρ = πσ^{-c} (where the Verifier randomly assigns 0 or 1 to c), they get either  ρ = π or ρ = πσ^{-1}.
• By applying ρ = π to a graph, one will get its permutation. By applying  ρ = πσ^{-1} to a graph, one will get its permuted reverse isomorphism:

One round of protocol:

Back to Zero Knowledge!

Now that we’ve explored examples of proof of statement and proof of knowledge, let’s discuss whether or not they have zero knowledge property.

Informally, zero knowledge means that a Verifier can’t retrieve any additional information from a Prover (except for the information clear from the proof itself).

In the example of graph isomorphism, proof of knowledge is zero knowledge (with honest Verifier). According to the protocol, the Prover doesn’t reveal any information on the isomorphism or permutation to the Verifier. Instead, they send the Verifier commitments and that’s it.

However, in the example of the proof of graph non-isomorphism, it’s not zero knowledge. Because, instead of setting K = π(G) or K = π(H), a malicious Verifier (i.e. a Verifier which deviates from the protocol) can set K = π{RANDOM GRAPH} and as a result of the protocol execution by the Prover, the Verifier will know if RANDOM_GRAPH is isomorphic to either G or H. So the Verifier is definitely able to retrieve additional information.

Can we convert our proof of graph non-isomorphism into zero knowledge? Yes, we can. The Verifier should also provide proof that (i) the graph it sends is isomorphic either to G or to H (meaning the graph they’re sending is not arbitrary), and (ii) they know the isomorphism.

One should note that most protocols in the space are only honest-verifier ZK (i.e. ZK property doesn’t hold with malicious verifier). However, this isn’t an issue because the protocols are made non-interactive with the Fiat-Shamir heuristic. Hence – there is no distinction for non-interactive protocols as the verifier cannot "misbehave.”

Now, when we differentiated between proof of statement and proof of knowledge and saw that both of them can have zero knowledge property or not have it, let’s take a look at ZK-rollup and figure out (i) does it use proof of statement or proof of knowledge, (ii) does it have zero knowledge property?

Finally, Back to ZK-Rollups!

In a ZK-rollups, the logic is pretty similar to the graph-non-isomorphism problem (where we prove the statement that two graphs are non-isomorphic). In ZK-rollup, we prove the statement that the state transition was done correctly.

A Glimpse into How ZK-Rollups Work

In this section, we’ll briefly cover how ZK-rollups work and how they utilize proofs. By “ZK-rollups,'' we mean regular (i.e. NON-privacy-preserving) ZK-rollups such as Scroll, Starknet, zksync, Taiko, and many more.

The main use of “vanilla” ZK-rollups is to enable scalability by posting a single proof of the validity of transactions.

ZK-rollups execute transactions off-chain and post proof on L1 (Ethereum) that whatever they did off-chain was done correctly. Their purpose is to prove that the new chain state is correct.

To generate a proof of correct state transition, one needs to prove that all transactions were executed correctly on given inputs.

For the sake of this, the Prover needs to know previous state and input values.

However, for the Verifier to verify the proof, they need to have the proof as well as to know new state, previous state, and input values:

Inputs

There are two types of inputs, public and private. In ZK-rollups, “private input” does NOT mean “secret” even though they are called “private.” Instead, it means that private inputs are consumed by Prover only while public inputs are consumed both by Prover and Verifier (sometimes private inputs are also called “witness” as a reference to the NP complexity class). Public inputs are expensive as they need to be submitted to L1 hence we want it to be as small (“succinct”) as possible. In terms of what these inputs consist of in the context of the proof:

Public inputs (consumed by Prover AND Verifier) – all data that needs to be submitted to L1 so that everyone can update their records of the current state. This will include new state root as well as might include signatures, sender, receiver, functions, contract addresses, function arguments, newly-deployed contract data, storage slots which have changed and their new values, events that were emitted. One should note that this reveals A LOT of information to a public observer. The specific list of public inputs will depend on the specific ZK-rollup design.

Private inputs (consumed by Prover ONLY) – all information that was needed by rollup circuits to prove correctness of the state transition. This will include Merkle membership proofs (hash paths) as well as the execution trace (might include transaction inputs such as newly-deployed contract data, storage slots which have changed and their new values, and events that were emitted).

As you can see from the logic above, private inputs have nothing to do with privacy. So if a ZK-rollup is generating a proof that Alice sent Bob 1ETH, both the Prover and the Verifier will be aware of this information (i.e. no privacy at all!).

To sum it up, in the case of a ZK-rollup, we want to prove the validity of transactions, it is a proof of statement and it does NOT have zero-knowledge property because all the information (i.e. state, functions, inputs) is public and everything that is not provided explicitly can be derived by a Verifier.

That is to say, there is no ZK in a vanilla ZK-rollup. Why is it called ZK-rollup then?

Maybe… For the sake of marketing =)

And Still, Can ZK Provide Privacy?

Short answer: yes, it can. While the main use of “vanilla” ZK-rollups is to enable scalability, the main use of Aztec is to enable scalability AND allow privacy. And, it utilizes ZK exactly for the privacy purpose.

Aztec provides privacy by means of client-side proof generation, i.e. whatever should be processed privately is processed on the user’s device and then a proof of its correct execution is supplied to the mempool.

Processed privately means that

• Transactions are processed privately (on user’s device)
• Their outputs shroud side effects (such as note hashes and nullifiers)
• And those get added to the global state without revealing any information to anyone except for (i) the client who executed transactions and emitted side effects, and (ii) the receiver of side effects (for example, in case of a transfer from Alice to Bob, Alice executes transactions client-side and emits side effects and Bob receives side effects).

Client-side proofs are then verified by the sequencer (who manages the mempool).

In this case, client-side proof is a zero knowledge proof of statement: the sequencer verifies the proof validity without any information about what was executed on the client-side, and is unable to retrieve any information about it.

After client-side proofs have been verified by the sequencer, everything is similar to a vanilla ZK-rollup mechanism as described in the previous section. That is to say, Aztec ZK-rollup first generates a number of client-side proofs (which are zero knowledge proofs) and then a block proof (which is not zero knowledge).

One Can’t Just Add ZK to Get Privacy

It’s not possible to add privacy ad-hoc to an already existing ZK-rollup. It should be designed to be private from the very beginning.

One first needs to give a precise definition of “privacy” as the statements proved, depending on the rollup design, may reveal unnecessary information and harm user privacy.

If builders want their dApps to interact with the external world; meaning that dApps aren’t monolithically private but instead allow some functions and variables to be private while some functions and variables stay public (e.g. necessary for AMMs, lending protocols, etc.), rollup state management becomes very non-trivial. Now it has to process public and private state updates separately. However, it’s exactly the latter approach that unlocks dozens of use cases we’ve been dreaming about for years! (Think programmable on-chain identity management and DeFi alternatives to conservative financial institutions).

As of today, Aztec is one of very few privacy-preserving L2s on Ethereum where privacy is provided by processing private information on the client-side. Check out this article to dive into client-side proof generation and this article to learn more about Aztec smart contracts anatomy allowing for hybrid private and public state management.

Ready to join Aztec’s building pioneers? Let us know by filling out this form.

Many thanks to Palla, Patrick, and Brecht for review.

In the ever-evolving landscape of digital privacy, the power of Zero-Knowledge Proofs (ZKPs) is revolutionizing how we protect and prove information. Noir, a leading language for privacy-first programmable privacy, is at the forefront of this innovation and is calling on you to help us enhance provable emails using Noir. This research campaign (NCR#1), running from August 8th - 25th, 2024 presents a unique opportunity to push the boundaries of privacy while creating novel solutions for secure email verification.

Why Privacy-First, Provable Emails?

The rise of Programmable Cryptography and Zero-Knowledge Proofs offers unprecedented potential for trustless and private verification of information, cryptographically bridging data across silos. Imagine a world where you can prove ownership of an email address or an email received without revealing its content or personal details. This capability is not just a theoretical possibility, but a practical reality waiting to be unlocked through advanced research and development.

What We’re Looking For

Aztec Labs has been a strong supporter of this vision, particularly with the ZK Email team's pioneering work. As a part of these continued efforts, we invite researchers, developers, tech enthusiasts, and anyone with creative ideas to propose a two-month research plan that explores ways to leverage Noir (and Aztec) to augment this work and its broader vision.

We’re looking for proposals focused on building end-user-oriented projects, including MVPs. Proposals focused on building developer tooling and technical/cryptography research are also welcome as long as their relevance to zkEmail is clear.

Multiple submissions are welcomed, however, to be considered, your proposal must meet the following criteria:

• Implementation in Noir: Your final implementation should include components written in Noir, if not fully in Noir.
• Testing and Documentation: Ensure thorough testing and comprehensive documentation of your implementation.
• Open Source: The final implementation must be open-sourced under a permissive license (e.g., MIT).

How to Submit Your Proposal

To participate, please head to our GitHub and submit your proposal using the following format:

• Title
• Summary
• Methodology
• Timeline and Deliverables
• Team
• Start Date
• Questions

Proposal submissions are open now and will close on August 25th, 2024. Our selection committee will pick two proposals that will receive up to US$40,000 in grants. Winners will be announced before September 5th, 2024, via GitHub Discussions and X.

Click here to get started on your proposal today.

Audit Partners

We believe in the value of the real-world impact of top-tier research.

To ensure the security and quality of applying research outcomes, we’re onboarding audit partners to sponsor and provide auditing for the final implementations of selected proposals. Potential audit partners will be evaluated up to August 20th, 2024, and announced on GitHub by August 31st, 2024.

To learn more about how to get involved, please contact Savio or Lisa.

Start Tinkering

Join us in pioneering the future of privacy-first communication. Submit your proposal and be part of this transformative journey with Noir!

Special thanks to Palla, James Zaki, and Emmanuel Batse for the review.

Disclaimer: if you’re familiar with Account Abstraction and are curious about how it works on Aztec, go right to the section “The most abstract Account Abstraction”.

Account Abstraction context

What is AA and why did the Ethereum community give it this name?

• Initially, all Ethereum accounts were Externally Owned Accounts (EOAs), controlled by the user’s private key (i.e. whoever has the private key owns the account).
• With the Ethereum evolution, it became clear that to make Ethereum accounts more flexible and unlock a number of use cases, we need to abstract some or all parts of the accounts. However, this is expected to happen without sacrificing decentralization or censorship resistance.
• Among the use cases to be unlocked are account recovery, gas sponsorship, multichain accounts, and support of signatures other than ECDSA, such as more efficient signatures (e.g. Schnorr, BLS), or more user-friendly ones (e.g. smartphone secure enclave).
• Among the account parts to be abstracted are authentication (“Who I am”), authorization (“What I am allowed to do”), replay protection, fee payment, and execution. But strictly speaking, if we abstract even one of them we already call it AA.
• Today, when one is talking about AA, they mean abstracted verification logic. It can be abstracted up to the protocol level or to the smart contract level. In particular, it usually implies that accounts are controlled by smart contracts (i.e. a piece of code) that describe the verification logic.
• By native AA, we mean that AA is implemented at the protocol level. As a rule, in this case, all the accounts on the network are smart contracts (i.e. no EOAs at all).
• By non-native AA, we mean that AA is implemented at the smart-contract level. In this case, there might be both EOAs and accounts controlled by smart contracts.

Note: the second option is sometimes also referred to as “contract wallets” or “smart accounts”.

The story of Account Abstraction

AA on Ethereum

The discussions around AA on Ethereum started around 2017. There were a number of EIPs and ERCs proposing different versions of AA (e.g. EIP-86, suggesting abstraction of transaction origin and signature, EIP-1014, and EIP-2938) that were explored and discussed but ultimately rejected, so we won’t cover them in this piece.

The first ERC affiliated with AA that made it to Ethereum mainnet was ERC-4337 (deployed on Mainnet in March 2023). It introduced AA without any modifications to the core protocol. It achieved this by replicating the functionality of the transactions mempool in a higher-level system. Instead of transactions, users send UserOperation objects to relayers, and these relayers package a set of these objects into a single standard transaction that is sent to Ethereum nodes.

Since then, the community has argued whether ERC-4337 is the Ethereum AA endgame or not. Right now, there is a dispute around EIP-3074 in the next Ethereum protocol upgrade. It suggests AUTH and AUTHCALL opcodes, which allow EOAs to delegate execution to smart contracts. However, one should note that the transaction validity still relies on EOAs’ ECDSA signature (i.e. ECDSA signature becomes enshrined).

This EIP is not new and some ecosystem players have discussed it being complementary to ERC-4337. The core question is what’s the more urgent problem for Ethereum to solve – censorship-resistance (against EIP-3074) or user experience (for EIP-3074)?

Account Abstraction on L2s

As Ethereum follows the rollup-centric roadmap, we expect most activity to happen on Ethereum L2s. As L2s technically don’t depend on Ethereum, they can implement AA on their own by introducing appropriate opcodes.

Some L2s have chosen a native AA “feature” as one of their core value propositions and implemented native AA (among those zkSync, StarkNet, and Aztec). In particular, this means that a transaction can be initiated directly by a smart contract (i.e. without any reliance on EOA).

As a comparison, in ERC-4337, AA is not native, as there is a step in the tx flow where an EOA account is engaged (as a Bundler).

As an alternative to enshrining AA in Ethereum, the Rollup Improvement Proposal (RIP) was proposed. RIP is a way to facilitate L2 standardization (not only around AA but around other L2 aspects as well). RIP-7560 is a native version of ERC-4337 for L2 chains currently under discussion. Check a series of RollCalls to learn more.

The most abstract Account Abstraction

While we talk about “arbitrary verification logic” describing the intuition behind AA, the logic is not really arbitrary. The verification logic (i.e. what can be checked as an authorization) is limited to make the verification time fast and bounded. That is the case for all chains where transaction validity is checked by the sequencer. Otherwise, it will cause UX downfall, whereas the main reason behind introducing AA is UX improvement.

On Aztec, there is no limitation on verification logic, as transaction validity check is executed client-side and a proof of validity is supplied to the sequencer. The sequencer only verifies the proof and this process is independent of the verification logic complexity.

This unlocks a whole universe of new use cases and optimization of existing ones. Whenever the dapp can benefit from moving expensive computations off-chain, Aztec AA will provide a unique chance for an optimization. That is to say, on traditional chains users pay for each executed opcode, hence more complex operations (e.g. alternative signature verification) are quite expensive. In the case of Aztec, it can be moved off-chain so that it becomes almost free. The user pays for the operations in terms of client-side prover time.

For example:

• Multisig contract with an arbitrary number of parties that can verify any number of signatures for free.

• Oracle contract with an arbitrary number of data providers that can verify any number of data entries for free.

However, one should note that if the verification logic depends on the public state and requires a public function call (e.g. checking the balance), this check will be executed by the sequencer and imply some limitations on the allowed complexity of verification logic. For those who prefer watching over reading, here is a talk, “Account Abstraction for a Private Network”, by Santiago Palladino (Palla).ConclusionAA is not a new topic, however, AA on private networks unlocks new capabilities for arbitrary verification logic, allowing for more complex logic as well as significant cost optimizations.  Check documentation to dive into the details of Aztec’s AA. And if you are up to join Aztec’s building pioneers – express your interest in this form. Sources

• The website ERC-4337.
• An article, “Why 4337 and 3074 authors are disagreeing, and who got it right”.
• Notes on the Account Abstraction roadmap.
• A talk, “Account Abstraction for a Private Network” by Palla.