Ethereum- The Road Ahead

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), 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, 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)