All the packages that make up Aztec.
circuits: C++ code for circuits and cryptographic functionsl1-contracts: Solidity code for the Ethereum contracts that process rollupsyarn-project: Typescript code for client and backenddocs: Documentation source for the docs site
- Aztec.nr: A Noir framework for smart contracts on Aztec.
- Aztec Sandbox: A package for setting up a local dev net, including a local Ethereum network, deployed rollup contracts and Aztec execution environment.
- Aztec.js: A tool for interacting with the Aztec network. It communicates via the Private Execution Environment (PXE).
- Aztec Boxes: A minimal framework for building full stack applications for Aztec (using React).
- Example contracts: Example contracts for the Aztec network, written in Noir.
- End to end tests: Integration tests writted in Typescript--a good reference for how to use the packages for specific tasks.
All issues being worked on are tracked on the Aztec Github Project. For a higher-level roadmap, check the milestones overview section of our docs.
Run bootstrap.sh in the project root to set up your environment. This will update git submodules, download ignition transcripts, build all C++ circuits code, install Foundry, compile Solidity contracts, install the current node version via nvm, and build all typescript packages.
To build the C++ code, follow the instructions in the circuits subdirectory, which contains all of the ZK circuit logic for Aztec. Note that "barretenberg", Aztec's underlying cryptographic library, can be found inside the circuits subdirectory as well and is automatically built as a side effect of building the circuits.
To build Typescript code, make sure to have nvm (node version manager) installed.
To build noir code, make sure that you are using the version from yarn-project/noir-compiler/src/noir-version.json.
Install nargo by running noirup -v TAG_FROM_THE_FILE.
This repository uses CircleCI for continuous integration. Build steps are managed using build-system. Small packages are built and tested as part of a docker build operation, while larger ones and end-to-end tests spin up a large AWS spot instance. Each successful build step creates a new docker image that gets tagged with the package name and commit.
All packages need to be included in the build manifest, which declares what paths belong to each package, as well as dependencies between packages. When the CI runs, if none of the rebuild patterns or dependencies were changed, then the build step is skipped and the last successful image is re-tagged with the current commit. Read more on the build-system repository README.
It is faster to debug CI failures within a persistent ssh session compared to pushing and waiting. You can create a session with "Rerun step with SSH" on CircleCI which will generate an ssh command for debugging on a worker. Run that command locally and then do
cd project
./build-system/scripts/setup_env "$(git rev-parse HEAD)" "" "" ""
source /tmp/.bash_env*
{start testing your CI commands here}This provide an interactive environment for debugging the CI test.
Logging goes through the info and debug functions in C++, and through the DebugLogger module in Typescript. To see the log output, set a DEBUG environment variable to the name of the module you want to debug, to aztec:*, or to * to see all logs.
Releases are driven by release-please, which maintains a 'Release PR' containing an updated CHANGELOG.md since the last release. Triggering a new release is simply a case of merging this PR to master. A github workflow will create the tagged release triggering CircleCI to build and deploy the version at that tag.
There are many ways you can participate and help build high quality software. Check out the contribution guide!