Protocol FAQs

This compilation addresses common questions about the Prom zkEVM protocol. For further details, please refer to our extensive documentation.

How Are Transactions Collected and Ordered in Prom zkEVM?

  • Users generate and sign transactions in their wallets using private keys.

  • These transactions are then sent to the Trusted Sequencer's node through their JSON-RPC interface.

  • They are stored in the pending transactions pool, awaiting the Sequencer's review.

  • The Trusted Sequencer selects transactions from the pool, deciding on their execution and order.

  • Finally, the Sequencer batches and sequences these transactions.

Is There a Specific Interval for Sequencer Batch Creation?

  • The Sequencer maintains an open batch, adding transactions until it's full or a significant timeout occurs.

  • Batches accumulate until reaching 128K or experiencing a major timeout, after which a sequencing transaction is sent to L1.

  • From a user's L2 perspective, a new L2 block (different from an L2 batch) is finalized and communicated, giving the user a sense of transaction finality, even if the L2 batch isn't closed yet.

Stages of Transaction Finalization on L1?

  • Trusted State: Instantaneous state provided by the Trusted Sequencer, not requiring L1 transactions.

  • Virtual State: Transactions on L1 are immutable in order and final; anyone can calculate this state.

  • Verified State: When the virtual state is confirmed by the smart contract, funds become withdrawable.

How Does a Sequencer Validate Transactions for Proof Generation?

  • The Sequencer checks the transaction's format and necessary information.

  • It verifies transaction validity by confirming sufficient funds for gas and the validity of the called smart contract.

  • It ensures the transaction is not a duplicate or a double-spend.

  • Valid transactions are then applied to the current state of Prom zkEVM, updating smart contract states and account balances.

When Do Transactions Achieve Finality in Prom zkEVM?

  • Trusted State finality occurs once the Sequencer sequences a transaction.

  • Virtual State finality happens when the transaction is present and finalized on L1.

  • Consolidated or Verified State finality is necessary for withdrawals, occurring after the Prover converts the implicit state to an explicit state.

Are Sequencers and Provers Internal or External, and How is Decentralization Ensured?

  • Initially, both Sequencer and Prover in Prom zkEVM will be centralized.

  • Future plans include decentralizing the Sequencer and creating a market for Provers.

  • A decentralized system of Provers is crucial for overall network decentralization.

Can a zkNode Function as Both Sequencer and Aggregator?

  • Potentially, a zkNode can fulfill both roles, depending on the zero-knowledge proof protocol's implementation.

  • In some protocols, a node's role is predetermined to ensure network security and efficiency.

What Are Forced Batches?

  • Forced Batches are L2 batches included in an L1 transaction, mandated for inclusion by the Trusted Sequencer.

  • This mechanism ensures user withdrawal capability even if censored by the Sequencer, providing censorship resistance.

Last updated