Ethereum Sequencing and Preconfirmations Call #18

Transcript

Hello and welcome to sequencing call number 18 where we're going to talk about Ethereum R1, a new base rollup that was announced just a few days ago. It's been quite a while uh since we've uh had a sequencing call. So good to to get it uh back in motion. Uh I'm going to give a very very short presentation um and then I'll hand it over to the Ethereum R1 team. Okay, let me share my slides. Okay. Um so as I said today's topic is one and these are the the four

people who authored the Ephraim magicians post. Jun, Ariel, Junga, and Ahmad. And uh the main presenter for today, as I understand, is Ariel, but uh the other co-authors should also be participating uh in the in the discussion. Here is a quick overview of the the the based ecosystem. Basically, what we have here is uh a few different types of players. We have the early movers that are already based. Uh we have a few up and cominging uh rollups uh that are potentially going to launch as as base rollups. Uh and then we have incumbent

rollups um that are potentially going to migrate from centralized sequencing to uh base sequencing. And I think um what's starting to emerge here as a strategy for these incumbent rollups is to have a two-phase strategy. So phase one is to enable preconfirmations centralized preconfirmations to get familiar with the concept and the infrastructure and the integration with the wallets and once you have these preconfirmations those are forward compatible with decentralized sequencing such as uh base sequencing. So I think projects like uh bass for example have announced that they're going to have 100 millisecond uh

preconfirmations on mainet very soon. uh and projects like Inc. uh and others are are probably in my opinion going to do a similar thing and hopefully they love pre-confirmations and uh and and they will also want decentralized sequencing at some point. And then we have a bunch of other players uh that are building infrastructure and products and services uh around uh base sequencing. And uh today I just wanted to highlight the two new icons that I've added. The first one is R1, a new base rollup project. And I also wanted to highlight builderet um as potentially being effectively a gateway in in the mental

model uh that that that we have. Uh so the the the proposers the L1 proposes can basically delegate their sequencing rights to builderet and builderet will be able to provide uh base commitments such as uh such as preconfirmations and I I had a call with the flashbots team a few months ago uh and uh it seemed like we we aligned on on on this vision of uh building it effectively being a gateway. Now zooming out, what are we trying to do with uh with these the these sequencing calls? We're trying to enrich the network effects uh around uh Ethereum. And in particular, what we're

trying to do is have synchronous composibility across the L2, something that we've lost with with fragmentation. And the two key ingredients that we need in order to achieve synchronous composibility are real-time settlement and shared sequencing. And one of the really exciting things is that we've made tons and tons of progress regarding uh real-time settlement. So, you know, finally we're reaching a point where these two ingredients are starting to mature and we can start to to to to look forward to potentially having synchronous composability once we mix the two ingredients together.

So I just wanted to quickly recap the various ways in which we can have real-time settlement. Like traditionally I've really emphasized snarks as a tool to achieve it but there's multiple other ways to achieve real-time settlement. So snarks is number one and snarks are absolutely on fire. Um there's a lot of effort towards getting real-time proving actually if proof's call number two is going to be dedicated to to real-time proving. Um, and we're going to have um all sorts of uh of announcements uh related to to real-time proving in in the the weeks and months to come. Another way to have real-time settlement is actually to leverage the

L1. Uh there's um you know some efforts to scale the L1. There's potentially a bump to to 60 million gas coming soon. Um but there's also the effort around the execute pre-ompile which is another way to get um real-time settlement whether or not the execute pre-ompile is enforced by snarks or through naive execution. And then there's a couple of other miscellaneous tools that are available. One of them is tees and and here we uh as I understand there's been some progress on having really ultra low latency tees. So for example, as I understand builderet um is uh you know

running builders now the full full full stack in TE's with with really really low latency. So that's kind of a good tool to potentially work with. And of course we can use economic security. We can have for example an AVS that allows anyone to um place pledges um that you know state transitions are correct. And you can imagine even combining all of these things. So you could have a snark a te proof uh and some sort of economic proof of let's say a million a million ETH. And these three things combine all of which in real time should provide plenty of of security for for settling

your rollup. And then there's a another uh tool that that is you I guess less exciting which is to have some sort of trusted and permissioned committee or even centralized operator who will just sign off on the validity of of the the state transitions of the L2s. Okay. Now, if you're interested in learning more about EF proofs, which is probably like the the the most exciting development of the the last few months in my opinion, then uh you're welcome to join the the the community group. So, that's it from me. Um I will now hand it off to the uh Ethereum R1 team uh with uh with Cassandra who will uh make a presentation. Uh Cassandra, Ariel, the

the floor is yours. Yes. Hello. Can you guys hear me? Sorry, I was having an issue with my sound. So, uh, you'll hear me from over here, but Okay, cool. And then let me see if I can share my screen as well. I believe it's this one. And you guys can see this. Yes. Alrighty. So, it worked. Um, so, uh, hi everybody. I'm Cassandra or KZgath or RE AFK. So, uh, great to see you all. Um, and I'm contributing to this uh, Ethereum R1 project. Um, before we even

get into it, we're going to start from the beginning and we will get to um, sequencing. Actually, a question I have Justin is how much time do you want me to take here? Just in case I just to know. So you have the full 50 minutes and the way that we usually do it um is that after the hour we have unrecorded conversations that won't go on on YouTube and we can be a little bit more more more candid. So stay around uh up to an hour and a half, but you have the full 50 minutes for uh presentation and Q&A. Perfect. Yeah, I imagine we won't even necessarily take that long. Um but maybe we will. That gives me plenty of

time. So, uh, thanks for letting me know. Um, so yeah, uh, one thing I just want to say upfront is I think this is a really new project, um, and a different way of approaching these things. So, take everything that I say with a grain of salt because there's no, uh, there's no singular leader or founder or person uh, to I'm just a uh, one of uh, the community members and contributors here. And while we do have this moniker of maybe core contributors, um even that we see ourselves as just facilitators of this project and don't want to necessarily be seen as like owners or the have the final say. Um so uh yeah, just want to mention that. Um so take

everything I say here with a grain of salt, but somebody's got to present R1 and here I am. So really really excited about this. So this is the Ethereum R1 project. What is it? So Ariel, would you mind uh making it full screen the presentation? Uh not at all. Uh let me go for it. Let me see if it works. Works for you guys. Perfect. Okay, cool. So what is R1? I think um uh the most important contextual thing to say in my opinion is that it's really right now more than anything an idea or an offering. Um and so I think um we're really excited about how this um general

idea or approach towards layer 2 um and trying to build layer 2 solutions on top of Ethereum um like how it can mobilize the community and be excited to people. Um but there are many things that are not yet set. Um there are a few and they're named here on our website. You can go to ethereum r1.org or ethereum r1.eth.limmo. Um and uh I'll just name a few of the core ideas. So it's a new rollup project. It's 100% donationf funed. So no auxiliary token, no private investors, just ETH contributed. The ticker is ETH. Um it's the goal is to be a stage twobased rollup from day one and have like a very uh you know uh long

slow upgrade process if any at all and really try to make it so that users have a transparent experience in terms of trust assumptions regarding the um Ethereum blockchain. Um wanted to have this ethos of being an Ethereum public good. some some base fees may go to R&D, but by there's a commitment already that by 2030 everything will be burned and there will nothing will go towards R&D anymore. It'll just be set and yeah, the goal is to be replaceable by design. You just want to scale Ethereum. And so to me, the main offering is um there's been tons of research, tons of amazing development as well done by all kinds of other teams and by Ethereum uh lay uh core developers as well. Um but I'm uh

frankly surprised that uh there's no differentiated offering uh like R1 that has uh come to the market or um you know presented itself to the community yet um which is just unencumbered by some of the other things that maybe other layer 2 projects have which might be you know commitments to private investors uh their own third party token their own ideas about their own brand and what they'd want that to be and uh the differentiated offering we see for R1 is really just the the the goal is scale Ethereum. The brand is transparently Ethereum and uh there are no other commitments and can can we use that to maybe uh build in a different way and

and provide some a differentiated offering as a layer 2 solution. Cool. So, uh, maybe to go a little bit more into some of the technical parts. So, or not even quite yet, but a little deeper. So, yeah, what we know for sure is it's a new stage 2 rollup and that we are committed to using based sequencing. Um, there's no token, no VCs. It's by and for the Ethereum community and we're really hoping to to to honor that idea.

Um yeah, we have this plan to build on top of the great work from Tao and the based rollup stack that they have. I think part of what's interesting about uh this idea coming to the world at this moment is maybe this would have been more difficult when there was still a uh a lot of research to be done about how L2s might be made and uh you know uh accelerating snark development and and a ton of we stand basically on the shoulders of giants and a ton of research and development that's been done but uh now there's actually a lot of tools out there and a lot of have already come together to make it maybe possible that something uh that's truly

just a community initiative uh can can build you know put all the pieces together and build a layer 2 solution that's uh somehow a bit different. Um so one thing we're going to get to at the end of this presentation which I think will be most uh most related to the idea of the sequencing calls is we definitely want to target uh based preconfirmations and uh I think we'll get into maybe the different flavors of these and and uh what we're excited about here. Um, and yeah, there are a few novel things about the R1 design that are already uh known to some degree. And that's this uh our plan to use this uh novel two out of

three finality gadget which we'll talk about in a second. And there was uh uh a lot of this work is uh come from great research. It's been done by people at Nethermine Ahmed um who's uh uh has been working with us and also uh uh Vitalik of course. So um this is something new and finally we'd like to also contribute some sort of novel rollup upgrade governance design and ideally that design is something that once we design it and and we release it could be something that other roll-ups could also opt into. So um these are the things we're targeting.

So as I said things are not really set in stone yet. It's really an offering an idea. see how we, the Ethereum community, can come together to build something this way in this direction. Um, and we're thinking of right now as phase zero for R1. And in phase zero, we really are looking to uh actually nail down some of these concretely some of like the plan of what our R1 would become. And instead of just setting that all in stone beforehand as some small group, we really want to do that along with the community. So to me the really concrete things in this phase zero are this finality gadget spec but in my view this is pretty much done. We'll talk

about that in a moment. This governant gadget spec what that might look like. How can you make it something maybe modularized enough so that other rollup projects could also opt in to utilize some of that infrastructure. Um a complete technical spec of all the details of what R1 rollup should look like. And finally some sort of concrete plan of how the development will be done to actually bring this thing into the world. Um uh during this phase zero there's also uh it's open for donations and our goal is a thousand ETH or more.

If we don't make that everyone can return their donations trustlessly using the donate smart contract. Um uh but if we do then we can actually uh move forward with this concrete development plan. So we'll have these weekly open meetings. So everyone who's here, please um uh look out for those. Um we'll probably start next week um where we try to move towards these goals as well in some asynchronous uh you know communications and so forth. So I want to talk about actually get so that's just the the background hopefully makes some sense. Uh I want to talk a little bit about some of the novel things here and we'll start with uh the governance gadget proposal. And this really is uh um something where

it's not set in stone at all. There's still a lot of room for uh feedback and and uh learning more. But we wanted to ask this basic question which is who should govern rollup upgrades. So I I made this little picture here of a number of different stakeholders in the Ethereum community who might be potentially uh participants who uh would govern uh upgrades of a rollup like R1. So you have all all of ETH, you have staked ETH, you have ETH that's bridged into this uh layer 2. Um you have uh people who were part of the group that donated the initial ETH that uh that funds the project. um or you

have the dev team and uh some sort of guardian multisync. So these are the participants that that might be able to govern and so far our design uh that uh we are leaning towards is uh something that looks like this. So we believe that all ETH holders and maybe this design some I got some feedback it's a little confusing. All ETH holders and staked ETH holders notice have no authority whatsoever. So they don't participate in any governance. Uh layer one uh simply you know is what it is and this is all about the the layer 2 commitments that get checkpointed on to layer one. So that simply don't need to govern over anything here.

Um but the the flow that we do see all the other participants potentially do have some uh some agency overseeing uh the rollups the the rollup upgrade. Um and I think the flow looks something like this. So the dev team might propose an upgrade. This upgrade requires the signature of the guardian multisig. And so this is like um this is what without that this upgrade will not go through. So this is just like a security measure. But note that this guardian multisig is not like uh the security council's multics that you have today on other layer 2s which have like rushing upgrade authority and other sort of administrative powers. It's simply uh

required that they approve the upgrade but they can't push some arbitrary upgrade that they would like through without waiting for the exit window etc. Um after that uh there's definitely a 30-day minimum exit window. Could even be longer but that's at minimum. It's also needed in order to reach the stage two criteria. But the other two types of participants that we see as um potentially having uh a role in governance uh only through veto power are two different subsets. One is the ETH donators. So all everyone who donates to the donation contract that can easily be tracked on chain and exactly their you know weight and you can create some

criteria where that group that committee can uh uh veto some upgrade that the guardian has approved and that is waiting in the exit window and then similarly all the ETH that's bridged into the R1 L2 solution those ETH holders could uh coordinate to uh get reach a quorum enough of that ETH and uh also veto a certain upgrade. So the idea is that the people who actually funded the project or the people who are actually using the underlying system uh have a say in saying if they want um any new changes to the rollup to actually um be implemented. So this is the idea. One question would be how can you modularize

this? But what are the actual abstractions and like what does the what do the smart contracts on L1 look like to to make the system real and make it maybe reusable by others. But this is the current proposal for governance and the goal is to minimize it. There are also uh interesting conversations going on about maybe making it not upgradable at all in which case some of this would be uh less relevant. Uh so I think there's still a lot of interesting ideas to hear from the community here. Uh okay. So let me see I'm doing on time also fine. Yeah. Um so uh I think this is a really interesting part of the design and again this has been a

lot of people uh great uh researchers and contributors Vitalik etc helping to create this design. So I'm really just uh relaying it more than one of the designers myself here. Um, but I think it's a super uh interesting and clever way to try to reach uh fast finality and also have some safety as uh ZK rollup. So, um yeah, let's see how I do here. The goal is to uh be able to on a happy path have very fast finality for uh this Z the state transitions of this type of ZK

rollup or this rollup are one and um one issue that I think is very important is that today ZK proving systems are still very young. We've had amazing acceleration, but there's still uh very much non-negligible fear of bugs in ZK proving systems. And so, how can we try to um still have like reach the happy path of a um getting very fast finality when the when the proof is actually constructed and verified on chain, you get finality. But also in the real world, in a world where ZK proving systems could have bugs and billions of dollars could be at risk, um maybe have some uh some trade-offs here to to make

it even more safe. Um so the idea is to use uh to get a heterogeneity of assumptions um so uh that you might have a lot more safety in uh finalizing state transitions. So what you have here are basically two ZK systems. So it's two separate ZK proving systems. One that we're calling an optimistic ZK proving system and one that's like uh let's say traditional. Um and you also have uh the use of trusted execution environments. So these are your three systems. The trusted execution environment proving and these two separate ZK proving systems. and two out

of these three, you need uh the agreement of two out of these three systems for your uh rollup transitions to finalize. So the TE system because TEES are of course they're just um they're just machines, right? They have some really nice properties, but they might be much cheaper to break. Um I one idea is also that the TE system itself is a two out of two TE system. So you can get different types of TE. So if there was some sort of zero day attack on SGX or whatever it might be TDX um you know this doesn't compromise outright the whole the TE system in this design. Um but uh yeah that's what I want to say about TEES. Um, but I think

the really interesting thing took me a while to get myself is this idea that by having this one OP ZK system and uh the traditional ZK system side by side, um, you should make it so that even if these two ZK proving systems shared a soundness bug, let's say, you still would also have to pone the TE in order to uh to get this two out of three and accept or you would have to find a soundness bug in one TE system and a completeness bug in the other in order to get this two out of three. Um and uh I'll explain a little bit more in a

moment. But so uh the idea let's just go from the happy path here. In the happiest path a sequencer will you know progress the rollup. Um, without going into too many details here, there's maybe the idea that a sequencer might place a bond. Um, this is just so that when they progress the rollup and then provide their proof later, um, there's something at risk so that they actually have to provide this proof. If someone uh if they don't, then someone after a certain time stamp, someone else could provide this proof on their behalf and if it gets finalized, then they win the bond back. Um but if you actually uh uh finalize your state transition then then you get your bond back as a sequencer.

So you place this bond, you uh you uh transition the roll up to the new state s and then um finally you uh in the happy path you would now present the proofs which might be uh the agreement of these TEES with this uh with uh your state transition as well as the ZK proof you constructed with some ZKVM let's say uh uh risk zero whatever it may be. Um, and if you provide these things and they agree, you get instant finality after these proofs land on the L1. So that's the happy path. Um, let's say on an unhappy path, maybe the TEES are just dead, not alive, and there's livveness

failure for the TE's or maybe they're doing something erroneous. Uh, this is where the OPZK system comes in. So if you don't have this agreement between the TEEES and the ZK proving system, then you have to wait for we move into more like the way an optimistic rollup might be where you actually have to wait for a 7-day window. And uh during this 7-day window, if nobody can provide a challenging proof for the ZK uh EVM, then uh then eventually you can finalize. So, uh, I think what's what's interesting

here is again, if you had a soundness bug, even in both of these ZK systems, you actually would not be able to finalize your malicious state transition. And that's because in the OP ZK system, well, it's a soundness bug, which means we can prove arbitrary statements. So here uh some you just need one honest actor in the OPZK system to uh to you know reject this malicious SS star let's call it and then this malicious SAR will not finalize unless you could also let's say I don't know backdoor the TEES as well

and then uh you would be able to uh and have them agree with your initial SS star malicious state transition and then then you would be able to finalize such a thing. So, um there you have the idea for uh the finality gadget. I think this is a really exciting work personally. So, I'm quite excited about this um and might be relevant for when we finally get into more sequencing related topics. Uh I just show this there's an even more in-depth diagram from Ahmed from uh Nethermind. And uh some stuff that's interesting related to what we were talking about the governance gadget before is some of the uh upgrade conditions where uh potentially if you look at these blue boxes on the bottom

uh you might be able to uh more quickly upgrade some faulty proving system by using what you learn through like uh the the the two out of three proving technique so that you don't actually have to wait a long delay in this case because you can be sure that there's some problem with X proving system and that's the one that's the problematic one while the other two are following things correctly. Um so yeah feel free to look at these diagrams more in depth if you'd like. So now uh I think where we finally get to um is R1 as a based sequenced rollup and how can we provide a great

experience for applications and here I think uh pre-confirmations will be very important and play a major part. So, um, yeah, I think I I'm going to pass it off to Junger for now to talk maybe about the different, uh, flavors of pre-confirmations we might target. Potentially at the end, I might say a few comments or maybe thoughts and suggestions about pre-MPS, but uh, yeah, younger, if that sounds good, take it away. Yeah, thanks for the whole presentation. So actually at the base sequencing calls we already covered a lot of things. So I don't want to I I don't want to mention again all of them. So basically I mean from our

point of view Ethereum Ethereum's own rollup should be base rollup because we have to use all of the modules of Ethereum uh like sequencing like data and in future execution. So there is a lot of improvements uh on the base sequencing part because thanks to Tao we have very major uh base rollup stack. So it's going really well and I really appreciated them to build that stuff. So um yeah the the main difference of R1 from the other rollups will be finality gadget but the text stack uh will be similar. So base preconfirmations are

also a very important thing to solve economic problems of base rollup. Uh I I I felt I mean uh there's a lot of thing on the economic side of base rollups. So yeah from base preconfirmation side there's also a lot of improvements on this side like come boost fabric uh yeah me comet. So we have very good text right now. So there is a lot of research also. So it's still going on. we will utilize their research and also we will contribute from the research perspective. So yeah uh yeah base rollups are very efficient way to build a roll-up I mean from alignment perspective also and also provides in a

sense synchronous composibility so that's possible so yeah that's my two cent so cool uh yeah I will mention a few more things here and then I think we'll get to questions pretty early and actually this might help shape the conversation a good amount uh very excited to hear what kinds of questions people might have um I think for me to to zoom out on the pre-MP discussion for a second. Um I I think again what seems important about R1, this is very much my opinion, not the opinion of R1 itself, is uh its differentiation. And I feel like the key of this differentiation comes actually

from this ethos uh uh not encumbered by uh other types of uh private investors private commitments that it needs to make good on. It doesn't necessarily need to be an uh exponentially profitable company um and uh it doesn't have this kind of baggage. And so how can we maximally leverage that to have a differentiated offering that actually matters for users? That's cool from an ideological perspective, but is there something that that actually is there a path that that affords um that maybe other projects might be more reticent to take or can't take that actually ends up giving users a much better experience.

And here is where I see this road to synchronous composability being really exciting for R1. I think maybe for other L2 projects um there might be much deeper set of tradeoffs to like commit boldly towards just trying to just trying to arch create an architecture that fits that vision and that allows us to reach uh you know a synchronously composable Ethereum where you no longer have to fight tooth and nail against everyone for liquidity network effects on your rollup but we can simply interoperate. Um uh I think this is a really exciting differentiation. I think there are also some other ones you can think about censorship resistance and neutrality and things like this. Um, but

for me, I'm most excited around uh actually what are the core concrete benefits? If a user doesn't care about any of these ideological parts, they just want to know where they should build their application. Are there ways that uh R1 could could be somewhere that other projects uh might not be or get there faster? And so to me, uh yeah, I'm quite excited around the actual feature set. um trying to trying to accelerate towards a a feature set that's not just par with other kinds of roll-ups, let's say like a single sequencer rollups. So you can you can already get par by um some of the designs maybe even with like a whit listed set of sequencers um in like a based sequence design. Um but

you'll just get par. you'll be able to offer pre-confirmations and not have this uh slowowness that you have to deal with with the base rollup where you must wait for the you know L1 block time, but you don't yet gain anything that you don't already have on other rollup solutions. So to me, I'm really excited about things like L1 s load, L1 call eventually with uh things like commit boost and and fabric getting more mature um actually being able to offer a user experience which is completely new where you have this uh synchronous stitching or maybe almost synchronous stitching if there's some step in between that uh

allows you to build applications actually in a new way in a way that you could not on let's say base. Um so uh yeah I think this is really the exciting part of the conversation. Maybe the questions can uh push us uh in the right direction to learn more about this part. Uh but this is what we had. Um thanks for listening everybody and uh we're really excited to get started with R1. Amazing. Thank you so much for the presentation. Uh if you have any questions, feel free to just unmute or ask in the chat or um raise your hand. Uh Orest um Cassandra. Yeah, first of all, thank

you. Super super interesting. Um I was wondering, you did mention that a combo of a soundness and a completeness bug be the dangerous one. Why would completeness be an issue for integrity? So, as far as I understand, maybe I can even go try to go back. Um, as far as I understand, the issue is that if you so let's say the TEES are dead, right? So, you can't use the TE's. They they don't help. So you try to you are able to you know you find this soundness bug in ZK system one and you exploit it and you try to you know you try to prove

state transition S star now nothing happened with the TE so we go into the ZK optimistic proving system if there's just this if there's no bug in that system you're fine obviously let's say there is the same bug and this is where this is what I find quite interesting is the idea that actually today different ZK proving systems they are different but they're not that different and so the idea that they might share the exact same soundness bug is actually not so unlikely. So if that's all you have, you have the same soundness bug on the OPZK system, on the ZK2 system, that's not a problem because as long as you have one honest actor, right, a soundness bug

implies you can prove anything, right? So one honest actor will show that hey there is actually this Sar is not the only thing you can prove and so it won't go through. And so that means the only way you could uh get through the with these two systems is if you had the soundness bug in ZK system one and in ZK system 2 you somehow could fail to prove anything for this state transition and then uh you'd wait the seven days the clock would run out and two out of three would uh does that make sense? Yeah, it makes sense. Thank you. Interesting. One question I have is on the the donations. So there's this interesting mechanism whereby if you don't reach the

thousand E the funds are returned is the idea that um R1 will only go through uh if you can raise the 1,000 E. That is the idea and this was the rationale for this was chosen I believe uh mainly for the idea that this is what we believe is like the absolute minimum today that might be needed to actually spin up this project in earnest. Um and uh the main thing that was considered to try to find that like lower lower bar of what what might be needed to to actually make it worth develop this project and bring it into the world completed. Uh is things like infrastructure costs for proving

and uh what what is the what kind of scale would we like to target? How much infrastructure cost would that be for something like 6 to 12 months? And we arrived at 1,000 ETH as like some sort of lower bar. But this is definitely hand wavy math. Um, but yeah, we believe that it it uh it maybe does a disservice to the 15 ETH that donates if that's all you get and then you try to build something, you know, with such a small amount of funding. Yeah, I could add a few um other point. the I think the rationale is that um we are just proposing a proposal to Ethereum community. So if Ethereum community don't want it, don't want to farm it, don't want to see it exist, there's no

reason for us to work on that. So yeah, a vote with your ETH. Sasha from Lido is asking is the idea that fees alone will make it sustainable after six to 12 months. We have no idea. Yeah. Yeah. No idea. I agree with that. I think one thing that's true is that event the the goal is certainly that eventually you reach something fully sustainable. So there is this idea that by 2030 either either Ethereum has gotten to such a place that you don't even need L2s at all anymore for some reason or that this thing you know by

that moment would be fully sustainable. There's absolutely um uh you know the it's sustainable to sequence this yourself. You have a very uh you know heterogeneous group that's actually doing that and and you don't need some sort of dev team to have some funding stream in order to keep the project alive. Yeah, one one just just one thing here we're working on for surge and uh by design we'll go to R1 if R1 adopts surge is that um we're working on like currently the base rollups that I know of they don't incorporate the L1 fees into the L2 transaction fees and this is something that we're looking into right

now heavily and we think that it is one of the preconditions to actually go to mainet for surge or for R1. Um because if if if we want to show okay like like the the rollups have been uh like unless you have a certain volume on your rollup then you are basically most likely subsidizing a lot of the cost for proposing for approving etc. And we don't want to showcase the tech in that way. We want to showcase the tech as pure as possible. And the way to do it is by um showcasing the actual L2 fees that you need to pay to actually the actual L2 fees that you

need to pay to actually then propose and prove on the L1. Um obviously this uh with low transaction volume the L2 fees will be higher than uh you would normally see on other L2s. But as volume starts picking up then you might see this these transactions uh actually become cheaper and cheaper um as as they can share the proposing and proving fees uh that are carried on the L1. Um so yeah it is an area that we're looking into and it's a prerequisite for going to um mainet for us.

Got it. So no subsidies and you want to be very organic. Uh makes sense or rest you have your hand up. One more question for I guess maybe Amad. I'm looking at the uh updated diagram and uh I I had assumed hearing Justin's intro with uh combining cryptoeconomic security like as style as potentially an additional security um security adding measure which I've long been a fan of but I don't see it here like in here the bond is just some sort of like a small bond that the block proposer adds in right is this like um the target

design or have you thought about uh using ABS or restake for actually for for composibility uh especially like for for fast like I can't say that we're going to use the ABS or the solver model or cryptoeconomic security for uh fast settlements. I don't think this is something that we're aiming for. But if you look at one of the it's been like out for a while. Uh I I just shared an article uh by the surge uh research and engineering team about how we can do fast L2 to L1 um bridge outs without waiting for the proof to come in and incorporating this with the other

article that we have also for um instant L1 to L2 messaging. you can get like same slot bridge in bridge out and trans bridge in transact bridge out kind of behavior um with the L2. Um so like um this is this is something that also we are working on and it is in the road map for surge. Florian from Lineia has uh shared a link in the chat where um he has basically estimates as to how much um gas will cost if L2s are not subsidized and

that's in the context of the the linear blockchain which may also become based in the future. And also to add on this like a were mentioning like you don't want to subside fees. So this is one first approach to take into account the uh data availability for the proving uh cost. There was discussion on how to uh estimate them and I think it was presented also along this line in the previous call. Um so there is discussion on this. I'm happy to uh to uh discuss this further uh whenever you want.

Yeah, I'll I'll I'll definitely look into this. I will also ask the team to look into this document. Thank you very much for sharing it. And uh we'll probably uh if we if we have any questions or further collaborations, we we'll probably reach out. We already have you your guys contacts. Um yeah, awesome. Thank you very much. Yeah, one thing I didn't mention about the costs and this idea of this minimum bar is of course there is also yeah L1 gas costs as well but I believe we think that the proving costs will be uh uh much larger multiple than the L1 gas costs. Actually in in in reality with high transaction volumes the actual cost

comes from um the onchain verification of the proofs rather than coming from the proving cost offchain. Um so yeah like uh there like it all depends on the amount of volume that you have and how many times you are going to propose blocks and how many times you're going to uh prove them. So with that like Tao has been doing such amazing work uh with their codebase where they now have introduced with the new spec that is coming to mainet in um June or July. Uh they introduced something called batching. So that now you can um

submit multiple blocks in a single batch and then for this whole batch you can you can do u you can verify a single proof on chain. This cost this amounts for a huge amount of costs saving because a single batch could have like hundreds of blocks and you basically reduce the cost of the proof verification by that amount. Um like one over 100 if you if you for example put 100 blocks in a badge. Um so yeah like it's uh it's uh the work that is being done here uh especially by the Tao team uh for cost savings and um uh for base rollups in general is very impressive.

Just on the proving cost I think a thing that could make things a lot simpler would be to manage to align the gas cost of the up code to the actual cost of proving the the up code. So there is some um uh research I think there is an EP about this to review the the pricing of the OP code uh to better reflect the proving cost cost of them and it would make um this pricing um and like notizing the transaction a lot easier. Yeah. So, so there is there is the concept like I think that the the

the one that have introduced this concept before was ZK sync when they introduced this concept called ZK gas and I think this ZK gas concept is very interesting um where you can where you go and profile all the pre-ompiles and all the op codes uh on the on the that uh the EVM supports and then once you have that you can uh go you can profile that how many ZK cycles it requires to actually prove each op code in each pre-ompile and then you can price uh the transactions based on how much ZK gas it's uh it it is consuming so this is for off-chain uh uh proving costs right uh and like so there is these u zkillers

that we know about and we heard about uh from um uh from from the ZK uh what was it called ZK proofs uh all and we know about ZK killers but yeah like what we want to accomplish is actually to profile every single op code and every single uh uh pre-ompile uh I don't know if there is someone who's doing this effort because Nethermind is actually interested in this applying for a grant for something like this but I don't know if someone else is already doing it um obviously like we we'll reach out to the EF and ask these questions and see if if someone is already doing this effort there is no need to like replicate it. Uh but yeah like it is something that we're looking

into and very interested to to to look into further. So we uh there is Evo in line with work was working a bit on this. I just shared the EIP uh in the chat. It's not exhaustive. So maybe um uh you want to do some larger efforts but definitely there is some some work that have been done so it's worth uh discussing this. I remembered one thing I didn't uh mention so that just want to mention briefly which is I didn't made no mention of native rollups and uh the native uh pre-ompile. Uh I think this is

something that R1 is also deeply interested in. It's only not mentioned because this is something that does not exist yet today. Um, and so it's also somewhat path dependent on uh R1's approach to upgrades. Um, would it be something you launch completely separately or is there these are there these long delayed upgrade paths that actually exist? Um, and if so, I think uh we would be interested in this pre-ompile somewhat tangential to the most recent conversation, but maybe matters a bit in terms of how you compress L1 costs.

I mean the execute pre-ompile might be helpful to collapse all of the complexity around the two tees and the two proof systems into just the one uh one pre-ompile makes sense. Yeah, totally. One of the hidden costs of of running a rollup is um all of the integration costs with some of the um the the tooling like um EAS scan or chain link which cost millions of dollars and one 1000 E is is not going to cut it. So is the idea to have pro bono integrations with EASCAN and and other providers? I mean they

they always can offer their services if they are like want to align with the Ethereum and with the community etc. We're not going to be like no we don't want your help. Of course any help is appreciated. Anyone can contribute. Um but there is like so for example what we're aiming to do is we're aiming to do like an L1S load or an L1 call mechanism where you can actually if you want to call like a like a chain link oracle you can just call the L1 chain link oracle. Yes, there might be some some slight delay in the result that you get from the L1 chain link oracle but um it's still something that you can use and it could be viable.

Um uh yeah like but but so this this is might be like our way of like the cheap man's oracle right to do composibility with the L1 and then we can just rely on the L1 for most of the tooling. Um but yeah like uh obviously it's not like a like a sustained uh uh uh solution for all the or like a complete solution for all the tooling that might be required and of course we rely on the community support to get this uh to get this done. Absolutely. And and this is also where I see that fork in the road of the trajectories of how this project is being built and why I was mentioning for a while having this actual

differentiated offering for applications and users. uh why it would be so exciting if today we could have like fully realtime proving already then I would see R1 as very likely would want to launch with like synchronous composability from day one where that where basically the idea is right instead of uh that there's actually a reason that there's a lot of network effects around this execution environment and then a lot of that tooling starts to come as well because of these network effects and that this is ultimately drawn uh you know that drawing in of these different participants is ultimately because of this differentiated you know this better tech stack that we can be the first one to to be towards um so to me that feel

like this is uh yeah we we certainly uh can't compete on having you know the biggest coffers with other uh other L2s uh to in order to you know have lots of money to give out grants all kinds of tooling and so forth. Um but maybe because of the yeah again the difference of uh of uh sort of how it was built and and who the stakeholders are we can have a faster path towards a user experience that then actually creates a lot of network effect and and brings the tooling naturally jun sorry one one thing that I'd like to note is that the the the R1 itself and

surge itself do not have a stack. So what we are depending on is the generous open-source project of Tao. And what Serge does is that adds these uh extra features, extra boosters to to to the to the already existing uh tech stack that is offered from Tao. And what R1 comes in and and and adds the community governance governance and like um and like the the community effort around to to to push then this this rollup project forward. It it there so like I like if if it wasn't if it weren't for like the Tao team and their earlier work it this any none of this would have been

possible. Um and like so yeah like like u very grateful for the Tao team for their open source uh work and uh over the years uh honestly so uh Jungar in the chat made an interesting comment he said that when R1 was announced uh there were many uh offers from oracles big apps and explorers to make integrations for free so it looks like the expectation is to not pay anything for all of these um critical integrations which is fantastic. Um talking about Tao um I believe that there is a base rollup summit which is

being organized and Join has a has a message for us on on that event. Yeah, thanks Justin. Hey guys, it's Pier Sea. By the way, thanks our guy everyone guys for the presentation and thanks for the kind words for Tao. We we really appreciate it. I'll be quite quick on my on my end. So we just wanted to flag that. Exactly. Right. We're organizing a followup to the base ro summit this time during HCC in K. It's scheduled for July 1st. And for the ones that don't know about it, it's it's like an extension for these calls which are really good, insightful, but instead of online, we

make it IRL. We realized there was no real gathering dedicated to to this. So that's the intention of this event. It's on similar topics to the sequencing calls around sequencing, preconfirmations, base rollups, and some other Ethereum hot topics. Uh last one was in SF few months ago was really really good. So if you'll be around in July, I I guess most of you will be there. Well, first of all, feel free to join. It's of course free but limited in Spain. Uh but if you like to get more involved, um we are very open to suggestions on topics, uh formats, edge cases, like whatever. It's a it's a really nice opportunity to bring all

these conversations to to real life. and uh we really try to make it meaningful for everyone's time and for Ethereum overall. It's not only about the talks but also about getting together overall. Um I also want to share that we have a short uh sponsors deck uh for anyone interested in supporting the event. Uh some tiers include speaking slots of course needless to say we are being very thoughtful about fit to keep every session high value but yeah it's nothing crazy in terms of cost but it just help us you know make it happen and hopefully run more of this because it's it's quite an expensive thing to do to be honest.

So yeah, just to finalize it, if you want to you want more information about the last one and this next one, we've got a web page for the for this uh Luma page. Um all the links are ready to share. Actually, I'm going to share them here in the call now. Uh not sure if people outside can access them. Probably not. So perhaps for whoever listens to this call later, you can just maybe ping the Tao X account if he's here. And yeah. Oh, and thanks to Drew and the fabric team. They're helping a lot shape the whole thing, get speakers on board, and you know, make sure it it runs smoothly. Yeah, that's it. Back to you, Justin. Thank you, Drain. Um, so we're at the hour. Uh, this, uh, wraps up

sequencing call number 18. Thank you so much to Ariel, Jajun, Junga and and Ahmad first of all for presenting uh the the proposal but also for for sharing their thoughts today. Um this is the end of the public segment of the call and we'll now open it up for off the record conversations.