The batches of transactions submitted to Ethereum by the sequencer are not necessarily valid (i.e. they have not been proven to be correct) until a ZK proof is generated and verified by the L1 rollup contract.

ZK proofs are used in a two-step process to ensure the correctness of batches:

  1. Proof generation: An off-chain prover generates a ZK proof that a batch of transactions is valid.
  2. Proof verification: The proof is submitted to the L1 rollup contract and verified by the on-chain verifier.

Since the proof verification is performed on Ethereum, Abstract inherits the security guarantees of the Ethereum L1.

​
Proof Generation

The proof generation process is composed of three main steps:

1

Witness Generation

A witness is the cryptographic term for the knowledge that the prover wishes to demonstrate is true. In the context of Abstract, the witness is the data that the prover uses to claim a transaction is valid without disclosing any transaction details.

Witnesses are collected in batches and processed together.

Witness Generator Source Code

View the source code on GitHub for the witness generator.

2

Circuit Execution

Circuits are executed by the prover and the verifier, where the prover uses the witness to generate a proof, and the verifier checks this proof against the circuit to confirm its validity. View the full list of circuits on the ZK Stack documentation.

The goal of these circuits is to ensure the correct execution of the VM, covering every opcode, storage interaction, and the integration of precompiled contracts.

The ZK-proving circuit iterates over the entire transaction batch, verifying the sequence of updates that result in a final state root after the last transaction is executed.

Abstract uses Boojum to prove and verify the circuit functionality, along with operating the backend components necessary for circuit construction.

zkEVM Circuits Source Code

View the source code on GitHub for the zkEVM circuits.

Boojum Source Code

View the source code on GitHub for the zkEVM circuits.

3

Proof Compression

The circuit outputs a ZK-STARK; a type of validity proof that is relatively large and therefore would be more costly to post on Ethereum to be verified.

For this reason, a final compression step is performed to generate a succint validity proof called a ZK-SNARK that can be verified quickly and cheaply on Ethereum.

Compressor Source Code

View the source code on GitHub for the FRI compressor.

​
Proof Verification

The final ZK-SNARK generated from the proof generation phase is submitted with the proveBatches function call to the L1 rollup contract as outlined in the transaction lifecycle section.

The ZK proof is then verified by the verifier smart contract on Ethereum by calling it’s verify function and providing the proof as an argument.

// Returns a boolean value indicating whether the zk-SNARK proof is valid.
function verify(
    uint256[] calldata _publicInputs,
    uint256[] calldata _proof,
    uint256[] calldata _recursiveAggregationInput
) external view returns (bool);

IVerifier Interface Source Code

View the source code for the IVerifier interface

Verifier Source Code

View the source code for the Verifier implementation smart contract

Was this page helpful?

SequencerL1 Rollup Contracts