AllCoreDevs — Execution #236

gm

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.

Gm

g(svalbard)m

Reacted to "g(svalbard)m" with ☀️

Reacted to "g(svalbard)m" with ☀️

Still chilling in the arctic?

Reacted to "g(svalbard)m" with 🐻‍❄️

gm folks 🤠

gm

gmgm, nice to be back in the acde participant role for the first time in a while

gm

Reacted to "gmgm, nice to be back in the acde participant role for the first time in a while" with 💙

Reacted to "gmgm, nice to be bac..." with 💙

Reacted to "g(svalbard)m" with 🐻‍❄️

Reacted to "gmgm, nice to be bac..." with 💙

Reacted to "g(svalbard)m" with ☀️

Heeft gereageerd op "gmgm, nice to be b..." met 💙

gm

Reacted to "gmgm, nice to be bac..." with 💙

Reacted to "gmgm, nice to be bac..." with 💙

https://blog.ethereum.org/2026/05/02/soldogn-interop-recap

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

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

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

Reacted to "gmgm, nice to be bac..." with 💙

Replying to "g(svalbard)m" nah man are you still there!?!$#$

Reacted to "g(svalbard)m" with ☀️

Reacted to "g(svalbard)m" with 🐻‍❄️

Reacted to "g(svalbard)m" with 🐻‍❄️

Replying to "g(svalbard)m" someone gotta skii all the slopes

https://github.com/ethereum/pm/issues/2033#issuecomment-4397074196

Replying to "g(svalbard)m" And keep providing 24/7 uptime

Reacted to "g(svalbard)m" with ☀️

Reacted to "g(svalbard)m" with 🐻‍❄️

Reacted to "gmgm, nice to be bac..." with 💙

What if we create a gas trace format?

Or extend the existing trace format?

Replying to "What if we create ..." Yeah we need to align on state gas in the traces

Reacted to "Or extend the exis..." with ➕

Is it an idea for testing to leverage the BALs here to isolate txs for debugging here? At most 16.7 regular gas used

Reacted to "Or extend the existing trace format?" with ➕

I would prefer to make it oblivious to the user

Heeft gereageerd op "I would prefer to ..." met 👍

Reacted to Yeah we need to alig... with "👍"

Reacted to "Yeah we need to al..." with 💯

Reacted to "Or extend the exis..." with ➕

Reacted to "Yeah we need to alig..." with 👍

Reacted to "Yeah we need to alig..." with 💯

Reacted to "Or extend the existi..." with ➕

Don't mind where it goes; but is very hard atm to tell either from receipts or trace where the gas goes on a client

Reacted to "Don't mind where it ..." with 👍

Reacted to "Don't mind where it ..." with 👍

Whats the tldr?

https://github.com/ethereum/EIPs/pull/11399 which proposes to update the SFI'd EIPS in Glamsterdam to: ### EIPs Scheduled for Inclusion * [EIP-7708](./eip-7708.md): ETH transfers emit a log * [EIP-7732](./eip-7732.md): Enshrined Proposer-Builder Separation * [EIP-7778](./eip-7778.md): Block Gas Accounting without Refunds * [EIP-7843](./eip-7843.md): SLOTNUM opcode * [EIP-7928](./eip-7928.md): Block-Level Access Lists * [EIP-7954](./eip-7954.md): Increase Maximum Contract Size * [EIP-7976](./eip-7976.md): Increase Calldata Floor Cost * [EIP-7981](./eip-7981.md): Increase Access List Cost * [EIP-8024](./eip-8024.md): Backward compatible SWAPN, DUPN, EXCHANGE * [EIP-8037](./eip-8037.md): State Creation Gas Cost Increase

Replying to "https://github.com/e..." 8037 isn't in devnet yet?

Replying to "https://github.com/e..." wdym? I thought this was included in every devnet after BAL5 with all the latest changes.

https://forkcast.org/priority

Replying to "https://github.com/e..." D'oh; was thinking of the other one

Replying to "https://github.com/e..." 8038

Reacted to "8038" with 👍

Replying to "https://github.com..." classic off-by-one

Reacted to "classic off-by-one" with 🤣

Reacted to "classic off-by-one" with 🤣

Replying to "https://forkcast.org..." I would consider this more as pathfinding towards introducing a prioritization list. so for Hegota we would start relying on it more (but as nixo is saying, only as a default ordering, not binding)

Reacted to "classic off-by-one" with 🤣

Reacted to "classic off-by-one" with 🤣

Replying to "https://forkcast.org..." but who decides prios then if not ACD?

Just deployed a forkcast change to make the client prios, STEEL complexity assessment, devnet status easier to find. Not meant to be prescriptive, just helpful data. Feedback welcome: https://forkcast.org/upgrade/glamsterdam/candidates

Reacted to "classic off-by-one" with 🤣

https://github.com/ethereum/EIPs/pull/11006/changes/3fd84bb5a82b5f41d79cb4b3f5cde592bee609bf

Reacted to "classic off-by-one" with 🤣

Reacted to "I would consider thi..." with 👍🏼

Reacted to "classic off-by-one" with 🤣

Reacted to "classic off-by-one" with 🤣

Reacted to "I would consider thi..." with 👍🏼

Reacted to "D'oh; was thinking o..." with 🤣

Replying to "https://github.com/e..." single character change :D

Ok this removes my confusion as well thanks Marius

Reacted to "classic off-by-one" with 🤣

https://github.com/ethereum/EIPs/pull/11444

I'd love it if EL devs could take a look at this, regarding those "reorgs back", I believe there's a lot of confusion on this topic: https://www.potuz.net/posts/gloas-honest-reorgs/

We are working to support arbitraly long reorgs with targeting finalization block

Do you want this number to be in the spec?

Reacted to "I'd love it if EL de..." with 👀

It will be nice to have some tests to verify the client behavior with different reorg

Imho if the number is as low as 128, we need to completely rethink what we are doing with consensus, because there’s no point in trying to worry about all kinds of crazy edge cases of days without finality if then at the end of day it’s not possible to reorg past 128

We have a PR in Besu

Reacted to "Imho if the number i..." with 👍

@nixo my stupid client on Arch doesn't let me raise my hand, would like to comment on this topic briefly

Replying to "https://forkcast.org..." we’ve been doing ACD-T proposals for devnet inclusions: testing teams (devops+steel) suggest EIPs then core devs should raise if they disagree either because a proposed EIP is not important, or a more important EIP is missing, we put EIPs in the agenda prior so everyone has time to digest and raise opinions

It can be a Hive test, right?

Reacted to "@nixo my stupid client on Arch doesn't let me raise my hand, would like to comment on this topic briefly" with 👍

Replying to "It can be a Hive tes..." Hive chain isn’t that deep unfortunately

Yes would be good as hive test!

Replying to "It can be a Hive tes..." Oh, that’s an interesting limitation

ahh it was full screen

Reacted to "we’ve been doing ..." with 💯

Replying to "https://forkcast.o..." Once we have a CFI list I'd love to have a flexible devnet-N plan (timeline). STEEL<>pandas should propose this during ACDT, and I feel it should be correlated to EIP complexity. The lesson this fork is that more complex EIPs should be in a devnet earlier

Reacted to "Just deployed a fo..." with 🔥

Reacted to "Once we have a CFI l..." with 👍🏼

Should we modify the “safe” in the api to be “justified” per-protocol? I think everyone is doing it, but there’s nothing on EL side that guarantees it. All we have on our side is finalization.

Replying to "It can be a Hive tes..." I think we need also p2p part because we can receive a new block in a new chain but we don’t have all the blocks of this new chain . So we need a backward sync

“user” here you mean the node operator, right?

The goal of Jacek was different here. It is about sync.

Replying to "“user” here you mean..." yes

This is the PR: https://github.com/ethereum/EIPs/pull/11601

Yes, plus if everyone starts snap sync that is an issue as the amount of providers left be small plus the network would be heavily overloaded, whereas deep-reorgs should be mostly self-supported, right?

Right now it uses WSP (~15-16 days) but I'm happy changing it to the 38 days (restoring finality with 70% of the network offline).

We should agree that returning before finalized **requires** social intervention anyway

Also what if we finalize something weird

We have a pruning mechanism in Besu and we not remove trielog before finalization

IMO if you have to revert to pre-finalization you might as well resync, that is a stop-everything situation

Replying to "Also what if we fi..." social recovery or etc

Replying to "Also what if we fi..." the technical mechanism has broken

exactly, we need to agree socially in that case anyway

Reacted to "IMO if you have to..." with 👍

Replying to "Also what if we fina..." Yes, but for that we need the state anyway

Imo if we don’t want to support reorgs past X blocks, then we should explicitly have soft-finality past X blocks, where the CL also refuses to reorg that deep and we accept that we could lose liveness/require manual intervention if such a situation ever happened. The in between state where some clients do support deep reorgs and some do not is not helpful, we are probably not going to be robust to such situations in practice if it’s not something we test for, but we still pay the cost of trying (in the consensus design, and in client work)

Replying to "Also what if we fina..." The 90k was chosen because it allows for social recovery

Replying to "Imo if we don’t want..." forbidding such reorgs in the CL may be quite complicated

Replying to "Imo if we don’t want..." can look into it, but it sounds like hacking forkchoice to start from below the justified checkpoint perhaps

I think we will leave Engine API as is with that abstract ‘Too deep reorg’ error where the limitation is supposed to be implementation specific. And figure out the ability of EL clients to reorg separately

Replying to "I think we will leav..." But thats for reorgs in the canonical chain

Replying to "I think we will leav..." Not for normal reorgs

Geth reorg is also pretty slow. We should really optimize it more

Replying to "Imo if we don’t want..." Yeah I meant something like this, not so much forbidding a reorg but more marking a block as always canonical like we do for justified (tbd exactly)

Replying to "I think we will leav..." For the moment we return SYNCING in besu in this case

Replying to "Geth reorg is also p..." what is slow? I would have expected that executing the payload is slow, so on newPayload and not on FCU

Replying to "I think we will leav..." It’s for all types of reorgs

Replying to "Geth reorg is also p..." well, perhaps on newPAyload you don't execute in this case

I would like to assist on the testing part of this, so we can also optimize/test reorgs and also make this somewhat part of benchmarks to get an idea of the performance of nodes in this network attack situation

Replying to "Geth reorg is also p..." but I think the execution is the slow part right?

Replying to "Geth reorg is also p..." Applying all the state diffs in reverse

Replying to "Geth reorg is also p..." We apply the reverse diffs on the db directly

Replying to "Geth reorg is also p..." Lol as sina said

Replying to "Geth reorg is also p..." yeah but if this is slow then you don't reorg

Reacted to "Lol as sina said" with 😃

Replying to "Geth reorg is also p..." cause you trigger the node to be optimistic

Replying to "Geth reorg is also p..." Its like 6 hours slow

Can we better clarify what “this” as in “this is doable” is? Are we talking about deep-reorgs in general or reorgs deeper than finality?

Without any tests difficult to say . We should see the result of client before we decide

Replying to "Geth reorg is also p..." We should return syncing in this case. Currently we block until reorg is finished

Reacted to "I would like to assi..." with 👍🏼

Replying to "I would like to assi..." what framework do you have in mind to write this test?

Replying to "Geth reorg is also p..." thanks yeah that confirms the above

Replying to "Geth reorg is also p..." then nodes that can't just become optimistic

Replying to "Geth reorg is also p..." for a whil;e

Replying to "Geth reorg is also p..." but it doesn't kill the chain

Reacted to "We should return syn..." with ➕

Replying to "I would like to assi..." We can give it a try and I can assist whether is eels or hive

At that point wouldn’t most people just resync their node?

So on the fcU SYNCING is returned and node becomes optimistic in this case

FCU there is timeout for RPC calls ? Return syncing and do reorg in background seems to be better

For NewPayload we just return “accepted” if we don’t execute it, e.g. would require deep reorg

syncing would be “oh I’m actually doing work to get there"

Replying to "So on the fcU SYNCIN..." yeah this seems to me the sanest option here

Replying to "So on the fcU SYNCIN..." instead of not returning anything

And if you get ACCEPTED and then reorg to it, and get SYNCING in the fcU response then you become optimistic right?

Replying to "So on the fcU SYNCIN..." because at least this lets the chain stall until execution finishes

Reacted to "FCU there is timeout..." with 👍

Reacted to "And if you get ACCEP..." with 👍

Antwoord verzenden naar "I would like to as..." I feel hive as this is a test, if we do eels only we assume that we have local rollback, and we want the network to be available to see what the network does. In case all clients except one rollback to sync we want to see the impact of this (esp. on the network)

Reacted to "And if you get ACCEP..." with 👍

Antwoord verzenden naar "I would like to as..." (then the one node which does the local rollback is essentially the snap sync seeder)

Or we fork the deposit contract

Reacted to "Or we fork the depos..." with 😄

Reacted to "Or we fork the dep..." with 😄

Reacted to "Or we fork the depos..." with 🤣

Reacted to "Or we fork the depos..." with 😄

only builder deposits are a problem right?

Reacted to "Or we fork the depos..." with 😄

Replying to "only builder deposit..." no, all deposits

Antwoord verzenden naar "I would like to as..." For EELS this is also doable for the local rollback but the fixture file will be funny to fill if we want to do 113056 blocks rollback (flashbacks to 8192 blocks for blockhash contract lol)

Reacted to "no, all deposits" with 👍

top up / new validator anything

I am in the support of this EIP as it removes the dependency between MAX_DEPOSIT_REQUESTS_PER_PAYLOAD on the CL side and gas limit on the EL side

Replying to "only builder deposit..." all deposits are not a big issue for us cause we don't verify the sig immediately

Replying to "only builder deposit..." Even 1 ETH top ups can cause issues

That's how it looks in EELS (tldr super simple) https://github.com/ethereum/execution-specs/pull/2818 Block builder is more problematic

Replying to "only builder deposit..." only the SSZ issue is the problem

Replying to "only builder deposit..." but builder deposits are actually a problem

Antwoord verzenden naar "I would like to as..." And this should also use blockchain-engine-x format I think as this is not a "normal" blockchain test

Replying to "only builder deposit..." thats another problem

Reacted to "That's how it look..." with 🔥

Reacted to "thats another proble..." with 😅

Replying to "only builder deposit..." yeah the SSZ limit we can simply just limit the number of deposits. But the DOS on builder deposits I think it's a real danger

Heeft gereageerd op "That's how it look..." met 🔥

Heeft gereageerd op "Or we fork the dep..." met 🤣

Reacted to "That's how it look..." with 🔥

We could look into a queue in the CL

Reacted to We could look into a... with "👍"

And have CL execution requests to keep arbitrary number of deposits up to a gas limit?

Reacted to "yeah the SSZ limit w..." with 👍

Replying to "We could look into a..." And we would raise/remove the SSZ limit.

Antwoord verzenden naar "I would like to as..." (ill doc this chat and move it to discord for async discussion)

Reacted to "(ill doc this chat a..." with 👍🏼

@Felix (Geth) I do not think raising the limit on the CL side is an issue for normal deposits, the problem is builder deposits as far as I can see, we should lower that limit in fact

Replying to "And have CL executio..." Yes, that’s right.

Damn that's so annoying, changing building rule

Replying to "And have CL executio..." I don’t love the idea of having another queue, but it’s sounding like the best solution to me right now.

Replying to "@Felix (Geth) I do n..." yeah I’d reduce the max from 8192 to 512

Replying to "@Felix (Geth) I do n..." probably less :) need to bench this for builder deposits

Replying to "@Felix (Geth) I do n..." we have had slots with over 600 deposits alraedy

slots with >251 deposits Slot Deposits 13509034 335 13210333 692 13210332 400 12357246 328 12258228 648 12151075 383 12151074 400 12148580 470

Lets switch out the contract

Replying to "And have CL executio..." But yeah, simpler the better. Idk. Limiting to 512 on both layers would indeed be the simple fix.

Deposits go into a queue in CL anyway, right?

8,192 deposits per block is 1.5MB of data

Replying to "Deposits go into a q..." there is no queue

Reacted to "there is no queue" with 👍

Replying to "Deposits go into a q..." There is no queue for builder deposits. We might want to have one

This should be easy to test no? Just fill up a block with 200M gas + 512 builder deposits to stress the machine

Reacted to "There is no queue fo..." with 👍

Reacted to This should be easy ... with "👍"

Heeft gereageerd op "This should be eas..." met 👍

can we spam devnet3 with lots of builder deposits per block?

Replying to "This should be easy ..." its more than the current ssz limit

Replying to "can we spam devnet3 ..." I can profile the impact

Replying to "can we spam devnet3 ..." No, don't break the network, create a new nft

Replying to "can we spam devnet3 ..." if we do 8193 deposits or more we gonna break

Replying to "can we spam devnet3 ..." I mean even 512

Replying to "can we spam devnet3 ..." every CL breaks

Replying to "can we spam devnet3 ..." (That seems like the concern)

Replying to "can we spam devnet3 ..." @terence we are able to handle about 1500 deposits with gloas

Replying to "can we spam devnet3 ..." Builder deposits?

Replying to "can we spam devnet3 ..." around 2000 its really struggling (at least on my local kt)

Reacted to "No, don't break the ..." with 🤣

Replying to "can we spam devnet3 ..." I’ve tested top up deposits, but don’t see how it would be diff than builder deposits

Replying to "can we spam devnet3 ..." can also try 500/1000/2000 builder deposits

Replying to "can we spam devnet3 ..." I think we aren't even batching signature verification in this case

+1, don’t think we should throw away that property (cheaply check includability) so easily

If we want to limit the amount of deposits should we not do this in the contract itself?

This is basically soft-fork situation proposed for the DAO fixup.

Replying to "can we spam devnet3 ..." getting to that point of exceedign the deposit limit already costs 8192 ETH.. driving a gas waste attack on this sounds extremely expensive

Heeft gereageerd op "This is basically ..." met 👍

Replying to "can we spam devnet3 ..." Ya but it seems to me builder deposits are more stressing than normal deposits so we should just test it like 512 and see what happens

but size can be verified statically

I think proposing a change to the deposit contract would have huge implications

We have it with blobs too but there it's nicely statical

Replying to "@Felix (Geth) I do n..." not builder deposits

Replying to "can we spam devnet3 ..." I don’t care about normal deposits. Only builder deposits

Replying to "I think proposing a ..." Definitely. I would be very against deploying a new deposit contract.

Replying to "but size can be veri..." And validity rules actually force you to not even have the chance to go over the limit, you can’t include a tx that could over the gas limit even if it doesn’t actually do it in practice

192.9 🥲

Yes

seems like this is complex enough to delay the decision to next call? or do we want to PFI the EIP as a stand-in for whatever mechanism we end up choosing?

I’d also be against a new deposit contract tbh. The second order effects for the ecosystem will be non-trivial and its not easy writing a contract that will be responsible for ~30%+ of all eth. At least not one we can write in a month.

Reacted to "I’d also be against ..." with 👍

Reacted to "I’d also be against ..." with 👍

yeah I believe the UX of changing the deposit contract is just too complex

money could be lost

and therefore will be lost

Reacted to "and therefore will b..." with 👍

Someone somewhere will make a mistake, money will be lost if we change it

Is there a limit for execution requests eip 7685 which could handle this on el side also, or is there no limit? (deposits are in exec rqs)

Could we make logs emitted by the deposit contract extra expensive? Add a special gas charge to `LOG` opcodes, but only in the deposit contract.

Replying to "Is there a limit for..." No

Reacted to "and therefore will b..." with 👍

Replying to "Is there a limit for..." Also this would run into the same issue as metering it in the el

one note on block building DOS: the issue is less bad now that we have the per-tx limit than it used to be. at least it is no longer free to do so, at worst an attacker can force the creation of under full blocks (and here at the cost of locking up ETH). pre the per-tx gas limit one could create txs that were not includable under such a cap

Heeft gereageerd op "Also this would ru..." met 👍

Reacted to "Could we make logs..." with 💯

Replying to "one note on block bu..." so I actually wouldn’t mind a simple cap so much here, at least for now

Replying to "Could we make logs e..." that would make depositing ETH quite expensive, seems not ideal

I want to propose formally essentially what Felix said about the problem of deposits. A two part fix: - Modify `apply_parent_payload...` to assert that there are no more than x deposits. So no block that builds on full is valid. - Modify `on_execution_payload` to not insert into forkchoice on these payloads.

This seems trivial to do on the CL and has no implications on the EL

nor on UX

and we just lower the limit, or can even have independent builder and normal validator limits

Replying to "Could we make logs e..." yeah, we should. And we should charge deposits 192 * 64 gas in addition. (charging 64 gas per byte) - deposit requests add 192b to the block.

I agree that changing the deposit contract might not be feasible. Not clear on the alternative though. Is it mempool guards?

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

https://ethereum-magicians.org/t/can-we-completely-remove-selfdestruct/28464

Replying to "Could we make logs e..." doesn't solve the problem though

Replying to "This seems trivial t..." Unless round robin to keep building those blocks by the EL since the txs are available to add?

Replying to "Could we make logs e..." The max of 8192 is just way too much for CLs

Replying to "This seems trivial t..." we count on builders to be smart

Replying to "This seems trivial t..." they won't like their blocks to be missed

Replying to "This seems trivial t..." Fair

Replying to "This seems trivial t..." And then only local block building could become a problem but we don’t expect that many deposits in the mempool?

Replying to "can we spam devnet3 ..." I’ve tested top up deposits, Ah, keep in mind for top up deposits, CL doesn’t even need to verify the signature

Account creation will be more expensive due to eip-8037 so this pattern to create temp contracts is now more expensive (in terms of gas units)

Replying to "This seems trivial t..." Can change local block building; just keeps it out of validation path

btw is anyone against removing self destruct, feels like everyone is on board lol

Replying to "This seems trivial t..." As long as someone is building the right blocks