# Real-Time Proving (RTP) to Unify Ethereum | Orest Tarasiuk | ETHWarsaw [4] - Speakers: Orest Tarasiuk - Channel: [ETH Warsaw](https://streameth.org/eth-warsaw) - Date: 2025-11-09 - Duration: 37:05 - Watch: https://streameth.org/watch/yt-c7N9BkfazxM - YouTube: https://www.youtube.com/watch?v=c7N9BkfazxM ## Description Orest Tarasiuk from T1 Protocol is a computer scientist building the cross-chain infrastructure layer that brings real-time proving and programmability to Ethereum, solving EVM fragmentation. This is how every application becomes cross-chain by default. 🎥 Recorded at ETHWarsaw 2025 Follow ETHWarsaw on social media for the latest updates! X (Twitter): https://x.com/ETHWarsaw LinkedIn: https://www.linkedin.com/company/ethwarsaw Telegram chat: https://t.me/joinethwarsaw ## Transcript Welcome everyone. Thank you so much for staying up this late. It's the last talk of the day. So I appreciate that very much. Um I'm going to talk to you about real time proving but not just for the L1. Real time proving for the L1 and existing rollups. What I would like to cover most of all is uh this very situation we find ourselves in as a ecosystem as Ethereum community that is basically a fallout or a result of a longstanding um idea of rollups um or sorry of blockchains willing to be a decentralized system. But at the same time as they become popular and and successful needing to scale and those two features those two properties seem to be in a bit of a conflict and so years ago people at the Ethereum foundation came up with the idea of the rollup ccentric road map. That rollup ccentric road map was basically hey let us have um zones of execution that run in parallel to Ethereum DL1 and every now and then settle back to Ethereum and the idea was well we use some sort of proving to convince the L1 about what's happening in the zones such that we retain the ability to compose we retain the ability of having those money legos that had made Ethereum so successful in the first place. Meaning a dev can deploy a DAP that maybe allows is a is a token ERC20 and anyone may create another DAP that is actually a swap letting those tokens to be traded and yet another dev deploy yet another DAP that takes results of such swaps and gives you some sort of loan against them as collateral. having those three um devs that never need to have met, never need to even have known about one another um have composibility like use each other's um input outputs as as if it was small command line utilities in the Linux paradigm is what I mean by composability and that um was supposed to be kept intact in spite of rollups with proving But what turned out is that we ended up in a world with big rollups be having become islands having become separate entities effectively where users can't easily um interact between them and so I would like to present to you an approach that we take at T1 towards merging those islands of liquidity those islands of users and those effectively independent blockchains almost into a world where you can restore composability um among them. Why do we even care about this? Let's go back to first principles. Well, I care about uh blockchains and I like the uh the ideals and the ethos behind um Ethereum specifically a lot. And yet we also need to care about um being able to provide good apps and good apps are in the end what the block space is for. And what also leads then to a good seamless user experience and that leads to more users and more demand for block space in the first place and lets us develop those block spaces forward and compete with with things such as web web two apps uh web two apps. And so what I would like to um describe with a bit more context to you is uh real time proving um in the context of programmability using real time proving to mean the ability for an off-chain component such as a rollup such as T1 to convince the chain let's say the L1 Ethereum chain about its new state in a with a latency that's low enough to um not be noticeable on the L1. So effectively current L1 block time is 12 seconds. This means if your offchain component is able to convince the L1 about its new state within um 12 seconds that feels like instant with respect to the L1 stick. And the other property is programmability. What I care about very much and what enables composability is not just the ability to prove a a component state fast. It's also the ability to express in code what should happen, what you want to happen depending on what the offchain component says does and what the L1 says does and maybe um then take that and again program something outside of the chain. This is what I mean by programmability. So yeah, the goal is to reenable the money legos but now in a crosschain paradigm. So how can we do this? How do RTP realtime proving and programmability come together? Well, think about it as um there's this status quo. We have optimistic roll-ups that take seven days to finalize the state towards Z1 and ZK rollups that take maybe an hour or a few. And so you can compose and you can program with those, but it takes a long delay. So you can't effectively have this original token that's living on optimism mainet be used on a a swap that's living on scroll um rollup mainet and then use the result of the swap that you did in uh um a lending market on starkware all in a single step or something that feels like a single user interaction. Now if you add real time proving um you you can effectively get that feel of instant being instantaneous. But the magic happens if this real time proofed system, real time proofed offchain system, the T1 rollup in this case is able to also interact with those other pre-existing rollups where we have those billions of uh value secured and users and and and valuable DAPs. And so how you can do that is um in the case of T1 um we are running trusted execution environments in our nodes that are following those individual rollups sequences trying to keep up with the current state and uh trusting and in the sequencer confirmation and expose and they expose the ability to call into those rollups as though they were those rollups users to DAPs living in this T1 block space. So what this means is the TE is basically acting on the user's behalf as um as though it was a consumer of the other pre-existing rollups block space and this acting on a user's behalf is codified in a programmable way. So a DAP that lives on T1 may um encode some behavior depending on the other rollups. This we hope is one way of solving the fragmentation problem that we see today. Now there's some bets and same some hypothesis that I'm um assuming here. So for instance what you cannot have in a world where where where people use uh yeah basically in our world is shared sequencing. Um in order to have shared sequencing the big incumbent rollups such as arbitrum and zik sync etc would need to opt in and give up the autonomy to um at least partially block build for their rollup. However, this is a strict necessity for the um synchronous composability property. So this ideal of being able to in a single transaction know for certain that the ERC20 living on rollup A be minted and that the swap living on rollup B against this newly minted ERC20 be successful and yield some amount of tokens and that the uh lending transaction on rollup C using the swap tokens um succeeds. as well. Like you can only have the certainty and and and you can only promise the user what exactly the state of the world the the the states of the rollups um contained will be if you are sequencing as a monopoly player in the first place for that period. So yeah, this is something we sacrifice on this altar and instead um in order to in my opinion be pragmatic and and and realistic aim for asynchronous composability but with fast like low latency um turnaround times. So think callbacks, think the ERC20 gets minted on rollup A. Once that's successful, we are talking rollups. So maybe a second of block time delay later a call back gets called on that rollup into T1 and T1 proceeds with the execution from there going to roll up B and asking rollup B to run a swap etc. Okay, so why do we even care about this? Again, let's have a look at a couple of uh sample applications that thrive in a cross-chain composible ecosystem. So first of all we can have you can think about vanilla applications where you basically in a world like this are able to take what you have what what you used to have your your solidity smart um contract and put it on um some special block space such as T1 and you get to experience like the custom environment etc. Um um however if if this is a T1 system you also then get access to the liquidity in other chains. So from your smart uh contract you can add um the call into T1 native pre-ompiles or or um op codes that lets you act on um your users behalf on other rollups and uh react to a call back upon a successful call into such rollup. Moreover, you get to share users. So users living on base are able to have their tokens. For instance, if if if this is a lending market situation, their tokens are actually more attractive and and and uh y and f they create more yield for them if they are used by a larger network which is an like a synergy if uh other rollups are enabled to interact with uh your users's home rollup in the first place. And yeah, generally better UX where the front end could abstract away from the user the fact whether the yielding um yield bearing token position is living on rollup A or B or C. They could literally just say, "Hey, I have 10,000 USDC. Um, I trust the Aves and the compounds on these five rollups. Just move it wherever the yield is the highest and I don't want want to know about it." So, where is this uh whole thing now? Well, we actually have a test net life um that we call the proof of read test net where any developer is able to um request um on base or on arbitum that a fact like some um red data from the other rollup be brought to their rollup. What this enables for instance what we are using this as a demo application is very fast um ERC7683 repayment to solvers. ESC7683 is the idea of formalized intents where a user wants to have funds on uh token B but they have funds on A and so they ask someone hey please give me five ETH on B and uh and in exchange I'm putting in an escro contract five ETH plus some small fee on token A. Now the generala use case the general situation nowadays is that such a solver saying okay I'm fronting those funds and now I am stuck with funds on this other chain needs to um unlock the escro funds with some sort of proof that they did indeed fill the user's demand the user's intent on the foreign chain and this currently state-of-the-art takes somewhat around 1 hour. And so what this means is if you have a million USDC that you want to use for um solving such intents um you will only be able to turn it around once an hour. Now with a proof of freed primitive like uh T1 enables you are able to actually um shorten the repayment the presenting of a proof of a successful fill to 1 minute instead of 60. So that increases the capital efficiency by 60x and that should reflect game theoretically in um a lower fee for the user. Now after this we intend to be launching our first mainet very soon Q3. I think it just ended yesterday or something. Um and uh this will be focused on the proof of read um primitive on basin arbitum and soon after expanding it to more chains but also adding the support for requesting rights. So requesting that for instance a yieldbearing position be opened on another chain in the users on on users's behalf when the APY is higher there and afterwards we will be going towards um a general purpose block space where any sort of transaction is exposable to um to developers and yeah afterwards we we intend to render this system permissionless and decentralized. via adding um consensus among TE nodes, securing that with u um stake um so probably cryptoeconomic security via restaking something like as on top of that adding some sort of periodic zero knowledge proof generation that is needed in order not to be bound by the stake that is uh behind the system in the first place. um and uh doing that only periodically. So yeah, that's basically our defense at uh in depth approach. So first hardware security, this is the easiest to build uh and the least secure um then uh rendering um execution within the trusted execution environment deterministic which is not trivial because remember we have those best effort um requests. Hey arbitum sequencer include this transaction please. So how do we render this reproducible? Like you need to actually make sure that the calls you um allow the developer to define do not depend on time for instance. So for instance you want to know the yield on a on arbitrum in block one two three and not the current yield on a arbitrum. So once we render the um compute deterministic or mostly deterministic, we um are able to add several TE notes and have them reach consensus and um be able to detect um offenses and slash the stake. This is possible because we are not using TEES for privacy. If you were using TEES for um like for instance hidden imbalances or having private shared state this is unfortunately um something that is not decentral properly decentralizable because it's not an attributable fault to leak some private material. You don't know which of the thousand node operators did it. Now, if one of the thousand node operators somehow manages to break into the TE, break the warranty like the the guarantee that the TE is supposed to give you and changes the code that's running inside it and then um signs off on an incorrect state transition output. you will very clearly see well like this guy suggested this be the new state and this guy supported the new state and and this guy did not support it so it's very clear who committed fraud and so you can slash them and then the third layer of security what I call the bespoke zap element is uh basically expanding beyond the limits of whatever stake you have uh um in your system because let's assume Well, Abum has depending on the day 15 billion TVs basis something like that as well. Like now what if T1 is somewhat successful and there's a billion TVL in in T1? Well, it's not likely and not capital efficient either to have 1 billion stake, right? So what could happen is there's like a million stake or a 100 million stake but the TVL is a lot higher. So it's um rational to cheat and not just risk but know for sure that you will get slashed and lose your millions in stake because you know you have already gained a billion in stolen money. So we don't want that and in so so so so you can avoid this ceiling by keeping a counter of what the value at risk is currently in the system in your uh different contracts going into the different chains and uh contrast that with the stake that is currently behind your systems cryptoeconomic security and then as it um as the value at risk approaches the value um that is staked. We encourage we will be encouraging the creation of a voluntary zero knowledge proof of all the transitions since the last ZKP was provided and if someone manages to provide a ZKP like that they get a little reward and the system resets its value at risk counter to zero. So this prevents the system from stalling, from having the long latency of hours for ZK roll up, but it also prevents it from being bound by the cryptoeconomic security. And the main issue that remains is what if someone wants to this a big whale who owns 1 billion in T1 and wants to withdraw it all in a single transaction. Well, and and you don't have 1 billion stake. Well, what happens then is this would be the rare extreme situation where the system would detect well I I'm not sure I can uh securely release those funds on on outside of the system and so I require a mandatory ZKP before I uh release the funds. This system works with basically any um roll-ups, any LLT ones. We can envision doing uh completely nonem um environments as well. And what we what we can also do is uh follow centralized systems for instance follow Binance price feeds from within a TE as long as remember you render such input um deterministic. So for instance for something like Binance price feed again you would want to ask it for the price at some point and you would probably want to have some sort of precision uh rounding etc. Now the devet that we have um oh actually we had a devet before the test net. We had a devet that is a general purpose um block space system where the user is able to deposit into T1 in a single L1 block. You can deposit from Ethereum Sapoleia to T1 in a single L1 block. You can have T1 take some action for you at T1 DAP. Um and within the same L1 block, you can withdraw to the L1 again. So this enables this very cool user experience um of having 5k USDC on Ethereum mainet and not even knowing that you are transacting with a rollup um and and and this all is abstractable away um in in in the front end um and behind the scenes the rollup is able to actually tap into other rollups liquidity. So we launched that in what do we say in March I see and uh then recently in June we launched a uh real time proving test net that focuses on proving reads between arbitum and base specifically um for focusing on the 7683 uh bridging improvement um and now um I would like to show you three quick areas where real time improving and programmability ility shine and that is first uh the 7683 um improvement by roughly 60x that I mentioned before. Um second what you can have with with real time proving and uh writing to rollups is this idea of yield yield difference arbitrage between chains the thing with a on um arbitrum and and scroll and last I didn't talk about this yet is the idea of some sort of liquidity layer that's above a specific chain um which is uh then able able to draw synergies from users of the other primitives. So for instance, all of the deposits into uh contracts on scroll and arbitrum and optimist mainet that people are making in order to have money credited to the T1 balance can be used under the hood if the user opts in to um make for instance 7683 bridging a lot more efficient to have this coincidence of once like clearing house mechanism where you actually don't even need to have a solver fill an intent because this um T1 crosschain liquidity layer already has so much liquidity in the different rollups. So it can basically clear uh such intense such debts instantly and for free. So this is a cool like synergistic longer term uh vision. We don't have that much time. So I thinking maybe I show you briefly our architecture uh just for the more uh technically inclined among you um which I tried to briefly sketch out and there's one interesting thing um if you go over the user journey here the user has some funds and they deposit the funds um via the canonical bridge on Ethereum um to be credited to the T1 rollup account such um yeah let's say this happened already and then the user wants to do something in T1 for instance open a trade they are able to use some sort of privacy for the transaction for the um for um yeah for for the mempool via trusted execution environments having a shared private key for decryptting shortterm short-lived um ephemeral privacy um that is rendered more censorship resistant via an additional step in the system that is basically just running sequencing of such partially encrypted transactions without knowing what they entail and passing on such bundle of uh transactions to the trusted execution environment only. This has this cool feature that uh even if the TE guy were to have broken into the TE, will they not be able to sandwich attack you? And also they will not be able Yeah, they will not be able to sandwich attack you. Um and also um they they are not able to exclude certain transactions. the censorship resistance is created in a way broader set of validators who don't need expensive TE hardware and who are doing this lightweight job of just sequencing transactions into a bundle. They don't need to be running all those nodes for other rollups etc. So this is like this uh interesting thing I wanted to draw your attention to. Um, other than this, um, I'm happy to take questions. Um, and if you are interested in building something in a world that cross, uh, chain composability I hope reopens very soon, I would love to talk to you. Uh, and so please hit me up. This is my telegram. My Twitter DMs are also open. My handle is >> Oresta. My bad. Uh any questions? >> Yeah. >> Well, this is very impressive. Uh very cool. I have uh many questions. Maybe start with the specific one. I'm trying to understand what exactly you meant um by running a full note within a TE. So what um yeah, basically what sort of information will need to be there? Do you need like the full history within the TE and um yeah maybe if you could comment a bit on that. >> Sure question. So ideally we would like to live in a world where this component over here T1 rollup can just tell the user you can call this uh pre-ompile and we have a deal with arbitrum or like a direct channel with the arbitrum sequencer and um if you call it they will call it and they it will certainly be included in arbitum. we will know what the state of the world is after your thing got called. This is what they call shared sequencing like Espresso used to be doing that some people are trying that with base rollups etc. But uh I don't believe that to be feasible and so what I mean by running full nodes in this system in this component is to have a this trusted execution boundary where we assume even if you have physical access to to the to the machine you will not be able to change the code it's running. Um and uh and and then we let this boundary also contain a a way to basically talk to arbitrum as though you were a user. So it's basically just running arbitrum sequencer follower node and read only mode getting um pre-confirmations from the arbitum sequencer about new blocks new mele transactions etc. I think without the mele and submitting like opening a a local co TE colllocated API to another component living inside the same TE to request that some transaction be sent with an EOA that's supposed to not be reachable by anyone because it uh lives in the TE. And so that node would be submitting via again standard P2P um a transaction to the sequencer and hoping that the sequencer not sends to them hoping the sequencer is life and hoping that the sequencer give them the result. And so this is where the asynchrony comes in where where callbacks are needed. So that because this is a best effort approach where the sequencer can take an up to infinite amount of seconds to actually include the transaction and then once it succeeds if it's ever succeeds will um um a colllocated uh component in the same TE be able to react to what happened. This is what I mean by running full nodes. And so yeah, history, all of that stuff doesn't really matter. You can envision it as just basically talking to an RPC that you trust somehow and you can trust it because you know it's running in a TE. So it uh is supposed not to be able to manipulate the transaction before it's sent and no one is supposed to be able to have um a way to misrepresent as this TE because the EOA private key only be generated inside the TE, >> right? But you actually need a full note within a TE like a argon client that will actually do this. So you could indeed just to save a bit on hardware beefiness over here go for light clients but they come with the car. So first of all not all rollups have light clients. Second of all light clients usually introduce roughly a one and a half blocks delay to to what you see. And uh yeah, running a TE node is like it it's usually easy to just move the slider a bit to the more to the right, have another gig of RAM and it doesn't hurt that much. Um so in the in the interest of latency, you probably don't want a light client, you want a full node, full follow node. >> Okay. Um any more questions? Oh yeah, let's go. Uh yes on the topic of uh sequencer censorship and other stuff. Um how much of this is truly permissionless meaning that yes I need to of course you know put down a deposit you know for the for the stake and so on and so forth but can I run this or you need to sign off on me running this? >> Yeah. So in the long-term vision everything is permissionless. The reality is nothing is permissionless nowadays even for ZK rollups let alone for a system as complex and as young as T1. So right now everything is permissioned of course like we are not even on like we are almost on mainet um and so um what what you can envision what you can how you can imagine this is there's some VM which is a TEVM that um that I am operating and which is holding all of the state which is holding all of the programs and and I actually at first do not even render the TE secure Sure because I know there will be bugs. I know there will be um situations where I want to upgrade the contract um or the u um software code very fast without waiting for um some sort of delay etc that I would that you would want in the long term. At first you don't want those uh um permissionless properties really. But yeah, it's uh we we think a lot from the long-term vision and this is for instance why we only have this very shortlived secrecy feature even though you could think well we have a TE why don't we just also allow like privacy and private states storage etc. Well you could but this makes it harder for you in in my opinion impossible for you to decentralize. >> Yeah. So uh on that note another question SL suggestion uh shared private keys are terrible idea uh have you considered using dand which allows uh which is another network which allows uh timebased encryption with a 3second uh stable block time. So basically I can encrypt for 3 seconds from now and it is both open permissionless and decentralized at the same time. Have you considered that? >> Yeah. So, I'm a fan indeed of experimenting with short-lived or value capped privacy, but what I'm worried about is having a system where maybe you have indeed rotating private keys and maybe you even have NPC or whatever. But if the like there's going to be some sort of weakest link. So, for maybe it's if it's NPC, it's probably two PC, right? So you need to have two parties collude and all of the privacy is leaked and you don't even know that it was leaked. So they might have colluded for a moment and then all of the future may depending if you have forward secrecy and everything but at least the current slots privacy is sacrificed and people don't know it. So okay maybe we also burnt our fingers a little bit. My co-founder previously co-ounded secret network. It it's it was like a 1.8 8 billion L1 using TS for privacy specifically and it's really difficult to do it in a good way and there's numerous exploits and we are seeing those every day um to this day with with TEES um and indeed most of the exploits around TEES are about privacy and very few about uh integrity so it's quite and you can think about as a computer scientist well there's some memory somewhere and it's you you can see how especially if it's a lot of RAM um and it's not all um made to be encrypted if it's like terabytes of RAM that there's some patterns and some accesses are taking place and some things take long some things take slow so you can see all those site channels for privacy but for integrity of computation you would actually need to change the code this is a lot this seems to be a lot harder to do with the TE so this is a further reason Why I'm very hesitant when it comes to doing too much or too big in terms of privacy. But yeah, we are indeed thinking about for hybrid private public key cryptography for sharing this ephemeral mele decryption key like elements like that are interesting. So I would love to learn more about what you had in mind. >> All right. Um thanks Orest really cool presentation. Uh big round of applause for Orest. Thank you guys.