Ethereum:

The Road
Ahead

Where are we now?

The original roadmap

OOlOym
O OpOiOcO (Launched 15.03.09)
FOro
O OnOtOiOerO O (Released 15.07.26, Genesis 15.07.30)
HOom
O OeOsOte
O OaOdO (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

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 cant reliably
disincentivize such behavior)
But we can develop specific solutions for large

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

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)

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.11% 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

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

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)