AllCoreDevs - Testing #078

GM

Gm

I’d like to talk about syncing both here and ACD eventually, a few minutes at the end of the joint section

This was brought up in ACDC last week too I think

Reacted to "This was brought up in ACDC last week too I think" with 👍

Reacted to "This was brought up ..." with 👍

Reacted to "This was brought up ..." with 👍

How stable is (1) ePBS devnet and (2) bal-devnet-3?

Reacted to "This was brought up ..." with 👍

I’d like to avoid what Marius is proposing. I’d suggest we stick to having both. I think what we could do is launch both, and use glamsterdam-devnet-0 branches for both network.

Replying to "I’d like to avoid wh..." agree

Replying to "I’d like to avoid wh..." also agree

Next devnet introduces few disruptive changes to EIP-8037 so it makes sense to have it separate at bal-devnet4

Barnabas could you link the execution-apis PR pls?

Using bal-denvet-3 as the first glamsterdam devnet feels good to me. bal-devnet-4 might take a while to get stable, the 8037 changes are taking us a while to get right

Replying to "I’d like to avoid wh..." +1

Reacted to "Using bal-denvet-3 a..." with ➕

Reacted to "Using bal-denvet-3 a..." with ➕

If glam-devnet-0 is using bal-devnet-3, then I think we need bal-devnet-4 in order to complete development for 8037 and data EIPs

Reacted to "If glam-devnet-0 is ..." with ➕

Okay you all convinced me..

Reacted to "Okay you all convinc..." with 🥹

Reacted to "Okay you all convinc..." with 🥹

Reacted to "Okay you all convinced me.. " with 🥹

Reacted to "Using bal-denvet-3 a..." with ➕

Reacted to "Next devnet introduc..." with ❤️

Reacted to "Okay you all convinc..." with 🥹

Replying to "Next devnet introduc..." what are these changes then?

do we need #770 for epbs + bal

execution apis

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

Reacted to "Okay you all convinc..." with 🥹

we should have this in bal-devnet-4 pls ^

that way we could use same images

Replying to "https://github.com/e..." Yes we do

Replying to "https://github.com/e..." okay so we can't have glamsterdam devnet without it

Lol thats what I wanted to propose @Barnabas you just call it bal devnet 4, i would call it glamsterdam devnet 0

option 1: bal-devnet-3 + 770 = glam-devnet-0 option 2: bal-devnet-4 + 770 = glam-devnet-0

Reacted to "option 1: bal-devnet..." with 1️⃣

Replying to "Next devnet introduc..." Here is list: https://github.com/misilva73/evm-gas-repricings/blob/main/reports/eip-8037/spec_review_state_gas_accounting.md

Reacted to "option 1: bal-devnet..." with 2️⃣

Reacted to option 1: bal-devnet... with "2️⃣"

Reacted to "option 1: bal-devnet..." with 2️⃣

Reacted to "option 1: bal-devnet..." with 2️⃣

Reacted to "option 1: bal-devnet..." with 1️⃣

Replying to "option 1: bal-devnet..." Isn’t the issue with (1) is that if there is a bug in bal-devnet-3 that arises with epbs, then it’s a context switch since clients will be working on bal-devnet-4 changes?

as long as I can have 2 ELs done with devnet 4 + 770 by wed I’m happy to use devnet 4

Reacted to "as long as I can h..." with 🔥

Replying to "as long as I can hav..." can any other EL team volunteer?

Reacted to "as long as I can have 2 ELs done with devnet 4 + 770 by wed I’m happy to use devnet 4" with 🔥

Reacted to "as long as I can hav..." with 🔥

so are we removing the variable state cost?

or not

Replying to "so are we removing t..." pls no

full 8037!

We are keeping the variable cost

Reacted to "full 8037!" with 👍

Reacted to "full 8037!" with 👍

end of this week sounds more real

Reacted to "end of this week sou..." with 👍

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

Reacted to full 8037! with "👍"

Reacted to "full 8037!" with 👍

Reacted to "full 8037!" with 👍

Reacted to "end of this week sou..." with 👍

Reacted to "option 1: bal-devn..." with 2️⃣

Sorry people I have to drop early unexpected. Benchmark update for BALs: first runs are in https://benchmarkoor.core.ethpandaops.io/suites/bc398819d1ebc628. Only Geth and Besu have full + no batch io + sequential run modes, so request for other clients to add these modes ASAP.

We only support reorgs 90k blocks deep

Regardless of finalization

Replying to "We only support reor..." That’s absolutely fine, it’s fine to have implementations not supporting the full spec, every client in consensus cannot sync all blocks

Replying to "We only support reor..." would you need to resync for state in such a scenario?

Replying to "We only support reor..." or would you keep state diffs for that many blocks in case there's no finalization

Replying to "We only support reor..." Yes

Replying to "We only support reor..." We need to resync

How do the runs are scheduled ? I see a sawtooth pattern on mgas/s on besu side which doesn’t seem to be the case for Erigon .

Reacted to "full 8037!" with 👍

Replying to "Sorry people I have ..." I think you should ask on Discord Jochem is not here anymore

Reacted to "I think you should a..." with 👍

where is Francesco when we need him? [Full message cannot be displayed on this version]

Reacted to "where is Francesco w..." with 🥲

Reacted to "where is Francesco w..." with 🥲

Reacted to "where is Francesco w..." with 🥲

Reacted to "where is Francesco w..." with 🥲

Reacted to "where is Francesco w..." with 🥲

Reacted to "where is Francesco w..." with 🥲

Reacted to "where is Francesco w..." with 🥲

Reacted to "where is Francesco..." with 🥲

Should EL just return error (and we put this in spec), if they can’t reorg?

Yes that’s what should happen

And that’s it,

https://github.com/NethermindEth/nethermind/issues/9149

But the spec should say that you’re supposed to handle up to finalized

is it me, or it sounds like everyone is just agreeing? 😄

Is the proposed change to specify till finalized (caveats on implementation) vs the current specific static limit?

Reacted to "is it me, or it soun..." with 👍

We can just make the spec say that clients need to handle 2 block reorgs in the canonical chain

Reacted to "We can just make the..." with 👍🏼

Reacted to "We can just make the..." with 👍🏼

Reacted to "We can just make the..." with 👍🏼

whip.jpg

whip

Reacted to "whip.jpg" with 😂

Reacted to "whip.jpg" with 😂

Reacted to "whip.jpg" with 😂

Reacted to whip.jpg with "😂"

ship

Reacted to "whip.jpg" with 😂

whip

same thing

Reacted to "whip.jpg" with 😂

Reacted to whip.jpg with "😂"

Reacted to "whip.jpg" with 😂

Reacted to "whip.jpg" with 😂

CL that is syncing from scratch may have a finalized block way behind the EL has, this is why I am saying that if we introduce this then EL needs to be able to reorg back up to arbitrary depth

Reacted to "whip.jpg" with 😂

I replied here: https://discord.com/channels/595666850260713488/1493309049708744756/1493563229392338994

would geth ever fall back to snap sync if it has an initialized db?

No shouldn't do it

Replying to "would geth ever fall..." I think only if the state got corrupted but usually not

Yeah I don't think its unsafe

so everyone agrees?

lets move on?

yes

Replying to "CL that is syncing f..." The finalized from the EL would be the one that can’t be reforged, so it’s fine anyway I think

Reacted to "so everyone agrees?" with 👍

Need to think more into it

Replying to "I replied here: http..." that's the discussion thread

Do we need one @Barnabas ?

Do we need one @Justin Traglia

?

Where are the breakouts?

I never get to see one

@Parithosh Jayanthi can you add me?

Reacted to "@Parithosh Jayanthi can you add me?" with 👍

I am not seeing the breakout as well..

Same here, not seeing it this time

Can click “More” then “breakout rooms”