AllCoreDevs - Testing #080

tEsTiNg!!

gm

gm

gn

Let’s gooo Dan 😄

gm gm :)

Reacted to "gn" with 💤

Yes!

GM

Gm

more ppl than on ACDC 😂

T > E > C?

Reacted to "more ppl than on ACD..." with 🔥

ACDTTTTTTTTTTTTTTTTTTT!

Reacted to "T > E > C?" with 💯

Replying to "more ppl than on ACD..." the children yearn for the danceratopz

Reacted to "more ppl than on A..." with 🔥

Reacted to "more ppl than on A..." with 🔥

Reacted to "T > E > C?" with 🤔

Replying to "more ppl than on ACD..." Acdc? Never heard of it

Reacted to "more ppl than on ACDC 😂" with 🔥

Replying to "more ppl than on ACD..." Its where they demote you to once they get bored of you

Reacted to "T > E > C?" with 💯

https://github.com/ethereum/EIPs/pull/11540 Update EIP-7954: Raise contract code size to 64KiB

Ship it!! 🛳️

I see a wild Marius

Would this mean we need reprice account access?

Reacted to "Would this mean we n..." with 👀

Reacted to "Would this mean we n..." with 👀

We kind of should do both 32 and 64 tests and compare them

There’s a small caveat on 64KB if I recall correctly: Some EXT* benchmarks require contracts with maximum contract size to be pre-deployed to the network so we can query those, so we’d need to redeploy, it’s not difficult but just so we are aware

Replying to "There’s a small cave..." But there would be no such contract on mainnet before we upgrade.

Replying to "There’s a small cave..." I meant devnets, bloatnet, etc

glam-5 I think?

Reacted to "glam-5 I think?" with 👍

Replying to "There’s a small cave..." We can use our bench tooling to craft snapshots that have those contracts, so we can benchmark it

lets not change the devnet scope so last minute

Reacted to "lets not change the ..." with ➕

Reacted to "glam-5 I think?" with 👍

Glam 5 would be fine

Reacted to "We can use our bench..." with 👍🏼

Reacted to "glam-5 I think?" with 👍

Replying to "There’s a small cave..." Jochem and Carlos have been working on it

Reacted to "Jochem and Carlos ha..." with ❤️

Reacted to "Acdc? Never heard of it" with 😂

Reacted to "Its where they demote you to once they get bored of you" with 😂

Reacted to "T > E > C?" with 🤔

Reacted to "Jochem and Carlos ha..." with ❤️

Reacted to "lets not change the ..." with ➕

I agree with Marius, esp. the process part

param change :)

Replying to "param change :)" Its not just a parameter change

Should we target smaller amount to 48KiB, between 32 and 64

Replying to "Should we target sma..." Benchmark, ship the biggest safe of the three

Reacted to "Benchmark, ship the ..." with 👍

Has this EIP been CFI’d by ACD-E even?

going from 32 to 64, while keeping the same nr of contract code loaded into ram, we'd have to double the price, independently from access time. Is this possible at 300M gas for example?

Replying to "Has this EIP been CF..." yes

Replying to "Has this EIP been CF..." Yes sorry misleading agenda. It's just an update.

Reacted to "yes" with 👍🏼

Replying to "going from 32 to 64,..." We can test it

Reacted to "Yes sorry misleading..." with 👍🏼

I’d wait for benchmarks before we merge this in

Reacted to "I’d wait for benchma..." with 👍

Reacted to "I’d wait for benchma..." with 👍

Reacted to "I’d wait for benchma..." with 👍

Heeft gereageerd op "I’d wait for benc..." met 👍

Reacted to "I’d wait for benc..." with 👍

Replying to "going from 32 to 64,..." For our current in-memory cache we calculated that 64 is still fine - although on the higher side - we for example are not comfortable with 256 which was proposed some time back

Clients can create a 64kb specific branch

its whatever can we just move on lol

Remove SELFDESTRUCT brought up by Dragan in EthR&D: https://discord.com/channels/595666850260713488/745077610685661265/1504433379037417544

So do I merge it?

Replying to "going from 32 to 64,..." Is this checked even with higher gas limit, e.g. 400M or 500M? Also, what is the gas limit where clients might run into memory issues?

Reacted to "So do I merge it?" with 👍

Reacted to "So do I merge it?" with 👍

I worry this is too late, specially in a fork that is already super complex

won't we get (small but vocal?) community pushback?

I’d oppose adding a brand new EIP so late. Can’t we just repricce selfdestruct to insane high prices and do 0 refunds? Which basically the same as deprecated.

Reacted to "won't we get (small ..." with 👍🏼

Replying to "I’d oppose adding a ..." We have already not providing any refunds

Process wise is bad as is very far from finalised scope; upside is have so many selfdestruct bugs 😅

can we have a proper EIP and propose it for bogota?

Reacted to "can we have a prop..." with ➕

Reacted to "can we have a proper..." with 👍

Heeft gereageerd op "can we have a prop..." met ➕

Reacted to "Process wise is bad ..." with 👍

Heeft gereageerd op "can we have a prop..." met 👍

Reacted to "can we have a proper..." with 👍

Reacted to "can we have a proper..." with ➕

Reacted to "can we have a proper..." with 👍

Reacted to "can we have a proper..." with ➕

Reacted to "can we have a prop..." with 👍

Reacted to "Process wise is bad ..." with 👍

Replying to "can we have a prop..." we need a champion!

Replying to "can we have a proper..." dragan?

Reacted to "can we have a prop..." with 👍

Reacted to "dragan?" with 👑

Replying to "can we have a proper..." seen

Reacted to "can we have a proper..." with 👍

Reacted to "dragan?" with 👑

Reacted to "can we have a proper..." with ➕

Replying to "can we have a proper..." auto assigned responsibilities 😂

Reacted to "can we have a proper EIP and propose it for bogota?" with ➕

Would be great to get eth/71 merged: https://github.com/ethereum/devp2p/pull/264

Reacted to "dragan?" with 👑

FYI there is a new consensus-specs release: https://github.com/ethereum/consensus-specs/releases/tag/v1.7.0-alpha.8

We saw the same results as Stefan

Replying to "I’d oppose adding a brand new EIP so late. Can’t we just repricce selfdestruct to insane high prices and do 0 refunds? Which basically the same as deprecated." Main benefit is no need to test its connections to any EIP. So gas increase doesn't fix this.

Reacted to "We saw the same re..." with 🚀

They need to fix bugs for bal-devnet-7

we could use devnet (and benchmarks) for further optimization

we can launch without geth tho

Reacted to "can we have a proper EIP and propose it for bogota?" with 👍

Reacted to "we can launch withou..." with 👍

Reacted to "we can launch with..." with 👍

working on release notes just now: https://github.com/ethereum/execution-specs/releases/tag/tests-bal%40v7.2.0

Reacted to "They need to fix bug..." with 👍

Reacted to "They need to fix bug..." with 👍

Replying to "Would be great to ge..." This one :)

Reacted to "Would be great to get eth/71 merged: https://github.com/ethereum/devp2p/pull/264" with ❤️

Reacted to "Would be great to ge..." with ❤️

Reacted to "working on release..." with 🧪

Reacted to "working on release n..." with 🧪

Reacted to "we can launch withou..." with 👍

re: Maria’s point, this also is blocking CL testing since even things like the attestation deadline depends on this

For clients, let's sync on how far we're are on the post-state root optimization here: https://discord.com/channels/595666850260713488/1364000387195076608/1505940382884691999

And we may need to work on out optimization as well

Reacted to "For clients, let's s..." with 👍

Reacted to "They need to fix bug..." with 👍

Reacted to "working on release n..." with 🧪

alpha 8 + https://github.com/ethereum/execution-apis/pull/796

We are in charge of the gas limit!

Reacted to "We are in charge of ..." with 🔥

Reacted to "We are in charge o..." with 🔥

Reacted to "We are in charge of the gas limit!" with 🔥

Reacted to "We are in charge of ..." with 🔥

No more depending on EL devs, this was all a plot to take control

Reacted to "We are in charge of ..." with 🔥

Reacted to "No more depending on EL devs, this was all a plot to take control" with 🥲

Reacted to "No more depending on..." with 😂

Reacted to "No more depending on..." with 😂

Reacted to "We are in charge of ..." with 🔥

Reacted to "No more depending on..." with 🥲

CLs need it now because builder API

all the CLs already have this

Reacted to "We are in charge of ..." with 🔥

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

Reacted to "We are in charge of ..." with 🔥

Today?

Prysm is ready

But we want to merge more PRs to main branch first

Reacted to "Prysm is ready" with 🚢

for Teku, we would need few days

We should be ready by end of day

Reacted to "for Teku, we would n..." with 👍

Reacted to "We should be ready b..." with 🚢

Reacted to "We should be ready b..." with 🚢

Reacted to "We should be ready b..." with 🚢

Reacted to "Prysm is ready" with 🚢

Reacted to "Prysm is ready" with 🚢

Reacted to "We should be ready b..." with 🚢

For lodestar, we have a draft branch for it already, need to polish a little bit and merge PRs to trunk

But thats only for a limit of 300M

If we want to go further, we would need to reprice

And with 3 seconds execution time window

I hoped for 180MGas/s instead of 100M (60Mgas/s on 3 cores)

Reacted to "No more depending ..." with 😂

Replying to "I hoped for 180MGas/..." I think that is too aggressive. If we target 300M for glamsterdam and 5/6s execution from ePBS, doing 100Mgas/s is more than enough

Replying to "I hoped for 180MGas/..." I agree with Maria, we should target 100M/s and try to push the limits on that after the fork, we can probably do up to 400—500 safely

I would move it to glam-devnet-5

Reacted to "I would move it to g..." with 👍🏼

Eip-8246 spec and test: https://github.com/ethereum/execution-specs/pull/2842

https://github.com/ethereum/beacon-APIs/pull/580

Reacted to "Eip-8246 spec and te..." with ❤️

Reacted to "Eip-8246 spec and te..." with ❤️

Bharath's builder-specs PR: https://github.com/ethereum/builder-specs/pull/144

Brought up during ACD-C, might be worth discussing in ACD-T to get a decision. Which of these two REST-SSZ Engine-API proposals to go with: - https://github.com/ethereum/execution-apis/pull/793 - https://github.com/ethereum/execution-apis/pull/764

Replying to "Bharath's builder-sp..." Have raised my point in discord too: https://discord.com/channels/595666850260713488/710831784991916072/1505941835091021966 TLDR; I think we can move definitions to builder-boost-factor etc to the builder-spec

Nethermind and Erigon has merged in 764 into their trunk branches already

Brought up during ACD-C, might be worth discussing in ACD-T to get a decision. Which of these two REST-SSZ Engine-API proposals to go with: - https://github.com/ethereum/execution-apis/pull/793 - https://github.com/ethereum/execution-apis/pull/764" with ❤️

Brought ..." Jacek posted this on acd: https://discord.com/channels/595666850260713488/745077610685661265/1504526689533690018

I’d also expect CL teams to chime in, as they historically have more ssz background

Brought ..." tldr: reuse base beacon api structure for simplicity

"my ai is better than your ai"

Reacted to ""my ai is better tha..." with 😂

Replying to ""my ai is better t..." taste dif

Reacted to ""my ai is better t..." with 😂

Reacted to "Barnabas has sent yo..." with 😆

Reacted to ""my ai is better than your ai"" with 😂

Reacted to "Screenshot2026_05_..." with 😄

Reacted to "Screenshot2026_05_..." with 😆

Heeft gereageerd op "Screenshot2026_05_..." met 😆

Reacted to "Screenshot2026_05_18_165936.jpg" with 😆

Reacted to "Screenshot2026_05_18_165936.jpg" with 😆

Marius says he has better AI than Barnabas who says he has better AI than Guilio

Reacted to "Marius says he has b..." with 😂

Reacted to "Marius says he has better AI than Barnabas who says he has better AI than Guilio" with 😂

Reacted to "Marius says he has..." with 😂

Reacted to "Marius says he has b..." with 😂

Reacted to ""my ai is better tha..." with 😂

Reacted to "Screenshot2026_05_18_165936.jpg" with 😆

Reacted to "Marius says he has b..." with 😂

Reacted to "Screenshot2026_05_18_165936.jpg" with 😆

Reacted to "Marius says he has..." with 😂

Reacted to ""my ai is better tha..." with 😂

Reacted to "Marius says he has b..." with 😂

Reacted to "Screenshot2026_05_18_165936.jpg" with 🥹

Who of you added “make no mistakes”?

Reacted to "Screenshot2026_05_..." with 😆

Heeft gereageerd op "Marius says he has..." met 😂

Ask your ai which one is better

Reacted to ""my ai is better t..." with 😂

Reacted to "Screenshot2026_05_..." with 😆

I'm fine with routing, not sure about error codes, might be also simple, but need to understand it better, probably easy to adapt

Why is it only one opportunity?

its a backwards compatible change

Reacted to "photo_604632495969..." with 😂

Reacted to "photo_604632495969..." with 😂

Replying to "photo_6046324959698685700_y.jpg" original source of image: my claude.

Replying to "Why is it only one..." Changing standards between EL and CLs are high friction low importance

Reacted to "photo_6046324959698685700_y.jpg" with 😂

Reacted to "photo_6046324959698685700_y.jpg" with 😂

Replying to "its a backwards co..." makes it worse

Reacted to "Changing standards b..." with ➕

Reacted to "Changing standards between EL and CLs are high friction low importance" with ➕

Replying to "photo_604632495969..." Getting mogged by your own ai

Reacted to "photo_6046324959698685700_y.jpg" with 😂

I just want a resolution

lol

Reacted to "Changing standards..." with ➕

can we decide on ACDE?

Reacted to "Screenshot2026_05_18_165936.jpg" with 😆

Reacted to "can we decide on ACD..." with 👍