Ethereum: Glamsterdam fix on staking deposits finally merged

Coin Encyclopedia Improve your knowledge of cryptos

The tide has changed with the calendar. The postponement of Glamsterdam on the Hoodi testnet gave teams the time they lacked to correct a deposit rule. It would have allowed an operator to recover ETH intended for validators of protocols like Lido or Rocket Pool.

All current Gate EU bonuses in one place, cumulative with the Rewards Hub (10,000+ USDC) Take advantage of Gate EU bonuses Commercial link

It all starts from ePBS (EIP-7732), the separation between block provider and block builder that Glamsterdam enshrines in the protocol. The builders, these specialized players who assemble the blocks, have their own account there. We feed it with an ETH deposit, exactly like we launch a validator.

The problem arises at the time of the switch. Repositories still in queue when the fork activates must be distributed between validators and builders. However, the draft specifications provided for a very simple rule. As soon as a repository had registered a builder for a public key, all subsequent repositories on that key went to it.

On October 12, George Avsetsin, Lido's chief protocol architect, described the scenario in a GitHub post. An operator first registers a builder with a new key. A staking protocol then deposits ETH to launch a validator under this same key.

If the two deposits are still pending at the time of the fork, the two amounts land with the builder. “The operator can withdraw funds from the protocol,” summarizes Avsetsin.

And the trap closes. Since no validator has been created, the injured protocol cannot produce the proof that would allow it to recover its stake.

Avsetsin sifted through contracts from Lido, Rocket Pool and Origin using what he calls a “rapid AI search.” He is careful to speak of “conditional results” and not of confirmed exploits. Controls already in place, which reject a previous builder repository, could even block the attack.

The parade can be summed up in one sentence. With pull request #5736, each pending repository is sorted by its withdrawal credentials. A deposit intended for a validator remains with the validator, even if a builder uses the same key.

But touching on the logic of the deposits a few weeks before a fork gives you a cold sweat. After two calls from developers, Justin Traglia, who maintains the consensus specifications, closed the file on October 19. “There wasn’t enough customer support to make this change now,” he wrote.

This refusal was not worth a funeral. All Core Devs calls work without formal voting: proposals advance by rough consensus. A failed subject returns as soon as the context changes.

Machine-translated from French