Soda Labs | The privacy landscape for cypherpunk and enterprise - Avishay Yanai | Common S3nse 2026

[music]

So, yes. Uh I'm Abishai from Soda Labs. Uh this talk will be about privacy in public blockchains and the landscape or uh tension between uh Cypherpunk and enterprise. Uh I took this picture in uh art gallery in Jerusalem and I thought about two aspects of privacy uh that um you might relate to as well. So, um you might take 5 seconds to to try to think about something.

But, what I thought about was two things. The first is that when we enter the arena, we are forced to strip. This is uh something we have to do. We have almost no choice. We have some choice for different things as many people here are building, but in general, this is what we are forced to do.

And the second thing is that we are as developers of privacy tools, we get to this problem or um paradox paradox that is the chicken and the egg. Uh when we talk about privacy, then privacy depends on something called anonymity set, right? Uh and anonymity set depends on having a set of users. And if you don't have this set of users, then everyone who comes and try to use your or want to to use the system has no one to hide behind, right? There is no anonymity set.

So, this is a chicken and an egg problem that all privacy tools are struggling to solve in the beginning. So, this is um something it's a bootstrap problem that all privacy uh systems and tools have to solve before the the actual system becomes something real to rely on for privacy and especially anonymity. So, um yes, this is about that. Uh now, I want to stress about Okay. Um about the tension between the Cypherpunk and enterprise.

So, there are two different or not distinct, but we can we can differentiate between the two audiences of who are we solving privacy to. Um one thing we can tell about those two is that both want to protect customers, right? Protect ourselves, protect uh our users. But, there are some distinctions in the way um the two audiences are looking at at the problem. Privacy doesn't mean the same thing for everyone.

Um now, while I'm taking considering myself as part of the Cypherpunk uh community, I'm also program pragmatic and I'm running a business that needs to and wants to sell privacy and increase or raise the bar for privacy for the general audience. So, Cypherpunk has um their notion of privacy means freedom. And we're looking for extreme sovereignty. And um in math we trust. Where is enterprise, they take privacy as an operational necessity.

So, they embed privacy in things for compliance cuz it's the law. And to prevent operational leakage because their customers will be exposed to different bad things if they will not embed privacy. And so, there is demand from the customers. And there are some tension points in the properties of privacy that um are required by the different by the two different audiences. So, I can say that the Cypherpunk privacy they will not tolerate about the level of privacy and security.

These are the two things that Cypherpunk will not tolerate, right? If you buy a product only for the privacy aspect of it, then this is the only thing the product should do, right? You had one job, so give me the best solution you can you can produce. But, there are some other aspects of privacy that are more interesting for enterprises. That are not necessarily the best privacy in the world.

They want good SLA, right? They want availability. The system will never crash or will crash uh for no more than 0.1% of the time. They want to have support if something happened.

There there is a bug or uh um or something that they need to to help customers with. They want better performance. Whereas, as an individual or Cypherpunk, I'm more tolerate about. And they want easy integration. So, the system will not go down for integrating new feature.

It will not ruin other features they have in the system. And they care more about compliance and standards. So, as an individual, I I'm not necessarily care about standards or compliance. Um I leave it to the service providers that I use to take care of it of this. Um as an enterprise, they are under more pressure from regulators to to comply to different types of regulations.

As we spoke earlier in the in the panel. And what I want to argue in this talk, and it will um lead lead the rest of the talk, is that overall we want to raise the bar for privacy on public blockchains. And um I think the pragmatic way to do this is to raise the bar for everyone first. And from that point, we'll take another step towards like the perfect um limitless privacy that the Cypherpunk uh requires. Um so, one case that I want to to take um an example from is that the PGP versus SSL or TLS.

So, PGP uh started in 1990 1991. Um it was a privacy as a product. You had to install it, you had to manage your keys, and you exchange keys with your peers in uh face-to-face conferences, right? In physical meetings, uh to get the best privacy of communication between the two uh participants or group. So, it was good.

It's still being used today uh in some sense. Um but it didn't catch like the mainstream. On the other hand, there is SSL and TLS, which is privacy as an infrastructure. It is embedded in our browsers, started by Netscape in '94. It is invisible to users.

They don't even know there is something called SSL or TLS that secures their communication. And it was driven by e-commerce. People wanted to use the internet for online payments. This was a real huge uh driving force and it had a great incentive for everyone involved to actually build something that allows this e-commerce to work. Um so this actually grew up the the the the privacy that we have today on the the internet from almost zero to the state that we are in right now, which is 99% of the internet traffic is encrypted.

So I want to stress again, the argument here is that um if we want to solve privacy for the general audience we we need to look at this case and and and think whether we want to build a perfect thing that will uh do the leapfrog like from zero to 100 in one step or we can do it step by step in a more pragmatic way. I'm leaning to the to the second uh to the second way, but I'm also uh I'm I'm I also understand uh the other the other way. Now, I will not get too much into technical um aspects. Um I I'm in the cryptographic space. I was in academia for um more than 12 years.

Um I did my PhD in cryptography and I dealt I've dealt with many types of cryptography. Um almost all the pragmatic tools that we have today I had a chance to to touch. And this diagram depicts the tradeoffs generally speaking between sovereignty and and and utility. So the higher the the plane the the better sovereignty that the technology can give us. Where is the the larger the area means the more useful it is.

Can do more things. So, at the bottom we have TEEs which are a tool that allows us to deploy almost any program, any language um to inside a box, a hardware, special hardware that um promises to to uh secure the program and to not leak anything. When it works it's nice. Um at the top we have uh zero knowledge that actually maximizes the phrase that I mentioned before, in math we we trust. And in the middle we have MPC.

And MPC means that we trust multiple entities to compute things together without being able to read the data that they're computing on. This is in general what is MPC. And it is in the literature, there are many uh possibilities to implement MPC. Um I mentioned three, like secret sharing, FHE, and garbled circuits. And for the argument that I mentioned before, that we want to solve privacy for the general audience first I want to argue here also that MPC is um the right tool.

So, first in the traject- trajectory um the area of MPC is always growing. There are always new uh works and new techniques to do more useful stuff with MPC. To compute more types of functions or programs um on the basis of multiple nodes that collaborate and compute on encrypted data. So, on this aspect it increases the area. On the other aspect, these are represented by the stairs.

By increasing the number of parties and the threshold that we are using for MPC, we are getting towards the the level of sovereignty that ZK is giving us. Now, I'm not arguing it will reach the same level of ZK, but it it it it's getting very close. So, basically the more parties we can engage in the computation, um the better the better better privacy we can get because the collusion requirement becomes much much harder to break. So, this is why we chose um MPC in Soda Labs to implement what we call compliant privacy and we discussed earlier. So, one thing is availability.

We want uh we want from a system to be available and for that we need redundancy. For redundancy, we usually put more machines to do the same stuff. Um and if we chose TEEs, for example, then it means that we put more TEEs around. They had to synchronize between themselves, but that's fine. We have consensus algorithms, uh many of them.

But the problem here is that we will have many single points of failures. It's sufficient that one TEE get um is getting broken or compromised and the entire privacy argument collapses. So, it's really a trade-off between availability and uh privacy there. So, let's say you deploy a system with 100 TEEs around the world, it's almost guaranteed that one of them will be compromised. So, this eliminates uh TEEs.

The other thing is unified infra with an option to participate. So, with MPC, we can let more entities to take part in the computation. We can always add more participants to the MPC computation. And those participants have the best guarantee that the computation is is conducted correctly. And they keep the protocol secure, as well.

So, this is another aspect. And the last aspect is generality. Um and there is a problem, this is why we didn't choose ZK, is because we want to be able to do more stuff than only compute on my own data. Um there are many applications, even on blockchains, and even with uh simple token transfers, that require computing on um data from different participants. And this is in general something that zero knowledge cannot do, and therefore we chose MPC.

Within MPC, we chose something called garbled circuit. I don't know if if you guys have heard of this, but garbled circuits are boxes that are basically uh computing some function. And anything inside that box remains um obscure. You cannot see the intermediate values. And people can contribute encrypted data to the box and receive encrypted data out of the box.

So, you the box also dictates which parties sees what uh of the output. So, we chose garbled circuits to to and garbled circuits uh fits well that there are uh secure multi-party computations MPC protocols that works that work with garbled circuits. Um we chose garbled circuits because they offer us three uh main features. One is real-time performance. And out of the cryptographic schemes that do computation on encrypted data, they are the the ones that gives us the best results in real-time computation.

In general, of course, for different functions that you might find something else, but in general, this is true. They are very flexible in the circuits that they can compute. You can basically create any circuit and it will be computed well. And especially here, we wanted to be able to compute symmetric crypto. And we wanted to compute symmetric crypto because we wanted to use AES and um the SHA uh family of of hash functions.

Because we wanted to mimic the way we interact with uh the internet today. So, users right now, whenever you are browsing the internet, you use TLS and you use those algorithms, AES and and uh SHA-256. We wanted to use the same algorithms that are NIST uh standardized. The last one is cost. Many of the cryptographic solutions today, they require special hardware like GPU, ASICs, um FPGAs to accelerate.

Garbled circuits are already accelerated in CPUs. And why is that? Because garbled circuit techniques, they use inside them something called pseudo-random function, and that pseudo-random function um the best choice that is being used in the in the literature and implementations is the AES function. So, the AES is used both as an encryption scheme as well as a block cipher or pseudo-random function. And AES if you if you developed any cryptography before, you know that there is an AES-NI instruction sets in Intel um architecture.

And they are already embedded in the CPU. So, you can do many many AES's. Um the the throughput is very high. So, these are the main reasons we we chose garbled circuits. Um and we had to solve different um things in order to make garbled circuits actually good for for blockchains.

They were not ready to to be used in blockchains before we actually solve those challenges. The first challenge is that garbled circuits they were mainly uh before before we started to work on them, they were mainly effective for two-party computation. Not multi-party computation. And as I mentioned before, one of the properties we wanted from MPC is to be able to add as many participants as possible. So, if you are limited to two-party, this is not good for us.

We have to do something in order to to solve it for multi-party. So, this is the first thing that we solved. Uh we developed a a new uh layer of the of the protocol that does secret sharing of the labels of the garbled circuits and a new threshold oblivious transfer to be able to run um many evaluators of of garbled circuits without harming the performance. And actually, the performance remains as close very very close to the performance of two-party computation. So, this is the first thing.

The second thing um and I don't assume you know uh anything about garbled circuits, it's very high level. Um in garbled circuit, you have This is the property that people who build their knowledge, they know well. Um, the first version of garbled circuits is that you have to know the function that you will want to compute on in advance. So, this is a problem, right? Because if you want to adopt it in blockchains, in blockchains, you can deploy a new contract tomorrow that has a new function that you just invented, right?

I don't know it. This system doesn't know it. So, I can I cannot predict and build garbled circuit for any kind of function that there is in smart contracts on blockchains, right? So, it doesn't it's not practical. So, to solve this, we developed something called soldering.

Soldering So, garbled circuits, they work with wires, right? Uh, and soldering means we we solder wires, we fuse them to connect different garbled circuits together, to stitch them together in real time. So, the solution involves um, the garblers, they uh, create a lot of garbled circuits for atomic operations only. So, we break uh, we break the dependency between the creation of the garbled circuits and the consumption of the garbled circuits. So, in complete offline phase or in idle time, if you want.

There are parties that create garbled circuits. And those circuits, they are represent the atomic operations, the same instruction set as the EVM. Or any EVM. It it's not only dependent on on EVM. And in real time, the set of evaluators, they take all those atomic operations, and they see which function has to be computed now, because there is new workload on the blockchain.

Let's say someone just wanted to vote on on a function for a voting smart contract. So, this vote voting function has it uses different atomic operations. Um like the bytecode represents different operations. So, the evaluators they they take all those garbled circuits that represent those atomic operations in the byte codes. They stitch them together to represent the function of the voting.

And they can compute them um as one function that was uh as if it was created in advance only for the voting function. So, this was a major advance and completely decouple the two uh phases of creating garbled circuits and uh consuming them. And finally, garbled circuits previously did not have the notion of public auditability. Public auditability in the MPC um domain means that there are let's say 100 parties that compute some function. But, what about other other entities, external parties that are not part of the computation?

How can they be sure that those 100 parties they computed the function well and they didn't cheat? Let's say uh there is they compute a function for a token transfer. And someone just transferred sent sent a a transaction with 100 of USDC to transfer to someone else. Okay? And they did a computation.

And they report that the computation uh that the the user transferred 1,000 instead of 100. Who can actually verify that they did the computation correctly? So, public auditability is a feature of um secure multi-party computation protocol. Not all of MPC protocols have this feature. Some of them have this.

Uh and Garbled Circuit uh did not have it. So, we had to invent it to make it possible for external entities to be able to verify that a set of parties, even if all of them collude, they will not be able to claim something that is incorrect. So, these are the main challenges. And right now, uh the protocol runs in production. The overall architecture looks like this.

At the bottom, we have the blockchain. Um and the MPC network sits outside of the blockchain. So, they're not part of the blockchain nodes. They are an external entity we call the Soda Bubble or the Bubble Network. So, encrypted data comes from the blockchain, from smart contract, and transaction that people submit to the to the contracts.

The nodes in the Bubble Network, they listen to the smart contract, they retrieve the information and the workload to be done on the encrypted data. They compute all the all the workload that is dictated by the smart contract. And whenever needed, they return back a result to the smart contract. So, for example, in the in the voting example I I mentioned before, people submit votes to a smart contract. They encrypt the votes before.

Nobody can actually decrypt the votes. The Bubble Network listen to all those transactions and retrieve all the encrypted data, all the encrypted votes. Does the computation, for example, who got the maximum number of of votes, which candidate is the winner. And after 100 blocks, let's say, it has to return the decrypted result. So, they do the decryption.

They do the aggregation and the calculation of who is the winner inside that uh black box, which is implemented with garbled circuits. And only in in the end they decrypt only the results, only who is the winner. Or actually this result is also dictated by the smart contract. They cannot compute whatever they want. So, everything is um So, this is um a transparent um level that we that we take.

Everything that the bubble network computes is dictated by the smart contract. And there is another angle here on the right. Um the smart contract that uh owns the computation or the the managers of the smart contract, which are we call them the business the business owners, they also dictate who can see what. It might be that um they manage a business that runs uh that that is under some uh regulations and they want to uh be able to um give some of the information to third parties for security reasons or um to give it to financial auditors, AML screening, anything that uh they have to do or want to do. And sometimes the business owners, they want to know everything, right?

Uh and it's up to the users to decide whether it's fine by them or not. So, everything is transparent to the users, who can see what. It's all written in the smart contract that is called ACL, access control list. Um and uh it's up to the user to decide whether I want to use this USDC or USDT based on the privacy features it gives me or not or I want to use Zano or some something else. So, um this is a real measurement of of the system right now.

Uh we we've run 15,000 transactions on um of confidential private ERC-20 on Arbitrum Sepolia. Uh we got a sustained 500 uh TPS or we call it CTPS, confidential TPS. Um on a CPU, very simple machine on AWS. Um It's written here. Oops.

Um on on a single CPU core, the ceiling of CTPS is uh more than 3,000. And the cost is very uh low. So, for 1 million transactions, uh the cost per node that participates in the network is about 14 cent. And overall, um the more transactions uh there is, the more load doesn't add cost to the system. Cuz we don't use any special hardware, we don't use GPU.

This is one of the requirements that we we had when we started to develop develop it. We only want to be based on CPUs. This is how it looks and here I just wanted to stress something. We have three types of balances. The public balance is what we have today.

Uh we have private balance, which means the your balance is encrypted, but it's still link linkable to your main address. And we also have anonymous balance that is it means that there is some balance that belongs to you, but it's not connected to your main address. There is a balance that you uh to to to use it, to spend it, you always create a new address um to uh in order to use it, and it's very similar to the notion of anonymous tokens that we have um in Zcash or or other systems. It's It's a It's from similar to UTXO systems. And um as I mentioned before, we have the sharing options.

Uh you can share your transactions with um with anyone based on addresses. Uh and there is another third-party service that also allows you to to share using emails. And um that's it. With that, I will conclude. Thank you.

Thank you very much, Avishay, um for that very technical breakdown of what you're doing at Soda Soda Labs. Um yeah, I would also say Are there any questions? I mean, for me personally, I thought it was quite interesting that you mentioned that it uses CPU architecture, and that it uses I think Monero as well also uses random uh pseudo-random um yeah, right? Yeah, indeed. So, uh very interesting stuff.

Thank you very much, and um yeah, and yeah, another warm another round of applause for Avishay, guys. Thank you.