ETH2 sharding
Phase 2 (computation)
Execution environment design
State provision
Merge with light client servers?
Layer 2 state schemes, see https://ethresear.ch/t/layer-2-state-schemes/5691
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/
ZK Rollup, see https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477
Optimistic cross-shard state: see https://ethresear.ch/t/a-layer-2-computing-model-using-optimistic-state-roots/4481
OVM: see https://medium.com/@plasma_group/db253287af50
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)
Fee payment
See https://github.com/ethereum/eth2.0-specs/issues/1309
Relayer markets
How much state should shards have?
Lots
Main argument: applications need state, protocol can provide it with very strong guarantee
~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
32 byte hash per execution environment
Main argument: more functionality than above, but still simple and preserves flexibility
Zero state
Main argument: simplicity and allows maximum flexibility for different state schemes at layer 2
Phase 2 proposal 2: see https://notes.ethereum.org/s/Bkoaj4xpN
Phase 2 proposal 1: see https://notes.ethereum.org/bk5MrYgiQuCFwu-nI6gsBA#
Light client protocols
Light client / light server payment channels
Light client servers as relayer market participants?
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
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)
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
Shard block chains
Crosslink structure
What goes in a crosslink? (see https://github.com/ethereum/eth2.0-specs/issues/1304 )
Philosophy: "the shard chain is a decentralized block proposal mechanism, crosslinks are the blocks that the beacon chain sees"
Persistent committee structures (see https://github.com/ethereum/eth2.0-specs/issues/1293 )
Data availability verification
Data availability proofs (see https://arxiv.org/abs/1809.09044)
Proof of custody (anti-laziness)
Committees (honest majority model)
