Platform: Code4rena
Start Date: 02/10/2023
End Date: 23/10/2023
Period: 21 days
Status: Completed
Pot Size: $1,100,000 USDC
Participants: 64
Reporter: thebrittfactor
Judge: GalloDaSballo
Id: 292
League: ETH
xuwinnie | 1/64 | $502,041.99 | 8 | 5 | 4 | 2 | 1 | Grade A | 0 | 0 |
chainlight | 2/64 | $157,696.85 | 2 | 2 | 1 | 0 | 0 | 0 | 0 | 0 |
Audittens | 3/64 | $140,480.79 | 8 | 0 | 0 | 8 | 3 | 0 | 0 | 0 |
minhtrng | 4/64 | $38,573.19 | 2 | 0 | 0 | 2 | 1 | 0 | 0 | 0 |
erebus | 5/64 | $25,342.89 | 5 | 0 | 0 | 4 | 0 | Grade A | 0 | 0 |
OffsideLabs | 6/64 | $21,458.48 | 2 | 0 | 0 | 2 | 0 | 0 | 0 | 0 |
rvierdiiev | 7/64 | $17,605.91 | 7 | 0 | 0 | 6 | 0 | Grade B | 0 | 0 |
Koolex | 8/64 | $13,656.89 | 3 | 0 | 0 | 3 | 0 | 0 | 0 | 0 |
zkrunner | 9/64 | $13,145.99 | 3 | 0 | 0 | 2 | 0 | Grade B | 0 | 0 |
bin2chen | 10/64 | $12,223.84 | 3 | 0 | 0 | 3 | 0 | 0 | 0 | 0 |
Auditor per page
How the $1,100,000 maximum pot works:
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:
The VM section is related to the zkSync Era Virtual Machine.
Circuit Documentation:
For any clarifications, doubts, or discussion, please contact Code4rena staff, and we will address your concerns promptly.
| 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:
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:
isSystemCall flag, permitting only the contracts that are aware of the zkSync-specific features to call it.- 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