3

ZK rollups don’t store transaction on L1. They just need the Zk proof the check correctness of state transition and additionally state diff so users would be able to reconstruct the rollup state in case the operator stops his work. But if the individual transactions are not stored on L1, how would I be able the check on L1 that my rollup transaction has been executed / included in the last rollup batch?

I found the following info on ethereum.org docu: "Besides computing state roots, the ZK-rollup operator also creates a batch root—the root of a Merkle tree comprising all transactions in a batch. When a new batch is submitted, the rollup contract stores the batch root, allowing users to prove a transaction (e.g., a withdrawal request) was included in the batch. Users will have to provide transaction details, the batch root, and a Merkle proof showing the inclusion path."

So, it says that a user checks/proves transaction inclusion by providing a Merkle proof. But how would a user be able to generate a Merkle proof? She is unable to do this because she does not see all other transactions of the batch because in Zk rollups transactions are not stored on L2.

Does anybody know more here?

Improve this question

2 Answers 2

Reset to default
1

Not all ZK Rollups post state diffs, some of them post transaction data as Optimistic Rollups, e.g. Polygon zkEVM, Linea and Scroll. For the others that do publish state diffs, there is indeed no way to independently check if a transaction has been included in a state diff. Heuristics can be used, for example by checking that the nonce of an account has increased, but there are edge cases in which this approach is less useful. If there is a transactions (or batch) root, you can ask the sequencer for a Merkle proof and be convinced that the transaction is included. If the sequencer withholds this information from you, then you have no idea.

Improve this answer
1
  • Thx a lot, donnoh. Not being able to trustlessly proof that a certain transaction has been settled on L1 seems to be really a bad design. Maybe the following is a solution applied by zk rollups which publish state diffs: In addition to the state diff, they could publish to L1 a Merkle proof for each and every transaction included in the batch. Maybe this needs much less data compared to puclishing the full transactions because hashed in Merkle proofs are very small? Any idea whether this makes sense / is applied? Commented Jan 31, 2024 at 13:44
0

ZK rollups post transaction data on L1, either using calldata or (more recently) blobs. So they do store data on L1, and you should be able to generate the merkle proof from this data.

If they don't do that, they aren't a rollup but a validium.

Examples:

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.