Quality-of-life improvements to Aztec’s local developer testnet
A few months ago, we released the Aztec Sandbox at zkHack London.
The Sandbox is a local developer testnet intended to be a first look into how Aztec will ultimately work: as a privacy-first Layer 2 on Ethereum. It allows developers to write Aztec-native smart contracts with public and private logic, testable in Aztec’s Private Execution Environment (PXE).
In conjunction with our announcement, we quietly recruited multiple teams of developers to work closely with us to identify bugs in the Sandbox, expand its feature set, and begin experimenting with novel privacy primitives.
As a result of close collaboration with these pioneers, we are proud to announce a series of bug fixes, quality of life improvements, and other enhancements to the Sandbox.
Our Sandbox announcement blog post called it “the most ambitious software release in Aztec Labs’ history.” And with great ambition comes great quality of life improvements.
So we’re thrilled to share some of the obstacles our developers have run into and the work we’ve done to improve Aztec’s DevEx in order to highlight the novel application design space enabled by our software.
Now that the Sandbox is more stabilized and feature complete, we will be welcoming folks into future rounds of feedback.
Subscribe to our newsletter to stay up to date on the latest with Noir, Sandbox, and Aztec Labs:
Developer Experience Improvements
Early on, developers had to update a bunch of different pieces of software every time we pushed a new update. Docker, NPM packages, dependencies in nargo.toml, and more.
With the volume of updates we were (and still are) shipping – weekly on Tuesday – this quickly became very annoying. In fact, one of the major complaints about the Sandbox–and the reason this wasn’t an open-invite testnet–was the speed of iteration and the number of continuous changes.
So we designed a new update flow (aztec-cli update) that updates all components in one go via a Docker-only install experience, instead of manually juggling 4 different components.
We also bundled nargo (the Noir package manager) as WASM in the Docker image in the new update flow. This removes the extra step of installing nargo for writing contracts, so developers can get right into writing Aztec.nr contracts.
We’ve also implemented a slow updates tree to make it easier to read historical public storage in private functions.
Many external developers kept running into this constraint – if a private function is reading from public data, it is conceivable that by the time the private function executes, the public data has changed. This is one nuance of working with a network that has both private and public state, but we wanted to make it easier for developers to handle this.
So as mentioned above, we’ve implemented a slow updates tree – this is a contract containing public data that won’t change within a predefined time interval (for example, ‘over the next epoch’ or ‘over the next 500 blocks’). As long as the transaction in question is executed before that time interval, the public data will stay constant as it’s read from the slow updates tree.
At any time during the epoch, devs can tell the tree to update their particular public values to a new value. This data is stored in a pending tree. Once the epoch is over, the slow updates tree gets updated to use the pending values. This should be a useful data structure for developers who want to explore the new design space opened up by public ←→ private interactions.
What’s in a name?
Finally, better names. We know that Aztec Labs has not historically been great at naming, so we’re trying to be better at it.
First, we’ve removed the term ‘commitment’ in favor of ‘note hashes’. This is just more intuitive, since the ‘commitment’ actually comes from the hashing of the note (in other words, by hashing a note, you commit to the contents of that note, since changing any of the contents will change the hash!).
We’ve also named the private execution environment of the network as PXE (or ‘pixie’), instead of the other candidate name that we almost went with (PEE…).
Tutorials and Examples
The challenges of working with a completely new execution environment are not lost on us, so we’ve also been creating additional references for developers exploring a new ecosystem like Aztec’s. Here are some of the improvements we’ve made for tutorials and accompanying examples:
- More examples of custom notes – our network abstracts away a lot of the complexities associated with UTXOs, note commitments, and nullifiers. But custom notes are still hard to grasp without examples.
So we created a few more examples!
AddressNote and FieldNote are two examples of custom notes that should help developers grasp the note structures. - Aztec boxes – our version of Truffle Boxes. Essentially, a package with a dedicated user interface showing developers how to use Aztec.js and how to write Aztec contracts. These Aztec boxes act as a reference for developers to install and see how the different components interact to help create full stack apps.
- Portal tutorial, using Uniswap – Aztec portals are one of the most unique features of the Aztec L2. Portals allow for direct interactions with Ethereum, privately. In other words, no one can know where the transaction is coming from, besides the fact that it is coming from somewhere on Aztec.
(Long time followers may recognize this type of functionality as Aztec Connect, a previous iteration of our network. The Aztec network gets Aztec Connect functionality, out of the box!)
Tactically, portals are smart contracts written in Solidity that are related to the Ethereum smart contract that is being interacted with. This Uniswap tutorial helps developers understand how to use these portals to interact with L1 applications from the Aztec L2.
Smashing Bugs
Finally, bug fixes. There are always going to be a lot of bugs in new software, and the Sandbox is no exception.
Here are a few of the bugs that we’ve fixed recently:
- If the length of a note was incorrect in the compute_note_hash_and_nullifier method, developers would just get a ‘no method found’ error
- We weren’t properly deserializing arrays of structs
- Multiple things broke in the Sandbox – here is one Example
- The sequencer would go into an infinite loop when duplicate nullifiers were submitted
- Here are all of the bugs we’ve fixed in the past 2 months
Hopefully, it’s clear that we’ve been busy making the Aztec ecosystem a more enjoyable place for developers to explore the design space opened up by programmable privacy. These improvements should meaningfully improve the quality of the developer experience for interacting with the Aztec Sandbox, and in due time, the Aztec network.
We are committed to improving the intuitiveness of our execution environment and continuously upgrading our documentation (look at this activity!). All of this work is a result of listening to the challenges that the Aztec developer community is facing, fixing problems transparently, and working diligently to create a credibly neutral network with programmable privacy.
Thank you to our current partners:
If you’re interested in becoming a developer partner for Aztec and gain access to resources, funding, and early partnership on our privacy-first Layer 2 on Ethereum, stay tuned.
We hope you’ll join us for the ride.
