ETH2 in ETH1 light clients

eth2
eth1x
light-client
precompile
#1

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

9 Likes
Constrained Resource Clients: Mar 2019 Update
Ethereum Core Devs Meeting 58 - Summary
Finality gadget for Ethereum1x Working Group
#2

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.

#3

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.

1 Like
#4

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

#5

It’s here now :slight_smile:

1 Like
#6

This sounds great, but given the existing workload for Eth1.x and Eth2.0, where does this fit on project timelines? Do you see this as a stopgap until Eth2.0?