:warning: This post is outdated. For the latest block production design refer to this post. A protocol for random sequencer selection for the Aztec Network. Prior versions: Fernet 52 (Aug 2023) Sequencer Selection: Fernet (Jun 2023) Sequencer Selection: Fernet (Jun 2023, Forum) Introduction Fair Election Randomized Natively on Ethereum Trustlessly (Fernet) is a protocol for random sequencer selection. In each iteration, it relies on a VRF to assign a random score to each sequencer in order to rank them. The sequencer with the highest score can propose an ordering for transactions and the block they build upon, and then reveal its contents for the chain to advance under soft finality. Provers must then assemble a proof for this block and submit it to L1 for the block to be finalised.

Thanks to Roman, Franco, Florin @ Taceo, and Sean @Aztec for chatting about this with me this week, and for building a PoC. Taceo enables a network of MPC nodes M1, M2, M3 (currently 3) to collaboratively generate a zk-snark (aptly termed "co-SNARKs"). This unlocks two cool features, with the 2nd feature being the most exciting: Outsourcing proving. Generation of a zk-SNARK over a user's own private data can be outsourced to the MPC network without leaking the user's data. I.e. None of the MPC nodes learn anything about the user's underlying data (under anti-collusion assumptions). This is a potentially-faster alternative to client-side proving, depending on the user's hardware and their trust model. Private shared state. The MPC network can generate data that no one on earth knows (again, under anti-collusion assumptions). Furthermore, the MPC network can perform complex computations over that data (data that no one knows) and generate a zk-SNARK of having done so. This post won't go into the details of how co-SNARKs work; there are already good resources for that. This post talks about how co-SNARKs can enable private shared state on Aztec. Ok fine, a very brief ELI5 of co-SNARKs is: All data -- be it data that's been generated within the MPC network's circuits, or a user's private data that's been given to the MPC network -- is "secret-shared". Each MPC node gets a secret share of the data, meaning they don't have enough information to meaningfully interpret the underlying values being computed over. The MPC nodes can then generate a zk-SNARK over their secret-shared witnesses. They can then combine the results into a single "co-SNARK". The public inputs of this co-SNARK are useful, intelligible data that a co-SNARK verifier can interpret.

Let's go through a quick way to setup metrics using a local grafana/otel-lgtm backend. This particular dashboard is for testing purposes, and I hope it helps inspire better community submissions. If you have suggestions for metrics, please share in the discord! We're going to be following the tutorial from this grafana blog post Step 1: Pause your node If you're not already running a node then skip to step 2. If you are, this is a good time to stop your node. Step 2: Run the local grafana instance In your terminal, run:

Notation: The fold operation: Given a polynomial $h$ and $u\in F$ we define $$fold(h,u)= \bar{u} h_{even}+ u h_{odd},$$ where $\bar{u}=1-u$. Crucial relation: Given $r,u\in F$ and polynomial $h$, define $\alpha=h(r), \bar{\alpha}=h(-r)$ and $\beta = fold(h,u)(r^2)$. Then

We explain in this post how to think about and leverage the type of arithmetization used in PLONK. In its most general form, we refer to such an arithmetization as a Randomized Air with Preprocessing, RAP for short. However, in practice it will usually be convenient to work with restricted cases of RAPs, that we call turbo-Plonk and ultra-Plonk programs. We will explain all these terms! Our starting point is Algebraic Intermediate Representations - AIRs; this is the arithmetization used by STARKWARE. AIRs An AIR[^1] $P$ over a field $F$ has a length $n$, and width $w$. $P$ is defined by a set of constraint polynomials ${f_i}$ of a certain predefined degree $d$ in $2w$ variables. An execution trace $T$ for $P$ consists of $n$ vectors of length $w$ of elements of $F$, that we think of as "rows of width $w$". $T$ is valid, if substituting the $2w$ values from any two consecutive[^5] rows to any constraint polynomial $f_i$ evaluates to zero.

An external partner (who wishes to remain anonymous) did some work on note attestation. These are their notes: Contracts and frontend: https://github.com/AztecProtocol/token-partition-table Original Spec Reference: https://hackmd.io/O7RKI5lfQnqVVVKQYer75g Token The contract extends the normal token contract by adding a Partition table to each note.

Contents: Rahul's High level thoughts on how a good unit test framework could look. Notes for noir team on bugs/feature requests Rahul's High level thoughts on how a good unit test framework could look. ignore this section. It is just my ramblings and notes I wrote unit tests within the contract scope. Ref this file

Goblin Plonk: lazy recursive proof composition Introduction High level overview Recursion protocol Chapters Speeding up SNARKs with an Instruction Machine Aggregating Instruction Machine transcripts Processing IM Transcripts + curve transposition Non-Native Field Virtual Machine

Authors: Suyash and Arijit Disclaimer: This documentation was written on September, 2021. It is intended to give readers a high-level understanding. The codebase is the canonical source of truth, and over time this document might fall behind the implementation details of the code. Introductory Theory A Merkle tree provides a way to cryptographically commit to a set of values. Further, it allows proving membership of a particular value stored in the Merkle tree. A Merkle tree with depth $d$ allows storing upto $2^d$ values and the membership proofs are of size $\mathcal{O}(d)$. We start by hashing each value in the set, and then keep hashing our way up the tree in pairs until we get to the root node. Let us look at a simple example: suppose the set of the values we wish to commit to is $(f_0, f_1, \dots, f_7)$ and $H, H'$ are collision-resistant hash functions. Note that $H$ and $H'$ could be the same hash functions. The leaves of the tree are shown in yellow boxes while the nodes are shown in blue circles. The depth of the tree is equal to number of steps required to reach to the root node from the leaves. Here, the depth is $d=3$. :::success 💡 If each left and right node in a given pair is marked with $0$ and $1$ respectively, on tracing the path from $f_4$ to the root (shown as dotted path), we get a binary number $0b100 \equiv 4$, which is nothing but the index of the leaf $f_4$ in the tree!

Author: Zac (Aztec) image tags: recursion Similar document with diagram is here This book is a specification for a method of performing efficient recursive proof composition in Plonk/Honk/PlonkISH proof systems. The core technique involves using cycles of curves to avoid having to perform expensive non-native group arithmetic ala Halo2.

The goal of this specification is to enable users of shielded tokens to prove, in a permissionless manner, that their shielded tokens have not interacted with tokens present on a blacklist. Multiple blacklists are supported and the specification makes no restrictions on who can be a blacklist provider. Token contract changes Shield tagging Every shield interaction that generates a note will produce a unique shieldId: u32 value. i.e. a counter incrementing from 0. This is tracked by the token contract via a storage variable numShields: u32

:::info Author: Mike This note is PUBLIC, so Jay can read it :) ::: We're using the term "Note Discovery" to mean the scheme through which encrypted note information can be (privately) discovered by the intended recipient of that information. Notes in Aztec An Aztec user can store custom information in the form of a 'Note'.

Fundamental preliminaries WARNING: This doc is a work in progress. It started as my personal notes but has evolved into something that might be useful for others. It is incomplete and may have errors/typos! This document is meant to be a self contained guide to ZeroMorph, or at least the details required for its implementation. It lays out the unrolled (i.e. explicit) protocols for (1) proving and verifying a single multivariate evaluation, and (2) proving and verifying a batched evaluation, including shifts. The ZeroMorph paper is excellent and can be used to fill in theoretical gaps as necessary. Note: For now, the ZK-ification of ZM (detailed in the paper) has been left out of this document entirely. Notation In nearly all cases, the notation herein matches that of the ZeroMorph paper.

TLDR On the 12th of September we received a submission to our bug bounty program on Immunefi claiming Aztec Connect had a critical bug in one of its core ZK (zero knowledge) circuits. On the same day we assessed the validity of the submission and took preventative measures (disabling public access to the workflow that could exploit this issue) On the 3rd of October we patched the target system On the 10th of October we paid the bounty of $450,000 USD to the white hat The bug was discovered by security researcher lucash-dev Details Aztec Connect is a privacy-focused zkRollup system optimized for DeFi use-cases. It batches private transactions within its system using zero knowledge proofs, enabling users to send funds between each and to Layer 1 smart contracts privately. One of its novel features was DeFi interactions allowing users to exchange tokens or invest in protocols.

:::info Author: Mike This note is PUBLIC. ::: We're using the term "Note Discovery" to mean the scheme through which encrypted note information can be (privately) discovered by the intended recipient of that information. High level summary Many blockchain privacy protocols enable a transaction "sender" to relay private information about the transaction to some "recipient". For example, a private token protocol might enable a sender to create new "note commitments" for the recipient, and relay the underlying private note data to the recipient via a ciphertext which accompanies the transaction payload.

Feedback Partners are committed partners that will participate in a structured program for testing the Sandbox to (1) provide targeted feedback on protocol design, and (2) validate specific use cases. We are targeting 1 (up to 2) Feedback Partners per use case, for the following use cases: Account Abstraction User story: As a wallet provider on Aztec, I want to utilize native account abstraction to build a better UX for end users. Scope of Potential Sandbox project: Implement an account contract (TypeScript glue code here); implement the UI for the corresponding account, as a means to showcase the UX; and provide feedback on the following topics: (1) optimal interface for an Aztec-native account abstraction standard; (2) fee management; (3) EIP1271-like signature validation see here; and (4) use cases if we choose to abstract encryption keys (see here) Additional notes: Here are two documents (1 and 2) touching on how to implement an Account contract on StarkNet.

Towards a unified proposal abstracting the common parts of B52 and Fernet. Protocol phases In both proposals, each block goes through three main phases in the L1: proposal, proving, and finalisation. Transactions can achieve soft finality at the end of the proposal phase. Proposal phase During the initial proposal phase, proposers submit to L1 a block commitment, which includes a commitment to the transaction ordering in the proposed block, the previous block being built upon, and any additional metadata required by the protocol: Block commitment contents:

Introduction Background and Rational How It Works Introduction This proposals goal is to enshrine MEV into the protocol in order to maximise the value capture of the network and to tackle the centralising forces that arise from PBS head on. Enshrining an MEV auction, forces builders to take part in a first price auction for profitable blocks. It was previously stated that this proposal enshrined PBS but that is not true. This proposal explicitly removes the need for the proposer, by allowing builders to directly submit blocks.

This builds on Charlie & Phil's work here, but attempts to do everything via Ethereum calldata (or blobs), rather than use any other external services like Nym or Waku. The problem with using Nym or Waku is: Some apps will wish to constrain the caller to correctly handshaking, encrypt, and 'tag' encrypted event data with a clue. A sequencer can be forced to include encryped event data to L1, because that's where the rollup is finalised. But a sequencer (nor the caller) cannot be forced to send such data to Nym or Waku, because they're separate networks. There would need to be some kind of consensus spanning the Aztec network and the Nym/Waku networks. This problem goes away if an app is willing to assume 'senders' will be honest, and always send encrypted data via nym/waku. But Joe has given examples of apps where a malicious user could withold encrypted data from another user, in order to extort them.

tldr; use social consensus & end up migrating everything! Summary This proposal suggests a simple approach to Aztec's governance and upgrade mechanism - focusing on making everything non-upgradable, and therefore dubbed "non-governance" or "anarchy" (perhaps we can come up with a better name, or just call it social consensus?). Instead of having a system of governance that could potentially be co-opted by a few key stakeholders, such as the largest token holders or infrastructure providers, we propose a system where changes are triggered solely by community activity and acceptance, ala social consensus. The idea is somewhat to avoid the traditional concept of a traditional software upgrade altogether and let the network evolve organically with the community's direct participation and manually opting-in to all changes, while preserving the immutability and accessibility of all previous versions. Comparisons Unlike most networks that utilize a governance mechanism involving voting rights, staking, or delegated power, non-govnernance eliminates the traditional hierarchy and goes back to what we saw with Bitcoin and Ethereum via social consensus.