Real-Time Proving (RTP) to Unify Ethereum - Orest Tarasiuk

Transcript

[Music] much so much introduction and so much non-crypto stuff being mentioned on a crypto stage that's quite uncommon. Uh yeah, I'm here to tell you about what I've been working on in the past couple of years now. H but first I would like to ask you a question. Who of you is uh familiar with the concept of tees? Hand up. Okay, maybe half of the audience. And who of you thinks that there is a sensible use case for tees? A use case that makes sense? Okay. And who of you thinks that TE's are great for everything and should be used

everywhere? Great. That's what we think too. We are T1. Has anyone heard of T1 before? Last question. All right. Cool. I'm happy to shed some light uh into what we are uh what we've been working on and the TLDDR is uh and uh let me unlock just briefly the TLDDR is uh we are working on um restoring composibility in the rollup ecosystem. Uh my name is Arist and uh as the intro mentioned um I used to be a uh an engineer at scroll um where I joined with the idea of using ZK to scale Ethereum. But what turned out to be the

case is that this mission only succeeded partially. Scroll and and other roll-ups managed to um create a system where transaction fees remain low even though more users join the system. But unfortunately they failed um to keep this other desirable property of blockchains which is composability which is the money Lego building block property in spite of growing users. So what happens is people are isolated into a given rollup. So we are trying to fix that and so could I have my uh slides please? Ah great. Uh yeah. Um and and so there has been talk in town which is X

of course about real time proving RTP becoming a reality uh via ZK. Um but this reality is still in my opinion years away in practice. And so I'm trying to um find ways of bringing about a real time proving reality today. And I would like to try to convince you why this makes sense. And so I'm sorry something. Could we do the extension? Maybe it's my computer. And so why are we doing this?

Well, we care about um having apps, having use cases, having things that people actually want to use blockchains for because we believe this will also in particular create a better seamless user experience having better better apps and those will lead to more users, more sensible use cases, not just airdrop uh farming in the first place. And so one second please. And how do we intend to do it?

Well, and we intend to be able to do it with real time proving which we define to mean there's many competing definitions. We define real time proving to be the ability to prove some off-chain component state. In our situation, it's called T1. the T1 uh chain to Ethereum DL1 within less than than a single Ethereum block. So that's 12 seconds on average. And so in order to achieve this today, we um apply TE trusted execution environments. Um but we uh add additional security on top of this hardware security guarantee with AVS and ZKP. And I'm happy to talk about this uh

more as as if as if as if as if as if as if as if as if as if as if as if as if as if as if we have time. So what does this mean in practice? Well, the ability to have real-time proving means that instead of the traditional 7day optimistic um finality um for for optimistic rollups or hours in practice for ZK rollups such as scroll or or zk sync or starkware, you get to be able to do something in this offchain component in this rollup and have um the results of this action for instance some tokens but it could be anything. It could be the result of a vote etc. and be conveyed to Ethereum DL1 within uh 12 seconds so 6

seconds on average depending on where in the slot time um it falls. Now with T1 we don't want to be yet another rollup the 17th standard to unify the previous 16. Instead, what we mean by proving T1 state to DL1 includes the ability of T1 to actually follow um to follow the state of other roll-ups such as those uh very ZK optimistic roll-ups that suffer from long finality within its own um infra within its own node and uh react to changes in other rollup state and also enact enact changes in other rollup

state all facilitated via this secured um infrastructure as part of its own state. And so this state transition will be um provable to Ethereum in real time as well. Um and there is of course um the necessity to wait out or alleviate the risk of reorgs in the other rollups. So there's a bit of a a penalty. We estimate this would on average take two Ethereum blocks. Now what's the point? Well, the point is to solve the fragmentation issue that remains. And so we've had a couple of learnings since uh we started doing this early last year full-time and

that is first of all the market seems to be favoring good UX. Unfortunately, people don't seem to care about security as much um as uh o OG nerds like me would like them to. So, that's one thing. The other thing, of course, and that's also in my definition UX. People care about fees. People care about not having to care about what slippage to set and how a uh sandwich attack might uh get them and uh what sort of front running protection they need. they just want to have the one ETH sold for the whatever Google tells them uh USD amount it's

worth. Uh second uh a second turning is multi-chain is uh here and it's here to stay. We believe that uh people need to well ideally um developers wouldn't need to build for for a multi-chain fragmented reality but currently they do and uh so we believe there's a big um potential in abstracting away this new reality of a fragmented and and multi-chain um world towards DAB developers so that we can get back to this original goal of enabling better bet better apps and then um one and a half years

ago we used to be quite contrarian with a couple of bets we've been making. So for instance I used to um believe and and and I still do uh that um shared sequencing not be feasible. I remember in uh Bogotaa the defcon um had had a side event hosted by scroll and espresso. Espresso soon after that became a shared sequencer. And I was asking myself, well, if even like people who have like so many commonalities and and connections and relationships for some reason for years don't manage to join forces and the rollup doesn't end up being sharedly sequenced with other

rollups. How can we even hope for the big rollups with uh billions of uh total value secured? So I mean a basin and optimism to ever opt in and give up the uh the the power the uh flexibility the autonomy they have via opting into shared sequencing. So we believe shared sequencing will not be um politically feasible and instead we believe that it makes sense to have some sort of optin free like um a system that doesn't require an optin in order to still be composable and this is made possible via real-time proving. Another bet that uh

we made and that used to be quite contrarian and I think it's still relatively contrarian is that the ecosystem need synchronous composability and by synchronous people mean well I want to be able to sell my uh ETH for USDC on arbitum use the result of that if successful trade in order to take out some flash loan on scroll and I want to with with the amount of uh with the output amount do something like take out a a position on uh base and I want these things to happen in synchrony meaning like unfortunately the computer science

um implication is this means that the same entity must have full power over all three of these rollups all three of these systems such that they'd be able to guarantee synchrony So we believe this is not feasible and also we believe it doesn't make sense and like my personal take on this is most things in the world are local like I hear someone is like sneezing here. I I see it's like rainy or I I I feel it's warm and it's very very local. Like we don't need this like worldwide ledger to have to basically be paying like in transaction fees for the fact that the

fact that it's raining here and I'm deciding to go out or not depends on the fact that it's raining in all the other spots on on Earth. Like this is not needed. like it might be cool and make things a bit more elegant and easier for the programmer uh but it's not worth um it's it's not a trade-off worth taking and so yeah instead we believe in fast but asynchronous composability asynchrony in in in in the composability meaning there's for instance an entity like T1 able to follow other areas of the world and selectively look at what points of interests there might be and allow the developer to react to that but

only in a callback based setup. So only in a way where this other system might not behave as expected. So we need to take that into consideration. So how do we achie do we achieve that and what does it mean if we say well tees are not great for everything and we want to secure them well we mean specifically the fact that there's certain security budgets or attack cost thresholds to different uh threat models and so in the case of T1 we start with TE proofs so that's hardware security um this is the box on the top and we do

this well aware of the fact that you can exploit TEES at some um cost uh point. So maybe you could say for for tees this might be 1 million bucks in order to be able to have your TE that you control as a node operator do something that it's that it's code would not have allowed it to. So we don't want to be only bound to one million bucks of value secured, right? Um so what we do is we let many people run TE nodes and we make sure that even those by their nature asynchronous behavior uh steps or or items such as following other nodes be made

deterministic and then we can actually require consensus among TEES um via determinist deterministic re-execution and this thing because it's deter ministic we further uh secure with uh as um so that's like a restaking system basically an insurance um where if some actor manages to break into the TE and then have it attest to or like sign off on something incorrect this will in the aftermath be um attributable via data on chain and therefore will this entity be slashable and this slashstake will be

redirectable to the to the victim. But this again you could say has its limits as well. So what about this restake stake like how do we attract it? We can we need to generate yield and all that. So maybe we will have a billion in rest stake. Now what if aim is 15 billion TVs? How can we ever hope to be like a big player if we are bound by 1 billion? Because if we secure 10 billion, an attacker could just accept that they would um even though they they steal well they could steal 10 billion maybe and they would accept that they would taken away um maybe 1 billion,

it's still a good rational unfortunately decision to attack the network. And so towards that goal we apply what we call bespoke ZKP and I I just mentioned how how ZKP is slow and expensive. Um but uh it does make sense to apply it under certain circumstances. there is huge improvements being being made and in particular if you don't have this strict um ambition or strict criterion of requiring your ZKP to be produced within a very short time span you are able to relax um the cost like the budget very much and so in our situation what we do

is we keep track of the value at risk so for instance let's say this um 1 billion um dollars worth of tokens in our bridges and then someone wants to withdraw some some USD USDC we keep track of that and as the value like the accumulated value at risk that for instance has been withdrawn approaches the rest stake so let's say uh half a billion we incentivize the creation of an additional proof, the ZKP proof for all the transitions since the last ZK proof. And as the uh like if ever the

value at risk where to in a given block exceed the cryptoeconomic security budget, the AVS budget, we would then actually under those extreme circumstances hold finalizing on deal one and require as a hard um requirement, the provision of a ZKP. And so this way once a ZKP is provided, are we able to basically reset the AVS uh cryptoeconomic security budget because we know there's also a cryptographic guarantee that there been that there was no fraud, that there was no misdemeanor on the TE operator part and and and the consensus. And so we expect to have to

require zkaps very seldom only. Okay. So this has some more advantages like this infrastructure with tees and and as and bespoke zkap in that we are able to also surf alt l1s. You could completely envision having not just arbitrum scroll be followed within the T T1 node but also Salana or whatever else you have and expose even different um differently valued chains as um kind of oracle subnets to the T1 um DAP

developer coding uh the the DAP and solidity and you could parame parameterize how much security you want a certain subnet, like a certain arcane chain to have versus maybe the the big uh very like high TVS ones. And so where are we now? We've uh just launched our second Devet. So you can actually take this first security layer for a spin today. You can go to portal.t1 T1 no dev I think it's devnet.t1protocol.com and you can see how whatever you do um in the bridge

gets uh bridged almost instantly including the withdrawals um this is again just the TE proofs um layer and you can also deploy your your DAP there and take the EVM chain for a spin. Now we've had some quite some uh new learnings about TEES as we deployed the DevNet as in for instance the ETH global trifecta hackathon turned out to position TE on the same level of hype I guess as ZK and AI which is very cool to see. I think there's great potentials to be had there. Uh we also had a lot of uh yeah users and traction on the devet and

I was sure it must have been some bots and hardcoded entities but then we upgraded the devet everything was completely like fresh and it seemed like people actually go and like use the the apps and it's real people. So that's really cool to see uh for our team. Now why are we doing this again? Well, it was about dabs, right? about making um UX more smooth and in the end attracting more users. Well, so there's three categories of DAPs that we see that are of particular of of of special interest. First, and this is our um most advanced PC right now, uh 7683 style um intents can be made a lot more efficient

with something like T1. Second, uh we see a lot of potential for bridgeless crosschain defy applications such as um crosschain collateral accounts. And third, um, RTP realtime improving also unlocks, um, approaches such as a shared liquidity layer and, uh, specifically the ability to transact uh across um different chains in in this like unified way, treating liquidity as one. So maybe let's go super briefly over the intense use case. We don't have that much time for all of the use cases

um because it's the furthest one. We actually have uh uh yeah if you go to our devet portal you can take the intents bridge for a spin as well. The idea with intents is well um we have a user Alice. Alice has some 10 USDC on optimism and she wants to have at least 9.99 USDC on arbitrum and she um expresses this intention as what we call a 7683 um formalized intent and then such an intent may be uh yeah put on chain on on on the source chain um and uh the 10 bucks that Alice

is willing to give up on the source chain in exchange for the hope of getting those 9.99 on the target. She would be escrowing on um on the source chain and the 7683 escrow contract. And upon seeing this there's um basically a market situation where anyone uh could find hey she wants to have at least 9.99 on arbitum and she's willing to give me 10 on optimism so there's some arbitrage or some margin potential. I'm going to go ahead and uh send her uh at least the required amount on the target and at

some point in the future will the escro contract on the source chain learn about this fact and upon learning um about this it will release the funds to the solver. So this is basically the idea. This results in uh very this is basically what you do when you go to a cross or or similar and you want to bridge a small amount. You get pretty good rates and you get your money almost instantly. Why? Because under the hood the solver keeps funds on different chains and they wait for people to place intents in order to fill them in exchange for the small fee and every now and then they rebalance the portfolio.

If for instance a lot of users flow out of a given chain, they would need to actually counter that. And so now there was this little caveat um this escrow um yeah like that escrow contract on optimism needs to learn about the fact that this 9.99 transaction on another chain happened and this is difficult because we need crosschain capabilities for this. What happens nowadays is usually there's some sort of optimistic angle where um there's a maybe one hour delay for during which people may challenge like solvers um may

challenge some some statements about the other chain but these uh systems work in a pretty um yeah centralized and trusted um way and yet they are still uh suffering from this long delay of 60 minutes. While in a system like T1, you could lower this to below 1 minute. So that's like 60 times faster. And what this means for the user because again we care about the user. What this means for Alice here is that because the solver will be able to turn around the 1 million USDC on arbitragement optimism 60 times faster. they will be able to

offer Alice a better rate. So maybe instead of 9.99 they will give her 9.995. And so in the end this is good for the user. This uh leads to a more efficient market. So I'm going to skip the other uh use cases in the interest of time and uh yeah I'm happy to take questions uh in the last couple of minutes and also I encourage you guys to hit me up if you're interested in building um in a world where fragmentation is no longer a necessity. Uh and also if you have any questions after the talk I'm happy to take them um async as well. So thanks a lot or you have had a wonderful journey

in a very short span of time and I hope to have a good journey along with that and I think we can just take one question because we are running late. If you have any questions just feel free to ask him. Um what decides on the actual threshold when jumping the defense strategies going from TE to toss to the actual ZK? Oh yeah that's a cool question. So when it comes to the TEES, so I think you are basically talking about the layered security um approach with the three boxes and uh so the idea with just the E proofs is this like this is a very low

bar, right? If you decide to render the system permissionless, it's like relatively certain that once the value approaches a million dollars, you will get attacked because it's just rational. So you should not do that unless you either also implement too some sort of consensus and ideally consensus where you can hope to attract sufficient stake because you need to have people before they participate to lock up some money and this money remain locked up even as they stop participating for a couple of days. So that if it turns out after the

fact that they were cheating, you can still take away from the SL uh slash stake. Uh or what you can also do and this is our current approach. You don't render the TE uh proof only secured secured system permissionless. So you only allow trusted entities to run and and participate. And this way you basically prepare for the remainder of of of the uh security infrastructure without risking an expert. So this is a training wheel approach. Now how to go from two to three? This is easy like this is in theory easy because you have a very clear number next to this restate stake. But it's actually not that easy

because of two things. First the rstake it could be some tokens and those tokens could have high fluctuations in value like I token second and that's a lot harder your value at risk like your value in that you are securing the value at risk in your system it's hard to quantify so it's easy if you have USDC but once you have crypto assets it becomes volatile but then once you have NFTs like you can't restore like give like have an insurance for an NFT because an NFD is n like nonfgeible. So you can't have someone steal it and the insurer will give uh the NFT back. You

just can have uh money, right? And then um there's also inher even more inherently unquantifiable value transfers such as passing the message that some DAO governance decided to change some uh system parameters. Cool. So I guess we all agree that bespoke zks are the way. Uh so how would the T1 make sense when the Oh sorry you can I'm happy to uh talk after right right after. Yeah. Thanks a lot. Okay.

Thank you guys. [Music]