AllCoreDevs - Testing #097

Lol. Gm.

gm gm

<https://github.com/ethereum/pm/issues/2225>

GM

gm!

gm

Gm Dan!

gm

gm gn

📋 ACDT #97 agenda: <https://github.com/ethereum/pm/issues/2225>

gm

we're getting bids from them

but not tested much as they were plenty of bugs early on

⏳ Reduce compute_min_epochs_for_block_requests() after EIP-8061? (jihoonsong) EIP-8061: <https://eips.ethereum.org/EIPS/eip-8061#configuration> Gloas WSP table: <https://github.com/ethereum/consensus-specs/pull/5629> EIP-8383 proposal, fixed 8192 epochs: <https://github.com/ethereum/EIPs/pull/12188> Thread: <https://discord.com/channels/595666850260713488/1549841282652971111> TLDR: the serving window is still 33024 epochs (about 5 months) while the WSP it was derived from has halved. What should do with the serving window in Glamsterdam: - Keep 33024, - Reduce to 14299 (EIP-8061; same derivation), - Reduce to 8192 (EIP-8383, PFI for Hegota).

We would only need such large windows under non-finality? Otherwise check pointa are much fresher?

Replying to "We would only need s..." clients should never prune non-finalized blocks

Replying to "We would only need s..." Right, so yes?

Replying to "We would only need s..." no this retention is for happy path sync if your node is offline for a while

Replying to "We would only need s..." I see! Offline but not requesting a trusted checkpoint?

Replying to "We would only need s..." yeah and depending on what safety decay you use or think is safe

the cl retention determines the el retention, though?

we can make a recommendation for ACD?

Replying to "we can make a recomm..." ACDE or ACDC or both?

Replying to "we can make a recomm..." I thought ACDT is also an ACD call though lol

BAL retention should match or else deduping payloads becomes fraught

💾 EIP-7928 BAL retention, 3533 -> 33024 epochs (nflaig) Update EIP-7928: align BAL retention with the history expiry window: - <https://github.com/ethereum/EIPs/pull/12347> EIP-4444 HISTORY_PRUNE_EPOCHS for comparison: - <https://eips.ethereum.org/EIPS/eip-4444>

This is at 10% safety decay?

can snap sync also to catch up, right?

Whats the number for archive nodes?

Replying to "can snap sync also t..." We need BAL for snapsync healing, but could be some days only. In general it take less than a day to do a snapsync

Replying to "Whats the number for..." If its the max safety decay number (5 months), then this seems arbitrary

Replying to "can snap sync also t..." Snap anchors on the head block and we will def have the bal for head-64

Replying to "can snap sync also t..." We are also thinking to use BAL for PBT migration and to update the snapshot every n blocks depending on the BAL retention period @Kevaundray Wedderburn

Yep as tony said, we don't prune them at all atm

snap sync

Snap sync won’t be that old?

We need it for healing

We download using a pivot and we need to fix all the changes from the pivot block to the next one

I don't think we want to force checkpoint sync? We want offline nodes to catch up via forward sync?

I don't think we should force the spec in that direction, checkpoint sync is not needed if last state is safe to sync from

Reacted to "I don't think we should force the spec in that direction, checkpoint sync is not needed if last state is safe to sync from" with 👍

How is trusting a state checkpoint different from trusting a state diff (BAL)?

🗓️ Glamsterdam testnet quick check Sepolia Oct 6 (epoch 353024, 13:53:36 UTC), client releases due Sep 29: <https://github.com/ethereum/pm/pull/2205> and <https://github.com/ethereum/EIPs/pull/12355> Please review if you haven't, Schedule Sepolia Glamsterdam activation: <https://github.com/eth-clients/sepolia/pull/126>

ACDC #187 recap (Hoodi tentatively Oct 27, go/no-go Oct 8): <https://forkcast.org/calls/acdc/187/> Sepolia shadow fork date?

Reacted to "I don't think we sho..." with 👍

Łukasz Rozmej: On a decent machine we should be able to process 2 weeks of blocks faster than we would snap sync (~1h) fresh head. On EL there is a problem of continuity of state, we cannot snap sync past state, only get it through processing.

I wouldn't block testnets for it

Continuing on this thread here: https://discord.com/channels/595666850260713488/1549841282652971111

Reacted to "I wouldn't block testnets for it" with 👍

🚀 Preliminary Hegota devnet schedule (spencer-tb) frames-devnet-0 exists (lightclient), frames test releases: <https://github.com/ethereum/execution-specs/releases>

Eip8037 was worth it! 🙂

Reacted to "Eip8037 was worth it..." with 💙

Reacted to "Eip8037 was worth ..." with 👍

Reacted to "Eip8037 was worth it! 🙂" with 💙

Reacted to "Eip8037 was worth it! 🙂" with ♥️

Reacted to "Eip8037 was worth it..." with ⛽

when should we do a frames decent 0? the ethers has been going for a while now, i think we could get started with frames only devnet then oct work on frames x focus

Yeah sorry a few of us were on vacation and we’re just catching up 🙂 Happy to chat on the thread!

eip-8253 on devnet-0?

Reacted to "Yeah sorry a few of us were on vacation and we’re just catching up 🙂 Happy to chat on the thread!" with ❤️

Reacted to "Yeah sorry a few of ..." with ❤️

Replying to "Yeah sorry a few of us were on vacation and we’re just catching up 🙂 Happy to chat on the thread!" no worries :)

Replying to "when should we do a ..." IMO frames only and focil only at the beginning

Replying to "when should we do a frames decent 0? the ethers has been going for a while now, i think we could get started with frames only devnet then oct work on frames x focus" sorry had a lot of auto corrects on this 😂

+1 Stefan, it seems that AA and FOCIL only interact abstractly through the Engine API, so on the CL side at least, it would be much easier to test FOCIL alone without waiting for Frame complete branches

Epbs and BALs had not much interaction, almost 0. This is different for focil and frames, esp wrt mempool.

Reacted to "sorry had a lot of a..." with 👍

Replying to "when should we do a frames decent 0? the ethers has been going for a while now, i think we could get started with frames only devnet then oct work on frames x focus" *devnet *ethrex

I wouldn’t delay starting a devnet if there are enough implementations ready. For ELs we have 3 clients with frame transactions implementations already, while for FOCIL we are still trying to make 2 CLs agree

Reacted to "I wouldn’t delay starting a devnet if there are enough implementations ready. For ELs we have 3 clients with frame transactions implementations already, while for FOCIL we are still trying to make 2 CLs agree" with 👍

Reacted to "I wouldn’t delay starting a devnet if there are enough implementations ready. For ELs we have 3 clients with frame transactions implementations already, while for FOCIL we are still trying to make 2 CLs agree" with 👍

Reacted to "I wouldn’t delay starting a devnet if there are enough implementations ready. For ELs we have 3 clients with frame transactions implementations already, while for FOCIL we are still trying to make 2 CLs agree" with 👍

Reacted to "I wouldn’t delay starting a devnet if there are enough implementations ready. For ELs we have 3 clients with frame transactions implementations already, while for FOCIL we are still trying to make 2 CLs agree" with 👍

Reacted to "I wouldn’t delay sta..." with 👍

📋 CL Breakout: <https://ethereumfoundation.zoom.us/j/89441658268?pwd=yjqf4TheEb1R7ZSuesCdOAy5tdyVk7.1> Hegota PSA: EIP-8142 (BiB) is being withdrawn/DFI by its champion, @kamilsa: https://github.com/ethereum/EIPs/pull/12072#issuecomment-5757125260. 8411 (fast execution broadcast) replaces it and requires CL team ratings ahead of next ACDC.

@Jihoon So we would have a FOCIL only branch which includes a modified EL that includes ILs. Then a FOCIL + Frames branch where the EL adds ILs and frame tx type

Replying to "@Jihoon So we woul..." Yes and for FOCIL + Frames branch, we also need to modify CL a bit to support the interaction

Reacted to "📋 CL Breakout: <https://ethereumfoundation.zoom.us/j/89441658268?pwd=yjqf4TheEb1R7ZSuesCdOAy5tdyVk7.1> Hegota PSA: EIP-8142 (BiB) is being withdrawn/DFI by its champion, @kamilsa: https://github.com/ethereum/EIPs/pull/12072#issuecomment-5757125260. 8411 (fast execution broadcast) replaces it and requires CL team ratings ahead of next ACDC." with 👆

Reacted to "Yes and for FOCIL + Frames branch, we also need to modify CL a bit to support the interaction" with 👍

Replying to "@Jihoon So we woul..." So FOCIL only devnet on the CL is preliminary to Frames and FOCIL devnet on the EL

Replying to "@Jihoon So we woul..." ELs should design the frame mempool in a way to make building valid ILs easy later on

Reacted to "📋 CL Breakout: <https://ethereumfoundation.zoom.us/j/89441658268?pwd=yjqf4TheEb1R7ZSuesCdOAy5tdyVk7.1> Hegota PSA: EIP-8142 (BiB) is being withdrawn/DFI by its champion, @kamilsa: https://github.com/ethereum/EIPs/pull/12072#issuecomment-5757125260. 8411 (fast execution broadcast) replaces it and requires CL team ratings ahead of next ACDC." with 👆

Reacted to "ELs should design the frame mempool in a way to make building valid ILs easy later on" with 💯

Reacted to "Eip8037 was worth ..." with 💙

🫧 EL breakout: BPO test schedules for Amsterdam TLDR: Osaka-based BPO3/BPO4 stay until the fork; new Amsterdam-based BPOIncrease/BPODecrease test schedules; running them in hive needs clients to accept a BPO slot after Amsterdam

Are we considering increasing blob counts?

Or just for testing?

Not from my side

No from my side

Ben, could you add the topic here: https://github.com/ethpandaops/gas-lighting-tracker/issues/83 , thank you

Reacted to "Ben, could you add the topic here: https://github.com/ethpandaops/gas-lighting-tracker/issues/83 , thank you" with 👍

reminder: next frame breakout call is tmrw, if anyone wants to get something on the agenda: https://github.com/ethereum/pm/issues/2221