Episode 405 - Sergey Gorbunov on TEEs and the Arc Privacy Sector

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 I speak with Sergey Gorbongh, distinguished engineer at Circle, who joins us this week to talk about ARC, Circle's new L1 blockchain, and specifically its approach to onchain privacy. We start with a catchup about what happened with his previous project, Axelr, and how Circle's acquisition of Interop Labs, the team behind Axel,

brought Sergey to Circle. From there, we dig into ARC itself. It's an EVM compatible L1 designed for institutional finance with USDC as a gas token. ARK also has a privacy layer Sergey calls the privacy sector, a private execution environment running alongside the public chain. The core design choice is trusted execution environments or TEES rather than ZK or FHE. And Sergey makes this case that TE's provide privacy but also allow for composability with existing developer tooling, debugging, and enterprise infrastructure in a way that pure cryptographic approaches currently don't. That is a bit of a spicy take for

this audience. We explore the trade-offs, including the hardware trust assumptions, side channel risks, and his response to Ian Meyer's public critique of the ARC architecture built around TE's. So, hope you enjoy. Now, here's my conversation with Sergey Gorbonoff. Today, I'm here with Sergey Gorbinoff, distinguished engineer at Circle working on Arc. Welcome back to the show, Sergey. >> Hey, Anna. Great to be here. >> So, today we're going to be digging into the topic of tees and your work over at Circle on the Project Arc. I'm very excited to do that. There's been some great debate online about this and it seems like a really good time to dig

into this, but I first want to do a bit of a catch up because the last time you were on the show was 2022, April. This was during a time that I was doing a series on bridges kind of I think I interviewed four or five teams that were doing different bridges. This was also a time that Axelr to me at least was firmly in this cosmos landscape. It was very much in the Cosmos ecosystem and this was right before Terra. So I want to kind of go back in time to 2022 and hear from you kind of what happened. What was your experience like? What happened with AxelR since we saw you? And then obviously I want to understand how you

got involved with Circle. But yeah, let's go back in time. What happened after we spoke? >> Yeah. So at Axel we essentially had the thesis that you know we're going to be in a multi-chain future and we wanted to connect all the blockchains together in a seamless way right and I think when we spoke in 2022 we were at the very early innings of launching the network right so we um I think launched we actually launched with Terra as one of the kind of go-to market partners and you know seen all the crazy ups and downs for it and yeah we launched with the Cosmos ecosystem we were the main kind of a bridge provider for a lot of the partners there, Osmosis included, and brought a lot of liquidity, especially

after the terra collapsed. I think we, you know, we were able to quickly get like USDC and other assets into the Cosmos ecosystem. >> And yeah, since then the network's been growing. You know, it expanded over the years to support like 80 plus different blockchains and kind of interconnect them together, various protocols around the stack. Cosmos back then was a very big ecosystem and actually I think just the year before that they had been rolling out IBC. I just want to clarify like Axelr was not doing the bridging between the different chains in the Cosmos ecosystem right this was the bridge out and in.

>> It was agnostic to any blockchain right so we did support IBC and we had connected directly a lot of Cosmos chains through IBC. Okay. But yes, the main benefit was that it was able to talk to all the other blockchains outside of Cosmos, which IBC was not and still not, right? So, it's Ethereum, it's, you know, Avalanche at the at the time, you know, and many others since then. So, yeah, but Cosmos, as you said, it was the thing at the time, right? It was grow growing rapidly and a lot of ups and downs throughout, you know, throughout the cycles, but it was definitely a very vibrant ecosystem. you were a partner of Tara. We actually for some reason this year have touched on the Terara story a couple of times. A

little bit of history for anyone who wasn't familiar, but what happened for you as a bridge provider when that went down? Because did you have a lot bridged between Terra directly to Ethereum or were you always going through osmosis? >> So I don't remember all the paths. I remember we had a lot on Avalanche and you know of the USDC. I don't remember which other ecosystems had more. I think Phantom something like that >> or US you mean like the the uh >> well US was the asset right of pure and then we were bridging it out of Cosmos to other ecosystems right so to Avalanche to Ethereum to Phantom network and a few others I don't remember what they were at the time so yeah I don't

remember the exact numbers but you know in tens of million um for sure >> and what do you remember finding out about that like do you remember the day for you That must have been like a big one. >> I remember with with Terra it was like a couple of things. A I remember launching with them because on the first day I think we processed like over 100 million of of the USD volume and like our systems were going down and everything. That was our first launch day and I was like it's actually a good launch day. We have traffic, we have users >> and it was pretty fun. >> And then during the collabs it was yeah 24/7 for a while. I think the biggest thing was a isolating the risk and so um you know making sure that

>> terra itself people were afraid that terra itself would be compromised and people would infinitely mint you know these coins and then be able to dilute and steal from the pools and so on and so forth right so we you know through the governance sort of suspended the connection to terra I think at that time so that was one thing that happened and two then at Cosmos there was a crisis of where is the liquidity going to come from right because that was the main stable coin in the Cosmos ecosystem and nothing else was available and we were on our path to roll out you know USDC I think USDT or whatever other stable coins >> on osmosis. Yep.

>> And I think we we pushed that and flipped that on within like 24 hours brought a lot of liquidity >> and that was thanks to the protocol like that was a design that we could do this things quickly. So it was more about onboarding the asset itself and getting it live. But yeah, I mean I think we definitely brought a lot of liquidity, probably saved a bunch of, you know, assets in the parallel. >> Crazy. Yeah, we had Dave on earlier this year and he was telling us actually about his side of it on on the osmosis front and the fact that they had been judging these different bridge projects and trying to pick the best one and they were kind of doing a very slow process to vet all of these bridges and then it turned out this this stable coin that was sort of propping up a lot of what

they were doing got pulled out under them before they were able to make that decision or like make the the new setup happen. Yeah, it's sort of bad timing. I think you said it was like a two week window that was missed. >> It was uh probably like a week of full-time thinking through that and then frankly after that the next few months been roller coaster as well, right? With the bank collapses with FTX collapses and like usually that means liquidity moving in and out from this deck from this chain to that chain. It was pretty pretty busy times.

Okay, let's fast forward to your connection to circle and how that happened like I actually am not entirely clear like was Axel bought or did you move over? What was the sort of transition to working at circle? Yeah. So, Axel itself as we launched there is a public network, right? So, it has a decentralized validator set, public governance. Anybody can join and kind of participate and we had a lot of participants in the ecosystem that were building connections and extending the network. And then Circle wanted to launch their own chain ARC, right? um it's a new layer one blockchain that's that they've been working on and they wanted to make sure it's as interconnected with other blockchains as possible and you know have the best

interoperability stack kind of serve that and so they acquired interop labs which was the development team behind Axeler >> the Axel network itself continues to exist and continues to be the public network and the public good and a new team from common prefix kind of took over the stewardship of the public network and so they continued developing and building it and kind of interop labs team the original team behind Axel joined circle to work on the arc and you know interoperability stack around it. >> Got it. Is arc then a little bit the equivalent of like tempo over on the stripe side? Would you put them in the in sort of a competitive category? A new L1 I guess focused on stable coins and

payments but like working more in traditional rails. Yeah, I would say that the the current wave of L1s, as you said, I think they're focused on a proven, you know, use cases, right? kind of a stable coin payments and everything else around it trading in but B we are finally I hope at the point where some of the institutional adoption and some of the broader adoption of the system kind of goes outside of the you know web3 native community >> and definitely you know ARC and some of the other folks that you see are tailoring towards that right and kind of making making sure that the new types of requirements are met right requirements around you know whatever has to happen

with respect to the blockchain when it interacts with financial institutions you know with real financial assets that have to have you know insuranceances controls liabilities behind them and you know arc is kind of optimized for that >> can you share a little bit about what circle is today as well I don't think I've ever had anyone on from circle so like I think we are all somewhat familiar with USDC what is the circle company you're saying you're building an L1 are you within the company are you your own kind kind of sub entity just curious like yeah tell me a bit about circle and the ecosystem >> so to your point I think circle is known as as was the the issue of USDC which is you know one of the dominant stable coins that everybody uses since then

they've broadened their mission and and horizon right so now circle really tries to build kind of a the platform the the operating system platform for financial use cases and financial primitives right so that includes everything from he having primitive that allow you to launch new assets to infrastructure layer itself right like ARC there is a deep interoperability stack that's now built around CCTP which is a crosschain protocol for the USDC itself you know there is now kind of a agent stack that's been built and and and a lot of other things so yeah since the USDC launch kind of circle has really broadened and and now it owns both the infrastructure pieces in the web 3 as

well as this global distribution through USDC and some of the some of the partners. So it makes it you know really attractive platform overall. >> Does it want like ARC this L1 are you wanting things like a or compound or like def morpho or these like defy products to deploy there or do you want brand new projects to emerge from there? Like I'm kind of curious what kind of applications you're picturing existing on this. >> I mean a little bit of everything, right? Like we're definitely kind of a in the crypto space we know use cases that have a product market fit right you know borrow and lending applications trading applications asset is insurance applications stable coin applications payment applications right

>> well understood use case with product market fits >> of course the best players you know in those categories are going to come to ARC and you know we build there and and have liquidity and and support and everything else but really kind of a give it a platform that allows kind and this new wave of both agentic applications I would say and financial applications from the institutions to come in and thrive >> is what I think you know we're kind of optimizing for on the agentic side right and >> you know I think you you you've probably seen everybody is rewriting the applications in these agent frameworks everybody understands they're not going to be you know taking credit cards and and wire transfers so you need kind of a

fast efficient blockchain rails to to support that and you know that's that's definitely going to be one of the focuses behind the circle stack and you know arc as well. >> This is maybe more of a question to like the circle ecosystem strategists. I don't know if that's exactly what you're working on but do you think circle would take on things like perexes and hyperlquid or do you think because of this regulatory this sort of more connection to more traditional things that it would stay away from that? by take on you mean like compete or >> compete like almost like participate start to get into the per deck space like having maybe their own applications doing that.

>> Yeah. So I I don't think I can like speculate on on those things. Um so uh but like I said I think yeah if the if there is a product market fit and you know a good regulatory compliant path to doing certain things I think you know definitely kind of a you know maybe potentially good things to to look at on on that end. I think circle prides itself to being the compliant body in the US for you know asset issuance and for working with digital assets on this intersection between you know crypto and traditional finance right so if you come to circle not only that you know that you'll get this stable coin but you know that you get you know all the checks and

balances >> correct yeah checks and balances in process and uh >> anything circle does you know definitely needs to make sure it satisfies you know those those checks and balances. It's a it's a publicly traded company. So there's you know a lot of reputation and trust will build over the years that I think will will carry into arc and you know future initiatives and kind of specific shapes that they end up you know taking place. I don't know but it's definitely one of the strengths that you don't see anywhere else for other projects in the space. Right. So yeah.

>> How far along is ARC? Is it live? >> Yeah. So a lot of the stack has already been built. there is a public test network that anybody can go and you know use and interact and launch assets and you'll see a lot of other applications being built there and yeah it's it you know it's it's going through its transition to the public mainet and you know I don't think I I can say the date yet but you know hopefully over the coming weeks or months you'll see those announcements. >> Got it. I now want to understand what kind of network this is because we're here actually to talk about the ARC privacy sector. So I want to kind of understand what ARC is. It's an L1 guess proof of stake. There's a privacy component to the consensus itself. So yeah, why don't we talk a little bit

about what the plan is there? >> Yeah, so Arc itself is L1. It's EVM compatible. So you know any Solidity code that you have, you can run on top of it. It, you know, supports your standard applications from, you know, solidity, Ethereum land. Underneath the hood, it has fast consensus, you know, all all of those nice nice things. So, it can process lots of transactions. But one of the unique things we're doing is going back to the regulatory question and compliance is privacy keeps on coming up as a requirement, right, from the institutions, from the from the people that want to use these technologies. And so we thought what is the best architecture for enabling privacy alongside the public space of arc what I call so you can have a very

tight composibility between public side and private side of arc and satisfy both kind of public and open use cases where anybody can verify and audit what's happening as well as the private use cases regarding you know asset issues payments and and other applications and what is really the best design that we think that these kind of two systems can coexist with one another and uh that was the that was the design behind the ARC privacy sector that we recently published. Does this have like a bit of an echo of the shielded part of Ccash?

Like is this kind of a there's like an unshielded environment where except I guess programmatic. So you'd have like smart contracts and everything happening, but then you have like the ability to switch over to like kind of move your assets into this private pool that then you can't see into and you can kind of come back out. Yeah. I'm just kind of curious if it's at all similar to that if that's how we should think about it. >> It's it's more generalized, right? So Zcash to to your point it's for specific you know transactions right and for specific fields you can do that in the arc I guess maybe you can think of that idea on steroids right so meaning that you have public space that has full EVM composability in the public space and at

the end of a day public you know virtual machine creates you know a hash of the execution tree right that included in every block and you can think of the same thing now happens in uh private space. So you have full EVM composibility, full smart contracts and what that gives you is a commitment of this entire state and both of these public and private live in the same block space. So that's the benefit that allows you to your point go in and out of this, right? So you can go shield and unshield things and you know move move between private and public environments.

But do you imagine I mean I still have the Ccash model which is like you actually send your tokens into this shielded area in what you're describing if you have smart contracts are some of the contract calls private and then like I'm kind of curious if you're like mixing these programs into a sort of mixed private public environment or you are sort of on that strict line of like the assets either live in the shielded place and everything happens in the shielded place or they live unshielded and and public. Yeah. I'm just kind of I'm trying to imagine now if you have this smart contract platform then yeah what is what happens >> that's a great question and it's sort of at the crux of challenges of designing something like this right so meaning that yeah like I said the environments

by themselves are fully programmable and touring complete right so you can have as as you say a program that lives half in the public space half in a private space and you know throughout it execution things move in and out >> and in fact because the environments are fully programmable you couldn't principle do that, right? The challenge is is how do you make sure that the underlying information that should be private continues to be private when you do that, right? Because every time there is a call from the public space like a query, like a state transition, right?

Like those calls could reveal something, >> right? So the way we have done it is that in the design and the architecture yes you could do those things but the way we're rolling them out is sort of step by step where in step one we're a little bit more prescriptive in terms of how you make the calls in and out and they're around asset transfers been you know programmatically potentially but moved in and out >> but as we learn how to build these applications more the design allows us to have that type of you know flexibility completely. It's interesting though you you talked a little bit about the challenge on the public side of like recognizing what's happened but in my mind like how do you know that what is happening

within the private sphere is actually happening correctly because that's harder to audit right >> yeah so now it's sort of a question of in the private land how do you do things but still get verifiability of the data right and of course you know there there are multiple ways to get in verifiability you can use your knowledge proofs or other cryptographic techniques The way we're doing it is by relying on trusted execution environments that run on every validator but still running a consensus across all of them. So what that means is that whatever you do as a validator even if you do it in the trusted execution environment all the other validators have to redo the same and we still reach a consensus on it.

>> So you you reach a consensus on the output of the TE >> on the output of TE's. That's right. So TE's produce kind of the state of the private chain that's included in the block but every validator has to redo it. So at the end of the day we still get kind of a integrated by consensus which is which is very critical right but we get privacy from the TE's themselves. So, and the way you're kind of guaranteeing that whatever is happening in the private sphere is correct is this consensus part because even if one validator was running malicious software had some weird things it was doing it would get kind of outvoted by all of the others I guess.

>> Correct. Correct. Yes. >> What's your threshold? >> It's the standard you know. Yeah. BFT threshold like 2/3. >> 2/3. Okay. Um, would you consider what you're describing as like threshold decryption type validator privacy? Like we talked about that a long time ago on the show with the Osmosis folks. I think the Aptos people are doing something like that. Dan Bonet mentioned it recently. I don't know if he mentioned on the air or off the air, but he was talking about this kind of, you know, threshold decryption finally becoming like a live used thing. In those cases, they're also kind of like hiding. This is more for the front running like to prevent front running but in what you've built would you fall under that category?

>> Not specifically. I think yeah the designs that you talk about threshold decryption they're there explicitly to decrypt something at the end of like block execution right like for the me protection or other things. In this case, the result is still fully encrypted unless the developer of that contract or application defines a policy that allows certain disclosures to happen around it. Right? So, so, so we don't use, you know, threshold cryptography at least right now. >> And then that consensus is that like consensus on encrypted data.

>> Correct. >> And this is kind of what we talked about. So there's some like some calculation happening within the TE on that data and then what comes out remains encrypted and then just compared. >> Correct. Exactly. >> It's supposed to match I guess. >> Exactly. Exactly. Yeah. So >> just like in regular consensus the execution has to be deterministic, right? And it becomes deterministic in the T environment as well and then you have you know encryption that happens on top and you can sort of compare across that. The thing is though I want to now understand the link between what we were talking about before with the execution environment with this consensus environment and maybe that they are the same thing. I'm not sure but I always think of that's that being kind of separated like that you have the miners

or the validators acting in a certain way but then on top of it or separate from that you have these private areas in this case are they more intertwined >> for simplicity let's trace execution of a transaction right so in the arc chain essentially transactions propagate through the memple and transaction could be one of two forms it could be a regular you know transaction over the public arc or it could be encrypted transaction Right? Now these transactions propagate through the map pools and let's suppose a validator gets you know a set of transactions. Some of them are encrypted and some of them are clear text.

>> Mhm. >> This validator essentially runs two parallel execution environments. >> Oh >> one of them is the EVM over the public state. The other one is the EVM over this private state that happens within the trusted execution environment. Oh, >> when it gets a transaction, it decides which of the VMs need needs to execute it and then it continues processing them one at a time, one at a time until all the transactions for the block are executed. M >> and then each the public VM side and the private VM side produce its state route which is their commitment to the new state and then you include that in the block along with all the transactions and you reach consensus on it and you

finalize that and that's how you how you how you reach the next state and because you now doing public private execution within these two VMs like like to your question earlier you can in principle have the transactions that that cross the boundaries right um like I that you do have to be careful about it to prevent any leakage but yes that execution can happen. So a private side produces something that needs to call the public side. It all happens within the same kind of a machine and node and you can do that efficiently >> in the public side this consensus that's happening. I'm assuming there's a validator set is proof of stake >> um >> or is what is it like what guarantees that on the public side they're acting correctly? you sort of said on the

private side like the encryptions need to match but yeah what happens on the public side. >> Yeah. So on the public side there's a validator set that's been you know that runs a consensus kind of specifics of the how the validators are chosen you know there there are different mechanisms that will be available but yes it's it's a large validator set and they they run the standard kind of a optimized BFT versions to reach like two-thirds majority. >> Okay. Are the validators going to be mostly partners? Like I I feel like I've we've heard a bit more of that model where you have trusted partners running validators instead of just like random person running it from their basement.

>> Yeah. So the validators themselves are going to be kind of a vetted partners, right? And that's one of the benefits of ARC is making sure the validators are large, you know, established reputable entities. Mhm. >> But yeah, so trusted validators, many big institutional partners in a traditional finance space are going to be running validators and participating in the network. >> Okay. So I think I have a bit of a vision for ARC. I think the one thing that's missing for me is like where does USDC fit in? Like where does the stable coin is the stable coin at the heart of this network? Is it just an asset on the network? Like where does it live? Is it an app on the network?

>> Yeah. So it's a great question. One of the benefits of ARC is going to be is the tight kind of a coupling and integration with USDC itself. And so what that means is that you know one of the gas options is going to be paying through USDC >> right? So as you interact on the chain it's a stable asset and for a lot of the financial institutions it's a frankly it's a preferred way to interact with these blockchains right so it's it's an asset that they can understand it's an asset they you know they know how to price there is no volatility behind it you know they can predict whatever revenues expenses and all of that and so yeah it's going to be tightly integrated within the ecosystem for gas you know and potentially like other types of

mechanisms >> but if with gas wouldn't it still potentially be variable because like I guess the issue before with ETH was that the ETH like the gas price was variable but also the ETH price was variable. So you had these two variables. Sometimes you'd be spending like hundreds of dollars worth of ETH at the time which could also be worth less later or more later. But with USDC it could still like wouldn't the gas still be variable? >> Yeah. So the gas is still definitely variable and you have to do that for kind of denial of service and other protections. But as you see like with you know a lot of the other blockchains as well if they're fast and if they can process thousands of transactions per second the variability in the gas cost

itself is not that high right so most transactions you can still do you know at you know at very low cost at at pennies and its surviability from the asset fluctuation itself it doesn't actually add to the price maybe that makes it more complicated especially if you can process lots of transactions but it's accounting in its compliance, it's everything else that has to go around it that you know that I think makes it potentially more challenging for some partners. For some, you know, it's not an issue. >> Uh but for others, it could be more accounting.

>> Cool. How did the assets move between those public and private spaces if it's just a TE like this is something where because I think of it as like a public network. So I'm like isn't the state like is the state held in like on individual devices like or is it living in a central place the validate like only the validators have state of what's happening on the private front like how does how does something move into a te the reason I'm going to just give a little context of why I'm asking is that I've always understood it is like there's a proof that has to be created along with that transaction so that it's very clear what's happening in a te it's there's no need for it. There's no proof. But I still don't really

understand how that movement happens cuz it's device-based almost, right? Like it's T is a trusted execution environment on hardware. So where does that hardware live? >> Yeah. So a a couple points. So first of all, you can't think of TE's as something that also produces proofs, right? And in fact, you do have to check those proofs. So TE's by themselves produce atistations. >> Okay? >> Right? If you wanted to atestation is your proof. You could just verify that at the station and verify its execution. We go one step above. Like I said, we don't just trust the attestation, but we actually rerun the execution across all the validators. So we don't trust TE's for the integrity of these at stations.

>> Right. So we we take one step above and take extra measurements there. But to your point, the encrypted state itself, it could live anywhere, right? On any node, on anybody that's participating in the network. But the ability to either perform state transitions or execute queries with respect to the private state, they now have to be done against the nodes that's been sort of authorized by the consensus or more broadly to have, you know, the access to the private state and decrypt it and answer those types of questions. So, so there there's going to be probably a few different types of nodes that would have that. So, A are the validators of course, right? So the validators do the state transitions but B for you know

wallets for other types of you know explorers or other applications you still might need an ability to query and typically you have RPC nodes that that provide that functionality and so in this case there will be special RPC nodes that are provisioned with also trusted execution environments that would have an ability to answer those types of queries. >> Okay. And how would you pick that like how are those chosen? >> Yeah. Yeah. So that will be vetted right like by by the kind of ecosystem and by by circle you know in principle right by the design if you trust in TE's it could be anybody.

>> So design allows if you assume in the trust of TE's the design allow anybody to run that because you'll be able to verify the code that they run inside of TE's. So that's actually very very powerful. Again, Circle is probably going to go a step above that and still vet them and make sure they run in good infrastructure and so on and so forth. But by the design, you know, that could actually be run on an untrusted node if you want. >> But this is this is all there's a caveat in there which is like if you trust TE's completely. >> That's right. Just like with any system, any cryptographic assumption, you your trust has to start somewhere, right?

Whether or not it's math implementation, you know, or it's instantiations. I guess for us it it is the T as the underlying kind of a root cause but the design is not specific to one TE. So you could swap them, you could replace them, you could have multiple TE environments. So it's it it treats tea as a building block and you know I've done like a lot of academic work on it like actually a decade ago with you know Dan Bonet and a few other folks where we formalize TE's we try to understand how do you use it as a building block within broader you know cryptographic environments and I think we now have a good understanding how to do that >> had you actually explored TE's for AxelR >> no because we like we were not focused on privacy right and you know we did

have kind of a multi-party setup across the validators where many parties have to assign things and the early days we actually use like threshold cryptography for that until we switched to more of a multi-et cryptography but yeah we have not we have not you know explore it because we didn't have privacy needs at the time >> so in the announcement you made on Twitter you kind of described the arc privacy sector as the last privacy layer in web 3 which is very bold you then went on to describe the te infrastructure and obviously from like our side of the community, you got a little bit of blowback on just the use of TE's. I'm sure you're wellversed in the security, you know, around of TE's, the risks. So, let's talk a little bit

about that. What made you make that choice? And I want to bring up some of the counterpoints that were brought up by the community and see what you have to say. >> Yeah, for sure. Maybe take it a step back. I mean, I love cryptography, right? I'm I'm a cryptographer, so I spent grad school professorship We think you hate cryptography. >> Made papers on it and you know done a lot of lattice work and and other things. So trust me if there is an opportunity to use cryptography I will do that. >> Okay. Okay. So you also had to have your arm bent is what you're saying. All right.

>> No I think I you know I've been I guess the last decade spent more actually trying to build products that actually try to integrate security designs and good privacy and principles into systems. and I just know the complexity and the challenges that go around them and you know for for ARC and everything we've been doing it had to be a practical solution and at that point you know as we were thinking about it I I just had to put a product hat first not a technologist hat first right I think as a technologist and frankly >> first company you know when we were starting out of grad school like Dan Bonet was advising me we try to commercialize a lot of MPC a lot of homamorphic encryption stuff we also ended up using actually some T you know stuff but that reserve a decade ago. So

I the complexities are there and you know I well understand what that means for the complexities once you integrate them in the system. So it's it's it's relatively easy to write, you know, papers about them, but it's really really hard to build a product that that people use. And I think the TE right now when it comes to general execution environments when it comes to ease of usability and when it comes to actually understanding a little bit more security and assumptions behind these TE's I think that mix is is pretty much there and providing a really strong environment that composes with developer stacks. That that's that's that's actually one of the points I want to hammer out. Most privacy environments, they're not used because they do not

compose. >> They do not compose for debugging. They do not compose for developers. They do not compose for the users. And you have to always rebuild the whole ecosystem of those tools in parallel, right? And so we wanted something that composes a lot better. is a lot more tightly integrated but still provides you know really strong security and privacy properties and you know relying on TE's as the underlying assumption is the way to go these days. Do you mean when you say compose, do you mean like just being EVM compatible on either side or Yeah. is there a different kind of composition you're imagining here?

>> There's a lot more, right? So when you're running a system in production, what are the types of things that you have to deal with? So number one, debugging. So a user comes in and says, "Hey, my transaction failed." You whatever is a support person, application developer, whatever that means, you have to understand where the issues are. Is the issue in the smart contract itself? Is the issue in how the transaction was sent from the front end and maybe encoded? Is the issue in the underlying execution environment? Those types of things typically require a collection of tools to be built. Right?

So if you're running a system, you have you know your data logging system. So data dog or something else where all the data gets dumped and you get to analyze and you then you have you know your analytic systems, dashboard, performance monitors and so on and so forth. Then you have your support staff right that deals with all those types of issues. And then later you have accountant and everybody else that also has to have you know understanding of what happens and maybe they have to generate a report and to your point about gas like that's an accountant statement that has to be generated and somebody needs to needs to at least make sure you know revenues and expenses match or whatever they they need to be. So there's typically like 20 other tools that have to run in parallel with your main blockchain system for the

ecosystem to thrive and for the developers and and users to make their stuff. And so that's what I mean by actually composability. It's sort of composability with outside systems. Composability within smart contracts you can get and you know we kind of know how to do that. That's that's okay. You can you can do something there. But this developer and broader corporate integration suite is incredibly complex for pure cryptographic solutions which we try to avoid. M. So you feel that was it sort of like the decision to to use TE's at this level of the stack was also made because of how critical it is and how you it sounds like even though you've worked in cryptography for a long time you you still have sort of weariness about using it as a basis like

here you've decided you've opted instead for kind of an enclave on hardware which I mean it has all of the problems of oh well then you have to trust the hardware etc etc but I do feel like we've covered this quite often on on the show and I do know the pros and cons here. >> In your case, it being at the sort of base of the stack, is this why you chose TE's for that? But would you opt for more exciting cryptography for different parts or would you do TE's the whole way? Now, >> no, I mean like if there are opportunities to do, you know, stronger security without compromising a developer experience, right, or these composability properties? Well, absolutely, right? like you know if it

makes sense for instance to sometime use threshold cryptography for >> you know some me production yeah you can you can still have that right as a layer on top by the way one of the nice things about arc and the way it was designed is that there is this separation of consensus and execution environments and it's a really nice separation that's what allowed us to to plug in this privacy VM environment but you could have other type of environments running you know maybe for homorphic encryption I in parallel where okay you actually need extra layers of security and you don't want to rely on you know any hardware assumptions and you can do that >> I mean in fact some of those could nicely compose with the enclave

environments as well right so I'm I'm sure you know one of the potential criticism of enclaves is that you have sometimes side channel attacks right uh >> so they could be software they could be hardware >> but you know we've also done work how do you leverage things like oblivious RAM um right to protect against side channel attacks from from enclaves at least on the software layer. So you can you can imagine those types of building blocks being as like additional maybe data structures that get plugged in into the environment that runs for TE and you get a little bit of best of both worlds >> actually. Yeah, maybe I should have asked before I made the comment before.

Is the bottom of the stack like the part where the T is being used, is that the most critical data? Like yes, it has the private state in it, but I guess let me maybe we'll say a theoretical here, but like if T's were completely broken in 2 years, would it matter to the kinds of things that you're hiding? Are these things that have to be private forever? Is it a short-term privacy or a long-term privacy that you're looking for? The reason I asked this, I think this has come up on a recent episode where we talked about like sometimes it's okay to take a bit of a risk because you'd have to break it within like 30 seconds of it existing for it to be really damaging. I'm kind of curious if your system fits more into that category where it's like because it's

about a validation system where it's happening kind of in real time. >> The the way we think about it is that ARC and you know the privacy sector stuff it's a platform, right? So we want to provide a platform but given that it's fully programmable it means that you know it really depends on the use case and what the developer needs right so there are things like you know explicit like view keys that allow a developer to authorize you know maybe like financial report or to do their taxes you know to specific accountants whether or not their information is you know needs to be forever protected or not you know it's it's it's up to their their use case again because as a circle would do have an ability to work with kind of a vetted validators and you know

RPC providers and so on so forth like we could also at the network layer control who gets access to some of the you know encrypted state as well right and uh you know make sure it's not kind of propagated but we we do intend the encrypted state to be protected with the best guarantees in mind and for us actually the best guarantees being actually postquantum secure as well. So we've done like another paper that we published I think about a month ago >> where we talk about all the postquantum strategies that go behind the arc. So from our side we give a platform we we do protect it as much as possible you know including postquantum adversaries from the user side you can always you know customize it have U keys not worry

about your encrypted data maybe have shortterm application but those are application specific things that we leave to the users but we just want to give the best platform that that we can >> but you just sort of said so like the validators are chosen so you can still do things on like how encrypted it is or if they decrypt it like is there almost a bit of an admin system somewhere built in there like could you say you needed to find something or you needed to like are you able to do it >> so a itself like arc will have consensus so it have certain governance rules and so on and so forth right and I think you know as as the network gets rolled out you know some of those will be will be published but B as a developer you it's a fully programmable environment right

so you can in principle as a developer say hey I need to expose this amount of data or I need to show this data to an auditor or I need to show it make sure it it doesn't violate any sanction lists right and those are the types of asks that we we get all the time anybody running the systems need to make sure >> they're not interacting with you know foreign nations that are on the OFAC lists as an example so the system has an ability for the developer to you know to satisfy any of those checks that they that they want >> but like if you as circle needed to Say like say you're worried about a transaction has gone through it being nefarious. Would you be able to prop I know maybe there'd be a like a group but

would you be able to propose to unmask that like to unshield it if you needed to? >> No. So so by default there is a consensus of validators and you know everybody has to reach the decision. Now who could propose this consensus and rules and some disclosure to happen you know that's sort of TBD and that will be kind of rolled out over over the time right um >> but by by but by by default for any action >> you have to reach a consensus now who can propose it I think it's subject to you know governance rules that will be kind of laid out later but twothirds majority is kind of at the protocol layer that that's always there >> you did talk about like encrypting and then decryptting I'm kind of curious

Curious because like I always think of if you have to encrypt and then do something in a system and then decrypt that sounds like FHE not really tees. So like are you are you kind of doubling up there? Are you doing like you're making everything private and then you're acting on it within an enclave and then you're bringing it out still encrypted or are you doing an encryption on the in and out? I actually didn't Yeah, I just didn't follow that. >> Yeah. So by the way like T can be modeled as all of these kind of complicated you know function encryption fun functionalities right like we we wrote like some papers on that a while ago. So all of these things are very similar. The way that we instantiate it is that the transactions are encrypted by the user using kind of a postquantum

encryption first. They propagate through the mempool. They propagate through the validators. Validators bring those inside of TE. then inside of T. So once something is inside of T, you can think of it as already being protected or shielded or encrypted, right, by the T environment itself. >> So then you can strip off the inner layer of encryption, right? And then do the computation within the TE, but anything that leaves TE, if you want to protect it, you want to reenrypt it again at the at the exit. So that's what happens here as well.

>> So it's happening kind of in the TE. There's some encryption happening just as it touches the outside. inside. Is it still then in like a plain? Is it sort of like in the tea? If you were sitting in it, would it just sort of be happening in public? Like there's no it's not hidden in any way >> under the hood inside. >> Yeah. So inside of T the T itself sees the data, but the T itself is a is a is a shielded box, right? Like it is the you know depend on T like that is the encrypted memory space in some sense.

I'm just trying to understand like the riskers like if you could look inside the tea then you would see what's happening. >> That's right. Yeah. If you can look inside of T you can see what's happening. That's definitely you know the the assumption that we make. Is there any record of what happens in there? And the reason I as I mean you mentioned postquantum and I want to I want to talk about this where I mean this is something that's I think has sort of it's pro all the cipher punk and like hardcore cryptographers like yourselves have been thinking about this forever but you know layman like myself have only it's only just dawned on me recently that like if quantum computers are able to break quote unquote encryption it doesn't mean that like like systems could upgrade in the meantime which is great but if the

encrypted data is somehow held somewhere >> from the past. And yes, the new systems have new encryption, but the old systems had old encryption. You could with a quantum computer decrypt it and actually look at all of the stuff that was in there. And so I wonder in this case, like all of that stuff in a TE, if it was accessed today, even if it's not, if you can't look at it right now, would you be able to see it in the future with a quantum computer? I think your answer is probably going to be no because it's you already talked about it being postquantum secure somehow. So yeah.

>> Yeah. So anything that is kind of fingerprint or checkpointed to the blockchain itself always uses kind of a postquantum secure layer in cryptography, right? So you cannot you cannot you know that's a state that we assume that will be there forever. And so yeah, we want to make sure that to your point that kind of a capture now reveal later types of attacks don't work on it. And in this case there's two types of encryptions. There's you know public encryption for the transactions that go in and out and then there's typically symmetric encryption for the actual state itself. Symmetric encryption is relatively you know straightforward to make postquantum secure for the public encryption. You know these days you want to use like a hybrid of both classical and postquantum

secure encryption and then you know you end up with a nice layer of encryption there as well. >> Is this already postquantum? Are you kind of saying more like oh these are the sort of tweaks we would make in order to make it postquantum? >> No from from from day one kind of at the privacy sector we'll have you know the the encryption being postquantum secure there there is I guess like TE itself environments would have to be postquantum secure and uh >> so there's a little bit of work there with the providers of the actual TEES but the state that will go on the blockchain itself from day one it's going to be postquantum secure.

>> Cool. By the way, on that like one important thing I want to point out which is this is something I haven't realized until building on this as well is actually standard cryptography protected by the layer of tees gives you postquantum protection of your assets from day one. >> Why? >> So this is very very important right? So think of it this way. Why why are people worried about attacks on the blockchains? because you have a public key and some assets behind it and everybody can see what the public key is and if you have a quantum computer you break and figure out the correspondent symmetric key.

>> Mhm. >> Now in the privacy space your public key is always encrypted by symmetric encryption that's always postquantum secure. So you don't ever actually ever expose the public key >> and so nobody can actually try to come up with a corresponding secret key from it. So almost like in Bitcoin there is a the way of you know like pay to hash and like people use as a temporary way to protect yourself against quantum computers because your public key is not exposed and only the hash that's revealed >> but in this case your entire state including all the public keys and the assets are encrypted so you don't see them and nobody can break them and uh I think it's actually very cool property that I haven't realized either until

recently that like this layer of te gives you postquantum protection like for regular cryptography from day one. >> I mean, in this recent episode with Dan, we talked about this hybrid signatures where you just put something that was not postquantum with something postquantum and you actually get the postquantum characteristic. I didn't hear about it for tees. This almost suggests like everything should be just run in a DE because then it's automatically postquantum. >> Yeah. Yeah. I mean, yeah, you do you do make that sort of assumptions there, but absolutely I think it's actually it's it's a huge benefit that like, you know, I haven't I haven't thought of until recently as well. I have two questions coming up. One is what kind of cryptography is in that encryption? Like what is the encryption method itself?

And then what are the trade-offs? Because I feel like we've talked a lot about how great these TE's are, but there's got to be something beyond just the fact that there is this like sort of longtail risk that they get unshielded or like that they would be broken. But yeah, I want to talk about first the cryptography and then the trade-offs. So what's what is that encryption made of? So there are different different layers but the the the majority of the important data which is the state right that just encrypted using your you know a symmetric encryption right so symmetric encryption as you know is kind of a secure against quantum attacks because you you don't have a corresponding kind of a public key and you know you're relying on on sort of AES or some variance of it and it's a

it's a cipher that people believe to be postquantum secure and the majority of the state is encrypted with with a variant of as >> okay AES is that a choice by the way or is that like automatically built into the T like is does a T provider give you this or is this what you've developed? Well, what we have in developed, we're using standard libraries, but it's a choice, right? Um, you know, so within the TE to to your earlier question, things that come out, they need to be encrypted and you get to decide, you know, how they're encrypted. If you're sending them back to the user, you can encrypt it under the user key. But if it's most of the state that just gets put back on the blockchain, then, you know, you can just use a kind of a symmetric encryption for that.

>> Okay. Now, what are the trade-offs of using a T? >> Yeah. So, let's let's first of all take what are the alternatives, right? And we can talk about sort of the trade-offs. I mean, the alternatives are fully kind of cryptographic solutions. Let's say that, right? >> And FHE would be the most equivalent I feel right. >> FHE, you know, function encryption, multi-party computation, right? Those are those are essentially your your options. >> Mh. >> Now, so let let's take a look at FHE/MPC, right? Which is, you know, you can go from one to the other by themselves. Let's say FHE is wonderful that you can encrypt anything. you can you can do any type of computation. The issues are a the you know the the

performance overheads. So everything in the FHE has to work over some type of a encryption let's say like lattice based in cryptography that means that every bit that you want to compute on gets encoded in a you know large array of numbers think of it that way and then those numbers have to be manipulated you know in large arrays to to do the computation. So as opposed to doing computation over the bits, you're now doing them over large arrays that are kind of encoding those bits. So the performance overheads are there. They're pretty significant still. And if you want really general computation, they're, you know, extraordinary, right?

For specific computations, you can optimize things. If you only care about, you know, a payment from A to B, you can do that relatively efficiently. But for more generic computations, they're just intractable. And in fact, I think most people don't realize that FHE has a fundamental problem that everything has to be computed in the worst case runtime on the worst possible input. >> This encrypted input. >> Yeah, you're not allowed to see has this input terminated or not, right? Because if the input terminated like you're actually revealing information. So for instance, I'm sending you a transaction.

If you're able to see like a reverse of the transaction along the way, you actually learn information about the transaction and like for most smart contracts, you're going to expose everything that's inside there. So you always have to run in the worst case runtime on any possible input. Oh dear. >> And so that theoretical overhead I think something very few people realize and it makes it very impractical for generic computations, right? Um for generic computations. >> So that's the biggest one you know kind of a drawback. What was the other kind of cryptography you mentioned? >> I mean there is like functional encryption which is >> functional encryption that's Yeah.

>> Yeah. So functional encryption technically can allow you to release certain intermediate results and you know still be secure against that but the computation overhead for that is on the next level right of of overheads and you know that's that that's even harder to do. And so I I mean I I spend my grad school like doing functional encryption. So it's a it's it's it's complicated >> but yeah you know the good thing about FHE let's say approaches right or MPC is like yeah you can technically start with one simple cryptographic assumption implementations are not easy. um you do have to unroll every computation into the format that FHE understands that usually being in some type of a circuit and then you do have to have that

circuit to to perform on the worst case compute runtime. But the biggest one which I would say is that yeah by default like you just break all this composability that we talked about earlier right so everything with FHE >> it just does not work with your standard system does not work with your debugging support ticketing systems so you pretty much have to build that entire enterprise stack to accommodate that whereas with tees hey you can carefully define rules and permissions that would you know allow accounting to do their job you know on your encrypted it state as the developer of the smart contract and that's pretty straightforward and you know you can clot most of it these days but with the FHE those stacks just

don't exist and you have to rebuild them which which I found to be the the real barrier right to for for adopting the systems >> and I have to ask since you're on the zero knowledge podcast why not ZK >> well yeah so zk by itself right you have to ask who knows the data right and who is going to be computing these computations right So in this case in the world where nobody should be able to see the data ZK by itself is not sufficient >> doesn't work cuz someone at the start knows the data >> somebody has to know the data yeah >> correct so typically people combine ZK with FHE right so FHE by itself also is not sufficient from what we discussed right because FHE doesn't give you

integrity so if you tell me you did the computation over FHE and you tell me include this result in my blockchain I cannot do that by itself right I either I have to again rerun that computation across all the validators >> or I have to ask you to compute a ZK proof that I will then verify in my consensus and and include that and you know putting ZK on top of FH that's another layer of overheads which makes it intractable for many use cases but by itself yeah ZK it's you know it only gives you kind of integrity and privacy with respect to somebody who knows the entire state so for general smart contracts where it's multi-arty interaction across many players and you don't want to see you know who owns what

that makes it harder. >> H in the case of T's though like would you ever use ZK for integrity there too? Uh you could right like like I said like you know you could keep on augmenting TE's with oblivious with ZK type of backend agents if you want uh because we rerun consensus anyways and we don't trust TE's for integrity >> we don't need that but if you don't want to rerun consensus and you want to save on that you could plug in kind of a ZK within the TE without having the FHE right so you're essentially then replacing FH back end with TE back end and you're still taking kind of a ZK overhead only in this case.

>> So going back to my initial question though, what are the trade-offs of TE's? So we've kind of walked through the different types of cryptography, how they could be used. I mean I think performance you shared, but what is the negative of working with a TE in this context? >> I mean the the negative is kind of it's the assumption that you make right on the on the secure implementation of TE, >> right? So if you model T as a black box and everything is great, then you know you you're you're solid. But there are things like to certain types of TE's people have found like you know some side channel attacks right so if you were to have access to the machine and the physical environment and you can plug in some electrical probes into the CPU you know maybe you can extrapolate

something >> you know for us we're relying on kind of a nitro enclaves from AWS at least as a starting point to which nobody actually has the physical access right so >> so you have double protection you actually have them in a place which is hard to get to in the first place. >> That's right. >> And then you have the trusted execution environment. >> That's right. Yeah. So it's a you you're relying on the kind of the entity to instantiate them and their physical separation and physical controls which you know they're incredibly strict about of course and then the you know the implementation of the T itself.

>> Like I'm not familiar enough with how TE's work. I mean as I've understood it there's a whole tech stack that interacts with that. Is there any risk that that tech stack side of things could be compromised like with all of these AI hacks happening and just I mean not hacks of AI but like where clearly it's like an inhuman level of scrutiny and they're able to find like insane little loopholes little little gaps where they can act maliciously like is the software that runs the TE's or runs within them or interfaces with them like is that ever a vulnerability point beyond the physical entity?

The answer is yes. But that answer is yes for anything you do with privacy or cryptography, right? Like I'm sure you see I'm I'm sure you see now you know the ZK and Zcash you know exploits and I think in general in crypto the number of exploits again like picked up because of all these AI tools. Um so yeah like you know you have a software implementation of course you know you're going to have some some exposures and I think people need to learn how to leverage AI as both they build systems and you know defense systems and it's not easy to do with with complicated systems. So the simpler it is you know the less likely you have vulnerabilities. I would actually argue that the ZK systems that we have,

they're a lot more complex and so they're probably more issues that people don't know cuz like the reality is like Zcash and like vulnerabilities. >> Yeah. Like Zcash and like that implementation. It's probably like, you know, a couple dozen people that can understand what happens there, right? Like it's it's a very very complicated system. Although more today I mean maybe when it first came out like the orchard >> bug I agree but actually I think we see a lot of people learning in the zk hack discords there's like more than you than you know >> no that okay a few hundred people let's say that >> okay >> okay maybe thousand >> no a thousand people would know how to do zk probably not a thousand people understand like zcash implementation

>> fair yeah true >> so I think still like probably, you know, a couple dozen, maybe a hundred understand Zcash implementation and like all the details cuz that's also deep, right? Like there's a math layer there of like libraries and everything else. Then there's a cryptography layer on top of the actual ZK. Then there's a systems layer of how it's actually used and everything else along the way. So that stack is is is pretty deep. So you know, the deeper the software stack, the more I think vulnerabilities, of course, you know, you have to you have to keep an eye on. But actually unrelated to what we're discussing, I think we as security/privacy you know technologists need to think what is maybe actually a more dynamic way to build the systems that can patch faster and mitigate some of these things

more dynamically as they as they know. So almost like making an assumption that there will be an AI that will discover something. >> Yeah. >> And that might happen before you do. >> So what are the built-in mechanisms you have in the system to protect against that? create the antibodies. They have to be there ready and they have to be evolving themselves, >> right? >> Exactly. Yes. >> And they have to be crawling around it. Like I have a visual now that's like these attackers coming in from the sides, but like all around there's this layer of little white hat hacker bots trying to break it first and then create the antibody as quickly as possible.

Huh. >> Yep. Yep. Create the antibodies like system level isolations, right? Like pro, you know, contagion mitigations, you know. you know we all of that I think has to be >> there we go yeah >> it actually protects you interesting >> yeah so I think like that's something none of the kind of legacy systems have and I think we have an opportunity for the new systems going forward you know whatever technologies they use is to bake that from this from the ground up which I think we must >> interesting cool well Sergey I don't know if you have anything else you want to share maybe like how people can get involved or what's what you're what you're thinking about today in terms of yeah I don't know next steps >> yeah I mean a lot of ARC material is is

starting to be posted online so you can see like the postquantum paper we announced a couple of weeks ago the privacy paper that we posted as well the the ARC test net is is live and you know people can start playing with that and seeing what's available there you know and otherwise yeah happy happy happy to answer any questions if people DM me as well >> cool I do want to do a quick shout out to Ian Meyers who respond responded a lot to your post because I actually felt like the dialogue back and forth between you was interesting just around the concept of tees from an implementer and a researcher and kind of he's more on the ZK side I think and you're more coming from the TE side. Some of the questions and ideas that we talked about today I feel like we're covered in that

thread. >> Yeah, it was a really important back and forth I think. Yeah, >> you know for for everybody these are the important questions but I think kind of taking a step back right like I think the reason for back and forth like put aside again like technological ideologies right um you know if if one can use the best technology of course they should I feel like at the privacy we're and the reason I call this sort of the last project >> cuz I think we're a little bit all tired of hearing about it and not having systems that work and not having it been used at least I am you know I spent you know over a decade on on on thinking building the systems from research to production stuff very little of my dayto-day is actually using any of these

systems today >> and you feel like they should be >> I I think they they should be I think again like because of AI threats because of everything else like we do need to be encrypting more data we do need to be protecting our confidentiality with AI essentially the data you know is your intelligence right if you don't protect your data, you know, open AIS and clouds of the world are going to be doing your job better than you tomorrow like period. >> So having a data privacy I think is just incredibly important. Having confidentiality is incredibly important and I just want to see more tools and systems embed that from the day one. And I think we do have that opportunity a

with you know some of these new blockchain stacks like ARC b as we build around all these agentic agentic use cases and AI use cases I think we have an opportunity to embed that at the core of the systems and so I want that to be there with as little friction as possible. You know I actually hope to see more use of it at the end. It's funny at the beginning of the year I think we were like 2026 is the year of privacy but maybe not in the way that we expected it to be where it's like it becomes like the full loss of privacy becomes much more real as these agents really come online and just the scale of what AI can do becomes more apparent to all of us like how important these spaces are that remain a place where you

can be free to you know do your do your activities do you're thinking, do your writing without it all feeding into something that knows that much about you. >> Yeah, absolutely. I maybe that's the big motivator that kind of unfortunate waiting for. >> Anyway, cool. Well, Sergey, thank you so much for sharing with us your story of Axelar since we last spoke, your move to circle, the building of ARC, some of the choices that you've made, and yeah, our conversation about TE's. Thank you so much.

>> Awesome. Thanks so much for having me and uh for the discussion. >> Cool. I want to say thank you to the team, Rachel, Henrik, Tanya, and Hector. And to our listeners, thanks for listening.