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 1 blockchain that achieves the programmability of Ethereum, the privacy of Zcash, and the scalability of a rollup. 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 1 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 discover 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 podcasts' 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. So, Andrew, you are one of those guests that I have 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. I was like, hey, would you be up for coming on the show? And you said yes. And I'm so glad 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 this 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, we did this textbook together on an early systemization of knowledge. Right before that, I had been kind of pivoting my original grad school career in VR and graphics and 3D stuff, but just got totally down the rabbit hole of Bitcoin and especially reading 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 academics who 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 this survey paper and it's on Bitcoin, cryptocurrencies, anyone interested in helping, 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 bridging the gap of academia in 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 following art. We've already gamed through the consequences of these tech choices.

The Greg Maxwell invented everything before you did, argument.

Yeah, that's a Matt Green tweet, right? Every good idea under the sun has 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 bring us all into alignment there and had a bunch of, I think, events we hosted with cryptocurrency devs at the time, and --

Did it work?

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 there's, I think, now a very high bandwidth bridge between academia and the Web3 industry.

So you were working before this on media video stuff like video encoding? What did you just say?

Augmented reality. I had a really cool project as my master's project on the Microsoft, Microsoft Kinect, you know, the 3D scanner. So we would do real time scanning of DUPLO blocks as you would build them, and then instructions for how to follow along would 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?

It 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's ever on my mind about that is just I really changed my behavior, personality almost entirely before there. I was a terrible grad student the first time around. I only liked 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 did a much better intentional job of socializing the research and trying to do that. So that ended up a lot more fun the second time around. But it's like, I got a second go at grad school.

Nice. But 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 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 another career path I was trying to pick for myself. So it's 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 bringing it to the mainstream or 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 a new look on BFT protocols and that would be interesting enough for one career start.

Cool. How old were you when you got into this?

My first experience of your work from that time-ish was the NIPoPoWs.

NIPoPoWs.

NIPoPoWs. 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 anthropologists, or was your goal of that era, or was your initial goal to find something new? Because I kind of feel like I've seen both of your writing styles of what I guess I'd call Internet anthropologists 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 viewed it as a balance. I viewed that 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 posts about the historical context and also these new things. Maybe I viewed him as a role model like that. Definitely part of it, but, oh, I wanted to -- I wanted to break a new thing somehow. I think I ended up falling into 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 done great at scavenging old bits or overlooked bits and finding something useful to attach them then. So I think that's where I get my -- I feel I'm being adequately innovative and enjoy it.

Yeah, I like the anthropology and explaining the context and ecosystem view of it. I think something along those lines also is I've gotten to see now several times, a new academic field, get the Bitcoin bug and dive in and be absorbed by this. Like the financial cryptography crowd were some of the first, and so computer security and that kind of subfield in computer security, those were the first to take it over. And I think then the cryptography world with zero-knowledge proofs came next. And it wasn't until later that the formal methods community had their turn with the smart contracts and then proper distributed systems came over. There's probably some other subfields that have gone along those, but that's always been fun to see, and bringing the anthropology message a little bit is always helpful in doing those, because 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's clearly been appealing to all these different fields.

I'm curious because at some point you also moved into ZK. And I don't know what happened in between, sort of that work of, at first describing blockchains and doing these polls and surveys, as you called it, all the way to 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 found it. I mean, right when I got to University of Maryland, I think I got to meet Matt Green and Ian and Christina, who had been doing the Zcash paper, 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 the big deal. This was like the Pinocchio or GGPR paper, right, where out then. So all the cryptographers there were excited about this, and the Zerocash paper had already explained how to do this.

And I think the main project that I worked there, that to me, really set myself on the direction that, as we'll talk about, has been a fairly continuous direction since then, was this Hawk paper. So it's saying Zerocash is already showing how to use zero-knowledge proofs for transfers, which is what Bitcoin is capable of, but we can think about all of these smart contract applications, whether it's from early Bitcoin script at the time, or Ethereum had been 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 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 privacy auction and other applications on the way?

That is so early.

2016 or something?

Yeah. And at this point, so Ethereum is live, I think, but in its very early stages. 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 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 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 frontend that was available at the time. And 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 even a little bit before Groth-16 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 start to work with ZK?

Yeah, exactly. That was the first time using ZK and doing anything privacy-centric that way, or confidential the other way.

NIPoPoWs.

NIPoPoWs, sorry. NIPoPoWs, by the way, it stands for Non-Interactive Proofs of Proof-of-Work. Andrew can correct me, but I view it as personally just like a way of doing a SNARK of proof-of-work without -- it's a way of just proving that a proof-of-work -- a set of proof-of-work existed without having to do the calculation to verify.

Yeah, that's exactly right. I had a bunch of unhinged and didn't quite solve the problem posts on Bitcoin Talk about this. Yeah, it's just so you describe 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 a smart contract based light client. So that was the intent of it at a time. I guess that's pretty interesting. I mean, I think that I have been detached mostly from the scaling efforts. So I helped later with this scaling Bitcoin position paper that was like the merger of a bunch of already separate measurement studies that Gün Sirer and Christian Decker, the Swiss team were working on. I guess I had been kind of caught up in the drama of the Bitcoin scaling debates, but not really picked a side or dug into it, other than wanting to 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, very abstract, very academic goal. Like that's the target. Let's go make an algorithm that beats that goal. I don't know that I really conceived of that as helping the scalability effort that way so much. To me, the most salient tradeoff was much more privacy versus expressiveness.

That's awesome. Yeah. So to me it's the expressivity versus privacy tradeoff 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 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 smart contracts go. I think I had wanted to do something like that prior to hearing about Ethereum, because it was in the early Satoshi, the deleted pages of code from Satoshi's Bitcoin was a poker and a marketplace, and all of these extra features that were carved out because that didn't fit into the Bitcoin that worked and was launchable.

But it was always part of the zeitgeist, part of the grander 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 accelerate what the smart contract developers, permissionless innovators have in their toolbox to work with. And 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. It's still just operating on transparent data. So adding confidential computing of some kind to it was what I cared about the most.

What other involvement did you have at the time in the ZK world, though, because 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 thing that hit the real world per se. So, I mean, I helped with early Zash governance and participating in maybe 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 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 of simpler.

You were not the one who went into the woods, though, were you?

No, I wasn't in the woods. Nope.

I feel like one of the participants drove to Canada into the woods.

You're thinking of Peter Todd driving his desert bus with his thing and using satellite Internet to 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 just sort of looking more on the spirit of the project, I guess.

Yeah, I'd say that was right. And I've been picking technical battles for sure. Just they're more in the lines of the smart contract layer, which I guess I would even say I hope someday ends up being available for Zcash to use. But it makes sense that Zcash is more on the conservative, only add safe features, put a very high -- allocate all the points towards safety and reliability of doing those ZK proofs in the smaller scope the right way. Yeah. And as we get into TEEs and these extra things that take other trust assumptions, I like the idea of not enshrining extra trust assumptions into a protocol, but I love the idea of making them available as 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. I know a lot of this episode is going to be about that work, the sort of more recent stuff, but did you have an opinion at the time?

Yeah, it's different now. I don't have a super sharp answer because I would say that largely after I didn't keep going with consensus in depth after HoneyBadger-BFT. 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 HoneyBadger-BFT kind of kicked off this resurgence of asynchronous BFT protocols, which is the most interesting setting for consensus. And the idea that you could have pipelining for asynchronous protocols is quite exciting. It's so interesting that, I mean, consensus and distributed systems looked like a solved field. They started to have these papers. I wasn't deep in this community, but from what I could see from reading the conference forwards or keynotes, 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. What's left to do? 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, so you need something else, like a resource limit to open up proof-of-work or incentive stakes. And that just changes this whole perspective, opens up a whole new room for that community to grow into.

And what I would characterize as happening now in consensus is 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 inappropriately low. Maybe there's a setting where they have a double spend or are kicked off the network, fail to get liveness, but everyone else keeps going. So this is either subjectivity or suddenly not forgetting the right phrase, like heterogeneous trust assumptions or flexible BFTs, maybe, you know, the name of that.

So in other words, 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 can just have fine nuanced multi-layer assumptions and that opens up a lot of possibility. I think you see this in the high performance Aptos and Sui and Mysten kind of things, where you've got a very fast pipeline, fast path and a reasonable secondary path and then some worst case. And that's kind of like your switch from synchronous to asynchronous operation, and I think that's 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, I think maybe it was a little before its time, but something like Thunder was all about this fast and slow path separation, which is common in most database design or really any non-crypto thing. 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 there was a real improvement that occurred in a lot of papers. Like in HotStuff, I shrunk the number of rounds decidedly, or I shrunk the bandwidth required per round. In Tendermint, I have kind of very clean formulation of pBFT that's almost cleaner than the original formulation in some ways.

But then I, like, read these papers 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 deckchairs on the Titanic. Like it's like the thing is going to crash anyway, and 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 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 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, yeah, I don't have the best answers here. I guess that is the natural flow of things once the big 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 pejoratively incremental research papers that optimize something, but it's in a tradeoff with others. So not a slam dunk, or it's small improvements, but not a -- or it's improving the less important thing. Like it's making your non-fast path faster. So how do you sell the backup case performance? It's too hard to sell. So I would say maybe, yeah, you could be right, but if so, that's only -- if any field will come up with something different to do I would bet on consensus doing so.

Over TEE or ZK, where 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.

That's got to have been Micarag's name for it. I remember that.

It was.

But what's also so notable to me about this is that to me, is the success story of that academic to industry bridge, because that stands out as what are traditionally -- like those are huge technical contributions that get cited and are regarded as 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 coolest story for me there.

I think I remember that because I just remembered all the Chainlink Marines shilling it for a while.

Yeah, that's right. So I was aware that -- those, to me, are two alternatives of ways of getting around the thing that the zero-knowledge proofs alone have this limit. So with the zero-knowledge proofs, there's a witness. A 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 -- Zcash works like this and the commit and reveal kind of partial solution to an auction with Hawk works like that.

But if you really want to compute on private data, you don't really have alternatives. So there's either multiparty 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 three years or so as the way around that. And I kind of, 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 your TLS connection when you log into some website. And it can make then 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 TLSNotary, these kind of things. But it can make, for example, 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 Mikerah, right?

Yeah, that's right. Ratel, an MPC as a side chain, which we worked on for nearly three years. That was a tough grind of a paper, in part because the MPC was difficult to work with. And I've compressed this to be able to talk more about 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 datasets, databases will need oblivious RAM inside the MPC. So it's going to 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 ask them whether they've done that and get anything 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 biggest brick wall. And that was when I started to accept them. You know, that TEEs are necessary and even if the MPC works, you'd still want TEEs too. And that's kind of my modern framing of it.

So the MPC though, you just at some point realize 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 a 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's a perfect question. I think that's maybe the most important question for these, because, yeah, if it were just a matter of work and make performance, I would probably prefer to grind it out and keep chugging away at that. No, in a world where cryptography, even the very fancy cryptography, let alone FHE, 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 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 a -- you fundamentally need some irreversible right, and there's just no cryptography protocol that gives you an irreversible right 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 guess like, yeah, I think you're always a couple years ahead of me historically, except in DeFi. And I would say that 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 zkVMs, 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 tradeoff with the hardware. Because if I think about people who are using -- like 90% of people who are using mobile wallets arguably are making the same tradeoff hardware-wise. They're using Face ID and whatever attestation that is in a TEE in their phone or in their computer. I feel like the new users of crypto, the difference between TEE and not TEE is zero to them to some extent.

And so 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 TEEs, kind of doing this credential matching, doing kind of the TLS type of stuff, it just feels like it's probably going to be more impactful to the end user if you're willing to make those assumptions. I think obviously rollups are a place where 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 feel like there is this whole world of things where I think it's interesting that people from MEV land came into TEE as kind of out of necessity being the mother of all innovation versus sort of like endogenously thinking of it as a solution.

So I'm just kind of curious now that you've had a few years of conversion into the gospel of 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 close enough. But what are kind of the things you think that are easier than what you expected? What are things are harder? Sort of what do you view the tradeoffs as? Because you've kind of written code in all of these different systems, so you have sort of a high level overview.

Yeah. I mean, maybe just building on what you were just saying, I have two visions in mind. One is what I think is going to happen right now, and the other is what I think should happen, or is the architectural ideal to build towards. To me, the ideal to build towards is in the future we will have multiparty computation nodes doing the decryption step for FHE, and these nodes will to prevent that collusion risk, 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 their 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 verify, don't trust TEE alternative that come from -- 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. No matter how easy the ZK proofs get, I think it's going to be easier to make the equivalent, run it in a TEE, and use the remote attestation as a substitute in lieu of a ZK proof. It's just faster, cheaper, probably going to turn out easier to develop. And even if I would discourage it, I think people are just going to take it as a development shortcut. And I think you can see that in L2s. Even with Optimism, that might take finishing the fault proofs as a deferred thing. I can imagine you design a multi-prover system, we've got ZK proofs and TEE, but obviously you can ship the TEE one 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 what I would say was easier, really this is about 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 this is the only one I've picked up on, but I started to realize that all those FUD posts, I wasn't the only one who ate up that anti-DRM message about TEEs, and then also the vulnerability sequence message of them as well. But the knee-jerk reactions, the FUD people would say in reply comments, even companies working on TEEs just wouldn't talk about it. Turns out there are a lot of companies that have been working on these for a long time, and just mostly being quiet because it's negative PR to even bring it up. I started to realize that the responses weren't that defensible. They were leaving open too many easy answers to counter them. And a large part of this, maybe we'll talk about it in a moment, is software mitigations that aren't -- it's not entirely, you're just given this world of TEEs and you're completely at their whim. They're kind of crude technical tools, like a ZK backend, and it's up to us blockchain integrators, you know what to do with it and how to work around it. So realizing that the anti-TEE 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 say, 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 the sheer amount of investment -- everyone thinks about, hey, there's been all this investment ZK proving, people building hardware or whatever, is still probably on the order of 1% of the investment in TEEs overall outside of crypto.

You're including the development costs of Intel and AMD?

I did a lot of OpenCL when I was in graphics.

Yeah, yeah. I did a lot of protein folding stuff, and I unfortunately had the misfortune of dealing with the stuff back then.

You're bringing up 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 TEEs to use, maybe the way people pick up ZK proofs, but I mean, these are products and they're made to be used this way. And looking at it, it's so interesting the way that these are delivered. I haven't been able to wrap my mind full around all the strategic consequences of this. But how's that for a distribution strategy? Like, surprise, all of your server chips just have TEE in them. And like it's not a matter of are people going to pay enough for the extra TEE add-on. It's just like your servers have this, they're already there when you choose to open the SDK and use it. And when you see it from that lens, it almost just seems inevitable or obvious in some way like this isn't going away. The fact that AMD and Intel have kind of converged on the same virtual machine approach to enclaves with TDX and SEV-SNP as their 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 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 the confidential compute checkbox in those? So I can't really view outside of my kind of crypto viewpoint of this, but that's just the momentum of that far exceeds. I see what you were saying, that's far exceeding just the scope of what we want from them.

It's a great point. Love it.

Yeah. I mean, this question is about what are the companies using it, or about what are the other TEEs 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 by Dawn Song and co-authors out of that Ekiden 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 privacy tokens, especially coming from the Zcash world. I thought their claims were overstated and then had technical beef to pick on kind of nitpick decisions, but those are all fixable. Still, it's like I kind of favor the ZK proofs for this long term 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 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 a public chain NFTs problem. On a chain with sufficiently versatile confidential data, you can have this whole other world where there's actually property worth protecting that way. And the other one that I found so interesting was they had a couple versions of a Uniswap clone. If you take a Uniswap and you just run the Uniswap clone in a confidential smart contracts, 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.

And then the even more interesting one was their Compound clone, SiennaLend. 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 overexposed to one kind of collateral, then that 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, because 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 collateral health. So that's what you get with a one line change to the Compound code. I'm oversimplifying a little, but that's essentially what you get.

Just to go back to my initial question, because 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 -- or more products, more companies that are actually -- I don't know if Apple always had TEEs. Maybe it did back then too, but I feel like, yeah, it just sort of becomes more ubiquitous.

Not all TEEs are the same. And I mean, 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 fit for it. And I think actually 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. What's great about SGX and the others in that class, I think it's true of the H100s and the AMD ones as well, is they're user programmable, so there's no OEM that has to insert those. A lot of TEEs are 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 and customer's houses, can you know that you're providing your cloud service to your own device because you built it from your own OEM assembler and it's like 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 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 has left the 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 Intel can't touch it. There's an obvious attack surface where if they wanted to have a backdoor, 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, they obviously could. But at least they do have the structure that by design the processor is 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 an Azure SGX-based server is somehow a little bit of separation of duties between Intel and Azure. Azure are operating it, and what you hope is that if it turns out that there's an undervolting attack, that someone with a physical attack lab could be squeezing some data out of it. Azure is 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 locks make good neighbors. Even if it's not a perfect control, it does seem like a meaningful separation of duties. Intel would have to not follow their own design, and Azure would have to help them make use of it to break something. And then back to if they would do this for bulk surveillance over privacy data, maybe that's difficult. But then for an MEV application where Flashbots says, well, we mainly just need this for 20 seconds of 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 kind of answers the like why I'm excited about Flashbots for that. Like it's a narrower use case, where at least this should be able to do it. If it can't work for this use case, then the 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 cryptos 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 at least non manipulable in the sense of like a succinct proof tamper proofness forever, right? So a rollup 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 at most, say it takes to finalize that you actually need the privacy for. Because after that, it 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. It's kind of, it's done. And this notion of ephemeral privacy, or privacy that's 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 only need it for the small time it has to use to validate and then it deletes it. And so, I think there is a very important piece of thinking about the cost of privacy versus the duration of privacy. Imagine you have two axes, and you're comparing 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. Rollups being one where I basically would say time is infinite or very long.

But MEV on the other hand of the spectrum is 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 am not sure what the crypto applications are. Right? The finance stuff is very short duration privacy for the most part. You can argue maybe lending and a couple of things do have a little longer duration, but even then it's quite unlikely. And then rollups are infinite duration. But what is the middle? And I think the thing about zkVMs and TEEs is they're both hoping to find something in that middle, but they might end up finding it from different directions. TEEs might go from the very low duration to something in the middle, and zkVMs 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 competing and everyone fighting each other on Twitter is like -- anyway, sorry, that's my hobby horse on the like --

No, that's interesting. And you've identified, like that's a -- it's a hypothesis in the middle. Like they either overlap, there's some applications that are juicy and you can afford to do ZK for them, 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 for the ZK to be a good fit for it. Maybe that's where you're saying the AI applications do fit in. Yeah. I don't have a good answer, but that's a nice question.

I feel like we should jump very much now into the MEV-TEE. 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? I see you at talks, sometimes your name is like, there's Flashbots under your name. So I'm 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, has been fairly consistent for a while, that I can describe it well enough. But largely my interest has been on not only promoting the use of TEEs, like helping people counter what I think are the wrong arguments against it, and maybe accept that using it is important. But 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 like we can do a lot. We're a powerful infra engineers, the Web3 ecosystem broadly. We don't let the complexity of zero-knowledge proofs stop us from figuring out how to use them very well.

So there's a lot of pitfalls in working with TEEs. You have to prevent side channels. Those are very nuanced because you have to pick 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. 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 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 coprocessor to do the work of that. So the main thing I've contributed to at Flashbots is the Sura project, which is like a tutorial mode. It's in a way, just going back to the Ekiden paper and speed-running it.

You sort of already talked a little bit about something from Web2, the TLSNnotary. How does this -- I realize it might be not exactly what you're working on right now, but I didn't quite understand how TEEs factor into that. I know some ZK-focused projects that are playing with the TLSNotary concept of bringing Web2, like web pages, making proofs about the web on a blockchain, sort of almost becoming a bit of an oracle for the real world or something. Yeah, how did TEEs get used in this way?

If you don't mind, can you give me your one sentence description of how it works in the ZK version of that?

Well, 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 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, 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 just a plain text email.

I mean the only nitpick, or I think the biggest challenge of why it's not trivial to do this with TLS. You can't just make a zero-knowledge proof about what you saw is that there's this deniability issue with TLS where it's a Diffie–Hellman key. So if you're 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 a relay in between, like a proxy in the middle, or the DECO project I guess was another Ari Juels, one that I know a bit that's a secret shared version of that.

So that's the technical problem that you have to get around. You can get around one of these handful of ways and having a proxy in the middle reading 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 possible to spoof. That's how you go about using TEE as a substitute for that. So it can be used as a substitute for it, but do the ZK version if you can. But to me what's super exciting about this is that idea of having write access. So ZK TLS and all of those are good for login and for read access to an account, but being able to actually encumber the write access of either the -- it's called encumbrance. And this is also a later Ari Juels' paper with Mahimna, other of his students and James Austin's worked on follow up things of this. Like DelegaTEE 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 under what conditions it's allowed to write, and then it can still be following a thing from the blockchain to do it. We made this demo now -- I say we, but this is especially Xinyuan from Flashbots, and Ryan MacArthur, who's an Ethereum Foundation grantee, they made this Twitter encumbrance app, or Twitter delegation app is better, precisely called 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 OAuth 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 a little sanitizer. So to the Twitter OAuth, all Twitter OAuth has is read access or read-write access, but like, read's not enough, and read-write indefinitely is way too strong.

It's too much. Yeah.

Read-write anything, delete posts, unfollow people, change your profile photo. So it's the TEE that's saying you're giving it as Twitter -- as far as Twitter is concerned, you're over sharing, but it is enforcing that it's only going to stick to the policy of one-time user 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. 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 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, but you want to say, I promise I will 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. The only drawback there is just the complexity and cost of using over collateralization that way. So, yeah, this is like an alternative to that. It's like a proactive guarantee over write access.

I hadn't actually thought about that at all. So this is a new concept for me.

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. 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, because I do find these peer-to-peer credit networks very hard to understand who would use personally. But 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.

Let me explain liquefaction in terms of 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, even what to do, because it somehow is changing the rules of authorization beyond what the original account provider is already providing. There's many cases where you would like not to support this kind of fractionalizing. Like vote buying is a place where you don't want a secondary market popping up into your vote buying ability.

So liquefaction is the name for taking -- you know, the soulbound token approach that's just based on EOA accounts. I'm making this distinction because soulbound also has the social recovery notion, and I kind of mean -- 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 raw addresses where you think, well, because 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 later put an auction on top of it, or fractionalize. I think this was in the case of, if you have like a CryptoKitty, 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 encumbrance trick, and that's the kind of key notion of that 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. It kind of fits into a cat and mouse game in a way of trying to thwart or enable from the outside this kind of secondary market ability or redelegation ability.

Thanks for describing that. 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 maybe it would be great to talk a little bit about Cycles, especially since it's a very different TEE application, and I think one that perhaps also people in ZK land would find interesting, because there's things like ZKP2P, but this is sort of a different version of commerce between people.

Yeah. So the Cycles project has been something I've been helping out with the TEE stuff for around a year now. This is a project led by Ethan Buchman from Cosmos, Informal Systems, of course. And it's almost an accounting or a real world economics thing. It's 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 overall structure of this. But I like this idea of a credit network where we have 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. All of the account invoices that are due somewhere between now and the end of the month, these are all essentially uncollateralized credit between the companies who are 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 to actually do the paying their invoices. They have to load cash into the system that's expensive and has some 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 I owe you, you owe me, she owes -- we have third parties in between us. If we just all agree to 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 pay the cost of -- it's that much capital of cash that is displaced because it would otherwise have to be circulating. It doesn't have to circulate. We just atomically clear that. But this is sensitive business information. So even when it's in accounting software, Quickbooks or whatever, they're not trying to merge this and have a global eye view of everyone's competitive business information. This isn't a world that is just by default, everything public on the blockchain, 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 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. And then the significance of the TEE is because this is in more of a latency is okay, this is like a batch operation. Actually, the security of we don't just want to rely on the TEE to prove no one's going to be short, told not to pay, but then it's a big problem that they didn't. So we would use a zero-knowledge proof for the integrity guarantees that everything's atomic, you net out to zero or better while using the trusted hardware as a backup integrity, so multi-prover, but then that's also providing the privacy over all that data.

Interesting. So here the TEE 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 exchanging funds among friends? What kind of use case?

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

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 is inept chain to do that. One element of this TEE sidecar, TEE coprocessor approach is you can kind of attach it anywhere. So I like the idea that it could launch on an existing public chain. It's the TEE bits that would be new and added, but it could use Neutron or one of these Cosmos ones. I think but the way things go in Cosmos, it's most plausible that there'd simply be a 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 TEEs and kind of at first maybe not being into them and then 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-TEEs. And so I think it's good to hear your perspective on it. Also, thanks for sharing sort of these newer ways that we're seeing TEEs 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, Tanya, and Jonas, and to our listeners, thanks for listening.