You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
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:
fraud proof that the authority set at the previous block is equal to the last known one
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
transition_headers: a list of all block headers where the authority set has ever changed
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.
The text was updated successfully, but these errors were encountered:
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.
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".
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.
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:
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
transition_headers
: a list of all block headers where the authority set has ever changedlen(transition_headers)
must be equal totransition_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.
The text was updated successfully, but these errors were encountered: