Design Choices

in Eth2.0

Aditya Asgaonkar

Ethereum Foundation

Eth2.0 Design Requirements

1. Scalability

Super-linear scaling: total throughput of the system is super-linear w.r.t throughput of a single node

• Security

Security of the system is uniform in all parts, and corresponds to consensus safety across all nodes

Eth2.0 Design Requirements

• Scalability

Super-linear scaling: if capacity of each node increases K times, then capacity of total system increases super-linearly w.r.t. K

• Security

Security of the system is uniform in all parts, and corresponds to consensus safety across all nodes

Scalability

• Sharding
• Partition the state into distinct shards
• Subsets of the total validator set are responsible for each partition

Security

• Beacon Chain
• All validators form consensus on the cumulative total state, which is the accumulation of the states of all shards

​

Combining this with the scalability requirement immediately leads to 2 conclusions!

Security + Scalability = ??

1. Beacon chain data consideration:

Cannot contain full shard data, breaks super-linear data throughput

• Beacon chain execution consideration:

Cannot execute full shard transactions, breaks super-linear execution throughput

Eth2.0 General Design

• Beacon Chain
• All validators participate & form consensus
• Only merkle roots of state from shards
• No execution of transactions from shards
• Shards
• No consensus in shards!
• Blocks validated & voted on by committee sampled from beacon validators

Eth2.0 General Design

All validators

Shard Committee

Beacon Chain

Shard Chain

1. Sample

4. Consensus

2. 2/3rd voting

3. Crosslink

Eth2.0 for Smart Contract Devs

• Changes to the dev experience, ex:
• Static State Access [?]
• Some things that devs are used to today may not be possible, ex:
• Synchronous calls to ANY other contract on the system

Eth2.0 for Smart Contract Devs

• Synchronous cross-shard transactions
• Basic problem is to make receiver shard aware of incoming cross-shard transaction
• Impossible without including more information than only shard merkle roots in the beacon chain
• This would break super-linear scalability

Eth2.0 for Smart Contract Devs

• Static State Access
• Stateless execution:
• Nodes in the network are aware of only the state root
• Transactions must include witness data for all state that they access

Eth2.0 for Smart Contract Devs

• Dynamic State Access
• TX1
• … ; ptr = SLOAD(addr); data = SLOAD(ptr); …
• Witness:

​

State Root

ptr

data

addr

ptr

Eth2.0 for Smart Contract Devs

• Dynamic State Access
• TX1
• … ; ptr = SLOAD(addr); data = SLOAD(ptr); …
• TX2
• … ; SSTORE(addr, new_ptr); …

In the same block, TX2 is included before TX1.

What happens now?

Eth2.0 for Smart Contract Devs

• Dynamic State Access
• The merkle branch to location new_ptr is missing and the block producer must now fetch it

​

State Root

ptr

data

addr

new_ptr

Eth2.0 for Smart Contract Devs

• Static State Access
• Only access predictable locations in the storage
• Then it is possible for block producers to update witness without fetching data from the network
• Block producers can infer new witness from previous included transactions

Eth2.0 for Smart Contract Devs

• The primary objective of Eth2.0 is to make a scalable & secure blockchain system
• Enabling familiar, Eth1-like execution behavior is a secondary objective

Eth2.0 for Smart Contract Devs

• Don’t freak out!
• This is ok!
• You’ll be alright!

Eth2.0 for Smart Contract Devs

​

There is no other blockchain that provides the same strong security and super-linear scalability guarantees, which offers these things!

Eth2.0 for Smart Contract Devs

!!TRIGGER WARNING!!

There is no other blockchain* that provides the same strong security and super-linear scalability guarantees, which offers these things!^

* that I know of

^ such as synchronous cross-shard transactions

Thank You

​

Twitter: @adiasg