Skip to content

Latest commit

 

History

History
149 lines (85 loc) · 13.4 KB

content.md

File metadata and controls

149 lines (85 loc) · 13.4 KB

Aztec Network: Zero to One!

In the burgeoning landscape of Layer 2 scaling solutions within the Ethereum ecosystem, an overarching emphasis has been directed towards enhancing scalability. This prevailing trend is particularly pronounced in the case of most of the Zero-Knowledge Rollups (ZK-Rollups) and Optimistic Rollups. Amidst this surge, there is a rollup in the town that focuses on the another most important, yet often overlooked, facet: PRIVACY.

do_we_have_privacy

While the majority of L2 solutions predominantly concentrate on optimizing transaction throughput and reducing fees, a notable alternative arises in the form of a privacy-centric rollup. This seeks to address privacy concerns associated with on-chain transactions. In contrast to scalability-centric solutions, where the primary goal is to process a higher volume of transactions efficiently, privacy-oriented rollups prioritize the confidentiality and anonymity of user activities on the blockchain.

Aztec is the privacy-preserving zk-rollup which aims at privatizing the user interactions using some amazing components which are in tandem help achieve the objectives of Aztec Network. We will see those components in a sufficiently detailed manner to help devs develop/build on top of Aztec Network.

we_have_aztec

Why Aztec?

Public blockchains were primarily invented to transact (whether financial or non-financial) in permissionless, trustless, decentralised, and most importantly in transparent manner. But, the transparent nature of public blockchains seems to navigating back to the cruel world from which the Bitcoin, as invented by Satoshi Nakamoto, and other blockchains followed by it are primarily intended to free us. Many blockchain analytics companies are there today to surveil the user interactions. Infact, it is absolutely possible to trace back the user's real world identity because every user gets onboarded to crypto using a centralized exchange. These analytics companies make use of this and do massive analysis of the open blockchain data and provide services to governments, and other interested parties.

As most user interactions are happening on Ethereum($2.5 Trillions in volume as of March 2024), it becomes the choke point for surveilling the mass amount of people. This is what Aztec tries to solve with its rollup technology.

Architectural deep dive

Aztec in and itself has several groundbreaking stuffs that are worth exploring to stamp the principle of anonymity (not just pseudonomity) in the blockchain world.

Lets just take a look at the big picture of Aztec Network before looking into them individually.

Hybrid State Model

Lets talk about functions in a nutshell. A function takes in some arguments and updates the state.

$$f(state, x1, x2, ..,x_n)\ ->\ state'$$

For eg., when a transfer function is invoked, it takes in inputs (from, to, value) and updates the state by incrementing recepient.balance and decrementing sender.balance.

eth_transfer

When these state transition functions are public, there is no way to anonymously update the state. Aztec solves this by decoupling the private and public funtion calls, making a hybrid state model.

Private functions are called by users whereas public functions are called by sequencers.

What does this mean??

It means now we can separate the private and the public state. Users account details are usually the private state.

UTXO and Nullifiers

Lets think ourselves as to how we can proceed about building a privacy preserving zk-rollup. We will start from account. Ethereum uses account based model which is EOA. Whenever a user transfers ETH, the user balance is decremented and the the recepient balance is incremented. Both of their balances are public. In order to achieve privacy, how can we do this increment/decrement operation in an anonymous manner? Well, you just can't. If the user and the receipient perform these operations locally, there is no way to verify it. If they are perfomed onchain, then it is open to everyone as ethereum maintains the public state trie.

do_we_have_privacy

Enter Nullifiers!

Nullifier is a value used to nullify a certain other value. Not a good definition but it just explains its purpose.

Lets say you have a $Note$ which can be used to spend upto 1ETH. Now, you are transferring 1ETH to a Defi protocol. And you have a $Note\ Commitment$ in the $Note\ commitment\ tree$ (we will talk about this later). You store the note commitment in the tree and not the plain note for maintaining privacy. To invalidate the note that you have spent in the Defi protocol, you add $Nullifier$ in the Nullifier tree which is1,

$$Nullifier = Hash(Note Commitment, secret key)$$

By adding this $Nullifier$ in the $Nullifier\ tree$, you basically nullify the note. Nice, but how double spending is avoided here? If you attempt to spend the note again, you will again have to create the $Nullifier$. The computed nullifier is added to the $Nullifier\ tree$ only if there is no nullifier of the same value in the tree. That is, only if non membership check is achieved, you can spend the note which is impossible if you try to spend it twice. $$ \boxed{UTXO \text{ is accepted only if } Nullifier_{UTXO} \notin Nullifier Tree}$$

utxo_vs_account

PXE

Now we have ascertained a way to update the state in an anonymous manner. Next question is where that happens? Like, you cannot request a node or a sequencer to update the private state by giving out your account data. That is just where we were before. You can't reap the benefits of the UTXO and Nullifiers duo in that case. We need a local user environment to do the private state transition.

This is why we have Private Execution Environment(PXE). PXE is where the private functions, and private state changes are executed. PXE can be either on server side or on client side. Aztec Network wallets will have an instance of PXE to perform client side operations on behalf. You can find the functionalities of PXE here. Now, we will deconstruct the PXE to understand it more.

pxe
  • ACIR Simulator: This is responsible for simulating the transaction (private part of it) and generating partial witness (private inputs) and public inputs for private kernel circuits. It spins up an ACVM (Abstract Circuit Virtual Machine) for each function.

  • Private Kernel Circuit: This is responsible for generating the proof of execution of each private function recursively i.e., it verifies the previous function execution and generates proof for current function execution. This will end up with a single proof of whole private execution. This final proof is sent to the sequencer as you can see in the diagram above.

Here is the flow of how private kernel works:

kernel_private_circuit

ECDA signature, in the top of the flow, is when the user signs the transaction. First step of private kernel circuit is to verify that signature.

  • Database: When user initiates a transaction, the user's (private) state is loaded from user's local PXE.

  • Oracle: PXE also provides oracle functions for quering public data from a sequencer. Some oracle functions can be found here.

  • Synchroniser: Once the block (associated with the user transaction) is finalzied on L1, then the synchroniser updates the user's PXE Database based on that new block.

  • KeyStore: This is responsible for managing the user private keys.

Sequencer

As we all have seen, once the user locally runs and generates the proof of execution for private functions and are verified by kernel private circuit, a single proof of whole execution, public function requests, and public inputs (New note commitments, nullifiers) are forwaded to sequencer for creating a transaction.

Then public funtions are executed as requested by the PXE and the proofs of their execution are generated and verfied by kernel public circuit recursively as similar to kernel private circuit. Optionally, sequencer can delegate proof generation to prover network.

Generated proofs for each transaction are merged by Rollup circuits. It takes each transaction proof and generates a single proof in a 'binary tree of proofs' topology while performing state updates, commitments and nullifier insertions, and membership checks for every transaction. You can read more about this here.

Finally, the single proof (block proof) got submitted to L1 and is verified by the verifier contract in L1. In short, sequencers are just nodes with the capacity to create block proofs along with the block.

Here is the flow chart of a transaction lifecycle:

tx_lifecycle

Interesting ideas to build on Aztec!

Aztec Network with its inherent private state can be leveraged to build deep(complete privacy) anonymous protocols onchain. Some ideas are listed below;

Private DEX: A decentralized exchange which lets users exchange their assets in anonymous manner. Some existing projects: Shieldswap, AztecGravix.

Private Oracle: An oracle service which lets users anonymously query onchain/offchain data onchain. Look at Wonderland’s private oracle for example.

Wallet Infrastructure: Build a wallet that lets users make private function calls. Look at Aztec Snap for example. Build transaction simulation that will let an user identify the flow of transaction execution and the estimated gas.

Web2↔Web3 Bridge: Bring web2 accounts and credentials in anonymous manner enabling web2 identity onchain. Example: Wagmi lab’s proof of secret.

Verifiable location: Anonymously verify that a user is located within the authorized location to provide access using Wagmi lab’s proof of proximity.

Anonymous reputation system: Build a reputation platform that maintains a set of parameters that determine the reputation score and calculate users’ score using Wagmi lab’s proof of intersection.

Anonymous tracking: Privately track the individual users’ action and verify onchain. Example: Green Zktricity.

Anonymous voting: Build zk voting applications that will let users anonymously create and vote on proposals/polls. Example: Melo Cafe.

And, there are many more ideals and toolings available that you can look at here.

Conclusion

Aztec Network clearly distinguishes from other zk-rollups in every component of a rollup. They call it zk-zk rollup. Most of the ideas were inspired from ZCash protocol and Aztec is pretty happy to accept it. Its not only about who invents useful things. Its about who takes that and bring to the masses. Aztec is taking a hard path and looking to succeed in its mission. Huge applauds and respect to those who are willing to build on top of Aztec. Hail Aztec Ecosystem Devs!!

we_are_not_same

1. You can create nullifiers from hashing any values and not the ones mentioned in the example. That is, you can create custom nullifiers suited according to the case.