Alternatives to private Tezos blockchain instances

The California Department of Motor Vehicles is experimenting with a private Tezos blockchain.

Since a private Tezos instance will reduce the immutability and scalability (and some may say “defeat the purpose”) of using the public Tezos blockchain, is it advisable for entities that want the privacy and control of a private chain to run their own rollup?

Would running a rollup give an entity like the DMV the control it requires while also giving it the scaling benefits and immutability benefits of using the main, public, Tezos blockchain?

If a rollup doesn’t provide privacy, what other options does an entity have which would allow them to take advantage of the scalability and immutability of the public chain, without restoring to running a completely separate, private instance of the public chain?


I think and hope that the private instance is temporary and that the DMV will eventually use a rollup that’s secured by the public chain.


@NomadicLabs if using a rollup is a feasible alternative to a private Tezos instance, it may benefit all future potential users of private Tezos instances for you to put together some documentation explaining why a rollup is preferable.

With SORU, you don’t get privacy out of the box. While it’s easy for your rollup node to compute on private data via the reveal channel mechanism, anyone can force you to reveal that data by challening your commit. Either you’ll reveal the private data, burning their stake, or you won’t, and the rollup will be frozen (and you’ll both lose your stake).


So if a SORU doesn’t give an enterprise privacy out of the box, is there a way to apply privacy to them?

In a broader context, is there another alternative that an enterprise can use to achieve privacy and scalability without implementing a private version of the Tezos chain? I’ve updated my original question as well.

Shouldnt be a Sapling Soru be possible and solve the privacy issue?

@Britcoin brings up a great point - you could run ZK proofs (i.e Sapling) to do private transfers on a rolllup. There’s are some engineering challenges here though: namely, rollups operate in a VM, which will have worse performance than the native code used in L1. Maybe you can make up for it with the vertical scalability enabled by rollups. Further, we would need to benchmark Sapling to see how many ticks of the WASM interpreter it consumes. For scale, checking an ED25519 signature costs a few million ticks, out of the 11 billion available per block. I imagine Sapling could take an order of magnitude or more above that.

ZK proofs are pretty complex - well above my head. Maybe one of the awesome crypto people at Nomadic Labs can weigh in here.