On BLS precompile for ETH1, and its relation to ETH2 launch
By BLS-precompile, I mean this EIP: https://eips.ethereum.org/EIPS/eip-2537
BLS-precompile for phase 0?
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.
BLS-precompile for phase 1?
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.
Deposit contract and possible failure of phase 0 launch
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:
- A new, fixed phase 0, is launched, using the same deposits as the previous, failed launch. This assumes that the problem can be fixed without changing the deposit contract. Crucially, this does not address the issue of wrongly specifying exit addresses (therefore calls for extra on-chain validation via BLS precompile).
- Hardfork on ETH1 is proposed, and (fingers crossed), activated, to reverse the deposits. I hope you agree this is a very messy scenario.
Kill switch for deposits
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.
Who would activate (or remove) the kill-switch?
There are two options that I see:
- Kill switch activation or removal is the responsibility of the team that launches phase 0, or a certain commitee. It will do so if it is obvious that there are some fixable problems with the launch.
- Kill switch activation or removal happens via a vote of depositors. This way can potentially obviate any legal or societal risks to the launch team, but introduces some voting complexity.
I personally prefer option 2.
What about additional complexity?
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.
How would it all play together?
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:
- locking phase 0 on the chosen curve, or
- taking the risk of phase 0 launching with a different curve anyway, making the activated precompile a bit less useful
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.
Conclusion
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
On BLS precompile for ETH1, and its relation to ETH2 launch
By BLS-precompile, I mean this EIP: https://eips.ethereum.org/EIPS/eip-2537
BLS-precompile for phase 0?
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.
BLS-precompile for phase 1?
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.
Deposit contract and possible failure of phase 0 launch
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:
Kill switch for deposits
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.
Who would activate (or remove) the kill-switch?
There are two options that I see:
I personally prefer option 2.
What about additional complexity?
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.
How would it all play together?
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.
Conclusion
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