Orest Tarasiuk I Unifying Ethereum via Real Time Proofs I t1 Protocol I Pragma San Francisco 2024

[Music] before our next talk I want to bring on our next speaker and we're going to talk about how we can use trusted execution environments to make rollups a lot more flexible and secure and do better signing and while we get set up here I'm going to introduce orus from T1 protocol and you're going to get to learn a lot of cool things about secure compute and faster transactions so please give orist a big round of applause I wanted to um see a quick show of hands how many people around here are familiar with the acronym te trusted execution environment okay like half of the audience that's interesting very cool and how many of you would uh be able to define the term RTP realtime proving anyone ah like barely a few hands I see okay cool interesting so thank you for um giving me this uh input I see our slides should be visible now so I wanted to give you a quick teaser into what we mean by realtime proving um and so um the problem I would like to address and and give give you a bit of guidance into is what I call the rollup fragmentation problem in ethereum um as you might know there is uh there has been this rollup scaling road map um ever since the early days of ethereum but most recently maybe three years ago something that has been on the agenda for for for many people for many researchers and for many projects so uh who of you knows is familiar with the rollup scaling road map okay also like maybe a third of the audience that sound that boats well Okay cool so let me tell you um about what I mean by uh the rollup fragmentation problem now we want to um basically give you a bit of an Outlook a bit of context into how the challenges that we are seeing today came to be the has been this issue maybe um in in the def Su very visible that um the transaction fees on the L1 of ethereum have been skyrocketing like as soon as a slight bit of Interest came to be um we noticed that the block space is limited and uh that the throughput is limited and this resulted in Market forces playing out and the transactions transaction fees going as high as though to make a simple swap cost 100 bucks now that is of course unbearable um and so what uh people started working on were rollups which is uh to say offchain components that take on the burden of executing some subset of the tasks of the transactions that people want to execute and then find a way to convince ethereum about the new state of this offchain component now there's basically two big uh ways how ethereum can be convinced the first one is called optimistic um rollups optimistic fraud proofs um and the other one is zero knowledge fraud Pro zero knowledge proofs now the problem with those is that an optimistic uh fraud um challenge period is required in order for an honest actor in the ecosystem to submit something that we call a challenge where an optimistic rollup may be rolled back to a previous state because there was indeed something um that should not have happened now because of cryptoeconomic uh reasons this is required to be relatively long like in our case like nowadays it's like seven days for most optimistic rollups um and with ZK rollups um there's actually a technical um and E economic challenge which is that coming up with this zero knowledge proof of computation is a couple of orders of magnitude uh slower and and more expensive than the native compute itself than reproducing the compute which is the default in L1 now um what this means in practice is that um arbitrum and optimism and Co have been around for a while and they have been able to attract a lot of usage and liquidity um but as soon as you put your eth or your usdc on such a rollup you are kind of stuck with it it's pretty hard to actually get out of it again um so for optimistic 7 days for ZK rollups nowadays this is on the order of hours um and and and it actually varies now um why this is that it's on the order of hours like some people would say well but there there's all of those advancements in zero knowledge proving and there's all of the uh work being done with A6 and Hardware acceleration and people like scroll my previous employer is promising us a finality of two minutes by the end of the year yeah some people are saying that and and yet nowadays if you go and look at uh at the Block Explorer you will see for instance um yeah the big ZK rollups will be submitting um zero knowledge proofs maybe once an hour um and uh this is still a burden for people like if you go and and Bridge your funds to a ZK evm rollup um you can't just do your Swap and use the resulting transactions outputs to take out a loan on another rollup you actually need to go back and Bridge and wait for an hour or two and hope that there's not going to be a problem with that and so my point is ethereum's rollup scaling road map has been successful to when it comes to scaling the transaction cost and speed what we are still missing though is scaling as in having this shared layer this shared system where we get to play with those Lego building blocks of Defi and whatnot that we that that ethereum actually used to promise and deliver a few years ago before the onset of usage came into play and so that is something that uh I'd like to talk about more like how can we fulfill this second part of what I call still scalability which is keeping those desirable properties of composability um whilst accepting more users and so how can we achieve composability how can we achieve this um Universal component the universal Network without sacrificing scalability the situation currently is that and most users even though there are those rollup Solutions around are not really using rollups and if you go by active users you will see well if we combine all of the top rollups I think six or seven um the only 13% of ethereum users active in in a month or so who would actually use rollups as well this is of course a limited analysis this does not include people who enter through a rollup first but this is the best we've got currently and so we want to uh fix that now how can we fix it well um there's something called real time proving that I mentioned before and now Real Time pro proving would be the ability to convince the underlying base layer such as ethereum L1 about the new state of an offchain component such as a ZK rollup in in in uh with a delay that's less than the delay of producing an ethereum block 12 seconds currently and so when people are talking about ZK getting fast um this is what the context is the context is coming up with a z zero knowledge proof of something comparable to an ethereum Block in a matter of few seconds and from that unfortunately unfortunately we are very far away currently but there is hope and the hope is we can make a form of realtime proving possible today and that hope is made possible via trusted execution environments now whenever you hear the word tees will you instantly see people like point you to sgx do fail and say well but uh te are inse secure and this is a very valid point um you are only as secure as uh the hardware that protects this private key material that the te is made to made to protect and it it has of course its uh limits just like zkp algorithms have the limits and bucks and um threat models and and so on and so what we need in a situation like ethereums is a system that's slightly more sophisticated unfortunately and that adds um layers of Defense on top of the te in a way that makes it possible to still leverage the super low latency that a te enables a te enables um coming up with a proof of Integrity Within uh negligible uh delay let's say milliseconds like it's maybe five from my benchmarks it's a 5% performance hit over native compute compare that to what like 100,000% of zkp but we want to combine that with additional layers of security um in order to not be limited by the cost that is needed in order to break into a te and so one way of doing that is uh adding in cryptoeconomic security um one idea to do that is to use St eth with uh a reaking solution such as uh AVS by igen layer and have some sort of um double Assurance where a parties involved in Computing those te Integrity proofs are also required to have uh opted in to be slashed under additional slash conditions and a further security um increasing measure uh that you can conceive is actually leaning on zkps but in a different way than uh we've been doing so far one idea just to um try to like work on on on our imagination would be well how about we only require a zero knowledge proof for things that EX for transactions that EX exceed the value that for instance the underlying AVS actively validated service by igen layer is secured up to so maybe we can have those three tiers of security leg number one te cost of breaking 1 million n then for stuff that's more important like more valuable we have AVS maybe the restate stake is 1 billion and then if someone actually does want to do this like two billion withdrawal they will not be able to do so without also submitting a zero knowledge proof on top of the other two security layers so that is basically an idea how we can still leverage um the the advantages of tees that have like this super low latency whilst securing ourselves against um attacks where the attacka is actually able to break into the te so now let us think about uh how we can get there how we can achieve a system like that we've refreshed a little bit of uh a user flow walk through and the diagram that you should be able to see now um and I'd like to walk you through the different roles and and layers there imagine you are a user um what you can do in this uh T1 proposal of ours is you can deposit your funds on ethereum L1 into the T1 deposit contract and then um almost instantly will T1 um become aware of that and once that's happened um can you just uh change your wallet um RPC and use our L2 as though it was any other L2 and that moment uh there's one novelty going on and that is that transaction that you will be sending to um T1 will be partially encrypted so certain fields for instance the limit order parameters or the direction of the swap will be encrypted to the public key of the te enabled workers but they will not go to the workers instead they will go to the sequencer AVS and those sequencers they will not be able to decrypt the entirety of your transaction however they will be able to order such partially encrypted transactions into a block and create this finalized block ordering next the uh AVS sequences will carry this finalized block um and and give it to the second AVS Type n T1 which is the worker AVS together with a proof of sequencing consensus now the second role the worker AVS these guys um they have obviously the private key connotated with the te worker P key and so they are able to decrypt the uh encrypted fields of the partially encrypted user transaction that the user originally shared with the sequences and this enables them to execute this block and come up with a new state including the new state route and so they are not able to change the ordering with within the block they are not able to extract me uh that way now those workers they will proceed to uh take this new state and uh also the uh transaction data together with the previously received uh sequencing consensus proof and they will put the execution proof next to it the execution proof being um a technically trivial ecdsa signature that comes with an overhead of negligible like 5% over native compute that's why this is actually possible in um sub ethereum block time now those ingredients are going to be making their way now to ethereum to the canonical Bridge um or to the ethereum da when it comes to the transaction data and In This Moment uh ethereum will be aware of the new will will verify of course the proofs and then once these pass the checks the ethereum canonical Bridge 41 will be aware of the new state of T1 and will therefore be willing to accept uh proofs from users that a given for instance withdrawal transaction was indeed part of this newly computed and uh and and and proven T1 State accepted by ethereum and this again is possible within a single ethereum block um blocks worth of delay 12 seconds and therefore the user is able to use the funds um almost instantly an additional um element here um that uh I hinted at um just briefly is this bspoke zkb spoke zero knowledge proof component that basically prevents an attacker who is as powerful as though to be able to control the underlying AVS uh stake from stealing more money than the AVS stake um budget itself um as in the um withdrawal that would touch a a higher amount than the AVS stake will not be accepted Ed by the ethereum canonical Bridge instantly um and instead the bridge will Halt and require a zero knowledge proof to resume operations this is to prevent um this very sophisticated attack and we expect this to only happen very rarely um now finally there's this cool feature of tees that you are able to also run full nodes tapping in into other rollups partner rollups such as it could be the ethereum it could be the arbitrum sequences and such a full note would be following the chain and therefore able to know for sure that no fraud is going on in a given block for a given optimistic uh rollup and therefore provide um T1 um apps with the ability to look into for instance arbitrum State and act upon it without having to wait for the sday um challenge period whilst giving this assurance that there is no fraud going on indeed so this is uh what we mean by partner rollups and uh how we envision expanding towards a cross chain um Vision soon and so this um is how we hope to be able to incrementally approach the this vision of uh what some people like to call the United chains of ethereum and now I would like to show you or try to show you if the demo gods are with us today a uh inaugural demo of our devet that our two founding Engineers KSS and V were so kind to prepare just two hours ago so let's see if that works um and let's see if we can make it uh happen what I'm going to do now is I will be showing you the interaction from a user's perspective and now let's assume of course like this is crypto so the user as a developer uh and so you will be using remix uh and let us assume that this contract that we prepared that is called counter. Soul right now um this could be any interaction on the T1 um Layer Two and so I have uh deployed the contract here you can see um it's called counter. soul and it has this very trivial logic of exposing an ability to increment a counter now this contract is deployed at the address um over here um 0x b4b blah blah blah and I'm able to connect my metamask I'm using the injected metamask provider with a preloaded account with a lot of eth um and I'm able to call this public method and I'm receiving um a response over here that I'm oh that I'm able to make bigger great so this is the current um state of this contract of this counter and in parallel given the fact we don't have a block Explorer deployed yet um I'm just running a simple Watcher function that monitors for the um state of T1 on our make belief um L1 so the state of the L2 as per the canonical Bridge deployed to something like ethereum and this is um refreshing every two seconds um right now you can see and this is refreshing continuously that our current state is this 9 4449 blah blah blah um hash and what I'm going to try and and and pray uh it works now is I'm going to increment this counter on this T1 native da I'm going to conf sign and confirm this transaction in my metamask connected to T T1 so that is an L2 it seems to have passed and now VOA you can see literally two seconds later the underlying Bas layer is updated dated and a new state um is accepted on this canonical Bridge contract which means that from this moment on anyone is able to come up to this canonical Bridge contract and have a proof in the hand how to get from a given transaction that they claim a spot of T1 and uh get to the state route that you can see over here okay so now finally I would like to call out to any builders that we might have around here and uh invite you to an exclusive private group with uh our founding engineers and and uh very early developers um in order to build with us um we will be very happy to support you we will be very happy to also discuss your needs and uh take your feedback so uh feel free to scan this QR code and uh join the group other than that uh feel free to follow us on X the handle is T1 protocol um and uh DMS are open thank you very much [Music]