Title: ETH2_in_ETH1_light_clients
Category: Magicians

Author: vbuterin
Date: 2019-03-08T05:04:32.218Z

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

Author: tvanepps
Date: 2019-03-08T22:23:02.470Z

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

Where can I read more about what “availability engines” are? Is it at all related to something Justin mentioned at the Magician’s chat on Monday?

One research idea is a single unified Plasma chain to pay tx fees on any shard.

https://medium.com/ethereum-magicians/q-a-on-eth-2-0-ab1d5d3ac133

Author: vbuterin
Date: 2019-03-10T07:02:42.718Z

tvanepps:

Where can I read more about what “availability engines” are? Is it at all related to something Justin mentioned at the Magician’s chat on Monday?


Basically it’s a catch all term for a blockchain that is being used to store data and prove that data can be downloaded by anyone. This allows plasma-like constructions without the need for complicated exit games or 2-week waiting periods or anything like that.

Author: rossbulat
Date: 2019-05-19T06:03:04.501Z

vbuterin:

Here is a doc describing what implementing an eth2 light client would look like: https://notes.ethereum.org/s/B1DtMJZeV# 


This link brings me to a 404 Not Found. Interested in reading if it can be reuploaded.

Author: vbuterin
Date: 2019-05-19T13:14:43.061Z

It’s here now 
https://github.com/ethereum/eth2.0-specs/blob/dev/specs/light_client/sync_protocol.md

Author: alonmuroch
Date: 2020-11-04T14:12:06.096Z

@vbuterin could the light client be implemented in Solidity for example (considering BLS operations are available via precompiles)?
If so, a few questions:

Is security relies only on the selected committee? what happens if they accidentally or maliciously include an invalid block? Are there fraud-proofs that can be used to revert?
Validator set changes is a different operation than LightClientUpdate?