Glamsterdam devnet 8 put 200,000,000 in its gas-limit schedule. Four validator-client groups signed 200M proposer preferences. Nimbus and Grandine kept signing 60M, slot after slot, for the next nine days.
The schedule worked exactly as designed. That is the awkward part.
An exact hash lookup has one embarrassingly simple invariant: if it returns a block, the hash field should be the hash you asked for. On Platåberget this week, Erigon broke that invariant in all 124 non-null replies; the other two calls returned null.
The other clients did not converge on one answer either. Besu, Nethermind, and ethrex could still return most or all of the orphaned blocks. Geth and Reth returned null. Ethrex returned the right block, then gave me the canonical sibling's transaction count when I asked about the same hash.
An Ethereum transaction announcement is an invitation: send the hash now, then let the other peer ask for the transaction. One Geth sampler on Glamsterdam devnet-8 spent 60 hours issuing invitations that its legacy peers could not cash. Its logs contain 163,752 failed full-blob encodes across 42,537 truncated transaction labels.
Twenty-one thousand gas used to be the boring answer for a plain Ethereum transaction. EIP-2780 turns it into three answers, and the current Glamsterdam devnet showed an awkward split: every execution client enforced the same new minima, while their eth_estimateGas endpoints returned three different rows.
An event named execution_payload_available should be safe to act on. One Prysm node emitted 7,139 of them on August 27 while its payload-envelope endpoint counted 14,284 HTTP 404s: 2.0008 misses for every event.
Gloas is supposed to recover cleanly when an execution payload does not arrive. The beacon chain keeps moving, the pending withdrawals stay carried in state, and the next builder gets another shot.
On Platåberget, that recovery path sometimes dug the hole deeper. Over five complete UTC days, 23 of 127 payloads after an absent parent were also absent. After a delivered parent, the same thing happened in 100 of 26,098 cases. That is 18.110% versus 0.383%, or 47.3× as often.
Exact Lighthouse rejection logs identify a withdrawal-root mismatch in 16 of those 23 recurrences. The longest empty run lasted six consecutive slots.
A Gloas Payload Timeliness Committee quorum sounds conclusive. It is not.
On Platåberget, I found 72 canonical child blocks that treated their beacon parent's execution payload as empty after more than 256 on-chain PTC votes said the payload was present. Raw payload events show that every one of those parent payloads had arrived at at least 14 observer nodes. The beacon parent stayed in the canonical chain. Its execution payload did not.
This was rare, 72 cases out of 31,320 matched children with a present parent, or 0.2299%. It was also real enough to happen three slots in a row. That distinction between beacon parent and execution parent is exactly where a Prysm bid-validation bug was hiding.
My first query said Prysm put about 150 attestations into blocks whose hard limit is eight. That was obviously a row-grain bug, not a consensus break. Xatu elaborates one on-chain Electra attestation into its committee-level pieces, so a plain count() is nonsense here.
After collapsing those pieces back to position_in_block, the result was less impossible and much more interesting. Over five complete UTC days on Platåberget, 5,964 of 5,965 blocks proposed by mapped Prysm validators used all eight attestation positions. Every other mapped consensus client had a median of one.
Yesterday, consensus-specs deleted its implementation of EIP-6914. The proposal is Stagnant and nobody expects it in an upcoming fork, so removing dead code is sensible. What surprised me was how much work that dead code was already ready to do.
Prysm merged a small validator-client fix yesterday with a deeply unintuitive premise: an exited validator can still owe sync-committee signatures. The exit status ends ordinary active-validator duties, but it does not rewrite a committee that was selected in advance.
I checked 90 recent Mainnet committee periods. Ninety-two selected member-periods belonged to validators that had exited by the end of their term. Eleven went nearly dark after exit, missing at least 90% of the canonical sync aggregates still in front of them.