Unifying Ethereum with real-time proofs, made possible today – thanks to TEEs - Orest Tarasiuk

hope I got that right thank you so much yeah not too bad not too bad yeah hi welcome everyone thanks for staying here at this very late hour on the second day of the conference not too bad maybe before I start who of you has uh um does um have a definition for what a te is like does te ring a bell with anyone trusted execution environment okay like a few people okay yeah so uh I'm here to try and convince you that certain things that are desirable in the long term we could incrementally achieve today if we uh settle for a tradeoff temporarily and so how can we unify ethereum um I'm going to talk about how we can reach something that we like to call realtime proofs RP today and so um the idea behind T1 is to basically um try and get to an incremental realtime proving system um that we can then incrementally have lean more and more on additional cryptographical Primitives such as zero knowledge as those progress so now let's talk about the uh rollup Centric road map for ethereum like um who of you knows what the rollup Centric road map is scaling road map one people 2 3 4 5 six okay so then you will probably have been told how the rollup Centric road map managed to scale ethereum and uh my point would be well we scaled the performance part of it we managed to get to as an ecosystem where we can have those roll up offchain components run at high transaction per second rates um and low user fees what we are missing though is composability we lost this desirable property of defi Lego building blocks where you could have um some money on on arbitrum a th000 bucks and you could do something with those th000 bucks um to a contract that lives on scroll you can't do that today now why can't you well when I was joining scroll um some two years ago early 2022 everyone thought ZK rollups were the answer ZK rollups were um an answer to composable scalability because people would be able to have a Dap live on ethereum Main net and look at the state of the zik rollup and therefore compose into it now this is hopefully going to happen at some point but what prevents us from having that luxury today of composing between scroll and arbitrum is that scroll um or any ZK rollup nowadays still needs minutes if not hours to actually come up with a zero knowledge proof of an ethereum block um and uh optimistic rollups of course need a way longer withdrawal challenge period the result of this and uh there's many thesis for how this came to be is that indeed quite few of active ethereum users use rollups our research um our quick analysis on on onchain data shows that it's roughly one in five ethereum users who are active on um on rollups and this is surprising one would think well if roll up scaled ethereum people would live on rollups and never have the need to even go on Main net and pay those extravagant fees and uh have all of those issues so um yeah we we are still getting there we still need to solve this and uh an hour ago there was a panel here a panel on how l2s are are not parasitic towards l1's so the L1 and there was a several thesis were were stated such as that rollups be TRS and how the scaling problem might be solved but for this tiny Aster risk of liquidity fragmentation and my point here is well we're actually quite far away from uh having solved scaling while liquidity remains fragmented and uh the fact that only one in five people use um rollups um is proof to that in my opinion some people would say well ZK is getting fast see there's some ZK ogs sitting in the audience here um and there's some uh people such as Justin Drake claiming that real time proving with ZK be coming tomorrow or the day after but let us ask ourselves what it what it would mean for ZK to be sufficiently fast now what does it mean to be real time proving to be proving ethereum blocks in real time like any uh guess from the audience like how fast do you need to be less than 200 Mills less than 200 milliseconds okay and how fast are we today few seconds oh we wish the answer was few seconds no right now uh we are on the order of magnitude of uh minutes to hours when it comes to proving something like an ethereum block so usually an L2 evm L2 uh block we don't need to go quite as slow I would argue as 200 milliseconds depending on how our friends at thef and at all fix timing issues timing games with me on Main net like on with respect to validators and the MV supply chain but the upper bound is the block time of main net ethereum 12 seconds right we need to be able to have someone transact on this offchain system say a ZK rollup do things that offchain system need needs to come to consensus about its state and then some entity some Prov needs to come up with a proof for the state transition from the previous state to the new state of the offchain system now this very thing needs to make it to ethereum validators who are proposing an next an next block um and time for them to actually still be um become included during the 12C interval so this is actually very fast and we are orders of magnitude away from this and this is in a world where um ZK rollups are paying a lot to actually um have this performance so how can we make this possible today how can we approach real time proving today now I used to be a vement opponent of trusting anything else than pure cryptography um and then I I realized well what is a better system a system where I need to rely on insecure Bridges with running off a multisig because I can't possibly wait to have my funds withdrawn from arbitrum if I want to trade on scroll for 7 Days uh or do I prefer to have um a te based security system ideally um reinforced with additional nonte defenses and myself I uh opened up to the idea of actually going with the L now I would like to try to convince you this may make sense but maybe before I do like to whom does this sound outrageous trusting a te with your funds trusting a te with your blockchain one person two three okay three and a half I'm with you yes I would never the problem with te is there's a certain like the common criticism will be but sgx is insecure but a week ago we had the zero day and uh if you are running a an a seven-year-old machine and you didn't apply the recommended counter measures and uh you also didn't upgrade your firmware then a cipher text of some secret keys will be revealed yeah not good not a terrible tragedy but still not good at all now how can we prevent this in a blockchain context where we want the te to be able to secure not a million bucks not 10 million but actually a very big amount of of of funds like obviously there will be a some sort of limit above which a St State actor will be able to take a microscope and pay some people to to uh get into your te I call this an increment real time proving how we can get there is start with a te and then apply additional measures additional defenses um in an incremental way and so the vision is again let us remind ourselves what we are after to reach this United States of ethereum um situation where the different rollups not only provide for low fees and high TPS but actually are able to OS now how we can get there is what we've been working on with with T1 protocol over the past half year or so and our suggestion is the following no laser poter here unfortunately so uh you'll need to bear with me now what my idea for incremental real time proving is to start with A system that uh is the te enhanced worker this is the entity that is executing blocks and producing new state roots and those State roots are making their way to um the ethereum um smart contract that only checks in its simplest form the ecdsa signature of the wh listed te entity but now you can think about measures how you can limit the maximum um damage that the 0x uh zero day vulnerability in the te might introduce one suggestion towards this goal is to have another role a validator this could well be a reaking um role an actively validated service that draws upon the cryptoeconomic security of ethereum stake and to avoid the bootstrapping like are you guys familiar with reaking how say igen layer Works anyone okay great so yeah this is how we no longer have to bootstrap a valid data set right we we get to tap into this vast um Economic Security but we don't want those people to actually have this big computational burden of having to execute every user transaction instead we impose upon them a simplified set of conditions that need to be checked and one idea for how to do that is we start with the user intent to do something to trade for instance at a limit now the user will encrypt this intent to the pup key of um of the T worker let's say let's say it's a single T worker later we can expand upon this and this Cipher text of the intent will then be put into an ordering by the validators by the AVS validators they will blindly um order such transaction um candidates so intents over here does this make sense to to you guys like who does this make sense to Okay cool so this is a counter measure towards having the te vulnerability and reorder transactions reorder intents once uh yeah once the intents reach the worker in here with this system we are already removing the ability for the T that's compromised to uh um to extract value to front run and back run users for instance now a second idea that I wanted to share with you is to have something that we started calling match proofs wherein upon the execution of the um intents that only the worker is able to um to decrypt and and execute will the worker share not only the the the new state of the world the new state of the rollup or or L2 system but also the plain texts of users intents and then will the validator be able to check whether the new state of the world um matches what the users originally intended so they will be able to check hey maybe the t- worker was compromised and instead of giving the user at least 4 us 4,000 usdc per e they actually gave them zero usdc and because they will be able to match those no longer encrypted intents with the outputs from the workers and there's a um there's a little asterisk here does anyone see a problem with this a missing piece well the the very idea behind the validator is that they must not have to trust the worker so they can't just receive the plain text of the user intents we actually need to enforce that the user when they originally um create the the cipher text also commit to the plain text for instance they hash it and publish that and only then will um the validator be able to check check whether the uh plain text of the user intent indeed was what the user originally came up with now this is an important consideration to continuously be making when working with tees we assume like we in a maximally adversarial situation we assume that the te be broken which by the way should probably be assumed for ZK and cryptography and so on as well like there's limits to what this secures as well um but if we assume um a t can be broken we we are able to actually prepare better for a situation where where these outputs um are not trusted we continuously treat anything that comes from this guy as not trustworthy and we only ever trust what the user signed with their private key does this make sense to you who who does this make sense to cool okay yeah that's not too bad now those different types of proofs we call them Integrity proof from the worker and the match proof from the validator alongside some subset of the transaction data would go to ethereum and some other subset of transaction data would go to an alternative da and this way we could have a system that is actually able to settle on ethereum on every ethereum block up to every ethereum block every 12 seconds and then there's additional ideas that you could consider to security Harden this further one idea I wanted to share at this point is we could either in the let's say in the um ethereum contract we could also look for certain situations that are suspicious we could assume that for some reason the validators actually are no longer trusted maybe there a b and igen layers contract so maybe maybe there was a sufficient RI and a zero day exploit in the te worker now what we could do is we could have horis zkp requirements we could have a system that actually stops the uh balance updates on Main net ethereum until if it detects too big an outflow of funds or a situation that is suspicious and then block on receiving a zero knowledge proof of the state transition this would slow down the system to what we are used to from ZK rollups um but we could uh play with the hyperparameters here we could we could dynamically adjust the aggressiveness of such a horis and we could also lean on and and and leverage zkp um acceleration and be more aggressive aggressive as we go or be more aggressive as as the tvl secured by this system grows any questions about this diagram yeah um okay there's but there's like still Meed capability here because if validator and worker collude uh they can work towards extracting additional value on the users cost you have so how did you address that so the question is well if I understand correctly hey but there's still collusion risk because the worker has the private like the private key that is able to decrypt the user intent and they could collude with the valid dator to finalize Block in a way that extracts MV by for instance front running the user is that adequate yeah that is a risk and remember this is a te so this guy they can't just go to the validate and collude they need to break the te first because what the software that the te is running does is wait it waits for a finalized block signed off by a valid data it can't just decrypt an arbitrary user intent that's not what the software does and because we have a te around it the the owner like the the operator of the te node can't just change the soft software so I feel like this is actually a good Synergy for what te make sense me could be maybe some th few thousand doar maybe like if there's huge market movement maybe it would be on the order of like tens or hundred of hundreds of thousands but you need to have broken the te right before it and be ready so I feel like this is a pretty decent tradeoff a pretty decent compromise that would make me sleep well enough do you do is that is that satisfactory it is a compromise of course of course like it's a suboptimal world that we live in sure sure this could happen and there's more that can be done like you can Envision for instance requiring a consensus of workers you could Envision requiring a consensus of workers that each are running a different vendor te so that the chance that an attacker be able to break Intel TDX Intel sgx AMD scvs SNP arm trust Zone and also have colluded with the validators that are actually validating this exact block is diminishing and you could think of additional ways of making this less likely um if you have ideas hit me up I'd be interested in learning uh in learning learning more any more questions about the design yeah what about mled or cryptographic proofs if they open what how this uh system could work work out this could you could you repeat please yeah what about mishandled uh um mistakes how they could pass through this system Mis mishandled proofs mishandled Pro proofs yeah what do you mean by that like um mistakes that happens in design or and could evolve the whole system so like smart contract box or or ZK circuit box sure like a risk that we have in any system that includes a smart contract is that the smart contract be buggy of course that could happen if we have a horis zkp system there could be a mistake like um yeah um problem with the ZK circuits yeah of course these are things that could still happen and a nice thing about running um systems that are considered sufficiently secured on themsel on their own in a te is that you make this a bit harder to exploit so an additional step one could take and some people some other companies are working on this is to take this entity as well the validator and put them in a te and maybe they get like a better yield or like some additional like inflow of uh of of uh volume because of that and you could also Envision putting a ZK Prova inside the te so what this takes away is the ability to easily once you've spotted back in a zik circuit um leverage it like you also need to then um control the te so this is a an an approach that's known as security or defense at depth where you have additional like several layers of security each of uh Each of which adds to the security rather than dividing it any more questions this is my last like content slide so if you have any questions about the presentation Now's the Time okay H go ahead sorry Chris in this schema is the uh worker is it just doing the state transition function or is it also keeping state so in this situation uh it's not defined whether the worker be stateful or stateless both options are in possible for um pragmatic reasons us at T1 we are starting with a stateful worker just to be able to test uh sooner uh but I Envision having a stateless system yeah because in a stateful worker if there is a need to roll back because of changes in the ethereum like how do you do it like is it like rigged in that case I think roll backs are very tricky and another thing that makes stateless workers more attractive is indeed multivendor tees like if you have multiple vendors and you want to not only round robin but you want to somehow distribute this security Duty a stateless system would indeed be desirable yeah okay thank you any more questions okay if there's no more questions what I would of course encourage you to check out is our new website we've just launched the website because of the uh warsa blockchain week it's T1 protocol.com or you can just join us we are we are hiring we are hiring for founding engineering roles um and uh I would be Keen to learn about whatever questions or ideas you might have after the talk as well feel free to uh hit me up on Twitter DM open at Orest ta o r EST ta other than that thank you so much for your time [Applause]