The stateroot transition is verified by witness (pre- and post- state root) and proof, but validators also should verify the transaction data which is proposed by operators. How can verify the transaction is included in the stateroot transition? Or, should the transaction data be verified in another way?

AFAIK, there was certainly how to verify the stateroot transition, but no explanation for verifying transaction data. https://medium.com/fcats-blockchain-incubator/how-zk-rollups-work-8ac4d7155b0e

The proof is just verifiable for the existence of a sequence of valid transactions. So, we can't verify the transaction data by proof.


If the proof satisfies the circuit (i.e., it is valid), it means that there exists a sequence of valid transactions that transition the rollup from the previous state (cryptographically fingerprinted by the pre-state root) to a new state (cryptographically fingerprinted by the post-state root).

2 Answers 2


in ZK-rollup we have 2 Merkle trees, one is stored accounts, and the other stores balances and transactions, with checking pre and post-Merkle root the validation proved(as you mention),proving mechanism running in off chain VM(that compatible with EVM). in summary, the prover multiplies the values ​​by a number in such a way that the verifier performs the proof without knowing it. This requires cryptographic mathematics, in summary, it uses the Homeomorphism mechanism that proves E(s) without knowing "s", prover multiple E(t(s)),E(h(s)),E(w(s)) and E(v(s)) in number and validators approve them without know number. it is a complicated subject that I can explain here with formulation and mathematics and I recommend reading this article for deep learning about ZK proof.

  • Thanks for the information. Do you mean, the proof is derived from the L2 transactions batch and L1 verifier contract can check if the posted L2 transactions batch corresponds to the proof?
    – amanec
    Nov 28, 2022 at 2:24
  • yes, the L2 contract that implements in off-chain VM, aggregate and rolls up the transactions, and after that, the l1 contract prove the theme. Nov 28, 2022 at 7:56

ZK-rollups publish state data for every transaction processed off-chain to Ethereum. With this data, it is possible for individuals to reproduce the rollup’s state and validate the chain themselves. Ethereum makes this data available to all participants of the network as calldata and transaction data is published on Ethereum as calldata. While calldata isn’t stored as part of Ethereum’s state, it persists on-chain as part of the Ethereum chain's history logs. ZK-rollups use calldata to publish compressed transaction data on-chain.

See: https://ethereum.org/en/developers/docs/scaling/zk-rollups/

  • Certainly, we can verify that the L2 transactions were correctly executed, by re-execute the posted L2 transactions batch. But the L1 Contract should check the L2 transactions batch, not by re-execution (because it's the essence of rollups). I suppose proof includes some hash value of the L2 transactions batch, and L1 verifier contract can verify the posted L2 transactions batch by checking if the hash value of it corresponds to the proof's data.
    – amanec
    Nov 28, 2022 at 2:23
  • What you suppose may not be currently supported, unless you’re looking for a hypothetical answer. Nov 28, 2022 at 15:24
  • Do you mean, present implementations of L1 verifier contract do not check correspondence of transactions batch and proof's data? I would like to know the true concept of rollups method, but it might be under investigation.
    – amanec
    Nov 28, 2022 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.