Here is a doc describing what implementing an eth2 light client would look like: https://notes.ethereum.org/s/B1DtMJZeV#
It is written in an abstracted form that depends on the phase 0 and phase 1 specs here, but the gist is that it’s ~80 kilobytes of Merkle multi-proof verification (see here for an implementation of compact Merkle multi-proofs) every ~9 days plus verifying a BLS aggregate signature to verify a new block header. The size of the stored state is as written largely ~30 kilobytes of validator data, though this could be shrunk to just ~10 kilobytes (pubkey + balance for 256 validators).
The validator set update procedure gas cost seems low enough to process within one block:
- 80 kilobytes * 68 gas = 5.4m gas
- Saving 10 kilobytes = 2m gas (assuming you use the dirty trick of saving it as contract code, which is fine because the data doesn’t need to be modified)
- Hashes: ~3200 * 42 = 134400 (goes up to ~2.56 million if we use SHA256 instead of Keccak!)
It’s slightly over 8m, but that could be fixed by cutting the gas cost of tx data, which we want to do anyway. However, the block header verification procedure is complicated by the fact that it requires one pairing and 128 point additions in BLS-12-381, which eth1 currently does not support, and which is extra-inefficient in eth1 because it requires 384-bit numbers. This could be fixed by adding BLS-12-381 as a precompile in eth1, either as a standalone exception or as one of the first precompiles “implemented in WASM” as per the plan we discussed at the Stanford workshop (preferred).
But if we have that, then an eth2-in-eth1 client is actually not that hard, which opens the door to applications that use eth2 as an availability engine (ie. things like Plasma but waaay more powerful).
