Ethereum’s future hinges on TEEs

Transcript

out. [Music] Hello. Yeah. Hey guys. Um this is Delhi from Automata. Uh really happy to be here at ECC. Also it's first time seeing so many audience here um watching the talk on tees. So it's really uh I guess it's a moment for us. Uh so we are actually building the uh onetization layers uh for like many years uh focusing on delivering like solidity libraries working with zkms to um just

do one thing which is uh attached to your TE's on chain or or simply put verifying the code that's generated by the machines. Um so we actually work on many different stacks um Intel ones um also AMD uh AWS Nitro uh we touches basically all of them work with uh work very closely with cloud providers uh also we have bare metal machines so we know how to really deploy those uh even on bare metals so um earlier this year in Denver I also give a talk on um TE's adoptions uh at that time I wouldn't really believe that uh there are people like really love to exploit it but I think as uh today uh I could uh really

say that uh we've seen a lot of adoptions uh as we uh walk through the talk you will also see um like a lot of new ideas uh like around uh using like te to help uh ethereum to reshape its future um so um you must um see the news that um like L2 L2 beat the website that list all the uh rollups are starting to reassessing and also recategorizing the uh all the rollups and some are actually losing the like roll up states um which is the um maybe the kind of top signal because we've also seen uh rollups uh start being shutting down uh being phased out um it's a like it's really kind of a milestone uh to say that maybe

Ethereum already um kind of answered it initial scaling question uh but again it's also um um something that uh we should uh focus on the next stage uh because uh there are still other issues here. Um like I already listed like three um like different aspects. Uh these are somehow interwide together. Uh not really independent. Uh it's all it's really hard to like put them in a nice way but this is kind of the best effort. Uh so I will I'll be talking about like scalability with composibility and also the uh meaningful privacy and uh lastly the provable um speed and also uh fairness. Uh I think in the end you will know that uh maybe TE could be uh the

solutions for some of this. Um so first the uh the composibility issue I think it's uh it's kind of inherent when you start doing rollups because uh you create um like different states different chains uh it uh it's all these technical differences but also you creates like uh difference in terms of market growth or market shares. Uh so that's really hard to um have like coordinations between different like chains different rollouts because those big players uh wouldn't really um mind um like just win winning more right they could just stop like um doing any meaningful uh like collaborations with other chains and still maintain its advantage and also um another thing is

the crosschain uh transactions or messaging are still quite slow I think part of the reason is it's take time to um withdraw draw from uh layer 2 and then um uh and it's like the issue the reason is u kind of multifacet because you have um different type of roll up you have like decay rollups you also have optimistic rollups which have a longer like withdrawal period um so uh all this actually um become one um kind of big challenge which means uh which is the uh kind of the uh the entire ecosystem is not really skill up uh and preserving the uh the so-called like uh network effect as a whole um ethereum

ecosystem. So that's something we need to solve. And the second part is uh it's actually not a new issue. Uh I think it's already there um since the very beginning because it's uh I like blockchains are transparent layers. Uh but uh there are still uh some meaningful protections we can provide for users which are not in place today. Um for example, some are really highly demanded features or apps that we should uh promote or we should build. Uh I think Vitalik mentioned u a couple of them like the payment privacy issue which is I think uh kind of fundamental because you don't really want people to see your billing right see your spendings every day. Uh secondly uh I think uh we we don't really have really

some some good defaults. For example, all the onchain activities are are somehow linked together because you ended up using uh maybe just same wallet across chain across apps. You don't really have um kind of a per app protection. And for example, if um like if you are using Apple, they they provide this kind of a um like email relay, right? So you could just sign up uh using different address for different services. But I think there's no such default here. uh uh the only way is to uh maybe you you try to memorize so many different uh seat phrases or create so many wallets and try to maintain the mapping yourself which is troublesome

and also uh some other things including um the RPC RPC layer uh you're probably going to um be surprised that you are actually giving out a lot of information to the uh centralized providers um including your intentions including your identities because uh those data that you send over even it's a query uh it can reveal your identity or be linked back to your other kind of uh devices uh and um and also um I think um lastly the network level uh information um there's no really good choices to protect unless you are expert on like uh shielding your uh kind of connections to um uh to the

internet uh but that's not something that uh average people could use. So, uh again like I think a meaningful meaningful privacy really means that uh something that users could uh easily pick up and use uh without having to worry much about it. And last one is the uh kind of probable uh fairness and speed. I think uh when when we talk about fairness in Ethereum, I think the first thing come to mind is actually me. Uh I think it's been a a nightmare for many of the users uh also dep developers as well. um because you don't really have good solutions uh you either have to sort of bribe the uh validators or you just completely fall victim to it. Uh and also um in terms of

speed uh because of the delays you see in those withdrawals uh you really have to wait and this resulting longer delays when you try to do crosschain actions uh which uh really interrupt the uh user experience a lot and um and because of all these things uh it's really hard to create real-time apps um for example the games or uh even like messaging apps um sort of things um so we I think people are already thinking about um kind of making faster confirmations even the block time is still um longer. So in the end I think some good defaults are here are like we should really provide a kind of protected uh mode so that user get to enjoy the benefit and without have like

without having to worry about uh all these things and um yeah I think in the in the past we've seen that we've tried solving the issue using uh maybe some mathematical solutions or just based on social trust uh but um I think now uh maybe we can look at DE because it's uh it's actually changing the game. Uh I think in next slides you will see um like a lot of project using it. But now I'd like to just mention a few things maybe the also the key reasons people are choosing uh tees. Uh first of it is actually u um the performance because um a lot of things a lot of logics are kind of hidden behind the hardware it's inside those circuits and uh it's being

offloaded uh in hardware so that it can execute really fast. It's kind of the same logic that when you have um um uh if you offload some of ZK operations to um like circuit to hardware you will get a lot of performance gain but the story of TE here is uh these are really just special mode u made on top of CPUs uh or in a way that entire package of the hardware so that you could have uh some sort of isolations encryptions for encrypted memories you could have uh access control so that uh each trust domain is uh is not uh able to talk to each other. Uh I mean all these are really hardware primitives that you don't have to worry about. You could just uh really gain near native

performance because somewhere when you cross the trust boundary you still get a performance penalty. And second thing is on the um it's really um kind of controversial because uh um somehow it's becoming um alternative uh to other mathematical solutions or maybe a better word is to uh is uh complimentary right uh because uh if you choose hybrid solution um very often it's working better surprisingly better um and you you will get the benefit of both and also uh right now compared to a few years back. Um the technology is definitely more widely available uh on clouds um bare metals uh you could

easily get the TE machine running at your home. Uh actually um if it's possible um all your laptops would have this cutout functionality for example Macs but the unfortunate thing is they are not opening it up. they're not allowing people to u make like uh deployments to those uh secure chips but once they do it's actually going to be very powerful. Um then lastly the um I think it's also quite important to say that uh uh compared to a few years back nowadays you have uh VM based TEES you don't really have to worry about uh changing your code base making um kind of adaptions or making glue layers so that it will work with uh TEES um I

think based on our experience working with uh other projects uh they could really just uh focus on like shipping the code making the uh uh making it work in in the T environment and uh we will help them to take care of the attestations, take care of the verifications or even advise them on like making right choices on like security policies and stuff. Uh so this is I mean all these things uh kind of contributed to the adoptions of uh of tees. Uh but of course we have to be careful which is something um everyone's is trying to remind us of which is the uh assumptions or the security compromise you're you're trying to to make. um you you really have to trust the hardwares uh in terms of like all

the things right the manufacturer um like the the fabs and also uh the software packages the firmwares um like if it's VM based you probably have to trust the kernel as well bootloadader kernel um like even TPM modules uh but um I think um a good thing is um these are kind of part of the supply chain anyway uh because even if you do um um other technologies uh it's invaluable you have to have a way to you have to choose your base right you have to choose where is your foundation of the trust so if uh this is the uh state-of-the-art I think we can we can take it first then use it with a cure and also try to uh understand more and

and also like u there there has been like security experts working on fixing those issues there will be also more exciting development on new hardwares maybe it's open sourced maybe is uh fully audited so that you can uh like trust hardware just like you trust the code. So um here's actually uh slides I spent some time to put together. Uh um I intend to use logos but in the end I think text is more efficient so I can put more here but even though I couldn't uh like put everyone here so sorry for those uh who didn't make it to the slides. Uh you can see that a lot of rollers are now using tees. um it's it's probably not using it for the foundation of the security but it's using it as a

for example two FA solutions or as a way to um like uh increase uh security because uh strictly speaking using uh running things on TE is actually strictly better than not running it on TE right and also we see um um like flash bots uh really um leading on this um me space doing block buildings or even layer 2 block building the rollout boost uh framework and also uh we've seen um teams from uh like uh new construct they're doing the new um um orderflow layers try to uh compete with them and at interop uh there's protocols trying to um address those issues trying to make things faster um shorten the

confirmation time um wallet and key management I think these are uh people who really believe in hardware because they've been using it at the very beginning even at time it was just Intel SGX or Nitro Enclave which is uh way harder to work with and um of course recently um since last year uh there has been uh really a lot of development on verifiable AI based on um GPU TE um as of now it's it's probably just uh referring to the the one that in uh Nvidia has which is H100 or H200 series um and uh ZKVM uh you might be surprised that they're also using this for um for 2FA purpose or for uh private approving

because you don't want really let the uh uh prover node to know your input right so in those cases you could use te to to have some isolation to have some uh security uh and also web proof I think uh ts not tree is actually using um is running their notary server in in a te um and also lastly uh word id uh they're also um we're working with um trying to make the uh trying to let the uh run the MPC protocol uh initially in GPU but now u working on CPU as well. Uh so these are really um kind of surprising adoptions. Uh uh some of them are actually new compared to my talk at East Denver.

So um yeah um so also along the way we have some um u key patterns um observed uh for example um T is actually used as a more uh costefficient solutions or cost efficient to FA uh for those uh things um and building uh applications uh is becoming kind of straightforward as well. Many teams are even hiring engineers to do so. um you have um nowadays you have VM based DE which is more preferable because uh it's easier to work with and also um um we didn't see this coming because Nitro is also getting attentions uh people are using it maybe because of the uh existing

deals with AWS but that's also kind of a big part of the uh like developing your attack and and we've seen more complex security models being built uh people are trying to um um kind of um um let multi multiple parties have their code running inside the same TE so that they could work with each other or compete with each other. Um and also a very important key pattern is actually the onchain attestation which is a thing that we're working on. Um so is it this the kind of the concept behind this is really simple. you're you simply just take the code generated by all sorts of tees and put it on chain and um just verify it um using following

the same protocol that you would verify um at uh maybe at the offline environment. So we spend a lot of time um making the kind of port the code for example the Intel verifications uh into solidity which is the first step but the but after we've done this we realize also many like partners also help us to realize that it's too expensive because you have to uh process lot of data which includes uh some of the search some of the collaterals that comes together with the testation. So uh so in the end uh we provide the kind of alternative solutions we work with um Ziki VMs uh so that we could um kind of offload those

expensive solutions into a uh prover then onchain we just uh need to verify the u uh result uh which is more efficient and uh has less footprint down chain uh in the end I think very often you could achieve uh maybe many orders of magnitude improvement in terms of the cost of course you have to pay the cost of liquid proving but um I think uh conclusion is it's often like cheaper than just running everything on chain but again that's that means you are having additional dependency on zvm uh for many of the applications maybe you you still going to choose uh kind of native one and um um I'd like to also give a few

updates regarding our uh kind of open source libraries and some products X. So, uh this is actually the uh maybe the kind of state-of-the-art onchain testing libraries for Intel SGX and TDX. Uh it's uh support like I said solidity and ZK based attestations. Actually, there's been over 700K uh uh ZK attestations uh on AK verifications on chain and also it supports the uh v3 and v4 version. Uh v5 version is coming soon. uh we've spent time uh developing at and also getting the machine that support V5. Um also uh we're trying to add Solana support. Um and actually a funny story during the

development we we actually hit the uh the hip issue because uh the Solana program uh have a limit limit on the hip size. We have to find some work around it. Um and second thing is actually um um also maybe a highly wanted feature uh because people who work on the decap stuff uh is also um kind of be bothered by the all the uh collaterals. You don't really know where to find it. You don't really know how to update on chain. So we built this dashboard which is a new service we're going to release soon. Uh so this dashboard uh you could um easily track all these collaterals on chain and try to uh scope all the um FMS SPCs that your machines have and also uh trying to

uh see the all the activity logs to have some transparency. Uh so currently it's still in beta. Um so please reach out to us if you'd like to uh have a try on it. Uh this is some sneak peek of the uh kind of dashboard. uh you could see the uh like the ongoing monitoring and also the activity logs and also we will be uh providing functions um like automation so that those search will be renewed automatically um yeah and over here it's the uh some of the FM SPC stuff that you can control and what's next for us uh so we're actually trying to um like make more progress make the uh developer experience better we're doing a new uh

VM image that uh would support both Intel TDX and uh AMD. Uh so that as a developer you could just ship your code. You don't have to worry about the environment difference. We will take care of the difference and as well as the onchain attestations. So in the end you just pass data to your machines and you will really um uh get the uh result on chain. Also we have a new wiki uh launching uh catalog community effort with other TE projects. Uh all right. Uh and don't forget uh check out other TE talks at the ECC.

These are really good ones. Um happy um I think that's everything for today. Happy to take some questions. Thank you. Where do you store? Uh yeah. So the question is where do we store secret? So actually as the uh SDK developer, we don't really want to uh dictate on that. There are many different choices. Uh if it's short-term secret, it's better to just keep it in memory. If it's something that you really have to seal and put it on disk, then I would suggest maybe um like you you could either develop your own sealing and unsealing like um um like

SDKs or uh you could really uh use the um kind of the like disk encryption option provided by uh TPM because those are really transparent. You don't have to worry about that and it's uh it's kind of full disk encryption as well. Yeah, these are totally offchain. We don't really recommend putting stuff on chain because uh who knows if like quantum compute will decipher those things or not, right? That's it. Yeah. Um that'll be everything. Uh we probably don't have time for another one. Thanks.