*Special thanks to [Zac](https://twitter.com/Zac_Aztec), [Josh](https://twitter.com/critesjosh_), [Cooper](https://twitter.com/cooper_kunz) and [Bruno](https://twitter.com/Blulinski) from the [Aztec](https://twitter.com/aztecnetwork) team for their valuable feedback and reviews.*

## What is Noir?
Noir is a domain-specific language (DSL) for zero-knowledge (ZK) programming, released in October 2022. It is a generalized ZK programming language that exposes a high-level programming language with syntax similar to Rust. The language compiles down to ZK circuits but is deliberately platform agnostic.

Noir is not specific to Aztec or PLONK, and it is an open-source project that aims to be used by as many people as possible. Aztec Labs and the community wanted to create a generalized ZK programming language that anyone could use, regardless of the platform they were using.

The goal is to make Noir an open-source public good, where anyone can use it and build their backends and front ends, even if it doesn't touch any other Aztec system. A Layer 2 (L2) that recreates the smart contract ecosystem that Ethereum has, but as a L2 where the private state is a first-class default primitive. This means that things become private by default, and as a developer, you can easily include private data in your program logic. However, this requires a lot of disparate components to work, such as an exceptionally fast zk proving system. This architecture enables all this and a language to program these contracts.

Noir now has an official reference repository called [Noir-Starter](https://github.com/noir-lang/noir-starter), which is a full-stack project using Next.js and Hardhat and serves as the perfect starting point for anyone who wants to dive into Noir development.

## How does Noir work?
Instead of compiling to circuits or constraints, Noir compiles to an intermediate representation called Abstract Circuit Intermediate Representation (ACIR). The idea is that once you have an ACIR program, you can convert it into constraints for any cryptography backend that you like. This is similar to how computer programming languages are constructed, where you have a language front end and a language backend. The front end, in this case, is Noir, which has its own Rust-like syntax that compiles programs to the ACIR representation. The backend takes the ACIR and turns it into machine code for a specific computer architecture. This approach allows a program to be written once and compiled into different CPU architectures. Noir's goal is to be a generalized ZK programming language that anyone can use, regardless of the platform they are using.

While Circom is doing something similar, it is a bit more integrated and less abstract than Noir. Circom has an R1CS backend and a PLONK backend, but they are tightly integrated into the language itself. In contrast, Noir's intermediate representation allows for more modularity and flexibility. Noir's backend can take the ACIR and turn it into R1CS constraints or PLONKish constraints, which can then be compiled into a PLONK circuit. While it is possible to use Noir in the Miden error context, it may not be the fastest option since it involves converting the IR for Noir into Polygon Miden Assembly, another form of IR.

## Noir and Aztec
Noir is designed to be the smart contract programming language for Aztec to expand the developer ecosystem for Noir as a whole. Noir is being developed as a general-purpose language that can leverage SNARKs or STARKs to simplify writing ZK programs. While lower-level ZK programming languages like Circom require understanding cryptographic concepts, Noir allows you to write code without creating circuits. A larger developer ecosystem benefits Aztec, increasing the pool of developers who could create Aztec programs and smart contracts.

The release of Noir being used would contain either an integrated Arkworks backend, an Aztec backend, or a GNARK backend. There would be a toolchain available for this purpose. For the Aztec backend, the toolchain would allow you to compile Noir, which would then be turned into a proving key/verification key. Making proofs is relatively straightforward, and a JavaScript wrapper exists around it all. This means that if you are building a front-end website that uses Noir and the user needs to make a Noir proof, you can do that by making JavaScript calls.

At least once the necessary functionality is added to Noir, it will be possible to define a contract as a set of public functions and private functions. Public functions have the ability to alter the public state, which is akin to the state found in a Solidity contract, encompassing variables, mappings, and other related elements. This state will be part of the L2 state database. The new private functions will modify the private state, which will also be part of the rollup but will be encrypted.

## Optional: PLONK
PLONK, introduced in 2019, was a significant milestone in the world of cryptography. The team behind the original Aztec protocol faced a significant challenge during development, but the team spent most of 2019 researching ZK SNARKS to create a universal SNARK. PLONK permits, at most, one trusted setup for the entire cryptosystem, eliminating the need for additional trusted configurations. Since its introduction, PLONK has become an extensively used tool in the world of cryptography.

PLONK has significantly improved to enable private smart contracts, a vital driving force behind Aztec. While PLONK is a valuable tool, it's not sufficient on its own, and more speed and power are needed to make things faster. Over the last several years, many people in this space have been working to improve PLONK by adding lookup tables and custom gates, creating new variants like Turbo-PLONK and Ultra-PLONK. Another development that has changed the game is the introduction of HyperPlonk by Bedenikt and Ben from Espresso Systems.

## Interaction of Contracts with Private State in Aztec
One question arises whether each contract has a unique way of interacting with private state. Keeping track of the state may seem challenging when a part is private and stored as a blob of data without any account system. However, Aztec has a private state store to construct Noir proofs or simulations. The Noir intermediate representation includes state read and write opcodes, and when these opcodes are executed into constraints, requests are sent to the private state store to retrieve information. The private state store has its own permission security rules to determine whether to grant access to the requested information. Therefore, even though the state is private, the Noir contract can still retrieve data from it, subject to the security rules of the private state store.

## UTXO for Private State in Aztec
The private state will use similar abstractions that Zcash use, where there is a UTXO set on switch transaction objects and nullify set. When encrypted data is added to the UTXO set, it can be effectively deleted by adding its nullify to another nullify set. Unless the decryption keys are available, it is not possible to link a nullify to a UTXO. Therefore, if a UTXO is deleted, only the deleter will know about it.

The representation of the state as a UTXO is highly abstract, as the protocol level does not concern itself with the state it encodes. The values and identities are not known or cared about. It is simply 64 bytes of information, similar to a storage slot in Ethereum. The written Noir contract defines the rules for when the state changes, how it is encoded, and how it changes. For instance, a private token contract can be written using a combination of these private and public functions. The concept is that these functions are converted into SNARK verification keys. A contract on Aztec is defined as the set of SNARK verification keys that correspond to all of the functions of that contract. These keys are stored in a Merkle tree.

## Contracts Merkle Tree and Kernel SNARK
The contracts Merkle tree in L2 state databases allows for a representation of the contracts. Each contract leaf in the Merkle tree contains all the verification keys for the functions which uniquely define the contract. When sending a transaction on the Aztec network, a proof must be constructed over the kernel SNARK using the Zexe nomenclature. This approach is derived from XXI and is used to extract a verification key from the contracts tree that is being requested.

The user provides proof for the correctness of that function call, which is recursively verified by the kernel circuit. The kernel circuit extracts the public inputs from that SNARK circuit and interprets them based on a contract ABI. The kernel SNARK's role is to verify the validity of all public inputs to ensure that the user is not presenting an incorrect chain state. Basically, some public inputs represent chain state, while others represent state updates that the user is trying to make. The kernel SNARK's job is to check the validity of all of these inputs to ensure that the user is not presenting an incorrect chain state or trying to make state reads that don't exist.

## Recursion and Composability
To achieve composability between multiple contracts in a zk-SNARK world with privacy-preserving properties, it is necessary to add recursions. The kernel circuit contains two data structures, which are arrays or vectors: private function calls and public function calls. When starting a transaction, the private function call stack has one item on it; the contract is called. However, once the kernel circuit is processing that function call, the function call can instruct the kernel circuit to add more function calls to the functional stack.

The kernel circuit is a requester structure that verifies a previous iteration of a kernel circuit proof; if one exists, it pops a function call off the function call stack, processes it, and conditionally adds more function calls onto the function call stack if required. By iteratively computing kernel circuit proofs, the user can eventually wind their way down to have an empty private function call stack. At that point, the proof is ready to be sent to a sequencer to be aggregated into the rollup block.

<!--- One kernel proof represents the correct execution of a private function. However, in the case of multiple function calls to different contracts, composability is required to ensure privacy-preserving properties. This is where recursion comes into play. The kernel circuit contains two data structures: private function calls and public function calls. The private function call stack has one item on it, the contract being called, but once it's processing that function call, one of the results can be that the function call instructs the kernel circuit to add more function calls to the functional stack. By iteratively computing kernel circuit proofs, the user can eventually wind their way down to have an empty private function call stack. At that point, the proof is ready to be sent to a sequencer to be aggregated into the roll-up block.

The kernel circuit is responsible for verifying the correctness of function proofs, which is a SNARK circuiting a SNARK circuit. If a transaction consists of more than one private function, then the user has to repeatedly compute kernel circuit proof square at each iteration. The kernel circuit is verifying a proof of the kernel circuit at the previous layer, which is another layer of recursion. -->

## zkEVM and Aztec
Aztec Labs has concluded that privacy is not compatible with the EVM. In my opinion, this conclusion is a controversial and debated topic. The enshrinement of type 1 zkEVM is always necessary because it can be easily integrated on top of the current Ethereum and EVM or as a rollup whenever required. Teams such as Taiko, Privacy and Scaling Explorations (PSE) team, and the Scroll team have been doing great work so far. Aztec Labs didn't build any type of zkEVM.

Public account-based blockchain models like Ethereum cannot natively support privacy, while UTXO-based privacy solutions cannot accommodate the wide range of applications and tools created for public smart contract platforms. However, Aztec's integration of public and private execution enables seamless composability between encrypted and unencrypted transactions. While Ethereum's innovation was enabling read and write access to public state, Aztec's innovation lies in its ability to read and write to both public and private state. As a result, Aztec's private state portion is UTXO-based, while the public state portion resembles 'vanilla' Ethereum.

## Aztec's Supply Chain
Stakeholders will have the opportunity to operate Aztec sequencers, provers, or nodes, each of whom plays a vital part in running the network and keeping it trustless, reliable, and censorship-resistant. Sequencers process and construct blocks for submission to Layer 1. Sequencers then send blocks to a decentralised network of provers. Provers then split the 16,348 individual transactions comprising an Aztec block into trees of proofs 14 deep. They then “split up” the task of proving individual transactions, working together to construct the full Merkle tree, which builds up a finalised Aztec block. Finally, Aztec nodes provide chain data, syncing chain state, responding to RPC queries, and propagating transactions.

Additionally, Aztec has taken a major step towards decentralization by issuing an [open request](https://discourse.aztec.network/t/request-for-proposals-decentralized-sequencer-selection/350) for proposals for their decentralized sequencer design. This effort covers not only the codebase but also the ideation and product development process, demonstrating Aztec's commitment to transparency and collaboration. By inviting experts to scrutinize their solution, Aztec is investing in the technical community while ensuring a robust implementation.

## Aztec Connect: A Trial Run for Aztec
Aztec Connect has been sunsetted. It was a trial run for Aztec. At the time, the technology was not advanced enough to enable general-purpose programmability, but the team had the technology to produce a zk-rollup. Therefore, the objective of Aztec Connect was to demonstrate the usefulness of privacy on-chain.

## Aztec Mainnet and Testnet
The Aztec team is working diligently towards launching the mainnet by the end of 2024. Aztec Labs aims to release a local developer testnet by Q3 2023. This will enable developers to deploy the Aztec network to their local machines, write Noir contracts, deploy them to the local network, test them, and run them. However, this local testnet will not have provers enabled. The objective is to showcase the intended method of interacting with the chain, including how to write and deploy contracts. The aim is to provide users and developers with a seamless developer experience and gather feedback on how it works. Later, when the testnet is launched, the technology will be integrated. The development is being done in parallel, which will allow for the refinement of the approach and ensure that everything runs smoothly.

## What is next for Aztec?
In conclusion, the development of Aztec is now an execution problem. PLONK technologies are more than the demands of the current use cases. However, significant challenges still need to be addressed, such as building decentralised sequencers, provers and addressing unique challenges that arise when privacy is involved. These challenges require changes to the architectures of how sequences and provers are coordinated, and much complexity is involved in network engineering, critical engineering, and second building. Despite these challenges, the Aztec team is committed to launching the public testnet by the beginning of 2024, with a local developer testnet planned for Q3 2023. The team's dedication and hard work will undoubtedly pay off, and we can expect Aztec to be a groundbreaking development in the world of privacy-focused blockchain technology.

## Let’s talk
Thank you for taking the time to read my blog post. If you have any questions or comments, please don't hesitate to reach out to me. I would love to hear your thoughts and engage in a conversation with you.

* [Twitter](https://twitter.com/erayajk)
* [Website](https://erayack.github.io/)

## Further Readings and Resources
* https://discourse.aztec.network/
* https://medium.com/aztec-protocol/introducing-noir-the-universal-language-of-zero-knowledge-ff43f38d86d9
* https://discourse.aztec.network/t/request-for-proposals-decentralized-sequencer-selection/350
* https://medium.com/aztec-protocol/aztec-the-hybrid-zkrollup-a90a197bf22e
* https://docs.aztec.network/
https://github.com/noir-lang/awesome-noir
* https://medium.com/aztec-protocol/sunsetting-aztec-connect-a786edce5cae
* https://twitter.com/erayajk/status/1659531392915496963
* https://discourse.aztec.network/t/understanding-the-technical-aspects-of-aztec-and-noir/452
* https://noir-lang.org
* https://docs.aztec.network/aztec/milestones