Our current zk rollup setup consists of the following components: Unmodified op-batcher, op-node and an unmodified OP-compatible execution client. Custom op-proposer. Unlike existing versions, which only processes finalized L2 blocks to avoid dealing with reorgs (which adds ~12.8m to end-to-end latency due to Casper FFG finality), ours handles the reorgs on L1/L2. It connects to a configurable number of proving servers and load-balances the proof requests between them according to their weights. Proving server forked from op-succinct. SP1 zkVM programs which are based on kona library, forked from op-succinct. Custom L2OutputOracle contract on L1 – updated to work with our op-proposer. Tweaked OptimismPortal contract – adjusted to allow proving and finalizing withdrawal transactions within the same block (for better UX) - this change is optional. Demo

TLDR Onchain cost (per proof): Batch size L1 Gas L2 Gas Dollar Cost 128 750

V1. Accept requests of the form: { "vk": { ... }, "proof": { ... }, "inputs": [ "1", "2", ... ] } where vk and proof are in the upa format. In this way, groth16 with commits is supported and we have conversion functionality from snarkjs and gnark formats. Existing code for endpoint (circuits create in upa repo):

Dependencies Install golang and rust Install docker and docker-compose wget -qO- https://get.pnpm.io/install.sh | sh - curl -L https://foundry.paradigm.xyz | bash foundryup download jq from https://jqlang.github.io/jq/

Brainstorming doc: https://hackmd.io/FAXOf-PUTAOP--2_kuNb-A Plan WORKER: L1 mode and L2 mode For L1 mode[ ] track "injected" proofs through the pipeline[ ] when we submit the aggregated proof to the contract, populate the offChainSubmissionMarkers flags [ ] start injecting proofs from the off-chain submission DB [ ] track when off-chain submissions are fully aggregated [ ] "catchup" (determine how much of the next off-chain submission has already been aggregated)

Implement the following algorithm (loosely based on the Sumcheck protocol) using CUDA. The following implementation of the BabyBear field may be used for finite field arithmetic: https://github.com/supranational/sppark/tree/main/ff You are encouraged to create an implementation that demonstrates good coding style, engineering practices and efficient scheduling and communication between CPU and GPU. Execution speed of individual kernels is less important. Part 1 Let $\mathbb{F}$ be the BabyBear finite field. Let $N$ and $n$ be integers. You are given $N$ $n$-variate multi-linear polynomials ${ f_i }_{i=0}^{N-1}$, for $f_i : \mathbb{F}^n \rightarrow \mathbb{F}$, in the form of evaluations on the boolean hypercube $B^n$ (where $B = {0,1}$).

$\newcommand{\add}{\textsf{add}} \newcommand{\mul}{\textsf{mul}} \newcommand{\FF}{\mathbb{F}} \newcommand{\P}{\mathcal{P}} \newcommand{\V}{\mathcal{V}} \newcommand{\eq}{\tilde{\mathsf{eq}}}$ References GKR Review Virgo GKR + ZK via novel PCS

Introduction In this article, we show that Axelar can save gas costs in its General Message Passing (GMP) protocol by using NEBRA's Universal Proof Aggregation (UPA) system. UPA allows on-chain protocols that use Groth16 proofs to save gas costs by recursively proving the validity of batches of Groth16 proofs and verifying a single aggregated proof on-chain. NEBRA UPA has two options for users to submit the Groth16 proofs they wish to aggregate: Submit the proofs via an on-chain transaction. Submit the proofs to an off-chain RPC endpoint. The main tradoff between the two options is that the first option save less gas costs for the end user, while providing stronger censorship-resistance properties.

Axelar Protocol Brief Description Axelar General Message Passing (GMP) is a cross-chain messaging system. It is secured by a multisig of staked signers. The core API for the Axelar's GMP system is given by: // Initiate a cross-chain contract call function callContract(string calldata destinationChain, string calldata contractAddress, bytes calldata payload) external; // Record approvals for a set of messages, signed off by Axelar verifiers function approveMessages(Message[] calldata messages, Proof calldata proof) external;

Goal The goal is the create a simple MPI program that can represent nebra's distributed prover workload. For simplicity, the program only needs to run on a single machine instead of on a distributed cluster. Requirement must be implemented using Rust all inter-process communication needs to be implemented using MPI rather than shared memory allow the user to control how many processes are to be spawned: there will be 1 coordinator process and n worker process, your program should work at least with n=1~64. Specification Input

Non-native arithmetic using Plonky3 Use the plonky3 library to create a circuit that performs addition and multiplication operations on the BN254 base field. A Prover should be able to use the circuit to convince a Verifier that he knows some (secret) base field elements $A$ and $B$ and public base field elements $C$ and $D$, such that $A + B = C$ and $A * B = D$. The implementation should be "from scratch" (not using existing code for non-native field operations in-circuit). The circuit must use a scalar field that is implemented in the repository above. Partial solutions are acceptable. You may be asked to explain your code in a follow-up interview.

EC add using Plonky3 Use the plonky3 library to create a circuit that performs an EC add operation on the BN254 curve. A Prover should be able to use the circuit to convince a Verifier that he knows some (secret) points $A$ and $B$ and a (public) point $C$, such that $A + B = C$. The implementation should be "from scratch" (not using existing code for EC or field operations in-circuit). The circuit must use a field that is implemented in the repository above. The Verifier can assume that $A$ and $B$ are valid curve points (bonus points for verifying this in the circuit). Partial solutions are acceptable, but you will be asked to explain your code in a follow-up interview.

by Jackie and Shumo TL;DR: In this report, we present the first quantitative analysis of zero knowledge proof supply chain on Ethereum layer-1. We uses onchain zero knowledge proof verification activities as a lens to look at how zero knowledge proof changes the landscape of both applications and infrastructures on Ethereum. zero knowledge proof gas cost dune dashboard: https://dune.com/nebra/zero-knowledge-proof-verification-cost-ethereum Why and How Zero Knowledge Proofs are used on Ethereum Zero knowledge proofs allow arbitrary computation being verified with a small cryptographic proof, and with privacy guarantee. There are generally two ways applications/infrasctures using zero knowledge proofs: Majorly using its zero-knowledge property for preserving privacy

TL;DR NEBRA L2-UPA is derived from NEBRA UPA, a protocol deployed on Ethereum L1. NEBRA UPA L2 shared the same core contracts with NEBRA UPA, the main difference is that NEBRA L2-UPA only support off-chain proof submission via RPC, which is much less than the on-chain proof submission would cost. NEBRA L2-UPA Workflow l2-upa The high level workflow that World App uses NEBRA L2-UPA would be: Submitter (i.e. the World App's supporting infrasctructure) submits the batched proofs and a deadline to NEBRA UPA RPC. NEBRA UPA RPC returns an Aggregatation commitment to submitter, which contains:deadline: the confirmed deadline, which is the lastest block that the proof batch should be finalized

Push Model (current system) Currently, the worker pushes prover tasks to an available provers in a ProverPool. The drawbacks of this approach are twofold: The set of provers is fixed when the worker process is instantiated. Moreover the worker must know fine-grained details about the provers such as IP addresses, ports, etc. New provers cannot be (easily) dynamically added to auto-scale proving capacity. image

$\newcommand{\prover}{\mathcal{P}}$ $\newcommand{\verifier}{\mathcal{V}}$ $\newcommand{\tower}{\mathcal{T}}$ Notes on section 4 of https://eprint.iacr.org/2023/1784.pdf Background and definitions Polynomial IOP (for binary towers): An interactive protocol $(\prover,\verifier)$ where the prover and verifier use the following multilinear polynomial oracle: Fix a tower height $\tau$ and a binary tower $\tower_0 \subset \tower_1 \subset \cdots \subset \tower_\tau$Prover $\prover$ can $\texttt{submit}$ to the oracle a polynomial $t \in \tower_{\iota}[X_0, \ldots, X_{\ell-1}]^{\preceq 1}$.In response, the oracle sends a unique handle $[t]$ for the polynomial $t$ to both the prover $\prover$ and the verifier $\verifier$.

Gnark Verifier This for will have 1 iteration because we will have vk.PublicAndCommitmentCommitted = [[]], i.e. it's an array of length 1 (b/c we allow only 1 commitment) containing an empty array (b/c we don't allow commitments to public witness values). https://github.com/Consensys/gnark/blob/d84f52a16ff161f93654698d4144f7f03ed13fe0/backend/groth16/bn254/verify.go#L82This grabs the Pedersen commitment from the proof https://github.com/Consensys/gnark/blob/d84f52a16ff161f93654698d4144f7f03ed13fe0/backend/groth16/bn254/verify.go#L83 This one's empty (b/c no commitments to public witness values) https://github.com/Consensys/gnark/blob/d84f52a16ff161f93654698d4144f7f03ed13fe0/backend/groth16/bn254/verify.go#L85 This does the hashing (there are many options for hash to field function, the one we use is described in specs) https://github.com/Consensys/gnark/blob/d84f52a16ff161f93654698d4144f7f03ed13fe0/backend/groth16/bn254/verify.go#L90 The result is appended as a new public input https://github.com/Consensys/gnark/blob/d84f52a16ff161f93654698d4144f7f03ed13fe0/backend/groth16/bn254/verify.go#L98 This folding is a no-op because we only allow 1 Pedersen commitment https://github.com/Consensys/gnark/blob/d84f52a16ff161f93654698d4144f7f03ed13fe0/backend/groth16/bn254/verify.go#L102 So this is where Pedersen POK is checked https://github.com/Consensys/gnark/blob/d84f52a16ff161f93654698d4144f7f03ed13fe0/backend/groth16/bn254/verify.go#L105

NEBRA is a research & development organization working to make the zero-knowledge future a reality. We research and build technologies, infrastructure, and products to facilitate the mass adoption of zero-knowledge proofs. At Nebra, our mission requires a team that is not only talented and forward-thinking but also deeply aligned with our foundational values of inclusivity, sustainability, and transparency. We are looking for people who are prepared to excel in a dynamic culture that promotes proactivity and values every individual's input. Ideal candidates are those who are enthusiastic about participating in a collaborative environment that prioritizes trust, continuous feedback, and a culture of innovation. At Nebra, we are committed to pushing the boundaries of what is possible, while ensuring that our advancements lead to tangible improvements in everyday life.We invite those who are excited about technology's potential to make a positive difference to join us in our journey to accelerate the arrival of the future. About the Role We are looking for an experienced Founding Infrastructure Engineer. This is an early opportunity to join our world-class research and engineering team to make impact in the blockchain industry. You will work with our research and cryptographic engineering team to develop the backend infrastructure of Nebra. Your responsibilities will include, but are not limited to, building a distributed prover network, enhancing CI/CD processes, and establishing observability and security monitoring systems.

Nebra introduction NEBRA is a research & development organization dedicated to advancing the use of zero-knowledge proofs to enable a more private and scalable blockchain future. Nebra focuses on research and development of technologies and infrastructure aimed at the mass adoption of ZKPs. A key initiative for NEBRA is enhancing Ethereum's proof settlement capabilities in a way that is both trustless and resistant to censorship by developing Universal Proof Aggregation(UPA). Nebra's UPA is designed to aggregate proofs from various circuits, systems, and parties to address one of the primary barriers to a zero-knowledge future: the high cost of on-chain proof verification. The costs to verify different ZKPs on Ethereum can range significantly, making it expensive for many potential applications and users. NEBRA’s solution involves using recursive SNARKs to prove multiple ZKPs off-chain and verify a single aggregated proof on-chain, drastically reducing costs and improving efficiency. This approach aims to make ZKP verification more affordable and accessible, broadening its application and adoption. Moving application at scale onchain

$\newcommand{\G}{\mathbb{G}} \newcommand{\F}{\mathbb{F}} \newcommand{\K}{\overline{K}} \newcommand{\P}{\overline{P}} \newcommand{\poseidon}{\textrm{poseidon}} \newcommand{\groth}{\textrm{groth16}}$ This document studies gnark proofs and the gnark verifier and describes the necessary changes to our Batch Verifier circuit to accept gnark proofs. This document covers what the gnark verifier does, but doesn't cover: