# Privacy and Security for Data Sovereignty

- Channel: [Vana](https://streameth.org/vana)
- Date: 2025-03-06
- Duration: 26:50
- Watch: https://streameth.org/watch/67c8f70edfe4387924e57483

## Description

with Daniel Marzec, Aayush Gupta, Chris Rinard and David Sneirder. Moderated by Liz Harkavy

## Transcript

Hi, everyone. I'm Chris. I'm the head of engineering at Vana, and before this, I was an undergraduate at MIT. I started in the AI space right around the same time that our CEO and founder, Anna, did, where we worked in a similar lab, trained models that let users predict whether or not they're going to get cancer, how they're going to get it, how that's going to progress, using some really great data. At the start of AI, really the dawn of the modern AI age, when it was bag of words, when it was single, like single multi-layer perceptrons, it was state-of-the-art performance. Also worked on a number of AI training teams, worked in the research team at a place called Mosaic, where we trained the first and largest open-source chat GPT, basically. Yeah, and now I'm leading engineering at Vana. We're doing great work. Yeah. Cool. I'm Yush. I work on ZK email. The idea is you can prove or verify redacted information from any center-received email. We use it to do mostly, when related to Vana, to do data authentication. If you want to upload data to train a model, it better be valid, shouldn't be made up. We'll validate the data because we can say, oh, the provider sent an email. As long as that proof is valid, then you can validate that's correct. What's up? I'm Dan, or DMARS, at Flashbots. We think that privacy is the key to efficient markets, especially in the permissionless setting. We are trying to put block building, a bunch of other computation in Ethereum and related Layer 2s on top of TEs. We hope to expand that to more like Web 2 functionality as well. The idea that you could encapsulate an account and control it from a smart contract inside of a TE is something we're thinking a lot about right now. Awesome. My first question, we're going to get started. I think we talk a lot about, in Web 2, why you shouldn't trust centralized companies with your data. We see data leaks, we see all these hacks, etc. We at least like to think that Web 3 is better. When we are trusting you guys with our data, our keys, transactions, whatever, what are we trusting exactly? We could talk about the architecture. Is that what you're getting at? I guess the question is, where are we putting our trust, and what does it mean to trust you with our data? Yeah, it's definitely an architectural question. At least that's how I interpret it. The way that a distributed key generation, so key material is created through this cryptographic process where the key is created in the context of fragments in a threshold setting, typically articulated in T of N. Then the network that we have, the risk there, this is what people call threshold MPC. There's a collusion risk there. The defense in depth layering is to then run that threshold node inside of a TEE. Then the insight that we had in the context of building this over the past several years is that essentially the same insight that Vitalik had, which is setting up a network is hard. If you make a network programmable, it lets people build on top of it, ratcheting up the abstraction stack, and so we have a programmable element on top of this that allows us to do that. There's not a man in the middle, functionally. You're not trusting a controller, which is largely how privacy works in Web2 with server-side encryption. You say, hey, provider, here's my plain text. You encrypt it with your key and store it on your server. Yeah, I think that we're going to say a lot of similar things, but in Web2's sense, when you upload your data to Google, what you do is you give them a PDF or whatever text, whatever plain text. It goes through their form. It sits in their servers. They have the ability to decrypt it at any time, and any guarantees that they're giving you are legal, not very enforceable. Legal, not very enforceable, and basically, when your data is in a Web2 service, it's at their whim, where if you look at what it takes to put data on VANA, you come in. You come through a data dial, so there's a smart contract, some upload logic there. You can choose the storage provider that you're using, so whatever storage provider you choose, there's a trust assumption there. They have different underlying security mechanisms that kind of underpin that. Then that goes through a proof of contribution that can be either ZK on your own private server, so there's no trust assumption on the privacy side. You're trusting ZK to some extent. There's that proof of contribution, and then you take a hash, so you're trusting that that hash doesn't reveal your data, which is a fairly strong assumption throughout the years. It's encrypted and uploaded, so you're trusting RSA, Elliptic Key, whatever cryptography scheme they choose to implement, and then it goes into a – the other way that you can do a proof of contribution is through a TEE, where fundamentally, you're trusting Intel, AMD, NVIDIA software stack and their implementation of these modules that they say they define, combined with the external audit of those, and then you're also trusting Vana Network and our engineering backed by audits. Maybe more on the TEE side, and I don't know if you want to talk to this. How is that different than trusting a centralized company if you're saying at the root of it, you're trusting NVIDIA or whoever? Well, we're trusting the engineering of that centralized company that's handed out to us in a decentralized way. It's like if I say that if you're doing ZK, you're trusting the x86 instruction set, which is also AMD, also Intel. It's also made by a centralized entity, but it's distributed and it's controlled by decentralized users and decentralized networks. We're like, yeah. Yeah, I don't have a ton to add on to that, other than the reason Intel started working on SGX, even though secure enclaves have been a research area since, I don't know, the 60s or something. A bunch of people came to them and were like, hey, how do we trust that you're not doing evil things with our data? And they were like, I don't know, we'll find a contract or something. And that wasn't good enough. And so that's why they started to productionize SGX and develop it. I mean, that definitely makes sense to me. My personal speculation is that it's a direct result of the Snowden revelation. Because if you look at it, it was about 18 months after the cloud providers started providing the TEEs because the megacorporations were like, hold on, wait, all of our customer data is going to a consortium of the world's governments? And so it's speculative, but the timelines match up in terms of the reasoning. And then as it relates to the trust assumption, just to talk about what, at least in the context of the most modern type of TEEs, these encrypted VMs, like if you have the machine, you pull it back, basically what you have is like a big 64 core processor and wired into it is like, at least in the context of AMD's product, is a little ARM cell phone chip that holds the external keys that are encrypting the VM when you set it up. And so functionally, what you're trusting, provided that you trust the engineering and the audits, is also the supply chain, such that nobody pulled the TEE off of that little ARM chip before it got delivered to your data center. Yeah, and to contextualize a little bit, like if you look at that supply chain is actually usually fairly robust. You have to get very creative to break into one of these things. And with the first iteration, you've got SGX, and they broke it a couple of times. They fixed it a couple of times. But the technology has matured a lot. And I know, for example, that OpenAI, when they run their models in Microsoft data centers, they're moving more and more to using those TEEs. That's why NVIDIA shipped it in their hopper architecture. Yeah, and one thing to add to this, it is fun seeing how people break SGX. I think there was one where someone was able to do it in their sink, which is kind of scary. But one of the important things here is that the security assumption of SGX is that you don't have physical access to it. And so that's why in our use cases, we don't allow for people to run TEEs at home, even though you could buy one and turn it on. And so there's even a way you can ask the cloud provider to give you a proof of cloud. I think the holy grail is that we could have personal TEEs. And I think maybe I'm overextending the word TEE, but you have a hardware security module on your phone. So we're like, I don't know, not super far. Yeah, I would say, in my head, the TEE security model is something like, with enough millions of dollars of resources, some government could potentially break that at any point in time. And so it's kind of like, I think I see TEEs as a short-term security kind of thing, in the sense that, OK, if it's secure now, it's probably secure 10 seconds from now. If it's secure 10 years from now, I don't know. And so you don't want to hold private key data on a TEE for a long time, for instance, or have some long-range dependency. But it's potentially fine to take a short-range dependency, as long as you're confident that, OK, if we detect a hack, we can immediately migrate everything. On this note that you guys are already going down, we started with all of you explaining what we're trusting when we trust these companies or these decentralized protocols. And it sounded really good. And now we're kind of devolving a little bit into where does it fall apart? And so I'm curious on that topic, where you guys see the biggest vulnerabilities are right now in the decentralized data space? Totally, yeah. I mean, related to that question and the previous conversation, there are inherent risks with the TEE. One, there is the possibility of physical attack. Two, somebody could just unplug the computer. And so that's, at least in the model that we've developed at the protocol, it's not fully TEE dependent. It uses this defense in depth methodology, which is to say, even in the case that the TEE is compromised, there's still the threshold of globally distributed node operators that would be required to collude. And you kind of have a situation where the total is greater than the sum of the parts. These technologies are very complementary to one another. And then another choice that we made really early on was to build on the AMD stack rather than the Intel stack or the AWS stack. And that was specifically, and this is some TEE details, because you could get the attestation, which is to say the proof of the validity of that box directly from the key on the AMD box, whereas in the Intel case or in the AWS case, they have essentially another man in the middle layer where you get the attestation from them. And in trying to build tamper-resistant technologies, we thought that was really an important quality of the AMD product, such that in some horrible scenario where the federal government wants to shut down this type of network, just have the physical box, ship it somewhere, and then the network continues running without this dependency on some mega corporation that has to ordain the use of it by letting you get the attestation. So would you say then it's at the hardware level? Yeah. I mean, there's still the supply chain component, right? But it's the hardware level. And then in the context of lit protocol and running threshold and PC inside of that, then there's also the threshold component is the other aspect of the security. Yeah. And related to that, if you look at engineering systems and privacy systems that stand up well, generally the ones that have a lot of users, that have a lot of backing behind them, that have a lot of investment in this R&D and this bringing it to market, they tend to do pretty well. And Intel, AMD definitely fall in that sack where I trust that and I trust that engineering a lot. I know that theoretically you can break it for X, like tens of millions of dollars, but that's not really practical and that's pretty hard to show. Moving out of the very low level and out of the, here's the firmware, here's the hardware, here's the box, I really think that the user experience and all of the standard ways that you see wallets get rugged, wallets get pulled, having the user experience and having that at the user level, with my data, the thing that I'm most worried about is that I sign on with a hot wallet and I sign the wrong address. And that's something that like Web3 has had this problem for a while. We're making progress and it's this trade-off between safety and absolute sovereignty, my keys, not your keys, not your wallet. Yeah, to add on that, this may be like a different direction of privacy research, but something we've been thinking a lot about, so we have this like initiative of basically allowing people to calculate arbitrages inside of a TEE, and so you can think of this as like also a data privacy thing. We basically give it this sensitive block data and we say like, hey, calculate an arbitrage here and make sure the value goes back to the user, and we lock it down basically. We're like, only a block is going to come in and only a transaction can come out, and sure, we can trust the underlying architecture and we can grit our teeth because if we don't like some minutiae of this, but it'll be solved in a couple years. But I think the fun thing is like, what if a person just leaks one bit of data out of this? Like if you're doing any type of computation on this data and you just leak like one zero or one that tells you like, you know, is someone's social security number on here and does it start with a nine or something like that? So I think that's a fascinating like direction that we're very interested in. I'm also really excited about the initiative that you guys have around the open source TEEs. That's amazing stuff. Yeah, maybe one thing I would say like also like complemented the hardware stuff is maybe like at least kind of the way that I think a lot of other stuff with like the VK proofs is that you kind of want to be robust and even in the face of like these kinds of attacks as much as possible. And so in our head, like one thing we do is we say, oh, well, what are the most secured keys in the world? Well, probably the keys that secure like billions of email accounts. And so if we take like those keys and now we're making proofs that are based on those keys that say, hey, you have to break the entire email network or say like all of Gmail in order to break, you know, to take the signature that's going to be used in the VK proof. To us, that's like a pretty compelling at least start for, okay, well, let's at least start with like if we're going to make a proof of the validity of some data, then saying, okay, the provider who sent that data to the email, at least like we can use that as some trust anchor to say, okay, as long as that key is valid, then this VK proof is valid. And maybe going back to something you said about data sovereignty, I realized we didn't really define what data sovereignty was here. And so I think where we're talking about a few different things and we've mentioned privacy, we've mentioned control, we've mentioned ownership, like I'm curious for you guys, when you talk about data sovereignty, like what does that mean to you? I mean, for me personally, what it means is I own my data, which it's ownership, it's control, it's knowing that I can, wherever I put it, whatever application I use it in. What do you mean you own it? Like what does that actually mean? That's a good question. From a technical level, I'd say that that means that I control it on either my home server, some infrastructure that I trust, maybe I trust the cloud, and that's like, I mean, I personally make that assumption for non-secure data all the time. I keep my documents in Google Drive. But being able to control who else has access in it, how it's used, and really I think one of the things that we're really excited about here at Vana is being able to take that and feed it into applications with the knowledge that I can use it for my application and the counterparty. So the counterparty is the way in which they interact with that data is very well defined. So under that definition, would you have data sovereignty of your data in Google Drive? I would say no, but I would say no. And the reason that I'm okay putting like non-private data is I have to have a Google Drive. So when I upload my Google Doc in there, I don't put my passwords, I don't put any of the security things that I really care about because I don't trust that contractual security guarantee. Well, maybe one thing I would say on the question of like, okay, do you have sovereignty over your own data? If you're using somebody else's service that you kind of have to trust, maybe like one way to see this is like also the context of how people see this in like nation states is like, okay, you have a right to participate or you have a right to exit. And it's kind of like, I think a lot of the regulation has been around, well, do you have the right to exit? GDPR is like, well, can you delete your data? Can you export your data? And I think that as long as you have that property where you can export your data, ideally verifiably, then I think you can sort of, I would say you still have some level of data sovereignty. It's not ideal because you have to trust it's like third party, but at least in systems where everybody else is in that third party, you better have some way to be able to exit and say, yeah, that data was valid and that's what I did. And I have to use it on some other platform and they can verify that's in fact what I did on that platform. And as long as you maintain that verifiability, I would say that like your data sovereignty is part of also the logic around like the data exports is like, is hopefully at least like better than not having that right to exit. This isn't a definition, but one thing I'd love to see incorporated in this definition is like provable deletion of my data other than just like, yeah, we wiped the database, like, okay, are there backups, like, and things like that. Yeah, I think this was totally touched on. These are some great answers. The way that I think about this is whether we came to the context of sovereignty or privacy, almost like looking at this through a different lens, kind of culturally, the notion of sovereignty and privacy is to kind of go with a visual metaphor is that of a castle. What is mine is mine. And that's general kind of understanding of privacy. But really what it actually is, is about building bridges and sharing and consent, and the user having the authority to say, these are the parties that can see my data. Whereas in the Google Drive example, like you kind of have that, but also they're reading your PDFs. And then people can target you with ads based on that PDFs. And like, maybe they can sniff out the type of person you are, because all of the ad tech right now, ad tech has the most complete model of what each person is doing on the internet, with this notion of what they call data exhaust. And like the ideal case, and as the decentralized data space, data sovereignty space collectively, like we are still on the left side of the chasm, so to speak. And I think the big milestone is when we can go, ah, there's a lot of people on the internet, where the most complete model of how they are moving through a digitally mediated society is owned by them, defined by they are the parties that get to decide who gets to use this data and what for. All right, I think we have time for one more question maybe. So to wrap it up, what big breakthroughs are you guys looking forward to? Do you think we need to see to get to like full data sovereignty, or are you defying that in the next five to 10 years? If any? Well, the timing is really great with LLMs. Like, you know, this idea of user owned data and data sovereignty, as mentioned earlier, has been around for a very, very long time. But there's been this open question around like, what do I use this for? What's the point? And largely, that's you could say that's been a critique of the whole crypto economy, as less than 1% of the GDP is like, it's for nerds who are idealistic. And that is, like, no way to push something out to, you know, 90% of society. And so it's a little bit of magical thinking here, what I'm proposing, but I think we all kind of have a sense of what this mountain looks like, is that when you start to have, like, where's the thing that is your home on the an LLM, your core assistant kind of can think about the movie her and you're interacting with your core assistant, and is your core assistant using data that you own, that then acts on your behalf to interact with the internet, which we can like maybe assume will become a swarm of agents that you interface with. And so those type of constructions, and you know, like Apple and Google are going to go for that opportunity. And what we have collectively as a space right now is like 18 months, I think, to get the breakthroughs for you is like on the demand side, like it's not it's not a tech breakthrough or a security breakthrough. It's like we need a clear breakthrough on the demand side. 100% Yeah. I agree. And I think that, like, to me, tactically, what this means is you want a livable user experience and a very good user experience, ideally, on the web free side, which we've been getting there, we're getting there, we've been getting there, I think we'll be getting there for a while. And the other thing that would be really interesting is not really a tech breakthrough, but more of a, even a legal breakthrough, right? Like one of the things that was a pretty big tailwind for us with the Reddit data down the original, kind of like that, that was the OG thing was people were able to do GDPR exports, and really the easy way to off ramp the data from these Web2 companies, and on ramp them into your own self sovereign cell phone storage, and, you know, data network. Yeah, maybe building off of like, the ideas of like, Oh, well, what do you like, anything your research direction looks like, I think, like, if we can get like, ways to run like LLMs over FHE that are fast, like really powerful big LLMs, then you can kind of be able to query other people's data in ways where they can say, okay, like, this is going to run and it's going to output something. And no party is going to see each person's data, or like LLM2PC. And I think also along those lines, there's like a bunch of cryptographic primitives that we've like not seen so far, like things like witness encryption, which like, we kind of think maybe exists, but we don't really know that I think like, if those exist, then you can make queries, which are like, Oh, I'll encrypt this data, but only to people that have some property. And I don't know, like, who those people are ahead of time, but they must have this property to read my data. And I think being able to make statements like this, like we haven't even been able to think about that, because it's not really possible unless you like, I mean, it's in a TEE. But I think like, really seeing like cryptographic primitives evolve, I think will enable a lot of new stuff. We talked a little bit about like, kind of the Jim Gloom scenario. I'm very curious about Dan's take here. But like, you know, there's, there's the pessimistic side of the data is being hacked. We're being used as cattle for our attention and dollars. But I think like getting these rails in slowly, but surely, and then all of a sudden, very quickly, I think it'll be very clear that the data sovereignty actually leads to a better experience for people a better internet. These are things like, like, we're not going to have a global collective intelligence that is functionally owned by nobody, but everybody contributes to siloed in an individual company, something like that only arises in the context of using distributed systems and privacy enhancing technologies. Agree. Yeah, my answer to the question would be, we got one FHE, hell yeah. I feel like that, if that gets practical in the next like five years, I could like reshape the entire internet. And then my two other answers would be like, something like Tim Berner Lee's solid project, which allows you to put like access control on the data, but augmented with object capabilities, like the idea from security research, that you can like define functions on top of this data as well that you have to like authorize someone to be able to call. Because I think, you know, it's one thing to give someone your data, but then it's another thing to like define how it gets passed around in their own internal wall. And my last thing is like, I guess, just like more of like a fun research engineering thing. But like, if I can remove my influence on an LLM's weights, just like at the click of a button, like we could easily like DOS, Catchy PD, which like, probably we need to think about that. But that's like, I think something super cool. I mean, like, one question that I would not be so happy about if I were training one of these large LLMs is, if I want it to be GDPR compliant, how do I remove the data? Like, where's the right to be forgotten? Do I retrain the model? I don't know. Good for thought. But yeah. I mean, that's why OpenAI isn't in the UK, right? Like, that's a very real problem. Yeah, maybe just touching really quickly on something you just said, because we haven't talked about this, but this like data replication issue of like, you know, you give it to someone, or they didn't have the right to repeat it or to sell it to other people. And you briefly touched on this. Were you saying you think that there's like, possible future breakthroughs around that? Or was that just like a one off? Yeah, I think if you're able to define, like the functions that they're allowed to call on your data, so like, if you let them call coffee, then sure. Yeah, I don't know. I'm curious, I feel like Vanna thought about this and like the compute on top of the DAOs, right? The data. Yeah, one of the really interesting problems that we've been grappling with is, how do you let people be self sovereign and upload that data and, you know, monetize that data, bring it to the applications that they care about. But at the same time, like the minute that you let an application use the data, if you aren't careful, if you do it in like a wrong way, then that data is out of the ecosystem, it's not very self sovereign anymore. And from our side, like one of the, this is one of the great uses of TEEs, which, you know, two properties that we care about, verifiability and confidentiality. Yes, I suppose integrity also. Where, you know, our answer to this is, let's let an application run inside of a secure compute environment, run in a place where it's privacy preserving, it has integrity, you know that the, and it's verifiable that it's running the operations you think it is, and feed like just the raw output, just the like, personally, if I have a piece of data that's used in an LLM, I'm okay. And this is one of the things that we're enabling users to do is say, yeah, I'm okay with that operation on my data. I'm okay with it being an aggregated waste, but I'm not okay with it being shared to the public. We're really enabling that user control is something that you're right, we've put a lot of thought into. Awesome. All right. Well, thank you all so much.