'95% Confidence': Ethereum Developers Pencil In July 2020 for Eth 2.0 Launch

What are the odds they pull it off this time? Already delayed once.

We will see. It’s hard to move to sharding once your original architecture was based on a monolithic blockchain. Not only because there are miners, and so on. But because Ethereum is based on smart contracts and balances, so making each smart contract live on a shard will result in some being very valuable targets to try and attack the consensus. If the consensus is about something really valuable, it’s really got to have good security.

Here is how complicated it is, according to the Ethereum community:

In their own words:

Currently, in all blockchain protocols each node stores the entire state (account balances, contract code and storage, etc.) and processes all transactions. This provides a large amount of security, but greatly limits scalability: a blockchain cannot process more transactions than a single node can. In large part because of this, Bitcoin is limited to ~3–7 transactions per second, Ethereum to 7–15, etc.

However, this poses a question: are there ways to create a new mechanism, where only a small subset of nodes verifies each transaction? As long as there are sufficiently many nodes verifying each transaction that the system is still highly secure, but a sufficiently small percentage of the total validator set so that the system can process many transactions in parallel, could we not split up transaction processing between smaller groups of nodes to greatly increase a blockchain’s total throughput?

And here is from https://github.com/ethereum/wiki/wiki/Sharding-introduction-R&D-compendium

Ethereum 1.0 can only process 7-15 transactions per second, the goal of sharding is to partition all network computational resources into shards, so that a node (a single computer as a peer connected to the network) doesn’t have to process (download, compute, store, read) every transaction in the history of the blockchain, in order to make a new transaction (write and upload) or otherwise participate in securing and using Ethereum; rather a node can just participate in a single shard, or more if it so chooses. Multiple shards are handled separately by different subsets of securing participants, aka securitors (which include notaries, proposers, miners and validators)[1]. The primary goal is a massive scalability improvement, potentially exponential in phase 6 of the roadmap, although Vitalik questioned whether exponential sharding will even be tenable in an ethresear.ch thread.

I asked a question about what the shards will have, in their reddit AMA, but didn’t get an answer:

I have already heard something like this so many times that I do not have the slightest confidence in such statements, I would not be surprised if we read such a post again in a couple of years

Another miscalculation of the deadline from the Ethereum team. That’s sad. With such problems, “Berlin” will not be implemented in the promised time. This is bad and a blow to Ethereum’s reputation.