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

Commit

Permalink
More on GRANDPA
Browse files Browse the repository at this point in the history
  • Loading branch information
burdges committed Aug 7, 2020
1 parent 2b2e4f9 commit ae67543
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions roadmap/implementers-guide/src/runtime/validity.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,13 +31,13 @@ Approval checks provide more security than backing checks, so polkadot becomes m

We should therefore reward approval checkers correctly because approval checks should actually represent our single largest workload. It follows that both assignment notices and approval votes should be tracked on-chain.

We might track the assignments and approvals together as pairs in a simple rewards system. There are however two reasons to track assignments and approvals separately on-chain:
We might track the assignments and approvals together as pairs in a simple rewards system. There are however two reasons to witness approvals on chain by tracking assignments and approvals on-chain, rewards and finality integration.

- An approval that arrives slowly prompts assigning extra checkers. Yet, we consider a block valid if the earlier checker completes their work, even if the extra checkers never quite finish, which complicates rewarding these extra checkers. We could support more nuanced rewards for extra checkers if assignments are placed on-chain earlier. Assignment delay tranches progress 12ish times faster than the relay chain, but no shows could still be witness by the relay chain because the no show delay takes longer than a relay chain slot.
First, an approval that arrives too slowly prompts assigning extra "no show" replacement checkers. Yet, we consider a block valid if the earlier checker completes their work, even if the extra checkers never quite finish, which complicates rewarding these extra checkers. We could support more nuanced rewards for extra checkers if assignments are placed on-chain earlier. Assignment delay tranches progress 12ish times faster than the relay chain, but no shows could still be witness by the relay chain because the no show delay takes longer than a relay chain slot.

- We know off-chain when the approval process completes based upon all gossiped assignment notices, not just the approving ones. We need not-yet-approved assignment notices to appear on-chain if the chain should know about the validity of recently approved blocks. Integration with grandpa then requires only that grandpa messages identify some future relay chain block that approves the block for which they vote.
Second, we know off-chain when the approval process completes based upon all gossiped assignment notices, not just the approving ones. We need not-yet-approved assignment notices to appear on-chain if the chain should know about the validity of recently approved blocks. Relay chain blocks become eligible for finality in GRANDPA only once all their included candidates pass approvals checks, meaning all assigned checkers either voted approve or else were declared "no show" and replaced by more assigned checkers. A purely off-chain approvals scheme complicates GRANDPA with additional objections logic.

Aside from inherents for assignment notices and approval votes, we provide an "Approved" inherent that triggers the on-chain logic in a relay chain block `R1` to rerun the assignment and approval tracker logic for its ancestor `R0`, which then declares `R0` approved. We could integrate with GRANDPA by gossiping messages that list the descendent `R1`, but then map this into the approved ancestor `R0` for GRANDPA itself.
Integration with GRANDPA appears simplest if we witness approvals in chain: Aside from inherents for assignment notices and approval votes, we provide an "Approved" inherent by which a relay chain block declares a past relay chain block approved. In other words, it trigger the on-chain approval counting logic in a relay chain block `R1` to rerun the assignment and approval tracker logic for some ancestor `R0`, which then declares `R0` approved. In this case, we could integrate with GRANDPA by gossiping messages that list the descendent `R1`, but then map this into the approved ancestor `R0` for GRANDPA itself.

Approval votes could be recorded on-chain quickly because they represent a major commitments.

Expand Down

0 comments on commit ae67543

Please sign in to comment.