Privacy for everyone first: cypherpunk vs enterprise on public blockchains

Event: Common S3nse 2026, Amsterdam

At Common S3nse 2026 in Amsterdam, during Cypherpunk Week, Avishay Yanai, CEO of Soda Labs, gave a talk on privacy on public blockchains and the tension between two audiences that both want it: cypherpunks and enterprises. Here are the main ideas.

The bootstrap trap

Privacy depends on the anonymity set, and the anonymity set depends on users. A new privacy tool starts with no users, so the first people who try it have no one to hide behind. Every privacy system has to solve this chicken-and-egg problem before anyone can rely on it.

Two audiences, two meanings of privacy

Both cypherpunks and enterprises want to protect their users. They mean different things by it.

For cypherpunks, privacy is freedom: extreme sovereignty, "in math we trust", and no compromise on the level of privacy and security. For enterprises, privacy is an operational necessity: it's the law, and it prevents leakage that would expose their customers.

Enterprises also need things a cypherpunk will happily trade away: an SLA and availability, support when something breaks, performance, easy integration, and compliance with standards and regulators.

Yanai is part of the cypherpunk community, and he runs a company that sells privacy. His argument is pragmatic: raise the bar for privacy on public blockchains for everyone first, then keep stepping up toward the privacy cypherpunks want.

TLS vs PGP: privacy as infrastructure wins

PGP arrived in 1991 as privacy as a product. You installed it, managed your own keys and exchanged them with peers, often in person. It's still used, and it never went mainstream.

Netscape developed SSL, later TLS, in 1994 (first released in 1995) as privacy as infrastructure. It's built into the browser, it's invisible to users, and it was driven by e-commerce: people wanted to pay online, so everyone involved had a reason to make it work. It took encryption on the web from almost zero to almost all traffic today.

The lesson for blockchains, as Yanai put it: you don't get from zero to perfect privacy in one leap. You get there in steps, by building privacy into the infrastructure people already use.

TEE vs MPC vs ZK

Picture the trade-off as a landscape: height is sovereignty, area is utility.

• TEEs sit at the bottom. Special hardware runs almost any program, in any language, inside a protected box. When it works, it's convenient. You're trusting the hardware.
• ZK sits at the top. It maximises "in math we trust", for a narrower set of things it can do.
• MPC sits in the middle. Multiple parties compute together on data none of them can read. Secret sharing, FHE and garbled circuits are all ways to build it.

MPC is moving in both directions. New techniques keep widening what it can compute. And with more parties and a higher threshold, collusion gets much harder, which takes MPC close to the sovereignty of ZK, though not all the way.

Why MPC

Soda Labs chose MPC for three reasons.

1. Availability. A live system needs redundancy, which means more machines doing the same work. With TEEs, every extra machine is another single point of failure: one compromised TEE and the privacy argument collapses. Deploy 100 TEEs that all hold the same key, and one compromise anywhere is enough to break privacy. With threshold MPC, adding parties raises how many an attacker has to corrupt at once.
2. One shared infrastructure that others can join. More entities can take part in the computation over time, and each participant helps keep the protocol secure.
3. Generality. Even a simple token transfer needs computation on data from more than one participant. On its own, ZK proves facts about data the prover already holds. Computing jointly on several users' secrets needs MPC.

Why garbled circuits

A garbled circuit is a box that computes a function. Everything inside stays hidden, including intermediate values. Parties feed encrypted data in, encrypted data comes out, and the circuit decides which party sees which part of the output.

Within MPC, Soda Labs chose garbled circuits for three reasons:

• Real-time performance. Among schemes that compute on encrypted data, garbled circuits give the best real-time results for general workloads.
• Flexibility. They compute any circuit, including symmetric cryptography. That lets Soda Labs use the same NIST-standardised algorithms the web runs on today, AES and SHA-256.
• Cost. Garbled circuits use AES as their pseudorandom function, and CPUs already accelerate AES in hardware (AES-NI). No GPUs, ASICs or FPGAs.

Garbled circuits weren't ready for blockchains, so the Soda Labs team solved three problems:

• From two parties to many. Garbled circuits were efficient mainly for two-party computation. Soda Labs added a layer that secret-shares the circuit labels and a new threshold oblivious transfer, so more than two evaluators can run the circuit, designed to keep performance close to the two-party case.
• Contracts nobody planned for. Classic garbled circuits need the function in advance, and anyone can deploy a new contract tomorrow. Soda Labs' soldering technique garbles atomic operations, the same instruction set as the EVM, ahead of time, then stitches them together at run time into whatever function the contract calls.
• Public auditability. External parties need a way to check that the nodes computed correctly, even if they all collude. Soda Labs designed a protocol layer for this.

Who sees the data

The Soda Bubble Network sits outside the blockchain; its nodes aren't chain nodes. Encrypted data arrives from smart contracts and the transactions people send to them. The nodes pick up that work, compute exactly what the contract dictates and return the result to the contract.

Take a vote. Voters encrypt their votes before submitting them, and nobody can read them. When the vote closes, the network tallies them inside the garbled circuit and decrypts only the result: who won. The network only runs the computation the contract defines.

The contract also defines who can see what. The business running it may need to give information to auditors, AML screening, Travel Rule providers or security monitoring. ACL grants decide who can decrypt which values. The access control list lives in a smart contract, so anyone can check which access grants the contract has issued before choosing to use the app.

The Soda Bubble Network today

On Arbitrum Sepolia testnet, Soda Labs ran 15,000 confidential ERC-20 transfers and sustained about 500 confidential transactions per second (cTPS) on simple CPU machines on AWS. Soda Labs' analytical estimate puts the ceiling above 3,000 cTPS per CPU core. The cost is about $0.14 per node per million transactions on top of each node's fixed running cost, with no special hardware.

In the wallet, one account holds three balance types: a public balance, a private balance that's encrypted but linked to the account's address, and an anonymous balance, spent from fresh addresses with no on-chain link to the account's main address (amounts and timing aren't hidden).

Raise the bar, then keep climbing

In Yanai's view, privacy on public blockchains will grow the way it grew on the web: as infrastructure, under operational necessity, for everyone first. That's what Soda Labs is building.

sodalabs.xyz

Thanks to the Common S3nse team and CryptoCanal for the stage and the recording.