Handle registrations with bad proofs of possession

[JustinDrake]

At the moment validators with a bad proof of possession are asserted away in the add_validator function. One possible way to handle bad proofs of possession is to add a corresponding validator entry with status PENDING_WITHDRAW.

[vbuterin]

Ah, the assert is supposed to represent "the entire block that contains that registration is invalid".

IMO as a general principle, we should not be allowing no-op messages to get included in the chain as much as possible.

[JustinDrake]

Does this mean that if someone screws up the PoP their 32 ETH deposit goes in a black hole?

[mkalinin]

Wouldn't it be possible to submit PoP to the registration contract once again? Maybe there are any drawbacks related to that?

[vbuterin]

I suppose if we want we can add a mechanism for later re-submitting a "fixed PoP" for a previous deposit.

[djrtwo]

Yeah, I'm open to it. I'd say this is a "nice to have", not a "must have".

[vbuterin]

Agree. You can screw yourself over by submitting a bad withdrawal address already.

[JustinDrake]

What about:

• Have the "deposit contract" on the PoW chain be literally a burn address (e.g. the address 0xE7H20 for "ETH2.0"). In particular, no proof_of_possession, withdrawal_shard, withdrawal_address or randao_commitment is provided, just ETH.
• Introduce SpecialRecords to use the burnt ETH (for registrations, for top-ups, etc.)

This potentially kills several birds with one stone:

1. No PoW contract has to be written.
2. The above issue with bad proofs of possession becomes a non-issue.
3. The registration logic is decoupled from the PoW chain. In particular, upgrades to the registration logic do not require touching the PoW chain.
4. The same infrastructure on the PoW chain can used for both registrations and top-ups.
5. The registration logic being implemented fully on the beacon chain means it can be reused for "internal registrations" to solve issue 10 here. (IMO having ETH stuck for an undetermined amount of time after deregistration is far from ideal.)

[mkalinin]

Moving registration logic to the beacon chain makes it possible to feature shards with validator registration. Should be a straightforward solution for that 👍

[djrtwo]

I like how this naturally translates to keeping the same interface for shard chain deposits, but there are certainly some other complexities introduced as a tradeoff.

With the "deposit" contract, how does a validator utilize the eth1.0 ETH on eth2.0? If we use the eth1.0 pub-keys as the "right" to utilize the burned ETH, then we need to support ECDSA-verify on the beacon chain to verify that the SpecialRecord is indeed related to eth1.0 account that deposited the eth.

Also, we'd be consuming SpecialRecords that point to successful TXs on the PoW chain rather than ordered logs from a contract on the PoW chain. This isn't radically different, but it introduces some required beacon chain accounting related to what has or hasn't been consumed from the eth1.0 deposit addr.

[JustinDrake]

To address your point about the beacon needing to support ECDSA-verify what about having a minimal contract where the only argument is pubkey?