Privacy from operators

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.