AllCoreDevs - Consensus #178

gm

Gm

gm

Happy ACD day!

gm

gm

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

https://github.com/ethereum/execution-apis/pull/774

eth/72 also plz optionally

what is eth/72? that we need to do something?

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

ahh alright, that's fine for us

when blob devnet 0 is scheduled?

unfortunately can’t stay for most of the call, just wanted to drop in for the vibes :-) wishing you all a wonderful call!

Reacted to "unfortunately can’t ..." with ❤️

Reacted to "unfortunately can’t ..." with ❤️

Replying to "when blob devnet 0 i..." it’s already running

Reacted to "unfortunately can’t stay for most of the call, just wanted to drop in for the vibes :-) wishing you all a wonderful call!" with ❤️

Reacted to unfortunately can’t ... with "❤️"

Reacted to "unfortunately can’t ..." with ❤️

Reacted to "unfortunately can’t ..." with ❤️

I’m sorry what are we discussing ?

Replying to "I’m sorry what are w..." Eth/72 and the PR here: https://github.com/ethereum/execution-apis/pull/774

I think eth/72 - sparse blob pool is still in flight in terms of spec?

Reacted to "unfortunately can’t ..." with ❤️

bal-devnet-7 has eth/70 and eth/71 as a requirement fyi

Reacted to "bal-devnet-7 has eth..." with 👍

Replying to "I think eth/72 - spa..." is it?

Reacted to bal-devnet-7 has eth... with "👍"

Replying to "I think eth/72 - spa..." IDK @FLCL recent comments to me was that it is not final

Reacted to "bal-devnet-7 has eth/70 and eth/71 as a requirement fyi" with 👍

Replying to "I think eth/72 - spa..." He leads this from our side

Reacted to "bal-devnet-7 has eth..." with 👍

Replying to "I think eth/72 - spa..." we do have some implementation

Reacted to "bal-devnet-7 has eth..." with 👍

FYI Sparse blobpool latest EIP update is here (it reflects reflect execution API 774 changes) https://github.com/ethereum/EIPs/pull/11444 Please check that

Reacted to "Screenshot2026_05_14_100801.jpg" with 👍

+1

Imho it can't be named exactly frozen unless we widely test it and in big networks across implementations

Replying to "I think eth/72 - spa..." optionally is fine as early testing, but not mandatory

I want that and also the bid changes

fcu4 with targetgas

Replying to "I think eth/72 - spa..." and try to attack it also maybe

ideally we want that decided today and it should be very easy on the EL side

PR we are discussing: https://github.com/ethereum/consensus-specs/pull/5235

Btw, that's the eth/71 PR for devp2p. Some have reviewed it already, felix is also on it, but would then be great to have a few more eyes on it and get it merged: https://github.com/ethereum/devp2p/pull/264

https://github.com/ethereum/consensus-specs/pull/5236

Target here does not mean limit / 2 like today right? It literally means the limit

This needs to be in that devnet too

@terence it's not gas target is gas limit target

or rather target gas limit

instead of gas target

suggested_gas_limit?

or preferred_gas_limit?

TARGET_GAS_LIMIT

Reacted to "TARGET_GAS_LIMIT" with 👍

Reacted to "TARGET_GAS_LIMIT" with 👍

Reacted to "TARGET_GAS_LIMIT" with 👍

Reacted to "TARGET_GAS_LIMIT" with 👍

Reacted to "TARGET_GAS_LIMIT" with 👍

Reacted to "TARGET_GAS_LIMIT" with 👍

silence = agreement 😂

What happens if there’s no configured target in the CL? Does it just send zero?

thats how decisions made for all ELs

Reacted to "silence = agreemen..." with ➕

client’s default?

Replying to "Target here does no..." Right, it's more "target to push the gas limit towards"

all clients have a default

today we send it to the builder

Might want to quickly mention these two: https://github.com/ethereum/consensus-specs/pull/5223 https://github.com/ethereum/consensus-specs/pull/5227

Set your defaults; 300M for reference ;)

Reacted to "Set your defaults; 300M for reference ;)" with ❤️

Reacted to "Set your defaults; 3..." with 🔥

Reacted to "Set your defaults; 3..." with 👀

CL devs can approve here https://github.com/ethereum/consensus-specs/pull/5235 EL devs can approve here https://github.com/ethereum/execution-apis/pull/796

Replying to "CL devs can approve ..." https://github.com/ethereum/consensus-specs/pull/5223

Replying to "CL devs can approve ..." https://github.com/ethereum/consensus-specs/pull/5236

All CLs need to introduce a brand new flag right?

no?

we already have this

from a user pov, nothing changes either

Reacted to "from a user pov, not..." with 👍

When devnet4?

should be trivial on our part

Reacted to "When devnet4?" with ➕

Replying to "When devnet4?" EOW?

Replying to "When devnet4?" Sure

Reacted to "Sure" with 🚢

Reacted to "Sure" with 🎉

Replying to "When devnet4?" But merge the spec prs first

Reacted to "Sure" with 🚢

Reacted to "Sure" with 🚢

Reacted to "But merge the spec p..." with 😂

Could someone post the dual deadline PR?

which pr are you talking about potuz?

https://github.com/ethereum/consensus-specs/pull/5212

Reacted to "But merge the spec prs first" with 😂

Replying to "When devnet4?" what el branch are you using? bal-devnet-7 launches next monday right?

https://github.com/ethereum/consensus-specs/pull/5210

They sound reasonable to me, but we need other clients to weigh in.

@Potuz I like the idea of using the same deadlines initially, then tweaking later. Could you make this change?

lgtm

General skepicism of merging a mechanism specifically designed to be disabled

(dual deadlines)

would we need two PRs? then? I'd ask if we're fine with 6 seconds already @Justin Traglia cause we're mostly sending immediately now anyway

I wanted to reply to Dustin lol :)

lgtm

The EL needs a number for setting the appropriate gas limit. So CLs agreeing on an execution time ELs are guaranteed is necessary, so specing it makes sense, even if it's not a consensus rule.

Reacted to "Sure" with 🚢

Replying to "@Potuz I like the id..." Not a strong opinion on this btw. I just thought it would give clients more time to implement this, since it wouldn’t block the new devnet.

We usually go from spec to tooling

Reacted to "We usually go from s..." with 👍

@Toni Wahrstätter I think the EL should really be working with 6 seconds execution for benches

this is a very reasonable target as discussed in Svalbard

we need to make sure that all clients do fit in that though

alpha 8 by tomorrow?

Replying to "alpha 8 by tomorrow?" As soon as possible 🙂

Reacted to @Toni Wahrstätter I ... with "🙏"

Reacted to "As soon as possible ..." with 🚢

https://github.com/ethereum/consensus-specs/pull/5227

Replying to "@Toni Wahrstätter I ..." The question is that with this we should also be working with a max of 2 seconds for broadcasting at the moment

Replying to "@Toni Wahrstätter I ..." So we would need to make sure of these boundaries and check if this is reasonable

The nice thing is you can delete these code after the fork in subsequent release

Reacted to "The nice thing is yo..." with 👍

Reacted to "The nice thing is yo..." with 👍

Replying to "@Toni Wahrstätter I ..." Yeah, we should make sure to have "enough" time for propagation and would then set the gas limit based on the worst-case execution time ELs have

Replying to "The nice thing is yo..." I think it's useful anyway right? we just keep the pending queue with a prevalidated sig-checks and then processing pending deposits becomes faster

Replying to "@Toni Wahrstätter I ..." We are working on this on the repricing-side too

Reacted to "We are working on th..." with 👏

Replying to "@Toni Wahrstätter I ..." Together with the P2P team. Hopefully we get some results soon. Already started at: https://github.com/ethpandaops/benchmarkoor/pull/236

Can discuss 5 scoping in ACDT

I would prefer we stop adding features and we complete implementations? dealing with full blob propagation and start actually testing forkchoice?

Reacted to "Can discuss 5 scopin..." with 👍

we haven't done a single test of attestation accuracy and forkchoice testing

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

The only EL solution is to change the deposit contract. So this should be solved on the CL somehow

One issue about deposit time is that most of the effort for Pectra was for hypothetical ZK VMs that want to prove beacon STF. Why did we reduce the number of attestations just to now make it way worse than it ever was? Just add a queue haha

we don’t need churn limits, just a signature ratelimit

queue doesn’t solve the 8193 overflow issue

Replying to "One issue about depo..." the overflow issue is just pending 7688

Replying to "One issue about depo..." *8193

Reacted to "*8193" with 👍

Replying to "One issue about depo..." like, set gas limit to a way that avoids the problem, then go 7688

Reacted to "As soon as possible ..." with 🚢

Reacted to "The nice thing is yo..." with 👍

we probably want these benches from everyone

prysm/teku should be ready, wanna hear from others

glamsterdam-denvet-3-deposits

yeah we can do that

where are clients on 7688? can add your branch to kurtosis https://github.com/ethereum/consensus-specs/pull/4630#issuecomment-4377125436

https://github.com/ethereum/execution-apis/pull/793 https://github.com/ethereum/execution-apis/pull/764

can you describe the difference in the two PRs? why are they two different proposals?

Replying to "can you describe the..." Marius wants to refactor the whole engine api

we strongly support merging this. And I'll switch out of geth unless they implement this :)

We need help from a CL, a solid implementation we could test against

Reacted to "We need help from a ..." with 💯

we support all stuff like progressive containers also

Replying to "we strongly support ..." prysm implementation wen?

we support both SSZ and JSON at the same time

Replying to "we strongly support ..." there's a PR by Giulio under review, not sure of the status of that, seems that Nethermind opened a PR on top of that PR so it may be difficult to review and may be faster if we work this from scratch or get Nethermind + Erigon to agree to merge first

Reacted to "there's a PR by Giul..." with 👍

This isn't urgent so we can wait for discusion to ACDT and ACDE

What was the question?

Replying to "What was the questio..." how married are you to https://github.com/ethereum/execution-apis/pull/793 ?

Replying to "can you describe t..." yes it could use some refactoring

I don’t think there is a team position

Replying to "can you describe the..." could we do this as a two step process tho?

Replying to "can you describe the..." lets get ssz in first, then do the refactor?

Reacted to "I don’t think there ..." with 👍

But will discuss internally before ACDT

Replying to "can you describe t..." a lot of the SSZ urgency seems to be due to slow JSON parsers

Replying to "can you describe the..." I think jacek also wanted to refactor?

https://github.com/ethp2p/ethp2p/pull/5

Replying to "can you describe t..." yeah

Reacted to "But will discuss int..." with 👍

let's get rid entirely of IHAVE IWANT for attestations please

Replying to "can you describe the..." We thought we had a very fast JSON RPC parser and in our synthetic testing routing though REST + SSZ is still 5x-10x faster (!)

Replying to "can you describe the..." yeah JSON parsing is the biggest bottleneck by far for every EL / CLs

Replying to "can you describe the..." and we have AVX optimized json parser (numbers are from AVX-256, on AVX-512 path it might be only 2.5x-5x faster)

whats the rollout plan for ethp2p? Is the idea to have ethp2p implemented by h* and cut over to it from libp2p at the fork transition, or do we plan to have both implemented and both running for a fork?

but good AVX-512 in only on Zen 5 CPU's

Replying to "can you describe the..." Json also has approx 2x overhead on payload size because it encodes bytes as hex nibbles which impacts transport

Reacted to "whats the rollout ..." with 👍

Reacted to "Json also has approx..." with 👍

Time boxing to 5mins from now. Please keep your questions ready!

I have like 10 😁

Reacted to "I have like 10 😁" with 🤣

How does this affect the fast finality roadmap?

Replying to "How does this affect..." Yes, this is useful/necessary.

Reacted to "I have like 10 😁" with 🤣

As an incremental step, or even long term? MEaning, 4-slot rounds could be 2-slot rounds or 128K attester cap could be 256K attester cap?

Reacted to "Yes, this is usefu..." with 👍

Replying to "How does this affect..." I'm not thinking in terms of attester caps right now. This would allow finality voting rounds to be shortened.

Reacted to "I'm not thinking i..." with 👍

Replying to "How does this affe..." U mean currently, from 13 mins to ~6.5?

ethp2p [Full message cannot be displayed on this version]

Replying to "How does this affect..." Yes, and maybe better once we have decoupled consensus - there is more space in the slot for finality votes.

Reacted to "Yes, and maybe bet..." with 👍

ooooor we could just simply deprecate and exit 0x01 vals :D

Reacted to "ethp2p" with 😂

Replying to "ooooor we could just..." oh

https://github.com/frisitano/EIPs/blob/feat/eip8025/EIPS/eip-8025.md

EIP8025 Slides: https://frisitano.github.io/slides/presentations/eip8025-acdc-proposal-2026-05-14/index.html#1 EIP: https://github.com/frisitano/EIPs/blob/feat/eip8025/EIPS/eip-8025.md EIP PR: https://github.com/ethereum/EIPs/pull/11604

Replying to "ooooor we could just..." sounds like I need to write an EIP

Reacted to "I'm not thinking in ..." with 👍

Timeboxing to 15 mins, please have questions prepared

Reacted to "ooooor we could just..." with 😅

Replying to "ooooor we could just..." So we leave the poor 0x00 Vals alone right?

Replying to "ooooor we could just..." there aren’t too many of those

Replying to "ooooor we could just..." did we ping Vitalik to change his 😁?

if it’s optional does it need to be in a hardfork?

Reacted to "if it’s optional doe..." with 👍

Replying to "ooooor we could just..." just straight up rug

Reacted to "if it’s optional ..." with 👍

just ship it

Reacted to "if it’s optional does it need to be in a hardfork?" with 👍

(optionally)

Replying to "if it’s optional doe..." I think the main question is how comfortable are we allowing such nodes attesting

Reacted to "I think the main que..." with 👀

Replying to "if it’s optional does it need to be in a hardfork?" how comfortable are you?

In the slides soon we'll touch a bit on this OP question.

Replying to "if it’s optional doe..." zero, I need to study to try to understand and verify the validity of the verifier :)

Reacted to "zero, I need to study to try to understand and verify the validity of the verifier :)" with 💕

Replying to "if it’s optional doe..." I mean optional proofs excplictly say that you still need to run an EL to attest

Reacted to "zero, I need to stud..." with 💕

Replying to "if it’s optional doe..." question is how many people are capable of vouching for this today

Reacted to "(optionally)" with 😄

Reacted to "(optionally)" with 😄

Replying to "if it’s optional doe..." @Barnabas if this is optional for full nodes that's more than fine to me. In some sense even not verifying the payload at all is kinda reasonable for a full node that trusts validators.

Replying to "if it’s optional doe..." so verifying the proof is a net positive

Reacted to "(optionally)" with 😄

Replying to "if it’s optional doe..." but shis slide says "validators"

Replying to "if it’s optional doe..." full nodes can just run optimisic mode already no?

Reacted to "In the slides soon w..." with 👍

Replying to "if it’s optional doe..." The proof verification is an additional work that you'd do if you opt-in. When the proof and the EL disagree, you follow what the EL says.

Replying to "if it’s optional doe..." https://ethereum.github.io/consensus-specs/_features/eip8025/beacon-chain/

Replying to "if it’s optional doe..." so is it just for testing?

Replying to "if it’s optional doe..." Mainly for metrics AFAIU

Reacted to "Mainly for metrics A..." with 👍

Replying to "if it’s optional doe..." I argue to make it highly recommended, but not needed. https://github.com/ethereum/consensus-specs/pull/5151

Is the PR based on Gloas or Fulu?

Fulu afaik

Replying to "Is the PR based on G..." Fulu. People were waiting for Glam to be stablized.

Reacted to "Fulu. People were wa..." with 💯

Reacted to "Fulu. People were wa..." with 💯

can you hear me?

Would it need everyone to propagate proofs or only those validators that want to opt-in?

7 mins left for the topic and it’d be nice to do questions too🙂

Replying to "can you hear me?" no

Replying to "Is the PR based on G..." yeah just looking, Gloas should make it better right?

Replying to "Is the PR based on G..." cause you get more time to broadcast

Reacted to "yeah just looking, Gloas should make it better right?" with 👍

Replying to "Would it need everyo..." Only those that opt in

Reacted to Only those that opt ... with "👍"

Replying to "Is the PR based on G..." Of course, but I don't think there will be any significant change other than proof propagation time. The main change is verifying execution proof after calling newPayload.

Replying to "Is the PR based on G..." yeah the spec shouldn't change much I assume, but you get about 9 seconds instead of 2

Reacted to "Only those that opt ..." with 👍

Could we mostly stick to CL implications for this call?

Replying to "Is the PR based on G..." single 5090 does proof generation in about 6s now with 1tx

Replying to "Is the PR based on G..." I'm talking about attesters

Replying to "Is the PR based on G..." The builder will provide the proofs in the future

Replying to "Is the PR based on G..." assuming we gonna have mandatory proofs

Replying to "Could we mostly stic..." this is useful though

Yeah I can add some more time for the topic today, I doubt we can cover all questions even then

to understand the eip, please read the eip - ignacio, 2026

Reacted to "to understand the ..." with 😄

Reacted to "to understand the ei..." with 😎

Reacted to "to understand the ei..." with 😄

Reacted to "to understand the ei..." with 😄

Reacted to "to understand the eip, please read the eip - ignacio, 2026" with 😄

Reacted to to understand the ei... with "😎"

Hat auf "to understand the ei..." mit 😄 reagiert

Reacted to "assuming we gonna have mandatory proofs" with 😁

Replying to "Is the PR based on Gloas or Fulu?" i hope we can get mandatory proofs for rollups at least :p

Reacted to "to understand the ..." with 😎

Reacted to "to understand the eip, please read the eip - ignacio, 2026" with 😄

Replying to "Is the PR based on G..." what does this mean?

can we standardize the name? is it zkevm or zkvm?

Reacted to "to understand the eip, please read the eip - ignacio, 2026" with 😎

Reacted to "to understand the ei..." with 😄

Reacted to "can we standardize the name? is it zkevm or zkvm?" with 🤪

Replying to "Is the PR based on G..." We'd do it to test things, but on standard nodes, and not on validators, right? Otherwises, if they have to download and verify the proof + reexecute, they might attest too late?

Reacted to "can we standardize the name? is it zkevm or zkvm?" with 🤪

Replying to "Is the PR based on Gloas or Fulu?" native rollups / native proof verification @Potuz

Reacted to "to understand the ei..." with 😄

i didn’t catch why it needs protocol changes for an optional mechanism

can we make it explicit that vals that opt in still need the EL to run? And that also validators should not wait to the proof verification to attest?

Reacted to "i hope we can get ma..." with 👍

its currently in the spec yes (first part, not sure about the second)

Replying to "can we standardize..." zkevm = zkvm + guest program. team name is zkevm, effort is zkevm, some things like certain standards are properly zkvm. note i have not capitalized anything😉

Replying to "can we make it expli..." it seems to be locking on newPayload

But they still engage in propagating proofs, which might slow down blob + payload download and upload. No validator should use it, only non-validating nodes

thanks!

Reacted to "zkevm = zkvm + guest..." with ❤️

Replying to "i didn’t catch why it needs protocol changes for an optional mechanism" maybe it makes sense to make an option mandatory to be provided? (speculating)

Replying to "can we make it expli..." How does LH prototype handle this? @Francesco Risitano

Reacted to "can we standardize the name? is it zkevm or zkvm?" with 🤪

Reacted to "zkevm = zkvm + guest program. team name is zkevm, effort is zkevm, some things like certain standards are properly zkvm. note i have not capitalized anything😉" with ❤️

thanks that was the reason that I was asking for newPayload

Reacted to "thanks!" with 🙏