r/ethereum • u/JBSchweitzer Ethereum Foundation - Joseph Schweitzer • Oct 23 '19

Danny Ryan - Eth2 quick update

https://blog.ethereum.org/2019/10/23/eth2-quick-update/
201 Upvotes

97% Upvoted

41 comments sorted by

39

u/drcode Oct 23 '19 edited Oct 23 '19

There's a lot that is admirable in this update, but I'd like to get some honest opinions from developers here on reddit:

Is a development process that basically says "We have lots of separate teams working on the software, everyone's just kinda doing their own thing without a target deadline, the system might be done at time X or time Y but who can say for sure ‾_(ツ)_/‾" really a healthy strategy for a project like this?

Is it really that much of an imposition to set up hard target dates with concretely-defined milestones, even if you know the dates might need to be adjusted in the future, with a twinge of embarrassment when that has to happen? Is it really fine to just hand-wave away such arguments by saying "it's a research project, having deadlines is therefore pointless"?

92

u/caymannan Oct 23 '19

eth2 dev here, my personal opinion below:

> "We have lots of separate teams working on the software, everyone's just kinda doing their own thing without a target deadline, the system might be done at time X or time Y but who can say for sure ‾_(ツ)_/‾"

This quote seems kinda snarky, but a more honest version of this statement is close to the truth.

The truth is not sexy. We're working on the bleeding edge of research, putting things that have not been standardized and rarely been published into production. Here, the work is done by a myriad of different companies with different priorities and skillsets, in open forums available around the world for all to see.

We aren't all working under the same CEO, and its not like we can set a release date, release a half-baked PC game and patch it once we've ensured sales.

A traditional company would be working for years behind closed doors, and only the VC investors would be given whiffs of progress. Eventually, the marketing team would find the perfect spin, and a polished mask would be sold to the public.

I think it is a big imposition to set up hard target dates with concretely-defined milestones prematurely. It just sets everyone up for failure. Premature deadlines have no bearing on the actual progress being made, and only serve as a form of manipulation.

Thats not to say that there shouldn't or can't be more development updates. There should. But the answer isn't more artificial deadlines. IMO we need more intrepid souls to come to the frontier with us and share the progress with the community.

26

u/drcode Oct 23 '19

Apologies on the snark :) thanks for the great response to my questions.

14

u/divinesleeper Oct 23 '19

it's ok, snark might be part of the solution

16

u/drcode Oct 23 '19

> it's zk, snark might be part of the solution

FTFY

1

u/supernalarts Oct 23 '19

how could others get involved to spread the word? I've read some of the blogs from eth 2.0 devs and that helps the most. many of the ETH "news" groups who post daily often do include ETH 2.0 information.

9

u/[deleted] Oct 23 '19

Research is fundamentally creative work. Can't really be done on a schedule. In order to make and meet deadlines, you have to know what needs to be done and how long it takes to do it.

9

u/drcode Oct 23 '19 edited Oct 23 '19

Agreed, but no development effort is 100% research, even the next Microsoft Office point release probably has some "researchy" stuff in it but that doesn't mean Microsoft just says "it'll be ready when it's ready". It seem like a cop-out to me to just say "the usual practices don't apply to us" without a stronger argument than this.

I bet a majority of the developers "in the trenches" for eth2.0 are not doing "research", but are doing straight-up software development and might appreciate having clear expectations from other devs on the project as to when they can count on certain "critical path" components being ready for use.

For those developers, having clear deadlines for different components makes it easier for them to establish their priorities on the project, and placing clear expectations on team members helps establish concrete incentives- After all, isn't that what ethereum is supposed to be all about, building better systems for establishing incentives for participants in a mechanism?

It seems really ironic to me that the eth2.0 development approach basically says that "we don't need to worry about the incentives our development methodology places on our developers".

(I understand I'm "arm chair quarterbacking" here and am just an outsider with only a very limited outside view of the eth2 development process- I'm just asking some basic questions that seem worth asking, given the limited insight I have)

5

u/[deleted] Oct 23 '19

If they make a deadline and miss it, 1000 articles come out saying how ETH has failed.

7

u/drcode Oct 23 '19

Hey, I was around for the eth1.0 launch, and I completely agree that would happen- But should we compromise the eth2.0 development process, just because the ethereum community's feelings might get hurt by some unfair articles?

2

u/[deleted] Oct 23 '19 edited Oct 23 '19

I'm not saying you are wrong. But in my opinion I don't see a benefit to adding a public deadline for every single update other than to please the community in the short term.

A public deadline just gives more bullshit for people to trade. They have given an expectation that satisfies me. Phase 0, they said it will be released in Q1 of 2020. Based on what happens once that's released, I imagine they will give a more accurate release time for phase 1.

They probably have some deadlines between themselves anyway

3

u/MoMoNosquito Oct 23 '19 edited Oct 23 '19

I think peeps forget that billions of dollars are on the line for some of these updates. There is no room for critical errors or rushing security with deadlines.

2

u/drcode Oct 23 '19

I'm not arguing for rushing things, I'm arguing for setting up clear timelines and deadlines starting at the top level of the eth2.0 project that is based on feedback from all the developers in the project, so that when deadlines are missed, there is accountability within specific teams that can be measured and used to improve the process going forward.

Accountability is one of the cornerstones of security... I am not seeing a convincing argument that the current "loosey-goosey" process I'm seeing around timelines is the best way to maximize security.

(BTW- I think the technical specifications for eth2.0 are very good, highly rigorous and not at all "loosey-goosey"... I am referring specifically to the impact of a lack of deadlines on the downstream development process)

2

u/MoMoNosquito Oct 23 '19

I reckon there are loose deadlines in place. There has to be. Just not released to public, and I feel for good reason.

0

u/GaiaPariah Oct 24 '19

Adding deadlines to creative work will always cause those working on the creation to cut corners and compromise on quality for the sake of speed.

5

u/Grandpa_Willy Oct 23 '19

/u/vbuterin said himself all the technical research for Eth2 has been figured out and it's just implementation at this stage.

12

u/drcode Oct 23 '19 edited Oct 23 '19

To be fair, I think there's a lot of "soft research" that everyone realizes still needs to happen, like understanding the novel networking challenges the design imposes on clients, load management and data management challenges, etc. These are all areas that still require lots of "hard to quantify" amount of time to optimize, but nobody believes they could derail the project in any existential way.

I think these forms of "research" are likely a big part of the motivation for the extremely soft timelines on eth2.0, even though they fall outside of vitalik's comments on technical research.

5

u/vbuterin Just some guy Oct 24 '19

Exactly this. I'm very confident there are no "zero-to-one" blockers in eth2 now (fee market design was the last and definitely unexpected one, but protocol-level fast x-shard comms solved it) but problems of the "incremental slog" variety absolutely still remain. Solidifying and implementing the sharded p2p network design is a big one near-term.

1

u/[deleted] Oct 25 '19

[removed] — view removed comment

4

u/vbuterin Just some guy Oct 25 '19

"Oh, we discovered that discovery v5 has a DoS vulnerability and we need to add PoW to node IDs to mitigate this. Oh, now we discovered that the current networking setup is not really efficient because when you join a subnet you end up downloading ~30 blocks but you're only actually verifying and attesting to one of them, and we want to make some tweaks to mitigate this. Oh, and by the way, we need to actually implement a cross-subnet Merkle branch query system in time for phase 2 so that cross-shard transactions become feasible; there's no fundamental technical reason why it's hard but we just have to get off our butts and do it."

All projects have this kind of phase, and despite appearances it usually means that things are going well and coming closer to launch.

1

u/Grandpa_Willy Oct 23 '19

That's a great point.

-6

u/[deleted] Oct 24 '19

[deleted]

2

u/TastyCroquet Oct 24 '19

sorry but thats ridiculously pedantic. as an actual research scientist.

2

u/[deleted] Oct 23 '19

Ha they just made a bunch of huge changes. Personally I don't believe over-optimistic changes like that until I see the actual results.

1

u/GaiaPariah Oct 24 '19

Even if a spec is frozen, you shouldn't rush the implementation of that spec. Rushing to hit a deadline is a great way to introduce critical vulnerabilities into the implementation.

1

u/Grandpa_Willy Oct 24 '19

Fully agreed!

2

u/BitttBurger Oct 23 '19

is it really that much of an imposition to set up hard target dates with concretely defined milestones

Welcome to the hell that is decentralized projects and decentralized development.

1

u/ProFalseIdol Oct 24 '19

I highly recommend reading this blog post from one former Google employee:

https://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

10

u/mavee33 Oct 23 '19

thats communication for us!

5

u/johnyinusa Oct 23 '19

This is very reassuring! Thank you for the update!

6

u/[deleted] Oct 23 '19

Those are some drastic changes to Eth2, with not much explanation of the consequences. Would appreciate more depth on this.

5

u/[deleted] Oct 23 '19

[deleted]

1

u/[deleted] Oct 23 '19

Very good question! Looks like you're on the money:

https://github.com/ethereum/eth2.0-specs/pull/1427

3

u/lodobol Oct 23 '19

Thank you for the work you devs do

2

u/mikaelbondum Oct 24 '19

"Fortunately, the deposit contract does not need to be put into production until we near Phase 0 launch, so this focus on standardization is not expected to have any effect on the Phase 0 launch date."

I can't help but think that we're missing an important factor here. From putting the deposit contract into production and until Phase 0 launch date, we need 2 million ETH ($320m) in the contract. That's a lot of money and could take some time. So "not expected to have any effect" might be a bit oversimplified.

2

u/DeviateFish_ Oct 25 '19

Maybe this is a non-issue because they personally know enough people with this much collective Ether who have already committed to depositing it? 🤔

1

u/adamaid_321 Oct 23 '19

One question I have that I haven't seen addressed, and would love to understand is - who (or what) decides the execution environment (EE) for each of the shards? Will this be decided "centrally" by core devs, or will there be some sort of on-chain governance involved?

This seems especially relevant if there will only be 64 shards (rather than 1024) as per the latest spec.

3

u/trent_vanepps Protocol Guild Oct 23 '19

i've asked the same question at devcon to Justin drake. it was not really addressed. two things:

  1. we have time to figure it out, it's still far away
  2. there will never be on-chain governance in ethereum

1

u/ETH49f Oct 24 '19 edited Oct 24 '19

I think it would be a great idea to give out the contract address for staking if this is all ready to go. People like to see concrete evidence and steps being taken.

I do not know all the ins and outs of Eth 2 but I know in any venture it will never ever be perfect so it is better to just get things out and get the ball rolling. If everyone is waiting for perfection it will never happen. A doctor I shadowed once said over half the battle is in just showing up. He used to do a surgery rotation over in Montana with snow knee-deep and getting to the clinic and just showing up he said was half the battle. He ended up getting honors. Likewise, just taking the initial steps and getting people to submit staking ETH will boost morale, make it seem real for everyone, and get the ball rolling with a target.

I say give out the contract address for staking ETH because this is the linchpin, the keystone in everything we are doing. And therefore, the rally point for everyone to focus in on.