The State of Ethereum 2.0 Executive Summary 1 Overview 1 Interview Methodology 2 Observations and Potential Consequences 2 Implementation Teams are Committed, But Funding Is A Concern 2 The Spec Continues To Churn, But It’s Getting Better 3 Implementation Teams Do Not Push Back Against Research...
"The State of Ethereum 2.0" imo illustrates how we're talking about a scientific experiment and not just software implementation. "Possible that new research will invalidate or otherwise reshape the roadmap profoundly". https://t.co/ZLMEB8Ptjohttps://t.co/Vy7ap0m9oB
RT @RyanSAdams: This is the closest thing I've seen to a concerned letter from investors to @ethereum & the Ethereum community
I use the term investors to cover anyone who's invested code, money, energy, time, & passion into the Ethereum network
We want Serenity to succeed!
(cc @fredwilson) https://t.co/mjSMtVg76V
I'm late to the party, but what follows is the take I shared with some colleagues.
I have reservations about the analysis, conclusions and recommendations of that article. It reads like a report from a consultant that's just dropped in, applied a grid, but fundamentally doesn't "get it". Ameen presented it at the Eth 222 meeting in Stanford last weekend, and I tuned in via livestream.
Now, I have an "insider's" viewpoint, so I am biased and defensive, but I don't think that tending towards central control is the right solution. It's the easy solution, for sure, but just turns us into another Cardano/Polkadot/Dfinity look-alike. Radical decentralisation and inclusivity are Ethereum's super-power in my view, and I'll argue against things that threaten these. Of course there are things to improve, possibly many things, but I think the focus of our efforts ought to be on doing decentralised R&D better, not getting all old-school about it.
In case that comes across as unduly negative, let me add that I totally welcome Kyokan/Moloch DAO and appreciate their good intentions and support for the effort. These are important topics to discuss; I just think we should be cautious about easy fixes.
[Context, I put together the PegaSys Eth2 R&D team at ConsenSys and have been involved since before it was Eth2. Unfortunately I had to miss the discovery call that they had with my team as it was late on a Saturday evening my time and I had other things to do - I'm sure Ameen will forgive this :-) ]
It is baffling to me that there is no lead this far along. You needn't reinvent development processes to build a decentralized system. This is well-tread ground, and plenty of hard-learned lessons can be leveraged to improve this process.
Example: all efforts can be weighed by how they affect the goals with the lead canvassing the contributors and building consensus. Each significant spec change could be weighed on two axes: "Nice-to-Have vs. Need-to-Have" and "Delays Ship Date to Accelerates Ship Date".
Why do we need 9 implementations of the same spec? If funding is a concern, there should only be 3-4 implementations, based on current network usage (Go, Rust and Java?) and funds should be concentrated for those teams. I understand no one asked these teams to develop all these clients but can we get someone to provide guidance on which clients to build? We don't have endless amounts of capital.
Also, more teams do not lead to faster development. The "mythical man month" is real.
im a noob but considering the size and complexity of this project, it looks like there's pretty good awareness and communication on both its internal and external affairs. Im only a noob but i can tell ya one thing, democracy is messy and sometimes slow.
It looks like developers are devoted to success as long as they are funded, which is a reasonable concern in the current market.
if the hesitancy to have a "2.0 lead" comes from wanting to be decentralised... at this point it seems that decentralised development and governance in general doesnt work well....... that is to say not nearytly as well as traditional development... and not neccessarily less easily biased by any individual either
if it comes from wanting to avoid personal social or legal responsibility then "fair enough" but i think there will be someone capable and willing to step forward for that role if none of the researchers want to.....
reagrdless, for what its worth, i would suypport the funding of kyokan moloch and i think project management can still be done in a somewaht decentralised manner to some extent assuming that there is maintained a separation of economic/ specification decisions which would come from researchers, community and implementers/whoever else and timing/implementation decisions which would come from the pm, that is to say -- their role is not to make the ""important"" decisions but to make sure that other people do in a timely manner.... in this way i think pm does not cross too many boundary s
I think I agree with everything but the TC39 process. TC39 is built around having adoption in 2 major platforms basically in the final iteration for a significant amount of time. It seems WAY SLOW by design. I think the crypto world is moving too fast for that kind of churn here
What’s the source? His word that he heard this from actual ETH 2.0 implementers? Who says this article wasn’t made up for his or her own benefit?
I take articles like this as grains of salt when self-promotion like the following are said (under a heading at the end, titled: “How Kyokan/Moloch Can Help”):
“How Kyokan/Moloch Can Help
Kyokan is a blockchain-native software consultancy based in the bay area. In the past, we have worked with MetaMask, SpankChain, Cosmos, Dfinity, and Uniswap. In addition, we received a grant from the Ethereum Foundation to build an implementation of Plasma MVP, which is currently preparing for mainnet launch. Our team has significant experience shipping production software at prominent consumer and enterprise tech companies.
Moloch is a grant-making DAO / Guild and a radical experiment in voluntary incentive alignment to overcome the "tragedy of the commons". Our objective is to accelerate the development of public Ethereum infrastructure that many teams need but don't want to pay for on their own. By pooling our ETH and ERC20 tokens, ETH investors and teams building on Ethereum can collectively fund open-source work we decide is in our common interest.”
Did you read the article? We explained our methodology. We interviewed the team leads of 5 projects and Danny Ryan, the de-facto ETH 2.0 lead and who has been coordinating ETH 2.0 calls.
This article *was* written for my benefit—I am considerably invested in the future of Ethereum and want it to succeed. It was also intended for the benefit of the ETH 2.0 engineering teams, other projects building on ETH, ETH holders, and the greater ETH community.
I read the article but it’s hard to trust these things were actually said by team members when the quotes are supporting the ultimate recommendation at the end of the article that benefits you.
I’m not saying that you’re lying or that the things discussed in the article aren’t current issues but it’s easy to throw quotes around text. Perhaps you should contact the team members and see if they are ok with having their names associated with their quotes. It’ll be more persuasive that way.
To be clear, I’m just not sold on you listing the team names and stating the following:
“We now present our findings from the interviews described above. Quotes from individual interviewees are placed in quotation marks, and are reproduced verbatim.”
If they are quotes from individual interviewees, then you should at least have one or two who are comfortable putting their names next to the quotes. It’s not like they would be bashing Ethereum. They would be constructive criticism to help move things forward.
>If they are quotes from individual interviewees, then you should at least have one or two who are comfortable putting their names next to the quotes. It’s not like they would be bashing Ethereum. They would be constructive criticism to help move things forward.
Agreed, would be nice to directly attribute people to so called quotes. But the fact is that today, valid concerns exist about our inability to implement basic network upgrades and those who voice their concern are shouted down. This gives a very fair reason to doubt our ability to implement Ethereum 2.0. This isn't about the price of ether at all. The future of where this technology will take us is self-evident and it would be a shame if Ethereum pissed it away due to what amounts to a basic coordination failure between the various stakeholders in this platform.
\*Edit\* reread your post and it saddens me even more. You are one of the few quality posters here and you seem to be more concerned with defending the integrity of "team members" than you are the platform itself. May I ask you - what exactly constitutes a team member? It is the product that matters, not the individuals involved, and our criticism is aimed at our collective inability to improve the platform.
I’m only suggesting that names should be put on these quotes because it would help legitimize this article and also so people implementing ETH 2.0 would know who to reach out to. Articles like this is a way to interview multiple teams and collectively present their feelings on various issues. But without an identity to those statements, anyone within the various other teams won’t know who to contact to help fix these problems. This is why I say this article is taken as a grain of salt for me especially because it uses its quotes for only its own purpose (I.e., its self serving recommendation).
The things that drive Ethereum 2.0’s “narrative” - i.e., when it’ll ship, what it’ll be useful for, and how developers can use it - is driven more by posts like Prestwich’s than Prysmatic’s since the information is more directly relevant to the day-to-day work of Ethereum’s users. We commend the Ethereum 2.0 teams for their commitment to transparency, and obviously want technically-focused updates such as the one above to continue. However, if nobody from the research or implementation teams provides additional context around when Ethereum 2.0 will be ready and what it will look like when it is, others will continue to step in and do it for them. As a result, it will be difficult for correct expectations to be set and lived up to.
Not saying that this is the responsibility of the research or implementation teams, but it is certainly a responsibility of the community as a whole. Uncertainty around what ETH 2.0 has a real impact - unless you are very deep in the ethereum R&D community, it's not easy to figure out what the transition will mean for a given app. We can do much better in answering those questions and responding to concerns or confusion.
> nobody from the research or implementation teams provides additional context around when Ethereum 2.0 will be ready
I've repeatedly shared my rough ballpark figures: 2019, 2020, 2021 for phases 0, 1, 2 respectively.
Phase 1 is significantly simpler than both phases 0 and 2. I expect it to come relatively soon after phase 0. Phase 1 can provide scaling by being the data availability layer for L2 execution engines such as Truebit.
I think you might have taken that out of context a little. It took me reading James Prestwich's post to understand what each stage of ETH 2.0 means _for me as a dapp developer_, not to mention what it means for the greater ecosystem (i.e. wallets, block explorers, dev tooling...) which go beyond the "rough ballpark figures" for the phases of ETH 2.0 delivery.
While we're on the subject, do you think there is there any way to make ETH 2.0 happen faster? E.g. position ETH 2.0 teams to start Phase 1 spec engineering _immediately_ after Phase 0 spec engineering is complete? It would require separate resources on standby to push Phase 0 to production in parallel.
Yes, there are various "obvious" parallelism opportunities which should get naturally exploited.
The hard part of phase 1 is getting libp2p/gossipsub production-ready to handle many (at leat one per shard) gossip channels with frequent shuffling of validators across those channels. Spec- and consensus-wise there's almost no meat in phase 1. We already have separate networking teams doing parallel work (e.g. the core libp2p team from IPFS/Filecoin). It's possible that phase 1 could be "considered done" before phase 0 is fully deployed.
Somewhat similar is phase 2. One hard part of phase 2 is getting WASM to be production-ready in a blockchain environment (e.g. deal with metering, JIT bombs, ...). There are ~10 other next-gen blockchain projects building on WASM and their parallel work and lessons learnt should be reusable for Ethereum 2.0.
With all due respect it's probably not enough to communicate a 2 to 3 year plan. It may satisfy your direct reports but not the greater community. It's unrealistic to expect people to not be concerned given the Ethereum development track record, perhaps doubly so with Vitalik stepping back. I hoped by now there would be clear leadership and commitment towards goals but this doesn't appear to be happening. I'm aware that "Uncertainty is the only certainty there is, and knowing how to live with insecurity is the only security." but are others?
Are you concerned for the development of Ethereum 2.0 or for the development of your personal wealth? Your post comes off as the latter. Vitalik and company aren't doing what they're doing to enrich you or to satisfy shareholders. If your concern is around this then it's misplaced and irrelevant. If your concern is for the former...then maybe relax a little and let them build? Good things take time and this has never been done before.
It would be nice to see you on a dev call here and there.
It's painful to watch what is currently unfolding as there is zero leadership and project management. And yes there needs to be some leadership, or nothing gets done (see last weeks ProgPOW discussion).
I'm on almost every 2.0 call. I don't focus on progpow because I honestly think progpow vs no progpow means little in the grand scheme of things compared to much more important things like 1.x (I was at the 1.x workshop in SF a week ago) and 2.0 (I was on a 2.0 call yesterday).
If you're focusing on core dev progpow debates, you're focusing on a place other than the place where the most meaningful action is.
Agreed, the peanut gallery will always provide a cacophonous background of criticism because, for most of us, that’s all we are capable of contributing to a project of this complexity, one which blurs the lines between idealism, practicality, and magic. In the end you will have permanently changed the world in a way that perhaps only a few dozen in history have. Keeping a high level, long term view is appropriate. Thanks for all you do, for your amazing patience, and your generous willingness to engage us in the revolution.
Keep doing what you’re doing. The people getting their panties in a bunch probably have never built a company before and don’t understand the extreme difficulties that go with it. You are building a new internet and none of us really can relate. Perhaps they are mistaking 2.0 for some new feature on a neat website rather than an entire new internet. Some startups I know that are building basically a copy of Wordpress have been in stealth mode development for as long as Ethereum has been around, and still haven’t launched!
> Some startups I know that are building basically a copy of Wordpress have been in stealth mode development for as long as Ethereum has been around, and still haven’t launched!
Many startups die like that.