[ZK Stack] - Understanding Validium mode and privacy

[LimonChillo]

Team or Project

No response

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

1.81.0

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

Hi everyone,

I’m trying to get a better understanding of zkStack, it’s Validium capabilities and its impact on transaction privacy within a zkstack ecosystem.

In this ZkChain overview page from in the documentation, it’s mentioned multiple times that Validiums are a “privacy” (-oriented) solution.

"Validium offers a privacy-oriented solution…"
"Validium Mode: Naturally provides privacy as long ...”

So far I have thought of Validiums as a “scaling” solution where the “privacy” aspect comes rather as a by-product of not having the data on chain and so having a better control over it.

I’ve already learned, that the default configuration is the NoDA Validium, which persists the data in the DB (l1_batches table --> pubdata_input)
What I want to understand better, is the following. If every participant of a Validium ecosystem has access to all of that data from this DB, what would that mean for privacy? Is it possible to correlate any practical information from that data? Like any transaction metadata or for example transaction volumes of specific accounts?

Thanks for you help already :)

Expected Behavior

See Description

Current Behavior

See Description

Repository Link (if applicable)

No response

Additional Details

No response

Prior Research

• Yes, I searched for similar issues and did not find any matching ones.

[gleenai[bot]]

Hello,

Thank you for your detailed inquiry about the Validium mode in ZKsync and its implications for privacy within the ecosystem.

Validiums in ZKsync are primarily designed as a scaling solution by allowing data to be stored off-chain while still ensuring its availability through various means. This indeed can offer a level of privacy since the data is not directly stored on the blockchain, which makes it less accessible to the public.

However, the privacy aspect of Validium is not absolute. If every participant in a Validium ecosystem has access to the data stored in the database (as in the NoDA Validium configuration where data persists in the l1_batches table under pubdata_input), there is potential for data correlation. Participants could potentially analyze transaction volumes or metadata related to specific accounts, depending on their access level to the database and the nature of the stored data.

For true privacy, additional measures would need to be implemented to restrict access or encrypt the data, ensuring that only authorized parties can view or process it. ZKsync is serious about privacy as a part of its roadmap, aiming to implement more robust privacy features in the future.

For more detailed technical insights and updates on privacy features, you might want to keep an eye on the ZKsync developers discussions on Github.

If you have further questions or need more specific details, feel free to ask!

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.

[bxpana]

Thanks for the question here, going double check on this and get back to you.

[bxpana]

Appreciate your patience. If everyone can access the data from the DB then there is no privacy.

As you mentioned "the "privacy" aspect comes rather as a by-product of not having the data on chain and so having a better control over it", which is exactly how privacy is obtained with validiums.

With ZK Stack, a chain builder can do something where there is only one entity that controls access of the DB, RPC, and the data is not publicly available through the RPC (like what GRVT has)

[LimonChillo]

Hi @bxpana

Thanks for the clarification. I thought about a couple of of different deployment architectures without having that "one entity that controls access", therefore it's been important for me to know. For example, I thought about hosting the DB and the Sequencer by different entities. I see, as of now they would need a central entity managing the access, thats fine for now :)

Sorry for offtopic here, but could you please have a quick look at my question in #281 (reply in thread)
in short: Whats the best way, as of today, to dockerize my local zk-chain ecosystem and push it to the cloud?