Aztec achieves Noir alignment

Today Aztec Labs is proud to announce that Aztec’s core circuits have been rewritten in Noir.

Aztec’s core circuits were previously written in C++. The circuits spanning private execution, public execution, and proof recursion are now in Noir. We didn’t undertake this decision lightly, but we made the call based on a single fact:

Writing circuits in Noir is simply better.

It was always our goal to achieve Aztec-Noir alignment, unifying our cryptography stack and making our code safer, simpler, and easier to audit.

We’re there now, in the era of unabashed Noir maximalism.

💻 You can find the open Noir circuit repos here.

The Noir circuits are merged and passing Aztec’s stringent protocol test suite–huge achievement for Noir as a language.

Why Noir at all? Why a DSL?

Writing your code in a domain-specific language (DSL) does not make it safer than writing it in a library.This may not be apparent – a DSL is just a language made for a specific problem. One could create a DSL that makes writing circuits easier, but does not improve on performance. One could even create one that makes writing circuits harder, but it’s very performant. Noir makes writing circuits easier and safer than our cpp library with little sacrifice to performance.

As a startup you want to be able to write code fast, but also safely. If you take too long to ship, you may just die. If you write code that is unsafe or brittle, you may lose the trust of your target audience.

We could say that all developers need to do better. Skill issue. However, this approach doesn’t scale beyond. Developers love to write smart, elegant, clever code, i.e. code that’s subject to bugs. In Noir, you need to opt into writing unsafe code.

The Barretenberg C++ Library

So what’s wrong with using Barretenberg as a C++ library?

Nothing.

In fact, a library inherits a lot of adoption from its host language; a Solidity library can be picked up quickly by Solidity developers, for example.

Aztec’s constraint system library is written in C++, and while this allows developers to do anything they want, it also allows developers to do anything they want.

Developers need to be aware of quirks with C++ whenever they use Barretenberg. This can lead to subtle bugs due to the inherent compounding of quirks specific to C++ and quirks specific to the library. In other words, more gotchas or footguns.

Library writers also need to be careful because in some places they are reasoning about constraints. In other places, they are reasoning about unconstrained code or non-constraint system code.

The overarching problem here is that in order to write safe circuits, you need to be able to write C++ code and also be a good circuit writer. These are two different skill sets that Noir reduces to one because Noir is specifically designed as a circuit writing language.

Making the Switch

In March, a team of cryptography engineers developed Aztec’s core cryptography circuits under the guidance of Aztec Labs CEO Zac Williamson. Developing in C++ required significant onboarding and technical overhead, including:

• Developing an embedded C++ DSL
• Dealing with the quirks of C++ plus the quirks of our embedded DSL
• Creating a Frankenstein workflow of CMake and custom build scripts

In the meantime, the Noir team has built a comprehensive toolchain that makes ZK development significantly smoother:

• Syntactic simplicity makes code easier to reason about
• Nargo provides convenient package management
• One-line CLI improves testing

In addition to developer tooling like performance profiling, syntax highlighting, and auto-formatting.

With Noir, we built the fast and safe DevEx we wanted for ourselves, resulting in a full rewrite of all Aztec core circuits from C++ to Noir in less than a month of three engineers’ time.

Here’s a side-by-side code snippet comparison of our private kernelbase rollup circuit in C++ and Noir, highlighting the legibility and simplicity of Noir.

C++:

Noir:

Why did we switch?

• Contributors: developers no longer need to know C++ to write circuits, meaning the number of developers who can now contribute to Aztec’s core circuits has doubled or tripled overnight
• Tooling: Noir tooling only needs to cater to writing circuits, whereas Barretenberg Library tooling will always take into consideration what is written in C++
• Stack integration: contracts on the Aztec network are also written in Noir, leading to tighter integration
• Better optimizations: updates to Noir include new applications that are immediately applied to existing code

Noir Ecosystem

Finally, Aztec Labs gets to more fully participate in Noir’s vibrant ecosystem.

The community continues to develop new tooling that improves code analysis. Developers building in the Noir ecosystem and discovering bugs continuously battle-test the compiler. And Aztec is now fully aligned with the many developers building applications and protocols on Noir.

We too would like to share in the fruits of the Noir community.

Noir maximalism is open-source maximalism.

Build with us toward production

While Noir is still Beta software and isn’t fully production-ready until it is audited, the language is progressing towards an implementation freeze by the first half of 2024, and a completed audit by the back half of the year.

🏗️ Start building with Noir at noir-lang.org.

Next stop: insane crypto

In addition to basic optimizations required for the kernel circuit to run on low-powered mobile devices, we intend on integrating Noir with the arsenal of novel cryptography in our development pipeline:

• Honk: our next-generation proving system
• Protogalaxy: super-fast folding
• Goblin Honk: super-fast recursion
• Super low-memory proving

Building Aztec in Noir has been a long time coming.

As a result of adapting our core circuits to Noir, testing a wide array of features, and having Noir code pass extensive test suites, we have dramatically more confidence in its stability.

The collaborative approach between our internal Aztec and Noir teams demonstrates a commitment to advancing the capabilities of zero-knowledge proof technologies in an integrated fashion.

Improving Noir now improves Aztec.

Now is the time to Noir

The truth of the matter is: you cannot escape potentially dangerous code.

You can still write unsafe code in Noir.

You can only move the responsibility of writing dangerous code to folks who are least likely to make a mistake. And with Noir, you make it Aztec Labs engineers’ responsibility to write compiler code and optimizations. And with our stack, we make it the cryptographers’ responsibility to write absolutely unhinged cryptographic proving systems.

You are free to rebuild all of this yourself in C++. But Noir makes it so you don’t need to.

Where we cannot help you is unsafe business logic. If your application was meant to choose a random number between 1 and 10 and it instead chooses a random number between 0 and 1, then that’s on you.

But that’s as it should be! That’s the sort of code that you should be responsible for, and Noir aims to make it such that that’s the only thing you are responsible for.

If that sounds good to you, you might consider making the switch, as we have.

⭐ Get started with Noir today at noir-lang.org.

Today we’re releasing NoirJS– a Javascript package for Noir developers who want to build real applications that generate zero knowledge proofs in the browser.

Web development within the Noir ecosystem has historically been, uhm, complex. Practically, that meant Noir developers couldn’t really build applications that ran in the browser. And we want people to build applications with our software!

Y u no browser

A browser is an application used to access the World Wide Web and interact with Internet applications. It turns out most people like using browsers.

Before today, Noir didn’t really let you build applications that could run in-browser. Instead, developers were forced to run applications locally in a CLI.

In simple terms, that meant Noir couldn’t actually support real applications.

But now Noir does support applications with NoirJS.

The goals of NoirJS are simple:

• enable Noir applications to work in web browsers
• simplify package management
• improve DevEx from “oh God” to “oh good”

Reminder on what Noir is

Noir is a zero knowledge circuit-writing language that works with multiple crypto proving back-ends. That means the front-end (the language) remains the same but Noir can be modularized to support the latest and greatest in zero knowledge proving research.

We do this through the ACIR (abstract circuit intermediate representation). Learn more about the ACIR here.

NoirJS lets developers build around the core concept of client-side compute: the ability to harness user hardware–phones, laptops, tablets–through the browser in order to compute proofs of execution.

And client-side compute in turn allows for fully private and trustless blockchain systems.

…sound familiar??

That’s the core philosophy of Aztec–giving developers the tools to develop programs with private data and compute while remaining fully trustless.

• Users download encrypted data
• They decrypt and manipulate the data locally (unbeknownst to anyone else)
• They furnish a proof of computational correctness
• They submit the proof

In English: do blockchain things without anyone knowing! Cool, right?

And for developers’ convenience, NoirJS is packaged with Barretenberg–the same Plonkish backend used by Aztec Labs in the Aztec rollup. No need to go shopping for a proving system unless you like, really want to.

Quality of Life Improvements

NoirJS does a lot of other things, too! Developers were previously burdened by the need to manage multiple components like `bb.js`, `acvm`, `noirc_abi`, and future components like `noir_wasm`.

But managing component libraries and balancing version compatibility is not our idea of fun.

To install NoirJS you simply run `npm i @noir-lang/noir_js` in your Javascript directory

Install your proving backend of choice (ahem, probably Barretenberg), and you’re good to go.

NoirJS handles all Noir dependencies, exposing them through one clean interface, allowing you to focus on building rather than fiddling with packages.

Here are some other advantages:

Immediate Access: Browser-based applications don’t require additional software, making it easier for developers to reach a wider audience.

Improved User Experience: By enabling Noir functionality in the browser, users can interact with applications in real-time. That means fast apps.

Enhanced Security: Operating in the browser allows for client-side cryptography, offering an additional layer of security for applications that require cryptographic proofs.

Developer Flexibility: NoirJS enables developers to build rich, client-side applications with cryptographic functions, providing a broader toolkit for web development.

Community Building: Browser-based Noir enables rapid prototyping and sharing among the developer community. This is especially useful for teams who focus on in-browser applications and use-cases.

In-Browser Tooling: NoirJS fits seamlessly with in-browser IDEs like VSCode for web, allowing for a streamlined development process in which Noir programs can be compiled and proven directly in the browser.

So to summarize, by bringing Noir to the browser, we’re:

• simplifying development
• expanding the scope and capabilities of what can be built with Noir

Siiick.

Use-Cases and Applications

Less development pain means more time for building new applications. Here are some use-cases we’re excited to see:

• Pseudonymous identity web apps: Projects like Noxx are focused on building pseudonymous identity web apps.
• In-browser ZK games: Tonk.gg's NES emulator Dappicom can now incorporate Noir functionalities seamlessly.
• Proof of solvency: prove solvency or liquidity without exposing the underlying assets or trades
• On-chain poker: play poker with its hidden card dynamics without a trusted third party
• zkEmail: decentralized e-mail with no trusted servers

Conclusion

NoirJS lets you build real Noir applications that run in the browser. It also makes your life easy breezy beautiful CoverGirl.

If you don’t know what Noir is, read this announcement, scan these docs, and watch this video.

If you do know what Noir is, install NoirJS right now. Right now. Right now.

And if you end up building something cool, come ask us for money.

When we compute a ZK circuit we are not just executing some code, but proving that we have executed the code correctly.

Take a program that computes x + y = z. It’s not enough for a ZK program to simply output z, the program also needs to prove that x + y was executed correctly to arrive at the value z.

Producing the proof requires establishing constraints.

In other words, circuits are comprised of constrained functions–meaning ZK programs that generate proofs based on a set of constraints.

So why then, would you need a function with no constraints–an unconstrained function? You might think unconstrained functions would be unsafe, given their name–like taking the guardrails off of a ZK circuit. And you’d be right!

Circuit code without constraints can be “proven” to create any outcome! Rather than creating a proof that deterministically proves the validity of a piece of code, unconstrained functions allow you to execute code that would otherwise be very expensive or difficult to compute inside the circuit.

But being able to execute logic outside of a circuit is critical for both circuit performance and constructing proofs on information that is external to a circuit.

When to use

Generally, we want to use unconstrained functions whenever there's something that's easy to verify but hard to compute within the circuit.

An unconstrained function simply executes code as you would expect in a normal programming execution environment.

In this post we want to make sure that developers who are tapping into the performance benefits of unconstrained functions aren’t incorrectly implementing unconstrained functions in a way that leads to worse security for their programs. Incorrect usage of unconstrained functions could lead to bugs, and zk development overall is a newer, scarier paradigm. We want to make it easy for developers to use Noir to write performant and secure ZK programs, and unconstrained functions can help them optimize their circuits when implemented correctly.

Simple division

Assuming proving divisions in ZK is costly while proving multiplications is easy, and we want to prove the computation of 100 / 5.

Proving 100 / 5 = x directly in ZK would be inefficient:

Instead, we might use unconstrained functions to optimize our circuits. A more optimized approach would involve:

1. Computing 100 / 5 = x in an unconstrained manner

2. Proving x * 5 = 100 in ZK

Here’s a way to optimize the same division operation:

Cautious readers however might notice both the code excerpts above yield approximately the same number of constraints in Noir’s abstract circuit intermediate representation (ACIR) given the optimization is simple enough to implement in Noir’s compiler.

The key intuition here is that in a ZK execution environment, proving multiplications is cheaper than proving divisions.

Given all Noir programs compile to an intermediate representation called the Abstract Circuit Intermediate Representation (ACIR), we can judge circuit optimization on both ACIR opcodes and the ultimate number of backend circuit gates.

This simple division case has 2 ACIR opcodes and 7 final backend circuit gates. The unoptimized version where we check assert(x == 20) has 3 ACIR opcodes and 8 final backend circuit sizes. Our optimization reduced the final backend size by one gate. Given this is a super simple example, let’s dive into a more complex case where the optimizations are more meaningful.

A more complex example

Colin Nielsen, developer in the Noir community wrote the following code for converting unsigned integers (uints) to u8 arrays, without the use of unconstrained functions.

👀 See Colin's Twitter + Github

Here's the unoptimized code:

This code has 91 total ACIR opcodes and a circuit size of 3,619. A lot of the operations in this function are already optimized away by the compiler (e.g., all the bitshifts turn into divisions by constants).

However, we can save a bunch of gates by casting to u8 a bit earlier. This automatically truncates the bitshifted value to fit in a u8, which allows us to remove the XOR against 0xff.

This is what the slightly-optimized code looks like:

ACIR opcodes generated: 75

Backend circuit size: 3,143

Already, this saves us ~480 gates in total, but we can do better.

This code is all constrained, so we're proving every step of the calculation using num. But in fact, we don't actually care about how we make the calculation, just that the computation is correct.

This is where unconstrained functions come in.

Optimizing with unconstrained functions

It turns out that truncating a u72 into a u8 is hard to do inside of a SNARK. Each time we do this operation to truncate down into u8, we lay down 4 ACIR opcodes, which get converted into multiple gates.

It's actually much easier to calculate num from out, rather than the other way around. All we need to do is multiply each element of out by a constant and add them all together, both of which are relatively easy operations to do inside of a SNARK.

So, instead of truncating u72 into u8, we can run u72_to_u8 as unconstrained function code in order to calculate out. Then, we can use that result in our constrained function and assert that if we were to do the reverse calculation, we'd get back num.

An example of what this looks like is below:

Total ACIR opcodes generated: 78

Backend circuit size: 2,902

This usage of unconstrained functions ends up optimizing our circuit even further and taking off another ~250 gates from our circuit!

We've ended up with more ACIR opcodes than before, but these are easier for the backend to prove (resulting in fewer gates overall). This is the beauty of using unconstrained functions – optimizing code that’s easy to verify but hard to compute within the circuit.

Put differently, unconstrained functions allow you to reformulate certain pieces of code that are easier to check than to execute directly in a ZK circuit.

Resources
‍For more on unconstrained functions, see this post by Tom French in the official Noir docs: https://noir-lang.org/docs/noir/concepts/unconstrained

Are you a developer interested in getting started with Noir?

Jump into the noir-starter Github repo and when you’re ready apply for a Grant–we’re currently supporting Noir use-cases through the end of 2023.

We’ve all heard that “privacy UX sucks.” We tend to agree.

Users want to drive a car, not change the oil. We previously discussed how we abstract Aztec’s underlying UTXO architecture with Noir Lang and Aztec.nr, Aztec’s smart contract framework.

Today we’ll cover how we improve transaction processing via account abstraction and composable public-private design.

To date, protocols focusing on user privacy have exposed the underlying privacy architecture. And it turns out that users don’t like dealing with the nuts and bolts inside the machine.

We think user-friendly abstractions represent the future of intuitive UX in blockchains–a necessary step to bringing crypto to parity with web2. We’ll define transaction paths, explain what they mean, and explore how they future-proof the Aztec experience for developers and users.

Ethereum Accounts, A Primer

In Ethereum, every account is controlled by a private key, commonly derived from a mnemonic. If you’ve ever created an Ethereum wallet, you’ve seen the list of words you need to engrave, memorize, or at minimum jot down to secure your account.

Note that we’re talking about Ethereum externally-owned accounts here (EOA’s), not contract accounts, since on Ethereum, EOA’s are the only accounts that can initiate transactions.

When you initiate a transaction on Ethereum, the network expects a signature from the private key that controls the account. If you create a signature that matches the public key associated with the transaction, the transaction is submitted with a transaction payload that instructs the Ethereum Virtual Machine on exactly what functions to execute.

Account Abstraction, aka “Seed Phrases Ain’t It, Chief”

At Aztec Labs we’ve been thinking hard about forms of account authentication beyond signatures. The use of seed phrases has significant issues:

• No recovery: if you lose your phrase you may lose access to your account forever
• Confusing hygiene: you should never, ever, ever copy your phrase to your computer’s clipboard using the copy and paste feature
• Single point of failure: anyone who has your key has full access to your account

📕 Read this post by Santiago Palladino for more about the account abstraction designs being developed for Aztec on our Discourse forum

So how do we get around seed phrases and private keys as the sole forms of account validation? Seed phrases are just one very secure but very flawed form of account validation. There are myriad methods of account validation, spanning the spectrum from very secure to totally insecure, from intuitive to confusing, including but not limited to:

• Key sharding
• Plaintext passwords
• TouchID and other biometric signature schemes

Keep in mind account validation can be as secure as you want it to be. One simple account validation scheme would be: “If you click the ‘yes’ button the account is validated.” It wouldn’t be secure AT ALL, but you could do it!

Account abstraction is confusing as a term, since it encompasses “everything but seed phrases,” but the holy grail of authentication would include three factors:

• Something you know (like a password)
• Something you have (like a hardware wallet or Yubi Key)
• Something you are (like biometrics or a decentralized proof of identity scheme)

Aztec allows for combining all three.

But Aztec’s improvements to Ethereum go beyond the implementation of alternate authentication schemes.

Aztec’s transaction anatomy is also a bit different — users send proofs of computation rather than signing transactions from an EOA.

Here is the flow diagram for an Aztec transaction:

• User connects wallet to app
• User expresses transaction intent
• App supplies transaction info to wallet
• Wallet executes function
• Prove account interaction
• Prove function
• Wallet generates kernel proof
• App receives kernel proof
• Wallet broadcasts transaction to network
• Aztec node includes transaction in rollup block
• Ethereum finalizes L1 block

We’ll talk through each in turn.

Anatomy of a private Aztec transaction

Before we carve the patient open and look at its guts, know that there are two transaction paths within Aztec: private transactions and public transactions, each with their own attributes.

At the center of these transactions is something called the kernel circuit. The kernel circuit is the beating heart of the Aztec system, and validates private transactions. We’ll get back to it in a second.

For now let’s talk about what a blockchain transaction in general is:

1. Authorization: typically a signature, but as we’ll see can be many things
2. Intent: typically a transaction payload that includes instructions such as FROM, RECIPIENT, SIGNATURE, and fee information

We already discussed how Aztec allows for new forms of authorization, but how does it process transactions?

Aztec is a completely new execution environment beyond the EVM, and uses client-based zero knowledge proofs to prove individual transactions. That means the application developer’s job is to constrain functions appropriately and prove user intent.

Application developers can constrain user intents by writing smart contracts using Aztec.nr. In the private transfer example, the circuits behind the smart contract are checking a few conditions:

• Does the user own >10 DAI?
• If so, destroy 10 DAI of their notes by creating nullifiers against them
• Create a new 10 DAI note for the transfer recipient
• Broadcast and encrypt the message containing the 10 DAI note

The nullifier, new note, an encrypted log are all made public, but kept encrypted, such that the public information tells you nothing about what happened. Roughly all an observer can see is “a transaction happened here but I’m not sure what.”

That’s the core of Aztec’s value proposition — we know with mathematical certainty transactions are happening that follow blockchain rules, but we can’t derive any information about those transactions.

📕 See our previous piece on how Aztec’s privacy abstraction works

Public Transactions

The path for public transactions is slightly different, as Aztec relies on the familiar Ethereum account-based model for public transactions.

The key to Aztec’s public transactions are unconstrained functions–Aztec’s public VM bytecode. Unconstrained functions just do “normal code stuff.” And by “normal code stuff” we mean simply execution code rather than proving execution as in Aztec’s private execution path. Unconstrained functions don’t lay down constraints. They just executes code.

If Aztec is a world computer, then unconstrained functions are the instructions the computer understands. Just like the EVM executes Solidity, the Aztec VM executes Aztec bytecode.

One key difference between the private and public execution paths is when code gets executed. In the private transaction example, code must be executed and proven locally–that is, before proof of the transaction is sent to Aztec’s network of nodes.

In the public execution path, the wallet has to receive authorization, but doesn’t process the transaction, instead sending transaction details onward to an Aztec node which then creates a proof of execution and inserts the proof into a block.

Because privacy is no longer a concern with public transactions, they can be sent unencrypted to the node to do efficient batch processing, rather than relying on a user’s local device.

Conclusion

Privacy UX sucks. Zero knowledge is complicated. Our goal is two-fold:

• Simplify DevEx with tools like Aztec.nr — a smart contract framework that makes it intuitive to reason about private state management
• Simplify UX with abstractions that help users access the blockchain with better tools than EOA signature validation

Great privacy-first applications will be built on the backs of best-in-class tooling that makes it easy to build powerful software that makes preserving privacy smooth and intuitive for users.

That means more code, less cryptography.

Keep in touch

To learn more about Aztec generally, keep up to date on our Discourse, where we discuss major protocol decisions like upgrade mechanisms and decentralizing sequencers.

For more technical news on Aztec and Noir, join our e-mail newsletter:

📬 Subscribe here to the Aztec Labs Developer Dispatch, the latest news and releases about Aztec and Noir

Join our team

Aztec Labs is on the lookout for talented engineers, cryptographers, and business people to accelerate our vision of encrypted Ethereum.

👪 If joining our mission to bring scalable privacy to Ethereum excites you, check out our open roles.

And continue the conversation with us on Twitter.

Acknowledgements

Thank you to Bruno Lulinsky and Maddiaa for input on this piece.