[General] Storage read costs, ZK friendly hashes, finality delay

[bxpana]

Discussed in #638

^{Originally posted by alexhooketh July 27, 2024}

Environment

Mainnet

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

Hey! I'm the founder of Untron.finance, a trustless ZK bridge between USDT on Tron and Ethereum L2s (ethresear.ch). We're building our project on top of ZKsync Era and came across a few engineering questions that would help us design the system as efficient for ZK Stack as possible.

1. I realize that due to a state-diff based system the less SSTOREs in different slots we have, the better. Is the same fair for SLOADs, however? Are storage reads expensive on ZK Stack?

2. Is it feasible right now to verify ZK proofs on-chain? We have two kinds of proofs: SP1 (PLONK) verified a few times an hour, and Noir (used only as a low-demand fallback every 20 secs when there's <1 order/20 sec).

3. We need some hash function which is easy to perform both on EraVM and our circuits. Keccak and SHA256 are not ZK friendly, but Poseidon/Pedersen/etc are not available as precompiles on EraVM, so I'm wondering if they'd actually be cheaper than precompiled unfriendly hashes.

4. Wen smaller finality delays? 24hrs make cross-L2 USDT transfers highly illiquid and thus have pretty large fees ; (

Repo Link (Optional)

No response

Additional Details

No response