Security Considerations and Bug Bounty
Countdown to Launch
Today we’re pleased to announce the bug bounty for the upcoming Aztec 2.0 main-net launch.
This article outlines the security decisions we have made in the lead-up to launch, and our approach to auditing and our bug bounty programme.
Aztec 2 will launch without an external audit.
Our upcoming launch utilises the TurboPlonk zero-knowledge proving system, which is an enhanced implementation of PLONK, our state-of-the-art ZK-SNARK.
We plan to upgrade the Aztec network frequently over the coming months, to support DeFi, ECDSA signatures and private smart contracts using Noir. As we upgrade we will incorporate our Plookup research, which promises to revolutionise what ZK-SNARKs are capable of.
In our opinion launching each of these major upgrades as experimental software with an on-going large bug bounty, is a far safer way for the community to gage the risks of using cutting edge cryptography.
Once we have we upgrade the network to our latest R&D — UltraPLONK, we will move out of the experimental stage. At this point we will be seeking multiple external audits.
Publishing bleeding-edge cryptography to end-users is a responsibility we take seriously; given the absence of an external audit, we are launching Aztec 2 as experimental software.
In the interim, we have conducted two internal audits of the code-base which are described below. After patching the resultant security flaws we have a high confidence in the soundness and security of our cryptography.
Bug Bounty vs Multiple Audits
External audits are critical sources of final assurance, but issues hidden in complex cryptographic protocols can sometimes only appear months later, especially at the experimental phase.
It is our view that for experimental software, on-going bug bounties better incentivise the community (and usually the people doing audits) to spot bugs than shorter-lived external audits, especially when it comes to cutting-edge cryptography.
Report: Our Internal Audits
Aztec’s world-leading research team, inventors of the PLONK and Plookup cryptosystems, has performed two extensive audits of our ZK-SNARK circuits and the underlying proving system.
These audits caught and fixed in particular the following high severity flaws.
Issue #1
When simulating operations modulu a prime number p, using operations in the native SNARK field Fᵣ for some r ≠ p, we discovered our equality function allowed proving for any c ∈ Fᵣ, that c = c + a where a= p mod r. Since this field simulation is used for recursive SNARK verification, this would have permitted fraudulent recursive proofs to pass the verifier check.
We notified Matter Labs of this security issue in their PLONK code, which was inherited from our open-source March 2020 codebase.
Issue #2
We discovered our method for removing spending keys involving an account nullifier, broke the sender privacy of transactions from the account; and consequently changed our key removal procedure to use an “Account Nonce” instead of the nullifier.
Issue #3
Our privacy circuit was not correctly including the user account nonce within the encrypted note cipher-text. This would have meant that a deprecated account, with an old nonce, would be able to spend any note owned by the account. We modified our circuit to include the account nonce when encrypting notes.
Burning in the Network
#1: Transaction Cap ≤ 1 ETH
Given the cutting-edge nature of the Aztec rollup, we’ll be implementing a 1 ETH cap in the first few months of operation, as a security precaution.
Users are nonetheless reminded to use any new cryptographic system with extreme caution, and to remember that you do so at your own risk.
The burn-in period gives time for the bug bounty to have the desired effect.
#2: Ownable & Pausable
Secondly, our Rollup contract is:
- Ownable
- Pausable
— via the OpenZepplin contracts. These two contracts give Aztec the tools to respond to responsible security disclosures whilst also providing a path to full decentralization.
We’ll irrevocably relinquish ownership of the contract no later than 6 months after launch, in the absence of further security disclosures.
Summary of our Safety Mechanism
For this burn-in period, the Aztec multi-sig wallet has the ability to:
- Authorise new Rollup Providers
- Authorise the introduction of new ERC-20 Tokens
- Change the verification contract used to validate RollupProofs. (For critical cryptography bugs)
- Change the Fee Distribution contract
- Pause all contract interactions.
The Bug Bounty
The source code for this release has been published under the Polaris Licence here (the recursion code), and MIT code for the verifier and private-transaction prover.
The bug bounty covers our ZK-SNARK circuits and the Solidity contracts. We request all security issues to be disclosed responsibly to us via email at hello@aztecprotocol.com, and reserve the sole discretion on if a bug report qualifies for a bounty.
We will pay out bug bounties in DAI, based on the following schedule:
Keep Updated for the 2021 Mainnet Launch
We’ll soon be deploying to main-net — stay up to date with the latest news by following us on Twitter and joining our Discord.
Join the team
We’re on the lookout for talented engineers and applied cryptographers. If joining our mission to bring scalable privacy to Ethereum excites you — get in touch with us at hello@aztecprotocol.com.
