Ethereum Sequencing and Preconfirmations Call #8

Transcript

okay welcome everyone to sequencing and pre-confirmation call number eight uh today the the topic uh is uh research and development that has been done by lime chain specifically on on base sequencing and base prec confirmations my understanding is that they got a grant from theim Foundation which has now been complete and I guess this is part of the the outcome of this grant uh George the the floor is yours thank you yeah I'm assuming you're seeing my

screen yep okay cool all right yeah well uh thank you guys for the for the time as Justin said uh we applied and gag Grant to research uh based prec confirmations uh from matum Foundation uh and very quickly we realized a couple of things um first of things first thing that we realized that actually pre confirmations are not uh per se the end goal but they're just a feature of sequencing so we needed to figure out okay well uh what is the form of sequencing that LS itself the best to prec confirmations and then uh yet again

when going one step further we wanteded to examine the fundamentals of the centralized sequencing uh in order to prove to ourselves and prove to the readers uh why we believe that actually Bas sequencing is the thing to to go and then make the case for prec confirmations uh and then we are able to um go into a little bit more details into how would one implement the uh prec confirmations and the whole base sequencing thing including the modifications of the software that that are needed uh mechanics on opting in etc etc uh so this is what we're going to be talking uh about today uh and I'll start with a con controversial statement centralized

sequencing is actually cool uh and centralized sequencing is actually cool because first of all it offers great ux uh for users it offers fast informations it's very easy to find the sequencer it's easy to bootstrap a roll that has centralized sequencing and normally generates normally massive revenue for the for the rollup if it gets adopted but this is until it isn't uh because centralized sequencing also is a massive Target uh and any liveness fault within the centralized sequence server uh can hold the ROP like something that happen with inscriptions to one of the rollups previously also there are potentials to for censorship and potentials to monize

the fee Market uh and pretty much uh move the price any way they want and uh we don't really like this um these downsides and we need to do something about these and the obvious thing that we can do is to try and figure out what actually the centralized sequencing looks like so let's go through a little bit of a to experiment uh and quickly design the centralized uh sequence thing um and before designing the centralized sequencing I wanted to highlight the five guiding goals and principles that we have worked out of in order to to be able to design centralized sequencing and you'll see all of these are

interwined and ingrained within the concepts that we have researched and we are proposing now uh the five guiding principles are secure without uh ux sacrifices economically sustainable for for All actors and this also includes the rollup and the rollup team um it's uh decentralized sequencing enables composability over over W Gardens inherits theum liveness over external liveness guarantees and uh there is a protocol over trust based sensorship resistance so we have been designing with all this in mind so we started our research and we did this thing don't squint it's purposely purposefully

unreadable but we essentially in uh we Traverse the whole design space for decentralized sequencing and I'm quickly going to walk through what we found this is the thing that we found first of all the centralized sequencing got hands uh it's not that easy to actually design centralized uh sequencing as uh many people that have tried to do so have found out uh one way that you can design the centralized sequencing and one whole group of of designed approaches is freefor all sequencing which is essentially a completely open permissionless sequencing anyone can submit sequencing B transaction and sequence your uh your rollup um this however is uh is suboptimal especially when you consider

user experience because it's hard to support prec confirmations you don't even know who to ask for prec confirmations even whether they are actually going to be able to honor these prec confirmations and if they have the control to honor these prec confirmations and also there is a huge potential for uh sensorship or front Runing so the whole group of freefor all sequencing um uh approaches uh we kind of discarded and we went for the other group of approaches which is leader election and one of the most popular way that people have been designing uh the centralized sequencing and exploring the designs of De centralized sequencing is through external consensus algorithm which is essentially you building your own

consensus algorithm reading your own bft having your own validator set and then electing a single leader uh and this leader is the one that can be submitting the sequencing transactions for your rollup and this is great because during their Monopoly time when the leader is elected they can offer centralized like uh ux for example pre confirmations uh however when you are just having an external Trum um consens algorithm uh you start lacking two things or you are complicating two things uh first of all you have lack of time guarantees because uh a randomly elected leader based on your con algorithm actually doesn't have uh

100% um guarantees that they can actually include their transaction on time and by on time we mean within the slot that have been allotted for them to be uh putting these sequencing transactions uh and there is actually only one actor that can do this that we're going to be uh talking about just in a second uh but the second downside for external consens algorithms is that actually is quite hard to prove that the leader selection was correct to L1 you can do stuff like ZK for that but if we looking for robustness uh if we can figure out a system that doesn't require uh hard proof uh proving hard proofs for selection correctness uh is going to be

much optimal system and then we end up with the original based sequencing um concept proposed by Justin which is leader election concept and it offers centralized yeah it has leader so it can offer centralized like QX for example prec confirmations it that's timely timeliness guarantees because essentially what B sequencing says is that the sequencer of the RO is going to be the L1 proposer and the L1 proposer is the so actor within L1 that can 100% guarantee that they can include a transaction sequencing transaction within the uh i1 block um and then it's easy to prove the leader selection correctness because you know

it has to be the the the proposer but as just in talk the previous time there is this um downsides of the original Bas sequencing concept that's uh the sequencing gaps plus cold start like how do you bootstrap actually uh by sequencing and just impr propose some of the uh ways that you can do do so and we are also uh having the same thoughts of how do boot this um and basing ourselves on the base sequencing no intended here we actually uh are suggesting now something that we call vanilla based sequencing and vanilla based sequencing is very similar to Bas sequencing uh it's again the L2

sequencing is again performed by opted in L1 proposers same as the original basing concept uh there are two two types of selections primary selection is uh happens whenever the current L1 proposal have opted in to be the L2 sequencer so we are immediately giving them the rights to be the L2 sequencer this again same as the uh original base sequencing concept and then there is the uh second fback selection which is in the case where the current A1 proposal has not opted in uh to be the current uh to to be part to be sequencer of the of the Rope then we are just taking one random um opted in proposer and our

argument here is that this actually is um addressing the call start problem and sequencing gaps uh because even in the beginning if there like very few sequencers L1 proposal that have opted in uh they will be able to one of them is going to be to be drawn and they're going to be able to profit from the sequencing fees of the of the rollup uh which means that going to be eligible for more and more and more profits and this should make it very um lucrative and very interesting for more and more proposers to actually get on with this sequencing thing uh which is ultimately what we are uh looking for uh to have bigger and bigger participation so if we

can think about what vanilla Bas sequencing is well vanilla Bas sequencing is the original Bas sequencing concept plus Thea fall back selection added uh on top few notes uh you're seeing you're seeing these numbers one four etc etc these map exactly to these goals that I mentioned here uh whenever you see them this is well like a property of the vanilla based sequencing that through which we are actually satisfying these goals um so as you are seeing here uh pleaser election uh immediately satisfies stuff like um user experience um this concept supports prec confirmations because you can discover

your sequencer so that you can ask the for prec confirmations it supports it supports share sequencing within uh primary selection uh which supports the goal of having composability rather than wal World Gardens um something that's requirement for rollups that are implementing vanilla Bas sequencing is to bet requirement punishment mechanisms staking or bonding this is mainly design decision of the of the rups whether they want to go for for staking or for bonding or raking um then sequencer profits from fees and um me uh which makes it economically viable for sequencers

rollups can have can have Revenue by extending the design to include commission out of the sequencer balance increase which can uh allow the protocols that are using vanilla Bas sequencing to actually be ically viable for the rollups and rollup teams themselves um the sequence sequencing frequency uh in in the diagrams that I showed you previously We Are equating One L1 slot to one rollup slot but this does not need to be so uh we can discuss the various um cases where you can have one roll SL be multiple uh L1 slots or the other way around we didn't want L1 slot to have multiple roller blocks and

something that's going to become important a little bit later role of sequencing can actually be delegated to external pipeline much like currently block building for L1 is delegated to external pipeline role of sequencing can be delegated to external PIP plan and this is what V Bas sequencing is it's very close I I'd say like it's 85 to 90% the same as uh what Justin is uh proposing we just uh figure it out from the fundamentals we we reason it from the from the ground up and we ended up with very close uh conclusions to Justin his proposing and then we went into prec confirmations um and yeah what are we

talking when we when we say precon well uh first of all we are talking about um inclusion precon and execution prec confirmations inclusion prec confirmations are the precon that just guarantee a transaction is going to get included within uh rollup slot execution prec confirmation allows for specifying the desired values of parts of the state of the rollup after the execution of this uh of these transactions um the first one is very useful for stuff like simple transfers the second one is very useful for stuff like Arbitrage um so how do we actually um support these two how do we Implement

these two well we we are proposing two new uh EIP 2718 transaction types uh by the way you'll see a to doce at the end of the presentation this is something that we planning to to have a roll up impovement proposal for uh and we're looking for collaborators on this obviously um these are going to be serving as prec confirmation requests uh the reason that we want to have separate transactions for this so that they can have tailor made FS for their respective cases and they can have separate pricing and rollups can actually choose whether to support um just inclusion or both types of prec

confirmations uh and when we talk about these uh these transactions let's look into a little bit of the properties of these prec confirmations one thing that I wanted to to quickly mention is that both of these transactions uh we um suggest to include um a deadline field and deadline field is a massive user experience enabler uh deadline field is essentially indication by the user um what's the latest possible1 slot the disp information can be can be honored and there are actually two places where this is uh ux savior uh and when I'm saying ux savior you can think about users needing to click the sign button

uh type their password type their Ledger pin or whatever it is there uh and first is first case where this is like a ux savior is whenever sequencer rejects a pre-confirmation and sequencer can sequencers can reject prec confirmations for various reasons uh one reason that sequencer can reject prec confirmation is that maybe there is a conflicting State already uh and they cannot honor this PR confirmation another reason that sequencer can actually reject PR confirmation is that is if prec confirmation request comes too late within their slot so that don't have time to build the block with this PR confirmation uh in place or delegate it to the uh blog building pipeline so SS

May opt to reject these prec confirmations and if we have deadline fied within our prec confirmation requests wallet softwares can actually take um take this ux inconvenience and just resubmit it to the next leader to the next sequencer um so this is the deadline field that uh you you will see shortly within our suggested fields for the prec confirmation requests another thing that's important to discuss is prec confirmation pricing um here again with user experience in mind uh we are proposing that the two prec confirmations uh are priced similarly to EIP 1559 rather than having gas auctions

in here um and we would like to enable the BR teams to actually decide uh on this pricing but we want the pricing to be premium on top of the base veper gas so uh basing this on a similar mechanism as cp50 59 it allows for easy price Discovery for users and for for wallets and then the uh rollups can set the premiums on top of the um EAP 1559 base fee per gas and each of these transactions can have different premiums on top um this is just the formula for you to to to to get it it's extremely

easy looking into the fields um what's an inclusion prec confirmation it's just a type two transaction with deadline on top of it which is like it's very very minimal uh thing on top of type two transaction execution prec confirmation uh is a little bit more complicated uh but as you can see on top of the deadline field it also has three constraining lists and you probably are already guessing it but they are constraining the state of the resulting rollup because they have the same structure as the um ethereum state it has a storage it has a code and it has a balance list and each of these uh

essentially uh contain the requirements of the user for this uh resulting state after their uh prec confirmation um George you have a question from Joon now please okay hey this is great so far just going back to the previous slide I'm curious if you thought about allowing payments to be made in l2's local token which is probably a better ux for L2 users uh we are not opinionated on what is the the the native token it doesn't have to be it's a decision that can be made for by by each of these by each of the like

what's the native currency of the is decision of the of the RO it's not opinion this is why we're just saying base Fe per gas but you will not see here anywhere we're mentioning like it's that amount of E I see okay makes sense yeah um there was a rollup that we spoke about about van base sequencing they had the same the same question no this is not constrained to to to e um now it's a I guess business and entrepreneurial decision whether you're going to use it or use your own token um and this also come back a little bit to the to the question like

about staking reaking bonding um every different rollup team has a different idea of their business model of their way that they want to operate the rollup and therefore they have different preference whether they want to go for reaking of eat for example or staking of their own token or staking of eat or even bonding yeah um cool I'll just go ahead with the execution per confirmation see if that's good cool all right yeah the last thing that we that I wanted to point out here is that uh the the quick Aster here that if we leave the uh constraining lists

and bound it um they can great greatly expand the the transaction size so the RS must limit it uh their size so that transaction sizes are not like huge what is the flow of prec confirmations it's just a two step process first step is already something that is uh happening naturally it's just eth underscore Central transaction to send up PR confirmation transactions acting as as a request it's important here that that the sequencer either accept or reject them uh acceptance is returning of a transaction hash that is now zero whereas rejection is returning zero has this by the way is already part of the uh of the the ethereum spec uh

eore Central transaction can return actually zero cash so we have reused this property to be completely compatible um and then introduction of new endpoint that is uh ethor get commitment uh and this can be used for the by the user to obtain a pre-confirmation commitment assigned commitment um which is B representing assigned commitment for the um for the for the conf for the prec confirmation transaction that they have uh had accepted and they have transaction hashed um what is the commitment quite an easy thing is a signed um signed byes

by the sequencer that that are constraining two things first of all which transaction hasch this is concerning and second of all which L1 block number the um sequencer is committing that this transaction is going to go through whenever you see these like big question marks I have left things that are discussion points that we can have a discussion on um maybe after I finish the the slides I I'll I'll make sure to have like at least 15 to 20 minutes to to to have discussion on the various discussion points that are here I wanted to mention one and pin one here uh which is lack of time diservice incentive um what I mean here well a rational

sequencer will delay the commitments for prec confirmations until the end of their slot uh because this is where they have the most search space and they're going to know how to extract the maximum value this however can render prec confirmation slow and H user experience um the bad part about lack of timely service incentive is that it's hard to detect an enforce punishment for for this um for this lack of timely service um there are several options that you can use here um timeliness committees is one option that you can use here but it's very very complex whenever you start introducing committees you are moving into a very complicated domain uh another thing that has been

explored by some teams is decaying payments uh so essentially the the later that you commit the later that you're actually um the Lesser that you're going to uh get paid again this is somewhat easy to game and it's also a little bit hard to implement um our suggested option that we can discuss later uh is to have robustness incentive approach uh additional Revenue that is offered to sequencers that are actually consistently offering high quality service uh and this actually can be roll up opinionated uh because this is something on top of the um of the sequencer

payments and this was on prec confirmations and this is still all like a little bit of architectural high level Concepts uh but we went one step below and we went a little bit more into implementation details a little bit more into development and we went into the how do you actually build these things how do we build this onchain what do you need onchain what do you need offchain in order to build V based rollups and V based sequencing and this is where we spent the most of uh our time in our research because um it was it was something that uh it was a new ground that needs to

needed to be walked and needed to be explored and we came up with this scary thing uh and don't be scared too much about it I'm going to walk you TR it um so first of all what we are imagining here is that we are going to to have an architecture that is proposal Centric um and we're going to have a discussion whether having a proposer Centric rather than Builder Centric architecture uh is the best decision there I'm just going to go through and describe what are the components and elements that we are imagining here um and immediately you see uh that the the central point the orchestrating point is the one proposer

and there is something new already uh this something new with the uh red Asterix which is something that we call gy GF boost uh gyf boost is a fork SL update SL upgrade of Mev boost uh its main goal is to enable the connection between multiple L2 pipelines and L1 pipelines so this design essentially separates the pipelines into a single primary that you're seeing horizontally and multiple secondary pipelines the single primary pipeline deals with the current L1 block building uh so the end result of the L1 pipeline is a block that is already built and this is

already existent this is what we know with our PBS we have M boost we have the relays we have the builders and everything that's behind the behind the builders this is how we currently build blocks how proposers actually get blocks in order to propose them um the vertical thing is uh the block building pipeline for it's actually the the the pipeline for building sequencing transactions so for the L2 sequencing transactions so the end result the and the resulting artifact of the SEC secondary pipelines are actually single transactions so the idea here is that we need to actually combine these two so

um the vual based rollups the the sequencer that is our proposer is going to craft um one or multiple sequencing transactions for one or multiple uh base rollups but these transaction actually transactions actually need to go through and get inside an L1 block This is the End idea of this is the the goal of basic thing for for the for the proposal to be proposer to be able to make sure that the transactions for sequence are going to go into the L1 Block in the slots that they meant to in order to do so we are proposing the things uh on top of this upgrade of M boost it's called GM boost by the way G stands just for

generalized uh so it's generalized n boost uh so the we're proposing that the primary pipeline is extended with conditions API which is an extension API to the external block building API implemented uh within the within the relays this is the ethereum external block building API um it's Backward Compatible and it allows the proposer to specify validity conditions over their blocks that the relays needs to to enforce and when I say validity conditions I mean complete transactions uh is there a question okay yeah just thanks for George all right uh yeah um so yeah the conditions API is an extension

for uh of the of the ethereum uh external block building API backwards compatible we are not breaking anything so if somebody just installs GF boost and just and doesn't want to be a sequencer but wants to continue participating within the um within the current block building pipeline of L1 no problem it's going to go through um for the for the for the GF boost in order to um for the secondary pipeline we are Al we are proposing uh something that we call pipelines API um and the pipelines API is the way that the uh proposers rollup notes are able to submit these L2

sequencing transactions uh that are going to go to G boost and then GM boost is going to through the conditions API submitted to the primary pipeline so that the builders actually build conforming blocks uh and I'm going to move on from this carry diagram because I know it's complicated there is a simpler version here that yeah I essentially walked you over it I'm just going to quickly um tell you about each of these components uh a little bit more um GF boost the goal as I said enable the convergence of dl2 pipelines within dl1 pipeline um and enable the proposers to

specify validity conditions towards the external building pipeline so this is why this extension to the external building pipeline uh API external block building pipeline API so that the proposer is able to tell the builders hey Builders I want you to I want you to be building me a block that has these transactions inside um and we want to enable the relays to actually uh check for these if these conditions are met um and GF boost essentially takes the resulting artifact of the secondary pipelines the L2 sequencing transactions and combines them and pro propagates them through the conditions API to the primary uh

pipeline the conditions API uh as I said enables the proposers to communicate with the external uh blog Builders uh there are no breaking changes to theum Builder API uh and practice this is going to be implemented within the relays so that the proposers and Builders can communicate requirements with each other now it's important to think about security of the conditions API uh and in order for the um proposer to be saved from impersonation and so that relays can actually trust the proposer and that the proposer is submitting them these conditions uh it requires authentication and this is another

discussion Point here uh what is the mechanism for authentication of the of the proposer in front of the relay what we're proposing here is that authentication happens via the validator signature it requires uh again GF boost to have access to the validator key signing facility and I know that this sounds egregious and it sounds outrageous but we feel this is fine because first of all GF boost is a software run by the stakers themselves uh keys can be accessed the same way that the validator software is accessing them so you don't need to send them to third party or whatever it is there it is still a thing that is on your machine and is only accessed uh uh by your own

software that you're installing and yeah there is no third party that's getting access to your validator case and through this casys uh we can authenticate the communication between the proposers and the relays um we can have discussion later on on this uh I have pinned all of these discussion points so that we examine them later um pipelines API uh the pipelines API serves the purpose of enabling the communication between the L2 rollup nodes and GF boosts um again um this communication between GF boost and the secondary pipelines needs to be authenticated uh similarly to um this is this happens in order for

GF boost to be able to trust requests from the from the secondary pipelines uh and the two components um are going to be authenticated in a similar manner that is happening uh that the authentication is happening between the consensus and execution their clients which is JWT tokens this something that thers are already familiar with uh so that um yeah essentially want to prevent that unauthenticated um actors are just submitting L1 L1 transactions for you to sequence within your L1 slot you want to have uh only only your own sequencing rollup notes to be the ones that are submitting these uh L1 transactions that need to

get included within the L1 blocks and these are the sequencing transactions um and then finally combining after we have the two these two apis uh essentially GF boost combines whatever we receive from the secondary pipeline and sends it through the conditions API to the primary pipelines I feel I said this like several times but I wanted to hammer this point like that although this thing looks very scary and very big it's actually quite quite an easy thing you have uh the vertical thingss uh creates you several transactions and the horizontal thing includes them within a one blocks

um pway API specs and software modifications required are existent within this HCK um I can send you the uh links for for this later in the chat and in the telegram group and something that I promis that we're going to be talking about which is choosing the uh pipeline orchestrator as you have seen um there is there is an implicit requirement for Bas sequencing to have a mechanism uh for submission of the L2 sequencing trans transactions within the existing A1 pipeline right well if we are sequencers we need for we need a way for the L1 sequencing transactions to end up

within the L2 blocks um and then we need to to ask ourselves a question well there needs to be an actor that receives these these submissions these transactions and we're going to call them the orchestrator uh and they need to make sure that these transactions get included within this L1 block so who's this orchestrator and we have two options for this this orchestrator one option is to to use the builders as orchestrator so essentially what I'm saying here is that one option that we can do is essentially ask the wallets to go to the builders and ask them for pre confirmations or to go through the gateways and the gateways are going to go to to the builders and ask them to include these transactions uh within their

blocks um and this has both prons and cons uh the obvious advantages is that the builders are already sophisticated and highly available uh and it requires little to no modifications uh to the existing software because the sequencers or the gateways are going to be essentially acting them as acting as a Searchers for them uh but the downsides are that we can have something that that we've called The Godfather of rollup syndrome uh which is something that hurts the roll of sovereignity uh what do I mean by Godfather of roll of syndrome well think that we currently have um a very small group size of Builders any Europe

that wants to get to be supported by these Builders would need uh to get some form of blessing of the builders in order to be able to to to even get started to to um to have their roll up serviced by the by the builders so that their gateways so that they have access transactions from their gateways um and then this uh this is a thing that it might be it might be problematic it might not be uh something that we are basing our thinking of is that there were ecosystems within the wider blockchain community that exhibited this

godf farther rup syndrome and there were networks like there there are systems that in order for you to have to launch your own network you essentially need to go and ask for permission for a blessing of several actors and this led to less and less decentralization less and less uh networks being being launched uh and the second uh I think obvious downside of having the builders as orchestrators is the smaller group size uh and this can exacerbate geopolitical risks I actually saw Twitter threat quite recently like couple of hours ago that made somewhat similar point that um there are geopolitical risks with the

current Builders U ecosystem that might materialize within extreme scenarios another option than the builders as orchestrators is having the proposers as orchestrators so what do we have here as pros and cons well this is based on why diverse decentralized group of L1 proposers like this one of the highest strengths of of of ethereum and it enables for permissionless creation and operation of vanilla based rollups I mean what I mean by this is that worst case the rollup team can actually run multiple W one proposers opting themselves and this is a form of progressive decentralization because they they might start with only own

their own proposals but then any other proposal can just start joining in uh the downsides of having the proposer is orchestrator is that it requires the adoption of um modified version of uh M boost the GM boosting uh that is used to orchestrate and uh delegate to the external block building pipelines all the things that we previously spoke about GM poost and this is uh something that needs to get adopted by by El one proposers um we have chose we we have chosen to go with this idea to have the proposer uh as orchestrators um our main worry is the

that is the downside of the builders becoming Godfathers of any rollup um and we feel that if GF boost is developed and it's strictly better and more profitable for proposers to run GF boost then they're going to uh run GF boost last thing which is the onchain part how do how does actually one sequencer opt in uh and how does uh user wallet discover and communicate with sequ ERS um sequencers optin well the goal for sequencer optin is to enable L1 proposers to optin as sequencers to rollups and advertise their

rpcs uh we're imagin that this is going to happen on chain through a two-step process uh process of registration and process of activation um the process of registration is for sequencers that are uh active validators uh uh to is used to advertise their RPC Euros validate BLS public keys that are going to be needed to check them out and they're representing uh wallet addresses and the registration requires um signed message by the proposer so that they can be uh checked whether they are valid uh and active um proposers um activation is mainly used

in order for rollups to be able to to Define their own activation criteria and this is where we again go again into staking reaking staking a feat or maybe staking their own native tokens uh but this is what activation is for after you have registers you need to activate by staking for example sequencing mechanics how do sequencing contracts actually like the sequencing contracts need to know um if the currently submitted uh sequence is sequence transaction is by is performed by the currently eligible sequencer and this actually was is is uh surprisingly hard uh because uh as the memes says One

does not simply know the current L1 proposer uh you have no access to the current L1 proposal you have the previous one uh but you don't have the the current one um so we are suggesting several Solutions two of them are implementable now but are somewhat suboptimal there is a third one that requires hard fork and as Conor from mm mind has said previously uh we don't like too much solutions that are requiring several Forks in order to come through life so uh the first two are at least implementable now um you can have optimistically accept all sequences and include the verification of the eligibility of the sequencer within the

uh proofs of finality um or enable challenge challenge period uh the third solution that requires Fork is to actually to ask eum L1 to just tell us who's the current L1 proposer so that we can do the checks that are that are necessary um sequencers Discovery how does one wallet actually know who's the sequencer because the previous thing was how does a does the rollups contract know that this is the eligible sequencer well u w just need to check the um rollup contract the taking contract for that is we're calling here the sequencer registry and by the way for this we also

have a full specification with the interface that needs to be complied with um and within the sequencer registry you can just see uh who's the who's the who's the current um who's who's the next eligible um sequencer you for some in some cases you might need to perform some uh Det terministic Randomness algorithm in the fullback case in order to figure out who's the eligible sequencer but if the current uh A1 proposal have opted in you just need to figure out their advertised RPC URL and just talk with them um and then as I said in the registration Point uh opting in

proposers validators are just advertising their RPC end point and then wallets and users just use it as normal RPC endpoint and yeah this was the onchain part I left several discussion points maybe I'll just tell you what are the next things that we are that we are planning and then I'll just open the floor for questions discussions and think that's there so currently what we are applying for is uh proof of concept with Tao uh in order to be able to showcase the viability of vanilla uh sequencing in the meantime we are exploring the creation of GF boost so would love to talk with the flash BS

team on this um we are also uh uh currently drafting uh RP for the information transactions that I mentioned in the beginning of the talk uh and we are also contemplating on suggesting an EIP for the conditions API uh because the conditions API can actually be used for much more than just uh L2 sequencing transaction actions and we are looking to talk with any rollup that is um willing and wants to explore base sequencing vanilla based sequencing per se on what it takes actually to to to implement vanilla based uh sequencing and yeah that's a wrap and I

have left the discussion points so that we can have discussion if anyone is interested into any of these I see Jonas has several questions if you want to go for I yeah I had a quick question but I might just be misunderstanding a technical point if you only expose the BLS keys on block n minus one for the proposer block n can't you just create a requirement that every base sequencer has to finish the sequence by posting to ethereum State like the the the block and um BLS keys so you have this invariant that it's always in state unchain for black end um so whenever you're see what you're

suggesting here is that whenever the current sequencer is posting the current sequence they also uh provide the next sequencer BLS key is this what you're suggesting yeah there's something interesting to to to explore I have to think more and yeah let's collaborate on this this could be a very interesting um very interesting solution yeah absolutely and I have I think Max has a question great yeah great presentation I'm just wondering what the what this kind of architecture does to L1 proposer bandwidth Hardware requirements um as

you scale it up in terms of transactions yeah well this is going to be best answered when we when we finish the gmf Boost architecture uh one thing that I think it's important to be mentioned here is that we are designing this system to be delegatable uh so that you don't need actually to run additional softwares uh apart from upgrading or replacing depending on how do we want to implement GM boost uh of of M boost so uh we are we imagining that this is not going to have uh massive impact on definitely on on on on hard disk uh maybe leaveit on CPU but then again like the thing that

the that that that GF boost needs to do is just to take two transactions and forward them to the primary pipeline it's not a gangster boost yeah pushes transactions and it doesn't need to doesn't need to do any processing yeah it doesn't need to execute them now no it doesn't need to execute them it's just almost like a dum pipeline just needs to combine them into a single request for for the for for your lace okay cool um I see a raised hand yeah um hey George this is also very enjoyable what I wanted to touch on was more of a kind of I don't know a

request or a bias but what you mentioned about delegating um the BLS signatures for the like you know the actual hot Keys having them like sign stuff regularly can be kind of slow particularly in a kind of a block building context most people favor staying in the K1 side of things and my bias towards that is I'm one of the like team building distributed validators and we have you know all of these different like normal validator clients working together to sign single things with fall tolerance and the thing I might suggest is in that message you said where it's kind of like a you know Builder registration M boost land is that you very much try and favor something that's very deterministic and maybe specify the timing of when to resign because what we

ran into with me Builder registrations is they have a non that you can you know increment whenever you want to kind of update your address but it's kind of more or less left as an exercise to the implementor of if you want to do it more often just to make sure that the relays you know remember you and haven't forgotten you and stuff and all of the different clients wanted to like minimize how often they did BLS signatures didn't want to do it on the turn of the epoch and did different like you know little games and did things a bit strangely and it ended up with the world where we now just signed the MV registration once um and that could work and you going the delegated route which I think is probably better but yeah anywhere with with the BLS signature the more like deterministic it can be and

the more like timing specifi the more I'll be able to like aggregate them across you know five different client teams that do it slightly differently yeah let me try and repeat it and I definitely want to follow up this with you because you seem to have worked a lot in this part of how do you authenticate validators but uh if I understand correctly you're proposing a two-step process where uh the first step process is initial registration of the validated with the registration I'm I'm I'm I'm fearful if I don't want for us to have a breaking change of the current external Builders API so if we can avoid this this is definitely better and then just the second step is uh exchanging um uh other forms of authentication with the relays and this is this more robust

form of authentication to be used whenever we are submitting um conditions for for the conditions API yeah more or less I think if you didn't want to break existing apis you could probably just accept a builder registration method and separately accept like a beacon State proof that that you know Pub Key is active that's kind of two separate calls so that's not going to break anything um and coming back to your think about you don't know who the proposer is in a block you just kind of let anyone you know use like push transactions or something but yeah you only have people opt in and like slash them if they come from yeah I haven't fully thought I that that that proposal side but yeah if you didn't

want to change things I think the bill registration is a legitimate you know proof of the existence yeah on the on on on the twostep process one thing that I'm I'm fearful U now that we're having this discussion is also I don't want to dump too much too much more new processing to to the relays uh because I think that they are going to actually take the burden of a lot of the the processing they are already doing this but I don't want to to over complicate them with each of these um which with each of these calls so yeah there's definitely something more to be to be explored there thank you uh H was up down he's down okay there is a question from him

in the chat is the rap public no but you can look into by the way all these um I'll share the links in the in the group but what is going to be in the rip is going to be the thing that I talked about the fields here in the pr confirmations thing like these two things essentially making them into formal format of RP plus probably the conditions Jonas hey uh George great presentation oh

Loren um so I had a question question about what happens when the fallback um sequencer cannot include like their batch in time and it overflows into like the next uh the next sequencing window yeah um this is the unfortunate consequence of you not being the L1 proposer uh what we're suggesting here is two things first of all having much lesser penalties for liveness folds for fallback uh fullback selected sequencers and second of all obviously uh bum bumping up uh the the tips for the for the builders in order to be able to uh cover for this um what I'm imagining is that with time

uh fallback selection should go down and primary selection should go up because it's more favorable for you to be a primary selected uh proposer and if it's strictly more profit for you to also be a sequencer for multiple rollups within your validator um um then we're going to have more and more participation which is ultimately what we're looking for within Bas sequencing right and maybe another thought is like could you potentially if you fail to include could you potentially rely on the next uh kind of proposal to include it since assuming that they they're already building uh upon your pre-confirmation [Music]

as as long as they are willing to and as long as they know about what you have actually committed to because think about the communication is literally point to point like the next sequencer might not even know what you have committed to oh okay so the commitments are not publicly BR broadcasted in this well you have a single RPC that is getting hit by everyone this is why we are having leader election okay we have not proposed a m pull for for all prec confirmations or something like this because now this requires coordin this is going to definitely in increase the requirements sophistication requirements for all validators that opt in into this uh to have mol between all of them okay thanks cool any more keep them

coming no all right cool uh we arrived with three minutes early um I guess thank you guys for for the time thank you for the questions I definitely want to follow up with um some of you on the different ideas that you already gave us here uh and I hope that you find this uh Concepts worthy of further exploring if so please do go ahead ping me up in in Telegram and yeah let's chat more about it um back to you Justin perfect thank you George so this is the end of the public part of the call and I guess we can open it up to

the the private uh off call