All Core Devs - Execution #127

Transcript

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

foreign [Music] [Music] foreign [Music] foreign

[Music] [Music] [Music] [Music]

thank you [Music] thank you foreign [Music] [Music]

foreign [Music] [Music] thank you [Music] and tonight

weekend [Music] [Music] [Music] am I doing [Music] and we should be live so welcome

everybody to awkward devs number

Tim Beiko: 127. um first thing quickly before we get into it we have the arrow Glacier Fork happening in two weeks for anyone listening so it's happening on December 8th uh if you run an ethereum magnet node please upgrade it in the agenda for this call there's a link to the Aero Glacier spec with the release versions for all of the clients again the arrow Glacier is just an upgrade to the difficulty bomb so it doesn't do any kind of substantial changes and yeah you want to upgrade before December 8th or block 13.773 million with that out of the way

um yeah so uh Mikhail I saw you had a couple points you wanted to discuss about kinsugi um I think we could probably just get a quick update from the different kind teams and then and then dive into those uh yeah I don't know if any team wants to start and share kind of their progress over the past two weeks I know there was some sinking uh that was happening this morning or last night and I'll call on Marius because I know Geth was the one of the sinking clients with I think

take you so

Marius van der Wijden: yeah yes I can I can go first

um yeah so the devnets um I'm not sure if we talked about definite zero on the last call but definite zero uh basically broke because I ran two miners um at this at the head which meant we had like two competing uh proof of work blocks and clients were not able to um to Fork to the correct one or like to to uh Fork after after the proof of work was uh after the proof of stick change started which meant that like half of the network was on one chain half of the

network what's on the other chain um this is not really fixed yet so we have to uh think more about how we can uh make sure how we can work with these like these Forks around the the terminal proof of work block um and also maybe how we can uh show that to the user to make the user where um that there are two folks and that he has to decide between them um and then like we can have a social

consensus on like the the right proof of work block and then build on that and um yeah that that was the first definite um the second or devnet one uh it's zero based uh definite one um broke because I uh um made uh like I wrote the book and um and yeah but we have updated guest now and we fortunately never mind was correct

was correctly producing the chain and we then fixed Geth and synced to the chain and I think currently on on the chain it's never mind Gasol I'm not really sure um and for the consensus layer clients it's uh loads Lighthouse um teku that are currently running I think and um yeah it's it's it's going going okay um and I also tested today uh tested the

optimistic sync uh with uh with uh taku which were like there was a buck and GAP that prevented tiku from optimistic sinking um but that is also working it works it was just the back on our side and we're going to fix it that's basically it well

Tim Beiko: yeah great progress

Marius van der Wijden: um anyone from any of the other fan teams want to add some more

content yeah

Marek Moraczyński: okay so from another mic we have to do several not critical fixes and quite a lot lots of refactoring

our sync process allows us to work in any devnet however this is not our final solution we plan to rebuild it uh we are in sync and we are producing blocks on kitsuki devnet like Mario's side it seems that Netherland is working fine and we will definitely continue testing different client combination that yeah I think that is update from

nethermite

Tim Beiko: thanks anyone else

Gary Schulte: from uh base two we've implemented the kinsugi spec and uh We've successfully interrupt with uh merge Mach uh but we

have been focusing more on trying to get our merge Branch merged into Main and um we haven't tried to interrupt on the devnets yet uh but we're at a point now where we probably could do that but we aren't at a point where we can do that with a main branch so uh yeah we'll probably jump in with uh a client from uh our merge Branch instead

Tim Beiko: got it uh Andrew you have your hand up

Andrew Ashikhmin: uh right so for everyone invest we're still developing uh the merge uh we so we haven't been able to uh sync yet um uh I have a question about the merge

so now we we will have uh eipa 43.99 as well uh and um there is 3675 says that mix hash should be zero while in EP 43.99 we are reusing mix hash so can we actually clarify if 3675 so that mix hash doesn't have to be zero

Tim Beiko: I I put in the pr I think two days ago to clarify that

yeah um yeah yeah

Tim Beiko: you want to explain yeah okay uh uh I think okay I can yeah

explain it so yeah we we put in the pr in 36.75 uh I think we just added a note saying like that these parameters that are set to zero can be overridden you know based on subsequent Eeps I didn't want to assume that like every implementation like if there's another Network or something that wants to use 3675 that they did also use 43.99 um but yeah I just tried to make it clear um and yeah the 43.99 does supersede uh basically uh 36.75 so you do use the next hash all right cool thank you yeah and Miguel shared the pr in the in the chat

cool uh Perry I see you have your your your hand up

Parithosh Jayanthi: yeah hey um so while the aim of march.netic one wasn't to test the execute like random transactions Etc there is however a faucet applied so someone has interesting edge cases they want to try out please claim some ether test it out um I'll also just share a couple more resources so if you find something to break feel free to break it

Marius van der Wijden: um also if people are testing their execution layer that there's a uh 4399 transaction or difficulty before the merge and random op code after the

merge so um both is in the test net so if you don't have 4399 enabled then you cannot sync the post merged and you will crash on block 1641 I think so just yeah FYI

Tim Beiko: cool any other updates from teams working on this okay um in that case Mikhail you had two

issues you wanted to discuss uh the first was the message ordering for the uh engine API and how do we reset request IDs

Mikhail Kalinin: yeah so there is the pr to engine API that refines the message ordering section and the one corner case was um yeah it's dropping B yeah oh thanks Tim thank you as well okay so there is a discussion about one HK scenario uh let me just give you a quick context um what's what's the edge case is um so

we are it's very important that pork Choice updated messages are propagated in the same order as they appear in CL and for this purpose we use request ID Json RTC request IDs so they must be constantly increasing and El must not process for Choice updated method calls if they have the ID that is lower than the previously processed call of this method uh that's how it's uh that that's how this PR uh proposes to um to adhere to that message or to the

order of uh Focus updated events happen in LCL and the edge case uh then um supposed when CL just went offline and got back and get back so um it will either need to persist the request ID to start from the same value um otherwise all we need to reset it somehow via engine API otherwise um the counter will start will start like let's say from some default value which is one or zero and execution there will have to if it's for it if it

follows this back it will just have to reject those messages um until the time when the counter gets back to um dudes to to do the same state as it was before the restart of clients so and yeah the proposal for a second this counter is just uh if execution layer clients see that the request ID is zero then it means that the counter reset and Counting starts from like zero and those onwards um that's it

Danny Ryan: this seems totally reasonable to me the edge case is even worse than that it's

not just like one single CL resetting like CL a should be able to be swapped for clb transparently to El and so anything that you have to persist across those two layers to be able to communicate after that swap is you know worse than just resetting CLA IM so I would I think the zero makes sense to me

Mikhail Kalinin: is there any like a position to implementing it this way or if yes you you let's discuss it now if uh if not if there is no stronger

position you may just go to this thread comments put a comment there otherwise I guess it will be nourished pretty soon uh with this proposal this resetting mechanism

Daniel Lehrner: cool and um um there was a second uh issue you wanted to bring up also to add a if get blocked body or sorry engine get Block bodies method

Mikhail Kalinin: yep uh yeah there is it's it's a proposal yet it's it's not even a PR uh it's like a request for comments but um yeah we can drop the issue uh what the proposed is to implement get Block bodies method in engine API it allows for pruning execution payloads on sales side and save like potentially a lot of space on the disk in this case um the CL clients will um request block bodies which is just the transaction list um after after the merge

um and whenever it needs to serve a block uh Beacon blocks to their note here or to the user it will just go to El and request bodies and request transactions of those payloads that are supposed to be served um one thing worth mentioning here is that this get Block bodies maps on the git blog by this message in the eth protocol so it I I'm assuming that it's pretty straightforward for execution where clients to implement to expose this logic this same logic via

engine API because basically the logic already exists and it just needs another one interface to be accessible

so

Péter Szilágyi: um question uh the response do you expected in Json format or are included

and

Mikhail Kalinin: it's basically it's it's the array of bytes according to EIP 2718 so it's either rlp or a binary encoded transaction according to this

EAP

yeah okay but that's a single transaction but the list of transactions still are okay so you expect the consensus format in short whatever that is so not not the Json format rather than the binary concept is from right

Mikhail Kalinin: right it's it should be like yeah it's array of encoded transactions it's not rlp and code it's array of encoded transactions

yeah

Danny Ryan: I'd say something like this seems very reasonable um if this becomes a complexity though I think it can be a optional on at the point of the merge and

something that's pretty high priority to get in place after not not that I or even just utilization of the pruning mechanism even if the the method exists um but I I think deduplication does make sense

no I mean the the implementation of these things pipelines so I I missed that what was that Peter I'm saying that the implementation of this execution their side is five lines of code

Danny Ryan: okay so mandatory as part of the spec but uh whether CL is doing pruning at

the point of merge or not um can be

sure

Péter Szilágyi: yeah I mean you can do whatever you want there's just right mandatory then you know that every client will be able to serve you so that you can swap off outside from the other

yeah okay cool yeah

Tim Beiko: does anyone think we should not include it or like have it as an optional okay I guess because you have your feedback

yeah okay

Mikhail Kalinin: so thanks sense to open a PR

probably or yeah I'll just wait for some some time and probably open a PR next week

Tim Beiko: anything else about kinsugi or the current merge implementations

um I

Mikhail Kalinin: I was going just to say that we are about to release the next version of Kentucky spec pretty soon um they need do you want to add anything here

Danny Ryan: yeah um so I think as you all are all aware the devnets are now launched on Tuesday

president Thursday um and we had spoken about attempting to do the persistent test that you know next week or the week after I think given progress and given some of the iterative changes that are still coming out on the king 2B specs I think we'll be at a king Sugi V3 uh by about Monday or Tuesday um I would suggest that we are aiming for the persistent test net launch on the 14th rather than seven uh just to give us time to I would say can you give you three specs are out Monday or Tuesday so then the seventh can be a V3 um devnet and then the 14th can be the a

persistent test not assuming things are going well um I know that begins to push us close to the holidays I think it's at least reasonably far away from Christmas but uh obviously open a feedback on that the shift in the timeline

what answering the question maruse has um yeah we'll have the change log in the kitsugi stack in the table

Tim Beiko: um one thing I'll point out for uh the client team so if we do aim to have uh say a devnet that's stable and that we want basically non-client people to use

over the holidays uh I think it was inferior and maybe coinbase mentioned that just having it in master with a flag really helps um yeah so just uh if if that's something that we can aim for on the client sides for like the December 14th release I think it'll help just get more folks onboarded to it

um not gonna happen no I mean if you were if the request was to have the everything virtually that merged onto Master you know

Tim Beiko: got it so it's still easier to keep it on a branch by

then

um well

Péter Szilágyi: the problem is that once we learn something to master it's uh it's I mean it already sort of say fast food so nobody is going to just dig it up again to see if there's something wrong with it or not so it's kind of

thing

Tim Beiko: fair enough um I think yeah in that case you know having like a clean Branch we can point them to and and if it's possible to have a command line flag on that Branch that's that's probably as good as we can do

yeah that's a reasonable anything else on kinsugi

Péter Szilágyi: um

yes Danny will be away for the next uh few weeks the month-ish um so you're stuck with me and

Mikhail I'm

Tim Beiko: so okay so we had two other topics from the last call that uh that we we had kind of bucketed uh basically How We Do Fork IDs for the merge and uh the discussion around the ip444 and how you know we want to go about potentially implementing that after the merge um I think it's worth uh maybe moving to the next section first because it might affect those discussions so in parallel to that in the past two weeks there's

been a lot of discussions about uh transaction costs on roll up and how we can uh potentially help alleviate those and there have been two proposals kind of brought forward which would uh kind of reduce the call data gas costs in different ways um potentially with the desire to see if those could be brought to mainnet fairly quickly given that one of them is a literally one character change um so I think it makes sense to maybe just have uh the authors if they're all on the call kind of walk through those proposals why they're valuable um and get some general feedback there and that yeah the impact of those

probably the determines like how we want to deal with fork IDs and um and what we have to do with regards to historical data uh so let me see if I could yeah is there an author of either of the Eeps that wants to give context

um I'm happy to talk about 4488

Tim Beiko: sure okay

Vitalik Buterin: um so the idea behind 4488 is that that it decreases the call data gas cost uh from 16 gas per byte uh to three gas per byte so it decreases it by more by more than a factor of five and this it would make Roll-Ups five five times cheaper um

so make something like uh I think on average optimism and arbitrum tends to be around the two to five dollar range it would bring them up under one dollar and then um Loop ring and ZK sync are often about a quarter and it would bring them back up bring them back under five cents um the one extra fee feature that the CIP has is that it also adds a separate call data size uh a limit per block um so it says that Asia block um can have at most one megabyte of total transaction call data plus uh 300 bytes for every additional transaction so this is uh like in terms of code it's uh here it's still fairly easy to

implement it say yeah um it's a one line function but in terms of consequences this basically this does mean that instead of having a single dimensional limit we have a two-dimensional limit so there's a limit to guess and um there's a limit to call data and historically I think we've been wary of adding two dimensional limits because two-dimensional limits make the algorithms for figuring out what transactions you include harder because you can't just like take the top priority fees and the next priority fee and then and then the next priority for you and keep going down until you run out of space um so there's a yeah so the IP has a couple of mitigations to this

um one is just the fact that we already did EAP one five five nine uh basically means that the the number of case like most of the time uh blocks or the the constraint is not going to be block size most of the time the constraints will just be like you take everything that's willing to be that's willing to pay the base fee until the until the mempool at that level clears um and then also the yeah just the facts that the limit is fair um the limit is quite High I don't think we've even seen a um um blocks today that rise to anywhere close to that limit and so the average is somewhere around 15 times less than the limit and also this extra stipend of

a 300 bytes uh per transaction which basically says even if you create a block and that block fills up to the to the call data limit you would still be able to keep on including transactions with less than 300 bytes less than 300 bytes of small data which is on average about 90 of all of the um of all of the transactions in the mempool so the reason behind this limit is basically to um because historically we have been concerned about the possibility of that if there is a really really big block then that would just temporarily crash the network and always um in ways that we don't um that we don't fully understand

because we haven't really had blocks of that size yet um and so this is basically just a keyhole solution it says well you can you can't have uh blocks that are larger than than a level like which is somewhere between one and one and a half megabytes which is uh actually like based the same limit as like actually lower than the current uh de facto limit of blockchain like today um the theoretically or just more duty to construct is uh 1.87 million advice and then with this uh with the limits in the CIP it would be between 1 and 1.5 million bytes depending on the amount of gas of gas in the number of shares

Industries

yeah

Tim Beiko: and maybe before we go to comments uh it's worth just highlighting also kind of the other proposal which was uh four four nine zero so this one would basically basically propose this to just reduce call data from 16 to 6 uh so a smaller reduction uh but then does not add these mechanisms to cap the amount of call data in a block or the transactions type and so it's just like a one-line change to uh the actual gas cost of uh call data in transactions and Micah I see you have your hand up

it's for a comment you said no comments

Tim Beiko: oh so sorry that was like the overview of the second proposal basically just like

okay

Micah Zoltu: yeah for 4488 why have the gas per block as a function of the number of transactions in Block rather than just having the gastro block create a fixed value like if our goal is to Target you know make sure blocks don't be too big why don't we just say

Vitalik Buterin: right so this right so this mitigates the uh the the two-dimensional optimization um problems like basically that uh the problem with adding any kind of extra limit other than the guess limit is that it means that the naive algorithm for filling out blocks is not going to be optimal anymore

um which would mean that like either um we have to um actually Implement some much more sophisticated algorithm um or um blocks created in a non-standard way are going to be more uh more profitable and so like more people are going like even more blocks they're going to be creative through flash Plus um so the idea behind the 300 uh byte stipends for transaction is basically that if you still create a block using the current naive algorithm and your blog fills up so the call data maximum before you run out of transactions or before it hits the gas maximum then you would still be able to

keep on including any transaction which is called Data less than 300 bytes so you'll still be able to keep on including 90

of the mempool

Ansgar Dietrichs: and just a brief after that like uh it's important to know that basically in the extreme scenario so like say roll ups become very uh popular well this is an effect and you have a one big roll-up transaction every single block more or less um that would fill up almost all the call data and this would also start interfering with the 15-59 algorithm right because basically if you don't have a stipend then after this roll-up transaction there could only be each transfers because those are the only transactions that don't consume any extra call data um but you might just not have enough

um each transfer demand at this it will kind of face feed level and so the basically would be artificially depressed um and then you basically have the the role of transactions doing your first place auction again on the on the um priority feed so basically this just ensures that blocks can be produced as normal right

Vitalik Buterin: so like in that kind of extreme World basically the Roll-Ups would uh sometimes end up competing By Priority by setting a high priority fees and if your transaction is one of those 10 that has really been accelerated then you would have to push your priority fee up to compete with the Roll-Ups but if it's under 300 then you would still be able to um get in with a free with this game usual priority

of one to three uh Andrew C you have your hand up

Andrew Ashikhmin: uh right I'd like to relate Alexis concern and his concern is that with this change here we might incentivize we might actually prohibit the adoption of data sharding because the the input data on the execution layer will be so cheap that actually nobody will be incentivized to like to move to like data sharding that was his concern

foreign

Danny Ryan: yeah go for it oh just the data charting one would have eventually much more capacity than what can be provided there and does not have

the competition mechanism for uh additional execution and so I think naturally you would see the move to data sharding because one that would be uh the capacity would be exceeded and two likely combine cheaper data elsewhere if that actually became a problem in like the overuse and abuse of that mechanism you could have a fork to up the gas price of that after you had submission data

shorting

Tim Beiko: right so this would be kind of a temporary fix in that worst case scenario where

Danny Ryan: um yeah I'm not necessarily advocating for having to update it but that is something that could be done in the

future if we if we really needed to directly incentivize moving to data shards but I suspect

that's something I mean I think

Dankrad Feist: generally there's a strong case for just reversing this change when we have data shots why why not

right and

Tim Beiko: I guess yeah one thing in the chat uh that enscar said is obviously Chardon is probably still a couple years away um so it's you know kind of a medium term problem contrasted to like the current state of just High fees on the network um Martin you have your hand up

Martin Holst Swende: yes and we're wondering a bit about possibilities the game

um this algorithm so say you're a minor and you've just filled it to the full base Max call the different look but you have there's another juicy transaction about 600 bytes that you want to include so therefore you make three tiny tiny transactions um that just I don't know are at the minimum and that free stuff gives you another 900 bytes that you can put into the block is that something that can easily happen and it's not something we should think about and be concerned about

Ansgar Dietrichs: right so actually um this is um in a sense intended so basically the

idea is to to say that in a Blog the first megabyte of call data is really cheap you basically just get that Wallace for free and you just have to pay the normal call data pricing the the reduced three bytes to use the gas provides for it then afterwards call later just becomes um really expensive meaning that basically for every 300 bytes you want to consume extra and to invite is like a super tiny fraction of one microbi right so then forever is 300 bytes you want to consume x-rays you have to include one more transaction that's like this at the minimum twenty one thousand um a thousand guys and so um if you really like if you're in this situation let's say you have a 600 by its transaction and you're really willing to pay quite a bit to get that

in even if um you're not willing to compete for this Prime spot in the beginning of the Block it's perfectly fine to even I don't know say use flashbots to create a bundle where you add an e-transfer in front or something again this would be like a super rare workaround but the the risk of the idea is just that it makes um call data after the first megabyte expensive it's it's not that there's a hard cap of 300.

Vitalik Buterin: yeah and you don't actually need flashbacks you just send a series of transactions with the same

sender and sequential nonsense that might end up in different blocks though which would

Vitalik Buterin: uh okay yeah that's true

Martin Holst Swende: yeah so well what I'm worth it basically

or what I'm seeing as a potential problem is if we suddenly start getting these padding transactions included in the book just to push it a bit further um which but the padding transactions are basically useless and just take a

bookspace

Ansgar Dietrichs: right but just like so basically if management section would only be a workaround for inefficient mining algorithms so because if you actually if the miner is runs the Mining Node that actually can deal with this then it kind of just reorders the transactions because they like again that threat invites is chosen the way where like 90 of transactions are below it so if you visit once you kind of deduct the big one megabyte roller

transaction um the rest of the block kind of like almost in all circumstances would on average consume um less um less call data than 300 per transaction basically smooth over over them and so kind of like the only problem that can can kind of cursed us that if the minor naively assembles the block they might skip a transaction with 600 call data even if if they just ran all of them it would still on average just work out fine and to block the pre-ballot and so if they are smart about it this will just never happen and so this is really basically just a workaround for um either miners that just run in in a efficient mining algorithm or the very occasional block where the average is even even for like for after the the big quality transaction is through um

average quality says it's still about 300 but like this uh maybe we're talking into box but I would just assume that's basically like one block a day or something and then having like two or three padding transactions a day which shouldn't be a problem

right yeah like basically it's like that's uh a very exceptional case because it would be both for the subset of transactions that is bigger than 300 um and for the um transactions in those particular in that exceptional case where call data actually is going over the cap um and also the other um it would have to be a situation where priority fees are getting so high that uh do like padding with uh junk transactions is a cheaper

strategy for them for the that uh sender than just uh mopping up their priority for you right because if you're willing to uh add on a bunch of junk transactions then you would also be willing to add on a yeah for your um a pretty big priority for you um so that is um that'll be my answer if we really want to uh made it to to make this uh not an issue we could basically say um that like there's the possibility of redesigning the EIP to basically say that data under 300 bytes doesn't um like um increase the stipend so instead of saying it's uh called like the total call data has to be less than a million plus 300 times the number of

transactions we would say the total number of bytes exceeding the byte number 300 of each other of each transaction can I can't exceed one megabyte so I guess that would be on like that would be less exploitable um though that would also increase the number of the number of times in which the in which the limit actually gets hit like basically because just people's random accidental um or ease transfers would not would not increase for women yeah and I don't really have an opinion about I just wanted to hear everything about it

Ansgar Dietrichs: and just for the record like if this

would really be a sustained concern then basically uh I'm sure we would find someone who would be willing to just write an optimized mine algorithm but that is smart about this so so this yeah so this one won't be relevant if no one else would do it I mean I'd be happy to do it myself

Tim Beiko: uh Lucas you've had your hand up for

a while

Łukasz Rozmej: so um is this possible that it will incentivize miners to like skip the uh huge call data transactions and have an uh affects uh opposite of the desired

Ansgar Dietrichs: and why would that be the case

Łukasz Rozmej: um so for example it makes the block smaller so they can I don't know propagate them quicker Etc

shh

Ansgar Dietrichs: right so that's actually a good point um I think um if you if we look at say the conversations around what is the expected optimal priority fee there was some kind of reasoning that like we would expect a priority fee slightly above one way uh to account for the increased anchor risk of um basically uh having bigger blocks and so it could well be that indeed miners choose to demand a priority fee of above one grade specifically for big call data

transactions right this would be a trivia rule to add you could just look at the call data and if it's some threshold you basically say okay I ignore transactions if they don't at least have two three four or five way whatever you eat the minus choose two to count to bank risk but this should like be just a normal simple kind of economic decision and it so and then there's this this simple level of the priority feed so it might well be that Roll-Ups just have to pay a little bit more priority just to kind of like um make minus

hole there

Tim Beiko: and I guess right instance a bit more is not 5x right like probably not enough

yeah

Vitalik Buterin: yeah and that would only happen in the uh like a dream world where we actually

are getting a like a megabyte of roll up data

every block

Tim Beiko: um yeah then crowd I saw you uh commenting uh about this this week and I think you feel pretty strongly this is something we should do sooner rather than later so do you want to take maybe like a minute to explain kind of your position and like why you think this is really important and like yeah and and probably

Dankrad Feist: yeah I mean I think right yeah I mean I I think like is this is like an an amazing

opportunity we have like if we think slightly less like only about the tech and risk side but also about uh well I've said before it would be nice to have some users on all core devs because like feasts of like hundreds of dollars are crazy and like everyone talks about this like literally everyone in the crypto universe and like we're pushing users away left right and center and like this would be the opportunity of a lifetime probably to like show that we're doing something and actually be doing something and in I think actually sustainable way because we do have a long-term solution for the Roll-Ups so it's just like a temporary kind of subsidy you could say for the

Roll-Ups in order to push this and um I yeah I I would basically argue that we should try to just get this done like even this year even if there are some risks associated with that but I think it's a very simple change and um and um I think that would show the community that like we really do care and uh and if you're still alive and punching and isn't like completely ossified and can't even make a change like this in in several months

Péter Szilágyi: um well I mean the theory sounds nice but uh I think you seriously underestimate the

effects that it has on every other part of the system I mean of course it's one that changes to drop the my the gas limit or the gas price but uh for example gas currency limits transactions to be maximum 128 kilobytes uh if you all of a sudden you want a lot of transactions going up to one to two megabytes as if that's a gigantic change that's an order of magnitude change on the network

traffic

Dankrad Feist: but do we need to do that I don't see why we need to increase single transactions like a rollup can single simply use like two three transactions to to load all that data on the into the block so I don't see why we need to change that

well they would use it like if you want

to use 1.5 megabytes that would be 15 transactions or is that a problem not for me particularly

Dankrad Feist: well I don't know how corrupts are currently constructed but I think the teams are probably much much better at making quick changes than we are and so if they need to pack it into five transactions to make use of this I'm pretty sure they will

Danny Ryan: yeah there's two very clear clean mechanisms to do that one is they just limit the sides of the blocks and be able to check in multiple blocks in a single uh L1 block and then the other is there already are mechanisms I think optimism uses for optimism pre preloads the data in a transaction and then use the subsequent transaction to

essentially check in the data um and so you could batch the you could do batches on the first rather than

needing a monolith IC already sorry what did you save Italian

Vitalik Buterin: I was just saying does it start we're using restricts already because like I think there are stocks are going to be obviously bigger than

128k

Danny Ryan: yeah it seems likely

Péter Szilágyi: uh so the reason I kind of brought stuff is because um I think the past week or so some of the I think Robert Trump was opening issues on the Gap repo asking whether we could raise the the transaction limits to half a Meg and

uh essentially I mean there's definitely a sweet spot 128k was kind of put there as a salmon deliverance we could go a bit up but uh there are so the problem is that as long as nobody is actually using 128k transactions or maybe there's one per day it is almost impossible to to see one of the effects of of this is on the

network

Dankrad Feist: I think that's an orthogonal issue I mean it's certainly something interesting as well but I would say this is completely orthogonal to this to this change I would not say like we if we make this change we have to make that change as

well

Péter Szilágyi: okay but okay that in the same vein the other downside which I think is what I'll also mentioning uh with Comics VIP is that curls so essentially if you if you want to sudden every block would max out it's the best definitely have you mentioned that that would be about a three terabyte chain growth per year so what do we do about that

yeah

Micah Zoltu: and this was my comment as well that I agree with what Peter said last meeting which was that well we don't need to implement the ip444 right away we need to commit to implementing 4444 um

in the future and four four of those don't remember is the one where we assert that we're gonna start dropping historical bodies and receipts um with that then the uh his history growth is much less of a concern without that then I agree that's like a big a big concern um so I would like I don't have a problem with the cap as long as it comes with the promise of committing to 444 eventually which means we advertise to users today that hey we are going to be dropping history rewrite your daps to not rely on infinite history storage

I

Danny Ryan: I totally agree and proof of stakes which is a great time to begin to

advertise that promise and to develop a group that figures out what the pain points are and helps to resolve them you know on the order of Seven Ten twelve months time

yes

Péter Szilágyi: that's uh that's why I was also before I wanted to go towards is that I mean it's so the thing is what we kind of need to be aware of is what the timeline would be so I mean we could commit to 4444 saying that yes we will start rocking but we cannot need a realistic attack plan for the whole thing because just promising that we will do it someday and then the changes grows wild

in between it is a bad place to be at

Danny Ryan: I think that we can reasonably form a working group that pushes this out within by the end of 2022 I mean it with an even more aggressive timeline potentially being available I think a lot of the changes a lot of these things that don't have to concern this group directly um and so it can be done in parallel without taking a lot of resources from this

Péter Szilágyi: Yeah well yeah so from my personal perspective if if we can get the 444 off the ground then

I don't see any particular issue with it um problem that it will be a bit weird a bit uh he copy when you all of a sudden you'll have large blocks appearing so I'm kind of curious how how the network will take it

but

Dankrad Feist: yeah I think we have tests on that right there there were tests I don't have the data in front of me but that has been done

in the past

Danny Ryan: yeah I'll drop the link right here

Dankrad Feist: maybe also comment on 4444 I mean I think that is the Assumption for data shards already anyway that such a mechanism exists so I I see like I see it as a given that at some point we will

switch to such mechanism maybe a question on this so right now the only real concern about having the sludge train data like realistically I could run a node with dropping all the chain data except that uh I'm not a fully functional peer-to-peer client right that's people could request data from me and I can't I can't give them those blocks because I don't have them

Micah Zoltu: also there are a large number of applications out there that will not work if you don't have history okay which I think is the harder problem that we need to do Target do some community outreach

to

Danny Ryan: primarily receipts is that the mechanism that we're worried about

here

yes there

Micah Zoltu: are some who also use call data which annoys me greatly but

um like or these your implants stop um store like um surveying transactions older than a year I forget what the exact change was so no longer indexing

Péter Szilágyi: transactions that's all that are older so if you you cannot look up transactions by hash but if you know that if you want transactions from block five then you can achieve it

Vitalik Buterin: okay got it

right

Micah Zoltu: and that's what and that's what a lot of apps do is they just troll through all of block history and ask for the logs for every single block in history

Lightclient: I think what's generally okay though because if they're doing this to populate their own database then we can just require them to download those out of band and run them through maybe a more sophisticated client but I'm like worried about the case where it adapts are literally calling your local client and they're requesting historical data

Vitalik Buterin: right right I guess uh look my impression would be that a lot of those applications are going to be crazy slow in the world where you're not talking to in Fiora already right like there's a bunch of adapts that are already basically even had to switch to the graph because uh like using ethereum's built in like a log query in for very long time spans is just too slow

Micah Zoltu: the one issue I have with that point of view is that we're basically saying everyone who built their apps to be censorship resistant sorry you're screwed and everyone who is using a centralized server everything will be fine for you

not necessarily what's

Danny Ryan: being said because being able to get historic receipts and confuse them in some way like and get historic blocks it could be them in some way should be part of 444 also being able to index them in a sane way should be part of

it and I think

Vitalik Buterin: yeah I think it can be done especially given that I'm expecting to have a serious push for the Revival of a light buoyant usage

um and now that's uh like um especially past the merge now that we have Alterra now that uh very efficient like lines are possible um and once you have like clients then like if you have a one event trust model then log dealing history player has been doing log queries and everything is pretty simple

Tim Beiko: um just a I guess kind of bubble this up a little bit um do so obviously there's concerns about uh chain data growth uh some concerns about just like the max transaction size which are you know we can kind of sidestep for for now um we we spent a lot of time talking uh earlier about like the the kind of

optimal block packing strategy um I'd be curious to hear like just between the two proposals like do people feel like having you know a lower call data cost with a couple additional constraints is you know significantly harder to implement than just changing the actual call data cost um is the or basically the flip side of that is whether just changing the call data cost even if it's not lowering it by as much is already kind of too much in terms of the worst case block size so we would there's not a world where we just lower the call data cost because we need some cap anyway um so I guess yeah kind of a roundabout

way of asking like you know is there basically like a proposal people feel it is more realistic or like you know simpler to implement um yeah just so we can kind of focus the the conversation and otherwise more explicitly like would say we just reduced from 16 to six and had no other mechanisms or no cap in the block and whatnot would that be you know chain data growth aside which would be slightly slower um than than producing the three you

know would that be reasonable

right

Vitalik Buterin: so that would be a uh a maximum block size of five megabytes 30 million divided by

six

Danny Ryan: yeah that seems worse cannot have it and I think the additional complexity is probably minimal to get the additional validation rolling

does everyone agree with that I think

Micah Zoltu: I agree as long as we're okay with um punting the block stuffing strategies to Searchers and professional block producers and we just say hey it's their

problem because in that case it really is a very easy change there's one line basically if we want to force the guest team on the other hand to go and design a Better Block stuffing strategy then that costs you know a quart of time significantly more and again all the clients

Ansgar Dietrichs: yeah yeah but I mean just to retreat there like that's basically exactly what the stipend mechanism is supposed to address so like I mean we talked about it earlier like but with the even if you do the naive thing um

it's already basically you already get 95 to Optimal blocks you have the occasional situation where it's maybe little bits of optimal but it's very close to Optimal even even with an

iPhone rotation right

Micah Zoltu: so if everybody's okay with that then I don't have any problem with uh four four nine zero no the other

one yeah I

Tim Beiko: guess can we get like a client team to confirm or say they have no idea and needs to you'd still look into it more oh I see Gary is

unmuted

Gary Schulte: yeah I was gonna say I don't think baseball has a significant portion of magnet uh mining but I think that we're okay with the making this change

Tim Beiko: got it Edgar your hand is still up is that uh just

do you have something oh

Ansgar Dietrichs: this this time it's actually on purpose

Tim Beiko: okay perfect

I just

Ansgar Dietrichs: briefly wanted to uh kind of try and bring this back on on timeline discussion because um I generally agree that the kind of a general commitment to something like 444 or just in general basically that we say that in the medium term we expect or like we have certain that the chain like

that that science will no longer by default provide all the history basically if we are certain about that in any version right like it doesn't matter like how exactly we end up doing this but like then I think something like that is indeed would be important to you um but at the same time I I would want to say for context that right now uh we only have a few Roll-Ups live on mainnet and those usually only settle very occasionally I mean I haven't talked specifically the optimism but like ZK saying concerned that that's I think last time I checked was every couple hours and so there's a long way to go between the concentration and the situation where they settle every single bed like one world upset is every single block

um I mean hopefully of course we get there because that that means we we have more options but it won't be that like we turned this on and we immediately have a kind of yearly growth of three terabytes um this would be like the long run situation and even then like it would take a year to get to the the three terabytes so I think it's something as we're saying is bigger as long as we kind of reasonably certain that by the end of next year we have some version of History um uh limiting history in place or even by I don't know early mid 2023 this would be perfectly fine and the question is just like are we busy because because if I think a lot of people here would really want to see

this change in in a like special purpose fault before the match and for that of course the timeline would have to be quite accelerated on decision making um and the question is like if if it takes us a lot of time to kind of like discuss the details of focus for on the way there basically how comfortable are we with already making a preliminary decision on like a special purpose fog for this before we kind of fully worked out the details before I think that's really the the main question

Tim Beiko: right and I guess maybe to like give some context on the the timeline you know the the default say path if this was accepted is we'd say like oh it goes into Shanghai and realistically you know Shanghai is like a year away uh

plus or minus a quarter um and you know the the pushback there would be well transaction fees are already super expensive they're like non-trivial on Roll-Ups and like waiting another year to reduce them is is just really bad um and so basically the the options you have is then like there's something between the merge in Shanghai that's just this um and then you know you also open up the cam there of like all the other things we want to do after the merge um then obviously with the merge itself that's a fork um and and and you know we're uh we're already making two eips there uh the

trade-off is you're obviously adding more complexity to this already massive upgrade the other thing is uh we discussed on the last call potentially having like a an empty Fork before it emerged to just set the fork ID for the merge um and so that's a time where like we might have to get everybody to upgrade their notes anyway and then the other option is like you have just you know a completely separate fork with just this um and at the risk of potentially pushing back the timeline for the merge I think that's the other thing it's obviously um obviously you know people are very excited about the merge uh you don't want to push it back for you

know for a bunch of reasons um so if if we have a completely separate Fork you know is that actually pushing things back or is that maybe the most efficient way to do it because then you're just separating concerns much more um I think that's kind of the timeline discussion like yeah the yeah the way I see it is like either we have something completely separate either we bundle it with like some Fork ID change or with the actual merge itself or we basically wait until after the merge and then the problem is just you know High fees on Roll-Ups uh basically persist until then

Danny Ryan: so the the fork ID change wouldn't that wouldn't be two software releases so like that would be say the fork ID changes

two or four weeks before the merge is supposed to happen you upgrade your node before them you don't upgrade your node a second time later so if you coupled this or anything with that then you now have coupled them inextricably and are yeah so you you don't do that really until the merge is ready to be released and so I I think that type if you do want to do an aggressive timeline for those tightly coupling that in that way actually encumbers things that makes things a bit harder rather than doing something independent

might do something my two

Péter Szilágyi: cents would be not to couple this thing with the merge because the merge is messing up by itself and you don't want one extra stuff to debug

now as for whether to do it before or after I guess if somebody just creates a proof of concept we are to see what it would take then it might be interesting to consider whether we can without delaying the merge if not doing it after the most only the only downside there is that that era please the upside would be however that after the merch we would have a nice nice symbol so to say hard Fork to test out how we can Fork staff post merge world which isn't a bad thing either to have

is it oh sorry and Scar go ahead and and Drew after

all right

Ansgar Dietrichs: I just wanted to grip with Dimension so that um quote looked into a Justice for curiosity into like an implementation of 4488 and um physically implemented it didn't get untested yet so it's kind of like definitely only like a prototype but that was pretty straightforward so I don't I don't think implementation complexity would be high um and just the other comes that I would want to make it's just that I think we have talked in the past repeatedly about that there's a problem with with the awkwardness governance structure and that like use their voices uh kind of underrepresented and I think this is

really kind of like by far the most kind of pure purified example although no no no instance of this but I think we basically like I I think that the user side is very overwhelming for kind of trying to to do something like this before the merge if there's any chance put and listening to it at least it sounds like on this call everyone was at least ambivalent so like I didn't hear any strong opposition against this so I would just kind of like argue that we should do this before the merge because we are more or less ambivalent but the community is like extreme like very strong I don't always say it but like it seems like the community is very strongly in favor of something like this before the match I even saw a lot of people saying like

yeah the merch is divided by a couple of weeks um and I don't even think that's necessarily the case but like if even if that was the case um that would be more than worth it so I I really think that we should kind of try and even if no one is on the call here like to represent this kind of this broader set of people but like I think we should really keep in mind that that is an important

Dankrad Feist: maybe we should treat it as value urgents and we should do it before Christmas that's my opinion

Louis Guthmann: I I agree I I agree with that 100 I think it's uh it's uh we'll provide the change in both in narrative and costs for for users to do the migration to to Roll-Ups in general

Tim Beiko: thanks for sharing Andrew

Andrew Ashikhmin: um I think it's not a good idea to do it along like at the time with the match because yeah I agree it's better that the merger is already complex enough um and if we decide to do it before the merge my slight preference would be to go for the simpler 4 for 90 because it's a kind of a more trivial change than 4488

foreign

Andrew Ashikhmin: engineering capacity or just on like analyzing kind of the second order

impacts of the change I think it's the second order impacts because um like it's not hard to add uh next validation but like them there might be uh implications for block proposers and so on

okay

Tim Beiko: so would it be valuable to say like in the next couple weeks get feedback from I don't know say flashbots or I don't know what team like sub team that has experience in like the mempool to see you know how easy or hard it is to have an optimal strategy would that like help

with these concerns I know Aragon also has like a separate design for the transaction board so I'm not sure if like yeah if it's helpful to say have an implementation in get or if if that's just you know so different from what you all have um yeah I guess I don't know yeah what would be kind of the way for you to like feel more comfortable about that this is just taking more time is it seeing your proof of concept

um yeah uh well

Andrew Ashikhmin: well it's probably a relatively easy change so we can do it but it's like it will be some development work it's not like changing a single constant right so it will delay the merge more than just like changing a single

constant right

but

Louis Guthmann: I even want to point out that you we could uh mix you know make for four four nine nine nine and like zero uh 92 like you know before and and then do uh 4488 like there are no I mean they are uh for 44.90 is just a simplified version and uh 44 88 goes just deeper

Vitalik Buterin: right but then are we okay with what's the possibility of five megabyte

bucks

Louis Guthmann: yeah I mean that's a that's a very good question and uh and I don't have a good answer for that I don't expect me um those two actually happened because

obviously there is like the uh there is a Max uh size transaction by a gef which is 100 kilobyte which will mean that every time we're going to publish a transaction there is at least 20 20 20 000 uh gas to spends on on the on the signature itself like another base cost so we will never get to that numbers but I didn't quantify the actual

Vitalik Buterin: uh right but then if the argument is that we'll never actually get to it then that's also an argument that whatever the issues with optimization with block optimization

Micah Zoltu: right the I think we need to remember is

that if they someone can like crash the network or break a network or whatever by making a five megabyte block we will see if I megabyte block I don't think the question is are we likely to see one naturally it's will one break the network and if so we will see it

Danny Ryan: and block production often bypasses the mempool so the eventful doesn't necessarily like the validations of an input doesn't really in today's practice bound bound to what is going to go in there

Louis Guthmann: that's a that's a very fair statement I um yeah I don't have a clear answer for that it's also notice as someone said that in the worst case uh due to even 259 it's also go to 10

megabytes on the worst case um in in the worst case scenario when yeah because the

13 million guys

Tim Beiko: well isn't like 30 million divided by six gas the five megabyte block isn't that the worst case

Louis Guthmann: let me check

yeah because I mean if it's if it's six if it's six gas per byte

Louis Guthmann: right right right right you're right yeah yeah I will confuse sorry sorry

Tim Beiko: yeah so the worst case is uh a five megabytes not a 10 megabytes um and obviously that's worth noting that like uh it's it's easy to send one of these worst case blocks

but then if you're spamming the network with these five megabyte blocks the cost goes up exponentially so um so you you know you can't send like 105 megabyte blocks in a row the cost to do that would just like be millions of ether with the

basic going up

Tim Beiko: you can basically send 10 wait a half an hour send 10 wait a half an hour that's that's like a expensive but not like completely out of reach strategy yeah or do 2.5 megabyte blocks forever

yeah

Péter Szilágyi: so just to add with them since we're talking about five megabytes of 10 megabyte blocks I wanted to add that that p2pn has a message limit of 10 megabytes so essentially a 10 megabyte block would be impossible to propagate uh probably possibly eight megabyte is I don't know so I'm not entirely sure what the payload caps are but uh I I think that has a cap or two megabytes or something I don't know it had a pretty adverse cap on how much it's willing to forward so that's one potential issue and another Financial issue that we should not forget is that the block propagation is essentially every block

it's forwarded it's unaskable it's also forwarded to square root of your peers now if kept by default runs with 50 years that kind of means square root of 50 is what seven so it would you will actually propagate it to seven years and you kind of expectedly you're going to get it from Seven other appears that you have so he is going to cross your network line 14 times so you have a five megabyte dialogue that's 70 megabyte of data traffic just for that one long and propagate through the method that's a pretty hefty bandwidth requirement right

Tim Beiko: one thing sorry Lucas I'll get to you right after uh this but one thing that's worth highlighting also is um next call is the last call of the year so next awkward Dev calls will be December 10th then the next one would fall on December 24th I don't think anyone here wants to have a call uh on Christmas Eve and even if some people did we probably get quite low attendance um and if obviously we're talking about potentially doing one of these changes before the merge um you know we probably want to have consensus on it hmm if not you know by the next call definitely by the absolute First Call in January

um and so I think it's it's just worth kind of highlighting that like to see I don't like the people think we should like think basically plan out to think about prototype a potential fork for this in February I I don't think we need to agree to it today um and if so basically what are the what are the things that we want to figure out in the next two weeks right like um and and can we potentially come back with that and and make a decision or like get closer to a decision on the next call just because yeah if if if we are doing this before the merge it we we need to make the decision sooner than we

otherwise would

Micah Zoltu: can we make the decision today on um committing to 4444 or something along those lines so that way we can start the Outreach process sooner rather than later is anyone that disagrees that we should do four four four four or

something derivation

Louis Guthmann: um there there is some Community disagreement over the uh change in security assumption from Community grow up so I I don't know if the community will not fight those already seen someone on Twitter being extremely active against

four four four four questions

Ansgar Dietrichs: maybe uh because you might be the best to ask

um it isn't because we we expect Roll-Ups to to move to um sharding data availability in the next two or three years anyway and starting as Stanford pointed out so it has already the same security effect providing like data availability like of the con data but not not the history so so this isn't basically isn't that the same situation that we have to end up long time anyway

yes

yes

Dankrad Feist: and I think it's a misunderstanding like people people confuse um data storage and data availability these are different properties and and uh um I I don't I don't know like uh Luis

did you get this from any uh from any actually like roll-up people I I know there was someone on Twitter who did that but I think they didn't understand

the problem so

Louis Guthmann: so so From perspective of DK roll up uh there is a solution to four four four four uh which is to have like enough chain uh queue of uh of latest uh like Win Slots uh where touch or modified so that wouldn't be too I mean there is a way around uh forziki everyone to manage that I'm not familiar how autistic web can sustain uh at least gender assumption so I I I can talk on behalf optimism without you from here

oh

Ed Drew

Andrew Ashikhmin: um yeah so we discussed uh four four four four four um inside the team and um we are not opposed to it so aragonism flavor of it

Tim Beiko: thanks

Danny Ryan: right and I mean the the assumption is that 4-4 is coupled with uh historic block distribution standards that are outside of the P2P Network um and that if the blocks are available by any of these standards you can always recursively validate all the way to the the base of the chain uh via knowing uh recent information to secure information about the head and so the expectation and data availability is that data's

made available and then those that want to have it and can use it and there's not uh security risks around state of holding tax and then once it's made available and infrastructure and communities they're utilizing it then it's ultimately their problem to store it in the long run

Dankrad Feist: yes agreed um like basically we should be careful because data storage is not an attack Vector you can't make someone forget data you can only withhold data in the first place that's an attack

vector so when it comes to roll ups we don't

have optimistic relapse people here but since star queries here uh how does star query would why would for Force impact the ZT roll up where would the roll-up use

Louis Guthmann: that's a very good question for ZK roll up uh I think there is a solution which is as I said keeping Q of the of the like data being stored on on like when it was modified published and republished it uh before the grace like before the destruction of the data to uh to guarantee that availability over time and what I'm saying is of course you require engineering work and uh it's something that would be quite uh like an

extensive modification of uh of the what we call Core OS of stock Nets we can manage it we can probably work around it but what I'm saying is obviously crop I don't I can't talk on their behalf so they should

to jump

Dankrad Feist: in there I don't like I understand what you're doing but I think you are you are operating from an extremely pessimistic security model and I think what what you do there is not necessary and that's what I think ways to do that I I'm I'm uh so you're basically saying you basically want to use the ethereum data availability layer as your storage layer which is what

you said yes that's what you should do

Dankrad Feist: is because I think you're spreading fat I don't think like you are having a super pessimistic security assumption that you say everything has to be reconstructible from the current data availability layer and I don't think that's that

so I'm sorry just because

Tim Beiko: yeah just because we have only like five minutes left um obviously four four four four is going to need a lot of community outreach I suspect whatever version goes live is probably not exactly what's the Eep today um but something like it is probably like has to happen at some point um agreed yeah and we can't I don't like we we can make some commitments towards like pushing this and and whatnot I I

think we probably can't do that in the next two or three minutes um what I think we can do is try to highlight like you know what the different teams want to see to be comfortable with 4488 for in the next two weeks um and so obviously trying to have implementations across all clients is one thing and then Andrew's concerns about like and and others have raised this as well but just around like how you do optimal kind of block packing I'm not sure if that's something we can get done in two weeks but it might be um it might be something that even say we have you know the client implementations ready uh we still need to figure that out but we we don't necessarily have to block everything on

it and I don't know how like would most client teams have the bandwidth to prototype this in the next two weeks um if not I'm happy to reach out and try to find teams or contractors that can that can work on prototypes um yeah how I guess I'm curious yeah how realistic is it for like client teams to actually spend some of their Cycles on that in the next on on 4488 to be clear in the next two weeks

never mind

Łukasz Rozmej: can try to prototype it in this

week cool I

Louis Guthmann: I just want to correct one thing

before I drop before we drop uh I'd uh I did we've done I I'm not trying to film just you know that's like I was just expressing the current security mode and I maybe the security mode can be changing I agree with that I was a 444 is a necessity there is no doubt about it uh I was just saying that uh we

should I think we should took that off the call

Dankrad Feist: we should take that off yeah to explain to you why I think it should be different

is

Danny Ryan: critical that that it becomes the model if you plan on using data sharding because that data charting not going to provide persistent data storage guarantees for all

the time

Marius van der Wijden: so

um uh Tim one thing that I would really like to see is what's the like what's the worst block what's the what's the worst like with the current packing algorithm if we change it to to um to to this this new one like what's the difference between uh like a like how how different can this this block be from like a really uh like smartly packed block um like if someone could work on that that would be really really nice

and by

Tim Beiko: the worst you mean the most damaging from the for the network basically

or

Marius van der Wijden: no I mean I mean like um like given a set of transactions uh

and uh like a smart algorithm to pack them uh how like how much overhead can can there be to like the the naively packed uh version of that

block and when you

Ansgar Dietrichs: when you say okay you mean kind of like lost profit for minus that kind of like Solutions extra okay because that I think it does make sense to kind of analyze like an artificial worst case because you know it's just construct a case where basically transactions are pending in just the right way that you kind of like lose out on a lot of of profit but like I mean that's not an attack Factor kind of like taunting someone as potential profit and they're not giving it to them that that that's not an attack um so basically what you'd have to look this is just like historically and like

historical just real world blocks and say okay if we had this naive algorithm basically and we just assumed there would have been one extra big transaction in the front that used up a lot of The Collector cut kind of like how much would you have left on the table that that might be interesting

about this

Tim Beiko: is that something you have to bandwidth to look at and Scar because you seem to understand the problem pretty well and

Ansgar Dietrichs: um yeah yeah I could take a look at that if someone else also want to look into this or something if we do to reach out

accordingly

Tim Beiko: and uh Yeah so basically so there is a PR against guests another mine can

prototype Aragon can probably pull in the consensus changes but not the transaction for changes um and it would take some extra bandwidth to do that uh base you uh I get okay so there's a comment by base you is this something you think you could prototype in the next two weeks or is this something where if somebody submitted a PR to base you would make your life much easier

Justin Florentine: yeah we're always open PRS um you know two weeks for a prototype would be tight for us but um I'd have to talk to the rest of the team

Tim Beiko: so I guess let's see let's see if two weeks if you are listening to this call and like you've got a Java or go background and you can

help with PR's uh please reach out to me um yeah we can definitely kind of find or set up some some bounties and whatnot for that um and yeah I guess in two weeks we can get back here and discuss and see kind of what the progress made you know how how realistic is it to put this uh potentially before the merge

work

Danny Ryan: I think that the EF can also commit to uh providing resourcing for pushing four four four four along uh throughout 2022.

Tim Beiko: um cool we are one minute away from time but uh there's someone on the call who had a quick shout out uh so Zach is here he's working on a documentary about ethereum uh called infinite Garden so uh he'll probably be trying to reach out to a bunch of people on this call and and others in the community over the next few months it's already started uh so yeah I just wanted to give him a few minutes to kind of explain uh what they're working on and yeah

as far as your exactly

thanks Tim uh yeah I just don't want to take too much time but I wanted to jump on and obviously we are huge fans of the work of the core devs and um we were making this film called ethereum the infinite Garden which was

actually funded by the community via a mere crowdfund on Mir and it's allowed us to kind of focus on how ethereum is already affecting people's lives around the world we've been filming all around the world um and how ethereum will affect people's lives in the future so we're filming through the merge uh and obviously the work of the core devs is fundamental to the story of this film so um I just wanted to jump on and you know if uh we pop into your telegrams we wanted you to know who it was so um you know we'll be talking to a lot of you moving forward and yeah really just appreciate the time and all the work you're doing

Tim Beiko: thank you uh where's the best place for

people to reach out if you know they want to pin you they have something interesting to share

yeah absolutely um my email is Zach optimus.co.co and um you can check out all our work our previous films that were on Netflix and HBO on that on optimus.com uh so you can check out the website and our contact info is on there as well um but yeah probably email is the best

Tim Beiko: awesome thanks um yeah and one last quick thing before we go um uh Trent is organizing emerge Community call next week at all core dev's time so 1400 UTC which uh is now a

new time in uh I guess Europe and North America because of daylight savings um so uh yeah if you are uh basically a infrastructure provider tooling provider application that wants to like see what the merge what's happening with the merge ask your questions get the updates uh please come next Friday there's a link in the chat here it's on the ethereum PM repo for the agenda and uh yes final shout out please update your notes uh if you are running a node on the proof of work Network right now uh Arrow Glacier will have happened before the next awkward devs yeah Happy Thanksgiving for Americans

um and yeah thanks for anyone in the US who made it on this call much appreciate you spending uh your holiday weekend here with us and yeah I think that's it uh thanks a lot everyone this was this was really really good thanks Tim

thank you Tim thank you thank you have a great day [Music] bye [Music] thank you thank you

[Music] come over to the fourth floor side [Music] foreign [Music] [Music]

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

foreign [Music]

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.