Skip to main content

zkSync Era

Key Takeaways​

  • zkSync is a Type4 EVM rollup solution for Ethereum that enables high-level source code, such as Solidity, to be compiled into IR and linked to zkEVM bytecode.
  • The zkSync network is operated by a Core App layer that generates zkSync chain blocks, prepares executed blocks to be proved, and submits blocks and proofs to the L1 smart contract.
  • The finality and security of zkSync Era depend on the finality and security of the underlying L1 Ethereum chain, and zkSync also implements an off-chain data availability solution called zkPorter to complement the rollup component.
  • zkPorter is the internal consensus mechanism for data availability within zkSync 2.0, enabling high TPS numbers and secured by 'guardians' who stake zkSync tokens and sign blocks to confirm data availability in zkPorter accounts.

1. Overview​

The lifecycle of zkSync rollup operations can be summarized as follows:

  1. Users initiate a transaction or a priority operation.
  2. The operator processes the request and creates a rollup operation to include in the block.
  3. The operator submits the completed block to the zkSync smart contract as a block commitment. Note that the smart contract verifies certain rollup operations.
  4. The proof for the block is submitted to the zkSync smart contract for block verification. If verification succeeds, the new state is confirmed as final, indicating the end of the zkSync rollup operation lifecycle.

2. Execution​

Core App is the layer responsible for running the zkSync network and performing the following tasks:

  • Monitoring the L1 smart contract for deposits or priority operations.
  • Maintaining a mempool that receives transactions and executes them in a VM.
  • Generating zkSync chain blocks, preparing circuits for executed blocks to be proved, and submitting blocks and proofs to the L1 smart contract.

At the protocol level, it has implemented native Account Abstraction. In the zkSync Era, transactions from both Externally Owned Accounts (EOAs) and smart contract accounts are processed through a unified mempool. The Operator bundles transactions regardless of the account type and sends them to the Bootloader (similar to the EntryPoint contract), resulting in a single mempool and transaction flow.

Like other L2 rollup systems, the finality and security of zkSync Era depend on the finality and security of the underlying L1 Ethereum chain. Finality on zkSync Era is determined by the time taken from sending a transaction to when the L1 smart contract updates the L2 state. This process has several steps:

  • Filling a batch with transactions (usually takes a few minutes).
  • Committing the batch to Ethereum.
  • Generating a proof for the entire batch (usually takes around an hour).
  • Submitting the proof for verification by the Ethereum smart contract.
  • Finalizing the batch on Ethereum (delayed by ~21 hours as a security measure during the alpha phase).

Once this process is complete, which takes around ~24 hours in total, the batch is considered final, just like any Ethereum transaction included in the same Ethereum block.

3. Settlement​

This Settlement layer is responsible for ensuring the integrity of state transition zkSync. Prover app generated proof and the verification process is done in the deployed smart contracts in Ethereum. There are one entity that generates proof and two important contracts in this process

  1. Prover
    1. The prover app takes blocks and metadata generated by the server and constructs a validity zk proof for them.
  2. Contracts
    1. Executor Contract: This contract gets block data from a validator and zk proof of the state transition in zkSync.
    2. Verifier Contract: This is a logic contract that allows the system to validate block data and zk proof provided from the Executor contract.

Executor Contract

The proveBlocks function is a critical component of the zkSync system as it ensures the security and integrity of submitted blocks. This function verifies zk-SNARK proofs for submitted blocks by confirming their order, checking their hashes, creating a proofPublicInput array, and verifying the zk-SNARK proof. If the proof is valid, the system is updated and a BlockVerification event is triggered. This function plays a crucial role in preventing invalid blocks from being executed.

Verifier Contract

The Verifier contract acts as a guard for zkSync by checking zk-SNARK proofs to validate submitted data. The verification key, which is stored in the Verifier contract, is used to verify these proofs. When zkSync submits an update, it generates a zk-SNARK proof and submits it to the Verifier contract via the Executor Contract. The Verifier contract then checks the validity of the proof using the verification key and either accepts or rejects the update. By verifying these proofs, the Verifier contract ensures that only correct and valid data is accepted into zkSync, which helps prevent invalid state changes and ensures the system's security.

3.1 zkEVM​

zkSync Era is a Type4 EVM. This allows for high-level source code, such as Solidity, to be compiled into IR. The IR is subsequently linked to zkEVM bytecode, which generates a zk SNARK proof of the execution. This ensures that the entire process is secure and reliable. With zkSync Era, developers are able to create applications that are faster, more efficient, and more secure.

4. Data Availability: store input and output​

Storage Layer: The various components and subcomponents do not communicate with each other directly via APIs, but rather via the single source of truth -- the database storage layer.

zkPorter​

One of the core visions for zkSync Era is an off-chain data availability solution called ‘zkPorter.’ This solution is designed to complement the rollup component of zkSync Era, allowing rollup contracts and accounts to interact with zkPorter accounts and vice versa. Off-chain data availability in zkPorter will be secured by ‘guardians,’ who stake zkSync tokens and sign blocks to confirm data availability in zkPorter accounts.

zkPorter is the internal consensus mechanism for data availability within zkSync 2.0, enabling high TPS numbers. While zkSync 2.0 can handle ~1,000 to 5,000 TPS as a standard ZKR, zkPorter can accommodate ~20,000 to 100,000 TPS (depending on the complexity of each transaction).

5. Team​

6. Resources​

CTRL + J