ETH2 sharding

Data availability verification

Committees (honest majority model)

Proof of custody (anti-laziness)

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

Shard block chains

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"

Light client protocols

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

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 (computation)

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

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)

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?