Skip to content

Latest commit

 

History

History
55 lines (43 loc) · 3.93 KB

polygon-zkevm.md

File metadata and controls

55 lines (43 loc) · 3.93 KB
Raw

Polygon zkEVM

Glossary

  • Account: An object containing an address, balance, nonce, and optional storage and code. Can be a contract or an externally owned account (EOA).
  • Aggregator: Receives all of the transaction information and L2 state for sequenced batches proposed in the Consensus Contract and sends the data to the Prover. Receives the generated proof from the Prover and submits the proof to the Consensus Contract.
  • Batch: A group of L2 blocks, and their transactions, posted in a single L1 transaction into the Consensus Contract by the Sequencer.
  • Block: A bundled unit of information that includes a single transaction and consensus-related information. Blocks are generated by the Sequencer.
  • Consensus Contract: The PolygonZkEVM.sol contract deployed on Ethereum. Receives sequenced batches from the Sequencer and validity proofs from the Aggregator.
  • L2 Node: Polygon zkEVM node. A client that the network requires to implement the synchronization and govern the roles of the participants (Sequencers or Aggregators).
  • L2 Transaction: A transaction submitted on Polygon zkEVM.
  • Pending Transaction Pool: A list of pending transactions waiting for execution by the Sequencer.
  • Prover: Enforces all of the rules for valid transactions. Receives the L2 state and transaction data of proposed batches from the Aggregator to generate validity proofs.
  • Sequencer: Selects transactions from the Pending Transaction Pool for execution, generates blocks, and updates the L2 state. Rolls up generated blocks into batches and adds them to the Consensus Contract.
  • Synchronizer: Responsible for syncing data between the Consensus Contract, Aggregator, Sequencer, and the L2 nodes.

Transaction Lifecycle

  1. User creates and signs a transaction.
  2. User sends the transaction to a Polygon zkEVM node.
  3. The transaction is placed in the pending transaction pool.
  4. Sequencer selects the transaction from the pending transaction pool.
  5. Sequencer verifies that the transaction is valid and that the caller has an adequate balance to cover gas costs.
  6. Sequencer executes the transaction and generates a new block (only one transaction per block).
  7. Sequencer adds the executed block to a batch (batches are up to 300,000 bytes).
  8. Sequencer updates local L2 state.
  9. Polygon zkEVM nodes sync with the Sequencer's state.
  10. Sequencer collects up to 1,000 batches.
  11. Sequencer submits sequenced batches to the Consensus Contract.
  12. Polygon zkEVM nodes sync their L2 state by fetching data directly from the Consensus Contract.
  13. Synchronizer listens for committed sequenced batches events and triggers the Aggregator.
  14. Aggregator receives batch data from the Synchronizer and queries the L2 nodes to obtain the old L2 state for proving.
  15. Aggregator sends the batch data and old L2 state to the Prover.
  16. Prover uses the received batch data and old L2 state to generate a proof.
  17. Prover returns the proof to the Aggregator.
  18. Aggregator submits the generated proof to the Consensus Contract.
  19. Consensus Contract verifies that the proof is correct. a. If successful, the Consensus Contract updates the new L2 state root.
  20. Polygon zkEVM nodes retrieve consolidated state roots from the Consensus Contract via the Synchronizer to validate their local L2 state.

Architecture

Polygon zkEVM Architecture

Sequence Diagram

Polygon zkEVM Sequence Diagram

Entity Relationship Diagram

Polygon zkEVM Entity Relationship

Sequenced Batches

Polygon zkEVM Batches Diagram