Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Warp/Light-friendly Authority Contract chains #5427

Closed
rphmeier opened this issue Apr 7, 2017 · 5 comments
Closed

Warp/Light-friendly Authority Contract chains #5427

rphmeier opened this issue Apr 7, 2017 · 5 comments
Assignees
Labels
F8-enhancement 🎊 An additional feature request. M4-core ⛓ Core client code / Rust.
Milestone

Comments

@rphmeier
Copy link
Contributor

rphmeier commented Apr 7, 2017

cc @keorn

Needs to be introduced soon-ish, but there are still a couple small problems I'd like to iron down first.
Opening this issue for discussion.

Specification

Add a seal field: "authority_transition":
If the authorities set is the same as the prior block, the field's value is empty.
If the authorities set has changed since the last block, the field's value is set to:
sha3([nonce: P, [authority1: B_20, authority2: B_20, ...] ])
nonce must be N for the Nth transition, and the authorities' addresses must be in lexicographical order.

This will allow light clients to indicate when they need to get a fraud proof of the transition, which consists of two parts:

  1. fraud proof that the authority set at the previous block is equal to the last known one
  2. fraud proof that the authority set at the current block matches the authorities_hash field.

Additionally, light clients will need to store the block number of the last transition along with each CHT root. Then, when re-organizing outside of recent history, a proof of the authority set at that block can be fetched.

Warp sync would work with "consensus proof chunks", which in this case would contain

  1. transition_headers: a list of all block headers where the authority set has ever changed
  2. fraud proofs as mentioned above for the transitions in the list.

len(transition_headers) must be equal to transition_headers.last().authority_transition.nonce
In other words, the snapshot must provably contain proofs for all transitions since the genesis.
This could be optimized with hardcoded checkpoints in the future.

Problems

Once an authority set has been put in place, any authority within it can continue producing a chain light clients will trust for as long as they like, regardless of whether the "main" chain has forked away. Chain score will have to favor chains with more authorities signing on them.

Bad authorities could silently change and revert the authorities set without being detected, but that's not really a problem with a good authority contract. Also, blocks from the un-mentioned authorities wouldn't be trusted.

We'll also have to save all authority sets (or maybe deltas) to disk on the light client.
If the set changes a lot, this could lead to a high storage requirement.

Alternatives

Instead of adding a seal field, signal changes in the authority set with log events. This will save block space on an additional field, but would require going to the network to check receipts, and handling false positives. Potentially easy to manufacture false positives to inconvenience light clients, but if the log events had to include the parent hash I don't think people would be able to compute bloom collisions quickly enough.

In this case, the authorities list can be put into the log data. Then light clients can recover ancient, discarded authority sets from block receipts without re-doing the state proofs.

If we impose an additional requirement that the authorities list be followed by signatures from more than half of the previous authority set, no state proofs will be needed. But this might be needlessly restrictive on what kinds of contracts can be used.

@rphmeier rphmeier added F8-enhancement 🎊 An additional feature request. M4-core ⛓ Core client code / Rust. labels Apr 7, 2017
@rphmeier
Copy link
Contributor Author

rphmeier commented Apr 7, 2017

Consensus proofs should be kept in the state column of the DB, so they play nicely with pruning.
Never deleted, but only written when the block they pertain to becomes canonical.

@rphmeier
Copy link
Contributor Author

rphmeier commented Apr 9, 2017

There's still an open problem with warp where you don't have any way to tell whether the authority set at the warp block is unchanged from the last transition proof you've gotten. It can be solved by periodically setting a header field to the authorities hash + current transition nonce, and only warping to blocks which contain a "heartbeat".

@gavofyork
Copy link
Contributor

Alternative is where it's at.

@rphmeier
Copy link
Contributor Author

I thought so initially, but it's much less clean to implement since you have to pass parent block receipts into the validation functions on top of the header.

@5chdn 5chdn added the Z3-stale 🍃 Issue is in principle valid, but it is not relevant anymore or can not reproduced. label Sep 4, 2017
@5chdn 5chdn closed this as completed Sep 4, 2017
@rphmeier rphmeier reopened this Sep 4, 2017
@5chdn 5chdn removed the Z3-stale 🍃 Issue is in principle valid, but it is not relevant anymore or can not reproduced. label Sep 4, 2017
@5chdn 5chdn added this to the 1.8 milestone Sep 4, 2017
@rphmeier
Copy link
Contributor Author

rphmeier commented Sep 4, 2017

Specification at the top isn't valid anymore (alternative is ~close), if somebody wants details of the new workings, LMK

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F8-enhancement 🎊 An additional feature request. M4-core ⛓ Core client code / Rust.
Projects
None yet
Development

No branches or pull requests

3 participants