CHAIN_START_FULL_DEPOSIT_THRESHOLD bypass

[JustinDrake]

The deposit contract has a CHAIN_START_FULL_DEPOSIT_THRESHOLD (currently set to 65536). The intent is that, at the genesis of Eth2, there is at least CHAIN_START_FULL_DEPOSIT_THRESHOLD * 32 ETH at stake. This expectation is not realised when multiple full deposits are made to the same pubkey.

An attacker could take advantage of this. To illustrate, the attacker makes 65,000 full deposits to the same pubkey A. The other 536 pubkeys are controlled by the community. At Eth2Genesis the attacker does an immediate VoluntaryExit for pubkey A, and makes 1000 new deposits . Those new deposits are sufficient to take over Eth2, at a low cost.

[JustinDrake]

One idea is to remove Eth2Genesis altogether, and instead require (using "offchain" logic) at least 65536 active validators at genesis (as opposed to deposits).

This has the added advantage of cleaning up Eth2Genesis. Indeed, Eth2Genesis is not strictly required. It may even be "dangerous" in case a last-minute Eth2 bug is found and we want to postpone the launch.

[djrtwo]

At Eth2Genesis the attacker does an immediate VoluntaryExit for pubkey A, and makes 1000 new deposits

At this point, the community controls 100% of validating keys, the attacker has spent 2M eth that is now locked in withdrawable state (no transfers yet), and now has to spend another 32000 eth to make the sufficient deposits to take over.

The more sane attack is to take the 2M eth and make separate deposits and just control the initial vset.

Will ponder the value of Eth2Genesis in general, but I believe the above attack is not really a vector over just a normal takeover. In regards to a normal takeover, we previously upped the amount to reduce likelihood and prevent changing or adding additional logic.

Another alternative is to separately count distinct pubkeys in a map and only initiate genesis at 65k full distinct pubkey deposits.

[JustinDrake]

Closing in favour of #1152 which address this issue.