Polygon zkEVM Glossary
Layer 1 or the base blockchain is where the rollup smart contracts are installed. It's Ethereum or a testnet of Ethereum, but it could be any EVM-compatible blockchain.
Layer 2 refers to the rollup network; in our case, the Polygon zkEVM network.
Consensus Contract (PolygonZkEVM.sol)
Consensus mechanism utilized by the Polygon zkEVM network. It is enforced by the smart contracts deployed on Layer 1 (in this case, Ethereum).
A group of transactions that are executed / proved, using the zkProver and sent to / synchronized from L1.
zkEVM participant who is responsible for selecting transactions, putting them in a specific order, and sending them to L1 in batches.
A sequencer with special privileges. There can be only one trusted sequencer. The privileges granted to the trusted sequencer allow it to forecast batches that will be applied to L1. In this way, it can commit to a specific sequence before interacting with L1. This is done in order to achieve fast finality and reduce costs associated with using the network (lower gas fees).
A sequencer role that can be performed by anyone on the network. Although it has competitive disadvantages compared to the trusted sequencer (like slow finality, or MEV attacks), its main purpose is to enforce decentralization and censorship resistance to the network.
Group of batches and other metadata that the trusted sequencer sends to L1 in order to update the state.
A batch that is sent by permissionless sequencers to L1 in order to update the state.
Same as an L1 block, but for L2. It is mostly used by the JSON-RPC interface.
Currently, all L2 Blocks are set to only include one transaction. This is done to achieve instant finality. Therefore, it's not necessary to close a batch to allow the JSON-RPC to expose results of already processed transactions.
L2 state committed by the trusted sequencer.
State reached after processing transactions that have already been submitted to L1. These transactions are sent in batches by either trusted or permissionless sequencers. Those batches are also called virtual batches. This state is trustless as it relies on L1 (here Ethereum) for security.
State which is proven on-chain by submitting a ZKP (Zero Knowledge Proof) that proves the execution of a sequence of the last virtual batch.
A transaction that can't be processed and doesn't affect the network state. Such a transaction could be included in a virtual batch. The reason for a transaction to be invalid could be related to:
- Ethereum protocol: invalid nonce, not enough balance, etc
- limitations introduced by zkEVM: each batch can utilize a limited amount of resources such as the total amount of keccak hashes that can be computed.
A transaction that is executed, but is reverted (because of smart contract logic). The main difference between invalid and reverted transaction is that reverted transaction modifies the state, at least to increment the nonce of the sender.