Ethereum’s roadmap is ambitious. In our last article, we described the Ethereum 2.0 vision.
As a recap, Ethereum 2.0 combines these key projects:
- Proof-of-stake (Beacon Chain, Casper FFG)
Once delivered, Ethereum 2.0 will support massive on-chain transaction throughput, while balancing decentralisation and security. With this foundation, Ethereum has the potential to be:
- A key piece of infrastructure for the world’s transfer of value;
- A platform for new economic systems;
- A hub for global collaboration;
Ethereum 2.0 is not being developed by a corporation; Ethereum is decentralised on multiple levels.
Vitalik says it best:
Blockchains are politically decentralized (no one controls them) and architecturally decentralized (no infrastructural central point of failure) but they are logically centralized (there is one commonly agreed state and the system behaves like a single computer)
Vitalik Buterin (Meaning of Decentralization)
Additionally, Ethereum is operationally decentralised (no single entity is responsible for keeping the blockchain running).
So if no one controls Ethereum, how is Ethereum 2.0 being built?
This is one of many fascinating aspects of Ethereum. It has an organic quality that hopefully will contribute to how human organisation can scale up but remain inclusive.
The Ethereum protocol describes the interactions necessary to produce the Ethereum blockchain. It is a massive open source project. A large community of researchers and implementors propose ideas, discuss, refine, and implement the Ethereum protocol. The Ethereum Foundation are influential in this process and have highly regarded researchers and implementors, but decisions are made by the community through consensus.
The software used to run Ethereum is called a client or node. Many Ethereum client implementations exist, written by different software development groups (all are open-source).
In addition to client implementations, there is an entire ecosystem of open source software projects working on building different aspects of Ethereum.
- Smart Contract Languages (Solidity, Vyper)
- RPC Libraries (web3js, ethers, Nethereum)
- Development Tools (truffle, ganache, solc, solium, embark)
Enough context, let’s get into the meat and potatoes.
There are many research topics under investigation that need to be pulled together to make Ethereum 2.0 work. These topics are publicly documented and discussed on the Ethereum Research site. Researchers and software developers get a chance to query and critique proposals.
The research topics include:
- Signature aggregation
- Random number generation
- Fork choice
- Data availability
- Light client support
- P2P communication
- Cross-shard communication & state/execution separation
Many of the topics have reached the point where they can be implemented, but there are equally as many that are in early stages and need more time to lock down.
As research topics mature they coalesce into a specification that the implementation teams are using to develop their Ethereum 2.0 clients.
To help in this endeavor, the Ethereum Foundation is developing a reference implementation client in Python. They also provide valuable community support to help implementation teams and a regular Ethereum 2.0 implementors call is run biweekly to track progress, answer questions, and reach consensus on common issues.
Beacon Chain / Shard Clients
The following teams are either researching or developing a beacon chain / shard client:
- Prysm- developed by Prysmatic Labs, written in Go. They have an excellent bi-weekly update on their progress.
- Lighthouse — developed by Sigma Prime, written in Rust.
- Nimbus — developed by Status, written in Nim.
- Harmony — developed by Ether Camp, written in Java.
- Pantheon — developed by PegaSys the protocol engineering group at ConsenSys, written in Java. The team are focused on key Ethereum challenges including scalability and privacy for both public and private chains.
- Trinity — developed by the Trinity team (led by Piper Merriam), written in Python.
The teams vary in their progress implementing the Ethereum 2.0 specification. At this stage, all teams are working on building a beacon chain client, which is central to the Ethereum 2.0 vision.
The beacon chain work carried out so far includes:
- Beacon chain state data structures and persistence
- Per block state transition
- Fork choice implementation
- Validator shuffling
- Block proposer role
- Data structure serialization
- P2P protocols
An essential process being discussed is the need for a common testing language that encodes test cases — enabling researchers to define a bunch of tests with expected results that each team can use to validate their implementation against the specification, providing consistency across the different teams.
eWASM is not specific to the Ethereum 2.0 approach. The project has been in development for some time by the eWASM team and is focused on compatibility with the current EVM. The eWASM team are assessing the implications of the new approach but the research is still quite early in regards to how execution will actually work.
In particular, it is likely that the new Ethereum 2.0 shard system will use a delayed execution model. The current EVM blockchain executes smart contract code immediately when a transaction is processed.
In the new Ethereum 2.0 shard system:
- Shards will be responsible for transaction ordering and storing data only
- An overlaid execution process will read transactions, execute code, and write back results
The execution overlay may be a layer 2 process built on top, rather than baked into the blockchain.