Mach 34 is excited to bring our final report on Noir Research Grant round #1! We've spent the past few months working to bring ZKEmail to the powerful Noir language. Furthermore, we've demonstrated a production-grade integration of ZKEmail.nr with Z-Imburse - an Aztec native application for self-authorized reimbursements using email receipts. Two of the industry's top auditing teams, Consensys Diligence and Veridise, partnered with Aztec on the NRG#1 to audit Z-Imburse and ZKEmail.nr. You can view the audits here Consensys Diligence Audit Veridise ZKEmail.nr Audit You can read the previous NRG#1 half-way report from Mach 34 here.

Grant Proposal: https://github.com/orgs/noir-lang/discussions/5814 Halfway report: https://hackmd.io/sPwcJ2obTFajkCaZ_0I52A Docs Writeup: https://hackmd.io/@IQZ-5dJ4QGGu4K6oX71X7w/BkFZfgCgye Code Scope Consensys Dilligence has expressed that capcity is limited and first priority should be given to ZKEmail.nr ZKEmail.nr Commit: 2f81196ac04cd11a921816b52b432bb8c5eb3150 Loc: 1599

NRG#1 Proposal: https://github.com/orgs/noir-lang/discussions/5814 Mach 34 is excited to deliver the half-way report on our work integrating ZKEmail into the Aztec Ecosystem! Our deliverables are split into two categories: The ZKEmail.nr SDK for all Aztec/Noir devs to implement to easily prove any type of email in Noir The Z-Imburse proactive reimbursement application We've mostly completed the ZKEmail.nr library already - and we look forward to delivering the Z-Imburse application by DevCon 7. Below is a recap of our progress so far: Zkemail.nr

Table of Contents ZKEmail.nr <-- to add, see zkemail.nr readme for now ZImburseRegistry ZImburseEscrow Scope ZKEmail.nr entirety of https://github.com/zkemail/zkemail.nr:

The Z-Imburse registry provides three main functions Guarantee integrity of ecrow contracts Central DKIM keyhash registry Entrypoint for escrow contract discoverability :::info The registry is a bit of an experiment into parent/child contracts, however in the context of optimizing proving speeds we forsee a scenario where the escrow registry functionlaity is abandoned and the DKIM key registry functionality is moved to the escrow contract. This would require escrow operators to synchronize their keys manually, but it would save recursive calls from an escrow contract to the registry contract. The discoverability and labeling functionality provided by the escrow contract would be moved to an end-to-end encrypted database at the cost of decentralization.

Aztec does not yet provide the ability for contracts to deploy other contracts. This means that we cannot guarantee the integrity of an escrow contract or its parameters during deployment of the escrow contract. To rectify this, we include an escrow registration function: #[private] fn register_escrow(escrow_contract: AztecAddress); From a security standpoint, there are two objectives: Guarantee an asserted contract is a valid instance of a ZImburseEscrow contract Guarantee the contract points to the correct escrow registry and payment token Escrow Contract Instance Integrity

In order to authenticate emails as originating from a trusted domain, DKIM public keys are registered in a common and agreed upon registry. Public keys are pedersen hashed into a single field element for efficiency. DKIM key hashes are applicable for a specific scope - in the case of Z-Imburse, we have a set of receipt verifier types (Linode, United Airlines, etc.). To constrain a DKIM key hash to a scope, we employ a map DKIM Key Hash (bool) -> Verifier ID (u8). This way, reimbursement claimaints can hash the DKIM key used to verify their email and check the mapping to ensure the dkim key used is valid for the entitlement type they are trying to claim. Shared Immutable for Key Hashes The ID of the verifier a DKIM key hash maps to is stored in a SharedImmutable type. The benefit here is that a claimant can contrain the lookup of the verifier ID without leaving the private context. The use of SharedMutable introduces additional complexities that are not worth delving into, and PublicMutable would leak the fact that someone is looking up a certain public key, thus leaking that a certain receipt type was claimed. :::info Trust assumption: The issue with SharedImmutable is that DKIM key hashes cannot be revoked. In V1, we do not address this issue. In a later version, we could rectify this by allowing the registry admin to emit a nullifier of the DKIM key hash, and lookups of the DKIM key would also have to prove nullifier non-inclusion to ensure the DKIM key hash is currently valid. :::

The following documentation describes actual interaction with the ZImburseEscrow. Contract Construction The ZImburseEscrow constructor publicly initializes a new instance of the ZImburse contract. The constructor simply takes: an address for the ZImburseRegistry contract an address for the USDC payment Token contract a string title that describes what the escrow does Additionally, the execution will retrieve the context.msg_sender() as the admin. A SharedImmutable<EscrowDefinitoin> will be created to allow constrained private access control by the admin, checks against DKIM key hashes in the registry, and initiation of token transfers for reimbursement.

Z-Imburse Escrows are the engine for how organizations and their participants interact with each other to perform reimbursements. The general functionality is: An admin creates a new escrow group Out of band (i.e. by DM/email/etc) the admin is given a participant's aztec address The admin creates an entitlement to reimburse with specific parameters and permits the participant to use the entitlement onchain The participant produces an email receipt satisfying the parameters to claim the reimbursement :::info

EntitlementSet EntitlementSet is a wrapper around Map<PrivateSet<EntitlementNote>> with abstractions. :::info To prevent collisions in TXE where all accounts can see eachother's notes, we map the "scope" (address of user we want to act as) to the private set. This introduces additional constraints and complexity that may not be necessary, but we could not find an API to prevent this bevaior from occuring in multi-tenant PXE's (essentially just the TXE) ::: Unconstrained EntitlementSet::view_entitlements can be used to view entitlements (including entitlement "receipts", the entitlement note duplicate sent to an admin) in the unconstrained context for clients. It simply provides the options to set parameters to match for EntitlementNote.recipient, EntitlementNote.verifier_id, and EntitlementNote.spot.

Entitlement Notes are how an admin gives an organization participant the ability to self-reimburse for expenses. The data is defined below: Note Definition pub struct EntitlementNote { // the user that is allowed to use this entitlement recipient: AztecAddress, // the type of receipt verifier that this entitlement can be used for verifier_id: u8, // the maximum value that can be withdrawn from the escrow using this entitlement max_value: U128,

1. What is Grapevine Grapevine is a utility for building private, verifiable social graphs that show distance from a given identity This is cool because we can build apps that rely on pure social connections to attest in some way to the valididty of an identity We're going to run through the basics of what is being proven, show off the CLI since it is feature complete, talk about the JS library which does work for proving but is not yet ready for developer use quite yet, and talk about where we see grapevine going 3. Flow We're very quickly going to run through the protocol, you can ask questions for clarity at the end but I'm going to go quick since the demo is like 75% of our time. Also addresses are just the poseidon hash of the bjj public key

Summary image image image Work in the crypto ecosystem often presents situations where grantees pay for costs upfront, and some company or foundation eventually reimburses them for the funds. This slow, reactive, and bureaucratic process is an ironic antithesis of the infrastructure these organizations are building. We propose ZImburse: an Aztec-based web app for instant self-authorizing reimbursement dictated by organizational policies. There are two classes of users in ZImburse:

Theory What is an attestation IRL? What is an attestation in progromatic cryptography? Why are attestations desirable? Are attestations intrinsic facts? Why or why not? Tech What kinds of attestations exist?zk-JWT zk-emailemail header hash signed by dkim signature, hash contains hash of email body dkim signature = signature by MTA (MAIL TRANSFER AGENT) (smtp.google.com for gmail)

What is Baseline? Baseline is a library of tools for private synchronization of complex business logic with many participants. Critically, Baseline uses ZK to allow coordination to be done confidentially and without putting sensitive operational information in shared databases. This is done by settling ZKP's on a blockchain, which is referred to as a "Consensus Controlled State Machine". Baseline is 100% open source, governed by Oasis Open under the Ethereum Oasis Open Project (formerly known as Ethereum Enterprise Alliance Community Projects). The founding participants are Consensys, Ernst Young (EY), and Microsoft. BRI 3 Linked here BRI 3 is a reference implementation demonstrating how the infrastructure is used to

At the end of the year, your Instagram and Twitter feed is probably plagued with "Spotify Wrapped" posts. Spotify provides a service for you to tell your friends that you listened to 4,000 hours of Taylor Swift this year. But what if we could recreate this experience for live events? If you missed the the previous blog post, check it out for context on Cursive's app. As a quick summary, zkSummit 11 issued NFC cards to every attendee and speaker, and also placed cards at each presentation. These NFC cards could produce Babyjubjub-ECDSA signatures, and the keys on these cards were grouped into Merkle trees of attendees, speakers, or talks. At zkSummit 11, you could tap any of these cards with your phone and prove you met an attendee or attended a talk by verifying the authenticity of the signature and the existence of the corresponding public key in the tree. Most importantly, Cursive deployed a 2PC/PSI service that allowed two users to discover the people they both met and the talks they both attended without revealing any extra information. Cursive built the infrastructure for verifying the social layer at live events. With all of these signatures lying around, the idea to aggregate these signatures into a summary of an attendee's event experience presented itself. With some slight tweaks to the core signature/tree inclusion circuits developed by Cursive, we were able to combine these proofs to create a statement like "I met X other zkSummit 11 attendees" or "I attended Z unique talks at zkSummit 11." Once all your signatures have been aggregated, the Cursive app stores the proofs and creates a shareable webpage for you to easily show off private* and cryptographically verifiable metrics on the social network you built at zkSummit 11. See the demo: Why Folding Cursive provides us a bunch of signatures by keys grouped in trees. Sure, we could batch a bunch of signatures together into a single proof, but that could get expensive and can't be amortized as you meet new people. What if we could recursively verify signatures into a single running sum as we acquire them?

Grapevine V2 is a SDK for creating private, provable social graphs using Nova-style folding. It provides the most basic primitives for enforcing relationships, as well as proving degrees of separation away from a given relationship. Grapevine exists as a Cargo crate grapevine-rs and a Javascript package grapevine.js. Developers can implement these packages to use any Grapevine identity registry, be it the officially hosted server or one they stand up themselves. Grapevine Proofs Grapevine V2 uses Nova, a uniform IVC folding scheme. This means that each circuit is the exact same as the previous one. However, Grapevine has two different functions: Proving an identity Proving separation from an identity Thus, Grapevine circuits use an incrementor to toggle different logic according to whether it is the 1st step or a step > 1.

ZKML Projects === Projects: Keras2Circom: https://github.com/ora-io/keras2circomeasiest to use- circom can generate solidity verifiers leaves some performance on the table EZKL: https://github.com/zkonduit/ezkl Halo2 based, more performant but maybe slightly more involved to get onchain

List of topics to research for general understanding of crypto space in 2024 Staking & Consensus Eigenlayer Restaking LIDO liquid staking Superfluid Staking? RocketPool Shared Validation SSV Shared Sequencing BeraChain Proof of Liquidity

Table of Contents [Code] What is a State Channel? The Aztec Stack 3a. Kernal Circuits and App Circuits 3b. Private eXecution Environment (PXE) 3c. Notes Aztec State Channels 4a. Hijacking Transaction Proving 4b. The "Orchestrator"