How to attempt an eth2 delay in five steps: 1. Create a weird way of making a deposit. 2. Claim it’s a bug. 3. Claim eth 1 now has to do something, giving timetables over to them. 4. ???? 5. Profit?
Ethereum 1.0 devs are suddenly claiming ethereum 2.0 has to wait for them to incorporate an upgrade of BLS signatures to verify malformed deposits.
“We want Berlin to be before the deposit contract is launched so that it can use the BLS Precompile,” James Hancock, the eth1 hardfork coordinator says, with Hancock suggesting the deposit contract should not go out before Berlin, “but, we are flexible as to when that should be to support the Eth2 roadmap,” he says.
Berlin being the planned upgrade of ethereum 1.0 which includes tons of things that are set to go through in June, although far more likely the estimate is ‘god knows.’
Plenty of those Ethereum Improvement Proposals (EIPs) are interesting and useful with one potentially including improvements to facilitate further zk tech.
Compared to the BLS signature upgrade, however, arguably none of the other EIPs matter at all as far as probably some 90% or more of ethereans are concerned.
Hence it isn’t clear why they are not making an emergency BLS upgrade including just the signatures bit, with it arguably doable very quickly.
Nor is it clear who Hancock is referring to by “we.” Trustnodes asked for clarification, but has received no response in time for publishing.
We suspect by “we” he is referring to eth1 devs, not least because the eth1 call notes suggest it would be useful if an eth2 dev/researcher can take part next time.
One eth2 researcher we spoke to who doesn’t want to be named re-iterated the eth1 BLS upgrade is not necessary.
“BLS12-381 curve EIP is helpful anyway, it’s important for a future eth1<->eth2 bridge especially. It would also make stronger security for the deposit contract, but this enhancement is not critically ‘required’. Other client devs may have different opinion though,” he says.
There’s a conference currently going on, so Danny Ryan, the eth2 coordinator, has probably been a bit too busy to respond to our requests for comment.
Making it a bit unclear just what exactly is the “official” plan now, but we are told the deposit contract should hopefully be finished by April.
These developments are fairly new, with eth1 and eth2 being different teams working on very different things, so there might be a bit of confusion as different things are said, but the deposit contract User Interface (UI) is to be showcased at EthCC next week when there should be a lot more clarity.
Presumably if you deposit through this UI there shouldn’t be any malformation, and thus there shouldn’t be any problem.
As such if other devs want to form their own deposit methods then expecting them to do it in a well-formed way is perhaps the minimum.
Hence presumably why the eth2 researcher is stating the eth1 BLS is not necessary, and thus eth2 doesn’t have to wait for it, but obviously it’s desirable and maybe even preferable if it goes out by April.
Waiting on eth 1 however is probably something eth2 doesn’t want to do because it would lose control over its own timelines over which quite a few eth2 devs have staked their reputation, including Justin Drake who has stated he would consider it a failure if eth2 doesn’t launch this year.
UPDATE: Ben Edgington, an ethereum 2.0 client developer, says:
“We haven’t had an Eth2 devs call since this came up, so no chance to discuss yet. My thoughts, adding some more elliptic curve precompiles has long been on the agenda for Eth1. It is not necessary to do this for Eth2, but is a nice to have.
It provides a an extra layer of checking if people screw up sending their deposit data to the deposit contract.
The proposed BLS-only version of the EIP is an attempt to simplify it for quicker implementation. Alex Stokes is working on this, and is an Eth2 dev.
Depending on timing of Berlin, Eth2 contract deployment may wait for this, or we may go ahead without it, I guess – as I say, we haven’t discussed it together yet.”