4

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.

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

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).

Improve this question

2 Answers 2

Reset to default
2
+50

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.

Improve this answer
2
  • 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? Commented 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. Commented Nov 28, 2022 at 7:56
1

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/

Improve this answer
3
  • 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. Commented Nov 28, 2022 at 2:23
  • What you suppose may not be currently supported, unless you’re looking for a hypothetical answer. Commented 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. Commented Nov 28, 2022 at 21:20

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.