All Core Devs - Execution #204

Transcript

Okay. Uh, well, oh,

Tim Beiko: are we good? Okay, awesome. Uh, welcome everyone to ACDE number 204. Um, we have a fairly packed agenda today. So, um, first off, uh, we can discuss what happened, uh, on DevNet 5, where we're at there. I know there were a couple bugs that came up, and then, uh, plans for DevNet 6 related for that, related to that. Sorry. Um, I believe, uh, people want to revisit the, uh, work slots that we had proposed a couple weeks ago. I think uh it'd be good to align on a schedule based on where client teams are at, what they

expect to be done and when uh they expect to have releases. Um and then uh there was a conversation as well on the chat this week around how long we want to wait uh after picking these test net slots to pick a mainet slot. Um and then two uh other things on Petra. So one, we have many of the auditors here who um who reviewed the system contracts for the fork. So we'll be going over uh the audit reports. Um and then um I think there was also a point around the system contract addresses that we need to clarify. So figuring out what the final set of addresses will be for the test net and mainet um and then starting to look forward a bit. Uh so there's this

spectra retrospective thread uh that I wanted to follow up on. Um start to look at some stuff for the next fork and then there were uh two specific EIPs if we have time that people wanted to bring up. Um, so I guess to get us started, uh, do we have someone from Panda Ops to give an update on the death nets? Yep. Can give an update. Thanks. So the first good news is um, DevNet 5 is finalizing again after all the bug fixes from last week. Uh, thanks to all the client teams working on that. Um the bad news is um we have tried to run the execution spec tests again yesterday and uh Nethermind has a consensus bug and

basically split out at specific spark. Um the Netherite team is aware they are fixing it. Um do they want to say anything to that?

Marek Moraczyński: Yes, it is fixed right now. Uh so that's the most important update. Uh it was like uh optimization combined with BLS pre-ompile that caused this issue. Uh yeah um I I think Netherm was stable for months and break last night on Devet but yeah it is generally fixed so I I think it shouldn't be any blocker for DevNet 6 for sure and for Hleski as well.

Cool. uh can you send me the um branch then I can deploy the images? Yeah, so I'm running this image for already on some uh notes but uh it would be good to update a few notes all notes as well. So let me send you

Ahmad Bitar: I already shared the image name on the telegram group. All right, thanks. Um the next thing is um we have the Defnet 6 Hive app. Um please uh also send branches to that so we can update um the image uh the clients that are executed so we can have the latest uh results.

Um we'll launch um definite 6 um as soon as most of the clients pass these tests. Um Mario will also release an ES EST release. Um yeah, but we already have an early version to test on Hive, so please send in images.

Um Mariel,

yeah, one one thing worth mentioning is that uh there's a PR currently open in the EIP repo, one for each of the uh system contracts, and that's just to update the addresses to the late last uh update that's going to happen before uh Brag launches. So I think we should get those merged and then uh yeah please

review. So then we can just uh proceed and update yields and then we can proceed and update east and then we can deck. Um it should be fairly quickly. Uh but yeah just just a heads up that the addresses are going to change in 106 if these EIPRs go in.

Tim Beiko: Got it. Do you want to share the PRs in the chat when you have a chance? Um these and these latest addresses are like the nice ones with the number of the EIP at the end. Correct.

Exactly. Yeah. Yeah. PK PK open those uh those PRs and these are the addresses that we are going to probably potentially going to use for for mainet.

Yep. Cool. I think you're going to talk about that later on too.

Tim Beiko: So I mean yeah. Do you want to cover it now if we're chatting about it? It's not a huge uh topic. Yeah. Uh let me finish the update first. Um the last thing I want uh to mention is uh I should remind the clients of the um block fee update in the Genesis for Def 6. So that's the last update. Okay. Um so um regarding the def uh the contract addresses um we have generated a set of nicer looking addresses starting with zero bytes and basically having the EIP number at as suffix for the contract. It's now quite late in the

uh release cycle as we plan to have releases on next Monday but um I guess it's a oneline change hopefully for most clients. Um, we have update we have opened PRs for them. So, yeah, it's basically up to decide if we want to use the nicer looking addresses or if we stay on the not so nice ones. I think given they're going to stay on chain forever, it's worth doing the change. Um and it is it is kind of a nice uh pattern if we can use it going forward for system contracts to have like leading zeros then uh yeah zeros at the end and the EIP number

is does is there anyone for whom this would be like significant change or they think that it would delay Yeah, let's just do it quickly. So, I guess let's maybe leave the PR up today and then merge it tomorrow morning. Or do people want to merge it even quicker than that? It would be nice to have someone sanity check it, but Okay, I'm hearing merge now.

Anyone oppos? Anyone opposed to merging it? Okay, let's uh get it merged in. And yeah, Mario has a comment in the chat which is that like it's nice for smart contract writers to know that they're calling the right thing by looking at the EIP number. Um so I agree this is like a a neat feature. Um, we should have thought about this a couple forks ago, but second best is today. Um, anything else on the DevNet? I think that's it for now.

Yeah. And so And so to be clear, DevNet 6 would then include all of these new addresses, correct? Yes. Perfect. okay. So uh last call or two calls ago we had tentatively agreed to some uh fork slots on test nets. Uh we were aiming to uh forks on uh February 12th and then Sepia the week after on the 19th. Um and this meant having releases out by February 3rd. Uh so meaning uh this Monday or this coming Monday. uh we do not have them at six yet and I know there were

some concerns in the chat about uh hitting the state. Uh I guess I want to open up the conversation of one like you know should we pick a new time today and if not when should we pick it? I think um it's worse to pick a date and then not hit it than it is to just not pick a date if people are not ready. Um so yeah, open up the floor to this.

um parents,

Terence Tsao: does it make sense to pick a date like after death 6 just to see how things went? Because obviously there are like a lot more issues than we expected for death 5, right? And those are actually consensus issues, they're quite serious

and even if you look at Dora today, the participation for death 5 is still not 100%. So I don't know. Do you think it's slightly premature to pick testnet dates right now?

Tim Beiko: Yeah, I'm fine. I would rather wait if we're not confident than pick one that we have to change. Um, and then there's comments in the chat as well about the GU issue. So I don't know, Marius, do you want to talk a bit about that and if it affects the get timelines?

Marius van der Wijden: Um yeah, I can talk about that. Um I can't really like doesn't really impact the timeline too much. I cannot really um I cannot really talk about the timeline because I was uh uh on sick leaf. Um but uh yeah, we had a pretty bad issue today or we fixed a pretty bad issue today. We made a release. Um it's a bug in the P2P that also affects some of the L2s. Um but the L2s have been um

have been notified and they most of them have already put out a release uh themselves. And yeah, just a general if if you're running a guess, um you should either downgrade to one to like a 113 release or upgrade to the latest release. Um because uh with the 114 release cycle, we introduced a bug. And um yeah, but as always we we uh we we would prefer if you updated it to the newest release um or yeah, if you don't want to update and don't update if you are if you're

running a version below one uh 114. Oh uh oh yeah downgrading is not possible because we changed the database version.

Tim Beiko: Okay. So, if you're running 114, you should upgrade. If you're not yet running 114, you should either keep your old version or upgrade to um the latest release.

And uh if I may ask a question, uh if this bug is triggered, what what would happen like what is the worst case scenario?

Um the

Marius van der Wijden: you can shut down nodes um like a pier can shut down the node that they're connecting with.

Tim Beiko: Okay. So um I guess any question on any more questions on get before we go back to the test net? Uh okay then um on the hki yeah timing. So um

would the rough plan then be get Devet 6 launched which we can hopefully do uh in the next few days. Uh ideally you know if not by the Monday testing call then shortly after that assuming this works then we feel confident to pick the the test net fork blocks. Um, so I guess realistically this would mean picking them on um on next week's AC/DC. And then if if that would you know if that went well um would people be ready to put out a release days after AC/DC basically so that um if we say pick the blocks on the 6th uh which is next week then by the 10th we have all the client

releases and we can make an announcement on the 10th or 11th. Is this something that's uh that people feel is possible? Um yeah. Uh Justin,

so a point on that. Um we haven't had a great track record with making ACDE decisions on the AC/DC call. So I am all for it. I actually think that's a great idea, but I think we should all commit to showing up and not put the AC/DC call in a situation where they can't make a decision and they're waiting on us. that that has happened in the past and I think that we can um try to make sure that everybody shows up there.

Yeah,

Tim Beiko: good call. So, if we make the decision next week and your client is not there, uh we will ship the release and we'll have a TBD for your client's release in the blog post. Um yeah, and if you can't make the call for whatever reason, then just post a comment on the agenda with like your, you know, opinion if it's uh yeah, if it's wrong. But my hope would be that in the next week we get DevNet 6 sorted. Um if it if there's some issue we find on deet 6 that we hadn't found before, obviously we should address and fix that. Um so I don't want to like um assume that everything will go well. But um if it does then by next week we should be able to find uh uh a fork slot um and then we um yeah and

then we pick it there. But my hope is that we could have fast turnarounds for the releases um after next week's call. So team should expect to put out a release next like Friday or Monday or the Monday after that. Does that seem reasonable? Okay, no objections. Um and I do think in general it would be good to have some representation from most teams on most calls. I know that it goes from like a call every two week to a call every week. Um, but it's true that it is kind of annoying when you have to wait two weeks instead of one to make a decision.

So, um, I don't think it happens super often, but as especially when we get close to shipping the fork, um, if yeah, it saves us a week, then we definitely should, um, yeah, we definitely should have people on both calls. so Sumat, I'm not sure I understand your question.

Sorry, Tim. Uh, just wanted to make sure that DevNet 6 was up and running and uh, completely stable before taking a call on uh, making.

Tim Beiko: Yes. And I'm saying, can we do this by next Thursday? Ideally, we can get it up in the next few days and then by Thursday it would be stable. Is this realistic or do people have a strong concern with that?

Marius van der Wijden: Could you please clarify whether it uh moves the uh test net timestamps like provided devot 6 is stable will we still uh might commit to the same time stamps or

Tim Beiko: I would push them back. So yeah, so if we if we forked next week or sorry if we

chose the time stamps next week, I would push it back a week. Uh so my my proposal would be February 19th for Hleski and then uh February 25 for Sepia. Uh I have some time stamps in the agenda that are like uh good times and that meet all the the epoch boundary criteria. Um But like, yeah, but I'd rather not commit to those today. But I think if we if everything goes well in the next week, then I think pushing back the timeline we had by a week uh would be my proposal.

Marius van der Wijden: And to to clarify one more time, we're given these two weeks uh between we commit to uh timestamps and potentially immediately do the release uh to actual test net uh fork timestamps to to give the ability for all of the people to upgrade.

Correct. Is

Marius van der Wijden: is two weeks a long time or so

Tim Beiko: so in practice it's going to be closer to like 10 days or a week or something. So if we have you know the say the last client release comes out on like the 10th or and then we have the blog post on like 10th or the 11th

whatever then um the first work is on the 19th so it's like a bit under a week. Historically that's what we've done for test nets and then for mainet we tried to had have a bit more uh delay because um yeah because we obviously want like all the mainet operators to to upgrade and it's it's it's worse if we we don't have test nets but I wouldn't feel super comfortable doing like a week or less unless there was a like a strong reason to do so. Um and I and I do think so. Yeah. So and

one last thing is like I think it's kind of nice if this test nets fork before a core devs on those weeks. So like you know if we have the blog post out say on the 11th um there's a core devs on the 13th. I don't think we'd want to do like a one day heads up before the fork, but then um I think it's quite important to have the test net fork before the awkward devs of the week after that so that we can actually see it fork and then you know make any adjustments um on the call. Um yeah and then and and the reason I guess um the I think the reason as well is if we uh we probably do want a week between the two test nets because if something

goes wrong with Hleski and we want to say have a fix for then we can kind of do an emergency release between the two. Um so I wouldn't do like Hleski and Seapoleia quicker than this. Um um I guess I don't know maybe like a yeah related topic to this is how long did people feel we should have between the test nets being set or forked and then picking the mainet slot. So there was conversations on this as well on the

discord. Um my sense from the discord is people wanted to see hleski fork before picking a mainet slot. So would assuming the Hleski fork went well, would people want to pick the mainet slot on like the awkward devs after Hleski even if Sipolia had not forked so that we can give people um something like 3 weeks or so of heads up. So I guess yeah, anyone opposed to picking mainet after we see one test network if the test net goes well so

that we give can give people a bit more of a heads up. Okay, so the plan would be to summarize all of this um in the next week get DevNet 6 up and running and stable. Assuming it's stable by next awari and sepoleia slots on that call teams are expected to make a release on uh on the 6th, 7th or 10th. you know on the 10th or the 11th we have an announcement go out assuming we followed that timeline we'd aim to fork uh Hleski on the week of the 19th on that week's

awkward dev so on the 20th we would pick the mainet fork time and then on the week of the 24th we would see fork and assuming forks and doesn't have any issues then we can start having client releases out and potentially announce uh you know have the fork announcement go out um on like the 27th or 28th if there aren't any issues and ideally give people uh a few weeks after that to upgrade. So um yeah, that would give us that would get us somewhere around like mid-March or something for for mainet assuming we had no um yeah, no delays.

Any objections to this? Okay. So, I think we can revisit this uh next week, but uh so prime teams just please uh get the hive test passing. Um let's try to get the six working and uh we can agree on the fork slots uh next week. Um, and then one last thing to would it not be useful to have a preliminary timeline by next week's awkward deaths? I mean, I guess what more do you want in terms of preliminary timeline than I can like I can look at some mainet possible mainet for slots for next

week's devs as well if people find that helpful. I do like this can backfire though because um sometimes I'll say like this is the tentative mainet block fork block and then uh it will be tweeted and people will just assume it's that and they'll be disappointed if it's not. So I yeah I I don't I don't have a strong opinion there but there is kind of a downside of like having it tentative. Um yeah, I know we can discuss that I think. Um so we had several people do audits of the system contracts. Um Frederick can give a quick overview of like the entire process and we have a

few of the auditors on as well that can share um that can share their findings. Um Frederick.

Yeah. So we did audits like uh Tim was mentioning we had um four different auditing firms looking at this uh blackthorn da plane shift and sigma prime and uh they did the audits sequentially. So we started with black thorn and uh after that one was completed and we had implemented whatever fixes that we felt was uh important to implement uh we went went forward with the next ones. So this

was done during the whole process. Um so that means that the uh the findings are are different um given that they looked at different code bases and um or different commits rather. And at the same time we also had uh Dej from A6 andZ who did for verification on the uh these contracts uh using HOS. we have all the u reports available publicly in a GitHub repo

that I shared now. uh if you look there you can find all the reports and um we have at least some of the I hope all of them but we'll see uh auditors to give a very brief presentation about their report. I'm thinking like one to two minutes per uh per auditor and uh yeah I'm thinking that we we start in the order that uh the uh the audits were done. So is there anyone from Blackthornne who is here?

Yep. Yep. Frederick. Hey. Cool. Yeah,

I think that we can start uh just quickly quick intro from our side. I'm Artsy from Sherlock and Blackthorn. We also have Vagner here who will go through uh know our findings. I think we were one of the first uh audits on the system contract and the Blackthorn is kind of like ours and different brand uh from Sherlock and yeah I'll let Wagner to quickly go through the all the issues and the findings that we had.

Yeah, thank you Arti. Um so we conducted an audit with four auditors for uh the geese implementation of um especially the IP 7002 and 7251 um because of the experience needed you know was the things were pretty specialized so we needed to find people with low-level coding experience and people who can audit um specification implementation especially so in our report we had two low severity findings. The first one would be a semantic finding which is more like a recommendation uh basically to update the counter semantic that will optimize the guest

usage when it comes to consolidation and withdrawals. um which as I said it was more like a recommendation but considering the fact that uh the current gas semantics will not always hold true you know and about the fact that the complexity of the contracts could change this is not uh something that uh is expected to to be purposed in the future and another issue the second low severity issue that was found was regarding an overflow that could happen in the fake expo that could lead to a mismatch when it comes to specification implementation But again this is more spec specifically to the EIP's Python specification and an important note that like the reason that uh why it was a low severity finding is

that in the current setup in the current settings it is pretty much impossible to reach that value but in the possible you know in the future assuming you know heavy scalability especially it could be um possible for uh the excess to be bigger than uh 2,892 too. So because of the fact that in current settings it is impossible. It it's again it is a low severity issue. Uh but it's important to keep that in mind also for future references. Uh so yeah that was uh basically the two findings and the report from uh Blackthorn.

Thank you very much. Um do we have anyone from Dub here?

Sifis Lagouvardos: Yes I'm here. Uh so should I like made a small presentation. Should I say or do you think it will delay the thing?

Tim Beiko: Go ahead if you can. Yeah. Go through it fairly quickly. But yeah, I think you can share and then maybe put the slides in the chat after.

Yeah.

Sifis Lagouvardos: Okay. Yes. One second. Can you see my screen?

Tim Beiko: Yes. Yes.

Sifis Lagouvardos: Okay, so I'm S. I worked on this along with my co-orker Tony Valenton who's also on the call. We did the three system contracts. Now I'll speak briefly about the methodology we we used. So the two of us audited the contracts for two weeks and because it was a really low-level uh code audit we looked at the code at different ab abstraction levels beat the G source the EVM bite code directly uh the recovered the decompile source by our decompiler and the three address code of our binary lifter as well and along with the report we have some annotated control graph and

decompilation outputs uh which you can find. So uh for the EIP 2935 was the simplest of the three. So I'll not mention much. We only found a discrepancy between spec and implementation regarding the ring buffer size which has been addressed. Uh now the other two EIPs are more important and they share a common architecture of the message Q and yeah and and so the basically messages are added requests are added to the end of the queue and uh

once that it's blocked uh the system call is performed to remove some of these requests. and a request fee is um is required in order to add a new request and that request fee is based on the number of excess requests. Now uh I I will go over some of these things because we have a little time but basically we identified three set issues and the one the most important one was a medium severity the narrow sales vulnerability and uh three advisory issues which I'll not mention you can go through the report to to look at them

and the impact of this do is not huge it's it's basically a lot of convenience if this is to uh to happen and uh but yeah it will be expensive to perform and the overview is that because the fee is updated once for every block. uh if you take it at an extreme a user can fill a whole block with hundreds of requests or even over a thousand that uh ideal conditions and cause up to a few hours of downtime.

And we believe this can be mitigated by uh changing the code to update the number of excess requests uh at every new when every new request is added instead of once per block. And yeah, at most we found that for example one can fit uh 1650 requests in a single block for EIP 7251 and 1900 requests for EIP702. And for example, if you started at a reason at a favorable place uh and you start from a low fee, you can make the uh validator consolidation

requests for AP7251 cost over one E for uh 288 minutes. And these are the optimal uh conditions for this attack as we as we found them. We didn't uh extensively we don't have an extensive report for this and uh but it's a complex attack. requires it relies on many factors that will not be uh controllable by any attacker and these factors can be the gas price, the current number of excess requests and the contents of the storage slots that will be written and yeah due to and the EIP7251 contract is more uh vulnerable

because of uh its lower throughput. So basically this we also have some user level considerations which you can find at the report but I don't want to take uh up more time. Thank you.

Tim Beiko: Thank you.

Thank you. Uh do we have anyone from plane shift who's here?

Yeah. Yeah. Um I'm Sria. I'm part of plan shift. Um so during our audit we noticed fairly trivial issues um you know mainly regarding minor spec deviations as listed in the report. So like things like you know how like the IP states to return zero in some cases whereas the um implementation reverts um

other deviations from the spec like length checks for um call data inputs to the uh system contracts which we found to uh not have any um exploitable scenarios. Um, we did find multiple issues regarding the comments which were a bit confusing and um, we briefly used Helmos, but I would leave it up to the uh, A6NZ team to go over their dedicated formal verification report.

Yeah, thank you. And uh, yeah, like Tim mentions that yeah, the audits were sequential. So we do indeed uh it was expected that there would be fewer and fewer uh issues

found. Uh so obviously the fact that if someone doesn't find anything doesn't mean that they have they were have an inability to find uh the same issues. The the same issues just might not have existed in the uh commit that they were looking at. Um yeah, Sigma Prime is next. If uh anyone can see my primary.

Richard Meissner: Yes. Hello. Um I'll also quickly share a screen if I can.

okay. So uh quite a lot of what we found has already been discussed and covered. So I won't I won't uh repeat and go over it again. The main topic we found was the thing that that the DDA people were talking about and we got similar sorts of numbers here. Um a talk briefly about some of the possible impacts. It could be done intentionally to um avoid fees if you did have a large number of validator consolidations or withdrawal requests. Um if that's a concern, possible storage bloke. We we asked you what were your concerns? what were your reasons for having a fee? And you said, you know, concerns about storage bloss.

And I suppose that's if you have no fee at all, but there's still could be some storage bloat by having lots of extra um requests written into the storage space. Um and then yes, as DAP was talking about the the um sudden spike in fees, it it would shoot right up instead of curving up. And I think I think I think he skipped this. It looked to me like he had this, but in the EIP, it does talk about fetching the fee. Um, and then like you could have a smart contract that fetches the fee from the contract. Um, this is 7 uh 002 and and 7251. Um, both of those. So you could fetch the fee from the contract and then automatically send that fee. And obviously you could have that request in

the meool thinking you're going to spend a very small fee and then end up sending like more than an ETH um to to make a withdrawal request. So that's um that's that point. And then other smaller findings, one thing the um the block uh block hash um contract that's 20 uh what's the number? 2935 um is payable um which may or may not be a concern to you. In Solidity terms, it would uh Solidity would put things in to check the call value. Um it's not very natural obviously to request a block hash and send lots of lots of ether in that request but it can be done and with

an ether with a solidity contract that would be blocked. So maybe you want to check the core value at the start and block that um and then dab talked about this as well. the um this is the same point really to dis we also investigated the fake expo and found that it starts to overflow at 28.93 and we we did a little test and we didn't find the numbers got sort of suddenly dipped and uh we went up to 10,000 an numerator of 10,000 but it is possible that this value beyond that might suddenly dip and there's a test in the report to check that further if you want to do that um I won't go through this inconsistencies with EIP. Um, one little oddity, probably an irrelevant

edge case is that in a genesis block, um, some of the some of the behavior is is not as expected. Leave that to the report. Um, and then also, as has been mentioned, lots of comment um comment comments comments about the comments, possible minor um um uh uh optimization. And yes, that's uh that's everything for me. Thank you.

Thank you, Richard.

Do we have uh Dejan here as well?

Daejun Park: Yeah. Um I let me share my screen quickly. Um can you see my screen? Awesome. Um uh hey I'm Dejun from Crypto. Um one second just quick disclaimer that uh my comments are not uh business or technical device. Um so I'm working on uh methods at ACC crypto.

Um previously I was at the runtime verification and I'm worked on some bunch of the formal verification work early days and right now I'm working on um the HMOS uh for more verification tool um and I used HMOS for this verification um so let me clarify the scope of this verification um to set the correct expectation uh that um what I focus on is that the bite code uh behaves as uh specified in the EIP documents and I uh uh I mean this is because that the um the assembly programmings are really uh challenging

and many things go wrong. Um so wanted to make sure that nothing happened there. Um I did not verify or reason about anything about the EIP spec design itself. Uh like all the dos vectors or any numerical analysis that discussed before. Um there's a clear separation um on this. So essentially I focus on the low level. Um there's also some caveats in that bite code verification that uh so the highos I'm using is based on the uh bounded symbolic execution. So there are two types of bounds. One is the loop bounds which meaning that how many loop iterations are considered. So right now

it's set to the 16 which is uh sufficient for most parts of the contracts uh uh except that the uh the loops uh in the fake exponential uh which can go to like hundreds or even thousands in principle. Um so if anything issue uh that appears in the higher uh iteration for example this overflow more than 2000s uh uh uh will be missed uh with the current setting. Uh of course we can increase this bounds uh right now it but but but it will take longer. Um so right now it took uh 10 minutes in my laptop with this uh 16 bound. Um so you can run an increase but I think that uh I'm not positive that if

you can increase more than thousands um you know you know not really practically feasible. Um there's another types of bounds uh which is the call data sizes. Um so you need to specify uh what sizes of that and whatever is not specified will not be considered. So but with that caveats um uh the result is that uh all the verification passed. Um so we have a really high confidence that uh the uh bite code really matched with the spec and this is also the automated so you can actually rerun anytime uh the contracts updated. Uh so actually I set

up this continuous verification actually uh since last November and actually it found some actual issues uh some mistakes uh uh during the uh past uh refactoring change uh which is im immediately fixed. So I think this uh continuous verification is really uh uh useful uh and I hope that the other projects also adopt this idea. Um so yeah I I will keep running this uh contin uh the maintain these artifacts uh until uh this will be finally uh deployed. Um and good thing about it is that like this all the audio reports actually uh uh based on slightly older version of the contracts uh and there

are some minor changes made since then. Uh of course there are minor still uh wanted wanted to make sure that uh nothing happened. So the my verification is actually run on top of the latest version and that it all passed. So meaning that uh all the minor changes really uh didn't break anything. Um so hoping that I can continue this uh all the artifacts available uh in this link repository. So please check out uh you can review or run by yourselves or even uh contribute. So uh and uh reach out to me if any question. Uh so yeah that's all from me.

Yeah. Yeah. Thank you. Thank you very much. And um a very big thank you to all the auditors that took part of this and uh were very flexible with their timelines. We know that we were a bit late and uh the auditors were very good to work with in regards to that. um they also showed a lot of good faith by providing um reduced fees given that it's a public good uh project. So we are very thankful and u to de Jung who has been working on this um proono. So yeah, thank you very

much.

Tim Beiko: Yeah, I'll echo that. Um, we reached out on what on what was pretty last minute pay timelines for uh what I know uh or for what I know of how book uh auditing calendars are. Um really appreciate everyone who uh who participated in this and worked with us. Um yeah, it's it's nice to know that uh we have high confidence in these contracts. I don't think there were any questions and again Frederick shared the report.

So um last call otherwise I think we can move on. Okay. Um, next up, uh, so we have this thread about the Petra retrospective. I saw some there's some activity there already, um, but there hasn't been a ton yet. So, I just wanted to, uh, flag this again. I think it would be great if in the next week or two, we could hear from most or all of the client teams there so that we can start discussing things. um because uh people are starting to bring up uh plans or suggestions for Fusaka and I think uh there's value in reflecting on Petra before we start making decisions about Fusaka. Um that

said on yeah on that note like one thing we did agree to in the past was to um cap the number of EIPs we include based on what's in a devet. Right now we have pureas and eof already included in fusaka. So um meaning that we should not include anything else until at least these two things are running on a devot. So in terms of work and prioritization teams should move those two things along if we have cycles uh after pectra. Um but yeah hopefully um if like yeah maybe next week we'll still be quite busy but

perhaps two weeks from now uh we can tentatively try and uh like yeah discuss everything that came up uh on the magician thread around how we want to approach Fusaka and uh have a bit of a like yeah higher level discussion before we start to get in the weeds. Um but yes any um questions comments on this if not yeah so gender has a comment saying verol is in devet so to be clear here I mean like the real fork devet not just like it's running on an arbitrary devet so the thing we said we would do is that prior to adding more stuff in a

fork we want to get what's already included on a fuss Tusaka DevNet. So, Fusaka DevNet one would have like teardas and eof and then I think until we have that stable and running, we should not include anything else in the fork. Um, and we can obviously um expand that if and when we're comfortable with it. Um, but that would be like the baseline. And in terms of like short-term work, I think on both those tracks there's still a lot to do. Um so if teams want to move Fusaka forward as they wrap up Pectra um getting both those things um in a spot where they're stable enough to merge together on a devet would be like the highest impact thing to do.

Um GM

Guillaume Ballet: uh yeah just a quick question. So if uh it takes for a very long time to if it takes a very long time to get any feature running on a devet what do we do? like we just uh or we realize there's a good reason not to do something. And I'm thinking specifically about execution engine like the idea that seems to be coming back. So I think um that would make sense to to question some choices we did a year ago. Um but okay. Yeah. Not not trying to start a debate but more like just

Tim Beiko: uh so it's fine if we remove some we can choose to remove something from a dev net that's fine. What we should not do and what we did wrong with Pekra and caused you know months of delay is add

10 unimplemented or schedule 10 unimplemented things for inclusion and say okay we're just going to go and like implement all of this now and then we have 12 different client teams that have to implement 10 different things and we try to like move all of that forward. It's it's just extremely hard to do this in like a coherent way. So we have like these different statuses. So scheduled for inclusion, CFI. So we should start SFI should be the stuff that's going to be in the next DevNet. And right now for um for Fusaka we have EOF and PRDAS. And you know that's what we should try to put in the first DevNet. If we realize

that you know these things are wrong, we can always remove them from the devnet. Um, but we shouldn't do something like, okay, we have um we have EOF and Fusaka or EOF and PIDAS and neither are ready and there's these five other EIPs and they're not ready either and so we're going to put these seven EIPs at the same time. Um, and I guess yeah, Lucas, you're saying like does won't this make us move slower? My strong intuition is it would not because then we can at least know everyone's like done the thing at the same time. Otherwise I think it becomes quite hard to like um basically align on okay who's who is where in terms of the different clients

and different things and it doesn't mean there should be only like one new EIP per devet we can agree like okay say we have eof and purdas and then everything is stable and we want to add more stuff and there's like three small EIPs then we can all agree okay those three small EIPs will be in the next devet but we shouldn't from the start have like more than we think is reasonable for a single dev. Um, uh, Roman,

so first of all, thanks for saying this very supportive. Uh, my personal view on the, uh, ideal schedule of when we scope and when we ship features is so we have fork n, forkn plus one and fork n plus2.

By the time that fork n hits mainet, we already have fork n plus1 scoped. So immediately after that, so in this case, by the time pectra hits mainet, we already have fusaka scoped with major features and we start iterating on that. And by the time Fusaka hits mainet, we already have work N plus2 scoped and we can immediately start going into development cycle and testing.

Thanks. Um, Lucas,

Łukasz Rozmej: well, I'm not sure if you want to start this discussion or should I wait for some other time to give the feedback

about

Tim Beiko: I mean, we have Yeah, we have some time now. So, I think it's an important discussion to have.

Łukasz Rozmej: So in in my opinion what we should do is try to adapt this kind of uh tik tok u situ schedule I don't know how to call it. So uh and I think what was proposed just before is u too uh too short. So I would say when we are hitting mainet on one on one fork, we should already be going to DevNets on the second fork if we want to make it faster and that uh that means we need to um we need to

schedule uh so we should have now already for example Fusaka scope defined at this moment right now and we could potentially uh uh now debate the next past Fusaka scope. Right. So, uh we need to see because and and this is a good example from from my side from our side execution client side because we were thinking that the next after Fusaka fork would be veral and we put a lot of um resources to it, a lot of time, a lot of effort but right now it's in limbo and we are um completely not sure what will be next right so that's a very good point that we are not there and uh Yeah.

Yeah. And that's kind of we kind of have to parallelize that paralyze a bit testing in my opinion which is not paralyzed because uh development is already quite well parallelized uh but uh testing and shipping is not parallelized at the moment and it's not like I'm pointing out uh anything. It's just I think it's it's more of a I don't know coordinated resources. So on on on all the sides. Um yeah, so that's kind of what I wanted to say.

Tim Beiko: So I I would like us to get there, but my sense is what you're proposing is almost like one step past what Roman was proposing. So it's like step one is so I like my sense is if if we do things well in the next year, then maybe for Glamsterdam we can be at where you're at. put it like today we don't have Fusaka implemented right and to be fair we already do we already do have Fusaka partially implemented like there are there are eof devets there are pure dust dev so like I think we're we're maybe 50% of where you're saying we should be and I I agree it would be nice to to be

part

Łukasz Rozmej: yeah exactly

yeah um Gil

uh yeah

Guillaume Ballet: I um just wanted to say I think I think It's a bit of a it's not a very good idea to do this thing because we have a lot of things changing all the times and I don't think we're fixing the real problem here. The real problem is that we are not scheduling the stuff that matters on the on the road map. We're just adding whatever is currently all the rage on Twitter and it's going to change in six in six weeks and we'll you know we'll keep running on the next item without removing the previous one.

Uh we've had a lot of this happening for Pectra. We've had for example inclusion list. We realized after some time that this was not going to that that this was not ready enough. So we decided to put it on later and now um we don't really know when we're getting inclusion lists. So it's not even about just vertical. It's about all the very important changes to the

Tim Beiko: and I think there's so there's two different so there's two different problems though. One is making good decisions and being better at that and I agree we can improve that. The other one is basically parallelizing the debating about the fork versus implementing the

fork. And I think like Roman's suggestion is like when we get to uh shipping fork A in this case spectra then we assume that the debate is closed on fork B so this case Fusaka and we can debate the fork after all we want. So we can debate Glamsterdam um you know all we want but we don't we don't delay the implementation of Fusaka because of this and sure this means like yes we have to make decisions about what we implement with imperfect information and in extreme cases we may want to revisit those but I do think there's value in locking the scope earlier to sort of move the argumenting to like the

fork after and you know I don't know say we're debating inclusion list or vertical for the next year and we still haven't come to a conclusion by the time Fusaka ships then whatever we did come to a conclusion for is what we should probably put in Amsterdam

Guillaume Ballet: right but my counter point would be exactly that it's vertical right I started working on it four years ago it was always supposed to be the next fork um and every time it's pushed yet another small fork in between and then something more important like

sure

Tim Beiko: okay so that work but I It's different to say we chose not to prioritize veral for the next fork which is the case like we chose not to put it in Petra and then we chose to split

tetra that's different from saying at a given time we should freeze our decision- making and that's independent of whether you know putting veral in fork A versus fork B is the right thing. It's more when do we close the door about about the scope of the fork and can we just have like a clean uh set of features that we we implement and test and then we can continue debating you know whatever other features for the next fork

Guillaume Ballet: right but okay what I'm getting at is when you talk about parallelism and I understand there's some scheduling thing that's uh that makes sense uh it's just that if you keep working on features so that they they get scheduled um you

you're still having this problem like you're still having people and okay I'm talking about vertical because that's what I did but I could talk about SS SS uh transactions stuff that Ethan have been has been working on um there's there's plenty of examples like this that happened to EOF for the longest time um we we need to have a solution and I don't think this approach I mean okay I understand why why you're saying this but I think we need to also have some guarantee that stuff we work on, you know, first are useful and that we don't waste time working on stuff that will never make it.

Tim Beiko: I agree with that and I think that's like a third hard problem because there is uh there are

things that are just fundamentally high uncertainty and we should do those and we don't have a great way to like make a decision about it. Um so it's like yes, there's three different problems. One is just can we ship stuff quicker? Two is can we separate arguing about stuff versus uh focusing on on the implementation and three is what do we do with like more speculative projects and how should we frame those because and and you know there's a sense where sometimes they're just like not ready and you know they take longer than expected and whatever. we can like I think that should be expected but I I agree we don't have like a clear way to

say oh you know like we actually don't think ver is the path forward or we don't think eof is a path forward or we don't think SSD or whatever like um yeah that's another can of worms and I I don't have like a solution for it right now

Guillaume Ballet: right just just one last thing uh when you say we want to ship stuff quicker I understand that very much I'm just saying we also need to be careful careful because what happened is that petra got super big because people said oh this should be quick sometimes it was sometimes it was not but the scope completely expanded and we should be very careful to pick what is important and not what is going to be fast

Tim Beiko: I agree and this is why I feel extremely strongly that we should only pick what

we think is the next most important thing to implement in the devet and move that forward um yeah I know Okay, there's a couple extra hands. Uh, Ahmad, I think you were next.

Ahmad Bitar: Yeah. Um, one thing that I wanted to say is that probably we need to prioritize EIPs with spec tests already employed or uh developed. uh with EIPs that are have the spec tests already developed then the that that the the development and testing of the developed versions can just go ahead. So what I would suggest is that uh to to to make uh uh tests mandatory for for yeah for

for for inclusion and any EIP edi uh uh author that does not that wants to uh uh his EIP to be included to find if he does not know how to write the spec test then he needs to find someone to champion and to write the spec test for him. If not then he should do it himself. Yeah.

Tim Beiko: Yeah. I think this is everyone I've spoken to in any context agrees with this. Um, we should my gut feeling would be for something to go to SFI. It should have tests. We might want to CFI something when it's still like in in a more uh like yeah in development stage.

But to me that should be part of the the gate to move from CFI to SFI. I do not work on testing. Uh I think if someone from either Eels's DevOps or testing wants to open a PR against EIP7723 and like propose a sort of formal uh like testing requirements that would be extremely helpful. Um but yes I I think having a like yeah having that at the gate is is quite quite valuable. Um yeah

uh pus oh

Potuz: I'm approximated um I wanted to make a couple of comments uh I heard two different things one is let's uh freeze

early the scope of the fork and the other one is weaker which is let's just freeze right now the scope of the first devet uh I would disagree with the first one but I would agree with the second one the the way that I believe that we can get to ship things faster is by always having a rolling devet for the next fork. So right now this would be eof plus pure dust and we get that devet going at the same time we can parallelize and start discussing whether or not we're going to add something else or not but at any time we have a devet that is ready or more or less ready to be shipped right next so then we can always make the decision let's just pull the trigger right now we ship only eof

and pierdas and uh we or we add things to that devet I agree that the first devet should if scoped it seems that it's already scoped. I don't see anyone disagreeing that it should be eof plus V does uh however even if we go that way like having this role in devet uh the only uh change that I would make to this uh this uh proposal of like freezing the scope is that I think uh EIP that are widely agreed and that are uh already implemented can be added to such a devet. Uh so for example to give an example now 7 to12 seems to be a no-brainer that everyone uh wants to to ship and somehow for some

reason no one just like strongly pushes for it but everyone that I talked to they say yeah it's already implemented it's trivial it should be there those things that are already implemented I believe that it's easy to change the scope of the current devet and add them

Tim Beiko: yes I agree and I'll I'll reiterate uh when we say devet Like I think we want to clarify like Fusaka Devet one rather than like some random you know feature DevNet but I think yes having a clear next fork devet um and we should maybe find a better word to talk about nonfeature either like yeah we either we have a call them forknetss or we call them like

nets or whatever but yes I think it's causes confusion to compare um an EIP specific devet with like the thing that we're building towards the fork. Um yeah, anyways, we can bike shed the specific name, but I think we like yeah, we we should clarify that.

Um Ben, um just beating back on the

Ben Edgington: we should prioritize what's important rather than what's fast. Um, I think as long as we um get the correct prioritization and I'd use um you know for all of our audience. So I'd use tetor as an example there which was both fast and

um for a certain community i.e. onchain devs uh was very important but I mean that took like three years plus to or two years at least to land um even though it had been implemented before. So we shouldn't forget the little things um and what's important to uh wider community rather than just I don't know sters validators that kind of thing.

Tim Beiko: Yes, I agree. Like we need to improve the decision- making as well and uh justify like why we're doing something. anything else on Fusa? We can continue this conversation on another call, but I think this has been helpful to at least get some context from different people. And I would reiterate like it seems like there's strong agreement on at least moving forward with a tight scope to start. So if you do have spare cycles and you're looking for what to do now that is almost done um pieras and eof I think should form the basis for fussaka devet one. Um and that should be like

our our starting point for any other things we consider. and then I'll also flag uh Mark on the call had proposed uh two EIPs for inclusion in Fusaka. There's been a couple also proposed uh as well before. Um so we don't have to discuss these on the call but if people want to start reviewing them async uh it can help as we start to um uh yeah as we start to discuss this. Um there's a comment about scheduling DevNet one for Fusaka. Um I guess I'd be curious to hear like what's the state of the pure das and eof dev nets uh if we want to do this and if if

it's still my sense is it's still more valuable to test them independently than to try and merge them together but I don't know if anyone uh has an updated view on that.

Potuz: they are independent scope so it's it's easy to test them in the same devet because the kind of bugs that you can find are completely different

Tim Beiko: um yeah

tum

Danno Ferrin: so as far as the the yeah it is fairly separate from the consensus layer um I've got four different um clients nethermind ref and basu um running under a fuzzing program they've been fuzzing for almost half a day now no problems uh found so far so I'm fairly confident we could ship or we would have shipped for

PCRA um into a DevNet. However, since we have time since we're not going to ship it in Q2, there are some basic features that we would like to address um that we didn't address because we were trying to hit the vector timeline. We didn't want to hold things back. Um I have a list I'm going to go over it um in the EOF call next week, proposal for draft for um what the DevNet's progression would look like before I bring it to ACD. I want to talk it over with the the EOF call. Um, but I'm fairly confident that we could uh if it's ordered in wish list order, we could cut from the bottom when we need to ship. So,

Tim Beiko: okay. And then pure devet should be ready the week after. Um, did you want to add something to this?

Potuz: Yeah to to to Dano I would suggest that we don't change eof right now at least not for the scope of the devnet let's just schedule a devnet let's ship a devnet let's start testing on a devnet and then you have in parallel discussions as to how the the scope of eof on the next devet would be

you're practically describing the document I have written up and our devet zero is shift what we have now and then tweak on devet one here.

Tim Beiko: Okay. So, I guess yeah, let's maybe uh yeah, continue this conversation, I

think. But like, sure, if we can if we I'm I guess I'm cautious about scheduling DevNet one now. I'd rather us focus on DevNet 6 perra actually ship this um especially in the next week than like move people's efforts too much. Um okay says we can do both. Does anyone else want to schedule the devnet now? Okay. Uh yeah, let's let's not do this now. We're let's ship Pekra. Um and we can also

coordinate async on the devet. Um and I am cautious about also like yeah having bugs in pure das affect eof progression and vice versa kind of like D was flagging. Um Roman.

Yeah. Uh just a quick follow-up response to autos disagreeing with raising the scope and having uh the devets for uh for N plus1 running. Again, as I said in the chat, like this would be ideal state of the world, but this is not something we can get to tomorrow or or by the end of this work because like we need we agree that we need to change the

process, but we cannot immediately just switch it and get to our northstar of how the process should work. So in in this case, freezing the scope seems to me like a good first step forward.

Tim Beiko: We can actually do this. Okay. So let's yeah, let's continue this conversation um in the next calls. Um, and yeah, I think again I'll I'll say if teams want to share their views in the ETH magicians thread, I think that would be helpful so we can summarize them uh prior to the call. Um, and then

hopefully in the next week or two we can uh yeah, we we we can agree on a path forward. Um, and then okay, we have about 15 minutes left. Um, so there's four EIPs uh that people wanted to discuss as well as uh Nico from uh the EF has been working on a bot to help streamline some of the ACD stuff. So we can cover those. Um, first off, Mark, do you want to briefly touch on the two EIPs you'd uh you'd propose for Fusaka?

Hi. Um, yeah. So I'd like to propose these two EIPs uh 7793 and 7843 and both of these add um pre-ompiles which expose some metadata about the context of where a transaction is currently executing. Um so the first one which I think is uh the more important one is 7793 which adds a TX index pre-ompile. So this returns the index of where a transaction is being executed in the current block. Um and the main application for this is in encrypted meles. Um so we can check in a smart contract that a transaction is being executed at the top of the block and

otherwise invalidate it. Um so this can enforce front running protection and it allows us to implement encrypted meles um at the smart contract level rather than having to enshrine it in the block validity conditions. Um so the other pre-ompile is 7843 which is the slot pre-ompile and this just uh simply returns the corresponding slot number for the current block. Um so this is something that is already possible. Um so we can calculate the slot number from the block timestamp but to do this you need to hardcode the slot length in a contract. Uh and so the motivation for adding this pre-ompile is making it easier to change the slot length in future without breaking contracts. Um so

they would be able to migrate to using this pre-ompile at an earlier stage before we potentially change the slot length in future. Um and it would be good to get some more uh feedback from application developers to understand if this is much of a problem like if there are many existing contracts which are hardcoded uh with the current slot length. Um so to address a few things that people might raise about this. So why make it a pre-ompile instead of an op code? Um, so this was Dano's suggestion and it allows uh L2s to decide whether or not they want to implement the pre-ompiles because it might not make sense to them whereas if it was an op code they would be forced

to implement it. And the other one is um could this uh kind of introspection be a problem in terms of uh zero knowledge proving um and I don't think this is the case because we already have some very similar op codes such as gas and time stamp um which are very similar to these pre-ompiles. So I don't see that there would be a problem with proving these new pre-ompiles if it's not a problem for the existing op codes. Um so yeah I would like us to uh consider this fusaka obviously pas and eof are the priorities but relatively small changes that yeah we could consider

Tim Beiko: thanks uh Ben you have a question on

this

Ben Edgington: uh yeah is is the slot number so you can encrypt transactions to a specific slot and if they're used beyond that then like if they don't make the slot you can invalidate.

yeah. So, that that is potentially how it could be used for encrypted meles. Um, but yeah, I'm not sure. This is kind of why I'd like to kind of start this discussion is are there other applications, people uh with contracts that are using the slot length for other stuff um to actually see if this will be a big problem for changing the slot length or not?

Ahmad Bitar: Yeah, I mean, I'm pretty sure there are. Uh I've already brushed upon some other contracts that are uh that they want to calculate some slot length before. Um that's why we are proposing this uh this pre-ompile to be honest. Uh because future proofing that's number one reduce the number of contracts that will be breaking. Um because like right now if you want to calculate the slot you have to divide the the time stamp minus the genesis time stamp over 12 which is u not always going to be the case if we change the slot time later. And yeah, this this this resolves this issue so we

can have faster faster blocks eventually.

Tim Beiko: Okay, any other questions? Uh, next up, uh, Kev then had an EIP to discuss hardware and bandwidth requirements, which we've, um, which we've brought up a bit before, but now it's all been formalized into a single doc. Um, yeah. Kev, do you want to give some context?

Kev Wedderburn: Uh, yeah.

You you can hear me. Hello. Okay. Uh, yeah. So, we now have a EIP. Uh, I can copy it into the chat. Uh, but essentially it defines the hardware and bandwidth requirements for block builders, uh, attesters and full nodes. Uh if I paste it in here, I think there was some confusion I saw about the block building part. So I probably open up discussion for that first. At the moment it's 50 megabits per second upload for max throughput for block building.

any uh anyone? Uh yeah, Nick.

So um I just I do want to push back on um 50 megabits per second just because that we have seen a lot of the staker community uh speak up and say that their upload bandwidths are are far below that. And I think that uh if we look at media and bandwidth upload speeds in a lot of countries in a lot of developed nations um in Europe and the US and Australia uh it's it's far below 50. I would be much more comfortable with something

like 25 or 30.

Kev Wedderburn: Uh but this is for block building, right? Like solo stakers aren't just like not all of them are block building. Some of them are using MEV boost and this is for max

local block building, right?

Kev Wedderburn: Yeah, sorry. Local block building.

Yeah. This this means that they're not able to anymore if we if we benchmark to 50.

Kev Wedderburn: Um they would be able to, but it wouldn't they wouldn't be able to go to the max throughput. So, they'd have to have like less maybe like half a block or something like this or like one

blob in there.

Blobs. Yeah. Yeah. Sorry. Yeah,

Tim Beiko: on that note, I saw uh recently there's um there's data saying like you know the public mele uh gets very little uh transactions anymore. So does do we know what's the average gas side gas limit of a locally built block at this point? Like my sense is that they're they're actually not full because um there's just like yeah not that many public transactions anymore.

Kev Wedderburn: I think the data always said it was like 6 million. I'd have to double check. Uh pus.

Potuz: Yeah. So the the local block building gets triggered for everyone. Uh if the circuit breaker gets triggered that's our fallback and uh if the circuit breaker gets triggered if the builders are not building for whatever reason transactions will be on the main poolool blobs are always on the meool and currently clients do not have a way of saying I want to build this block but I want to build a small block so that I

can actually broadcast it. Uh so it's uh I think it's not correct to have an app an uplink bandwidth neither required nor recommended that is far beyond the average that can be found in most countries. Not the average I'm sorry the median that can be found in most countries. The average is also a bad number to have here.

Kev Wedderburn: Great. So, you're saying that if we had this flag that basically said, I want to put in one.

Potuz: I I definitely disagree with that flag, but that's a different conversation. Uh, all I'm saying is that now you're taking averages on countries that have meal uh that have like over a thousand uh megabits per second for of uh on on on fast connections. And this certainly drives the average up, but the median is much lower than that.

Kev Wedderburn: Right. So I did actually look into some of the countries that people were uh quoting and I think a better indicator was like the fiber coverage. Uh Germany definitely uh had the lowest one but like most of the countries being cited had like 70% fiber coverage.

But when you look at those uh those numbers it like in the US for example when the fiber coverage is reported it's per census block and only one residence per census block needs to be uh able to get fiber for that census block to be considered covered. So that's not actually representative of who has fiber.

Kev Wedderburn: Right. But if right, I mean maybe this is debatable, but like if the ISP is saying they're giving 1,000 megabits or 5,000 or whatever it is, I don't know if it's like a good argument to say that they're going to be giving less than like whatever the 40 or 50 that's being uh suggested.

Like you'd have to be giving you'd have to be shaving off like 99%,

No, but for for example, um these census blocks say that like Brooklyn is covered u because they offer fiber to a few residences in that neighborhood and that that way they they can say that they offer it to that census block when actually it's not available to most residents in that neighborhood.

Kev Wedderburn: Mhm. Okay, I see.

Tim Beiko: Um, yeah, we do only have five minutes left and there's a couple other things.

So, I think it's worth continuing this conversation on the node requirements uh channel in the Discord. I I guess

Kev Wedderburn: can I quickly ask, do people have a problem with the max blobs flag? Because this solves the issues that we're having, right? I mean I know has a problem with it but do people generally have a problem with just saying if you can't do the max throughput then just build as much as your based on your hardware requirement or based on your bandwidth requirement like

Tim Beiko: okay uh there's definitely some concern

so yeah Let's uh let's move this back to Discord. Um yeah. Yeah. Thanks for bringing this up, Kev, and doing the uh hard work of trying to get some consensus on this uh which no one has wanted to do for years in part because it's uh contentious. So yeah, really appreciate you pushing this Um, okay. Next up, we had EIP7823. Um, Alex put this on the agenda. I don't know if you're still on the call to set some upper bound for the mod exp pre-ompile.

Marius van der Wijden: I'm here.

Kev Wedderburn: yeah.

Marius van der Wijden: So, the the modex pre-ompile has three variable length inputs and these inputs are unbounded. Um this has caused um multiple consensus bugs. Um many of the bugs happen with like practically useless inputs um if you just craft um those kind of transactions. Um and the second problem is that it is kind of hard to implement it in uh ZKVMs and many ZKVMs have chosen to put limits in place already. Uh an example is Polygon ZKVM or uh scroll Um and some others just purely decided

not to implement this recompile. Um this EIP proposes to put a reasonable upper bound um the same upper bound uh 28 bytes to each of these three inputs. And the reason choosing this value is that this enables this still allows um RSA um 8K RSCA verification which is the highest uh key size for RSA which is in use. Um it's not the highest reasonably used key size that's um half this size.

Um but nevertheless um this seems like a fairly uh good limit. It turns out that Polygon ZK VM has chosen the the same limit and we have also performed um some analytics on um the actual mainet starting from 2018 when this pre-ompile was introduced ending January January the 4th. Um these statistics are in the IP itself and it shows that um the highest width uh using successful transactions has been 512 bits and the the actually useful like um regularly used sizes are up to 256 bits.

Um this basically means that the EIP wouldn't um change the outcome of any past successful transaction. But we don't propose to uh introduce this retroactively rather introduce it in a hard fork. Um and then furthermore one more outcome of this would be that this would make it much more simple to be implemented with something like EVMax. Um there are a number of other questions we could put in further limitations. Um and those are being posted on the magicians forum link. So that's in Giz. Um I just want to get some temperature check if anybody is have any any thoughts about this. Maybe we don't have time for the feedback today.

Tim Beiko: It seems like there's some loose support in the chat. Does anyone have like an objection that they wanted to bring up otherwise I think we can continue async. But is there anyone who feels strongly against this or sees an issue? Okay, then if not like yeah, it seems like there's some support. Uh we can continue this async. Um we had one last thing on the uh agenda. So Nico's been working on a bot to help automate some awkward dev stuff. Um Nico, are you on the call?

Nicolas Consigny: Uh yes. Can you hear me?

Tim Beiko: Yes. Right.

Nicolas Consigny: Um so I'm not going to do the full uh demo today. Uh maybe I'll do it next week because we don't have time. Um, basically just to give uh context, it's a bot that will automate everything from the Ethereum PM repo. So when an issue is created, um, it will automatically like create a recording meeting um, and crossbost on different uh, platforms. So it's going to crossost on Ethereum Magician and probably also on parker. Um, I still need to to finish this one. Um so and then once the meeting is um is done it will record uh

it will give a summary and the transcript uh automatically posted in in the Ethereum magician um thread and that way people can like um access um the text like the text transcript to search precise uh words with time stamp and all of this. Uh so hopefully it will help people to win some time and to be more effective and uh yeah I'm open to suggestion. I think there's a lot we could like automate and um we could have um yeah a good solution that help everyone to get good information from ACD without spending a lot of time uh

into like the YouTube recordings and stuff and yeah and we can probably iterate on the AI summaries to find the best ones and yeah this way we can have um a more efficient ACD process.

Tim Beiko: Yeah, thank you. This is um yeah, this is really helpful. And then maybe one last thing to mention is I think the bot is open source or will be open sourced. So um yeah, we can get uh other people to extend it and add some cool features to it. Uh but hopefully we can uh automate a bunch of these things that we have to do every time and make it easier because now there's about 10 plus

breakouts running in parallel. So um yeah that'll be nice. Um and I know sorry last thing before we wrap up uh there's an RPC standardization call next Monday. So I'll just put the link there in the chat. Anything else people wanted to flag before uh we conclude today? Okay. Well, thanks everyone. I talk to you all soon and yeah, let's get DevNet 6 uh sorted in the next week.

Bye, guys.

[Music] What's up?

Thank you.

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