Ethereum L2 Standardisation: L2 Transaction Fee API and more

Transcript

hello and welcome everyone my name is Peter Robinson this is the ethereum Engineering Group Meetup and today we have Andreas and he's going to talk about L2 um standardization so Andreas before you share your slides would you like to briefly introduce yourself sure so um Andreas I have been in the blockchain space since 2014 um actually to run a note on Olympic that was fun only shortly but it was fun um uh my moniker is is the blockchain with army knife um head of uh technology of the uh Global blockchain

practice at other consultancy services at one point then um at consensus um now um uh I was three startups now there's the my third one um is interweave uh Technologies where we're um providing um um multi-enterprise Earp Solutions um to uh Telco companies using um privacy enhanced layer tws um over public ethereum before that it was tree trunk um and um I am working across the entire stack so both from an

infrastructure point of view so involved with companies that work on on on ZK hardware for example um to protocols to um uh to um application STS um decentralized governance decentralized um like to tokenomics um as well as legal and Regulatory questions so I'm I'm covering the the entire um Spectrum um and um uh Al my own company where I provide um advisory Services exp technology Consultants so um as part of that I'm I am co-chair of the um uh ethereum open project uh um

Community um Layer Two standardization working group um that's um managed by and supported by Oasis so I will um actually start sharing my live because that's where things starts do that so um you know um just set that so um why do we need a formal uh uh or why do we need formal standards for L2 four primary points number one facilitate discussions between L2 projects um developers and other

interested parties such as Enterprises so that is where the long-term money is unless you bank on your pump and dump coin that's true you need it's like the Enterprises will be the the primary users of l2s if that is actually going to stay a thing um because they perfectly suit um Enterprise uh requirements once you you know um look at it a little bit more closely um so that's one the second is to promote interoperability and better alignment across the L2 ecosystem which is highly fractured um and um also very important especially for for for Enterprises and governments uh you um

they're more comfortable adopting new technology when they're based on formal standards developed by respected standard bodies atfw 3C Oasis and so forth so that's the fourth point so hence Oasis and um the last point is to level up on quality of standards and specifications in the ethereum ecosystem which is really needed getting better yet you know it's still by far not there um at the level of like an you know Oasis w3c or ISO so uh this is where we're trying to take um uh the work that the that the um uh group is doing um which means there's there's a lot more

work that needs to be done from a standard point of view than what for example eips are required to contain they're improving they're getting better um not going to rat on them they're they're wonderful they're wonderful people um it's just needs to to to take more need to be higher quality um and but we're we're getting there so um so then the quest is like then wait well like why ethereum Community projects managed by OAS right um number one Oasis is the story nonprofit technical standards body

that was formed in 1993 so like Sam standard and everything they did um so there is um a lot of prestige that is um that enterprises um recognize and um behind that that and um we can do it in open open source um and standards development um um and that is also important not only open source but that we have open source standards and their respective reference implementation and so this and know Asis open project for ethereum related work

was started in 2019 by the ethereum foundation consensus and the EA um uh it has low bureaucracy and flexible standards processes um lot more rigid than um in the IP process or RP process um but significantly less so than for example of w so why so we have that that's the why um it has a you know you have a well-known name um that is knows how to do open source you have some um good support at startup and you are creating um you're you're trying to

interpolate between w3c and an EIP so um to to get there so that's the that's that's why and this was possible within this context of of um uh an oasis um um within the Oasis Community project so there are multiple Community projects ethereum one is only one of them the key poke sorry key focus is Enterprise friendly but inclusive of the entire ethereum Community um so participants that we have um in the working group are metal lab um we have arbitrum offchain Labs optimism metas scoll linear Accenture eny polygon the

EA C working group and a few more um so you can see it's a it's a it's a it's a uh big mix um and um uh that's exactly how it's desired to be so what's the scope so four items so identify the most relevant use cases and business requirements for Layer Two um uh number uh number two is developed technical layer two standards for both ecosystem and Enterprise requirements

with a focused on interoperability um three is how to tackle layer two specific challenges such as me concentration like me tvl concentration Etc within the scope of Layer Two um and then uh last is identify characteristics of layer 2 blockchain environments that are key to address mainstream and Enterprise adoption so the group has been mainly focused on the second one um um because there were those were the lowest hangings group um that brings me actually to the standards development approach so looking the was find

ecosystem relevant topics with an eye towards the Enterprise number one number two what are the low hanging fruit right we're we'll tackle tackle those first and then third standards must be small in scope to iterate and finish quickly because the standards process can be year and a half two years three years so the point is let's create like you know a small scope and then um uh finish it quickly um iterate and then get it out and try to get reference um implementation so that's the development um s development so let me pause here

for a second any question up up to this point sure if no one else has got a question you you mentioned the EIP and rip process um and the and Oasis and um so what what when when would it be appropriate for a standard to be being say um standardized or something to be standardized in Oasis group rather than say via an rip or would you would you aim to more formally standardize something that's already an RP in Oasis how would that

work do you think so currently what we're doing we are actually so we're going the other way we're going not r the EIP to St to to to Oasis standard we're going we're taking Oasis standard and then we're creating eips so they're there and I'll I'll talk about that in a second okay um but we we can also take um we can also take uh um eips or rips and um work them into a more formal standard um there currently has not there there currently was enough lwh hanging fruit um uh on stuff that had not been addressed by rips and

eips that um uh we didn't have to look at that um and we there's probably enough to do um for the next couple years that we don't have to do that but eventually um uh this is going to this is going to come up yeah that certain things that are really key um should be uh taken to to a more formal um to formal standard yeah that makes sense thank you oh thank you for the question very good one so um uh the group was launched in 2022 um uh officially beginning of 2022

so we are only in year three um halfway through year three so um what do we have we have um e canonical token list standard so that's an official Oasis start standard draft with one active implementation linear and also an EIP and draft status um and uh then we have an uh evm based address aliasing uh which is again an official ois staff and E and draft status and uh then we have an L2 transaction fee uh standard um that is an official aasis standard draft and an

EIP and draft that well actually I I have not submitted the pr yet it's ready I just haven't been able to submit the pr that's why there's no link um I just haven't had the the time yet so we have like three fully finished standards um uh and we're we're pushing them and we're also discussing them in the in uh in the appropriate forums of uh the you this fors uh we have a fourth one in in in draft where um it's finished we're just collecting approvals and that is an L2 transaction fee API so we have the L2 transaction fee standard and now we're

we've uh created um uh an API over API uh spec over that um important point to make is that any official Oasis standard draft needs two reference implementations to become a full standard that's that's important so there's actually needs to be adoption um in addition to that the L2 standards working group is also P publishing a glossery of L2 terms in coordination with L2 uh beat um based on finalized draft standards so whatever we have um from these three um we have put them into into a gloss um in order to

standardize on the meaning of words which is important because you know when you hear the word like um L2 finalization or L1 finalization that means different things for different people so and actually we we see an example of that coming up shortly so that's you know that's that's for for two and a half years that's not that's not bad at all um what do we have in addition to that we also have public Publications and collaborations um we have um two formal reports there's an update on the state

of l2s it was published late last year and it's based on a previous report from 2021 um linked uh I've linked those um there are um three blogs um uh the um uh the last one the third one is um uh how w3c DS and VCS can help with ethereum's three transitions is about to be published by the ea uh current state of L2 bridges that report was published um in the spring of last year L2 digal assets with residual payments was uh published in

22 so um so besides standards we're also we also producing reports and blogs uh we have active collaborations um with a roll call um working group uh so that's an L2 working group supported by the EF um we also have a loose collaboration with L2 beat and uh also uh we're we're doing cross information with the EA cross train inop working group because that is relevant direct directly relevant to to um Layer Two Bridges so um yeah so that that's that's the scope that's the um of like

achievements of the of the working group in the first two and a half years of it of um distance um let me um go on so before we go on to the the current work item which is actually L2 transaction statuses let me pause here for a second um and ask any questions so far on the on the on the work items that I described the standards um the reports blogs collaborations all right it's I know it's a little dry but you know that's

what standard work is it's dry work um so what's our current work item um that we where we just started it's L2 transaction statuses of this this come up there was a long discussion in the role called telegram group and also in parallel in the L2 standards working group in context of the um L2 transaction fee API right because if you want to know what the what the if you have submitted a a transaction that's running through its life cycle you know and you get a get and you want to see what the fees were you also want to know what the current transactions St

is so came out there's like really no remote agreement on on what uh um on what the different statuses are what they mean what the trust assumptions are um so uh the working group went ahead and uh drafted a minimal set of transaction statuses that we published out on on The Magicians page as well as uh on the rip as an r on in the rip GitHub as an issue um and uh we'll we'll also um see if we can we'll also probably get a

breakout session organized um around that topic um so let's get right to it um so these are the statuses would love to get some feedback from everybody here um so and they're like sort of like in sequence of the life cycle so first is L2 pending so that's an L2 transaction submitted to an L2 and waiting to be processed by a sequencer um well the trust assumption here is like no inclusion guarantee on the L2 uh then we have L2 replace so an L2 transaction that was pending was replaced by another L2 transaction this assumption is the same as L2 pending um L2 drop is an L2 transaction that was

removed from the L2 processing queue for whatever reason um there's no trust assumption there just it's gone um so those are the first three statuses any thoughts comments on that first Set uh hi Andreas yes so there are some there's at least one obvious one missing there uh which is like an L2 active or something one that's you know a transaction that's been accepted by the

L2 and is in progress oh yeah yeah know that these are just the first three there there there there are five more statuses coming yeah okay all right that's what I was that's exactly my question thank you so then there is the the next one is L2 confirmed so an L2 transaction processed by a sequencer and assigned an order in a proposed L2 block by the sequencer by applying an L2 client specific L2 transaction ordering protocol the trust assumption here is the L2 transaction order guarantee is based on the security guarantee of the ordering protocol inclusion in finalized L2 and L1 blocks is not guaranteed next status is L2 included L1 pending so

an L2 transaction included in an L2 block but not get submitted to the L1 so the trust assumption here is the L2 inclusion guarantee is dependent on the submission guarantee of the L2 block to the L1 and L1 finalization and then the last two sorry there were not five only four the the the next to last status is L2 included L1 included so an L2 transaction included in an L2 block submitted to the L1 TR assumption here is the L2 inclusion guarantee is dependent on L1 finalization and then the last one and I actually didn't update it there's

already an update to that it should be um it's uh um yeah no no actually no this is already the the updated version sorry is L2 finalized and L1 finalized so an L2 transaction included in an L2 block that has been included in a finalized L1 transaction the trust assumption here is that the L2 transaction finalization guarantee is a equivalent to an L1 transaction finalization guarantee in a finalized L1 block so looking at these seven statuses anything that's missing anything in the definitions that should be should be changed

anything in the trust assumptions that's not clear so it seems to me that depending on the L1 you're talking about L1 finalized can be a pretty fuzzy concept it can be statistically uh finalized and yes so different L2 TW are going to have different definitions uh or different opinions about when it reaches that final state has there been discussion around that you mean well I mean the the the uh

um from a from a yeah so when they're when they're considering the um an L2 transaction safe um in ter of what the what they uh um whether they would allow another transaction to work on the new on the state that was created um that was updated by that transaction well yeah so you have you know certain l2s will submit L2 blocks at very different times and or at very different frequencies you know some do it every couple minutes every some some do it like every two or three hours right depending on on for you know like

ZK EVMS it's they're they're they're doing it at least now like hour like hour and a half two hours or something like that uh sometimes even even even less frequent um so but they're not apping on the um you know And1 finalization they're taking as as as as given by what the L1 is is being called finalized right so ethereum is that's not right that's not right they're they're making a judgment themselves rather the L1 status state has finalized and different l2s will have their own opinions about

when that occurs well there there is no place you can go to on an L1 and say this L1 thinks this state is finalized that's generally not how it works well in ethereum that's that's you know there's you actually have have finality in the in the um um when they when the uh yeah in ethereum POS you're trying to say yeah after after you've you it's locked in it's um you're locked in exactly 101% finalized takes 12 minutes though but still yeah it takes takes 12

minutes so it it it it all depend they're making a judgment call as to as to the the probability of a of a reor occurring and then having to an L1 reor occurring and then having to resubmit the L2 transaction yeah right they're not going to like Wipe Out the L2 State yeah right they're just if there's an L1 reor um unless there's there's an L1 reor that impacts the um that impacts the um L2 because there there are exits or or they're withdrawals or or or deposit right I mean then obviously

you're you're rolling um then you're rolling you're rolling the um the bridge contract you need to roll the bridge contract back yeah right so um otherwise yeah of course you have a you have a it it it is all depends on what is then what is what finalized means for a given L1 whether that's probabilistic you know or deterministic right so well that's that's why I said it depends on the L1 but on any on any L1 where an L2 has to make a judgment

called different l two they're going to have different levels of comfort right due to their implementations so I wonder what the Practical use of these transaction statuses would be even if they comply with the standard they're going to interpret it differently so what's the what's the value of these transaction I agree you could standardize them I just don't know how it helps one L to talk to or interact not no this is this is a this is about this is about um so this is about

um uh um that there is a that there's there's consistent it's about for wallets and end users right so that that there is there's at least a a a consistent set of words that are being used do they have to be contextualized within the L2 and the L1 Ed yes right but at least you you have a a a you know you don't have like three different three different sentences describing the same thing right that is that is that is super that is that is super super

confusing what is indeed true and what what hasn't been done yet and what is the next thing is actually to give a definition of of finalization and then categorization of the different l1s what fin what finalized means yeah right so once you once you create a definition of of finalization on an L1 you then need to categorize the L1 oh I assume that this standard is really just targeting having ethereum as the L1 isn't it or is it more broad yes because it's yeah because the because the the L2 working group is only is only targeting evm compatible chain yeah

right makes sense um so I I there is a a a state that I don't think is covered by your statuses so um some l2s rather than posting all their transactions to ethereum post the a um post their transactions to a data availability layer like Celestia or I da and um then they get a DA certificate which they um then post to ethereum and so you could imagine when you've posted the transactions to the

DA um but the da certificate hasn't hit L1 um you know you can't really say you're L1 included so you're L2 included but you're L2 included and now it's hit the da so if um you know and it depends on how you are going to derive your chain if L2 blows up um you know whether you're going to use what's on ethereum the da certificates on ethereum plus you're going to try and in use some of the the information in the DA for that say 1 hour between when the da certificate was last posted and when you know the information

that's posted been posted to the DA in meantime um so you know it depends on how how the chain does its derivation as to whether posting to the DA but not having the da certificate on ethereum is in is helpful or not because if you're only ever going to derive L2 state from the L one contract based on the da certificates then knowing something's in the da doesn't really help you right it's it's you know it's basic you know where you store the where you store the the the um um you know full-fledged L2 transaction is is in the

end is depends on is isn't isn't is implementation specific right some some use you know post them into blogs other use you know it's like it's like you know data availability layer um so and they or combination right they're posting them as blobs and then they're they're um also running a um running an an uh um uh running a a um a node consensus node and then keep that keep that um uh do not discard the The Blob data and keeping it as an archive node right

so there are different types of implementations how you how you achieve data availability um I think this is all sort of like subsumed in in L2 included L1 pending um that becomes then sort of like you need to say for this implement this L2 implements the status L2 included the following way or L2 included L1 pending the following way right what's the specific implementation what does that mean right so L2 transaction included in L2 block but not yet submitted to the L1 but it could be okay has been posted to

the DA we have to wait for the da certificate and then we're posting that as a transaction to the um one right or it's it's it's a blob um transaction right so um there is a need for a bit of fuzziness like in the statuses in order to not and that's always a a a fine line that standers need to walk um to be not too opinionated about a spe about specific specific implementation if that make sense yes yeah that does make sense otherwise it's

not a standard it's just a specification of a product so exactly exactly so it's like you know what you describe swal that fairly large bucket of L2 included L1 pending there's like all kinds of like Nuance there right um that is really implementation specific yep sounds good any more comments questions so I just wanted to give uh at the end a couple of uh um uh reference points so we have a GitHub repo the

Link's there we also have a slack that's the invite link so if you um click on that you you can sign up to our slack um we have regular meetings every two weeks um at 7:00 a.m. Pacific 10: a.m. eastern uh 1500 hours GMT um also posted the the zoom link um next meeting is July 24th um you can always reach me on email um or telegram or an next um email on telegram for her um yeah that's um uh that's it um so far um any more

questions comments not for me because I've already asked my question or two but um but from the floor we we have um have some people here but um yeah I mean I I think just the idea that there's a a standards group you know and in Oasis looking at this stuff um so it's not just say the EIP or rip process but something um that I think big companies are likely to be you know able to listen to um and you know like

fix their boxes is very interesting all by itself yeah okay why don't you flick to the next slide then and um I'll quickly present so we've got a merch store which is open still selling T-shirts and the next slide um okay we have two talks coming up um one is Ley who's going to talk about Unis swap V4 and another one is by David Highland Wood and he is going to be talking about

um Ai and web 3 um and um both talks should be U really good I mean just like this one here um and I know there's a last slide which essentially show tells you how to um so if you're here today there's a YouTube channel if you're watching this on YouTube there's a slack invitation link um to join the convers and then there's the um link to meetup.com all right so Andreas thank you very much um for your time today and before you run away are there any final questions yeah anything you want to ask

me it's totally fine um I've got a question actually which is not related to the standardization and is not what's your favorite color or anything like that but tree trunk it was a great project showed great promise where is it now what happened we launched on June 19 2022 okay that said you know it was into the teeth of the of the of the crypto winter yeah tough time tough time it it was the the timing sucked if we

had um if we had had the idea three months earlier we would have been okay we would have been probably some somewhat okay we would have had enough investment to to to to keep on going and finish what we wanted because you know one of the things that we were about to launch was um an NFD having its own um its own website where you can actually that you can embed into any other website and you had the full functionality to actually um uh buy that NF if it if it was for sale yeah yeah oh that's a real pity you know me you've got great Tech but then

it's it's timing is everything with startups startups timing is timing is everything it was it was just not it was just not and also it was um one of the problems we had was that we could not go to uh um ugc so user generated content so um it was just not enough time um between when we had to launch to where we could guarantee that you know you wouldn't um post you know um uh create nfts with pedophilia or not Nazi symbolism or or things like yeah yeah yeah all that sort of yeah yeah all right well look Andreas thank

you for your time today um have a great day and everyone see you in another couple of weeks um thank you this is actually I'm always enjoying the um the recordings okay well well that's great well thank thank you I um yeah we always try to always try to find speakers who've got like yourself who've got great content to share so yeah and one thing that I that I that I totally found which I love is like is like not the greatest developer but using like GitHub co-pilot and find I have been able to like build an entire um smart Erp module on the smart contract system using um The Diamond

architecture in like less than four weeks yeah wow pretty good yeah I mean with with it was it was um you know with with uh something that has actually passed through you know the Dilly fuzzer without problems yeah that was like that was that was I was I was actually surprised so yeah all right talk later bye bye talk later cheers bye