All the packages that make up Aztec.
l1-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).
- Example contracts: Example contracts for the Aztec network, written in Noir.
- End to end tests: Integration tests written in Typescript--a good reference for how to use the packages for specific tasks.
- Aztec Boxes: Example starter projects.
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, install Foundry, compile Solidity contracts, install the current node version via nvm, and build all typescript packages.
Alternatively, to just hack on Noir contracts and Typescript, run BOOTSTRAP_USE_REMOTE_CACHE=1 ./bootstrap.sh, which will download existing builds for barretenberg and nargo from the CI cache. Note that this only works on Ubuntu.
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 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!