The aztec-packages monorepo requires a specific toolchain setup to be able to run ./bootstrap.sh fast which fetches/builds all of the packages. Here are the commands to get the monorepo set up on a linux machine as of Nov 21, 2024. sudo apt update -y && sudo apt upgrade -y sudo apt remove cmake -y pip install cmake --upgrade

This handbook is focused on the aspects of building on Aztec.network--no high level explainers of how to do things. High level explanations should link back to docs pages. Much of this content is already written. For content that is already exists, link to it--for content that does not exist yet, create an issue and maybe write it. The goal is to reduce the on-boarding time to Aztec to <1 week. Before wave 3 we need to create a handbook of existing repos and research on the design space Includes Forum posts, github repos, and relevant public info aggregate info from previous notes/ discord discussions Dont want new partners to reinvent anything

Github Repo to follow along Aztec Docs: Quickstart Example Schnorr Signer account contract Setup Docker start Docker Install the sandbox and CLI

Handling shared private state (WIP) How to handle private escrows between two parties..? Events Emit events for every account that should be able to read the state. Authwit Simple token transfers Using token authwit when calling an other contract in TS

MAGA is a simple on-chain, privacy preserving attestations protocol. Attestations are associated with an ECDSA signature hash that a user can verify ownership of with a zk proof. Github repo here. This may be best for off chain applications. consider making the time a Public input that invalidates it after X seconds. the solidity contract could be adapted for specific onchain applications, to make it resistant to front-running the proof public inputs must include any inputs to other solidity functions in the transaction. so for access control, the proof must include inputs for the action to be taken. eg, if its for a vote, the proof must include the vote (for, against), the proposal id and contract, otherwise those could be manipulated by a front runner. Recursive proofs greatly expand the design space of what's possible. The multisig and voting use cases explored at the bottom of this document are improved greatly when using recursive proofs for aggregation.

WIP circuit here Membership inclusion Storage Proofs verifying token ownership requires storage proofssnapshot at a given block w/ specific block header zk program verifies a storage proof on that header struct Proposal { uint snapshotBlock; bytes32 blockHeader;

Spec What does this bridge do? Why did you build it? This bridge will allow users to deposit assets into Aztec from other L2 bridges supported by Connext as well as send assets from Aztec directly to L2s. Here is a simple bridge contract from the connext docs for reference. The Hop protocol could also be used for an Aztec-->L2 transaction, reference, but not for an L2-->Aztec since it doesnt support arbitrary message passing. The rest of this specs assumes using Connext, but Hop would be similar. What protocol(s) does the bridge interact with?

Spec What does this bridge do? Why did you build it? This bridge allows users to deposit and withdraw NFTs to/from Aztec Connect. What protocol(s) does the bridge interact with? ERC-721 contracts on Etheruem.