A Node Operator can circumvent DAO validator key approval

[skozin]

Adding validator keys is performed as follows:

1. A node operator appends new keys to its set; the node operator's staking limit stays the same, making the added keys unusable yet.
2. The DAO performs off-chain verification of the submitted keys: it checks that withdrawal credentials, deposit amounts, and signatures are correct and that there are no duplicate keys in the updated key set.
3. The DAO votes to increase the node operator's limit to allow the added keys to be used by the pool.

However, a node operator can currently add keys that were not approved by the DAO using a simple trick:

1. A node operator submits N correct keys.
2. The DAO validates them and sets stakingLimit = N
3. The node operator submits M <= N more (bad) keys and removes the first M keys.
4. As a result, stakingLimit is still N, and the newly-added keys are allowed to be used in staking despite not being approved by the DAO.

Moreover, currently, key removal is implemented by copying the last key to the storage slot previously occupied by the removed key, so simply decreasing the staking limit won't help. We need to either shift all keys to the left or mark individual keys as validated instead of using an index pointer.

Failing test scenario: #142

[vshvsh]

I think we can leave it for the after-release. Node operators can technically make system behave erroneously, but they's a very convoluted process that can't be done by mistake, and NO set is permissioned, professional and has no immediate way to profit from that.

[skozin]

Yep, I agree that, currently, we have more important issues to fix.

[rkolpakov]

Closed at #478

[TheDZhon]

Decided to re-open the issue because some more sophisticated approaches still exist.

For instance, suppose that steps 2, 3, and 4 are reordered as 3, 4, 2 by leveraging Easy Track motions front-running.

It can be tolerable with the curated set of node operators.

Would require additional Easy Track factory for the upcoming validators sets, and also can be addressed using the https://eips.ethereum.org/EIPS/eip-2537 (expected in the Cancun hardfork)