AllCoreDevs - Execution #235

gm

mg

gm

Red added read.ai meeting notes to the meeting. Read provides AI generated meeting summaries to make meetings more effective and efficient. View our Privacy Policy at https://www.read.ai/pp Type "read stop" to disable, or "opt out" to delete meeting data.

Reacted to "mg" with 🙃

2 times in a row Justin is just quiet when he joins 😢

Replying to "mg" ƃɯ

Reacted to "2 times in a row Justin is just quiet when he joins 😢" with 🥲

Reacted to "2 times in a row Jus..." with 🐻

the vibes remain off

Replying to "2 times in a row Jus..." did we do something wrong

Gm

Replying to "the vibes remain off" the silence will stay until the morale improves?

Reacted to "the silence will stay until the morale improves?" with ❤️

Replying to "2 times in a row Jus..." i think there is a reckoning going on.

Potuz will be 10min late. So maybe we can circle back to his topics later.

https://github.com/ethereum/pm/issues/2015

episode 😂

Reacted to "Potuz will be 10min late. So maybe we can circle back to his topics later." with 👍

Reacted to "episode 😂" with 🍿

Reacted to "episode 😂" with 🍿

Reacted to "episode 😂" with 🍿

Reacted to "episode 😂" with 🍿

Hooray!!

Replying to "episode 😂" its soap oepra

Reacted to "episode 😂" with 🍿

Congratulations, Nixo!

Reacted to "episode 😂" with 🍿

Reacted to "episode 😂" with 🍿

Congrats! <3

Reacted to "Congratulations, Nix..." with 👍

lets goooo nixo!

Reacted to "Congratulations, Nixo!" with 💙

gz 🍺

Congrats Nixo 🫡

Reacted to "Congrats! <3" with 💙

Reacted to "lets goooo nixo!" with 💙

Reacted to "Congrats Nixo 🫡" with 💙

Reacted to "gz 🍺" with 💙

Reacted to "episode 😂" with 🍿

Replying to "the vibes remain off" it's a good question tbh. the enthusiasm is usually warranted, but lately... I promise it will always be sincere

Yaaay nixo!!

lfg Nixo!

Reacted to "it's a good question tbh. the enthusiasm is usually warranted, but lately... I promise it will always be sincere" with 🫡

Reacted to "it's a good question..." with 🫡

Reacted to "it's a good question..." with 🫡

Reacted to "Yaaay nixo!!" with 💙

Reacted to "lfg Nixo!" with 💙

Reacted to "it's a good question tbh. the enthusiasm is usually warranted, but lately... I promise it will always be sincere" with 🫡

Reacted to "lfg Nixo!" with 💙

Reacted to "Hooray!!" with 💙

I think we did

Besu: Yes, no issues

geth now has bal-devnet-4 branch any other client has a branch prepared already?

tomorrow

Replying to "geth now has bal-devnet-4 branch any other client has a branch prepared already?" We have one as well. But 1 PR still needs to be merged in

The new 7 changes did turn the implementation quite ugly for us

No issues on the ethrex side

https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-0

bal-devnet-4 spec https://notes.ethereum.org/@ethpandaops/bal-devnet-4

https://github.com/ethereum/execution-apis/pull/786 or https://github.com/ethereum/execution-apis/pull/770

Both are fine, I don't care either way

Replying to "https://github.com/e..." could EL teams chime in which one would they prefer

Replying to "Both are fine, I d..." 786 is more principled, 770 is slightly easier to implement

https://github.com/ethereum/execution-apis/pull/770 or https://github.com/ethereum/execution-apis/pull/786

its been in discussion for over a month. Would prefer to make a decision

I prefer 786 because it is formally correct at least for consensus

+1 for what Marius says, just ship whatever

It feels like, in case there's no finalization for more than 128 blocks, then ELs should keep the state diff / state snapshot available to be able to do auch a deep reorg without falling-back to snap sync. I think Marek mentioned that option last time.

flip a coin

128 is also good for us

going lower than 128 requires more work

What happens if we hit that cap?

we stall

yeah cause no block can be acccepted

Reacted to "yeah cause no bloc..." with 👍

ah that was a reply to Marius

I believe reth already supports reorg up to finalised using config on the engine

what does “reorg within the canonical chain” mean?

Replying to "what does “reorg wit..." the CL chain has more nuance about what's canonical than the EL, we can reorg to a previous hash of the chain as canonical, but the CL takes a different CL block for it

Reacted to "the CL chain has mor..." with 🙇‍♀️

Replying to "what does “reorg ..." Reorg within the chain that leads to our current head

Replying to "what does “reorg ..." Thats our currently canonical chain

Is this really a reorg then or is it just building on top of a previous block in the canonical chain?

Replying to "what does “reorg wit..." you’re saying that we may maintain a header chain, but the contents may change?

Sounds like we should do the principled solution

@toni we have state for the last 90k blocks

we've already wasted enough time on this, the cap of 32 is fine too, it doesn't matter, we will need a majority attacker to trigger this and we'd be already in trouble anyway

Reacted to "we've already wast..." with 👍

we will never reorg more than 1 block

ever never

We can add this reorg scenario to benchmark scenarios. (In fact we should)

786 lets go

Reacted to "786 lets go" with 🚢

Reacted to we've already wasted... with "👍"

Reacted to "786 lets go" with 🚢

Replying to "we've already wasted..." ...or a bug

Replying to "We can add this reor..." Add in todo list

Replying to "we've already wasted..." Imo such a big attacker is less likely than a bug. At least empirically

FCU->finalized_hash->block_number lookup -> keep one pointer to it

just put the cap internally

Reacted to "FCU->finalized_hash-..." with 👍

do we need finalized-1?

Replying to "We can add this reor..." Thanks 🙏

let's just test depth 1 :) that's all that will happen ever

Replying to "786 lets go" who removed my own ship? 😂

I think we would need to make an assumption around how long we can have periods of non finality?

Replying to "let's just test dept..." This is the only real epbs need, right? The rest is just making a good spec

I'm fine with it but let's just be intentional that ELs would stall if such a scenario ever happens.

Replying to "let's just test dept..." yes unless there is a majority attacker on the validator set that wants to trigger this

Replying to "let's just test dept..." or a bug on clients

Replying to "I'm fine with it b..." It wouldn't stall, it would just reject this

Replying to "let's just test dept..." Or asynchrony / network issue

Replying to "let's just test dept..." no that can't be the case for this

Replying to "let's just test dept..." because it would be pretty weird that the CL p2p is gossiping blocks+payloads and not attestations

768 and stop arguing

Reacted to "768 and stop arguing" with 👍

Reacted to "768 and stop arguing" with 🚢

Reacted to "768 and stop arguing" with 🚢

Replying to "768 and stop arguing" that's a new one?

Agree with 786

Replying to "768 and stop arguing" up to genesis

Replying to "768 and stop arguing" 786

no u right

Reacted to "up to genesis" with 😂

Reacted to "768 and stop arguing" with 🚢

Reacted to "768 and stop arguing" with 👍

Reacted to "because it would be ..." with 👀

Reacted to "Screenshot2026_04_23_163146.jpg" with 😂

Reacted to "Screenshot2026_04_23_163146.jpg" with 😂

Replying to "768 and stop argui..." I'm not good with numbers

Felix(Geth): Is 786 in now ??

Reacted to "episode 😂" with 🍿

Reacted to "Is 786 in now ??" with 👍

Reacted to "Is 786 in now ??" with 👍

Reacted to "Is 786 in now ??" with 👍

Replying to "Felix(Geth): Is 786 ..." please close 770

is it useful to CL clients to give them our max reorg depth via a config api?

sorry for saying “emergency inclusion” - that’s obviously silly in this context, I just meant inclusion after the CFI window has been closed

Reacted to "768 and stop arguing" with 🚢

Replying to "is it useful to CL..." for Nimbus CL not really. either it needs the reorg or no

This was brought up many times in earlier calls, its just got its own EIP now

Replying to "is it useful to CL..." it's going to follow whatever its fork choice requires

again I do not really feel strongly about this, it's a good to have it EL devs think its easy

Reacted to "Screenshot2026_04_23_163146.jpg" with 😂

I think I might have misunderstand terence’s comment yesterday, thought it was high urgency for gloas

all I'm asking is for EL devs to take a look at it cause it would really save **a lot** of bwidth and speed to sync clients

Why do we need the accumulator?

Ye it would be very nice

Replying to "Why do we need the a..." because the attacker can lie what the withdrawals were

Yeah it's def nice and should be done in hegota

https://github.com/ethereum/pm/issues/2015#issuecomment-4305210461

Replying to "Why do we need the a..." the validators can be malicious and finalize an invalid block

Reacted to "Screenshot2026_04_23_163146.jpg" with 😂

One last thing on 8237 (or against 8237 lol) it's absolutely fine to ship in Hegota cause there's very little tech debt, a couple of structure changes but the whole range requests can be deleted from clients and deprecated immediately as soon as the EIP is SFId, so no problem to include it later

Replying to "Why do we need the..." Hmm I see

I have to run, I think we need 8037. Otherwise we can't really increase the gas limit

I agree that the complexity increased quite significantly

So we agree to try to simplify? Want to try some ideas

Adapting the price with the gas limit is a “nice-to-have” that increases the probability of setting an “appropriate gas price” (facilitating multidimensional metering with high throughput) at any given gas limit. However, it does not guarantee that an appropriate price is set, because the price will not adapt with actual demand anyway (as in the EIP-8075 proposal). So the best way to understand the functionality of adapting the price with the gas limit is that it makes it more likely that we can set an appropriate gas price across a wider range of gas limits, but it never actually provides any guarantees that the price would be set correctly at any limit. The direct outcome is that a fixed price must be set such that there will be a higher probability that the price is a too high initially, and too low when closing in on the Hegota fork.

STEEL has spent all day trying to simply 8037. We came up with approaches to attack all the problems, but the changes were so numerous it was basically a rewrite.

Reacted to "STEEL has spent al..." with 👍

I've been preparing spamoor to work under the new eip 8037 gas model. While doing so, we'Ve noticed that a lot of the deployments take significantly more gas, pushing some of the existing contracts, especially related to Uniswap over the transaction gas limit of 16M. So, implementing 8037 leads to the situation where existing big projects are likely no longer able to deploy their contracts on chain, because the combination of increased state cost and the per tx gas limit leads to a effective reduction of the deployable contract size.

do you have the list of all problems?

This should be ~fixed~ slightly mitigated with 0 -> x -> 0 rule that is going in devnet4

@Marius Van Der Wijden (M) do you still have your hand up or again?

Replying to "I've been preparing ..." Why? We remove the 16m gas limit, so they should be able to deploy

Replying to "I've been preparing ..." wait we removed the 16m gas limit?

Replying to "I've been preparing ..." yea, didn't know that we're removing the per-tx limit too.

Replying to "I've been preparing ..." Only for regular gas

Replying to "I've been preparing ..." There is mechanism that exempts state gas from the cap

Reacted to "Lets discuss on sval..." with 👍

Replying to "Lets discuss on sval..." good job sharing the secret location

Replying to "I've been preparing ..." Yeah, gas more than 16M can only be spend on state increase.

Reacted to "good job sharing the..." with 🤣

Replying to "Lets discuss on sval..." Its in norway

Reacted to "good job sharing t..." with 🤣

Reacted to "good job sharing the..." with 🤣

Reacted to "good job sharing the..." with 🤣

Reacted to "do you have the list..." with ➕

Reacted to "good job sharing t..." with 🤣

Reacted to "good job sharing the..." with 🤣

Reacted to "good job sharing the..." with 🤣

Reacted to "good job sharing the..." with 🤣

Reacted to "good job sharing the..." with 🤣

Replying to "STEEL has spent all ..." I don't have a comprehensive list in writing on me atm, sorry. We will get summary out ASAP.

defining cost via header accumulator of state additions? welcome total state difficulty 😄 (and no 2nd dimension)

Reacted to "good job sharing the..." with 🤣

Reacted to "good job sharing the..." with 🤣

Reacted to "good job sharing the..." with 🤣

Reacted to "good job sharing the secret location" with 🤣

I think the main issue here is not devnet-related. The concern about big contract txs hitting the limit is probably the issue I heard that I find concerning

Is the risk of a major bug in EIP-8037 really worth the benefit? Do we need that much scaling in the next fork right now, or can we ship a simple state-cost bump this fork and give 8037 another cycle for coverage? I'd rather we prioritize shipping EIPs that are well-scoped and well-tested than shipping something that even our testing team is finding “impossible” to cover.

I think EIP-8037 is fundamentally flawed - it's both far more complexity than the benifits that it actually brings, and is also the wrong path long term for dealing with charging for state growth.

Here is the research post: https://ethresear.ch/t/failure-modes-in-eip-8037-and-state-gas-scaling/23975 It discusses state-gas parameter only (SGPO) hard forks. There are various levels of complexity that it could be implemented at.

Reacted to "I think EIP-8037 i..." with 👍

8037 is really not that bad. Splitting regular gas and state gas makes a lot of sense. I agree, that simplification of the EIP is always a win.

Imo EIP-8037 is nice change and it unlocks bigger block, so it feels impactful to stay.

That part isn't that bad. It's the dynamic gas pricing

dynamic gas pricing is strange

Replying to "8037 is really not t..." More backwards compatability considerations in the EIP would be great.

Reacted to "dynamic gas pricing ..." with 👍🏼

Replying to "dynamic gas pricing ..." indeed

Reacted to "dynamic gas pricing ..." with 👍🏼

Replying to "dynamic gas pricing ..." I agree

if you have state cost increase you can increase tx limit proportionally

Replying to "dynamic gas pricing ..." We always have done costant gas number consumed by opcode and then price the gas in wei, this thing is making the gas number consumed variable

Just imagine how much headache we gonna give to Devs…

Reacted to "Just imagine how m..." with 👍

Replying to "Just imagine how muc..." ibuprofen

Reacted to "ibuprofen" with 😂

Replying to "Just imagine how muc..." ibuprofen for mascot

Reacted to "ibuprofen for mascot" with 💊

Reacted to "ibuprofen for mascot" with 💊

Reacted to "ibuprofen" with 😂

Reacted to "ibuprofen for mascot" with 💊

aextension :D

Reacted to "ibuprofen for mascot" with 💊

Reacted to "ibuprofen" with 😂

Reacted to "ibuprofen for mascot" with 💊

Reacted to "ibuprofen" with 😂

Note that SGPOs would allow more accurate pricing than the current EIP, and therefore quite possibly more scaling, because devs can adapt things to actually observed demand.

EIP-8163 - https://eips.ethereum.org/EIPS/eip-8163 https://ethereum-magicians.org/t/eip-8163-reserve-extension-0xae-opcode/27756 * Reserve `EXTENSION (0xae)` for non-Ethereum L1 EVM use * Equivalent to `INVALID (0xfe)` on Ethereum L1 EVM * No implementation effort needed :tada:

Replying to "dynamic gas pricing ..." Yeah I know, I needed to propagate this variable everywhere so it is a new mechanism I needed to make

Reacted to "ibuprofen for mascot" with 💊

Reacted to "ibuprofen" with 😂

the problem is that we need L2s to agree on how they will use the opcodes that are blocked off

Yes 0xae

https://eips.ethereum.org/EIPS/eip-8163

F range is oversubscribed, more proposed opcodes than space left.

0xef may be better

Antwoord verzenden naar "0xef may be better" l2 contract cannot start with this byte if it implements the blockoff of 0xef at start of contract

Reacted to "0xef may be better" with 🙃

Antwoord verzenden naar "0xef may be better" https://eips.ethereum.org/EIPS/eip-3541

Replying to "0xef may be better" Right, so start with jumpdest/ef-extansuon

Antwoord verzenden naar "0xef may be better" ah right yes that works

https://eips.ethereum.org/EIPS/eip-7979

Replying to "the problem is tha..." The EIP-8163 sets some minimal constraints (mainly not breaking JUMPDEST analysis), and punts coordination on the actual extensions to be outside of EIP-8163 scope (suggests coordinating via EthMag to start with). (also to be maybe more explicit - it's L2s as well, but alt L1s primarily)

Replying to "https://eips.ethereu..." Nethermind supports this EIP

Replying to "https://eips.ethereu..." but I agree we do need compiler confirmations

I have a technical question but cannot speak rn. What is the purpose of the validation phase of EIP-7979

would it be possible to add CALLSUB/RETURNSUB without this validation phase?

that seems a misguided approach

(not Felix's comment, the Vyper idea of not even looking)

I'm just curious because there is no rationale section about the existence of the validation

I've used VM's that work like this, and it worked well.

Would be great if solidity/vyper could form an opinion on it — or else it may be implemented in a way that they in retrospect would not like