AllCoreDevs — Testing #085
Transcript
Ask about this call
Answered from this call's summary and transcript only.
AI-generated — verify against the recording.
Call summary
Targets
- •ACDE this week: finalize devnet-7 EL scope — 00:33:50
- •ACDC next week: finalize devnet-7 CL scope — 00:34:02
Decisions
- •EIP-8282 builder deposit contract: keep static constants (no dynamic params); choose values carefully; Felix adds disable-switch for future upgrades — 00:30:26
- •glamsterdam-devnet-7 adds no new EIPs; EL scope limited to refinements of existing EIPs — 00:33:50
Highlights
- Testing Progress:
- ·glamsterdam-devnet-6 launched June 25 with Gloas fork; consolidation testing pending this week — 00:08:26
- ·Prysm nodes offline; potuz suspects EL-side bug (Nethermind invalid block, ethrex DB issue) rather than Prysm fault — 00:08:51
- ·Nethermind bug found via execution fixtures; fix in progress; Besu also offline — 00:09:27
- ·Erigon branch expected tomorrow; Reth branch exists but not yet joined; Grandine joining this week — 00:11:44
- Fork Status And Schedule:
- ·glamsterdam-devnet-7 scope: EIP-7688 (forward-compatible SSZ data structures) on CL side; no new EIPs on EL, only refinements — 00:31:05
- ·Open EL question for devnet-7: how to meter authorizations (EIP-8037 state growth + EIP-2780 transfer) — 00:31:56
- ·Target: finalize devnet-7 EL scope at this week's ACDE; CL scope at next week's ACDC — 00:33:50
- Eip 8282 Builder Deposit Contract:
- ·Per-tx fee merged to sys-asm; bytecode now committed to repo for easy devnet genesis use — 00:13:55
- ·Nico proposes lowering builder deposit params: target=8, max=64 (from 32/256) to limit validator sweep DOS risk — 00:18:32
- ·Debate: dynamic params via calldata (PK's PR) vs. deploy new contract at next fork vs. keep constants fixed — 00:20:03
- ·potuz: no builder churn expected; deploying new contract at next fork is acceptable — 00:23:57
Action Items
- •Felix (Geth) — Felix to add disable-switch to EIP-8282 deposit contract (easy, low-risk future-proofing) — 00:20:03
Meeting chat56
- danceratopz
ACDT #85 agenda https://github.com/ethereum/pm/issues/2133
- Barnabas
everyone having fun outside sunbathing probably
- Justin Traglia
Reacted to "everyone having fun ..." with 🔥
- Barnabas
And here I am with a closed blinds to keep the light and heat out 😂
- Edgar | ethrex
36C here
- danceratopz
same here!
- Felix (Geth)
who is here in their underpants
- Barnabas
just hit 41 here
- danceratopz
ACDT #85 agenda https://github.com/ethereum/pm/issues/2133
- danceratopz
🧪 glamsterdam-devnet-6 status https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-6 https://hive.ethpandaops.io/#/group/glamsterdam-quick Launched 06-25 with the Gloas fork
- Justin Traglia
Reacted to "who is here in their..." with 😅
- Ben Adams
Reacted to "who is here in their underpants" with 😅
- potuz
We need to test pre-fork though
- danceratopz
Reacted to "who is here in their..." with 😅
- potuz
We need to reach the fork with a bunch of enough slashed Vals so that we can check
- Barnabas
Reacted to "who is here in their underpants" with 😅
- Barnabas
Replying to "We need to reach the..." think this could be tested more reliably on kurtosis
- Guru
Reacted to "who is here in their..." with 😅
- Barnabas
Replying to "We need to reach the..." would you want n-2 slashings?
- Barnabas
Replying to "We need to reach the..." or n-1?
- Barnabas
Replying to "We need to reach the..." where n is fork epoch
- potuz
Replying to "We need to reach the..." We want the state to have a ton of already slashed validators it doesn’t matter when they were slashed
- potuz
Replying to "We need to reach the..." The point is that they need to be proposers in the first epoch post-fork
- Barnabas
Replying to "We need to reach the..." ok
- potuz
Replying to "We need to reach the..." So that we check that they are removed at the “upgrade to Gloas” part
- danceratopz
🏗️ EIP-8282 builder deposit contract (devnet-7 + audit) [optional] https://github.com/ethereum/sys-asm/pull/43 https://github.com/ethereum/sys-asm/pull/48 Per-tx fee merged; open: pass target/max/rate via calldata + final constants, then freeze for the audit.
- Barnabas
Replying to "We need to reach the..." this still feels like a sort of deadend devnet scenario
- Barnabas
Replying to "We need to reach the..." can totally do this locally.
- potuz
Replying to "We need to reach the..." Sure, I’m happy if this is tested in KT
- Barnabas
btw nimbus still doesn’t seem to use builder’s to build blocks
- Barnabas
Should we do a new contract if we wanna tweak the numbers?
- Barnabas
Feels like a lot more disposable contract vs the validator contract tbh
- Felix (Geth)
Regarding 'disposable contract', one big thing with 8282 is that the contract stores the actual deposits
- Felix (Geth)
So if we would launch another contract later, the builders might deposit to the old contract that we are not polling anymore, and their deposit would be lost forever
- Barnabas
Replying to "Regarding 'disposabl..." right but when builders would just exit, it would create the eth from beacon chain no?
- Justin Florentine (Besu)
Replying to "So if we would launc..." makes sense to decouple the queue from the depositing account, but it will complicate and lengthen the audit
- Felix (Geth)
If we want to upgrade to another contract later, then I think we should add a logic into the contract that disables it
- Barnabas
self destruct? (joke btw)
- Nico Flaig
target=8,max=64 instead of target=32, max=256 on the builder deposit contract, that's all my change does, we can then reduce withdrawal delay for builders on the CL side further without opening up a dos of the validator withdrawal sweep
- Justin Traglia
Reacted to "target=8,max=64 inst..." with 👍
- Toni Wahrstätter
lowering the target should make it cheaper no?
- system call
- pk910
I get that the dynamic fee might be too complex. but I thinks it's very bad to change the public contract address at a later fork. Disabling deposits on the old contract helps a bit, but still breaks downstream toolings and needs dev work. Could we make the depsoit contract a proxy where we can change the implementation via a system call? :D (kinda joking as it's likely more complex, but would solve it too)
- potuz
Replying to "lowering the target ..." I think lowering it should make it more expensive
- Felix (Geth)
proxy is ok too
- pk910
Announcing a deposit contract address once is something else than changing the contract address later imo
- potuz
We don’t expect to have builder churn on that contract, we shouldn’t spend too much time on this, deploying new contracts is absolutely fine
- Stefan Starflinger
Reacted to "Announcing a deposit..." with 👍
- Felix (Geth)
we can also do a thing where we pull from both contracts in the fork N -> N+1 window
- Felix (Geth)
and then stop pulling from it at fork N+1
- Toni Wahrstätter
Let's keep it with using constants (instead of dynamic) but try avoid needing a new contract by chosing the constants well
- Toni Wahrstätter
Is there anything still open on the EL?
- spencer
Any new EL spec changes for devnet 7? Not devnet 6?
- Felix (Geth)
Replying to "Let's keep it with..." I'll still put in the disable switch
- Felix (Geth)
Replying to "Let's keep it with..." it's pretty easy to do and we can use it later
- Alexey
Reacted to "Any new EL spec changes for devnet 7? Not devnet 6?" with ➖
Key decisions
EIP-8282 builder deposit contract: keep static constants (no dynamic params); choose values carefully; Felix adds disable-switch for future upgrades
The decision is about keeping static constants in EIP-8282 builder deposit contract and adding a disable-switch for future upgrades.glamsterdam-devnet-7 adds no new EIPs; EL scope limited to refinements of existing EIPs
glamsterdam-devnet-7The decision is about the scope of glamsterdam-devnet-7 which includes no new EIPs and only refinements of existing EIPs.