Episode 339 - TEEs with Andrew Miller

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week, Tarun and I chat with Andrew Miller. We cover his previous work on consensus, ZK, and MPC, and then switch to the focus of his current work, TEEs, or trusted execution environments.

We map his evolving opinion on TEEs, and why he sees them as an optimal solution to many blockchain challenges. Now, before we kick off, I want to remind you about ZK Summit 12 happening in Lisbon on October 8th. Our one-day ZK-focused event is where you can learn about cutting-edge research, new ZK paradigms, and products, and the math and cryptographic techniques that are giving us epic efficiency gains in the realm of ZK. Space is limited, and there is an application process for early bird tickets. I've added the link in the show notes. Be sure to apply and see you there. Now, Tanya will share a little bit about this week's sponsors.

Aleo is a new layer one blockchain that achieves the programmability of Ethereum, the privacy of Zcash, and the scalability of a roll-up. Driven by a mission for a truly secure internet, Aleo has interwoven zero knowledge proofs into every facet of their stack, resulting in a vertically integrated layer one blockchain that's unparalleled in its approach. Aleo is ZK by design. Dive into their programming language Leo, and see what permissionless development looks like, offering boundless opportunities for developers and innovators to build ZK apps. This is an invitation to be part of a transformational ZK journey. Dive deeper and and more about Aleo at aleo.org.

Gevulot is the first decentralized proving layer. With Gevulot, users can generate and verify proofs using any proof system for any use case. You can use one of the default provers from projects like Aztec, StarkNet, and Polygon, or you can deploy your own. Gevulot is on a mission to dramatically decrease the cost of proving by aggregating proving workloads from across the industry to better utilize underlying hardware while not compromising on performance. Gevulot is offering priority access to ZK Podcast listeners. So, if you would like to start using high-performance proving infrastructure for free, go register on gevulot.com and write ZK Podcast in the note field of the registration form.

So, thanks again, Gevulot. And now, here's our episode. Today, Tarun and I are here with Andrew Miller. Welcome to the show, Andrew. Hey there. Thanks so much for having me. Glad we can finally do this. Totally. And hey, Tarun. Yo. Excited to be back. Yeah. Uh so, Andrew, you're one of those guests that I've been trying to get on the show for a very long time. I put the word out a few years ago through friends trying to reach you. I didn't at the time. But, I'm very, very happy that I got a chance to actually run into you about a month ago. Like, we were on a panel. You couldn't You couldn't get away. And I was like, "Hey, would you be up for coming on the show?" And you said

yes, and I'm so glad that that you're here. I know that for today's episode, we're going to be primarily talking about TEEs and your work on that kind of topic. But, before we go into that, I'd love to go back in time a little bit and look at some of the earlier work in your career. As I was doing a bit of research, I saw that you had worked on early papers with Joe Bonneau and Ed Felten and I know some other authors. I just saw a lot of your work intersecting with previous guests on the show. Let's go back to maybe that point. Let's start there. What were you working on back then?

What were the problems that were very exciting to you? Oh wow. Yeah, I mean so just prior to starting to work with Arvind Narayanan and then Joe Bonneau and Ed Felten on we did this textbook together and an early systematization of knowledge. Right before that I had been kind of pivoting my original grad school career in VR and graphics and 3D stuff. I just got totally down the rabbit hole of Bitcoin and especially reading like the old consensus papers and BFT papers and talking on the Bitcoin dev IRC channel and all of that. So my first interest there was really trying to do consensus, you know, BFT models of Bitcoin understand it from a BFT protocols

perspective. And I had been doing this posting a lot on Bitcoin forum and on their IRC channel. Also talking with other, you know, academics was known by that. I think I ended up responding to it was Arvind who initiated this. He said he's trying to work on the survey paper and it's um you know, on Bitcoin cryptocurrencies. Anyone interested in helping, you know, just join from the public or academia or whatever. So I signed up and I started to get really interested in what I would say is um bridging the gap of academia and industry which at the time and really how I would frame that project with them is we had seen this trend of research papers that you're either reinventing or just talking about Bitcoin things and then everyone in Bitcoin world is

furious that oh you're not citing our mailing list post from the other week or you know, following our we've already gamed through the second, you know, consequences of these tech choices. The Greg Maxwell invented everything before you did argument. Yeah, that's a Matt Green tweet, right? You know, every good idea under the sun's been invented years ago and just thoroughly refuted in the Bitcoin talk forum. And so yeah, we tried to do the survey paper that would you know, bring us all into alignment there and had a bunch of I think events we hosted with cryptocurrency devs at the time and uh Did it work?

I I absolutely think it worked. There's now quite a lot of There's a strong pipeline of This was before all of the professor coins if nothing else. So, um Okay. There's I think now a very you know, high-bandwidth bridge between academia and the Web3 industry. So, you were working before this on like media video stuff, like video encoding. What What did you just say? Ooh, augmented reality. I had a really cool project as my master's project on the Microsoft Kinect, you know, the 3D scanner. So, you would do real-time scanning of Duplo blocks as you would build them and then instructions for how to follow along with pop out on a remote side on a projector thing. So, it was OpenGL graphics matrices kind of stuff.

Were you in computer science doing this? Was computer science, yeah. Oh, it was. Okay. Yeah, this was at Central Florida. Is there any point where anything you learned from that comes back into play in what you've been working on ever since? Oh, wow. That's kind of a tough question. Maybe I mean, what what's ever on my mind about that is just I really like changed my behavior personality almost entirely before there. I was a terrible grad student the first time around. I only like doing my own programming and I didn't like reading papers or talking to anyone. I kind of just wanted to wait it out until joining a game company or something. But then when I pivoted to crypto, I switched hard and I was then really interested in understanding the old papers and kind of this connection

to historical efforts and you know, did a much better intentional job of socializing the research and trying to do that. So, you know, that ended up a lot more fun the second time around. It's like I got a second go at grad school. Nice. But what Why do you think that is? What was it about this topic or this community at the moment that you joined it that got you so excited? I guess at the time I felt this really strong sense of mission. I had this sense that was like I've got this opportunity. I'm already in grad school and supposed to be doing this and this is such an important movement. It has all of this potential. I was really into like free software and I guess libertarian principles at the time. I think I had wanted at some point to be an Electronic Frontier Foundation

lawyer. That was like another career path I was trying to Okay. pick for myself. Um, so it was like this is the way to contribute. This is really important. At the time I felt that just by being an academic and working on Bitcoin, I would be, you know, bringing it to the mainstream or to the, you know, getting the right people's attention to look at it for the right reasons and I kind of figured it would just crash but still I could carve out a little theory niche where, you know, a new look on BFT protocols and that would be interesting enough for one, you know, career start. Cool. How old were you when you got into this? Oh, how old?

It would have been 2011 that I started my kind of pivotal. I kind of dropped all of my tasks and, you know, got away with it but just spent the whole year and a half reading these BFT papers and posting. And then in 2013 I transferred to UMD and that was when I really started my grad school, you know, over again fully. It was like high energy. I showed up with like printouts of all my BitcoinTalk forum posts and it was like these are the, you know, topics and directions I want to turn into, you know, research papers and, you know, largely got to do that. My first experience of your work from that time-ish was the Nipa post. Nipa posts? Nipa posts.

I I guess like when you were reading the forum posts and then kind of congealing things into research, was your goal more to be computational anthropologist or was your goal of that era or was your initial goal to like find something new? Cuz like I kind of feel like I've seen both of your writing styles of like the what I I guess I'd call like internet anthropologist versus the kind of pure new type of stuff and I'm just kind of curious as you kind of did that transition, how you kind of balance those two goals. That's a fun question, too. Yeah, I view it as a balance. I view it as two facets. I love the computational anthropology viewpoint. I picked up a lot of that from Nick Szabo, too, right? That was a lot of his style of writing, you know, posts about the historical context and

also these new things. Maybe I viewed on him as like a role model like that. Definitely part of it. But oh, I wanted to I wanted to break a you know, a new thing somehow. I think I ended up falling into you know, the path of what I would do is I don't feel I've been right on the cusp of a new thing so much, but I think I've been done great at scavenging, you know, old bits or overlooked bits and you know, finding something useful to attach them then. So, I think that's where I get my um I feel I'm being adequately innovative and enjoy it. Yeah, I like the anthropology and explaining the the you know, context and and ecosystem view of it. I think something along those lines also is um I've gotten to see now several times a new academic field

uh get the Bitcoin bug and dive in and you know, be absorbed by this like the uh the financial cryptography crowd were some of the first and so computer security and that kind of you know, subfield in computer security. Those were the first to you know, take it over. And I think then the the cryptography world with zero-knowledge proofs came next. And you know, it wasn't till later that like the formal methods community had their turn with the smart contracts and then proper be you know, distributed systems, you know, came over. There's probably some other subfields that have gone, you know, along those, but um uh that's always been fun to see and bringing the you know, the anthropology message a little bit is always helpful in doing those cuz you say here's this long rich of open problems that have been tried really hard from all the

viewpoints available from this community and that that's clearly been the appealing to all these different fields. I'm curious the cuz at some point you also moved into ZK. And I don't know if what happened in between sort of that work of at first describing blockchains and doing these polls and and surveys as you called it all the way to yeah, your involvement in ZK. Like was it because ZK entered the fray that you then noticed it or had you kind of found it yourself before that? Oh, no, I definitely hadn't find it. I mean right when I got to University of Maryland, I think I got to meet Matt Green and Ian Okay. and Christina who had done doing the Zcash paper. Yeah.

And everyone was talking about snarks at the time. I mean I got there with my I want to work on BFT and authenticated data structures and proofs of work. And zero knowledge proofs are about to become, you know, the big deal. This was like the Pinocchio or GDPR paper right where out then. So all the cryptographers there were excited about this and the Zcash paper had already explained how to do this. Nice. And I think the main project that I worked there that to me really set myself on the direction that you know, as we'll talk about has been a fairly continuous direction since then was this Hawk papers. So it's saying Zcash is already showing how to use zero knowledge proofs for transfers, which is what Bitcoin's capable of.

But we can think about all of these smart contract applications, whether it's from early Bitcoin script at the time or you know, Ethereum had been on maybe on its way when we started like we knew of Ethereum even though it might not have been out yet when we started thinking about Hawk. But we want to do auctions and other, you know, more interesting applications with private data of some kind. And so that was the scope of that project like how do we glue smart contracts together with zero knowledge proofs and get some kind of, you know, privacy auction and other applications on the way. That is so early. What year is that? 2014?

2016 or something? Yeah, 2015 I think is when the you know, e-print for Hawk might have been. Yeah, and at this point so Ethereum is live, I think, but in its very early stages. Yeah. What you created with Hawk though, was it like a rebuilding of a smart contract platform from scratch like with a UTXO model and SNARKs, or was it like actually in any way referencing what Ethereum had done? Oh, it was such a nice hack. Definitely not the first thing you described of like a deep rewrite. It is what I would call a mashup. Like we call it a, you know, a language, but it's really just here's your partition of code that's Solidity, here's your just partition of code that is a C program, and then we just carve out the C program, pass it

into the Pinocchio compiler. So, that was the first ZK front end that was available at the time. Mhm. And um then wrap the resulting circuit within a utility circuit that adds the commitments and the SNARK-friendly encryption and hash functions and so on. At the time we didn't have SNARK-friendly hash functions, so it was just SHA-2 the expensive way, so it was slow, and AES encryption the slow way, so it was slow. Now, of course, we'd use like Jubjub and Rescue or Mimc or one of those. Poseidon. Yeah, exactly. It's funny, it's also it's coming out around the same time or like even a little bit before Groth16 or any of the modern SNARK systems. That's right. We had Pinocchio then. Yeah.

Wow. Is that the first work you do where you actually like start to work with ZK? Yeah, yeah, exactly. That was the first time using ZK and doing anything yeah, privacy-centric that way or confidential yeah, that way. One quick question, just like philosophically, you know, a lot of the focus in the Bitcoin Talk forums was in the early days of just like either improving throughput or kind of like, you know, I think about the Scaling Bitcoin conferences prior to 2016. There was like a bit more of a focus on privacy versus scaling, whereas I'd say the Ethereum ecosystem, you know, Vitalik would maybe not agree with my characterization, but I'd say the empirical data is that Ethereum cares a lot more about scaling than they ever

really cared about privacy. And so I just I'm kind of curious how you kind of synthesize all the kind of privacy versus scaling trade-offs and then ended up writing something like Hawk or NiPoPo NiPoPo NiPoPo Pow's NiPoPo Pow's, sorry. NiPoPo Pow's, by the way, it stands for non-interactive proof of proof of work. Andrew can correct me, but I view it as personally just like a way of doing like a snark of proof of work without, you know, it's like a way of just like proving that a proof of work a set of proof of works existed without having to do the calculation to verify.

Yeah, that's exactly right. I I had a bunch of unhinged and, you know, didn't quite solve the problem post on Bitcoin talk about this. Yeah, it's just how you describe if if it's too expensive to do a snark proof or you just don't have snarks available at the time, then this is like a sampling-based alternative to that, but with the same goals and that would be a useful component within a light client or a better SPV client or or a smart contract-based light client. Um so, that was the the intent of it at the time. I guess that's pretty interesting. I mean, so I I I think that I have been detached mostly from the scaling effort. So, I I helped later with this on scaling Bitcoin position paper. That was like the merger of a bunch of already separate like measurement studies that Günther

and Christian Decker, the Swiss team, were working on. I I guess I had been kind of caught up in the drama of the the Bitcoin scaling debates, but not really picked a side or um dug into it other than wanting to, you know, do that measurement approach. I definitely cared about asymptotics of consensus protocols and those are about your cost and overhead as a function of n, the number of nodes in your network. But, I guess I would take that on as really just a technical, you know, very abstract, very academic, you know, goal. Like, that's the target. Let's go make an algorithm that beats that goal. I don't know that I really conceive conceived of that as helping the scalability effort that way so much. To me, the most salient trade-off was much more privacy versus expressiveness.

Don't tell 2017 ICO papers that statement you just said. That's awesome. It Yeah, so to me, it's the the the expressivity versus privacy trade-off is the more interesting one. I was very into the idea of what Ethereum wanted to do with more generalizability. And you read the old Nick Szabo papers and it's clearly about this general computing and we'll build these agoric market structures and whole new conceptualization of, you know, a world that has this tool in it for coordination. So, obviously programmability is the way to go explore with that. So, I was really interested in seeing on, you know, smart contracts go. I think I had wanted to do something like that prior to hearing about Ethereum cuz it was in like the early

Satoshi you know, the deleted pages of code from Satoshi's Bitcoin was like a poker and a marketplace and all of these extra features that, you know, were carved out cuz, you know, that didn't fit into the Bitcoin that worked and was launchable, but it was always part of the zeitgeist, part of the grander, you know, set of things that are possible. I'm on the side of exposing foot guns to developers. I'd much rather see the open-ended exploration. The fact that Solidity is a dangerous language doesn't make me want to say stop using Solidity, only use Bitcoin script. So, I'm way more on wanting to um accelerate what the, you know, smart contract developers, permissionless innovators have in their toolbox to work with. And um so, to me privacy was just one thing

that, okay, we see kind of the pattern. We see how to add Ethereum on top of Bitcoin. It's still a blockchain. It's still a proof of work, whatever. Um it's still just operating on transparent data. So, adding confidential computing of some kind, you know, to it was uh what what I cared about the most. What other involvement did you have at the time in the ZK world, though? Cuz I feel like were you not part of the Zcash group at some point? I was part of the Zcash group, but I don't think I've made technical contributions to Zcash so much. Definitely worked on the Hawk paper, but that didn't turn into a you know, a thing that hit the real world per se.

So, I mean, I helped with early Zcash governance and uh participating and maybe um explaining some things. Definitely was a participant in the trusted setup. Yeah, the first one you mean, the six-person one. Yeah, I was in the six-person one. Back then a trusted setup took, you know, 24 hours and you had to sleep on a mattress next to your desktop computer and then hit it with a sledgehammer when you were done. The next one was a lot simpler. You were not the one who went into the woods though, were you? No, I wasn't in the woods. No. So, I feel like one of the participants like drove to Canada into the woods.

You're thinking of Peter Todd driving his desert bus with his uh thing and using satellite internet to Yeah. do his rounds, drive across the tundra or something. Yeah. That's crazy you were part of that though. So, you're part of this early Zcash, but you feel like you weren't actually active on the research front. You were sort of like looking more on the the spirit of the project, I guess. Yeah, I'd say that was right and I I've been picking technical battles for sure just on they're they're more in the lines of um, yeah, the smart contract layer which um, I guess I would even say I hope someday, you know, ends up being available for Zcash to use, but um, it makes sense that Zcash is more on the conservative, only add safe features, put a very high, you know, allocate all the points towards uh

safety and reliability of, you know, doing the the ZK proofs in the smaller scope the right way. Yeah, and as we get into TEEs and these extra things that take other, you know, trust assumptions, I like the idea of not enshrining extra trust assumptions into a protocol, but I love the idea of, you know, making them available as uh things that can just attach to the side and provide some value even when not enshrined. I'm kind of curious like at the time that you were part of doing that early Zcash stuff though, how you felt about TEEs? Like I know a lot of this episode is going to be about that work, the the sort of more recent stuff, but did you have an opinion at the time? So, my exposure to TEEs was from reading Richard Stallman, you know, posts about them and, you know, the

first applications of TEEs were for DRM, which if you're precise is digital restrictions management. Like their only use is to keep users from being able to use their laptops fully. Like you know, so they were in the context of the opposition against general purpose computing. And so they're horrible. Like avoid them. They're going to lock you out of your operating system. Not like you edit the OS or anything like that. Terrible. Um so I hated them. I would hate them for years to come after that. So it really wasn't until maybe 2019 or 2020 that I started really paying any attention to them in a positive way. I was just laughing cuz you know, anytime Stallman shows up it's like which person are you getting this time?

But I uh I I guess like one question, you know, if I think back to that era of your research, there was you know, the Honey Badger type of stuff like maybe a little later. There was sort of more of a focus on classical consensus algorithm improvement. Let's fast forward to 2024. You know, I still go to conferences where I see a ton of new consensus protocol papers. I have very strong opinions about the answer to the question that I'm going to ask you, but you know, where do you see consensus research in 2024 versus 2016, 2018 when it was like felt like every week there was like five new papers that had some actual improvement.

Yeah, it's different now. I don't have a super uh sharp answer cuz I would say that largely after um I didn't keep going with consensus in depth after Honey Badger BFT. Um so I followed it kind of at a distance. I mean, the whole switch to pipelined BFT. I wish I had thought of that and worked on that kind of version at the time. So I love that Honey Badger BFT kind of kicked off this resurgence of asynchronous BFT protocols, which is the most interesting setting for consensus. And um the idea that you could have pipelining for asynchronous protocols is quite exciting. It's so interesting that I mean, consensus in distributed systems looked like a solved field. They started to have these papers. I wasn't like deep in this community, but from what I could

see from reading like the conference, you know, forwards or keynotes, they they started to talk about it a way I had seen people talk in academic VR, which is like our field seems stagnant and solved. What are we going to switch to doing next? Like we've already set our lower bounds and met them all. You know, what's left to do? And and so to me, well, Bitcoin opens up this whole new assumptions change. Like now you no longer can rely on a PKI. You don't know who the anonymous participants are. Um so you need something else like a resource limit, you know, to open up proof of work or incentive stakes. And that just changes this whole perspective, opens up a whole new, you know, room for that that community to grow into. And what I would characterize as happening now in consensus is um the

idea of having not all of it's like many viewpoints, but one system. Like you bring your own set of assumptions. You have many different groups of users of the same system that have different threat assumptions. And whichever ones the assumptions that they base on are justified they get a secure use of the system. And someone whose threshold was set, you know, inappropriately low, maybe there's a setting where, you know, they have a double spend or kicked off the network, you know, failed to get liveness, but everyone else keeps going. So this is either subjectivity or suddenly I'm not forgetting the the right phrase. Like heterogeneous trust assumptions or flexible BFTs maybe, you know, the name of that. So in other

words, if if you don't just have one set of assumptions and okay, we can maybe find a new set of assumptions and that pivots it. Now we just have, you know, fine nuanced multi-layer assumptions and that opens up a lot of a possibility. I think you see this in like the high performance Aptos and Sui and Mysten kind of things where you've got like a very fast pipeline fast path and a reasonable like secondary path and then some, you know, worst case. And that's kind of like your switch from synchronous to asynchronous Interesting. operation. And I think that's the how I would characterize the direction consensus has opened now.

Yeah, I mean, I feel like from that era there was this whole there was, you know, I think maybe it was a little before its time, but something like Thunder was all about this like fast and slow path separation. Uh which, you know, is common in most database design or really any non-crypto thing you you tend to find that type of thing. I think the thing that's weird to me is that I remember when I first got excited by reading consensus papers I always felt like it was there was like a a real improvement that occurred in in a lot of papers like, you know in you know, HotStuff I I like shrunk the number of rounds decidedly or I like shrunk the bandwidth required per round.

Um in Tendermint, you know, I have kind of very clean formulation of PBFT that's like almost cleaner than the original formulation in some ways. But then I like read these papers where with like the heterogeneous trust assumptions where it's like, "Okay, you want to be optimistic, you only need 20% honest. Oh, okay, no, I need like worst case 50%." Whatever. I feel like there's a little bit of moving deck chairs on the Titanic. Like it's like the the thing is going to crash anyway and like people have already built these things and they're not going to build 10 more code bases of the same form given how hard it is to test these code bases.

So like I I feel like consensus research has really lost its way. That's like me as an outside observer. It's lost its way again. Lost its way again, yes, that's that's true. Lost its way again. Again is a very key word there. Or is this a new stagnation? Is that sort of what you mean? Is this stagnation similar to what you had experienced before the Bitcoin blockchain kind of new paradigm showed up? Yeah, I guess that's what I would say. I mean, I yeah, I don't have the best answers here. I I I I guess that that is the natural flow of things once the the changes are solved for a while until there's a whole new paradigm that shifts everyone around a bit. You get more what you call, you know, pejoratively, you know, incremental research papers that, you know, optimize something, but it's in a

trade-off with others, so not a slam dunk, or it's, you know, small improvements, but not a or it's improving the less important thing, like it's making your non-fast path faster, so, you know, how do you sell the backup case performance? It's too too hard to sell. So, I would say it maybe Yeah, you could be right, but if so, that's only at at funny field will come up with something different to do. I would bet on consensus doing so. Over two years ZK, where like they changed the asynchronous model in some more fundamental way. Yeah, that's a good question. Is ZK being saturated at this point yet, or still has, you know, just as a technical and cryptography field still further to go? I'm not sure I have a good answer. I actually just recently did a talk on the history of ZK in the

last six years, seven years. And I was going through like each year and what kind of research was being published and what it meant. And 2019, 2020, if you look at the frequency of like incredibly important work being published, it's very, very high. And I think it's the highest our space ever saw for proving systems or a brand new technique, like look up tables were introduced, folding schemes were introduced for the first time. You really see this compression and so much excitement. Somebody coined in late 2019 like SNARKtember, SNARKtober, you know, but then the next year we had even more research. So, we had to do it again the next year.

That's got to have been Mikeraz's name for it. I remember that and um It was. Uh but but what's also so notable to me about this is that to me is the the success story of that academic to industry bridge, cuz I that stands out as um what are traditionally like those are huge technical contributions that get cited and are regarded as, you know, breakthroughs. And those came from industry in a field that is primarily those kind of contributions come from the universities. So, that's like the the coolest story for me there. Yeah. That said though, just to continue on that story to today, nowadays there are works that are coming out I I think there are still like in 2024, there's like at least two works that have created somewhat of a paradigm shift, but not as much so far.

In 2023, maybe Binneas has like a slightly similar vibe. Maybe JOLT. But then there's two. Whereas like really in 2019-2020, every one of the systems that's coming out that I mean I I went went through the list and it was kind of wild. In that two-year period, there's about like 14 works that were really really influential and changed something. And some of them, you know, completely changed it. That we're not seeing at the same frequency on the research side. Where I think ZK is today is it's just on the use case side and like how like where do you apply these systems is where it's very very exciting. Yeah. I want to dive more into the T stuff though. So, we talked a little bit about

what you had initially felt about it or where where you were coming from, but you started to produce some work on it. This paper Delegatee came out in 2018. Tell me a little bit about that. Did you continue with that work or did you just like do this one-off? How did you get back to it? Yeah, the um so TEEs were around at the time. I mean, for me the the kind of thing in between is multi-party computation. So, it became clear that you reach a wall with what we can do for Hawk. Hawk just used zero-knowledge proofs and then standard blockchain stuff.

Um but it was really unsatisfying because the auction application has this auctioneer who sees all of your failed bids. So, you don't get any post-trade privacy or failed bid privacy. And there's a paragraph in the end of it that's like you could instantiate this manager party with multi-party computation, but I didn't know how to use that at the time. And so, it was clear that Ari Juels especially and I guess Dawn Song at the time were doing a bunch of SGX related projects. Um like Town Crier was I think the hot thing from Ari's lab around that time. That must be 2017 or 2018. I'm actually not exactly sure. I think I think I remember that because I just remember the old Chainlink Marines shilling it for a while.

Yeah, that's right. Um So, I was aware that you know, that those to me are two alternatives of ways of getting around the thing that the zero-knowledge proofs alone, you know, have this limit. So, with the zero-knowledge proofs, there's a witness. The prover has to know the witness, the secret data to make the proof of it. So, it's good at showing facts about data that you already have and that can already in a UTXO and by adding commitments and public key encryption, you can build these cool, you know, Zcash works like this and you know, the commit and reveal kind of partial solution to an auction with Hawkwork. that. But if you really want to compute on private data, you don't really have alternatives. So, there's either multi-party computation where it's secret shared data and you compute on that. And that was the path that I

bet hard on and kept working on for, you know, 3 years or so as the way around that and I kind of, you know, I was still in the SGX sucks and the whole concept of TPMs and trusted hardware is bad and bad for users and bad for freedom. So, I really just tuned it out. But Town Crier of course is like a SGX based Oracle. So, it would have this access to sensitive data. Like it is watching alongside uh your TLS connection when you log into some website. And it can make then a a proof using this remote attestation feature, which is a lot like a ZK proof and this is a lot like something you could do now with ZK TLS or or TLS notary, these kind of things. But it can make for example, you

know, a summary of what was in your bank account. And so, it's like an Oracle and it can even be an oracle that does some computing and filtering on it. So, that was their paper and it was really pretty cool. We wouldn't try to do something like that with pure MPC because when we started trying to do MPC-based computing on private data, so difficult to use the frameworks and so performance slow that we would work on very stylized like a simple automated market maker that's like an automated market maker, but you don't see the size of the liquidity pool. So, it's kind of a dark pool proceeding in batches. This was the paper you did with Min Kwe Ra, right? Yeah, that's right.

Retel um in MPC as a side chain, which we worked on for nearly 3 years. That was a tough uh grind of a paper in part cuz the MPC was difficult to work with. And I got to compress this to be able to talk more about um you know, TEEs, but I kind of reached the conclusion that well, really what did it for me is this notion of a collusion attack. So, I could kind of see that okay, performance is an issue even when we try to do data sets, databases, we'll need oblivious RAM inside the MPC. So, it's going to continue continuous be a difficulty. But, in a way, even if we fixed all the performance issues, it would still be so unsatisfying because we have to pick N nodes to be our MPC set. And the collusion risk is that it's secret shared data. So, yeah, you can do a

computation on the secret shared data and only reconstruct the final output for everyone to see. But, if those nodes wanted to, they could just work together and collude and just combine their shares and decrypt everything, all the intermediate values, all the original inputs. And you can't even get them to prove to you they haven't done that and you can't, you know, ask them whether they've done that and get anything, you know, confidence-inspiring as an answer. So, I could grind it out further and keep chipping away at the performance challenges and the programmability challenges, but that would then be the the biggest brick wall and that was when I started to accept on you know, that TEEs are are necessary and even if the MPC works, you'd still want TEEs too and that's kind of my modern framing of it.

Um and I could go back to then the things that had passed me aside where that, you know, Town Crier paper. I helped with Delegat T, which is a lot like Town Crier, but with write access as well. So, the TEE can then um, you know, send messages to an account you've authorized on your behalf. And that opens up all of these kind of weird opportunities that um, I think are fun to talk about like turning Web 2 accounts into, you know, rental offerings. It's kind of a strange, surprising thing you can do with those. And then the Akita paper came out, which I helped with a little bit. That turned into Oasis. That was like 2018. Um, but I I I still was angry about TEEs. Like, my only help on that paper was like race condition in the blockchain like upload download bit. I still hated the TEEs at

that point. So, um, uh, yeah, I kept that at it for a couple years in MPC then. So, the MPC though, you just at some point realized the limitations were too great or the work would just be grinding, like almost trying to create an environment that MPC wasn't necessarily suitable for yet or maybe will ever be. So, you kind of went for TEE, but do you still see it as an intermediate solution or intermediary solution where you're like, "We're going to use it for now. We will replace it, but there's nothing yet that can do better." Or do you think it will always be part of the stack? That That's a perfect question. I mean, that's maybe the the most important question for these cuz yeah, if it were just a matter of work and make performance, I would probably prefer to grind it out and

keep, you know, chugging away at that. No, in a world where cryptography, even the very fancy cryptography, let alone FHE and um, but even other things like full-on obfuscation of some flavor and witness encryption, that kind of, you know, even beyond FHE future crypto stack, even in the, you know, dreams of cryptographers, if all the cryptography does what it can, it still doesn't get rid of the need for something like trusted hardware that can have statefulness. Like, you need um, you fundamentally need some, you know, irreversible write.

And there's just no cryptography protocol that gives you an irreversible right. That that needs to come from something external. Maybe it doesn't have to be trusted hardware. But that's the only thing in my mind that seems to fit there. I I guess like yeah, I think I you know, you're always a couple years ahead of me historically. Except in DeFi. And I I would say I would say that you know, I I came around to a very similar realization. Not that I don't think that there'll be a lot of cool things built with ZK VMs, but I do think there's a lot of applications where people just want to try something and do it quickly. And they also don't want to have all their data public in a blockchain initially. And they're

willing to make the trade-off with the hardware. Cuz like if I think about people who are using like 90% of people who are using mobile wallets arguably are making the same trade-off hardware-wise, right? They're using Face ID and whatever attestation that is in the T in their phone or their computer. Like I feel like the the new users of crypto, the difference between T and not T is like zero to them to some extent. And so you know, I think if people are already on the user interface side making that compromise so that the end user doesn't effectively oblivious that then it's sort of clear that hey, look, maybe augmenting existing contracts with T's kind of yeah, doing this credential like

matching, doing kind of the TLS type of stuff. It just feels like it's probably going to be more impactful to end user if you're willing to make those assumptions. I think like obviously roll-ups are a place where yeah, it makes a ton of sense to be ZK, right? Like the input is just public anyway and everyone's already agreed on the input. So it's like But I I I feel like there is this whole world of things where I think it's like interesting that people from MEV land came into T's kind of out of, you know, necessity being the mother of all innovation versus sort of like endogenously thinking of a solution.

Um so, I'm I'm just kind of curious like now that you've you've had like a few years of conversion into the gospel of the the enclave, I was trying to figure out if I could make some type of pun with conclave and enclave, but it wasn't quite wasn't quite close enough. Oh. But uh you know, like what are kind of the things you think that are easier than what you expected? What are things are harder? Sort of like how what do you view the trade-offs as? Cuz like you've kind of written code in all of these different systems. So, you have sort of a high-level overview.

Yeah, I mean, I'm maybe just building on, you know, what you were just saying like I I have two visions in mind. One is what I think's going to happen right now, um and the other is what I, you know, think should happen or is like the architectural ideal to build towards. To me, the ideal to build towards is um in the future, we will have you know, multi-party computation nodes doing the decryption stuff for step for FHE. And these nodes will to prevent that collusion risk, you know, there will be an MPC of them doing the decryption, but they will run in trusted hardware that prevent those nodes from colluding or doing decryption on anything that they shouldn't. And then hopefully at those point because it's just decryption, it's not bottlenecked on the performance of those, we wouldn't be having to use SGX or something from one or two

manufacturers. We'd be able to use some blockchain native uh verified don't trust TEE alternative that come from, you know, I I I can't say how to do that, but maybe the kind of people that were doing Bitcoin ASICs and now are doing SNARK accelerators. If they work on TEEs next, maybe that'll be a way we don't even have to take the centralized trusted manufacturer part of the story of TEEs for granted. So, to me, that's very clearly the long-term goal to technically strive towards. But exactly what you said, as just a market pragmatist now, this isn't what I'm trying to make happen. This is just the observation I think is inevitable. I'd push against it if I could, but people are going to take TEEs as a shortcut.

It's no matter how easy the ZK proofs get, I think it's going to be easier to make the equivalent or run it in a TEE and use the remote attestation as a substitute in lieu of a ZK proof. Mhm. It's just faster, cheaper, probably going to turn out easier to develop, and even if I would discourage it, um I think people are just going to take it as a development shortcut. And I think, you know, you you can see that in uh L2s even with optimism that might take, you know, um finishing the fault proofs as like a a deferred thing. I can imagine you design a multi-prover system. We've got ZK proofs and TEE, Yeah. but obviously you can ship the TEE one, you know, maybe faster, easier, and better performance. So, even when I

don't want that, I think that's likely the first appeal that people are going to see that's going to make this catch on. The other thing that's um you know, what I would say was easier. Really, this is about um the first thing that made it easy for me to swing into this, not just from a research perspective, but I think I started to pick up an arbitrage opportunity, I guess you would say. Maybe it was the only one I've picked up on, but I started to realize that all those fud posts, you know, I wasn't the only one who ate up that anti-DRM message about TEEs, and then also like the vulnerability sequence message of them as well.

But the knee-jerk reactions the fud people would say in reply comments, and you know, even companies working on TEEs just wouldn't talk about it. Turns out there were a lot of companies that have been working on these for a long time and just mostly being quiet cuz it's negative PR to even bring it up. Mhm. Um I started to realize that the responses weren't that defensible. They were leaving open too many easy, you know, answers to counter them. And a large part of this, we we talk about it in a moment, is like, you know, software mitigations that aren't um it's not entirely like you're just given this world of TEEs, and you know, you're completely at their whim. They're kind of, you know, crude technical tools like a ZK back end and it's up to, you know, us blockchain integrators, you know,

what to do with it and how to work around it. So, realizing that the anti-TE fud campaign had swung too far in the wrong direction or in the extreme direction, I think just left them open for clumsy psyops that I was in the right mood to bring. So, I also would would say, you know, I think there's the pragmatic Cypherpunk approach, which is how I would kind of term what you're saying, and then there's the pragmatic capitalist approach, which I will describe as the following, which is, you know, the sheer amount of investment, you know, everyone thinks about, hey, there's been all this investment ZK proving, people building hardware, whatever, is still probably on the order of 1% of the investment in TEs overall.

Woah. Outside of outside of crypto. You're including like the development costs of Intel and AMD. Yeah, the Nvidia Yeah, exactly. Intel's development costs plus Nvidia's plus Apple's acquisitions of all the hardware companies they bought for their TEs. And there's actually a much bigger driver of TE performance than anything crypto can really match, which is, you know, if I look at the fact that people want to do inference for AI in TEs because like they're afraid of people stealing their weights or like hacking, you know, the lot of espionage stuff has basically made some of the uh model operators start to do inference and then offer inference in in enclaves.

That is going to just incentivize much faster hardware development than anything else. I think just like simply by the pure sheer amount of dollars and people involved. And so that, you know, if you think about AI is riding the coattails of crypto in some ways, in that GPU performance got better because people started mining and so then we started making these like, you know, kind of low energy, high RAM throughput GPUs versus the pure graphics card GPUs. And so, yeah disclaimer disclosure whatever. I mean, I used to be a CUDA developer like in 2014 and 15 when it was deeply disgusting to use NVCC, but I did a lot of OpenCL when I was in graphics.

Yeah, yeah. I I did a lot of like protein folding stuff. And I unfortunately had the misfortune of dealing with the stuff back then. You're bringing up the you know the the momentum of this. I think that's totally important and it's almost like I mean I'm treating this like something I've discovered in a way, these TEs to use, maybe the way you know people pick up ZK proofs, but I mean these are products, right? And the you know they're they're made to be used this way. And in looking at it, it's it's so interesting the way that these are delivered. I haven't been able to wrap my mind full around all the you know strategic consequences of this, but like how's that for a distribution strategy? Like surprise all of your server chips just have TE in them. Like it's not a matter of are people going to

pay enough for the extra TE add-on. It's kind of just like your servers have this, they're already there, you know, when you choose to open the SDK and use it. And when you'll see it from that lens, it's almost just seems inevitable or or obvious in some way. Like this isn't going away, the fact that AMD and Intel have kind of converged on the same you know virtual machine approach to enclaves with TDX and SEV-SNP as their you know mode of working. It seems like this is just going to be an expected default that yeah, every cloud machine has this kind of capability. Anything running a modern you know compute card for doing inference or training just obviously is going to do its best to provide you this protected environment.

Who wouldn't want you know the confidential compute checkbox in those? So, I I can't really view outside of my kind of crypto viewpoint of this, but that's just the momentum of that you know far exceeds and as you guys were saying, that's far exceeding just the scope of what we want from them. And I think a a more a nice sort of charitable interpretation is you know, crypto helped GPUs get a lot cheaper and better 2012 to 2018. In that time that enabled people to do a lot of architectural experimentation in AI much more cheaply.

You know, everything from GANs to to transformers and all the other architectures in the middle. And now crypto gets to ride the coattails of AI putting TEs in everything. Cuz like I really do think it like that will drive TEs 100 times more than crypto probably. Wow. And and it'll be in like every device. It's a great point. Love it. I want to just ask about some of the what was happening in the industry over the last few years and TEs because you sort of hinted at this where like they started to pop up in things back in 2018. To me TEs were SGX and Intel was sort of synonymous.

But since then I feel like they've popped up in all these other places. Has that changed something as well? I I know it wasn't only Intel but at least like when I learned about it that was Intel SGX that was the TE standard. Yeah, I mean that this question is about like what are the companies using it or about what are the other TEs more? Yeah, just sort of what's the history of that kind of being added? I mean the ones that I was aware of the most I was aware of Oasis that was built you know by Dawn Song and co-authors out of that Aequitas paper. I started to follow Secret Network really well.

Maybe one of the things that was then most inspiring for me was just seeing what they did with private NFTs. I was pretty down on their you know privacy tokens especially coming from the Zcash world. I thought their claims were overstated and then had you know technical beef to pick on kind of nitpick decisions but you know, those are all fixable. Still it's like I kind of favor the ZK proofs for this long-term you know privacy. But there were a bunch of things that they've done that were really cool applications that to me is like yes, this is what I want to see innovators doing with um an extra tool in the toolbox. So, they have right-click resistant NFTs that have private metadata that only the owner of the NFT can see. So, right-clicking is, you know, a public chain NFTs problem on

a chain with um you know, sufficiently versatile confidential data, you can have this whole other world where there's actually like uh you know, property worth protecting that way. And the other one that I found so interesting was um well, they had a couple versions of uh a Uniswap clone. If you take a Uniswap and you just run the Uniswap clone in a confidential smart contract, it automatically is like a dark pool that one block at a time does a batch, but you don't see the individual trades and failed trades you don't see at all. Um and then the even more interesting one was their their compound clone, Sienna Lend. So, if you just take compound structure and run it in the confidential world, what you get is this snipe resistance. It's like you still have accounts accounts have different

portfolios of collateral. Depending on the price changes reported by an oracle, an account can go insolvent or not. And if it's over, you know, uh overexposed to one kind of collateral, then that's, you know, makes it risky to a change in that collateral. But here, you keep your portfolio positions hidden. The rule is that if they are in fact liquidatable, then it discloses the portfolio accounts cuz that's what liquidators need to see. But what you're immune to is sniping where someone can see, "Oh, you're overexposed to this one token and I can move the price on that one token and that would tip over your whole, you know, collateral health." So, that's what you get with like a one-line change to the, you know, compound code. I'm oversimplifying a little, but that's essentially, you know, what you get.

Just to go back to my initial question cuz I actually wasn't necessarily talking about companies that used TEEs, but rather hardware companies that had TEEs all of a sudden in them. As I understand it, in the last few years, TEEs have popped up in more places, right? Like there's more chips that are more products, more companies that are actually I I don't know if Apple always had TEEs, maybe it did back then, too. But like, I feel like yeah, it just sort of becomes more ubiquitous. Not all TEEs are the same, and I mean I would I would describe there's a handful of features that are most appealing to us as Web3 blockchain people trying to build a cool decentralized system using the TEEs, and then not all of them are are fit for it, and I think actually the some of the ones like in mobile phones,

I don't know to what degree they actually are suitable for what we would want to do with them. Mhm. What's great about SGX and the you know, the others in that class, I think it's true of the H100s and the AMD ones as well, is like they're user programmable, so there's no like OEM that has to insert those. A lot of TEEs are like for IoT devices, but then it's about and there's even remote attestation, but it's about from the admin controller to the devices out in the field in customers' houses, can you know that you're providing your cloud service to your own device cuz you built it from your own OEM, you know, assembler. And it's like you know, it's only two parties, like remote attestation, but the person who set the device out there is also the same one who's the relying party trying

to be convinced of it. And so, um I think that to some degree a lot of the most widely used TEEs are of that more constrained kind, like you may be able to use the TEE, but only with the Play Store or Apple stores' help in some way. And so, what's really interesting about this at the processor level is really once it's left the, you know, processor company, it's largely out of their control. There's absolutely a layer of opaqueness to this that makes it hard to say we fully trust that, you know, Intel can't touch it. There's like an obvious attack surface where if they wanted to have a back door, they could. If they wanted to sign a fake remote attestation certificate for a spy enclave that could join networks, but not actually protect anything, um they obviously could.

Uh but at least they do have the structure that by design the processors, you know, out of their direct control once it leaves the factory. I think it's actually really interesting what you have in this cloud environment where like an Azure SGX based server is somehow a little bit of separation of duties between Intel and Azure. Like Azure are operating it and what you hope is that if it turns out that there's, you know, an undervolting attack that someone with a physical, you know, attack lab, you know, could be squeezing some data out of it. Azure's promising not to do that. They have it in their ordinary racks. They're treating their customers with respect. They're at least claiming that. So it's kind of like the, you know, locks make good neighbors.

Even if it's not a perfect control, it does seem like a meaningful separation of duties. Like Intel would have to, you know, not follow their own design and Azure would have to help them make use of it to break something. And, you know, and then back to like if they would do this for bulk surveillance over privacy data, I maybe that's that's difficult, but then for an MEV application where like Flashbots, you know, says, "Well, we mainly just need this for like, you know, 20 seconds of, uh, you know, MEV time negotiating over this private data." Even if they could do this nation-state level attack or colluding attack, they're not going to burn revealing that capability and embarrassing themselves in front of their enterprise customers just to skim MEV for however long they can. So I mean

that that kind of answers the like why I'm, you know, I'm excited about Flashbots for that. Like it's a it's a narrower use case where like at least this should be able to do it. If it can't work for this use case, then the, you know, harder long-term privacy cases don't have a shot. So another thing I would add here, which I think is actually quite important and I think a thing people in crypto sometimes are cultured to not think about, is that there's a sort of natural time value of privacy. Like some applications actually do need persistent privacy or or at least non-manipulable in the sense of like a succinct proof tamper-proofness forever, right? So like a roll up needs to have all the proofs

that it's been valid to be right forever as it's still operating. On the other hand, something like DEX order flow in a block before the block is finalized is only a few minutes, you know, at most say it takes to finalize that you actually need the privacy for. Cuz after that, doesn't matter if anyone knows. It's not like they can front run it afterwards. It's like it's already confirmed, already executed. You can't really replay the transaction either, right? So, it's it's kind of it's it's done. And this notion of like ephemeral privacy or privacy that's like just-in-time around certain events is very important to have in a lot of applications. You don't actually need I don't need Face ID to give me privacy of

my picture forever. I actually need it for the small time it has to use to validate and then it deletes it. And so, I think there is a a very important piece of thinking about the cost of privacy versus the duration of privacy. Imagine you have like two axes and you're comparing like how much does it cost for this type of privacy versus how long do I need the privacy for? And there's some applications where you're willing to pay a very huge cost because you need a long time where either the privacy or succinctness properties need to be true. Roll-ups being one where I I basically would say time is infinite or very long, right?

But MEV on the other side of the the spectrum is like very short. And the question is what are the things that are in the middle? I think the things that are in the middle, the only things I've seen so far have really been like the AI type of stuff where it's like I don't want you to know my queries that I made for a while, but after many of them, you might be able to statistically aggregate something and say something about it. But immediately, I don't want you to know and for some amount of time I don't want you to know. And I I'm not sure what the crypto applications are, right? The finance stuff is very short duration privacy for the most part.

You know, you can argue maybe lending and a couple things do have a little longer duration, but even then it's it's quite unlikely. And then roll-ups are infinite duration. But like, what is the middle? And I think the thing about ZK VMs and TEEs is that they're both hoping to find something in that middle, but they might end up finding it from different directions, right? Like, TEEs might go from like the very low low duration to something in the middle, and ZK VMs will go from something very long duration to something in the middle, but they might never meet. They might just be in their own world. And that's why I think this idea that they're like competing and everyone fighting each other on Twitter is like Anyway, sorry. That's my hobbyhorse on on the like No, that's interesting.

You've identified like uh that's a that's a hypothesis in the middle. Like um they either overlap, there's some applications that are juicy and you can afford to do ZK for them. Um And a TEE is appropriate as well for the short-termness of it. But maybe it's the case they don't overlap and there's juicy applications that are too sensitive to trust the TEEs on their own, but they're also too performance or something to you know, for for the ZK to be a good fit for it. And maybe that's where you're saying the AI applications do fit in. Yeah, I don't have a good answer. That's a nice question.

I feel like we should jump very much now into the MEV T. I know we've touched on it, but the work that you've been doing, I think it would be great for us to understand exactly what your involvement has been and kind of your current work around the topic. I actually asked you before this episode like, are you part of Flashbots? Like I don't I don't I see you at talks. Sometimes your name is like there's Flashbots under your name, so I'm like confused. So yeah, maybe you can just share. Yeah, I'm a mate at Flashbots and I've been helping with a couple of other projects on the side as well. Cycles especially and still have some university things that I'm doing. Yeah, and I kind of hop around and hop on lots of projects generally anyway, but the role that I've been playing I think it's been fairly um

consistent for a while that I can describe it, you know, well enough, but um largely my interest has been on, you know, not only promoting the use of TEEs, like helping people counter, you know, what I think are the wrong arguments against it and maybe accept that using it's important, but I I'm really interested in bringing more clarity on how to use it and especially to identify like what is the tech debt or what are the pitfalls that software developers need to know. I generally take this attitude that's um you know, or like we can do a lot. We're powerful, you know, infra engineers the web 3 ecosystem broadly. We don't let the complexity of zero knowledge proofs, you know, stop us from figuring out how to use them very well. So, there's a lot of um pitfalls in working with TEEs. I you have to prevent side channels. Those

are very nuanced cuz you have to pick like what threat model you want and then also choose which mitigations you apply for those. You have to do things like preventing replay attacks, which generally involves making use of the blockchain. Like it's really interesting how blockchains and TEEs are complementary. I mean maybe in the same way our conversation was just about how ZK and TEEs are complementary. It's definitely true of consensus protocols and blockchains and TEEs as well. You can't have one without the other and you know, one of the most important design patterns is to have a light client for a blockchain network inside an enclave program. That's how you have the enclave, the TEE locked into the blockchain and only doing what the blockchain says. It's like you use the blockchain for a control plane and a TEE

as the, you know, coprocessor to do the work of that. So, the main thing I've contributed to at Flashbots is the Serai project, which is like a tutorial mode. It's in a way just going back to the Ekiden paper and speed running it. That's how we framed it cuz um it's similar in what it does to say Fela and Oasis and Secret Network. Um but it's meant to do so in an absolute minimal amount of code. I think our core thing of it was like a 2,000 lines on top of you know, all the packages that we import to use it. So, it's just basically meant to help get everyone on the same page on like what are the pitfalls that can go wrong, what do you need to do to connect these, you know, properly, how to think about what the security goals are. And it goes back to

that same, you know, motivating example from the Hawk paper of it it's a sealed bid auction where you want to provide failed bid privacy even for the losing bid, so you can't just do commit and reveal. And um it's Hawk except the manager only runs in a TEE and it uses the remote attestation instead of where Hawk used a ZK proof. You sort of already talked a little bit about something from like Web 2, the TLS notary. How does this like I realize this might be not exactly what you're working on right now, but I didn't quite understand how TEEs factor into that. Like I know some ZK focused projects that are playing with the TLS notary concept of bringing Web 2, like web pages, making proofs about the web

on a blockchain, sort of almost becoming a bit of an oracle for like the real world or something. Yeah, how do TEEs get used in this way? I mean if you don't mind, can you give me like your one-sentence description of how it works in the ZK version of that? Well, I I would probably not be the perfect person to explain it, but as far as I understand, you create a ZKP of some state of a website. So, if you were trying to prove like I don't know that your bank statement says something on a website that you'd be able to create a a proof that you'd write on chain. I'm probably totally butchering it and really one of these teams should say it better. I mean, another one would be and this one I understand a little bit better would be like ZK email, which is

where you're actually taking the format of an email. So, say in an email your I mean, the best example here is like Venmo sends you your balance or something that has just been transferred to you. You could create a proof about that amount, about that email template that you could then write on chain. And you have a proof about a signature from it essentially that's giving you this authenticity of it. Yeah, you create a signature out of it almost. Like it's just an email. It's like just a plain text email. I mean the only nitpicker or um I think the biggest just challenge of why, you know, it's not trivial to do this with TLS, you can't just like make a zero-knowledge proof about what you saw is that there's this deniability issue with TLS where like it's a Diffie-Hellman key. So like

you one if you're at one of the parties in the session, you can pretend you're making messages on behalf of the other party as a session. So just because I make a proof of what I saw on a TLS session, I could also make a fake proof of what I saw because I have the same key that the server had to make that. So you just have to work around this and this is why these systems are a little more complex. There's either like a relay in between like a a proxy, you know, in the middle or like the DECO project I guess was another Ari Juels um one that I know a bit that's like a secret shared version of that. So that that's the technical problem that you have to get around. You can get around, you know, one of these handful of ways

and um having a proxy in the middle reading the the TLS session that it has the little key and it proves that it's not doing that and you get to still see the output of the TLS session, but you don't have that key that would make it, you know, possible to spoof. That's how you go about using TE as a substitute for that. So it can be used as a substitute for it, but do the ZK version, you know, if you can. But to me what's super exciting about this is that um that idea of having right access, right? So a ZK-TLS and and all of those are good for login and for read access to an account. Um but being able to actually encumber the right access of either the it's called an encumbrance and this is also a later Ari Juels paper with

Mahimna other of his students and James Austins worked on follow-up things of this. Like Delegaty is always about putting a session into a TEE, and now you can sell off this access to it. You can also do encumbrance of the root account. It's like you go through the forgot password transfer account flow, but now you recover your password into a TEE. So, now you don't have the password to the account, only the TEE has a password to it. And it comes with whatever are its constraints on, you know, under what conditions it's allowed to write or um and then it can still be following um, you know, a a thing from the blockchain to do it. We made this demo now. I say we, but this is especially Shinu Wan from Flashbots, and um uh Ryan MacArthur, who's an Ethereum

Foundation grantee. They made this Twitter encumbrance app or Twitter delegation app. It's better precisely called um teleport.best. And it basically is you put a write session authorized into the TEE, but what the TEE enforces more narrow than what Twitter off says is that you only get to post once. So, it's like you make a one-time use link that lets anyone you give the link to post from your Twitter account, but just once. And I think you attach an LLM filter to it as well as like a little sanitizer. So, to the Twitter off, all Twitter off has is read access or read write access. Yeah. But like read's not enough, and read write indefinitely is way too strong.

much yeah. Like read write anything, delete posts, unfollow people, change your profile photo. So, it's the TEE that's saying you're you're you're giving it as Twitter as far as Twitter's concerned, you're oversharing, but it is enforcing that it's only going to stick to the policy of, you know, one-time use per policy only. I see what you're saying though. It's true that in all of the ZK-TLS stuff that I've seen, it's read. You it's read, and then you do something with it on chain. But what you're saying is you're actually well, you're delegating the access to the TEE, and then it can do stuff with limitations that's programmable. Exactly.

Yeah, beyond the application itself. That's really interesting. And and you can always sort of web3 your way around the first problem through over collateralization, right? Like if all you have is this read oracle, um but you want to say like I promise I will, you know, send whatever message through my email that the blockchain contract tells me to do. You could always set up slashing, like I have to show my ZK TLS proof to the contract that I did send the email that I said I would, and if I don't, it slashes me. Um the only drawback there is just the complexity and cost of, you know, using over collateralization that way. Um so yeah, this is like an alternative to that. It's like a proactive guarantee over right access. I hadn't actually thought about that at all. So this is a new concept for me. You know, we we

actually have talked a little bit about, I think when you think about MEV from this kind of lens of, hey, you only need privacy in a short-term sense. You know, other parts of DeFi and kind of transactions on chain do need longer-term privacy. And I went to this talk, which I admittedly really didn't understand, uh because I do find these peer-to-peer credit networks very hard to understand who would use, personally. Uh but like I I think I heard this concept of liquefaction, so maybe it would be great to kind of understand what that is and how to think about that. Uh let me explain liquefaction in terms of uh how it relates to this delegation and encumbrance story. First of all, there's reasons you would want

to discourage this delegation. It's a little bit of a controversial topic, uh you know, even what to do because it somehow is, you know, changing the rules of authorization, you know, beyond what the original account provider is already providing. There's many cases where you would like not to support this kind of um fractionalizing. Like vote buying is a place where you don't want a secondary market popping up on, you know, into your your uh vote buying ability. So liquefaction is the name for taking, like, you know, the soulbound token approach that's just based on EO A accounts. I'm making this distinction cuz Soulbound also has like the social recovery notion and I kind of mean um I mean to invoke the simpler version that's just like you don't want a smart contract to hold this airdrop token. So,

you only give airdrops to, you know, raw addresses where you think, well, cuz it's an externally owned account, it's a real person on the other end of it. Liquefaction is what you get when you ignore that and you actually have your airdrop key is itself inside of a TEE, which means that you can, you know, later put an auction on top of it or fractional. I think this was in the case of if you have like a CryptoKitties, some NFT where it's supposed to be one person owns it, no fractionalizing. You can fractionalize it out from under them by doing this TEE-based um encumbrance trick. And that's the the kind of key notion of that uh liquefaction paper. Do you need that though? You would need this if it was Soulbound, if it wasn't transferable, I guess, or if it couldn't be incorporated into a smart contract

itself somehow. Yeah, exactly. The kind of fits into a cat mouse game in a way of you know, trying to thwart or enable from outside this kind of secondary market ability or redelegation ability. Thanks for describing that. I think, you know, I I think I'd heard that during kind of a talk about Cycles or I heard the term for the first time. And I think it maybe would be great to to talk a little bit about Cycles, especially since it's, you know, a very different TEE application and I think uh one that perhaps also people in ZK land would would find interesting cuz like, you know, there's things like ZK-P2P, but this is sort of a different

different version of commerce between people. Yeah, so the Cycles project's been something I've been helping out with the TEE stuff for um around a year now. This is a a project led by Ethan Buckman from, you know, Cosmos and Informal Systems, of course. And it's it's almost an accounting or a real-world economics, you know, thing. It's like backed by blockchain and TEE and this cryptography approach, but the intended use of it is not really within Web3. It's really for real world businesses. And the idea is something like he does a much better job of explaining the, you know, overall structure of this.

But, um I like this idea of a credit network where, you know, we have a credit and debt relationships that are expressed in some way and that we might do something peer-to-peer involving these. The most interesting credit graph of this kind is like the trade credit in the form of all of the invoices between just business to businesses, um you know, all of the account invoices that are due, you know, somewhere between now and the end of the month. These are all essentially uncollateralized credit between the companies who are, you know, the accounts receivable and accounts payable for that. And the key idea is that if you just imagine this graph, it's like a directed graph.

People have to load into the cash system there, you know, actually do the paying their invoices. They have to load cash into the system. That's expensive and has some, you know, capital costs of working with cash to do that. If you had this global eye view of everyone's account information, you would identify these opportunities for cyclic flow, which is, you know, IOU, you owe me. She is, you know, we have third parties in between us. Um if we just all agree to, you know, deduct from our contracts to each other this amount, we never have to touch the banking system, yet we will have successfully cleared our debt and don't have to, you know, pay the cost of it's that much capital of cash that would is displaced cuz it would otherwise have to be circulating. Now, it doesn't have to circulate, we just,

you know, atomically clear that. But, this is sensitive business information, so even when it's in, you know, accounting software, QuickBooks or whatever, they're not trying to, you know, merge this and have a global eye view of everyone's competitive business information that they This isn't a world that is just by default everything public on the blockchain, right? They're actually safeguarded by default. And so, the plan is to do a combination of ZK proofs for integrity guarantees and the trusted hardware for the computing this graph flow-finding algorithm. Like, what's the most amount that we can clear this way?

Which requires a graph algorithm over all of the sensitive data, but no one person has all of that sensitive data. So, it's just like uh to me, it fits in. It's just another instance of this. Instead of computing the auction on top of the batch of sensitive bids contributed by every user, here it's you compute the clearing solution by computing on the encrypted invoices submitted by every user. Um and then the significance of the TE is cuz this is in more of a latency's okay. This is like a batch operation. Actually, the security of we don't just want to rely on the TE to prove no one's going to be hold, you know, short, told not to pay, but then they're, you know, it's a big problem that they didn't. So, um we would use a zero-knowledge proof for the integrity guarantees that everything's atomic. You

you know, you net out to zero or better. Um while using the trusted hardware, you know, as a backup integrity. So, multi-prover, but then that's also providing the privacy over all that data. Interesting. So, here the TE really does provide privacy. So, that's the thing that's obfuscating the actual information. ZK here is only being used for just verifying the correctness. Yeah, exactly. Verifying the correctness, yeah. That's cool. Is this a business solution then? Is this really for businesses or is this for individuals who are like exchanging funds among friends? Like, what kind of use case?

So, interesting. I mean, I I came into this with a bunch of um excitement around the P2P angle. Like, I want to see the output of this be that, you know, we're so good at now managing debt once we are enlightened by this concept and toolbox that we actually now want to form, you know, trust relationships or credit relationships with, you know, friend and family. And in some way, even use the zero-knowledge and privacy as like a bankruptcy guarantee, like to prevent um you know, squabbles from exceeding the value of them in the first place. But what I've been convinced is that maybe that that's still in scope for like a longer term thing that I'm excited about, but the the business is, you know, there's no hypothetical about it. Businesses like can benefit for this from already. And these this latent graph of all of these obligations is

already existent. It's just a matter of, you know, having a reason to import it and you know, mechanism to do so and do something useful with it. Where does Cycles live? Like where is it in an ecosystem? Does it touch the blockchain actually cuz like what you just described is like TEs, but yeah. Well, this comes from the Cosmos world. I would say it fits into the Cosmos ecosystem especially. You could imagine there's a Cycles chain that you know, is an app chain to do that. One element of this, you know, TE sidecar TE coprocessor approach is you can kind of attach it anywhere. So I like the idea that it could launch on a on an existing public chain. It's the TE bits that would be new and added, but it could use Neutron or one of these Cosmos ones. Think the but the way things go in

Cosmos, it's most, you know, plausible that there'd simply be Cycles chain. Okay. And that makes sense given that Ethan's involved in it. So Cool. So Andrew, thanks so much for coming on the show, sharing with us your history working on consensus and then ZK a little bit and TEs and kind of at first maybe not being into them and then you why you got really into them. I think that's really helpful for us all to understand. I think our community especially is pretty still anti-TEs. And so I think it's it's good to hear your perspective on it. Also, thanks for sharing sort of these newer ways that we're seeing TEs being experimented with. Yeah, thanks so much. Thank you.

This has been a blast of a conversation. Glad we could do it. Nice. Thanks everyone. Cool. I want to say thank you to the podcast team, Rachel, Henrik, Tonya and Jonas. And to our listeners, thanks for listening. Mhm.