[Music] So without further ado, let's welcome Orus to tell you all about real time proving. Please give him a round of applause. Thank you so much, Karthik. Thank you, Jacob, and all the crew for having me. Super thrilled to be here and uh super cool to see and and hear all of the founder support talk and uh thinking about what we need in terms of the soft components maybe and that might lead to broader adoption.
I'm here to basically give you the other end of that bridge of that stick and that is what we are still missing in terms of infra in terms of protocol. So I would like to tell you about real time proving and real time proving has been somewhat of a news on Twitter lately. Um however I'm here to uh come and uh try to convince you that what we care about as an ecosystem is bridging the gaps between the different rollups in Ethereum land. is specifically composability between the different um islands to which maybe some people are doing a great job convincing devs to deploy to on say base um and and then there's maybe the oins of the world deploying the the game to some other chain and now how do we make those um talk to one another and I want to make that possible today but with the vision of actually uh creating like giving tools to create better apps apps that would hopefully um lead to better and and more seamless user experience. And by user experience, I mean also the ability for the user not to have to bother whether someone else that they want to interact with happens to live on the same chain or not in order to in the end reach more users and uh and reflect this other end of the spectrum.
So maybe be before before we start, who of you knows what a TE is, trusted execution environment? Most people. Wow. Who of you thinks that there are some sensible, rational, good use cases for TEES? Almost the same people.
Now, who of you thinks TEES should be used everywhere and all of the use cases make sense? One guy. Okay. So, uh we will not be friends because I do not think uh that is true. However, at T1 we are using TEES in a way that we hope um makes for the best tradeoff in terms of security and uh performance.
Um and we try to combine them with cryptoeconomic security and ZKP in order to uh fix the Ethereum fragmentation problem that rollups led to. And the reason for that is myself I'm a computer scientist and uh the last couple of years before T1 I spent at scroll with the idea of uh trying to fix um the scalability problem that Ethereum was facing. And by that I mean as a computer scientist creating a system or changing the system towards one where even though you might be adding more users, more traffic, more interest, uh more volume, you would keep the desirable properties of this system. In this case, you would keep the property of low fees and also the property of having those money legal um composibility features. So the ability for one DAP to talk to another seamlessly.
And so at scroll um I observed how ZK rollups managed to fix the first bit of scalability getting fees to remain low. You can see that with L2s but unfortunately did not provide on the other part of the promise which is keeping composibility intact. So let's see how we could potentially fix that today. By real-time proving, what do I mean? Well, I mean the ability to prove the state of some off-chain component, for instance, a rollup, for instance, T1 towards the L1 in less than a single Ethereum L1 block time, currently 12 seconds.
And this enables certain properties that we can talk about soon. Um, now in T1's case, T1 state actually is not just an intrinsic system. It depends it is allowed to depend on the state of other rollups such as scroll arbitum and base. So this makes it for um a composable um system where within the T1 node and we follow other rollups and give the developer the ability once they've been through uh the the training and the shiping and whatnot to actually use Solidity to interact with another DAP living on another rollup on another L2 and react in an asynchronous way to whatever man yeah turned out to uh happen with the request and all of this is uh you can think about basically as a programmable interop layout a programmable uh bridge with its own block space. Now what uh in terms of uh values let's touch base on the 12 seconds when we talk about block um like finality um what we are used to is arbitums and optimism 7-day um finality window due to the optimistic challenge period.
This is something that you would naively do if you were to have the result of your game on Avatum become some sort of input on DL1. You would need to wait for 7 days for this result to actually become final on L1. Now for ZK rollups, we are talking about hours. So a lot better, but still not exactly what what users need and what developers hope to be able to use. So that's the 12 second threshold.
Why 12 second? Well, because Ethereum's block time is 12 seconds. So you can't go faster until, of course, um Ethereum decides to to manages to shorten that block time. The ability for a system such as T1 to follow other rollups and have an ability to realtime improve towards Z1 makes for this additional step where within up to two Ethereum blocks, a developer would be able to react to whatever happened in this arbitum game and maybe use that output as input to a swap or whatever on scroll and then depending on what happened with that trade do something on create another roll up. All of this with the point of solving the fragmentation issue like I outlined earlier.
Now, we've had a couple of learnings since we launched our early DevNets. One of them is the market seems to be favoring UX and this is in particular in the opposition of security at scroll and also other roll-ups. Um in the early days especially people thought well users will care about security. We need to build this system in a way that will withstand the third world war scenario. We need to plan even the L1 itself such that we not only be able to scale it 10x but that we see a path towards scaling it to 100x all without sacrificing security and and decentralization.
And it seems unfortunately people are not like that most of them. And so this is a a learning that we want to embrace um towards a more pragmatic approach. Second, people have been talking about multi-chain becoming the future at some point. Um we we see multi-chainers now. We see users go and uh transact in different chains and they use an insecure multi-IG bridges to make that somewhat acceptable somewhat bearable in terms of UX and this fragmentation we expect only to grow and that also means that it's going to be a political lobbying deed to get those different players different uh very yeah different types of of rollups to cooperate and settle on a common standard.
And so because of that it is that uh I believe we need to work on systems that do not require the optin the active cooperation of uh the chains out there. And finally, we've been making some bets early on, maybe early 204, 2024, that used to be quite contrarian. And um I would argue they are less of contrarian bets nowadays, such as um betting on composables um on on synchronous composability used to be a big thing and I think for many people still is with base rollups and native roll-ups and a shared sequencer. And I recall in uh Bogota for Defcon there was an event organized by Scroll and Espresso even before Espresso um focused on on being a shared sequencer and yet in spite of the close connections and a lot of relationship building. It doesn't seem anywhere near that we would have the big rollups optin and and sacrifice the autonomy and and flexibility and ultimately also power and potentially monetization avenues by doing shared sequencing.
And that means unfortunately from a technical perspective that we can't hope for this elegant and and visually aesthetically pleasing to the academic mind. um synchronous composability world and we must work towards a a asynchronous world world with fast asynchrony with a short latency between the steps. The other thing being real time proving um we we see out there that even ZK is becoming faster. It's in my opinion again a contrarian bet um a couple of years away from hitting production in a permissionless um way and uh for proper block gas limits but we are seeing this is becoming a thing and a real time proving especially sped up with the help of dees could indeed make fast asynchronous composibility um possible today. Now when it comes to TE secured with crypto economy and uh ZKT what does this mean?
Well, we know that tees have the limits. Um, maybe at a million dollar um of price point, could you basically have a node that you operate that contains a TE broken into by means of some microscopic um interventions and uh have this TE sign off on something that the source code that it's running would not have been expected to sign off on. And so it's a bad idea to use TEES for integrity proofs for a rollup um without any additional um security guarantees or security measures because once you hit a certain total value secured threshold, it would become rational for an attacker for for a malicious attacker to actually break into the TE and steal the TVS the total value secured. So in order to fix that um we propose a system where following other nodes is made deterministic by for instance not asking hey give me the current uh yield on a on on arbitum and instead for by asking hey give me the yield on arbitum a at this block height and uh if there's potentially non intrinsically deterministic compute. You could introduce determinism via rounding for instance.
And this way what you can do all of a sudden which you wouldn't be able to do with privacy TE setups is you can attribute faults. So you can after the fact of someone having provided an incorrect state transition um you can see oh this guy must have broken into the TE or found a bug or whatn not and that done something uh wrong. And so what you can design as a system is um rep you can have multiple people run multiple tees that are expected to arrive at the same result via determinism and run consensus among those TE uh node operators and then you can bootstrap this effectively validator set with a significant stake by means of restaking such as So then what what could happen for funible um transfers at least is that an attacker might be able to break into a sufficient quorum of TEES let's say one/ird for Byzantine fault tolerant systems and uh sign off on something that would allow them to steal your tokens on DL1. and however they would lose the the stake and the victim would be able to get reimbursed from that stake. Now, how about we look at uh L2B and see what value secured there is for Arbitrum?
Well, it's 15 billion. Can we hope to be able to attract 15 billion of free stake stake? Maybe, but better not to have to. And so in order to not have this glass ceiling, what we propose is an additional precaution that I call the bespoke ZKP mechanism which would keep track of the value at risk. For instance, fungeible token transfers outside like out of your bridge, accumulate that and as it approaches the security budget threshold, you would incentivize the creation of a zero knowledge proof proof um that would attest to the correct execution up until this point.
Um and once you do get such a ZKP submitted to the bridge, would you be able to uh safely reset the value address counter and thus never have to final stop finalizing the chain but also not be bound by the security budget. And then of course there will be the corner case of someone withdrawing a huge amount at once. And in this case, um, I would make an exception and have my L1 bridge stop finalization until a ZKP is provided, um, on demand. A cool feature of running TEES and, uh, having nodes follow other chains within a TE is that you could serve alt L1's even. It doesn't have to be bound to L2s that share let's say uh a DA layer or maybe um at least settlement on the L1.
Um it is a bit trickier to support nonem chains because we basically have this ambition of allowing the solidity dev who yeah there's a lot of solidity devs probably so soon more to come and and we want them to be able to take their decks their game deploy it to something like T1 and then as they um as the product matures and they want to open up um to other ecosystems or tap into other ecosystems liquidity or users they would use additional pre-ompiles all on solidity level in order to do that and so doing that for nonem chains is a bit tricky but possible in theory finally I wanted to share that we have a devet life we actually launched two devet uh so far and uh you can literally take it for a spin and see how both depositing from ethereum sapoleia to t1 as well as going pack is near instantaneous. Um, we have a couple of PC's coming as well. We were also lucky to be part of ETH global trifecta a couple of months ago and we've seen a lot of submissions but also we were uh yeah I was very pleased as a former TE hater and computer science purist to see that tees are now considered no longer the bad boy but actually on par with the hype keywords of ZK and AI and I think that's very sensible. I I believe there is great potentials to be had there. So I was talking about better apps and better UX in order to have more users and actual value.
What would those be? We've been talking to potential partners and uh and developers and users and we see three classes of applications. Um I would like to mention maybe the first maybe the first class because we don't have that much time intents. This is uh a standard um of EIP7683 that's gaining traction in the Ethereum in Ethereum land which basically works the following. A user Alice has some funds on optimism, let's say 10 bucks, and she formalizes this intention of receiving at least 9.
99 USDC on arbitrum. This is what we call a 7683 intent. What happens and the formalization of this intent also includes putting the 10 bucks into an escrow on the source chain optimism. Now there's some party somewhere of of chain that we call the solver who will see this intent and go ahead and try to give Alice at least the required amount on Abbitum. So let's say 9.
99 USDC and then there's some sort of verification that this filled this 9.99 USDC transaction happened and it somehow makes its way back to the escrow contract on optimism which then releases the funds to the solver. And now you can see well there's this magic step settlement verification. How does this work? Well, we somehow need to convey a fact about a transaction on arbitum to optimism.
The naive way would be to just send an arbitrary message via the canonical bridge to DL1, wait for seven days and then read that message on um on optimism using the canonical bridge again and then release the funds. Means seven days of frozen funds for the solver. there's no way you would be able to get 9.99 bucks for this. So what happens nowadays is there's um permission systems where there's some sort of validators checking maybe within a currently quite commonly within a 60inut um period that the fill did indeed happen.
there's some sort of optimistic oracle system in place for this and upon the expiry of this window will the solver on optimism get the 10 bucks back. Now with a system like T1 you could very easily see how the 60 minute delay could be reduced to less than 1 minute. And what this means for you as a user might be not obvious because you wanted to have 9.99 but what uh um happens under the hood is the solver is able to turn around this money 60 times more and so they are able to offer you a lot more of a competitive uh bid for your money. This is why you should care even though this should be abstracted away from both the user and the developer.
Okay, that's it for today. Please let me know if you want to build on T1 if any of this speaks to you. And also if we have time for questions, I would love No, we don't no questions. So please find me after the talk or hit me up on Telegram or on X for any questions. Thank you so much guys.
[Music]
Automatic transcript — names and jargon may be misspelled.