ACDT2026-10-12_100

AllCoreDevs - Testing #100

2026-10-12 5 decisions 604 transcript lines

Transcript

Follow along

jochem-brouwer
https://github.com/ethereum/pm/issues/2264#issuecomment-6125295010
jochem-brouwer
gm gm
Simone
gm!
Justin Traglia
Agenda: https://github.com/ethereum/pm/issues/2264
Barnabas
Replying to "https://github.com/e..." https://github.com/ethereum/EIPs/pull/12490/changes#diff-6027be04e04207b25b212ff4b36e5ce481dcf6d0b802bcf1fedfa21467fba8ffR60 where is this value coming from?
Nico Flaig
https://github.com/ChainSafe/lodestar/releases/tag/v1.50.0
Barnabas
Reacted to "https://github.com/ChainSafe/lodestar/releases/tag/v1.50.0" with 🥦
Iván | ethrex
Reacted to "https://github.com/C..." with 🥦
Justin Traglia
Reacted to "https://github.com/ChainSafe/lodestar/releases/tag/v1.50.0" with 🥦
Barnabas
https://github.com/ethereum/consensus-specs/pull/5733
Justin Florentine
i thought there was consensus over the shuffle, no?
Pawan Dhananjay
Will check it out today. Didn’t really get what you said now
Barnabas
Replying to "i thought there was ..." this would change the proposal lookahead
Dustin
can it wait for Hegotá?
Barnabas
https://discord.com/channels/595666850260713488/1557224783110742098/1559038075869470722
Barnabas
Reference of the start of the discussion btw^
Barnabas
also attached it in the 5733 PR
Enrico Del Fante
agreed to push it to H
Enrico Del Fante
Replying to "agreed to push it to..." Ye if we want to
Nico Flaig
can't you do the same manipulating the randao?
james
Yes we need to do it today basically
Dustin
yeah Thu is absolutely 100% nonstarter
Pawan Dhananjay
I agree we should push it
Toni Wahrstätter
is the issue summarized somewhere?
Justin Traglia
Replying to "is the issue summari..." The PR describes it pretty well. https://github.com/ethereum/consensus-specs/pull/5733
Toni Wahrstätter
one can self-slash to manipulate randoa. how bad is that attack - not worth doing anything
jochem-brouwer
https://eips.ethereum.org/EIPS/eip-7870
jochem-brouwer
https://discord.com/channels/595666850260713488/1554561056255377418/1559192506824921101
Justin Traglia
Replying to "https://eips.ethereu..." I think it should be a living document. Not a new EIP for each fork.
jochem-brouwer
https://github.com/ethereum/EIPs/pull/12490
Toni Wahrstätter
Replying to "is the issue summarized somewhere?" non-problem, imo. Attack is very unattractrive from attacker perspective
Dustin
Reacted to "I think it should ..." with 👍
Justin Traglia
Replying to "https://eips.ethereu..." Also, I support bumping the seq read/write values. Those are just way too low; like old 2.5in SSD speeds.
Barnabas
random IOPS are a lot more important than raw throughput
Toni Wahrstätter
Reacted to "I think it should be a living document. Not a new EIP for each fork." with 👍
Barnabas
so we should be focusing on that IOPS value here not the raw sequential MB/s
Toni Wahrstätter
Let's update it and keep it living, yeah
nixo
+1
Dustin
well define realistic
Barnabas
the new EIP proposal uses the same IOPS values
Dustin
Nimbus has a bunch of people running on 16GB ARM SBCs
Dustin
works great
Barnabas
Reacted to "Nimbus has a bunch of people running on 16GB ARM SBCs" with 👍
nixo
lol
Justin Florentine
TB not GB
jochem-brouwer
pr to update eip-7870 https://github.com/ethereum/EIPs/pull/12491
Maria Silva
Yeah, that is not part of the discussion
Toni Wahrstätter
Reacted to "pr to update eip-7870 https://github.com/ethereum/EIPs/pull/12491" with ❤️
felipe
Reacted to "pr to update eip-7..." with ❤️
Justin Traglia
Technically, that EIP defines the recommended hardware requirements. Not the minimum.
Barnabas
Replying to "pr to update eip-787..." again the sequential speeds only benefit pretty much blobs evm changes are mainly random 4k write IOPS limited
jochem-brouwer
Antwoord verzenden naar "pr to update eip-7..." i personally think each fork should have their own min specs as eip though, this makes the communication more clear. as now min specs is for fusaka, not glamsterdam, but clients might assume the current spec (so without above pr) is sufficient for glamsterdam, which it absolutely is not
Barnabas
Replying to "pr to update eip-787..." what are the rules of changing an EIP thats already final btw?
jochem-brouwer
Antwoord verzenden naar "Technically, that ..." naive question: is recommended >= minimum? 😅
felipe
Reacted to "i personally think..." with 💡
Dustin
Replying to "Technically, that ..." was an obvious bait and switch, or if one prefers, motte and bailey
Dustin
Replying to "Technically, that ..." because now it gets used as justification for increasing requirements because "recommended" gets read as "minimal"
Justin Traglia
Replying to "Technically, that EI..." Yeah that’s fair. They’re very often mixed up.
Dustin
Replying to "Technically, that ..." easier to get agreement on a "recommended" spec but then it won't get used that way
Justin Traglia
Replying to "Technically, that EI..." Even I say minimum half the time.
jochem-brouwer
ok, fair point
Barnabas
https://www.tomshardware.com/reviews/samsung-970-evo-ssd-review,5573-2.html
Barnabas
this was the reference hw that we used for the eip btw
Barnabas
Samsung says the new 970 EVO can achieve 15,000 IOPS at QD1.
Łukasz Rozmej
unless we are LOWERING hardware requirements, then update EIP after hardfork goes live
Toni Wahrstätter
feel free to move it from draft to being ready for review
jochem-brouwer
Antwoord verzenden naar "feel free to move ..." done
Toni Wahrstätter
Reacted to "done" with ❤️
jochem-brouwer
Antwoord verzenden naar "feel free to move ..." lemme fix the ci
Nico Flaig
why not call it heze-devnet-0?
cayman
Reacted to "why not call it heze..." with 👍
Jun Song
Prysm: will track here (focil-devnet-2 ), aiming Oct 28 https://github.com/OffchainLabs/prysm/issues/17673
Maria Silva
Can you be explicit on the EIPs?
Justin Florentine
Reacted to "Can you be explicit on the EIPs?" with ➕
Jihoon
Replying to "why not call it heze..." https://discord.com/channels/595666850260713488/1557442447074787438/1559129011471261699
spencer
Replying to "Can you be explici..." 8015 + 8365 and 8198?
Barnabas
Reacted to "8015 + 8365 and 8198?" with 👍
Mario Vega
For reference, CFI’d EIPs for the CL: https://forkcast.org/eips/?upgrade=Hegota&stage=Considered&layer=CL
Jun Song
Replying to "Can you be explicit ..." EIP-7805 Fork-choice enforced Inclusion Lists (FOCIL) EIP-8015 Remove deposit and eth1data fields EIP-8365 Disallow new 0x00 validators EIP-8198 Quick Slots
spencer
Reacted to "EIP-7805 Fork-choi..." with 🔥
spencer
Reacted to "For reference, CFI..." with 🔥
cayman
Reacted to "EIP-7805 Fork-choice..." with 🔥
spencer
i like the progression focil/frames -> heze/bogota -> hegota
Justin Florentine
focil is cross layer, why not hegota instead of heze? frames is already at devnet 1
felipe
Reacted to "EIP-7805 Fork-choi..." with 🔥
Enrico Del Fante
7805 + 8015 + 8365. quickslot if wanted
Barnabas
heze-devnet-2
Jihoon
8198 needs some EL support: https://github.com/ethereum/execution-specs/pull/3703
Maria Silva
Replying to "Can you be explicit ..." Which slot time? Keep it at 12s?
pk910
heze devnets would be the merged ones, so with frame txs?
felipe
Reacted to "Which slot time? K..." with ➕
Justin Traglia
Reacted to "8015 + 8365 and 8198?" with 👍
Mario Vega
Reacted to "Which slot time? Keep it at 12s?" with ➕
spencer
Replying to "heze-devnet-2" 0 or 2?
Barnabas
that would be hegota
Pawan Dhananjay
Lighthouse can have it by 28th
jochem-brouwer
Antwoord verzenden naar "pr to update eip-7..." this EIP is living, final eips cannot be changed
Matthew Keil
Just a name
Matthew Keil
Heze is fine
Barnabas
focil-devnet-0 -> heze-devnet-0 focil-devnet-1 -> heze-devnet-1 focil-devnet-2 -> heze-devnet-2 frames-devnet-0 -> bogota-devnet-0 frames-devnet-1 -> bogota-devnet-1
Matthew Keil
Whatever is easiest
Iván | ethrex
Reacted to "focil-devnet-0 -> he..." with 👍
Mario Vega
Reacted to "focil-devnet-0 -> heze-devnet-0 focil-devnet-1 -> heze-devnet-1 focil-devnet-2 -> heze-devnet-2 frames-devnet-0 -> bogota-devnet-0 frames-devnet-1 -> bogota-devnet-1" with 👍
Jun Song
Reacted to "focil-devnet-0 -> heze-devnet-0 focil-devnet-1 -> heze-devnet-1 focil-devnet-2 -> heze-devnet-2 frames-devnet-0 -> bogota-devnet-0 frames-devnet-1 -> bogota-devnet-1" with 👍
Justin Florentine
thats my thinking, fewer future changes
Justin Traglia
Reacted to "focil-devnet-0 -> heze-devnet-0 focil-devnet-1 -> heze-devnet-1 focil-devnet-2 -> heze-devnet-2 frames-devnet-0 -> bogota-devnet-0 frames-devnet-1 -> bogota-devnet-1" with 👍
Guru
Reacted to "focil-devnet-0 -> he..." with 👍
Stefan Starflinger
Reacted to "focil-devnet-0 -> heze-devnet-0 focil-devnet-1 -> heze-devnet-1 focil-devnet-2 -> heze-devnet-2 frames-devnet-0 -> bogota-devnet-0 frames-devnet-1 -> bogota-devnet-1" with 👍
felipe
Reacted to "focil-devnet-0 -> ..." with 👍
spencer
Reacted to "focil-devnet-0 -> ..." with 👍
spencer
Reacted to "focil-devnet-0 -> ..." with 🏎️
Nico Flaig
Reacted to "focil-devnet-0 -> he..." with 👍
Toni Wahrstätter
Reacted to "focil-devnet-0 -> heze-devnet-0 focil-devnet-1 -> heze-devnet-1 focil-devnet-2 -> heze-devnet-2 frames-devnet-0 -> bogota-devnet-0 frames-devnet-1 -> bogota-devnet-1" with 🤘
Iván | ethrex
Reacted to "focil-devnet-0 -> he..." with 🤘
felipe
Reacted to "focil-devnet-0 -> ..." with 🤘
Iván | ethrex
Reacted to "focil-devnet-0 -> he..." with 🏎️
jochem-brouwer
Antwoord verzenden naar "pr to update eip-7..." see https://eips.ethereum.org/EIPS/eip-1#eip-process https://eips.ethereum.org/assets/eip-1/EIP-process-update.jpg
Matthew Keil
Just should keep slots to 12 sec
Dustin
Nimbus might not join, hard to say, but it's fine
Justin Florentine
oct 28?
Barnabas
Replying to "oct 28?" I’d prefer oct 21 with 12s slot
Barnabas
Replying to "oct 28?" or oct 28 with 10s
Nico Flaig
lodestar has quick slots on trunk branch
Toni Wahrstätter
where would the deadlines move (attestation, payload observation, ptc) if 10s?
Barnabas
Replying to "where would the dead..." tbd?
Toni Wahrstätter
i guess clients aren't just implementing "naive" linear adjustments?
NC
Replying to "i guess clients aren..." they are “naive” I believe
Iván | ethrex
We added support for quick slots in focil-devnet-2. Now that the spec tests are merged I’ll see we are passing them
Toni Wahrstätter
Replying to "i guess clients aren't just implementing "naive" linear adjustments?" or actually, maybe just doing linear adjustments might be the right thing to do
Jihoon
Reacted to "We added support for quick slots in focil-devnet-2. Now that the spec tests are merged I’ll see we are passing them" with 👍
Toni Wahrstätter
Replying to "i guess clients aren't just implementing "naive" linear adjustments?" might be less naive but elegantly simple and effective? Not sure. Attestations deadline doesn't care much about slot time and might need to stay constant
Justin Traglia
Reacted to "they are “naive” I believe" with 👍
jochem-brouwer
eip-8199? which eip is this?
Toni Wahrstätter
Replying to "We added support for quick slots in focil-devnet-2. Now that the spec tests are merged I’ll see we are passing them" which deadlines did move?
Justin Traglia
Replying to "eip-8199? which eip ..." eip8198
jochem-brouwer
Heeft gereageerd op "eip8198" met 👍
Justin Traglia
Replying to "eip-8199? which eip ..." Quick slots.
Justin Traglia
Replying to "eip-8199? which eip ..." That’s what I meant to say, if I didn’t 🙂
Barnabas
consensooooooooor
Toni Wahrstätter
Replying to "We added support for quick slots in focil-devnet-2. Now that the spec tests are merged I’ll see we are passing them" e.g. attestation deadline kept at 3s and payload + ptc moved linearly?
jochem-brouwer
Heeft gereageerd op "That’s what I mea..." met 😄
jochem-brouwer
Heeft gereageerd op "Quick slots." met 👍
CPerezz
Reacted to "consensooooooooor" with 😂
Barnabé Monnot
Replying to "i guess clients aren..." I would imagine that it is optimal to not do linear adjustments, indeed there are moments in the slot that have fixed overhead rather than variable cost based on e.g., the block size (attestation deadline is one such moment)
Barnabas
keep up old man @spencer 😂
Jihoon
Replying to "We added support for..." Currently all BPS are not changed but it's all tentative. I'd leave more detailed answers to Barnabe though.
Toni Wahrstätter
Replying to "i guess clients aren't just implementing "naive" linear adjustments?" yeah but I think it's only the attestation deadline adn payload + blob deadline might be fine adjusting linearly?
Justin Traglia
Reacted to "Currently all BPS are not changed but it's all tentative. I'd leave more detailed answers to Barnabe though." with 👍
Mario Vega
https://github.com/ethereum/execution-specs/releases/tag/tests-frames-devnet%40v1.0.0
Guru
Reacted to "https://github.com/e..." with 👍
spencer
Reacted to "keep up old man @s..." with 🧓
Barnabas
Replying to "https://github.com/e..." do we wanna rename the tests too to ` tests-bogota-devnet ?
Mario Vega
Reacted to "do we wanna rename the tests too to ` tests-bogota-devnet ?" with 👍🏼
Jihoon
Replying to "i guess clients aren..." We can also take Glamsterdam mainnet data into account once we have them to decide this. No need to rush at all IMO.
Guru
Reacted to "do we wanna rename t..." with 👍🏼
jochem-brouwer
from my side eip-8253 should go in next devnet
james
It’s going to be tough regardless there’s lots of overlap with the priority work
Barnabé Monnot
Reacted to "We can also take Glamsterdam mainnet data into account once we have them to decide this. No need to rush at all IMO." with 👍
Justin Florentine
yeah, agreed with Dustin, planning is overhead
Toni Wahrstätter
Replying to "i guess clients aren't just implementing "naive" linear adjustments?" yeah, and observation deadlines are easy to change. Everything that doesn't scale the payload linearly might affect execution times though
Justin Traglia
Reacted to "We can also take Glamsterdam mainnet data into account once we have them to decide this. No need to rush at all IMO." with 👍
Jihoon
Reacted to "yeah, and observation deadlines are easy to change. Everything that doesn't scale the payload linearly might affect execution times though" with 👍
Justin Traglia
Reacted to "yeah, and observation deadlines are easy to change. Everything that doesn't scale the payload linearly might affect execution times though" with 👍
Jihoon
Replying to "i guess clients aren..." New .pics?
Toni Wahrstätter
Replying to "i guess clients aren't just implementing "naive" linear adjustments?" linearDeadlineChanges.pics
Jihoon
Reacted to "linearDeadlineChanges.pics" with 😂
NC
moving faster and less burnout are opposite things?
Toni Wahrstätter
agree with justin. full focus on headliners at this stage
CPerezz
I guess no SETCODEFROM anytime soon… 🙁
spencer
Replying to "moving faster and ..." they dont have to be :)
spencer
Reacted to "agree with justin...." with 👍
Barnabé Monnot
Replying to "i guess clients aren..." if we get the attestation deadline from 3 to 2 seconds, and scale down the execution time by a second (10 -> 9 seconds), we get to 10 seconds slot duration, and I believe we scale down execution time by less than the actual slot reduction, proportionally
Justin Traglia
https://ethereumfoundation.zoom.us/j/89441658268?pwd=yjqf4TheEb1R7ZSuesCdOAy5tdyVk7.1
Łukasz Rozmej
we should be focusing on whole CFI fork scope soon
Łukasz Rozmej
(be faster)
Iván | ethrex
Reacted to "we should be focusin..." with 👍
CPerezz
Reacted to "we should be focusin..." with 👍
spencer
https://github.com/ethereum/EIPs/pull/12457
Toni Wahrstätter
Replying to "i guess clients aren't just implementing "naive" linear adjustments?" but why would the attestation deadline change without any protocol changes? just bc we might have room anyway (which we find out with glam)?
Toni Wahrstätter
how far are clients with frames?
Iván | ethrex
Yes and yes 😄
CPerezz
Reacted to "how far are clients ..." with 👀
Toni Wahrstätter
and follow up, with frames + the cfi'd extensions
Łukasz Rozmej
frames + friends - devnet ready in Neth
Mario Vega
Reacted to "frames + friends - devnet ready in Neth" with ❤️
spencer
8141 + 8250 + 8272 + 7906
Iván | ethrex
I see ethrex, nethermind, Geth, and Geth in frames-devnet-0
felipe
Reacted to "frames + friends -..." with ❤️
Toni Wahrstätter
do we have specs + tests in eels for that already? how complete is that?
Guru
Replying to "do we have specs + t..." Yes. We do
Mario Vega
Replying to "do we have specs + t..." https://github.com/ethereum/execution-specs/releases/tag/tests-frames-devnet%40v1.0.0
Marc
yeah we’re fine with including the change
Toni Wahrstätter
Replying to "do we have specs + tests in eels for that already? how complete is that?" awesome!
Toni Wahrstätter
Replying to "do we have specs + tests in eels for that already? how complete is that?" moving super fast
felipe
Reacted to "moving super fast" with 🔥
Mario Vega
Reacted to "moving super fast" with 🔥
Guru
Reacted to "yeah we’re fine with..." with 👍
spencer
https://github.com/ethereum/EIPs/pull/12457
Łukasz Rozmej
Reacted to "yeah we’re fine with including the change" with 👍
Łukasz Rozmej
Replying to "do we have specs + tests in eels for that already? how complete is that?" let's go even faster
Justin Florentine
so same as the verifier install
Łukasz Rozmej
Replying to "do we have specs + tests in eels for that already? how complete is that?" ludicrous speed
Iván | ethrex
I made a couple PRs adding tests
spencer
Reacted to "I made a couple PR..." with 🔥
Iván | ethrex
https://github.com/ethereum/execution-specs/pull/3756 for 12457
Guru
Reacted to "I made a couple PRs ..." with 🔥
spencer
Replying to "I made a couple PR..." Thx for this!
Iván | ethrex
https://github.com/ethereum/execution-specs/pull/3757 for 12458
felipe
Reacted to "I made a couple PR..." with 🔥
spencer
Reacted to "https://github.com..." with 🔥
Iván | ethrex
Reacted to "Thx for this!" with 🙏
Iván | ethrex
Already renamed!
Toni Wahrstätter
too early to discuss next devnet eips already?
Łukasz Rozmej
Replying to "too early to discuss next devnet eips already?" no
spencer
Replying to "too early to discu..." never too late! iom
Justin Florentine
Replying to "too early to discuss..." setcodefrom?
spencer
Replying to "too early to discu..." *imo
Iván | ethrex
Reacted to "setcodefrom?" with 🔥
Maria Silva
Reacted to "setcodefrom?" with 🔥
Marc
Reacted to "setcodefrom?" with 🔥
CPerezz
If we have multiple clients implementing some CFI’d EIP + tests in EEST, when will we start considering adding them? Which devnet-height is the one that opens the door to this?
Mario Vega
https://github.com/ethereum/execution-specs/issues/3664
Justin Florentine
Replying to "too early to discuss..." what else is cfi'd that is frames adjacent?
CPerezz
Replying to "If we have multiple ..." Referring to: https://github.com/ethereum/execution-specs/pull/3769
Marc
happy to include any of the CFI’d EIPs
Mario Vega
Reacted to "setcodefrom?" with 🔥
Marc
maybe SETCODEFROM and 8151 would be cool to go along with frames
Toni Wahrstätter
It wasn't a bad idea to include 8037 early last time - gave time to understand it better and debug. The same might apply to the data repricing, esp 8279 which is the more involved one of the two.
Iván | ethrex
Reacted to "maybe SETCODEFROM an..." with ☝️
jochem-brouwer
https://eips.ethereum.org/EIPS/eip-8253
CPerezz
Reacted to "maybe SETCODEFROM an..." with ☝️
Marc
Reacted to "It wasn't a bad idea to include 8037 early last time - gave time to understand it better and debug. The same might apply to the data repricing, esp 8279 which is the more involved one of the two." with ➕
CPerezz
Reacted to "maybe SETCODEFROM an..." with ❤️
CPerezz
Reacted to "It wasn't a bad idea..." with ➕
CPerezz
Reacted to "It wasn't a bad idea..." with 👍
jochem-brouwer
https://github.com/ethereum/EIPs/pull/12456
spencer
Replying to "It wasn't a bad id..." 100%, for me I think adding the more complex EIPs first or hardest to test is the best move
Pooja Ranjan
Reacted to "https://eips.ethereum.org/EIPS/eip-8253" with 👍
Toni Wahrstätter
Replying to "It wasn't a bad idea to include 8037 early last time - gave time to understand it better and debug. The same might apply to the data repricing, esp 8279 which is the more involved one of the two." yeah, then 8279 would be a candidate
Stefan Starflinger
Reacted to "It wasn't a bad idea to include 8037 early last time - gave time to understand it better and debug. The same might apply to the data repricing, esp 8279 which is the more involved one of the two." with 👍
spencer
should we be focusing on the interactions with focil first? so this is discussing what we add after we merge the EL and CL devnets?
spencer
Reacted to "setcodefrom?" with 🔥
jochem-brouwer
Antwoord verzenden naar "https://github.com..." I will merge this one btw. No spec changes
Toni Wahrstätter
my feeling is do setcodefrom + data repricing
CPerezz
Reacted to "my feeling is do set..." with ❤️
CPerezz
Reacted to "my feeling is do set..." with 👍
CPerezz
Replying to "my feeling is do set..." SHIP IT
Iván | ethrex
Reacted to "SHIP IT" with 🚢
Mario Vega
Reacted to "my feeling is do setcodefrom + data repricing" with ❤️
Toni Wahrstätter
Reacted to "SHIP IT" with 🚢
Mario Vega
Reacted to "my feeling is do setcodefrom + data repricing" with 👍
Marc
Reacted to "my feeling is do setcodefrom + data repricing" with ❤️
spencer
Reacted to "my feeling is do s..." with 👍
spencer
Reacted to "SHIP IT" with 🚢
spencer
can confirm this next week?
Łukasz Rozmej
Reacted to "SHIP IT" with 🚢
Łukasz Rozmej
Reacted to "my feeling is do setcodefrom + data repricing" with 👍
Toni Wahrstätter
* set code from * data repricing * bump nonce * deactivate selfdestruct
spencer
Reacted to "* set code from * ..." with 🔥
Łukasz Rozmej
Reacted to "* set code from * data repricing * bump nonce * deactivate selfdestruct" with 👍
Łukasz Rozmej
Reacted to "* set code from * data repricing * bump nonce * deactivate selfdestruct" with 🔥
Iván | ethrex
Replying to "* set code from * da..." 8151 no?
Łukasz Rozmej
Reacted to "maybe SETCODEFROM and 8151 would be cool to go along with frames" with ☝️
Łukasz Rozmej
Reacted to "maybe SETCODEFROM and 8151 would be cool to go along with frames" with ❤️

Call summary

Targets

•October 16th — Hoodi client releases due; blog post publication - 00:09:57
•October 28th latest — heze-devnet-2 launch (3+ CL clients required) - 00:30:07
•Thursday October 15th — bogota-devnet-1 launch - 00:48:26

Decisions

•Proposer selection bug deferred to Hegota (or later); no fix in Glamsterdam - 00:16:50
•EIP-7870 remains a living document; update in place with fork-specific history rather than creating per-fork EIPs - 00:19:09
•All focil-devnet-* renamed to heze-devnet-*, all frames-devnet-* renamed to bogota-devnet-* - 00:34:25
•heze-devnet-2 slot duration stays at 12 seconds; quick slots (EIP-8198) included but not yet at 10s - 00:38:01
•bogota-devnet-1 test release to tag B1.1.0 including keyed nonce consensus change; launch targeting Thursday - 00:54:06

Highlights

Network Status:
- ·Glamsterdam devnet: Nimbus, Erigon, Lighthouse, Grandine, and Besu nodes offline; client teams asked to investigate - 00:07:01
- ·Sepolia post-fork: stable, all node operators synced, near 100% participation - 00:07:33
- ·JochemNet shadow fork v2 launched post-fork with 64KB contracts for benchmarking; Snap 2 sync issues found in multiple clients on v1 - 00:07:54
Client Releases:
- ·Hoodi client releases due by Friday October 16th; Lodestar already published v1.50.0 - 00:09:57
Hardware Specs Eip7870:
- ·EIP-7870 min specs are wrong for Glamsterdam: current 500 MB/s sequential read/write too low; jochem recommends raising to 2000 MB/s - 00:17:20
- ·Consensus: keep EIP-7870 as a living document (not fork-per-EIP); update with fork-specific history sections - 00:19:09
- ·Lukasz: random 4K IOPS matter more than sequential MB/s for EVM workloads; worst-case block must be handled by spec hardware - 00:23:33
Proposer Selection Bug:
- ·Spec bug reported: proposer can self-slash to manipulate compute shuffle index and influence future epoch proposer selection - 00:10:25
- ·Consensus: exploit is difficult, requires self-slash, and not worth fixing in Glamsterdam; defer to Hegota if at all - 00:13:10
Hegota Devnet Planning Cl:
- ·Proposed heze-devnet-2 (CL-only): EIP-7805 (FOCIL), EIP-8015 (remove eth1data), EIP-8365 (disallow 0x00 validators), EIP-8198 (quick slots at 12s) - 00:29:13
- ·Quick slots (EIP-8198) kept at 12s for devnet; 10s slot duration deferred pending broader client readiness - 00:30:18
- ·Teku, Lodestar, Lighthouse have quick slots implemented; Nimbus unlikely to join if 10s slots required - 00:39:17
- ·Devnet naming scheme agreed: focil-devnet-* → heze-devnet-*, frames-devnet-* → bogota-devnet-* - 00:34:25
El Breakout Bogota Devnet 1:
- ·bogota-devnet-1 EIPs: EIP-8141, EIP-8250, EIP-8272, EIP-7906 (frames, keyed nonces, recent roots, transaction assertions) - 00:49:28
- ·Spec clarification: keyed nonces are regular state added to BAL; floor gas pricing over full tx envelope changes call data cost when combined with frames - 00:51:21
- ·ethrex and Nethermind already passing tests-frames-devnet@v1.0.0; new tag B1.1.0 to include keyed nonce consensus change - 00:53:58
El Breakout Next Devnet Eips:
- ·EIP-8253 (nonce bump) should go in next devnet; behavior only triggers at fork transition, needs early testing on all devnets - 00:57:55
- ·Strong community support to include SETCODEFROM, data repricing (EIP-8279), nonce bump, and deactivate self-destruct in bogota-devnet-2 - 01:02:26
- ·jochem: if deactivate self-destruct ships, EIP-8360 (TCREATE) should be prioritized alongside it to avoid economic disruption - 01:00:54

Action Items

•All client teams - Notify Alex Stokes when Hoodi releases are ready for blog post - 00:09:22
•jochem - Open PR to add EIP-8253 test accounts to devnet genesis template - 00:57:40
•EL teams / spencer - Confirm bogota-devnet-2 EIP scope (SETCODEFROM, data repricing, nonce bump, deactivate self-destruct) on next call - 01:04:42

Key decisions

Proposer selection bug deferred to Hegota (or later); no fix in Glamsterdam
Exploit is difficult, requires self-slash, and not worth fixing in Glamsterdam.
EIP-7870 remains a living document; update in place with fork-specific history rather than creating per-fork EIPs
The document will be updated with fork-specific history sections instead of creating new EIPs for each fork.
All focil-devnet-* renamed to heze-devnet-*, all frames-devnet-* renamed to bogota-devnet-*
Agreed upon a new naming scheme for upcoming devnets.
heze-devnet-2 slot duration stays at 12 seconds; quick slots (EIP-8198) included but not yet at 10s
heze-devnet-210s slot duration deferred pending broader client readiness; Teku, Lodestar, and Lighthouse have implemented quick slots.
bogota-devnet-1 test release to tag B1.1.0 including keyed nonce consensus change; launch targeting Thursday
bogota-devnet-1New tag B1.1.0 includes keyed nonce consensus changes; ethrex and Nethermind already passing initial tests.

EIPs discussed

EIP-7870 EIP-8198 EIP-8250

Links

AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.