EIP-1011: Hybrid Casper FFG / Ethash

[5chdn]

http://eips.ethereum.org/EIPS/eip-1011

[rphmeier]

I can take it (edit: busy with Polkadot stuff; can mentor implementation)

[5chdn]

I'm on it to figure out the specs.

[vbuterin]

Would be happy to provide any assistance or support.

We will try to prioritize improving documentation asap. In the mean time, there's the paper and the python code:

http://github.com/karlfloersch/docker-pyeth-dev
https://github.com/karlfloersch/pyethereum
https://github.com/karlfloersch/pyethereum/tree/develop/ethereum/hybrid_casper
http://github.com/ethereum/casper

I recommend starting with the fork choice rule (priority 1: highest justified epoch #, priority 2: max total diff) and the validator logic.

[5chdn]

cc @pipermerriam

[5chdn]

http://notes.eth.sg/MYEwhswJwMzAtADgCwEYBM9kAYBGJ4wBTETKdGZdXAVmRvUQDYg=?view

https://arxiv.org/abs/1710.09437

[rphmeier]

The paper is pretty good documentation for a start.

Initial engineering concerns:

• BlockChain currently holds the whole fork-choice decision, based only on total difficulty. Parts of this will need to be deferred to the Engine.
• Engine needs to get a persistent data store to keep track of any votes targeting non-finalized checkpoints to avoid violating slashing conditions. This brings complication due to snapshot restoration replacing the DB in-place.

[vbuterin]

does a smart contract keep track of votes and justified checkpoints?

Yes. The Casper contract basically keeps track of everything.

How are light clients meant to track finality?

Probably via a special-purpose protocol, like randomly selecting 50 validator indices and verifying that valid votes for enough of those validators exist.

Engine needs to get a persistent data store to keep track of any votes

targeting non-finalized checkpoints to avoid violating slashing conditions. You can simplify this by simply tracking the highest epoch you're used as a target and the highest epoch you've used as a source; that way there's only 2 variables that you need to figure out how to persist.

…

On Mon, Jan 1, 2018 at 3:02 PM, Robert Habermeier ***@***.***> wrote: The paper is pretty good documentation for a start, but I haven't dug into how votes are broadcast/accumulated in practice -- does a smart contract keep track of votes and justified checkpoints? or does a full node have to track all justified checkpoints internally? How are light clients meant to track finality? Engineering concerns: - BlockChain currently holds the whole fork-choice decision, based only on total difficulty. Parts of this will need to be deferred to the Engine. - Engine needs to get a persistent data store to keep track of any votes targeting non-finalized checkpoints to avoid violating slashing conditions. This brings complication due to snapshot restoration replacing the DB in-place. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7162 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACIKbqSvvKBFORkhxZwjyaawxj1H2CFgks5tGTnhgaJpZM4QupmR> .

[rphmeier]

Probably via a special-purpose protocol, like randomly selecting 50
validator indices and verifying that valid votes for enough of those
validators exist.

@vbuterin
This does imply that light clients would require lots of old state to be available. the way we architecture Parity right now, we model dynasty changes as a signal (log event) which is applied automatically upon finality. State proofs of a new validator set are kept in a compressed form by full nodes to ensure general availability. For engines like Aura or Tendermint this is fairly easy because finality is determined outside of the chain's state.

In CasperFFG this will definitely be more difficult and it seems that light clients will have to download lots of state data progressively to follow the fork-choice rule correctly. It would probably be simpler to give light clients a batch of proofs for all finalized dynasty changes (i.e. a warp sync) than to have it try and follow the header chain from genesis.