RollCall #2.1 Breakout: 4844 Testing

Transcript

okay yeah welcome everyone um this is the 4844 Readiness check um roll call breakout so the idea is to just basically um hopefully bring most of the of the um all two teams together that that are um already kind of actively working on on starting to to move over to to to blobs uh once they they'll be live on mainnet and in that process also already either at least looked into into testing that or maybe already actively actively um doing so on any of the maybe the old Deets or now um on girly or maybe are getting ready for for the upcoming syoa for um so basically the we don't we have

a relatively light structure for the call to to leave just room for for for conversation for specific kind questions or issues that um the teams might have uh we have some people from from EF devups uh on the call which is really nice um because they've been very of course actively involved in in in testing both both B on in the devet stage and now also with with the test Nets and so to start with um it would be really nice if if if if if one of you all could uh maybe just uh give an update of um B basically um how how the how the G Park went how the situation there um looks now what what specifically kind of the The Blob testing on on girly looks like um that

would be a good Stu yeah um I can start with just uh what we have running right now and then go into girly so since December we've had devet 12 running um there is already blob expiry like we've passed the blob expiry window so if anyone's building tooling where it would be where it would make sense to test blob expiry please use DEET 12 um in case you're having any issues getting funds for the network just ping either barabus me or PK or anyone and we'll um make sure you get the funds you need to test um we do have a public RPC there so feel free to um use that one and we we do have some quick start guides if you want to just

spin up a note especially since it's just like a month old test net if you're starting off with testing it's a great place to just syn up a node and start using it um that being said we had the girly Fork last week and the fork is now stable we're seeing a healthy number of blobs but the blobs are being artificially induced right now um we did have a non-f finality period for the first few hours where we found a bug in the prism client but that has been p uh patched and the network is perfectly fine now uh we still haven't passed the blob expiry window so we're still within the 18-day period um we have goomi blob which is a blob spamming tool um maybe

PK can just quickly um link link that or say what it is um and using this tool we're inducing between three and six blobs uh ideally we'd like to stop doing this and hand over to more organic blob traffic because the main purpose is to understand how the peer-to-peer Network behaves with Organic blobs so it would really help if layer to start deploying blobs themselves and same as a previous network if you need funds to test or if you need help getting your node up or if you notice anything funky please feel free to reach out and we'll help you out great uh thanks per um I was going to

next go into maybe like around where all the rollups that are on the call all the teams that that are on the call can can can May briefly um uh just just give give a very quick kind of summary of um to what extent they already started um actively looking into into kind of testing um or basically how close close they are to that um so yeah so if we uh of course I I don't really there's a lot of names here that not all of them I can map to to L to so maybe if you just um you know raise your hands and then then I can kind of call on you um yeah Roberto I see see you first so you want to go first yeah sure um so we are activating um what we're calling the ecotone fork

on on Opie stack on our Dev Nets at noon today um at which point we will be enabling blobs on the Batcher um so if all goes well in about six hours or so um we'll have some initial results of uh you know starting to take advantage of it this is obviously on on Gorly um so that that's kind of where we're at right now and this is for both bass as well as uh op's devet okay great um the Peter next yeah hey this is Peter from scroll we also have a few more people from

scroll on the call so we have a development plan and publish an article our initial thoughts as to how the circuit implementation for 44 would look like and we're actively working on the contract and circuit implementation but uh we're not ready for testing yet also um we are in the process of deprecating a g test net so I think for us realistically our testing will start on sapoia and then on minut that makes sense and yeah it seems reasonable that the on the ZK set of course there's there's more work needed for for integrating with with with plops um yeah next also I'll call on all of

you and if you by the way if there's any specific of course issues you've already ran into something or specific topic you want to later on in the open section want to discuss feel free to also already mention it Um Zack you want to go next sure uh hi Zack from ZK s so we've finished development for and audits for our contracts and circuit side um of changes uh we're currently working on the changes to the sequencer that need to be done so we're planning on um getting everything ready for devet I would say for the support uh Fork uh hopefully we can try to get

it for the end of girly but that's the current working Target um one thing I was kind of curious about uh chatting on after is just the overall the number of blobs that are going to be supported I know that uh blob traffic has been kind of artificial and spammed but as we were trying to uh do some manual testing we did see the fee Market jump up to about 3600 Quay uh which uh was a little bit high so just curious um once all these l2s start to implement it if the target of three with the max of six is going to be enough to handle everyone's uh

data thanks and yeah that's that that's a good good topic um I made a note touch on that uh Lee you want to go next hello yeah I'm from offchain Labs integrating 4844 to arbitrum Nitro um our current status is that we've employed a defet 2 gly with blob support and have posted uh some blobs but um we don't have yet any sort of like automated spamming or much activity going on there yet um we've also test tested out the fraud proof integration with kcg proofs um the two sort of issues that we've run into so far i' say

are that um go ethereum's uh Dev flag doesn't seem to support um Cancun or at least then it on the last version I checked and this is a slight impediments testing because we use that to um do a lot of our testing of the onestep proofs um we could spin up a local devet and CI but using g- Dev flag generally makes this easier um the other thing we ran into is that the latest go ethereum release doesn't support the blob version to Hash field for eth estimate gas so there's not a good way to estimate the amount of gas a transaction with blobs

will take um I'm not sure if other execution clients support this but uh and I know that go ethereum has merged in support for these rpcs to master but I just thought I'd flag those two things we encountered in testing thanks yes that's that's very helpful um we I I do know we have at least one uh P St on the call as well so we can we can Circle back to this um ji you want to go next yes we are actively working currently in the in the circuit uh uh for the for verifying and for verifying the the blops and uh we expect to start actively testing in testet in

three weeks a month uh more or less we probably do some uh I mean some spot testing because all this part of sending the transactions will probably start before maybe next week or in two weeks but the the full test net uh working we expect about a all more or less okay sounds good and would you guys be targeting gly or would you be targeting one of the other networks we're targeting seia actually we have two test Nets running with the inle and sepolia so we

could activate in both but the idea is to go early to obsolete that and uh keep the test net in sepolia and for internal testing uh I mean we probably deploy something internal but in general we work in seia that's our main our main testing Network yeah thanks sounds good okay um is there any any further teams anyone um I mean those were already quite a few so um anyone maybe even if you're not the main person responsible something uh sorry my local setup of Zoom is uh is

buggy uh I could not raise my hand uh so uh I'm PR linear uh and so the update is that we are uh currently finishing the deployment of our circuit and we are targeting early uh with an intermediate release that does not directly use 4844 uh and the only missing step is uh the C evaluation uh which we will uh start integrating and we will be targeting first uh both sepolia and GLE okay um awesome thanks um yeah as expected I would say it's basically

self- selection the people the the teams showing up here are the teams that are already relatively far in in the process um and and and sounds like most most are actually kind of targeting to start testing actively um on on the on the test Nets before we reach me that's that's that's good to hear um uh yeah Harry I just wanted to like Zach post it in the chat but I just wanted to to reiterate cuz I think it's a useful point the the lack of blob has op code in solidity or any decent way of calling the blob op code is definitely like a

pretty annoying paino where at least for our use case basically we were forced off into deploying a separate Ule contract that then gets called which introduced a variety of comple of annoying sort of extra complexity um basically kind of all due to the fact that solid the combination of essentially solidity not supporting the verbatim block um to allow you to um call an unsupported op code in your mean solidity code along with the fact that solidity not adding uh Cancun support uh in in a version supported think this this has come up on like the last few hard Forks where the last couple at least I remember where kind of there's

new behavior that teams are sort of you know hoping to adopt and and the and pretty painful because the language tooling support isn't there yet it's definitely an interesting uh issue in terms of kind of the timing of of how things come together yeah I do remember this this coming up in other context as well that's that's uh quite quite interesting I don't think we have anyone um from solidity on um at least I also I didn't think of of of inviting anyone but that that's a really good kind of topic to follow up on um yeah so before maybe we we go to to the to the the open open section um that was already a few few

points race that we can talk about and then whatever else um people want to talk about maybe just uh very briefly um um par anyone on testing side if if you want to very Briefly summarize kind of from um from here basically um the remaining steps before we'll we'll reach main net just just we of that as as mind I mean I guess everyone kind of knows but still yeah so um the next step is foring sepolia and then we have H SK the last test net after that the dates have been set and the last releases are being made either today or tomorrow you should expect uh EF blog post by the end of the week as well um so seoa will be fing on

the 30th and uh hsky will be on the 7th the idea is that we want to still wait to see blob expiry at least on one network and the earliest we can do that is with girly that should be in the first or second week of February which means um we should have all the data that we need to decide on a main net date some point in February and the fork itself will probably be some point a couple weeks after that once releases are made um I think that's the critical part right now um so we want to see blob expiry we want to collect data from networks and and we want to make sure that at least some l2s have tested um their framework so that we know that

we're shipping something that's useful sounds good um with that yeah we can uh we can go to the open section maybe to start with um Matt I see you you're on the call there was some kind of questions about the the get kind of Readiness Readiness with with with flag and everything do do you happen to to to know kind of the the status of that and when that will be kind of ready yeah I need to look on the dev flag I'm not sure if we allow uh if we allow people to configure developer mode for different Forks than

what's live on mainnet I was just trying to check that right now but as for the RPC I think the those were merged to master and we had a release about three hours ago so the estimate gasta should be available um I think one hacky way of going through Dev mode without the fork being configured at Genesis is to start Dev mode in the previous Network and a previous fork and use-- override. canun and just set the time stamp to now so Dev mode will start in the previous for and just do the for immediately and I don't see any reason why that wouldn't work so I tried um setting-- override do Cancun equals zero uh the issue is that

lock production failed because the beacon sort of the simulated Beacon node in the dev no in the dev mode um doesn't support Cancun or at least doesn't seem to I think it was responses with zero you trigger out of um order of fkk execution you should try time do now okay I'll try that out yeah we've been trying that with vle so I think there's no fundamental reason it shouldn't work but yeah maybe some config is missing for Cancun yeah I just wored that the simulated Beacon Notice missing Cancun Fields but thanks yeah I mean the similar Beacon is

definitely missing the the field so I don't think like even if you do trick it to get into the Right Fork you're not going to be able to utilize any blobs um so so I don't know what the timeline for getting that updated is uh generally we've sort of kept developer mode up to date with whatever the latest Fork is and so you know on Main net and so that's something that we should talk about as a team to see if we can like support these Fringe cases where people are trying to test for the next Fork that's coming up yeah it seems almost that's because we have had that topic now in two different context that um separate from

44 specifically kind of basically tooling Readiness for for for testing upcoming forks and features that seems to be something in in general we we we could look into um and and and further improve I've definitely heard that also in the cility context in the past um and as we heard with with the blobes um upcot now um and figuring out a good strategy there um and and ideally of course something that then also I mean you know once we once we start talking more about IPS and and possibly having features um over there that that that not on mainnet but that we also that of course also teams want to use and and test and everything and having having kind of good good uh ways of of doing

all of that seem seems like a good topic to look into in the future um right so so so so those then just just to to briefly kind of finish what the points that were already raised um uh I think Zach you mentioned kind of the kind of a question possible concern around um for it for for throughput um of course maybe if you if you can uh can CL clarify um you said when you when you were testing a little bit you you saw kind of relatively High uh fees is that specifically was it was it on a on on girly so basically because because so

so so of course the the point being that um I mean yes we we have limited two put with for before it's not in itself necessarily A scaling solution it's it's mostly just a kind of this this fee Market Innovation so you don't have to you no long have to compete with nft drops for for fees so so of course there's at some point and this will hits its capacity limit but I think specifically if you if if you're testing on one of the test Nets where there is active blob spamming by by the by the the devops teams going on then then that basically means it already um saturates the the the available throughput so any any additional marginal throughput that you would cause would of course then um lead to a fee raise so can can you maybe briefly kind of clarify under which

conditions you saw very high fees um yeah sure um so it was happening on girly uh and after looking into it I think it was uh in combination with The Blob spamming that was happening but it basically raised the question for myself of uh is this going to happen on mainnet uh once all l2s are basically adopting 4844 I don't know how many blobs other l2s are planning on using but uh we're in the boat of uh targeting I would say two blobs per batch for us which is already two out of the maximum of six per block so if we have multiple l2s who

are all kind of um I would say committing batches with anywhere from like one to two uh blobs then this is behavior that we could potentially see on Main net um and yeah just having overall uh the fees go up um I just brought up uh some concern whether or not three a target of three blobs was going to be enough to handle um all of the data for all the l2s maybe I can jump in for the um fee um we are currently um spamming girly

with blops up to a a blop fee of 200 to 300 Quay so that's pretty high to just get blops in but we can obviously lower it to make more usable for you guys yeah I think we should also just set a Target to maybe fill one so that we don't have blocks without anything and then let the organic Lo take over yeah of course the problem is if you do that and while there is no organic load yet then we basically go down all the way to to to the minimum um fee so so I think actually setting some sort of relatively low floor for gray but then actually making sure that at

that floor you would always fill three on average and then just starting to Throttle Down once once we above that that would I think be ideal behavior I'm not sure maybe that's a bit too complicated but B Bally FL three and then if you we above that then you only do one or something but that could be a good kind of compromise um Lee yeah I just wanted to quickly mention in that context um sort of what uh what we're developing for arbitrum Behavior which is likely going to be that a batch if there's enough activity on a network especially with arbitrum one a that would probably include all six blobs um and this is just for

efficiency in terms of overhead smart contract layer so what that would look like is probably one block would consist entirely the the blobs would consist entirely of um of arbitrum blobs and then it would go back to obviously that wouldn't be true of every block but um that's sort of the profile that we would be looking at for likely looking at for arbitrum one um just a quick question I haven't gotten deep into the L2 world yet but how often are these batches or is that varying per implementation so it definitely depends on how much activity you have it's it's a direct function of that how many

blonds you need is how much activity is going on in the L2 um that said I think uh I need to double check my Na and math here but I think we'd be looking at a blob like every six minutes I want to say or cu um one blob is about uh 130 kilobytes which is about the maximum call data length that you can post with go to go ethereum's current menol uh pre blobs so that means that one arbitrum batch would likely consist of six blobs which would be about six current batches today so yeah we'd be looking at about when every six minutes maybe a bit more frequently than that for current arbitrum one load of

course that that's subject to which network it is um others might not be as as congested as that and also arbitrum one is still not at congestion yet so there's definitely room for it to increase the data posting rate right and of course there is think it's it's it's clear that that that even even with with 4 before like there will still be limited throughput so if there if if if if multiple l2s of course start reaching their own capacity limits and they all start posting very frequent badges um on on on mainnet so so I personally I'm less worried about say

per block kind of saturation because it's fine if if there's the occasional block that this fully filled by Abit and then there's the occasional block that's kind of filled by just a different one l two and then there's block blocks that that are split split up between multiple ones um and and with with the with the kind of the the the Bas fee kind of mechanism it's totally fine it could even be that like it's it's always 60 60 alternating or something that that that's perfectly fine so so there's no no kind of worry I think on the zoomed in per per block kind of kind of um composition um level um but of course once we reach over all the two usage levels where where the data needs become big higher than than the throughput we can provide with with with a target of

three um that that means that we we'll start to to just see kind of raise prices until until basically the demand levels which at that point of course we we are very actively working on on um improving the increasing the throughput that it's it's it's um just maybe add don't enough context in sure of how actively people have been following this um but so basically on one end of course we hopefully there's a little bit of Headroom we would have once once we see everything stable on Main net to go a little Beyond 36 um say in the in the next talk or something um but that that would probably be a relatively small increase and also like of course a onetime increase so it not really useful to to to to allow you all to scale much further but there's this very active

kind of research testing Direction um called pias where with there is that we will will go to actual um sampling techniques for making for basically checking checking for the availability for blobs um and that seems to be relatively far along so um I mean obviously I don't know it's always always problematic to talk about timelines but um uh let me put it this way I think if you all would would basically start to voice your make your voices heard that there's a a lot of urgency to getting this shipped as soon as possible I think that would really be helpful because a lot of the CL teams that would be the people implementing kind of this this um sampling technology they're looking

right now at what to do after danoun and what to focus on and if I don't think they have a big sense of urgency yet around this and so I think there's a world where this is becomes the next big proty and then there's a world where other things are maybe focused on First and I personally would really like if there was B some some sense of urgency created around the sampling technique because once we have once we move from from the current for perform mechanism of everyone still downloading all the plops to sampling then we could can really kind of scale I don't know I don't want to make promises and so maybe in the initial robot that would not be the case but relatively soon we could see something like a 10x to even more than that uh through but increase so so

yeah just like a little to-do if if you all can can try and just you know go to the CL team of your um convenience and just just talk with them about PS that that would be very helpful um Peter yeah just a question some rated to this topic that I'm curious about um so I think shortterm we probably won't exhaust all the throughput for for can offer but I think the conservative approach that we would probably take is to also retain the ability to to use call data so be able to commit to either blobs or call data I'm just curious how other people how their teams think about

it you just directly only use blobs or do you still kind of keep the C data logic of your F roll up yeah I can I can jump in from um the what we're thinking on the zking side so our contracts uh handle the ability to do both blobs and call data um the difficult part there is just because if we're filling a blob fully that basically uh is the same amount as the maximum uh Pub data that we could fit uh within call data so once we start uh utilizing two blobs um the system uh

falls apart a little but uh because of that when we first start testing we'll probably uh opt for doing a single blob so we can actively switch between the two but definitely something that we're looking into and want to have um a better plan for um when it gets closer to uh mayet or uh soon thereafter great yeah there's a similar thing um going on for arbitrum um the batch poster will right now the way it works is the batch poster will look at

the blob fee and base fee at time of posting and figure out which it should post with um but there's the problem of you can't replace by fee blobs um to a non- blob transaction and even if you could as as Zach mentioned the call data limit for The Gap uh non blob M Pool is much lower than the amount of data you can fit in blobs uh multiple blobs that is even one blob it's slightly lower but that's not a huge issue um but basically there's sort of this awkward situation where you can get stuck in blobs and if something happens where the blob Fe escalates well above the base fee uh comparatively per bite um there's not

it's it's a bit unclear there's there's definitely some ideas we have how to recover from such a scenario um but it with but it may just be that you have to pay for a couple of blob transactions to get out of it in the common case um and I don't have a great answer there to what should be done thanks Roberto yeah similar situation um with the op stack we've made it so you can post either call data or blobs and the change deration rules will will will will allow either um however the Bacher config supports either one or the other

you you either are always posting as call data or you're always posting as blobs um but you know that can be changed in the future once um we figure out some of the issues that were just mentioned around replacement rules and things like that sounds good and maybe just briefly mention how we' have been thinking about it from the the the the research side um of course I mean this is a concern it could be that if if all the L to start to only be able to to consume bubs then in principle the price could could could go higher on comparative per bite level um the nice thing is that as long as there's a few teams with reasonable throughput that are still compatible are still able to use both then they

basically will make sure that that that never happens right so like if you there's a bit of a pre rer situation where it's fine if 80% of the lay toos can only consume blobs because then on the margin that would always mean that that the the few that can would basically make sure that that they would always consume Coral data if it becomes cheaper ever than than the blob data and so would kind of keep keep the equivalence there um but of course that not should not that that should not mean that you as a team should should not um um um do that because the network profits like like benefits from at least a few teams being being able to to have that kind of compatibility with either uh either format um and of course while me know Bobs are not super

tested yet in production um at least for a while it's probably good to to be able to fall back to normal call data anyway uh okay uh anything further on the on the kind of pricing side and that that people would want to talk about okay then um one more topic that at least people touched upon um a little bit was expiry I'd be curious um so I think kind of on on in terms of the our

our um test net timings par already mentioned that the idea was to wait with main net kind of setting a minut at Target before we at least saw expiry blob expiry on the first test net meaning girly of course then by the time M it would for we would have already also seen it on on sayola um um and whatnot um to what extent our teams here kind of also specifically looking looking at testing around uh expiry I don't I don't even I'm not super familiar with within individual architecture of all the teams it could be that for most of you all that's not relevant at all because by that time

you've long copied the data over into your own network and no longer ring at anyway or something how how basically like how how how do teams think about expir that would be good to know if anyone thinks about exper at all Harry um yeah I guess to like one thing to say is certainly kind of one nice property is that at least for kind of for rollups basically we can support a uh a mode of syncing where basically you only need it where basically kind of you use the latest confirmed snapshot that kind of either you know when this

presumably is true for either ZK or optimistic rollups uh given that the blop expiry time is long enough that basically there will always be the blobs uh guaranteed to be available on the network between sort of the latest finalized checkpoint and the latest state which is nice I think there's like that assumes data availability of kind of whatever the latest confirmed uh no um whatever the latest confirmed state is which is certainly like a shift in security model from the current day since right now of course like if you can just sync from Genesis by just following ethereum and relying on kind of I mean obviously ethereum doesn't have formal security guarantees around ancient data availability but in

practice certainly that's kind of quite an easy assumption to make um there's certainly kind of some interest gray area now on kind of how like ancient blob data availability will work whether or not there's going to be kind of reliable service providers whether or not rollup teams are going to want to be expected to Archive their own blobs or kind of generally how that will work in practice Yeah yeah so we have a sort of a multipronged approach um one is um simply State sync um the other is

providing a blob archiv service um that you can use to persist your own blobs or or all blobs uh and in fact we're actually looking into sort of providing a um a coinbase instance of this that archives all blobs that people could use um obviously there's a trust assumption there um but it is one option um if you do need to sync from scratch and state sync for whatever reason isn't an option sounds good Lee yeah so I think this sort of touches on a point I've been thinking about more broadly which is I'm not sure how

available consensus layer rpcs will be in general um blobs are somewhat unique and that you need to Corry them from the consensus layer itself not the execution layer and you know popular RPC providers to my knowledge usually don't provide um consensus layer rpcs they only provide execution layer rpcs um so I think it's sort of an open question foret opin Labs um how this is going to work in practice if users aren't running their own nodes um if we're going to see more support from third party RPC providers for this kind of thing or uh if there will be some alternative service that offers the

same RPC um there isn't a huge trust assumption there luckily there's a trust assumption in terms of availability but there's not a trust assumption in terms of correctness because you can verify the blob proofs that it matches with the commitment but um that's sort of a yeah I don't have a great answer there yet um one point I do want to make for anyone looking into blog blob archiving in general uh blobs don't have the same issue with high iops requirements that state does which means if your CL client of choice does support it please dump the blobs on a hard drive and that

should reduce your cost by a massive order of magnitude yeah that's a good point and also I have heard the question around kind of um RPC access on on the SES side before um clearly data availability is is a new kind of concept that we're only now introducing um I would expect that in the long term as this result becomes more more important and and we start introducing further things like like DS and everything that that that there will be more broad kind of support and providers either same RPC providers as

today that also more more provide access to to to CL rpcs or on new ones um specialized on this popping up but that might not immediately happen um so so that I think that is an open question um I don't personally I'm not super involved with that world I I I don't know if there's RPC providers to to go talk to about this um but that seems like something that needs to be figured out indeed also in case you guys are running your own node and relying on your own

infrastructure for the beginning until RPC providers support the features cuz I think as of now most RPC providers are used to providing you an El RPC not a peon node RPC um we do we we've built this Beacon node uh load balance so so you can have a high avilability setup if you want it and we've been running it locally for a while and does quite well that's nice and yeah and just to mention of course um the the the the whole point of data availability and and kind of the expiry period is that in principle the idea is that the network

only wants to uh guarantee basically in avail in the flash of the moment um in a way the the expiry period is more convenience um feature because um because then it's it's easy for these short look backs to to just use a main net but in principle like every every layer to of course is its own chain and so um for say sinking all the way from from from Genesis or something like that that that is something where the ultimate responsibility for for kind of History availability and whatnot that that does lie on the um on the specific L2 P2P so it could easily be that say if if someone uses blobs for just inscriptions in the beginning and you

just put in Hello mom in there or something that that kind of blob over time just gets forgotten and is not persisted anywhere because it's just not relied upon by any party and that that would be just fine right so so basically if if you as a l to want to keep one blob around forever then it's kind of your responsibility to have some sort of persistence mechanism um to do so or just to hope that say I don't know some coin Bas run service will will forever persisted um okay uh so so so that's that topic um let me see if there was any other kind of topics that from kind of the the first section of the call to to touch upon um took some notes but I don't I don't

see anything right now so then maybe that's a good point to just open it up is there are there any kind of other topics either either problems people have already run into or just challenges things to to to to figure out or maybe just questions that that that came up that not very concrete yet that that people would want to bring up yeah Harry yeah Le less a question more just I guess like a a a thing to flag it's kind of overall development on kind of

preparedness for for 4844 has definitely been pretty tricky in that obviously kind of the overall L1 ecosystem has been sort of relatively heavily in flocks I mean there was just the big spec change even in in the in the core uh which I think was a great change but like was um pretty recently and like obviously like overall sort of support has been kind of picking up I mean and which makes sense um but kind of fundamentally sort of it puts it puts l2s in a position of like developing on top of kind of a pretty unstable base as kind of the overall kind of ecosystem is is sort of evolving

um and and it's it's kind of interesting because like it's it's none of and kind of you know I think that's to me I think that's kind of fundamental to kind of having the main having the main net hard fork and the actual kind of overall inteset hard Forks happen sort of like relatively um on top of sort of finalization of kind of the the you know various core implementations of sort of the necessary L1 infrastructure and kind of jumping immediately from essentially that stuff being done to rolling rolling it out which um generally works well and is fine although I think that like for rollups there's a bit of a a weird thing also which is that sort of like

obviously like there's a a huge incentive I think for everybody here to to support 4844 early um like if you know in a perfect world from my point of view like there'd be you know some number of months actually to you know actually have 4844 live before it start started getting heavily used just because um you know it could actually stabilize tooling could catch up and all of that but of course there's a pretty huge incentive for all rollups to support it early since I don't think anybody wants to be the rollup that's not supporting 4844 and uh their users are all paying much higher fees and so it creates a sort of just like weird situation

yeah yeah that's that that's actually a really good point actually um Proto brought from from from the optimism kind of um brought up kind of similar uh concerns um on the uh on last oh sorry on the last alfs um as well um I mean it's it's it's a bit tricky I don't think mayet of course can really kind of wants to actively kind of take these concerns into into consideration I think basically delaying roll out to alleviate this competitive pressure to to maybe be a bit reckless in in speed or like basically have to go

through a lot of extra hassle um of of of of of support I I totally understand that point but I don't I don't think that's something that may would would necessarily ever ever do so I basically given that that that route is probably not realistic for future changes like this um I do wonder whether maybe the next best thing we could do is to just try and have a forum like this right like the the roll call kind of to be a bit more bir directional with with aloda so right now I mean even this call that's the very tail end of of of the development cycle for 444 and this is even more of a hey now that it's done and set in stone we we here to maybe like just coordinate a little bit on how how you all are dealing with this I

could totally see that in the future like for example one question I have is maybe it would be useful to have a call like this in a month or two where we bring in the the people working on the data availability sampling specs and kind of check in and see I mean the nice thing of course with dat availability sampling is that actually the interface will be unchanged so so there's not much that actually will probably change but still maybe some trust assumptions some some sort of act actual kind of practical kind things might might still change and so instead of just waiting and then telling you all when it's or having this call only to clean up in the endend actually have have this be a bit more of a proactive um thing where now that we have the roll call and and and ler to is

involved that we can actually inform the processes it's it's it's as it's ongoing and and as it kind of before it it finalizes uh future changes I think that would actually be be really a step in the it seems like a step in the right direction and probably the best the best we can do here I don't know if anyone else yeah like if there like what are some concrete things that you guys are running into that is making you have this feeling because I mean there are like specific things that we could be working on or like collaborating on to make sure is a little bit more stable I think it's possible to do that I know like for example the rpcs you know we've been asking for a couple months what you know

how do people want to interact with blobs over the RPC you know um getting the blob Bas fee getting the estimate gas and there's been like you know no interaction from l2s and so I don't know if yeah I'm just like what exactly are you guys seeing that's making you feel like things are moving underneath you oh yeah I mean and and to be clear by the way I'm not really advocating for any particular uh specific change um other than just kind of flagging the general sort of uh the general Vibe almost um but you know to be concrete and I think that like we had done kind of an early wave of for four4 development

um quite a while ago like four months ago maybe which is kind of would have been ideal from like my perspective if we had been able to sort of you know had a number of you know a good number of months in advance of sort of stabilized uh libraries at at the time um I think there were a bunch of there was a bunch of weird stuff going on with the kcg implementations if I remember correctly and kind of a whole lot of sort of um kind of instability in terms of in terms of like well I mean I think that was before the most recent large spec change um yeah so I could come back when was the large spec change or what what was the large spec change you're referring to um The Blob sidecar change um when was that um we had one change in

November I think yeah November that was a consensus level change as far as I know yeah exactly was that the side car yeah um which I think was a great change and so I'm happy it was done but um certainly just as an example of kind of the degree to which things have been you know pretty core things have been in flux relatively recently yeah I mean I don't know I mean I guess I just don't really quite follow follow what like the inter to me the interface between the consensus protocol

and using blobs is kind of a fixed thing I don't really see why the side car specifically you know I don't really see like why underly changes of like the PTP would be affecting rollups ability to integrate the um the proposal oh I'm just talking about in terms of overall stability of the dependencies um yeah I mean yeah yeah don't don't know if I quite follow because it's like the you know we're trying to ship the thing and things are going to be changing underneath but you know the only thing we can really provide and make the

guarantee on is the interface and I feel like the interface has been pretty standard and clear for you know quite a while for people to test on I mean I'm not like trying to call you out or anything I'm just like yeah I want to make it better for the next fork and I agree like with onar like I don't think that we can make like a commitment necessarily to have like a very long period once things are like stable and ready to go to main net to let everybody implement but what we can do is we can try and communicate better early on and make sure the interfaces are correct so that even if the underlying thing is changing the interface that you're using to put blobs in verify blobs all that stuff stays the

same yeah it's possible we um misidentified where the issue was coming from we submit transactions using go ethereum's um using go ethereum's transaction Library um I think or I I believe at least that there were significant changes in the API of creating a transa of a creating a blob transaction with sidecars and submitting it um but it's possible that we've misidentified that and that just came from the Go ethereum version that said I think we did have issues with incompatibilities between the Go ethereum version we were using to try to submit the blobs in the Go ethereum version that was receiving the blob transaction so ah okay sorry you're talking about the side cars that was

added into go ethereum I'm not sure I think there's two separate changes here there's the there's the yeah there's the consensus change in November and then I think the blob transaction in version 1.13.0 and go ethereum was reformatted a bit um yeah definitely I mean we there's definitely been changes to those types of things and I mean this is something that we can do better at but like frankly there's no communication from like Upstream users of this stuff yet which is like the thing that's causing us to not like this is why we don't have Dev mode ready for Cancun because this is the first time that we're hearing that people are like we need this for Cancun you know yeah definitely I think

it's sort of a catch22 because we were trying to developed this stuff into November in November and or yeah I don't know exactly when but as Harry mentioned a few months ago and we were running into a significant number of incompatibilities between various you know go theum prism versions and um issues where apis weren't ready but um we can definitely try to communicate better those concerns um at the time that we have them and yeah yeah I think getting a better commun getting more communication and sorry definitely not didn't mean to you know I think to me like a lot of this is just kind of relatively fundamental to sort of trying to kind of develop the underlying Tech

simultaneously with trying to like develop Tech running on top of it is just a really hard problem so yeah I mean I don't I don't don't don't take me the wrong way I don't want to sound like I'm putting you guys on blast because what you're doing is extremely difficult because like you we got 10 developers building this go ethereum library and we just change it like every month because we don't know how people are using it who's using it and it's a really hard thing for you guys to deal with but I think the best thing that could be done on your end is to to you know just communicate with us when you are using things or like having problems with using things I get it's more work for you but I think that that would let us do some stuff earlier on if you guys

drop an issue and you're like Hey we're using this library and there's this in capability and like hopefully with that communication we can get to the point that we're getting to like today three months ago in terms of interfaces sounds great absolutely yeah I think in general sort of setting up better communication Pathways is probably one really good uh you know out you know takeaway from from all of this uh like in that I don't I think it'll still be pretty hard to kind of pull off this sort of thing of developing kind of concurrently you know multiple levels but like it's certainly you know to the degree that it's a shared problem that everybody faces and definitely we can't you know completely you know make everything perfect but we could

certainly like you know I think get things a lot better than they are today at least yeah and in the future we could of course also have have had a call like this where we specifically say also have forg people like like I mean just the the general the El people the say the solid like the the program language people and what not and and the lus already couple months before before it's ready for mayet and and kind of talk about what what remaining changes there might be what what people are to rely upon all these kind of things um so yeah I think there's definitely a lot to improve for for future changes but by the way just uh I I mean I I could be off here I don't know how much is kind of specific to our development process Al I'm assuming kind of based on the

fact that it seems as though sort of everybody is in a relatively similar position that we are of kind of kind of getting you know getting getting closer to you know being ready but not sort of being you know but not having you know only only kind of getting there now as opposed to getting there sort of weeks ago that there's a relatively similar paino being felt although I could be off there yeah I think one thing we did during the merge that worked out well was merge Community calls um we had like a couple of them spaced out throughout the year while we were doing the dev process and we could give a easier update as to what the current status was

point to latest documentation on how to use stuff ET and very often we just point to whatever we were using for testing and maybe that would have been a smart idea to do for 4844 as well cuz like you mentioned uh targeting the right go ethereum library or using the right interface Etc that's stuff we've kind of kept up to date with and we had to CU otherwise you wouldn't have any load on or testing on the dev Nets um and I guess if we had had those calls we could have just showcased hey we're using this script we're using this Library use it as a jump off point and tell us what you want us to change should definitely bring that back next time okay yeah that's probably those

those those were all good points on kind of on on that the future of that kind action um and definitely something to follow up on for for any future kind of changes that that might affect their to which probably most of them will in the future and yeah other than that um there's one more topic I I really wanted to touch upon that was most basically just like girly versus sepolia in terms of who's what's going to be mostly target for for for testing but but um yeah I mean okay let's maybe just brief to that so so of course people have already kind of talked about the little uh which which Networks targeting it's sounded like basically it's for now it's mostly function of how ready you

are like the teams that are already ready are of course using girly now because that's the only thing that's already over and sounded like teams that um needed a few more weeks anyway but then going to Target suia mostly out of the gates um of course given that girly will will be sunset kind of soon after um tenun it seems like s in the long run will will will be the more important Network in general I just wanted to briefly check in with um so I think the two teams that already actively kind of targeting girly were um op the op stack kind of chains and and and and and Earth chain Labs um are you

you all also kind of planning to to focus more on suia once once that's life or what's how do you think is ke between those two chains yeah I think for our test net we'll definitely be doing um sepolia as well um but right now our Dev net is only at least the super chain devet is only active on GAR okay that makes sense and on the on the of lap side I think that I'm not sure we I don't think we have a fixed plan for future Dev Nets and test Nets just yet

um we definitely prefer sapoia in general due to you know the availability of eth continued support and such um I think the the plan would be if we do any future Dev Nets um by the time SPO is upgraded they would definitely be on seia I think at some point of course the um arbit Gil and arbitrum sapoia test Nets will also be updates for 4844 um I don't have an I don't have an exact sense of timeline there yet though okay sounds good yeah I just wanted to check but it sounds like there's no one specifically on this call that's like no for for for for for we're just not at all ready to to focus on spolia and we would really for us girly

is the the main Network so that that seems healthy um okay um is there any we kind of a bit over an hour into the call anyway we would have like a good 21 minutes or so if we want to um is there any any more topics that people have that that we should talk about or is it yeah what what was the estimate gas issue that someone had mentioned I missed the details on that I don't think we've hit that so um I think just that unless another one was mentioned I think just that the blob version hash field or blob version hashes field of estimate gas was not um added to at least go ethereum probably

other execution layers as well until very recently so there was no way to estimate the amount of gas that a blob carrying transaction would take got it which I think has now been resolved in the latest version which is awesome oh was there a new version released few hours ago oh nice thanks okay well it looks looks like some

people are starting to have to leave leave anyway um I guess that that's a good stopping point then um I and I hope this was this was useful for for you all um it definitely was very informative for me kind of raising a lot of these kind of issues and whatnot um yeah and hopefully we can have um things like that in the future as well uh I think there will be several different kinds of of breakout calls I hope some like this we can we can do in the future as well with with with future changes and maybe even as as I was saying earlier a little bit more proactively not just once they're about to hit mainnet um and then we will also have other types of breakout again we're just experimenting a little bit with this breakout call so

next week there will be a breakout on uh just Fe fee markets for for layer tws um that will probably be a bit more just brainstorming exploring kind of figuring out how to how teams think about this so if anyone on this call is also interested in that feel free of course to to join again for for that and then I think on the next draw call in three weeks we'll basically have a bit of a retrospective of like which types of breakouts work and which ones to maybe continue um how frequently to have them and everything but but I I don't know I'm I'm very pleasantly surprised with how how well this this one went and so um thanks you thanks so much everyone for for showing up and actually contributing and and making this making this a useful use of time so thanks

everyone and thanks for having us see you thanks thank you