Igor Mandrigin

WIP

Privacy from operators

[privacy, operators, evm] · markdown

Part 1

One of the properties of private systems is privacy from operators. Sometimes also called operator privacy. I will explain what that is, how we do that now, and what else we could do.

I will mostly focus on EVM networks, but a lot of this is generic and applies elsewhere.

This is part of the research for the roadmap of Gateway’s Open Privacy Suite.

Who’s your operator §

To clarify the requirements, guarantees and limitations, we can do a little threat modeling.

Opening a little book of Adam Shostack: one way of brainstorming threat models is based on the attackers. Since we are defending from operators here, that is the best approach.

So our attacker is an operator. But who or what is that? Can we enter the room, or open the Slack chat or our ArgoCD logs, and point our fingers at someone?

The answer is not as obvious as it looks at first glance.

Types of operators §

1. Block producers.

When you are running a DLT or a blockchain, there is a party or a group of parties that produces blocks. It could be a single sequencer on a high-performance L2, run either by you or by an operator company (like Gateway).

If you are running a private network on a stack like Besu, it is each of the companies running a validator in QBFT or another consensus network.

If you settle on a public chain like Ethereum — this is the set of all validators, as well as block builder networks.

2. Provers.

In the witness-fed proving pipeline, the prover consumes a batch and the state needed to execute it. Whoever runs that process is part of the operator threat model. A proof accepted onchain establishes correct execution; it does not establish privacy from the party generating it.

3. RPC node operators.

This is just in the name. If you use RPC node operators (Gateway is an RPC node operator for Stellar, for example) to scale node operations globally. Even if you just give your RPC node to another party to run — a crypto exchange, an interop solution like LayerZero, another member of a banking consortium — they also become operators of your chain.

Those parts were obvious. They follow from the architecture of the chain itself. But we want chain + privacy. Often, by adding privacy, you extend the list of operators by the following.

4. Privacy providers and components

  • Key holders — encryption keys, viewing keys, “auditor” keys, HSM/KMS. Whoever can decrypt is an operator. Cloud KMS adds the cloud admin. Not all bare-metal providers can provide privacy from themselves.
  • Threshold / MPC parties — no single party sees plaintext unless enough of them collude. The operator set is the committee plus the collusion assumption.
  • TEE operators — side channels, hardware hosting, communication between components.
  • Notaries / decryptors / relayers — anyone who must open, endorse, or route a private payload. Metadata (timing, size, graph) leaks even if the payload is encrypted.
  • Ceremony participants — trusted setup and its participants.
Part 2

How to achieve it? §

The blockchain industry developed multiple different techniques of how to achieve privacy from operators. In this section, we will walk through them.

There are many options to choose from, but we can group them roughly into five groups.

1. State Minimization.

2. Trusted Execution Environments (TEEs).

3. Secure Multi-Party Compute (MPCs).

4. Fully Homomorphic Encryption (FHE).

5. Application-specific methods.

State Minimization §

This is one of the most straightforward and simple to understand techniques. Operators work on the "need to know basis". They receive the state they require and are authorized to receive. They don't receive anything unauthorized. There is no special encryption or protection needed, the data is just not there.

The difficult part about this (otherwise pretty simple and straightforward) method is not privacy. Is how to keep the protocol working. We have decided a couple of ways of solving that too.

Client Side Execution & ZK-Proving §

Zero Knowledge Proofs (verification) to the rescue! Being able to prove the correctness of the computation without disclosing the computation private inputs and outputs is a very handy property for state minimization.

Client-side execution, used in edge blockchains (such as Miden), is exactly that. The client itself (and not an operator) keeps its own state. Then it makes some changes to that state (transacts, mints token, buys a cute cat NFT or pays a mortgage). All these changes are made locally, then proven locally and only the commitments to the data (aka hashes) or public parts of the data are published to the network. The network then verifies the proofs instead of recomputing the data.

Client-side execution: private state stays with the client Inside the client, private state is used to execute changes and generate a zero-knowledge proof. The client sends the proof, commitments, and any public data to the network, which verifies the proof. Private state stays inside the client boundary. CLIENT · PRIVATE Private state Execute and prove ZK proof + commitments + public data (if any) NETWORK · PUBLIC Verify the proof
Private state stays on the client. The network receives a proof, commitments, and any public data.

The proof, being ZK, provides around zero knowledge about the data itself.

Full circle, all works, no disclosure.

The biggest challenges to this (otherwise very elegant) approach are two:

(1) Is the proof sound -- is verifying the proof enough to secure the chain?

(2) Is the proof generation economical -- how fast and cheap can you make the proof?

Selective State Distribution §

This is all about routing. Instead of having a global world state and some global validators (be it validator nodes, like in Ethereum, or proof verifiers like in Miden), we have many independent "states" across groups of parties. These "states" are validated by their groups.

Separate groups, separate private states Schematic of selective state distribution. In group A, Party A and Party B each hold and validate private state A. In group B, Party C and Party D each hold and validate private state B. Exchange arrows remain inside each group. A party outside both groups has no access to either of these private states. GROUP A Party A Holds + validates private state A Party B Holds + validates private state A GROUP B Party C Holds + validates private state B Party D Holds + validates private state B Party outside both groups No access to private state A or B
Schematic: each private state stays within its participant group.

One modern example of a chain like that is Canton Network. In Canton network, only the participating parties (and optional external invited "issuers") are verifying that the transfers are correct. For USDCx for example the issuer will be Circle. Each party is responsible for validating the state. No other parties can see anything, but Circle does see every tx. Information in flight is encrypted.

One more... vintage example is Tessera. There is privateFor:. The sender publishes the hash of the payload it intends to execute to a public blockchain, and then sends the payloads to parties. Each party maintains and validates its own private state and applies the change on its own. So this private state only lives on the machines that transact.

Challenges of this approach are mostly governance-based. The protection against parties colluding is weaker, because there is no global verifier. Often some 3rd party invited either as an issuer in Canton or just best practice to invite a 3rd party (token issuer) for transactions on Tessera (otherwise, private state divergence is a common failure on Tessera). The trust model is that at least some parties are honest.

Related