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