You are on page 1of 32

Ethereum:

The Road
Ahead

Where are we now?

The original roadmap

Olympic (Launched 15.03.09)


Frontier (Released 15.07.26, Genesis 15.07.30)
Homestead (Released 16.02.29, hard fork 16.03.14)
Metropolis
Serenity

Where are we?


Running for 5+ months without consensus failures
Successfully, smoothly completed homestead hard fork
transition (with 2 weeks notice)
100+ dapps (http://dapps.ethercasts.com)
~0.25 TPS (10% of bitcoin), ~6400 nodes (90% of bitcoin)
on live network
100000+ accounts
200+ meetups around the world

So whats left?

Umm, no.

So, whats left?


Ethereum is meant to be a world computer: a
decentralized network that tries to simulate the
properties of being a single computer as much as
possible, while adding blockchain authenticity and
security guarantees on top
So, where does it still fall short?

Privacy
All info on world computer is public
Creating Ethereum but with privacy is hard, carries very
serious efficiency and complexity tradeoffs, and possibly
impossible under an economic security model (cant
prove the miners arent all talking to the NSA, so you can
t reliably disincentivize such behavior)
But we can develop specific solutions for large
categories of applications

Who cares?
Financial institutions (incl private/consortium chains)
Ordinary users (who want privacy of their coin
transaction history, identity data, etc)
Decentralized financial applications (non-privacy may
lead to market manipulation opportunities)
Lack of privacy makes censorship easier, which makes
attacks easier

How do we do it?
Digital assets: linkable ring-signature + additively
homomorphic value encryption (ozcoin style), ZKSNARKs
N-party smart contracts: state channels, Hawk
Voting: linkable ring-signature
Data storage: plain old encryption (ECIES works well w/
existing ethereum crypto), secret sharing
Identity: linkable ring signature, ZK-SNARKs

These solutions do not need to be implemented in


Ethereum directly; they can all be built on top. So what do
we need to do?

How do we support privacy?


Problem: implementing much of that on the current
EVM is too inefficient (eg. ECRECOVER 3000 gas native
vs 750000 gas in EVM code)
Short term: add custom opcodes (ECADD, ECMUL,
MODEXP) for commonly-used computationally
intensive operations
Short term: EIP 101 (see later)
Longer term: WebAssembly VM

Scalability
Problem: every node processes every transaction. This
means the network can never be more powerful than a
single node
Just increasing block size carries centralization
tradeoffs (5 nodes in data centers, etc)

Scalability
Solution path 1: lightning networks / state channels
(eg. Raiden)
Solution path 2: sharding (Ethereum 2.0)
Essentially, create a network that can survive with no
full nodes at all
Each computer stores/processes at most ~0.1-1%
of the state/transactions

Scalability

Casper (PoS)
How I usually describe proof of stake: virtual mining
Casper: improved consensus algorithm based on
consensus by bet
Idea: bonded validators make transactions called bets
that give them profit in some histories at the expense
of loss in other histories

Casper (PoS)
This process converges, and over time one history
becomes favored
Finality: of validators stake their entire deposits on
one particular history, losing all funds in other histories

Efficiency
VM efficiency
WebAssembly VM
Block times
Casper by-block consensus
Merkle tree proof efficiency
EIP 104, tree structure changes
Consensus efficiency
PoW -> PoS

Abstraction
Currently, there are 2 types of accounts: externally
owned accounts (EOAs) and contracts
All EOAs use ECDSA + sequence numbers as a security
mechanism
EIP 101: reduce to one type of account, put security
mechanisms into EVM code
Transactions come from zero address, user accounts
check signatures and forward messages

The Higher Level


User-level security (multisig wallets, natspec, etc)
User experience (Mist)
Light client (desktop, phone, IoT, etc)
Short-term scalability improvements (eg. state tree
pruning)
Developer tools (Mix, formal verification, compiler
improvements)

The Higher Level

The Higher Level

So, whats the plan?

Rollout strategy (Casper)


Phase 1: start the Casper contract running, let it vote
on state roots only; PoW for blocks continues, delay
ice age
Phase 2: allow voting on block hashes, soft fork in fork
choice rule based on block hash votes, PoW continues
as initial bivalence breaker
Phase 3: take off PoW training wheels, go pure PoS

Rollout strategy (VM improvements)


Phase 1: EIP 101, move more parts of the protocol into
the state tree
Phase 2: introduce precompile opcodes, deprecate
old-style transactions
Phase 3: VM swap

Rollout strategy (Scalability)


Phase 1: EIP 105
Phase 2: Ethereum 2.0 (basic sharding)
Phase 3: Ethereum 3.0 (infinite sharding)

Rollout strategy (Pandas)