Private blockchains vs ZK rollups: key tradeoffs

TL;DR

Enterprises looking for blockchain privacy face two fundamentally different bets: private blockchains say trust the operators, ZK rollups say trust the math. A recent clash between the co-founders of Canton and ZKsync brought this tension into the open, and both sides have billion-dollar institutions building on them right now.

This article breaks down what each approach actually does and where the real tradeoffs are.

The enterprise privacy problem

Enterprises that need blockchain capabilities — settlement, tokenized assets, multi-party workflows — but can’t expose their data on a public ledger have a problem. Think banks settling trades, asset managers issuing tokenized funds, or institutions running cross-border payments. The data is sensitive, often regulated, and not something you’d put on Ethereum for anyone to read.

Two approaches have emerged: private blockchains and ZK rollups. Both promise privacy, but they make fundamentally different bets on how to achieve it. A recent back-and-forth on X between Shaul Kfir (co-founder of Digital Asset, behind Canton) and Alex Gluchowski (inventor of ZKsync, behind Prividium) brought this tension into the spotlight.

Kfir warned about “the systemic risk of relying on ZKP for privacy.” His core point: “There will ALWAYS be bugs. The question is, when a bug exists, how big is the blast radius?”

The inventor of ZKsync fired back: “If this logic held, we would not have aviation.” What matters is redundancy and containment — multiple independent systems catching each other’s failures — and private blockchains relying on trusted operators lack both.

Let’s break down what each approach actually is, and where the tradeoffs lie.

Private blockchains vs ZK rollups: how each works

Private blockchains

On public blockchains like Ethereum or Bitcoin, anyone can join the network, run a node, and read every transaction ever recorded. That openness is a feature for decentralization, but a dealbreaker for enterprises that can’t afford to have their trading volumes, counterparties, or internal operations visible to competitors — or to anyone at all.

A private (or permissioned) blockchain flips this model. It restricts who can participate: only authorized parties can run nodes, submit transactions, or view data. Think of it as a members-only network where a group of banks could run a shared ledger completely invisible to outsiders. The network operator decides who gets in and what they can see, rather than the network being open by default.

Privacy in private blockchains comes from access control. Since only approved participants are on the network, sensitive data never touches a public chain in the first place. Some implementations go further — for example, Canton uses sub-transaction privacy, where each party only sees the parts of a transaction relevant to them. If Bank A and Bank B settle a trade, Bank C on the same network sees nothing about it.

The trust model is operator-based. There’s no mathematical proof backing each state transition. If an operator’s keys are stolen or an insider goes rogue, the system relies on access controls and encryption to keep bad actors out, not on cryptographic verification to catch them.

ZK rollups

ZK rollups were originally built to solve a different problem: scalability. Public blockchains like Ethereum can only process a limited number of transactions per second, so ZK rollups batch thousands of transactions off-chain and submit a compact validity proof back to the base layer. This proof cryptographically guarantees that every transaction in the batch was executed correctly — without the base layer needing to re-execute them one by one.

📖 For a deeper dive into how this works, check out zkEVM and ZK Rollups explained.

But here’s where it gets interesting for enterprise privacy: the same cryptographic machinery that lets ZK rollups compress transactions also lets them hide them. A validity proof says “all of these state transitions are correct” without revealing what the transactions actually were. This means you can have a private execution environment where transactions stay confidential, while still anchoring the integrity of the entire chain to a public, decentralized base layer like Ethereum.

Prividium is one example that tailors this for institutional use. Technically, it’s a validium — transaction data stays off-chain in the operator’s infrastructure rather than being posted to Ethereum, with only proofs and state commitments anchored on-chain. Each institution deploys its own private chain — Deutsche Bank has launched for tokenized fund management, UBS completed a proof-of-concept for tokenized gold. Transactions stay private, but the chain periodically posts a cryptographic proof to Ethereum verifying that every state transition was valid, without revealing what the transactions were. Even if the operator misbehaves, the proof catches the inconsistency. The math handles integrity, not trusted operators.

Auditability, trust, and infrastructure: where they diverge

Auditability

Auditability is where private blockchains make their strongest case. Kfir’s point: even if the ZK proof system is flawless, a bug anywhere else in the stack causes silent failures. A ZK proof only proves that the bytecode was executed correctly — but if the compiler that generated that bytecode had a bug, the proof will “correctly” verify a wrong action. This isn’t theoretical: a security audit of ZKsync’s compiler uncovered a vulnerability that could have allowed users to withdraw locked collateral. The math worked perfectly — it just proved the wrong thing. This concern isn’t unique to Prividium or ZKsync — it applies to any ZK rollup. Auditability is only as strong as the full stack, not just the proof layer.

Trust minimization

Trust minimization is where ZK rollups push back. Gluchowski argued that private blockchains have “no cryptographic verification layer and no independent check.” In a private blockchain, if a trusted operator is compromised — whether through stolen keys, an insider going rogue, or a software vulnerability — there’s no independent system that catches the problem. The operator controls the data, and if that control is breached, the damage can spread before anyone notices. This isn’t a weakness specific to Canton — it’s inherent to any architecture where integrity depends on who runs it rather than what the math says.

ZK architectures approach this differently by stacking multiple independent defenses on top of each other. First, institutional nodes run within each organization’s own regulated environment, so no single operator has unilateral control. On top of that, zero-knowledge proofs act as a separate integrity layer — every batch of transactions must produce a valid proof before it’s accepted, meaning even a compromised operator can’t push through an invalid state transition without the math rejecting it. And as ZK proof systems mature, multiple independent provers can verify the same computation using different implementations, so a bug in one prover gets caught by another. The idea is that for a failure to go undetected, multiple independent systems would have to fail simultaneously — which is significantly harder to exploit than compromising a single trusted operator.

Infrastructure

Infrastructure is where the day-to-day reality diverges most. Private blockchains are simpler to operate — no external chain dependency, no proving infrastructure, no gas fees. But you own everything: nodes, key management, upgrades, and the permissioning layer. And if you’re on Canton, your contracts are written in Daml, a domain-specific language with a much smaller talent and security community than Ethereum’s.

ZK-based deployments like Prividium add complexity: you need proving infrastructure to generate ZK proofs for each batch, plus the connection to Ethereum for settlement — meaning gas costs, proof submission timing, and finality monitoring. But you get EVM compatibility out of the box: Solidity, Hardhat, existing auditing tools, and a massive developer ecosystem. Chainstack supports ZKsync Era with dedicated nodes and archive access. No separate language to learn, and switching providers doesn’t require rewriting contracts.

That EVM point goes deeper than convenience. Ethereum’s smart contract infrastructure has been stress-tested by sophisticated adversarial actors for over a decade, with hundreds of billions at stake. Every exploit fed back into the ecosystem as better audit standards, formal verification tools, and compiler safeguards. Daml, by contrast, is open source but has a far smaller ecosystem. As Gluchowski put it: every maturity concern Canton raises about ZK proofs applies to their own stack — except Daml will face those growing pains with orders of magnitude fewer eyes watching. This generalizes beyond Canton — any private blockchain using a domain-specific language faces the same disadvantage against the EVM ecosystem’s depth.

When to choose private blockchain vs ZK rollup

Private blockchains make more sense when the environment is tightly regulated and data can’t leave a controlled perimeter. Regulators want to know exactly where data lives, who can access it, and who is accountable when something goes wrong — all three answered by design in a private blockchain.

Choose private blockchain if:

• Participants already share infrastructure trust (e.g. a SWIFT network equivalent)
• Data must stay within a specific jurisdiction or controlled perimeter
• All participants are pre-approved and sufficiently trusted
• Your regulatory framework doesn’t accept public chain anchoring
• Operational simplicity matters more than cryptographic verification

ZK rollups are the stronger pick when trust between participants is limited or when you need the outside world to verify what happened without seeing the details. The math handles integrity — no single operator can manipulate state without the proof system catching it.

Choose ZK rollup if:

• Participants don’t fully trust each other or share a single operator
• External parties need to verify claims without seeing underlying data
• Cross-organization settlement or interoperability is required
• Cost efficiency matters at scale — more volume means cheaper per transaction
• You want EVM tooling, Solidity, and the existing audit ecosystem

Some parameters don’t have a clear winner. Performance depends heavily on configuration — private blockchains offer predictable throughput because you control the hardware, while ZK rollups are improving fast but still subject to proving times and L1 settlement delays. Maturity is similarly hard to call: private blockchains have years of production deployments, but ZK rollups inherit a decade of battle-tested EVM tooling, auditing standards, and smart contract infrastructure — so while the rollup layer itself is newer, the stack underneath it isn’t. And upgradability cuts both ways — private blockchains require coordinating upgrades across all participants, while ZK rollups can push updates faster but concentrate upgrade authority in smaller governance bodies.

Here’s a summary of how the two approaches stack up across the dimensions covered in this article:

Conclusion

The Canton vs ZKsync debate isn’t really about which technology is better — it’s about which threat model you’re designing for. If your biggest risk is regulatory exposure, private blockchains solve that by design. If your biggest risk is operator failure, ZK architectures replace human trust with mathematical verification. Neither is winning yet — Deutsche Bank is live on Prividium while major institutions run on Canton, and the market is still deciding.

What’s clear is that the tradeoffs are real on both sides. Private blockchains offer simplicity and regulatory clarity but concentrate trust in operators with no independent check. ZK rollups offer cryptographic guarantees but add stack complexity and inherit proof system risks that the ecosystem is still maturing through. The right choice depends on your regulatory environment, your participants’ trust relationships, and how much complexity your team can absorb.

What stays constant is the infrastructure underneath. Whether you’re running nodes for a private consortium or building on a ZK rollup that settles to Ethereum, the reliability of your RPC layer, archive access, and debug tooling shapes what you can actually build and operate. Chainstack provides dedicated nodes, archive data, and enterprise deployments — so your infrastructure keeps up with whichever architecture you choose.

FAQ

Related Reading

• zkEVM and ZK Rollups explained
• Demystifying Zero-Knowledge Proofs
• Layer 1 vs Layer 2: Ethereum Infrastructure, RPC, and scaling
• Getting started with ZKsync on Chainstack
• ZKsync Era tooling