Introducing Private Smart Rollups on Tezos

TL;DR: A new whitelisting feature allows Smart Rollup builders to choose their desired level of decentralization.

The majority of blockchains don’t provide transaction privacy by default. Tezos is no exception. An address is a pseudonym, and transactions are public. A resourceful and determined actor will often be able to connect an address to a real identity, and then all transaction history is freely available.

This is the case whether you are transacting on Layer 1, in an optimistic rollup, or in a zk-rollup (also called validity rollup). By default there is no privacy and special solutions are required to achieve it.

So how can we achieve privacy in Smart Rollups for use cases that require it?

A common way to achieve privacy is to use zero-knowledge proofs, also called zk-proofs¹. In short they enable you to prove properties about some data without revealing the data itself. Zk-proofs have been adopted by many blockchain projects, including Tezos’ Layer 1, in order to provide optional privacy for simple transactions. However, using zk-proofs quickly becomes complicated and resource intensive when used for complex transactions and smart contracts with many participants.

Some techniques exist that can be applied, such as multi-party computation where a group of participants perform collaborative computation over pooled data while preserving confidentiality for individual inputs. But this is a complex solution that relies on advanced cryptography. It’s costly to implement, and it doesn’t scale well.

So, is there not a simpler way to achieve privacy in an optimistic rollup? There is, but it requires us to relax some security assumptions, and it is only useful for some specific use cases.

Trading (some) decentralization for privacy

The Nomadic Labs adoption team has worked with financial institutions with specific requirements for privacy, and we have developed a simple solution that satisfies their needs. It is a Smart Rollup, but we relax assumptions regarding 1) publication of transaction data, and 2) decentralization of the rollup.

Transaction data for the rollup is not posted on Layer 1 or otherwise publicly, and Layer 1 provides no guarantees about its availability for later verification. Instead transaction data is posted to a non-public Data-Availability Committee (DAC). A DAC is typically run by a consortium of interested parties, which retain control over the data. This enables privacy for incoming transaction data at the cost of verifiability for outsiders.

Imagine a consortium of banks that use a Smart Rollup for fast and easily auditable settlement. As the transaction data is confidential, it is posted to a non-public DAC. The only thing made public are commitments – hash values representing the rollup’s state that reveal nothing about the underlying data.

Using a DAC has been possible on Tezos for a while, but it isn’t enough for keeping a rollup private. The permissionless nature of Smart Rollups means that anyone could create challenges to rollup commitments, even honest ones, which could force rollup operators to reveal some data publicly or face an economic penalty. Since only parties with access to the DAC can meaningfully challenge commitments in the first place, it does not make sense to let anyone do so.

For this reason, the Oxford 2 protocol proposal contains a small change to the protocol allowing Smart Rollup developers to define a whitelist of allowed operators (and hence potential challengers). It’s a simple and private solution for a consortium-style rollup that comes with the benefits of being secured by Tezos consensus, and having a direct bridge to Layer 1 and the wider Tezos ecosystem.

To be clear, implementing a whitelist effectively makes the Smart Rollup permissioned – not fully decentralized. Having it as an option lets Smart Rollup builders choose their desired level of decentralization based on their particular use case.

How Smart Rollup whitelists work

Whether a Smart rollup is private (permissioned) or public (permissionless) is defined at deployment. If a whitelist is defined, the rollup is considered private by the protocol. If not, it is considered public.

For a private rollup, only addresses on the whitelist can be operators for the rollup, including publishing commitments, challenging commitments, and participating in refutation games.

It is the responsibility of the rollup kernel to maintain the whitelist. It can be updated with a specific outbox message, which includes a new whitelist replacing the existing one. Kernels must therefore implement their own access control logic to add and remove addresses.

Note that a private rollup can become public, but not the other way around.

• Private rollups becoming public. If the specified outbox message is sent without containing a whitelist, the rollup becomes public. If a rollup is never meant to become public, its kernel can be designed to disallow empty whitelist messages.
• Public rollups cannot become private. An outbox message with a whitelist for a public rollup will fail. This is to prevent a rollup becoming private after it has been advertised as public.

More control for builders and testers

The whitelisting feature doesn’t just benefit those working with confidential data.

Some developers may prefer to initially deploy a “beta” rollup with a whitelist, even if still on testnet, and only later make it public. This kind of “training wheels” approach is often used for launching blockchain projects.

Others may opt for a permanent semi-private setup, which can reduce risk for the rollup operator. The transaction data are available for all to check, but only whitelisted operators can initiate refutation games. Transparency is kept, but bad-faith actors can’t leverage kernel bugs or errors by the rollup operators to cause problems, such as incurring a loss of the 10,000 tez stake required to operate a rollup.

With the whitelisting feature, builders have the option to deploy rollups with the level of decentralization that fits their use case, whether it has to do with privacy, security or simply comfort.

We welcome any kind of feedback that helps us make Tezos the best possible solution for blockchain builders. If you are interested in launching a project on Tezos and have questions or suggestions, don’t hesitate to reach out.

Notes