Ethereum:

The Road
Ahead
Where are we now?
The original roadmap
● O̶l̶y̶m̶p̶i̶c̶ (Launched 15.03.09)
● F̶r̶o̶n̶t̶i̶e̶r̶ (Released 15.07.26, Genesis 15.07.30)
● H̶o̶m̶e̶s̶t̶e̶a̶d̶ (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 what’s left?
Umm, no.
So, what’s 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 (can’t
prove the miners aren’t 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), ZK-
SNARKs
● 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, what’s 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)