All Core Devs - Execution #101

Transcript

[Music] [Music] [Music]

[Music] [Music] so [Music] [Music] [Applause]

[Music] so

[Music] [Music] so [Music] hello everyone and welcome to ethereum

core developer meeting number 101 i'm your host hudson and first we're going to talk about yellow v3 and the berlin klein updates mica has been kind enough to write up some documents that are in the last comment on the agenda if you refresh the page and he would like some time to give an overview of everything which i think would be really helpful as we're talking about some of this there's been a breakout room discussion there's been discussion on a few different discord channels so um he'll give a summary and then we'll go through first the outcome of the large basically just all the stuff that mike is about to talk about i guess and see if we can get some berlin

eip final go and no go based on our decisions or what we can come up with today uh so micah you can go ahead okay some of this is probably going to be review for some of you but i want to make sure we're on the same page i will try to go through it relatively quickly so those of you that already know it's know most of this don't have to suffer through a long presentation or anything let me share my screen just so you guys are seeing the document that i'm referring to and do you guys see that yes okay so this is one of the documents linked

over in the agenda this is the ssc and type transactions this is right up by piper it basically just goes over kind of a little bit of why why ssd is nice and how it integrates with type transactions potentially uh the main thing i want to talk about with with ssc here is just to try to get everybody on the same page or at least understanding each other if not on the same page of why there is value in switching to ssd that's come up several times for many people that ask well why ssc instead of rlp the core of it comes down to uh two things one as of to the merge blocks will be ssc is the pl that's the current plan and i believe that the e2

team is 100 on board with that and they fully intend to have blocks be ssc encoded rather than rlp encoded and the block hash will change to the merkle root or the ssd merkle root for that ssd included block what this gives us is a very interesting property that you can actually using a single proof and the latest block hash you can prove the contents of any ancestor of that block all the way back to whenever you started introducing whenever we introduced as a z block so as of the merge every block in history will be able to prove with a single proof

and the latest block header or the latest block hash sorry um that's obviously very powerful because it lets us do a lot more um we like there's a eip right now of saving all the block caches so just so that we have the ability to do proofs of blocks that are older than 256. um with ssc blocks we get that for free plus on top of that you don't actually need to transmit the block header like you do right now so right now if you want to validate a block on chain or something you need to have the block header and then the like parent hash or whatever and then you can verify those two match with ssz blocks we can actually prove individual pieces of data with just a proof not without having to transmit the entire header what's more is you can actually do this recursively down into

transactions and receipts as well so in theory you could do something like prove to me that uh there was a log with this index 10 million blocks ago and with a single proof and the latest block hash you could get that and so that's kind of the very high level overview of why ssd has value to us um in the in the future because it lets us do some really cool things with proofs and there are some other tangential benefits like you can with with the proofs if you have very large data structures you want to split across multiple blocks or multiple packets and you're using some like udp that has packet size limits then you can um prove that yes this half packet or this this half payload that i sent you in one packet

is actually half and i'm not just dosing you and sending you garbage data so those are minor but the big one is recursive proofs from the hash of the latest block so moving on and again i'm going to go through this very quickly just so we don't waste everybody's time since i think a lot of you already know this um in order to get that kind of recursive proof stuff it's very valuable if the receipt's roots and the transaction route is also sse instead of a traditional mpt so if we have the an ssd hash here for the the transaction route and the receipt route inside the block once the merge happens then we can do things like i

just described with the getting a specific log somewhere or deep in history oh this is good to know alex cruz are linear in history yeah i was writing in chat to avoid questions so normally i would agree with you uh but this is important because no one told me this over the last like two weeks that i've been talking with people about this okay let's let's move past it for now um i'll we can research that more later um so the idea is though we want sse and from the people i've talked to i think most

everybody is generally on board with ssc long term for most of our stuff that's in the block so the transactions and the receipts and the block itself so that gets us over to type transactions this document i'm not going to really talk about it's basically just discussions about all the problems we run into this one's the interesting one so basically what it comes down to is we want 2929 into berlin that one's very important because that's 2921 is the gas cost increase for state access opcodes that addresses some dos vectors against ethereum so we really want that one in and we want to launch berlin like those are our two things that we really want to do is launch berlin with 29.29 we can just do 29.29 by itself nothing

else however the disadvantage there as we've discussed is without 2930 there may exist contracts that are unable to execute within the gas limit due to the gas price increases and there may also be contracts that now become broken um because the gas costs increase and they were dependent on low gas costs and so because of that we want 29 30. if we then add 29 30 in that's great the disadvantage of just doing those two alone 29 30 is optional access list if we just do 29 30 and 2929 we do not introduce 27.18 then what we end up with is uh basically a bunch of technical debt because we're introducing a third transaction types we currently have pre 155 post 155 and they're kind of the same shape but

you switch on the value of v to determine which type it is we'll now be introducing a third transaction type without any sort of type mechanism or versioning system which means we're gonna have to both switch on v for one five five one five five and we're gonna switch on the length of the ro the number of items in the rlp encoded array for that so that leads us to well we don't that kind of sucks we don't want to just introduce all the technical debt especially if we know we're going to do 27 18 or something very similar to it in the future so that leads us to okay let's add in 2718 if we add in 27.18 on that um transaction discrimination is dirty to say it's not not as bad as without but it's still dirty because now you're switching on that first byte and then if the first

byte is different you have to switch on the the v value not too bad um not not amazing but it's not terrible it also introduces technical debt because um if we just introduced 27 18 we do not introduce ssc which means they'll be rlp for 2930 transactions and legacy transactions then we're basically saying yes we all agree we're going to do ssc transactions down the road but not yet and so we're just introducing a new piece of code that we'll then have to change later which means we have to go through some sort of transition process for 29 30 transactions we need to go to deprecate them we have to deal with dual hashing which i'll talk about in a moment stuff like that that leads us to next

option which is to do all the three of those plus add sse and for it for 29 30. so 29 30 would be ssc legacy transactions will still be rlp um big disadvantage for this one is clients who need to integrate integrate ssc before berlin um i think everybody knows that that's kind of the the big contention before switching from you know option 30 to option 40. um there's also this is kind of like we're introducing ssc but only half so like we're not wrapping legacy transactions ssc as well so we still have legacy transactions as rlp so we've got like this dual system where we've got half the transactions rlp half transactions or ssc it's not terrible but when you want to do things like ssc unions which would be really convenient

for switching and clean up the code for transaction type discrimination um it gets awkward because we can technically do it because there we can just flag the three rlp transactions by their first byte but we can't do just ssd at like an earlier phase in the decoding process so again not terrible not great let's get on to option 50 option 50 is saying basically all of the stuff we just talked about plus we do 29.72 which is the wrapped legacy transactions and we wrapped them as ssc and so this was basically saying you know we're going to eat all the costs right now and we're going to go move over to ssc transactions with berlin and

um the nice thing here is there's basically no technical debt we get rid of some technical debt like eip155 we are ready for the merge um like this is kind of just take on a bunch of work right now so we don't introduce technical debt and so we can pay down some technical debt big disadvantage of course there's a lot of work involved here the other big disadvantages transaction hash for legacy transactions will change and this isn't by itself necessarily a show stopper but it can create some problems with um around the fork block because someone can submit a transaction around the fork block and then the client says okay here's your transaction hash but then the transaction sits in the pending queue until after the fork block and then gets mined and that that transaction hash never got mined

uh there's some things we can do such as storing in memory both hashes just so if anyone asks for one we can send the uh get the other we can send we can send a positive response saying oh yeah we have that transaction here um again i i want to emphasize this one is a lot of work um do not get me wrong uh but it does pay down some technical debt and simplifies things like clients thing can't get rid of 1.5 though and the transaction sig depends on it correct so yes and no so yes we can we still have the the signature we'll still have to switch on that but we can at least split out the two transaction types so

we can have like when it comes to decoding and processing and everything except for signature validation and signing we can actually distinguish them as two different types we can have type zero and type one that's the advantage of the 2972 with with like you are correct we are not getting rid of all of the technical debt from 155 but i think we're getting rid of like maybe half of it so the discussion for us is which of these options are going to go with or do we want to try to find something between them um my personal preference just to kick off the conversation is i'm an extremist so i like option 10 or option 50.

the reasons are my main reason is is i don't like technical debt back in a long time ago when i actually did software engineering 40 hours a week technology that drove me nuts i hated how much time i would spend working around old code and bit rot and stuff like that and so i'm very much for any option that does not increase technical debt and or pays down technical debt and 10 and 50 10 doesn't increase any technical debt because we're just doing 29 29 we're just throwing everything else out 50 pays down some technical debt and gets us closer to our final goal and so we don't add new technical debt we're gonna have to pay down later that being said i know most people are not extremists like me they're concave or convex or

whatever it is and so i suspect we'll land somewhere in the middle so any questions i know that was very fast like i said i think most of you already know all of this they're just trying to summarize uh i do have a question so um so essentially my question is that um internally so current clients um internally you shuffle data structures by a hash so everything every time get does something with the transaction it's that it does it by a hash every time we do something with a block we do it by a hash now uh from an internal perspective i cannot just simply start using a

different hash so i mean even if for example if we're saying that okay now the four block will come and so all of a sudden we need to swap out the hashes from a client implantation perspective this means that when i start up get there at some point in time i need to start up get where get is just going to say that okay from now on i'm not using rop hashes anymore internally i'm using uh sse hashes internally that would be fine but then things start going getting funky on the networking protocols too because all the eth protocol will just ask hashes via rp hashes

or it's um i mean it's definitely doable we can definitely say that that we could definitely roll out the new east protocol which speaks sse and then you know whether the hash is ssd or rfp and then you can um you can maintain both hashes for for some period and then somehow handle both but uh it's it's quite a big kind of forms that does not surprise me at all i kind of look at this as a separate piece of technical depth that we can look at but but yes this that is going to be problematic in whatever transition period um

regenesis is an option that's on the table for us for dropping some of that historical technical debt so if we do this and then we do regenesis afterwards then we get an option to essentially forget about all of that rlp hash history um i don't have a i don't have a complete answer for you but those are um that's one direction that lets us at least eventually address that so um i see one one objection with the whole regenesis thing that uh in theory yes that means that you can write a client which which will only speak the protocol after

the regenesis event and it won't handle anything else but from a guest maintained perspective that's probably not something we can afford because we cannot afford to justify us to you guys from guest version 2 you cannot access the theorem anymore so it's a yeah it's it's um it's a problematic thing so it does that that approach i don't think it helps us much personally but the other thing is that uh what i wanted to get at is that i don't think so i i have no problem with ssd or transitioning into slc uh the point i wanted to make is that i don't think it's realistic to shove it into berlin because it will just delay berlin forever

and i would rather say that if we want a transition to ssc then we should have something that does not contain other stuff rather it just focuses on the transition to ssc for example we could have a hard fork after berlin and then there we can say that okay so this hard fork will contain a new eve protocol version will contain a new snap roll conversion will contain a new i don't know what and then we can actually focus on just the challenges of snc so it seems that this is a whole new kind of worms and it seems to me very very brave move to try to cram it into berlin i'm curious what other client devs think of that

um that idea of a i don't know you can call it a technical debt hardcore where we double down on on cleaning up the protocol some so in the past we've tried to have like or we've discussed having like these closed hard forks and like where we just focus on stuff that's already committed and whatnot and i think the challenge is priorities change so much in six months that it becomes like an untenable promise um so not that i not that i disagree with anything peter says like my opinion is also sse is way too big to

kind of shove into burden right now but i think if we you know it can be like priority number one after berlin is out but i suspect that if it takes six months to do some other things will have become high priority as well and we might not be able to do just an ssdr fork but we might be able to do it along with other stuff or if it goes quicker than expected do just that um but yeah i'm skeptical of the idea that we can like freeze priorities for like i don't know six months um given how much other stuff is being worked on well uh i could disagree with that so i do think it priorities and other stuff creeping in would be a big problem but if you ask me if we add in ssd i

don't think we're going to ship early in the next half year that's my personal opinion yeah and to be clear i agree but i think and i think you know we should probably do ssc right after berlin um but and maybe 1559 or or maybe whatever else or there's gonna be a binary tree like and i just yeah it feels like there will be something else that will be a high priority after berlin as well and that'll just commented in the chat the ice age you know that's coming so yeah i think it's totally fine to push it out after but i think it would be unrealistic to expect that ssz will be your sole focus after burden uh do we have other client teams who

have um opinions on this or any or questions or things like that to bring up for discussion yeah but i agree with peter basically it is big step including even partially sse i would really like if we can have some initiative to if you want to switch to sc to switch it completely this partially switching transaction receipt and leaving blocks as it is it could be problematic but yeah i agree what he said can you scroll down to option 50 micah uh i would like to ask so peter would your preference then be option 30

which one was that again that is where we do so oh wait sorry so essentially my preference would be everything and the kitchen sink except ssz yeah it would be it'd be option 50 minus ssc that sounds like option i don't know about i don't know about all the details about all these options so i don't want to say option 15 minus yes but the idea is that yeah so essentially i would try to solve as many problems as possible without mixing in essence into the soup mica is that more 50 or 30 because it sounds like 30 because i think 50 requires ssc well they the the so where we were last all core dev call

was eip 2029 plus eip 2930 plus 29 uh 27 18. and then we were discussing 2972 which just which kicked off that this this discussion and for this whole week so like where at least as far as berlin planning has been we are up to those three options so the last one is can we do 20 29 72 without ssc and do everything else without ssc then that's the kitchen seek minus so saving ssc for later we can yeah so we can add 20 we can't add 29.72 without ssc the caveat is that um

we just have to all remember that we're just adding like we're adding a wrap transaction around legacy transactions that we're then going to have to wrap again later with sse and so we're we're introducing a new transaction type for app legacy transactions that we know we're going to have to delete sometime as soon as we add ssc whenever that happens and so if if that's what people want we can do that is an option on the table i didn't include it here just because it seems very weird to me personally to introduce rap legacy transactions knowing that we're gonna have to wrap them again in one or two hard forks um that just seems awkward but maybe it's worth it um so you guys know was the could we do 2718 without 29.72 because i thought that was one of the

conclusions as we needed to wrap the transactions to be able to do it so we can do 2018 without sse and without 29.72 caveat there is that transaction discrimination is awkward and uncomfortable and again we have some tactical debt there because we're introducing 2930 without ssc knowing that we're going to switch over to it that might be that's option 30 basically yeah i just wanted to add a quick thought that around two things so mike i said that one of the problems is that we

would need to wrap legacy transactions a second time um i would say that um my suggestion would be to to simply deprecate legacy transactions so that for example in the berlin hard fork we would launch it but we will say that um legacy transactions will be dropped in the next hard fork and essentially you have one hard fork worth of time to transition from this wrapped legacy transaction thing into the proper way to encode transactions and then then the next hardware can simply just drop it and not have to do a double wrap so this was one thing that i want to see let me just quickly finish um so the the

thing the reason i think sse is uh will take an insane amount of time is because essentially every client needs to roll it out and activate it at the same time and it seems to me super dangerous and i mean everything will go wrong but um so the moment you add ssd to the consensus it's um it's a very dangerous path however a more gradual transition into ssd could be to start upgrading for example the eth protocol we could launch e360 whatever which will for example run with ssd and then for example guest can implement it and then uh trinity can implement it and whatever can implement it

and we don't have to roll it out all at the same time clients can implement it whenever they want they they were they can talk to other clients they can test whether the whole thing works uh if we roll out this networking thing that yes this implicitly also means that clients would need to maintain the rlp hashes and ssd hashes too because all of a sudden you can have if depending on the protocol version you the hashes will be this or that and the point of this would be that this would be going towards very heavily towards the direction of integrating ssd and phasing out rop without actually doing this hard flip that okay now everybody must speak perfectly rather you could have this mix

and match evolving thing so that that's just a random idea of how we could do this transition without uh too many risks um right do we do we have a plan with regards to the rlpx transfer protocol itself so now it looks like even if we fully transition to ssz we will still have rlpx transport which pulls rlp library and errol deserialization so do we plan to switch the fp2p to that too um i don't think that there's anything in like devp2p calls that rlpx but it doesn't actually have anything

that's uh that specifically makes things dependent on rlp messages are rlp encoded i think what peter's talking about is using ssc for message encoding over devp yeah so for example what i would do uh for the first time is to just uh for example just switch over the eats sub protocol so that the the messages are ssc or if okay i haven't thought about it too much but if that would mean also well we could also for example bump the death peer-to-peer version number and then all of a sudden it's ssd x not

rlpx so def peer-to-peer does contain version numbers so it's perfectly fine to to so for example geth can speak definitely version four and five i think the snappy encoding is the difference so we can launch a sixth one where just the rlp versus ssd encoding would be the difference and then again any client that does not yet implement ssd can do one thing and every other another so yes there are a lot of challenges here but the point would be that networking can be rolled out uh with errors potentially because the worst thing that happens is somebody disconnects and you can always implement some fallback that if something feels weird then you just revert back to the

the current networking version and then everything works fine so it allows you to to make bugs it allows you to experiment without the risks of breaking things too much uh ryan i think i interrupted you earlier when you had a comment if you still had one yeah i was just going to mention that the micra's point about the transaction type discrimination being dirty um it is dirty but it's only dirty in one place and it's quite simple for now so i think it there's a trade-off here obviously like we're all talking about trade-offs and people on different sides of this but it's not a terribly dirty discrimination and

it keeps berlin moving and we can get 29.29 in without without the option 10 kind of nuclear option we just do 29.29 we at least pay down some technical debt make sure or at least prevent future technical debt by making sure we have type transactions and yet from a client devs perspective like option 30 looks good is it option 30 plus revenue what was that james is it option 30 what also still wrapping transactions in the meantime so that you add that piece right right no i think it's just option 30 and you don't wrap the transactions so out of curiosity is that true for the

other clients as well does everybody feel like the um the discrimination dirtiness is isolated and constrained or i know this is something that might differ by client and they might need to look at it actually um to see and then peter you had your hand raised or martin if you want to go no sorry yeah yeah so i just think that uh i don't terribly mind if it's a little bit of dirtiness

somewhere if it keeps the if it makes us being able to ship berlin a lot faster and get these things in yeah so it's looking like so option 30 is everything except 2972 and ssz right yeah i just looked it up um so if that reduces one there's two cons on option 30. the second one is introduces technical depth that will eventually have to want to convert all 27 18 transactions to ssz and we're

introducing more transaction types we're going to have to go through a transition process or be deprecated and peter was talking about the possibility of just deprecating legacy transactions at that time but iteratively working toward full ssd eventually i think that's how i'm reflecting the conversation and i don't know if it's matt garnett on call but if if it's option 30 that's on the table i think the current implementation for go ethereum the pr is pretty close to being uh yeah pretty close to or less okay one thing we can completely

eliminate right now i think because everything's tending toward let's not do ssz from the few client devs who've spoken up but is there anyone who really wants ssc in berlin for any reason or can we kind of toss out half these options now that we don't want ssc is there any if anyone wants ssc and berlin speak up now okay so what we have left then is oh go ahead i'm sorry i don't want to speak up against slc again uh because uh so if ethereum if we strongly feel that ssd is the future i think we can agree that

ethereum do went that way and it's fine to go that way but i think i really strongly feel that we should introduce ssc in non-consensus places first and then transition into consensus cool okay i also want to say that i i like that idea of doing it at the protocol layer first um it's pretty or like at the networking layer first that's a pretty interesting way to do it in a in a way that's safer and lets all of the different clients on board to it in a nice clean way so that's a nice idea so the one thing i just wanted to make

sure is we're on the same page john so peter mentioned earlier about deprecating just saying like when we launched berlin let everybody know hey we're going to deprecate legacy transactions the impression i got and was that deprecation of an old transaction type is like a two-year process like this is not like a quick thing that we do in a couple of months this is like a we tell people hey your signatures will stop working in two years we don't tell them your signatures will stop working in a week or a month well we're going to tell them your signatures will start [Music] stop working when we ship ssz and that's going to take two years yeah i'm just screwing with you whatever

my point really is that we're not going to keep assessing any month so obviously hopefully it's not about not two years but you're not actually telling people that their signatures will stop working in a month maybe in half a year the soonest yeah so we get like a time period of like half a year and then it will potentially take us longer than that and that's that's fine um hudson do we have contact points with hardware wallet manufacturers because those seem like the hardest um the hardest places to to deal with legacy transaction deprecation which we don't have to talk about right now i'm realizing and we should probably focus on

other things that are more relevant for berlin yeah i know actually i think this was a super important point a super good point that sniper made we won't be able to to get uh hardware wallet manufacturers to upgrade i mean they some of them might support but i think it's super bad move to to brick somebody's hardware on it or tell somebody that hey you need to update your firmware because we just screwed you so i think that's a that's the super strong point against dropping legacy transactions something that was or that i thought of and that i think has been thought of before is uh maintaining support for legacy transactions through a precompiled so they may not be submissible at the

protocol layer but looking into ways to make them still executable via submitting them internally to a pre-compiler or something like that okay but that's something we can think of beyond berlin so um yeah the the only reason i want to bring it up for this just because we just want to make sure that we all understand what this means of introducing this technical that's a technical that's going to go away in a couple of years maybe yeah um okay yeah sure um what if we did you know something where we

only used ssc for the signature the of the transaction so whenever we determine what hash we're going to sign we use ssc to calculate that obviously that goes against the things that people have said about wanting to make sse not introduce the protocol level initially but from my point of view it seems that this signing hash is the one fixed constant pretty much everything else we can shuffle around at the protocol to meet whatever needs we we desire and we can modify the rpc endpoints to give whatever data that people are expecting but if we don't support ssc at the transaction signature we will always have to

continue supporting rlp for end users sorry i mean for new transactions of course we can't change it for the legacy ones but as we add new transactions if we use sse for their signing hashes it would be possible to in the future completely convert those sorts of things to 100 percent ssc mm-hmm wait didn't we lose micah is he back he's not back yet he's back i'm i'm back sorry the zoom

starts playing people's audio from like four minutes ago over top of whatever i'm hearing so i can't understand anything uh can someone summarize the question real quick i heard half of late client's suggestion be where i got us had to reconnect yeah i was just asking to me it seems that the one fixed constant in terms of trying to make radical changes in the future is what is the format of the hash that we have to sign for transactions and so if that's rlp then we always have to support rop at that point in time we can never change that to ssc otherwise we'll break people's walls etc but if we make that ssc there is a lot of things that we can do within a client in terms of you know modifying

everything to be ssc having rpc endpoints that reorganize the information into rlp for legacy people listening to those rpc endpoints etc but the thing that we can't change is the size our hardware wallets uh signs not the hash but the transaction is all so they expect as they input the transaction between full rlp encoded which they can decode pulls at least some data and display at least later does similar thing and they don't just sign a hash they recalculate but what they're saying is basically that that would only work for the legacy transaction but for the new ones it

would be ssd so and your hardware wouldn't be able to to sign something which hasn't accessed this that way so yes it's an interesting idea so the i think the the con there is just that we'd still run we're back into introducing ssc uh we only have to introduce the ssd serialization part uh we don't have to introduce ssd merklization and so the risk of consensus failure is lower um but it is still an introduction of new code which i don't know how a client does feel about introducing just like a little bit of ssc just the serialization the other thing i was thinking and

it and i ended up thinking that maybe sse is exactly this but what if there was an agnostic format that was as simple as possible and you know ssd's full name is simple serialize and so maybe that sse is that format but what if we just have a transaction signing format which we just say let's use this very simple serialization format whatever that is we will use this forever in the future because we don't need special mercalization techniques we there's not it's special advantages this is just an ephemeral format that we serialize and then we cack that's it and so if we just say that this was what it will be forever we don't have to worry about okay what if in 10 years we come up with this new

serialization scheme that allows us to do you know all these great features and we want to upgrade it now it's like we've said that signatures yeah i think that's not unreasonable and we could use rlb for that like in theory we can have ssd transactions over the wire and in blocks and everywhere but when you get that ssd transaction you decode it into some in-memory data structure and then you rlp in code in a very specific way and then cacac that to get the hash which you then sign that's definitely possible um and we like i said we could do that without introducing ssc if we wanted um so excuse me bringing this back to what we're gonna

do for berlin um i know we've had some suggestions of uh peter you had said put in everything except ssz um so am i i want to just make sure that i'm right that option 50 without ssz is a possibility is that possible micah or does ssd required for any of those eips or would break things or stuff like that ssd is not a hard requirement for anything it is um just you know there's different levels how much technical debt we want to incur by not doing it that's the only the only thing with ssc okay um can anyone give an argument of pros and cons between 30 and 50 if we drop ssc entirely does that change the

for the formula a little bit if we're dropping ssc the other difference between the two is adding uh eip 2972. okay yeah it's the it's the do we have wrapped legacy transactions eip or not all right um other opinions on what path we should go down for berlin um and if anyone has any insight into how much time it would take because i guess if we don't want berlin to be pushed out forever um what's the what's the um how long would it take for for anyone to implement eip 2972 which is the rap legacy transactions is

that something that would take a while or like more than two months two months this is a meta comment but we've had a fair number of vips ready to go for berlin for a long time and more of them keep arriving that's why i'm asking how long it would take so that we can i'm saying why do we need is there a reason that any of this has to go out now why can we not release what has been ready for many months

um i think we realized once oh go ahead peter what has been ready for many months i james you you're the keeper of the list if if i'm out of line i'm out of line fine but um certainly 25 23 15 which i care about and there were other things on the list at that time yeah 2315 has been around for a while but um and others it's november oh so that it even though it looks so the the one you're talking about is independent and is is has been so much ready and the gas

change ones or whatever the rest of them are all are actually kind of together like there's a reason we're having this discussion with the different versions of all the eips and we're talking about them all at the same time it's because they're all interrelated so though as far as what's been talked about for berlin we've talked everything has been discussed except for if we do 29.72 like all eips that have been talked about for berlin and we've been getting ready for are up are to the point except for 29.72 wrapped legacy transactions so we're having this final conversation today or hopefully final we'll see of is that is 2972 needed to be in given the context that snc is something

that will tackle on the network layer first and why do we is there an option that just says all of this can wait let's get berlin out and pick this up asap perhaps but i think i my take on that is that the most important thing to ship is not the subroutines it is uh the denial of service protections in 29.29 i'd agree that the 2015 it's not the most important but there's just been a number of themes

ready for a long time i'm i'm afraid this is never ending it's we're starting to look like oracle on a three-year cycle um and and then and the other part is i would say is type transactions are important given the context of what's coming in next year so and also if we don't want to break everything right like i think yeah yeah that's awesome we could ship 23 15 and 29 29 you know alone but then we break a bunch of smart contracts people are obviously mad that their stuff is broken and that's why we have 29.30 um and then introducing that requires a new type of transaction and if we're going

to do that that's why we have 27 18 so i i see i understand that 23 15 has been ready for almost a year and i i agree that it's it's it's quite a long time but it breaks nothing yeah was there analysis done on anything this discussion pardon martin i spoke over yeah i mean so um you kind of uh wrote the discussion of inner tangents and i was just hoping we could try to instead okay and in the intention of discussing us being meta stuck we've become

stuck about being meta stuck okay sorry i was talking i thought i was off yeah you're mute you're mute hudson oh i'm back okay but yeah so um uh greg and the famous words of that time of mean was here we can talk about it offline for specifics of why it will break or not break but um one thing is i think we're getting really close to picking these because we're not doing ssz and all we really have left is figuring out if anyone wants to really advocate for putting 2972 in berlin i think that's where we are am i wrong anybody that's also what i'm what i'm saying is that if we've talked as that's like the last piece cool i think we should go with option 30

unless someone wants to put 2972 in and has a reason and wants to advocate for that i don't totally understand the difference of what's messy what's more messy between doing it without 29.72 or doing it with 29.72 with the context of deprecating old transactions in the next like nine months well we're kind of starting to say we can't do that anymore my understanding was that the major push for 2972 was the guth team because of the way transactions were handled in their client especially in terms of

actually creating the merkle patricia root of the transaction hash but i'm not sure if that's still the case i don't know so it's not really implementation i guess it's you actually you actually wrote the pr which i mean which kind of works so i mean code wise you will have to maintain a transaction type anyway whether that's a go type or type flag or whatever and then when you encode and you calculate the hash it's uh i mean it's fairly trivial to say that uh type zero transaction is encoded with one special rule and type others with some other special rules so

i don't think it's uh it doesn't really really matter from an implantation perspective it was just out of code cleanliness whether the idea was just to not have too many weird messages in the code but at this point i would say that whatever is simplest and easiest to implement might be better and maybe we can tweak it in the future so if if this whole 2972 introduces a lot of extra complexity around legacy transactions then we might as well just leave legacy transactions as they are now and just special cases but yes this is a prehistoric thing in ethereum and we know that it's a bit

weird but it's it's what the ethereum one was and figured reading over martin's um uh gastry price right up uh in the summary i'm probably reading this wrong but it looks like you're basically saying that everything's fine like we don't actually need 29 30. i'm guessing i'm misreading this no you're not misreading it you what you're reading is that on these small segments of blocks analyzed on gurley in that particular block range uh there were no such ones

i see okay so we we we don't so it's a fear of the unknown basically here we don't know if there exists things that will break um but it's possible that there are is that correct yes and previous analysis uh yeah well well i said a couple of weeks ago that i would rerun the same thing for mainnet for a larger block portion and i have not uh i haven't done so i haven't gotten the time to do it well because it's dropping dropping 2930 definitely is dropping 2830 is by far the fastest and easiest way to get berlin out like that solves all of our problems uh so i'd be

if we think that we can quickly analyze whether we need 2930 like need need need um that may be a simple solution but unless someone has like tools ready to go for analyzing that i'm guessing that's a big chunk of work yeah i mean i get has built-in tools to analyze that and it can be done and the question is more like okay so if we analyze 500 blocks and find no such transactions are we then okay with that or how i mean how much is enough how short do we need to be is is the tooling something that we can't just run over the whole chain

um yeah i would i accept that answer alex is laughing how long would it take to run it over the last million blocks uh i can't say yeah but the thing is can we help run it over the last million blocks there's not only the question running it over the blocks you um so there is some some yeah either either there is some manual analysis step that needs to be performed afterwards or the tooling must be

better refined to figure everything out on its own um and if you want to run on a million blocks then obviously we want to minimize the manual post processing i'd say that it would be really unfortunate for us to introduce a new transaction type that we have to deal with going forward if it's not necessary and yeah a um of the a lot of the issues that are coming up here is because we are deaf we're assuming we're definitely going to introduce this new transaction type and it would be great for the health of the network if we could just get that dos protection out without so yeah creative ideas can we like bouncy

this with the community and say we will pay somebody you know x thousand dollars if you can show us a historical transaction that would fail under these new pricing rules and and and do you know commit to doing some analysis ourselves as well and if we can't find it and if nobody in the community can find it then we don't do it because it seems i get that the like extremely responsible thing to do or i don't want to call it responsible but the like bulletproof thing to do is to have this mechanism in place but

if you really need it then it seems it seems really unfortunate to implement it and deal with the debt that it's going to introduce so i'm just looking at each magicians right now and the cto of scale labs seems unhappy with 29.29 because of the gas cost changes uh he didn't provide like a specific uh example and and uh about it but um that might be somebody who could help um yeah i think a lot of people are unhappy anytime we increase gas costs yeah i think he's particularly unhappy

with many things that are posted there um as far as and some practical uh change affect many defy apps but didn't specify which ones what were you saying alex blassoff uh yeah for a person who is uh outside of this a little bit and just from a completely practical perspective um if storage is restructured and maybe binary utilization is implemented the answer is no need to increase the price because latency of accessing the

storage is going to be much smaller than right now as was demonstrated by a trooper guest team maybe instead of this and three months of discussion implementation on this part it would be better to agree on this you know own decisions that it's going to be breaking change uh and just fix the problem from your ground up so it would make everyone happy except people who actually have to write it but they still have to write it at some point um i have a question on for eip 2930 um is that something we could leave out and if we find out later that there is a transaction that is actually broken implement a fix then or is that like

pretty worse i believe we can do that just but we still have to have solve all these problems like then instead of now uh okay and then if we didn't have 2930 would we also remove type transactions for berlin yes i would say if 2930 doesn't go in we should cut all the stuff in my options list like if we don't need 29 30 that's the only reason all of this falls out is because 29 30. so just2929 we're done we can release brittle in tomorrow is there a if we do um like let's say the next fork is 50 has let's say that an upcoming fork i don't want to be quoted wrong

wrong here as has 1559 type transactions if we do is there a good reason to do to say like take this work now of having type transactions work and then make sure they work before trying to do more things at once like so one thing that makes it easier is just you know if type transactions are already a thing on mainnet then you know 1559 and i assume the account abstraction folks and whatnot we can just take it for granted that those things that we can use those things um otherwise it's just you know like kind of this uh this uh chicken and egg thing we're like we don't want to change the 1559 spec to depend on 2718 because we don't

want to add this extra dependency if um it's not going to be on main net um so you're kind of you know circling so it's it's not the end of the world um but it does make it easier if it's already on mainnet and it's already used for other projects to like leverage that i think that'd be an issue if 2018 were more controversial but i think what's more controversial is just the timing of it right like i think that it's safe for 1559 and other trans other eips to depend on 2718 because we're all pretty much in favor of the idea of it the problem is like okay can we actually get berlin out faster without it can we strawmen that if this was the beginning of the

discussion of the next hard fork and we're talking about putting proposal something like proposal 50 in which has all of the ssc stuff is there anybody here who would would be speaking out against that or saying i don't think that that's the right use of our time silence maybe here means that that's correct yeah i'd say so um i have an idea what about this we do analysis of the last however million blocks and martin there was a company that helped

us do analysis in the past the last time we were thinking we were going to break stuff do you remember what that company is yeah well i reached out to both of these both of them a couple of months ago but actually the the the stuff that's built into geth is better um but it's going to be a lot of work um but i can try to sort it out i still think there's an additional benefit of 2930 in that it provides access list which can later on be used when uh when we start using witnesses

okay and looking all this up would take time um and we're kind of in a holiday season analysis today that like you can make a transaction you can make a contract on the transaction which will fail in your analysis at this moment in time yes so a person who would want to stop this from being required so it's kind of pointless you cannot guarantee this like you cannot get is that non-existence of the contract which will not break yeah yes it's easy to make one and you could have a new farm two days before the hard fork you know i mean we can call the cutoff yesterday like if it didn't exist

yesterday well then another option that ud5 protocol hits in between this point as was mentioned by team i think then maybe new d5 protocol comes in which is popular in next months and one month before support uh yeah okay that's fair yeah okay so i think especially since martin mentioned that there are other benefits to 2930 um maybe 30 option 30 might be best what were you going to say micah i was going to say that core devs and security auditors and everybody has been screaming

at people for the last year do not make your transaction dependent on gas costs they will change at this point if you are writing contracts that depend on gas costs it is your fault like we have done everything that is in our power to stop these people from doing i sit in chat rooms all day since people say oh i'm just going to do this gas check and i immediately type up and say no don't do that here's why here's 17 articles by professionals and auditors and core dubs stop it we have to at some point cut cut people off and say we are not going to support you switching on gas costs anymore and i think that point was like six months ago and so while i agree that we should be checking old transactions i do not think that we should care about

transactions released yesterday or last week because those people should know better by now and if they don't think you're forgetting something so the problem is not only it's not about checking expensive gas cost it's about contracts that deposit using the solidity send and they provide it it winds up with only the 2300 gas at the recipient and they try to do a check and s load and they failed and the contract that did the deposit was hard-coded to do only a cent because that's like the solidity old-school best best practices you do sorry is it yeah that's true

yeah that's fair so this this gets a little bit more murky because there's like half of us so there's that group of people saying there's a screen of people to stop switching on gas costs half of us have also been screening people don't rely on the gas type and being enough to do anything and the other half have been saying okay i use a gas life and it's safe so you are right there has been mixed message from us and auditors on that topic is getting better like i've seen more and more auditors now saying don't do this um but you're correct there there is more disagreement on that so i'll concede earlier in the in the conversation peter you mentioned that your the geth client was close to uh off basically option 30 minus

and not having the 29 29 72 that the gef code is kind of closest to that option currently i think light client knows best actually oh sorry could you ask that again uh that the that the option 30 so everything except for the 2972 the lapt the wrapped legacy transactions that the geth code is closest to that version yes so and then other clients so it kind of still goes back to if we do like the thing we're closest to today is our other clients also in a similar position

as far as where we are developmentally yeah from a pedestrian side uh in a similar direction there was a lot of discussion around half a year ago maybe four months about what was called the un gasp to make gas not observable in evm at all and they didn't go anywhere at least as far as i know maybe the opposite would be better to make it observable so for the same way like yes people can hire code 20 300 gas for some operation

if they can say get the data with this operation will cost like in real time before making fall which may have been solved their problems uh but it was uh never introduced in this direction i think it was only introduced in over the one so like high degasmatics completely different people yeah it wouldn't solve anything you know these problems like it it wouldn't work everywhere because in complex interactions they obviously will not try to kind of estimate precisely how much gas they want to specify in a call but at least for a simple one where you can literally try to see what's going to be a slowed log and as a single store maybe single log

and maybe 100 for additional expenses they can at least do better than they do now okay it won't solve any existing problems yeah let's stay focused on the stuff for today i think but um uh i think someone's writing up option 35 right now um so what we're circling on right now basically is whether or not we can get by with dropping access list transactions um correct is that that's the latest thing we're stuck on and once we get past that i think that we're downhill from there uh what would

people need to be comfortable dropping that i guess that's maybe the question that that we need to figure out i mean it sounds like we're not going to get bulletproof knowledge that it definitely doesn't break anything if we ran it over the past two million blocks and didn't find any transactions that caused problems um and that was you know that analysis was done would there be people here who still would not be comfortable rolling out the gas price increases without the access list transaction type and i think part of it is that 2930 also

has stuff that's been like beneficial beyond just fixing or patching up um the problem yeah when you say that are you talking about like what martin mentioned about like witnesses and things well so i'm not saying that we don't ever do 29 and 30. i'm just saying that it's unfortunate to do 29.30 without doing it on top of 2718 and 2718 gets all problematic because it has to see and things like that and so if we're pretty sure that we're going to do 2018 coming up then we just do 29 30 with 27 18 coming up because if we don't need it now then all of a sudden berlin gets really easy i think we actually

do 29 30 and 27 18 for berlin and it wouldn't be a super long time right yeah that's that's what we're like we're closest to developmentally having that already ready yeah i think that's true for basu as well like option 30 is probably what we're closest to and would be the like path of least resistance i mean technically except and i'm okay i'm okay with that and i'm not going to argue against it what i'm what i'm suggesting is that we can if we don't even need to do 29 i've got my numbers all mixed up if we don't even need to do the 20 the the access list um transaction type at this stage then we can do it in a

better way when we do ssz based 29 27 18. um anyways just just like we don't have any concrete reason why we need access lists right now so there are actually some concrete if you look at the old uh 1884 security analysis there are a lot of contracts uh that were found the capped walls and the nexo crowd side and the ebc fund and uh some crowd machine compute token crowd sale yeah that were hit by 1884 and these would basically be

hit again and similar like them yeah it's seeming like the the things are stacking up more in favor of putting an eip2930 access list in because the analysis alone is going to take weeks if not a month and then then we would be able to make a decision and there's a chance that decision would be we need to keep it in and if we're going to put in that if that's something we want to put in eventually anyway even though putting it in right now might not be the best format to do it we can't it's it's the what we have

ready the maximally safe thing that we could ship in the shortest timeline includes 29 30. and 27-18 it sounds and 27-18 and then maybe 29.72 but i haven't heard many people say that we need it anymore yeah i'm not seeing people advocating for that um so i think i like option 30 going forward and if we can just declare that today um and update yellow whichever yellow we want to put it in before that i just want to hear from each client that there isn't anything in 2972 like just go through them that that they that they see that we need to just like exclude that ex

explicitly yeah if any client wants to speak up on that i guess that's a better way to yeah i could like for geth or baesu is there anything from 2972 that you guys would need or when you're doing your funny stuff to try to make stuff work in the meantime you don't think it should be a blocker for berlin so auction 30 is probably the best yeah i think that's oh is thomas here thomas is here you might be muted he said an all-court does that he's okay

with anything so he does not care yeah and then open ethereum would also be fine with dropping 29.72 yeah that's correct yeah yeah okay let's go with option 30 then cool what's the next hard four or what's the next date it's the 11th so um as far as that goes we're going with option 30. um that is dealing with the first bullet point of the agenda the second bullet point for eth 6x support option a versus option b um that's that's a separate conversation right is that dependent on anything that

we just talked about or yeah sorry just to make it clear from the chat because i don't know this on the live stream but thomas said that uh nethermine is fine with option 30 in the chat wonderful so let's move on to the next one we have a little less than 15 minutes left but this next one hopefully will be a little shorter um oh but i guess before we do that um what needs to change in the specs repo james for us to know where we're at on these eips that we just decided on for option 30.

uh nothing actually oh all right azer i'll go through and look right now i'll fix whatever needs to be fixed i'll handle it 2930 i believe will need to be touched maybe i'll check it out though the ap might the specification list still is 25 65 23 15 29 29 289 30 and 27 18. uh oh yeah 27 18 we are doing i i got that confused with the 29.72 okay great sounds good yeah just to be clear on that i guess before we do the networking stuff so does that mean yellow v3 will be the

list for berlin i assume so um and if so i think we still had the the bls pre-compile as part of yellow v3 we should probably remove that right so that the yellow v3 spec is just this whole bundle that we discussed for berlin um i don't think it i don't think it's in there i think that that oh we already have this yeah that one's really okay great so what's in what's in the spec right now yeah i'm looking at it is yellow v3 and that's what we'll we'll put on the what we'll make official for berlin is that right yeah yellow v3 plus whatever was in v1 and v2 right no yellow v3 has all that now exactly yellow v3 is the

is the right list oh yellow v3 yeah yeah yeah yes because the yellow v one and two have the bls frequent files which yolo v3 doesn't okay yeah so it's this five one two three four five eips okay so if we can get that stand stood up in the before the next all core dev call we'll have like some uh i guess preliminary data on how it's all working out for for britain great okay so to do's are micah is going to go in touch any eips that need to be changed and uh up do a pr on the eth1 specs repo to update the commit hash for whatever needs to be put in for yellow v3 right i can update 2930 if necessarily take a

look at it i don't know how to do the other thing you just said though um so in yellow v3 this the specs page i'll post it in zoom chat um we have commit hashes for ones that are if there was an update like fairly recently um just a link to the commit hash for what and what version to implement and so we might need that for 29 30. i'll work with you or james don't figure out how to do that i think they're for 29 30 we the thing that led to this conversation was trying to just decide what the rlp format for 2930 is i think there's still value in having some discussion there but it's nothing contentious it's just like what order we want the fields to be and kind of stuff so i

think martin had some thoughts on that i don't know if you have some time later this next week or early next week we just go over and hash that out sure great um the next item on the agenda is ethe 6x support option a versus option b and if you click on that it'll take you to discord um to a here was it oh well maybe it won't let me i'll post it in the um discord for the all core devs chat so there we go sorry about that let me oh there it is okay

so that's peter talking about the two options for rolling out the new versions of um the networking protocol um so i think whenever basically people thumbs up the post and then um artem went for option a open ethereum was looking at option b and liking that um open ethereum says b and i think that might have been the only clients that that spoke up as like speaking on behalf of their client i think for basically we said b as well yeah i think i meant did i not mention that yeah

basu said b um so what about nethermind have you happened to look at that and have a uh suggestion or a way you want to go i think the other mind indicated they're not actually here they're just listening ah got it no problem all right we can get their answers soon but it's tending toward option b currently um is there any updates on the guest side for this um discussion no i mean it's we've heard that people prefer option b so we'll use option b okay sounds good pending anybody doing a show stopper i really don't want to do

option b so we need a lot more discussion or changes i think we should go with option b that's that's good should we read out what it is yeah so option b is um we allowed type transactions in earlier protocol versions but number one geth will implement 66 request id before berlin so after berlin all geth nodes on the network will be guaranteed to speak 66 and then eth will drop 60 or geth will drop 63 support this year 864 support by spring 2021 and 865 support by summer 2021 so yeah that's option b so i think everyone understands that are

there any questions or considerations or anything else i'm missing on this one uh another mind has said that option b is better from their point of view they're they're in the chat they're just not he's not sure how voice right now okay sounds good um then we'll go with option b so that's settled um final go no go for berlin eips we kind of just did that it's everything in yolo v3 plus mica may be updating a commit hash for eip2930 yep and 29.72 is not included yes um there's one more thing on the agenda

um and uh before we go on is everything with yellow v3 and berlin kind of um good are we is there anything else we need to talk about there that i missed out on nope i don't i don't know if we want to discuss this further but i didn't really get a clear answer on if there was any desire to look at changing the transaction signature serialization scheme for 29.30 so i thought that you mean from ssz to something else or is this the thing we're doing in 2930 the the thing we're doing in 2930 because i like i said the the serialization format that we choose for the signature

to build a signature hash this is something that we cannot change in the future and so i kind of was hoping we could decide on one format to use at least you know some sort of perp in perpetuity that way it's not a discussion that has to happen again if we want to move everything to ssc we don't have to further discuss oh 2930 happened to be you know signature assets were built with rlp so should we deprecate those transactions etc etc um anybody have any comments on that is it what's the default like client is it just going to go what's rlp or something right now it's rlp and i'm

not necessarily opposed to rop my feeling is just i it kind of seems like it would be nice to break apart what we understand as a serialization format for the protocol and the special format that we build these transaction signature hashes with and it seems like sse is maybe the most simple serialization format we could think of and that's something that we could just say even in the future in 20 years if we decide that ssc is no longer appropriate in the protocol it's very simple to serialize transactions to sign them and so we will continue supporting those for a long time um i'm getting the feeling we might just

be burnt out for the discussion around that today uh it's fun but um unless people unless anyone has any comments but um bringing it up in the all core dev chat and putting it on the agenda for next time we'll probably be able to discuss that more if that's something that needs that can be discussed before we start implementing um that's good okay other eips this is the last one we have about four minutes so we'll just wrap this up with an overview of this and if anyone has any like one or two comments um like client talking about eip 26 18 limit account knots to 2 to the 64th uh power does this say 18 or 81 26 81 i read that backwards okay sorry i

didn't know if i put the wrong thing on there yes 2681 this is an eip that alex wrote earlier this year the idea is that building the witness format there is some complexity in dealing with these arbitrary length integers and as currently specified the account nonce theoretically could grow to you know very large numbers and so this eip is basically retroactively saying that we will limit account nonsense to 2 to the 64 minus 1. right now i looked up the current highest accounts in the state try and it's approximately 29 million it's the ether mine coinbase account

that sends out the disbursements that's a lot of gas spent oh my yeah so i don't really know what the proper way of doing some sort of eip like this where it's retroactive but it's a very small change that i think a lot of clients have already implemented and i believe geth has implemented it nonsense as being i'm signing 64-bit integers i think that this is how many clients have done this is there any opposition for accepting this or moving it forward i think i think we could mark this final okay what's the proper way sorry good my only

minor request and not enough to stop this from going through but would be um two to the 52nd or lower so that way javascript number doesn't have problems since i think 252 is way more than we're ever going to need like that's the end of the universe kind of numbers um again i don't want to hold back the cip if there's like that's not my my opinion is not strong enough to hold it back but that would be a minor preference it's two to fifty seconds i mean it doesn't really matter yeah actually because in practice it's never going to

reach either we could just yeah again in a couple years and we can say that you know let's just make it to the 52nd i think the fact is that we're going from something that's very our arbitrary length to fixed length and if we choose this 264 today we could potentially reduce it again in the future it's not going to be something that comes up you know in five years i think i believe as soon as we put this into ssc it actually does matter because ssc is a fixed width for like you need to set the number of bytes i guess 64 and 52 number bytes is that correct my math is weak 64 bits and it was 64 bits that's off by bite but up close

okay so you're saying that this could potentially become an issue when we begin doing ssc so i really think so i don't agree that it would be an issue because uh it doesn't say anything about changing it to be fixed with 64 uh length thing it's just just that it's limited to between zero and this number i guess i'm not sure what that means in terms of ssc is there a representation for something that's arbitrary so so if if we say this is 64 bytes and

then we encode this in eth2 somehow it ends up needing to be us to the encoder for whatever reason yeah but if you don't say that is exactly represented in every always represented using 64 bytes just say that the maximum value of this number i see okay um sure like i said my my preference is to say the maximum value is two to fifty second just because that way javascript can use a number instead of a big in uh again uh we don't have to talk about it here and i won't hold up the eip for that we'll disagree but just to clarify because if we were to say

instead that this should this is now a 64 byte thing then that would modify the consensus encoding in the try for every account object so that would seriously screw with everything so that's not what this is about okay that is a good point so as the eep is then in terms of just saying that the account nonsense we're not changing any representation we're just limiting it to to the 64. this is okay to move to final yeah sounds good to me great all right yeah i'm also and also it's good just because there are some json tests there that have some word announced

numbers we have some discrepancies with def with some tests so yeah having some send limits for this it will be nice and before moving it to final should we put it in last call for two weeks just because i know there's like some rss feeds and whatnot that fetch that so i think maybe we can move it to final next next alcor devs if in the next two weeks nobody's kind of stood up and and blocked it for a reason yep i can't do that let's do that last call for two weeks we are out of time thanks everyone for coming today um and uh welcome light client as one of

the new uh eip editors we've had some discussion on the eip editor chat there wasn't any dissent um that anyone spoke up about so light client is uh going to be any ip editor now um is there anything else i think yeah that's everything on the agenda so we will meet again in two weeks on december the 11th december the 11th uh thanks everyone have a good day thanks you thanks everybody having their video on yeah let's do the video again next time thanks cheers thanks for suggesting that [Music]

ride [Music] [Music] [Music]

[Music] [Music] [Music] [Applause]

[Music] so [Music] [Music]

so [Music] [Music] you