Beefy: add runtime support for reporting fork voting #4523
Assignees
Labels
T15-bridges
This PR/Issue is related to bridges.
Comments
programskillforverification
pushed a commit
to programskillforverification/polkadot-sdk
that referenced
this issue
Jul 3, 2024
Related to paritytech#4523 Extracting part of paritytech#1903 (credits to @Lederstrumpf for the high-level strategy), but also introducing significant adjustments both to the approach and to the code. The main adjustment is the fact that the `ForkVotingProof` accepts only one vote, compared to the original version which accepted a `vec![]`. With this approach more calls are needed in order to report multiple equivocated votes on the same commit, but it simplifies a lot the checking logic. We can add support for reporting multiple signatures at once in the future. There are 2 things that are missing in order to consider this issue done, but I would propose to do them in a separate PR since this one is already pretty big: - benchmarks/computing a weight for the new extrinsic (this wasn't present in paritytech#1903 either) - exposing an API for generating the ancestry proof. I'm not sure if we should do this in the Mmr pallet or in the Beefy pallet Co-authored-by: Robert Hambrock <[email protected]> --------- Co-authored-by: Adrian Catangiu <[email protected]>
TomaszWaszczyk
pushed a commit
to TomaszWaszczyk/polkadot-sdk
that referenced
this issue
Jul 7, 2024
Related to paritytech#4523 Extracting part of paritytech#1903 (credits to @Lederstrumpf for the high-level strategy), but also introducing significant adjustments both to the approach and to the code. The main adjustment is the fact that the `ForkVotingProof` accepts only one vote, compared to the original version which accepted a `vec![]`. With this approach more calls are needed in order to report multiple equivocated votes on the same commit, but it simplifies a lot the checking logic. We can add support for reporting multiple signatures at once in the future. There are 2 things that are missing in order to consider this issue done, but I would propose to do them in a separate PR since this one is already pretty big: - benchmarks/computing a weight for the new extrinsic (this wasn't present in paritytech#1903 either) - exposing an API for generating the ancestry proof. I'm not sure if we should do this in the Mmr pallet or in the Beefy pallet Co-authored-by: Robert Hambrock <[email protected]> --------- Co-authored-by: Adrian Catangiu <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Jul 23, 2024
Related to #4523 Add runtime API methods for: - generating the ancestry proof - submiting a fork voting report - submitting a future voting report
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this issue
Aug 2, 2024
Related to paritytech#4523 Extracting part of paritytech#1903 (credits to @Lederstrumpf for the high-level strategy), but also introducing significant adjustments both to the approach and to the code. The main adjustment is the fact that the `ForkVotingProof` accepts only one vote, compared to the original version which accepted a `vec![]`. With this approach more calls are needed in order to report multiple equivocated votes on the same commit, but it simplifies a lot the checking logic. We can add support for reporting multiple signatures at once in the future. There are 2 things that are missing in order to consider this issue done, but I would propose to do them in a separate PR since this one is already pretty big: - benchmarks/computing a weight for the new extrinsic (this wasn't present in paritytech#1903 either) - exposing an API for generating the ancestry proof. I'm not sure if we should do this in the Mmr pallet or in the Beefy pallet Co-authored-by: Robert Hambrock <[email protected]> --------- Co-authored-by: Adrian Catangiu <[email protected]>
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this issue
Aug 2, 2024
Related to paritytech#4523 Add runtime API methods for: - generating the ancestry proof - submiting a fork voting report - submitting a future voting report
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 14, 2024
Related to #4523 This PR adds benchmarks for `report_fork_voting()`. **Important: Even though the benchmarks are now available, we still use `Weight::MAX`. That's because I realized while working on this PR that there's still one missing piece. We should also check that the ancestry proof is optimal. I plan to do this in a future PR, hopefully the last one related to #4523.** --------- Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: command-bot <>
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 14, 2024
Related to #4523 This PR adds benchmarks for `report_fork_voting()`. **Important: Even though the benchmarks are now available, we still use `Weight::MAX`. That's because I realized while working on this PR that there's still one missing piece. We should also check that the ancestry proof is optimal. I plan to do this in a future PR, hopefully the last one related to #4523.** --------- Co-authored-by: Branislav Kontur <[email protected]> Co-authored-by: command-bot <>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Creating this issue to track the progress of the task
So far we have:
Still needs to be done:
report_fork_voting()#5188report_fork_voting()#6732The text was updated successfully, but these errors were encountered: