Data Structure, Hashing and Compression algorithms

Developer Support
1

Hi everyone!
I am working on a ZK-based Cross rollup communication protocol (Wisp)
Can someone from the team help me out with the following so we can integrate the CRC protocol with Linea as well:

  • What is the data structure used for the storage of the rollup? Is it MerklePatriciaTrees with Poseidon hashing or something else?
  • Are developers able to access the state root for a given block number from the L1 rollup contract or some compression algorithm is used for batching multiple blocks into one, meaning no direct access to blocknumber -> state root mapping?
  • Are the ecadd ecmul and ecpair precompiles verified by the prover?

Thank you!

6 Likes
2

Hey Daniel,

  • We use a sparse Merkle tree structure and the MiMC hash function
  • Yes, you will be able to validate the storage proof for on account on L2 via the L1 rollup contract. This mechanism is being worked on for integrating ENS. It is not recommended to use eth_getProof on the L2 as the target behavior of block hash will simply be a hash of the blocknumber.
  • ecmul and ecpair precompiles execute but are not yet proven (i.e. they’re trusted). The gnark team is close to implementing these and will be added to the coverage in the coming months
4 Likes
3

Please refer to this post too: Compiling Gnark proover using Tinygo - #5 by r00sh to learn more about gnark and tinygo

2 Likes
4

@0xroo Does it mean that the witness nodes for doing a Merkle Inclusion proof can be retrieved using eth_getProof or there will be some other way of getting the data for executing the proof validation?

1 Like
5

There will be another way. It’s currently being designed by the team - we can publish more details on this soon.

2 Likes
6

A post was merged into an existing topic: Share Your Feedback Here! :thought_balloon:

7

Hey, is there any update on this? We are building a stack on L1/L2 (already working on L1s and some L2). We need to verify the L2 root against the L1 rollup contract. You guys currently provide currentTimestamp and currentL2BlockNumber and stateRootHashes slots/mapping, but when we get the stateRootHashes[ currentL2BlockNumber ] it doesn’t match the getBlockByNumber rpc call returning the state root for the block. Are we missing something? Also, do you have an example implementation of the zktrie you are using? Thanks!