New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Collaborative Confidential Compute

DappconMon, Jun 16, 2025, 12:19 PM · 24:38

by Auryn MacMillan

Transcript

Hey folks, so the most valuable systems in our economy today are built on this kind of fundamental asymmetry, right? Whoever can aggregate the most data essentially wins, but what if we could radically change that equation? What if we could enable institutions, individuals, and agents to collaboratively compute over sensitive data without introducing information asymmetries, without giving up control of their data? So today I want to explore an emergent class of computational primitives, of cryptographic primitives that is not just creating new technological capabilities, but also reshaping how value gets created and distributed in these multi-agent systems. So we call this collaborative confidential compute.

What excites me about collaborative confidential compute is this potential for it to be a disintermediate force. It has this capacity to become another step on a kind of global progressive disintermediation journey. What I mean here is, so the internet was this radically disintermediating force for access to information. Blockchains like Ethereum are this disintermediating force for access to finance, and I see collaborative confidential compute as this radically disintermediating force for access to an interaction with systems that aggregate information, multi-agent systems that create value from large-scale aggregation. Large-scale aggregation like this has historically been the purview of large-scale organizations that have the capacity and willingness to aggregate and hoard huge amounts of user data.

And I think collaborative confidential compute will enable essentially a whole new class of applications that deal with shared secret space and the value that it creates. So looking at some of the most valuable companies today, Facebook and Google make huge amounts of profits by aggregating shared, by aggregating secret data from, sensitive data from users. Their web traffic, their social interactions, their purchasing, and their search data. The pattern is fairly clear here. Being able to aggregate large amounts of information, particularly large amounts of private information, lets you win.

And this creates this fundamental dilemma for builders building systems that aggregate information. Either take custody of user data or miss out on the insights that you can gain and the value that you can create from aggregating that data. And then a corresponding dilemma for users of these systems, for participants in these systems. Either give up custody of your data or miss out on access to the benefits that those systems create. Every current attempt to solve for this set of problems has come bundled with a handful of fundamental flaws.

Either privacy is temporary or it rests on some essentially trusted operator or trusted hardware. But here's what's changed. So we have three cryptographic technologies that are kind of maturing in parallel, maturing simultaneously, that can be composed in a variety of different ways to enable really interesting novel systems. Zero-knowledge proofs allow you to prove, succinctly prove statements of knowledge without revealing the inputs. It's the theory, the tooling, and the performance around ZKPs has improved dramatically over the last few years.

Multiparty computation allows you to distribute secrets across an arbitrary set of parties such that none of them have direct access to the secret but can use it in a way that does not reveal access. And so some use cases here are things like distributed key generation and threshold decryption allowing you to distribute, control, or solve for key management in these kind of multi-agent systems. And then lastly here, fully homomorphic encryption, FHE, allows you to compute directly over encrypted data and produce an output that when decrypted is equivalent to if you had to run the same computation on plain text. FHE has, the performance for FHE has improved dramatically over the last few years, taking it from possible in theory to usable in practice. And the kind of real breakthrough here is that these combinations of technologies let us embed privacy at the system level, making it possible to run arbitrary computations over encrypted inputs with very strong guarantees around the inputs and intermediate states from any private while the outputs being verifiable and trustworthy.

All without necessarily creating individual points of trust or failure. So before we dive into, or further into the kind of technical side of things, I just want to establish some of what's at stake here. So again, I mentioned hundreds of billions in revenue generated by digital platforms that rely on harvesting user data. And users rarely, if ever, if ever compensated with anything other than access. And often users are harmed by the misuse or mishandling of the sensitive data that they ultimately hand over to these platforms that are harvesting their data.

This asymmetry is a really defining feature of today's data economy. But it's not just about money and access. We also have things like life-saving medical research slowed or halted because of data silos between institutions or regulatory hurdles. We have things like systemic financial risk that are hidden or not discovered because of competitive secrecy between financial institutions. And things like AI models that are biased due to, that are distorted, sorry, because of biased or incomplete training data.

And I think, yeah, the difference now is that with this combination of cryptographic tools, we can take, again, this private data and aggregate in such a way to produce verifiable outputs without revealing inputs. And essentially this class of applications that were once theoretical are now becoming practical. The basic patterns for collaborative confidential compute look something like this. Essentially you have some data sources that will encrypt their inputs, compute will happen confidentially somewhere, we'll get to that in a minute, and then outputs are decrypted, again, with kind of strong guarantees around inputs and intermediate states remaining private and outputs being trustworthy, verifiable. There's multiple technical approaches to this, each combining some mix of kind of five-ish key ingredients, trusted execution environments, zero-knowledge proofs, multi-party computation, FHC, and then some form of game theory.

And they each have a different set of trust assumptions, trade-offs across privacy, scalability, cost, and throughput. The key insight, though, is that we have multiple viable technical paths to achieving collaborative confidential compute. And so this creates a completely new design space for builders. You have new constraints around your computation costs, economics, trust models, and user experience that you need to consider, but alongside of that you get these kind of powerful new affordances. You can enable competitive collaboration between otherwise distrusting parties, you can reduce viability from the data that you might have to take on in order to produce insights, you can prove that systems and their outputs are fair without revealing inputs, and you can implement dynamic value distribution based on contributions without revealing the contributions.

And these are fundamentally new capabilities for system designers. So let's take a quick look at how these ideas kind of work in practice, starting with a surprisingly unsolved problem, digital voting. So there's a good reason why every worthwhile democracy in the world uses a secret ballot. Open ballots enable collusion, corruption, bribery, coercion that ultimately distort their outcomes. The state-of-the-art for secret ballots is writing a vote on a piece of paper, dropping it into a big box with everyone else's votes, and shaking the box.

And there's a reason that digital voting has not kind of widely displaced paper ballots. It turns out that it's really, really hard to cast a digital ballot in such a way that you don't leave a traceable footprint. And in doing so, it creates an avenue for bribery, coercion, collusion, and the corresponding negative outcomes. So digital voting isn't broken because we can't tally accurately or we can't produce voter registries or any of the kind of technical challenges there. It's broken because its fundamental flaws enable corruption, enable collusion, and again, ultimately distort its outcomes.

But with careful design choices, collaborative confidential compute can enable voting systems that are legitimately receipt-free, enable us to build verifiable, censorship-resistant, receipt-free voting. And that last property, receipt-freeness, has been really, really challenging, if not impossible, to build to date in digital voting systems without taking on untenable trust assumptions—trust assumptions in individual operators or trusted hardware and their corresponding complexity and attestation chains. Beyond voting, though, these patents kind of enable a whole class of new applications—medical research that can happen across institutions without revealing institutional data, without revealing patient data—say, custody by different healthcare institutions, different medical institutions, different research institutions. You can have collaborative analytics across competitive financial institutions, and you can have feel-good auctions where you don't reveal any of the bids or bidders but have a verifiable outcome, just to name a handful of these cases. The pattern's the same for all of these.

You have inputs, secret inputs, that users submit encrypted to some execution environment, some encrypted execution environment. Computation happens in a verifiable way, and then an output is produced without revealing any of the media states. Performance-wise, collaborative confidential compute is practical today for moderate complexity, high-value use cases, where this kind of privacy premium is justified by the value of the output. But the cost and performance of collaborative confidential compute is improving radically year over year, and so I think the floor on what's a justifiable use case is radically dropping. So I just want to talk quickly about the kind of design space here.

Security in these systems requires thinking across a handful of different layers—the cryptographic assumptions, the economic incentives, the protocol implementation, nuances, and a handful of other layers. Different approaches have different sets of trade-offs. So, for example, trusted execution environments, they're the kind of de facto standards for a lot of these types of use cases currently. They're relatively performant but bundle in a whole bunch of complexity along with trusted hardware and trusted manufacturer and supply chain assumptions. MPC allows you to distribute secrets such that you can arbitrarily compute with them without revealing the secrets to any of the parties or revealing the secret publicly, and this is really great for things like distributed key generation and threshold encryption, allowing us to solve for distributed key management in these type of multi-agent systems.

Zero-knowledge proofs, CKPs, they allow you to succinctly prove statements of knowledge about some data without revealing the data itself. There's this kind of moderate overhead, and they're super useful for a handful of different scenarios. They're not great in scenarios where you want to aggregate information about multiple users because you must know the data that you need to prove in order to be able to generate a proof. And then the last one here, oh, I'm sorry, it's not on the table, but FHE allows you to compute other sensitive, compute other data while it's encrypted, produce a ciphertext that when you decrypt it will give you the same output as if you had to compute it over the plaintext data. The key here is to choose the combination of technologies that make sense for your use case, and obviously to take into account the kind of performance, privacy guarantees, trust assumptions, and all this good stuff.

In my opinion, the combination of FHE, ZKP, and MPC is one of the holy grails of cryptography. It gives you verifiability, allows you to compute over encrypted data, and to distribute trust in the decryption keys as broadly as you like. Caveat with scaling constraints there. So I think this technology has some pretty profound economic implications. Currently data aggregators like Facebook, Google, OpenAI, they capture this disproportionate value based on their capacity to aggregate private information, but collaborative confidential compute will challenge this.

It will allow participants to engage in these kind of aggregation systems without giving up their data, which ultimately gives them leverage and should help to force more equitable value sharing in these types of systems. We can build data cooperatives with cryptographic guarantees that enable competitive collaboration in previously zero-sum environments and implement merit-based application without revealing private information. So for builders ready to start, there's several emerging tools. Enclave, the tool that we're building at Gnosis Guild, provides a substrate for FAT-based encrypted execution environments. Sunscreen has a really performant TFAT library.

Primus, they've got a fantastic ZKTLS library as well as some promising research on threshold TFAT and also another TFAT implementation. Aztec has this awesome ZKDSL, which has really made it much more accessible to write ZKPs. Risk Zero, for example, has a great ZKVM, a RISC-V-based ZKVM that makes it really easy to prove correct execution of arbitrary codes that can compile down to RISC-V. And so with tools like these in hand, developers, builders now have everything they need to be able to build these systems leveraging collaborative confidential compute and ultimately create aggregations of information without leaking sensitive information. So this is bigger than any one project, right?

We collectively are building infrastructure for a more equitable digital economy. For researchers, there are fascinating open problems in optimization, in encryption schemes, in mechanism design. For builders, we need people pushing boundaries, breaking these things, and ultimately discovering how they work and where they're useful. And then for organizations, there's a really great opportunity to, again, get a push for boundaries here and pioneer privacy-preserving initiatives that still enable you to gain access to the insights you ultimately want from data that you would otherwise have to aggregate and take custody of. This is a vision of the future where data producers control their data and share in the value that they create, and where cryptography enables the collaboration between competitive institutions to their mutual benefit.

So I'll wrap up here. As I was saying, we're building towards this future where people who produce data actually control and share in the value that it creates, where insights from large-scale aggregation don't require giving up data, giving up custody or autonomy over your sensitive information, and where cryptography enables collaboration between competitors to their mutual benefit rather than just competition. So this is collaborative, confidential compute, and it's going to reshape how we think about data, how we think about privacy, how we think about value creation in these multi-agent aggregation systems. If you're interested in building this future, our team at Gnosis Guild is developing an open-source protocol called Enclave. It combines ZKPs, FHE, MPC, and obviously economics and game theory to enable encrypted execution environments.

Yeah, that's it. We'd love to hear your thoughts. If you want to chat about CCC, Enclave, or anything related afterwards, then yeah, come find me. I'd love to chat. Thank you.

Thank you, Oren. We have a moment for a few questions down here up front. We have someone with a question. Thank you. So at the moment, there are mainly two paths to build applications with private shared states that are, like, because FHE is so slow compared to MPC.

So either you build, like, co-SNARKs. So this is the approach on NOIR, like on Aztec, for instance, where you prove your SNARK inside an MPC setup. Or the other one would be more like doing everything in MPC, no ZK. I think Archium is building that on Solana. And so, yeah, on top of existing L1s.

What do you see? If there is a dark pool in two years, which one do you think would be where it would be? Yeah. I mean, in two years, I think a lot can happen in terms of acceleration of and kind of improved efficiency on both MPC, on co-SNARK, and on FHE. And so I think it's hard to pick right now which one is going to be most viable that far out.

I'd say if you're trying to MPC is the best solution for that, just like in a purely MPC-based solution. The challenge there, obviously, is that you give up some of the verifiability. It's a more trust-based system. I tend to think that the smaller, the complexity compute tasks are the things that are more accessible right now. So voting, the reason voting is the example there is that it's a similarly lightweight computation that's very high value.

And so that's where we are initially focused. And I think where the team's building this should probably be focused is in those kind of lightweight aggregations that unlock a tremendous amount of value. Out of the two options that you suggested, my preference is obviously for co-SNARKs. I would much prefer it to be cryptographically verifiable. And then, obviously, the architecture that we're going to be pioneering is this combination of ZKPs for input validation, validating things like DKG and threshold encryption, FHE for the computation itself, and then MPC to distribute key shares.

And I think by segmenting, particularly by pushing input validation to the edges, even on relatively complex computations, you can move a lot of the complexity to the edges and have users prove the validity of their inputs as opposed to doing that part of the computation in FHE. And so it can offset or reduce how much of that FHE overhead you have to take on.

Automatic transcript — names and jargon may be misspelled.