The `L2EthToken` contract simulates native ETH behavior on Layer 2 (L2) by managing user balances and total supply. It allows trusted system contracts to transfer ETH between addresses, mint new ETH, and initiate withdrawals to Layer 1 (L1). The contract also provides balance queries and emits events for transfers, minting, and withdrawals. It does not support direct user interactions like `transfer` or `approve`.

The `DefaultAccount` contract simulates the behavior of an Externally Owned Account (EOA) for addresses without deployed bytecode. It validates and executes transactions, increments nonces, and handles signatures. It includes modifiers to ignore non-bootloader calls and delegate calls, ensuring it behaves like an EOA. It also processes paymaster transactions and has fallback and receive functions to handle direct calls.

The `AccountCodeStorage` contract manages and stores bytecode hashes for account addresses, ensuring the integrity and format of these hashes. It allows only the deployer system contract to store or update these hashes, distinguishing between constructing and constructed contracts. It also simulates EVM opcodes `extcodehash` and `extcodesize` to retrieve the code hash and size of deployed smart contracts.

The `EmptyContract` is a default placeholder contract used in some system contracts. It includes a `fallback` function and a `receive` function, both of which are payable, allowing the contract to accept Ether. The `fallback` function is triggered when no other function matches the call, and the `receive` function is triggered when Ether is sent without data.

The `PubdataChunkPublisher` contract chunks large pubdata into smaller pieces that fit into EIP-4844 blobs for efficient L1 to L2 communication. It ensures the pubdata fits within a maximum of two blobs, calculates their hashes, and publishes these hashes as system logs. This facilitates easier processing of logs on L1. The contract restricts function calls to a specific L1 messenger contract.

The `Compressor` contract, designed for zkEVM, handles bytecode and state diff compression and validation. It verifies and publishes compressed bytecode on L1, ensuring the integrity of the original bytecode. It also validates compressed state diffs, ensuring they match the original state changes. The contract uses a dictionary-based compression algorithm and supports operations like addition, subtraction, and transformation for state diffs.

This contract defines constants and addresses for various system contracts used in the zkSync protocol. It includes addresses for precompiled contracts, system utilities, and storage mechanisms. The contract also sets up constants for system parameters like maximum message values, state diff sizes, and Merkle tree configurations. It essentially serves as a centralized registry and configuration for zkSync's system-level operations.

The `ImmutableSimulator` contract simulates the behavior of immutable variables in Solidity by storing them in its storage. It allows retrieval of these variables via `getImmutable` and permits the deployer system contract to set them using `setImmutables`. This ensures that contracts with identical code but different constructor parameters have the same bytecode, aiding in compiler simulations for immutables.

The `BootloaderUtilities` contract provides utility methods for calculating transaction hashes for different Ethereum transaction types (EIP-712, Legacy, EIP-1559, EIP-2930). It includes functions to encode and hash transaction data, ensuring unique and secure transaction identifiers. The contract handles complex encoding tasks that are difficult to implement in Yul, using RLP encoding and other helper libraries.

The `ComplexUpgrader` contract facilitates complex, multi-step upgrades on Layer 2 (L2) by delegating calls to another contract. Only the `FORCE_DEPLOYER` can initiate the upgrade process. The contract verifies that the target address is a contract and uses `delegatecall` to execute the provided calldata. If the delegate call fails, it reverts the transaction with the error message from the delegated contract.

The `KnownCodesStorage` contract manages a registry of known bytecode hashes, marking them as known and optionally sending them to Layer 1 (L1) for publication. It includes functions to mark multiple or single bytecode hashes as known, validate their format, and check if a bytecode hash is known. Only the bytecode compressor or bootloader can mark bytecodes as known.

The `L1Messenger` contract facilitates sending messages from Layer 2 (L2) to Layer 1 (L1) in the zkSync ecosystem. It supports both fixed and variable-length messages. The contract processes and logs these messages, calculates gas costs, and ensures data integrity through Merkle tree and hash verifications. It also handles bytecode publication requests and state diff verifications for L1 batches.

PatrickAlphaC

This repository contains a subset of zkSync system contracts for testing purposes. Once the era-contracts GitHub repo releases a library edition, we will recommend people to use that instead. WIP