According to a pull request on GitHub, an Ethereum consensus client has merged a fix for a poisoning attack targeting the verifier public key cache. This patch addresses a vulnerability related to the Gloas fork; due to an error in the global public key cache, this vulnerability could have caused some nodes to reject valid signatures.
Gloas is the consensus layer part that is undergoing the upcoming Glamsterdam upgrade.
Three deposits, two chains
The problem lies in a mechanism: the client stores the verifier's public key and its index in a global cache.
Technically speaking, deposits that have been finally confirmed should generate the same verifiers on each chain, but at the fork boundaries, the situation is different.
The attacker needs to have exactly 3 pending deposits ready before the fork. The first deposit is a large additional stake for an existing validator. The remaining two deposits are for new keys: A comes with a builder credential, and B comes with a regular validator credential.
On the standard chain, this additional staking will consume a balance of churn. Therefore, A and B will only be processed after the fork. A will become builder, while B will obtain the next validator index.
The flawed caching mechanism incorrectly assumed that two chains would produce the same verifiers, and imported key A into the global cache.
When a fork occurs, the affected nodes will reject all valid signatures from B on the canonical chain and thus fork off from it.
In reality, such attacks are quite complex to carry out, as they require a slashing to occur at the right moment, and also necessitate the use of a sidechain. Therefore, the likelihood of such attacks happening by accident is quite low.
What changes does the fix bring?
According to this PR, the fix is as follows: the relevant key should only be added to the global public key cache after its activation qualification epoch has been finally determined.
A new HeadPubkeys structure will also combine the keys in the header state with those in the global cache, so that if the chain completes final confirmation without new blocks, nodes will not miss any keys.
Whether similar issues exist in other consensus clients remains to be confirmed at this time. In other words, as Glamsterdam approaches, developers are faced with an increasing number of edge cases at the fork boundaries that need to be addressed.
