Skip to content

test(gloas): add pre-fork builder onboarding test (0x03 -> builder)#195

Open
barnabasbusa wants to merge 6 commits into
glamsterdam-devnet-6from
bbusa/builder-prefork-onboard-test
Open

test(gloas): add pre-fork builder onboarding test (0x03 -> builder)#195
barnabasbusa wants to merge 6 commits into
glamsterdam-devnet-6from
bbusa/builder-prefork-onboard-test

Conversation

@barnabasbusa

Copy link
Copy Markdown
Contributor

Stacked on #194.

Adds playbooks/gloas-dev/builder-prefork-onboard.yaml, a focused regression test for the GLOAS pre-fork builder onboarding path (onboard_builders_from_pending_deposits).

What it does

  1. A few slots before GLOAS activation, deposits builderCount keys via the standard validator deposit contract (0x00000000219ab540356cBB839Cbe05303d7705Fa) using 0x03 (builder) withdrawal credentials. These use the regular DOMAIN_DEPOSIT, so the ordinary generate_deposits task works unchanged.
  2. Because the deposits reach the fork still pending, the GLOAS transition dequeues them into builders.
  3. Right after the first GLOAS block, verifies each pubkey now exists as a builder (the dequeue/onboard actually happened).
  4. Verifies the onboarded builders go active.

Notes

  • Requires being started before GLOAS activation — if the pre-fork window has already passed, the test fails fast rather than silently passing, since the path under test is no longer reachable.
  • Complements builder-lifecycle.yaml, which covers both onboarding paths end-to-end; this one isolates just the 0x03 -> builder fork-dequeue case.
  • assertoor validate passes.

Isolates the onboard_builders_from_pending_deposits path: deposit builders
via the standard validator deposit contract with 0x03 creds a few slots
before GLOAS, then verify the fork dequeues the still-pending deposits into
builders. Fails fast if started after the pre-fork window.
Drop the 'wait until SLOTS_PER_EPOCH/3 before the fork' gate; just deposit as
soon as the test starts. Guard now only requires that GLOAS hasn't activated
yet so the deposit can still be pending at the transition.
The post-fork onboard check used expectActive+failOnCheckMiss one slot after
the fork. expectActive requires deposit_epoch < finalized_epoch, which can
never hold for a deposit onboarded AT the fork, so it failed instantly.

Make phase 2 an existence-only polling check (proves the 0x03->builder dequeue
happened), and make the phase 3 active check poll instead of single-shot.
…uilder

Depositing ASAP let the 0x03 deposit finalize and get drained into the
validator registry as a regular validator before the fork, so the GLOAS
onboarding (which only scans still-pending deposits, and skips pubkeys that
are already validators) never converted it. Restore depositing ~1 epoch
before the fork, within the unfinalized window, so it survives in
state.pending_deposits until upgrade_to_gloas onboards it.

Verified against consensus-specs v1.7.0-alpha.11 (process_pending_deposits
finalized-slot gate; onboard_builders_from_pending_deposits; no min amount).
…as epoch

Fills the front of the pending-deposit queue with junkCount (>16) regular 1 ETH
deposits at epoch F-3, then a 0x03 builder deposit behind the wall. The boundary
drain (16/epoch) can't reach the builder deposit, so it stays pending and is
onboarded already-finalized (deposit_epoch=F-3 < finalized@fork), making it
active in epoch F. Asserts active-in-epoch-F as the experiment.
…c+index

Add builderMnemonic + builderKeyIndex config to both pre-fork playbooks so the
0x03 deposit can target an external builder's key (e.g. buildoor's), letting that
builder bid on the onboarded builder. Defaults to a random mnemonic (unchanged
standalone behaviour). In queuefill the builder uses a separate mnemonic from the
junk wall to avoid index collisions.
@qu0b-reviewer

qu0b-reviewer Bot commented Jun 22, 2026

Copy link
Copy Markdown

🤖 qu0b-reviewer

Summary

The PR modifies the existing pre-fork builder onboarding playbook with corrected timing logic (deposit must land unfinalized at the fork) and adds a new queue-fill trick playbook that attempts to make a builder active in the very first GLOAS epoch. The timing calculations, configuration variables, indexing, and task wiring are all internally consistent and correctly use the check_consensus_builder_status task's polling semantics (failOnCheckMiss/expectActive). No blocking issues found.

Issues

None.

Suggestions

  • playbooks/gloas-dev/builder-prefork-queuefill.yaml:122 — The comment reads "prepare wallet and a single mnemonic (junk = first junkCount indices, builder = the next builderCount indices)" but the code immediately below creates two separate mnemonics (test_mnemonic for the junk wall at line 133, builder_mnemonic_rand for the builder at line 137) and uses them with different startIndex values. The code is functionally correct (the two mnemonics prevent any index collision), but the comment is misleading. Consider updating it to reflect the dual-mnemonic approach, e.g. "prepare wallet and separate mnemonics for junk and builder deposits".

Reviewed @ 3f8697c6
"Every system eventually becomes legacy."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant