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

[alexhooketh]

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

[gleenai[bot]]

Hello! It's great to hear about your project on ZKsync Era. Here are the answers to your questions:

1. Storage Reads (SLOADs) on ZK Stack: In ZKsync Era, storage reads (SLOADs) are not as costly as storage writes (SSTOREs) because they do not contribute to state diffs that need to be published on L1. However, optimizing the number of SLOADs can still contribute to overall efficiency in your smart contract execution.

2. Verifying ZK Proofs On-Chain: Currently, verifying complex ZK proofs like PLONK or Noir directly on-chain can be challenging due to gas costs and computational overhead. It's more common to verify these proofs off-chain or use simpler on-chain verification methods tailored to specific use cases.

3. Hash Functions: For ZK-friendly hash functions, you're correct that Keccak and SHA256 are not ideal. While Poseidon and Pedersen hashes are more ZK-friendly, they are not available as precompiles on EraVM. Implementing these as custom functions might be more expensive than using precompiled hashes. It's a trade-off between circuit efficiency and on-chain gas costs.

4. Finality Delays: The finality delay is primarily influenced by the time it takes to generate and verify the SNARK proofs, and the block time of the underlying L1 (Ethereum). Reducing this delay significantly might not be feasible without improvements in proof generation and verification technologies or changes in the underlying blockchain parameters.

For further technical details or specific optimizations, you might want to consult directly with the ZKsync development team or explore more in the ZKsync documentation.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[Jones098]

Yes

[bxpana]

@alexhooketh the bot responses to 1. and 3. are correct.

2. It will be cheaper when we have basic precompiles like MODEXP, ECADD, ECMUL.

3. Right now there isn't a short term plan for reducing the 24 hour withdrawal period which is put there for security reasons, but it is something planned to be reduced in the future. You can read more about the withdrawal delay details in our docs