- $1,100,000 total maximum prize pool
- Join C4 Discord to register
- Submit findings using the C4 form
- Read our guidelines for more details
- Starts October 2, 2023 20:00 UTC
- Ends October 23, 2023 20:00 UTC
How the $1,100,000 maximum pot works:
- Audit minimum pot is $330,000 (including $7.5k gas optimization pot). ❗️Please note, only L1 contracts are included in gas optimization pool.
- HM awards: $250,000 USDC
- Analysis awards: $15,000 USDC
- QA awards: $7,500 USDC
- Bot Race awards: $20,000 USDC
- Gas awards: $7,500 USDC
- Judge awards: $18,000 USDC
- Lookout awards: $12,000 USDC
- Scout awards: $500 USDC
- If ANY valid Medium severity issue is found, audit pot increases to $770,000.
- If ANY valid High severity issue is found, audit pot increases to $1,100,000.
Automated findings output for the audit can be found here within 24 hours of audit opening.
Note for C4 wardens: Anything included in the automated findings output is considered a publicly known issue and is ineligible for awards.
DefaultAccount, while it should always behave as an EOA (i.e. any call to it should return success(0,0)), if called with a selector of one of its methods and incorrect ABI-encoding of its parameters, will fail with empty error. This happens due to the fact that the ABI decoding fails before the modifier is triggered.
More known differences from Ethereum can be found in our documentation.
zkSync Era is a fully-fledged Layer-2 scaling solution, combining a set of smart contracts on Ethereum mainnet and zkEVM for enabling Ethereum virtual machine-compatible smart contract execution.
This repository contains comprehensive documentation and code related to the Smart Contracts, VM, and zk-circuits sections of the zkSync Era Protocol. Below is a high-level summary of each section along with relevant documentation links. Please refer to these before and during the audit for a thorough understanding of the protocol.
Relevant Documentation:
- L1 smart contracts
- System Contracts/Bootloader Description
- zkSync Era Fee Model
- Handling L1→L2 Ops on zkSync
- Batches & L2 Blocks on zkSync
- Elliptic Curve Precompiles
- Handling Pubdata in Boojum
The VM section is related to the zkSync Era Virtual Machine.
- ZkSync Era Virtual Machine Primer
- This primer is designed to provide auditors with a foundational understanding of the zkSync Era Virtual Machine. It offers insights into the operational mechanics and integral components of EraVM, serving as an essential guide for those seeking to explore the zkSync EraVM environment.
- zkSync Era: The Equivalence Compiler Documentation
- The document describes how zkSync Solidity compiler represents high-level programming language constructions into low-level EraVM instruction set, how to use unique features without extending Solidity language with new syntax and why system contracts are needed.
- EraVM Formal specification
- This document is a highly technical and detailed specification, providing an in-depth exploration of the zkSync protocol and its underlying architecture. It’s a comprehensive resource for those who desire a deeper and more formal understanding of the protocol's design and functionalities. While it’s not a required read for understanding the basic structure and operations of the protocol, it is an invaluable resource for those wishing to delve into the finer details and theoretical underpinnings of zkSync.
Circuit Documentation:
- How does ZK work? (high level)
- Examples and Tests
- Advanced
- Ensure to go through each section and related documents thoroughly.
- Keep in mind the overall working of the zkSync protocol while reviewing individual components.
- Review the code and documentation with a focus on security, correctness, and optimization, particularly concerning gas consumption.
For any clarifications, doubts, or discussion, please contact Code4rena staff, and we will address your concerns promptly.
- Documentation: https://era.zksync.io/docs/
- Website: https://zksync.io/
- Twitter: https://twitter.com/zksync
- Discord: https://join.zksync.dev/
- Previous Audits: https://era.zksync.io/docs/reference/troubleshooting/audit-bug-bounty.html
| Contract | SLOC | Libraries used |
|---|---|---|
| ethereum/contracts/governance/Governance.sol | 120 | |
| ethereum/contracts/governance/IGovernance.sol | 38 |
| Contract | SLOC | Libraries used |
|---|---|---|
| ethereum/contracts/upgrades/BaseZkSyncUpgrade.sol | 135 | |
| ethereum/contracts/upgrades/DefaultUpgrade.sol | 24 |
| Contract | SLOC | Libraries used |
|---|---|---|
| system-contracts/bootloader/bootloader.yul | 3825 |
| Circuits & circuit structures | SLOC | Purpose |
|---|---|---|
| era-zkevm_circuits/src/base_structures | 1971 | Structures for circuits |
| era-zkevm_circuits/src/code_unpacker_sha256 | 704 | Unpacks code into memory |
| era-zkevm_circuits/src/demux_log_queue | 868 | Demultiplexes logs into their appropriate circuits |
| era-zkevm_circuits/src/ecrecover | 1342 | Ecrecover precompile |
| era-zkevm_circuits/src/fsm_input_output | 352 | Validates the outputs of one circuit match the inputs of the next |
| era-zkevm_circuits/src/keccak_round_function | 531 | Keccak hash function precompile |
| era-zkevm_circuits/src/sha256_round_function | 464 | SHA256 hash function precompile |
| era-zkevm_circuits/src/linear_hasher | 224 | Creates commitment using Keccak |
| era-zkevm_circuits/src/log_sorter | 798 | Sort and deduplicate logs |
| era-zkevm_circuits/src/main_vm | 7673 | Main VM circuit |
| era-zkevm_circuits/src/ram_permutation | 657 | Circuit for RAM reads+writes |
| era-zkevm_circuits/src/sort_decommitment_requests | 1358 | Sort and duplicate code decommitments |
| era-zkevm_circuits/src/storage_application | 686 | Circuit related to storage. Handles the sorting and deduplication of code cancellation requests |
| era-zkevm_circuits/src/storage_validity_by_grand_product | 1670 | Circuit is sorting and deduplicating storage requests |
| era-zkevm_circuits/src/tables | 206 | Lookup Tables |
| Contract | SLOC | Libraries used |
|---|---|---|
| era-zkevm_circuits/src/recursion | 876 | |
| era-zkevm_circuits/src/scheduler | 1333 |
It is important to examine access control and permissions for any contract that contains potentially dangerous logic (including upgrades). While the assumption is that either governance or security council are not malicious, neither governance, nor the security council should be able to circumvent the limitations imposed on them.
Special scrutiny should be paid to the powers of the operator. While currently the operator is controlled by Matter Labs and is also partially trusted (for instance, it is responsible for supplying the correct L1 gas price), it should never be able to directly steal users' funds or conduct malicious upgrades. An example of such an issue, which was detected and resolved by the team before the contest.
Another important invariant is that the state of the rollup can be restored based on the pubdata sent to L1. Make sure that for a block that gets executed regardless of what a potentially malicious operator does:
- Users can always get preimages for all the bytecodes that were deployed to the system.
- Users can always recover the leaves of the Merkle tree of L2->L1 logs.
- Users can always recover the storage merkle tree.
In general, there should be always a possibility to have a new operator that fully recovers the state available solely from L1 and is able to execute transactions successfully.
Make sure that access to any dangerous logic is well-constrained. For instance:
- Access to potentially dangerous system contracts' methods is protected by the
isSystemCallflag, permitting only the contracts that are aware of the zkSync-specific features to call it. - Using innocent Solidity code without zkSync-specific features should not lead to unexpected behaviour. An example of a relevant finding.
- If you have a public code repo, please share it here: N/A
- How many contracts are in scope?: 39
- Total SLoC for these contracts?: 6011
- How many external imports are there?: 13
- How many separate interfaces and struct definitions are there for the contracts within scope?: 94
- Does most of your code generally use composition or inheritance?: Yes
- Is this an upgrade of an existing system?: Yes
- Check all that apply (e.g. timelock, NFT, AMM, ERC20, rollups, etc.): timelock, rollups, zk circuits
- Is there a need to understand a separate part of the codebase / get context in order to audit this part of the protocol?: No
- Please describe required context: ZK rollup
- Does it use an oracle?: No
- Describe any novel or unique curve logic or mathematical models your code uses: No
- Is this either a fork of or an alternate implementation of another project?: No
- Does it use a side-chain?: No
- Describe any specific areas you would like addressed: Missing constraints, logical errors, malicious input for zk circuit or bootloader
rm -Rf 2023-10-zksync || true && git clone https://github.com/code-423n4/2023-10-zksync.git && cd 2023-10-zksync/code/contracts/ethereum && yarn --ignore-engines && yarn test
rm -Rf 2023-10-zksync || true && git clone https://github.com/code-423n4/2023-10-zksync.git && cd 2023-10-zksync/code/contracts/ethereum && yarn --ignore-engines && yarn test:foundry
rm -Rf 2023-10-zksync || true && git clone https://github.com/code-423n4/2023-10-zksync.git && cd 2023-10-zksync/code/system-contracts/scripts && yarn --ignore-engines && bash quick-setup.sh
rm -Rf 2023-10-zksync || true && git clone https://github.com/code-423n4/2023-10-zksync.git && cd 2023-10-zksync/code/contracts/zksync/scripts && yarn --ignore-engines && bash quick-setup.sh