By BLS-precompile, I mean this EIP: https://eips.ethereum.org/EIPS/eip-2537
So far the discussions I heard about this precompile were centered around the needs of Eth2 phase0, as a way of validating 32 ETH deposits made by wannabe Eth2 validators.
So when I read this: https://blog.ethereum.org/2020/06/02/the-state-of-eth2-june-2020/
it seems to me that now the BLS precompile is rather required for phase1 of eth2, and not really for phase0.
Would it not be a safer strategy to introduce it after phase 0 is live, to make sure that the precompile has exactly the same curve as the phase 0 ends up having?
Otherwise it would be like pushing the cart in front of the horse, so to speak.
Let us address the deposit validation issue as well as the much bigger issue of potential problems of phase 0 launch.
This is how I understand the current strategy: if something does not go according to plan with phase 0 launch, then one of 2 things would happen:
My suggestion is to put a “kill-switch” into the phase0 deposit contract, that is removed when the phase0 is deemed to be successfully live. This kill-switch, when activated, makes deposits reversible. I think it will lower the risk of catastrophic failure after the phase0 launch, due to massive user error or some technical problem. It means that the phase 0 launch can be reversed and replayed, if needed.
When the kill-switch is activated, and the deposits are made reversible, you basically declare the current version of eth2 dead, and have to relaunch
The kill switch will mitigate large user errors at the launch (the policy of activation can be set forth before the launch), and mostly obviate the need to rush BLS precompile before the phase0 for the purpose of re-validating the deposits on-chain.
It will also make a temporary trust of initial Eth2 validators into the launching team explicit rather than implicit - if you trust the people who launch phase0, and you verified they control the kill-switch removal, you will put your ETH1 into the deposit contract.
There are two options that I see:
I personally prefer option 2.
Although engineering the kill-switch would add complexity to the process, it may actually enable earlier launch of phase0, because you would know that at least obvious catastrophic failures can be avoided.
The kill-switch logic can be tested many times on the mainnet, and such testing can start with low deposits way before the phase 0 launch.
I am not suggesting stop working on the BLS-precompile right now. I am suggesting to prepare it, and schedule the activation hard-fork for just after the phase 0 launch. At that point, the exact curve will be known, and you can introduce enhanced protection for deposit contract using BLS precompile, and then remove the kill-switch.
This would be a more sensible approach than fixing BLS precompile before phase 0 launch, effectively either:
EDIT: Now, after some discussion I see that it is very unlikely that the BLS curve chosen for eth2 is going to change, in fact it did not change yet. It is they that the exit address is derived that may still change. Therefore, the concerns about locking eth2 phase 0 into a wrong curve are probably unfounded.
This is just my proposal, I have no vested interest in any outcome - therefore I will not be “pushing” or “champion” it, I have lots of other things to do. But hopefully, this can get some people thinking and help start an important discussion