ETH2 sharding

Committees (honest majority model)

Proof of custody (anti-laziness)

Data availability proofs (see https://arxiv.org/abs/1809.09044)

Persistent committee structures (see https://github.com/ethereum/eth2.0-specs/issues/1293 )

Crosslink structure

Philosophy: "the shard chain is a decentralized block proposal mechanism, crosslinks are the blocks that the beacon chain sees"

What goes in a crosslink? (see https://github.com/ethereum/eth2.0-specs/issues/1304 )

Light clients are very important because almost no clients will be able to process the whole chain, so almost everyone will need to be a light client of something

SSZ partials (see https://github.com/ethereum/eth2.0-specs/issues/1303 and https://github.com/ethereum/eth2.0-specs/blob/dev/specs/light_client/merkle_proofs.md)

Verification path:

* You have a header at slot T
* You pick a random shard ID, S ϵ [0...1023]
* You Merkle-prove down to the persistent committee of S active between [T+1 day, T + 2 days]
* You use that committee to verify blocks on S
* You Merkle-prove from those blocks down to the beacon chain, you get a header at slot T + 1 day

Light client / light server payment channels

Light client servers as relayer market participants?

Phase 2 proposal 1: see https://notes.ethereum.org/bk5MrYgiQuCFwu-nI6gsBA#

Phase 2 proposal 2: see https://notes.ethereum.org/s/Bkoaj4xpN

How much state should shards have?

Zero state

Main argument: simplicity and allows maximum flexibility for different state schemes at layer 2

32 byte hash per execution environment

Main argument: more functionality than above, but still simple and preserves flexibility

~1-64 KB per execution environment

Main argument: allows space for storing more data to allow some proof batching etc, but still simple as the full state can fit inside a fraud proof, and preserves flexibility

Lots

Main argument: applications need state, protocol can provide it with very strong guarantee

Fee payment

See https://github.com/ethereum/eth2.0-specs/issues/1309

Relayer markets

Execution environment design

General idea: define pure function f(state, data) -> state

`state` is very small, so `data` would in many cases contain Merkle proofs.

Also requires defining:

* A "deposit" function (sending ETH to an EE generates a receipt with data chosen by the sender; this data could be accessed
* A "withdraw" function (the EE can generate a special kind of receipt that allows removing ETH from the EE)

Layer 2 state schemes, see https://ethresear.ch/t/layer-2-state-schemes/5691

OVM: see https://medium.com/@plasma_group/db253287af50

Optimistic cross-shard state: see https://ethresear.ch/t/a-layer-2-computing-model-using-optimistic-state-roots/4481

ZK Rollup, see https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477

Shadow chains (ZK Rollup but with challenge period + fraud proofs instead of SNARKs): see bottom of https://blog.ethereum.org/2014/09/17/scalability-part-1-building-top/

State provision

Merge with light client servers?