-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
/benchmark runtime pallet pallet_two_phase_election_provider |
/benchmark runtime pallet pallet_two_phase_election_provider |
Finished benchmark for branch: kiz-election-provider Benchmark: Benchmark Runtime Pallet cargo run --release --features=runtime-benchmarks --manifest-path=bin/node/cli/Cargo.toml -- benchmark --chain=dev --steps=50 --repeat=20 --pallet=pallet_two_phase_election_provider --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --output=./frame/two-phase-election-provider/src/weights.rs --template=./.maintain/frame-weight-template.hbs ResultsPallet: "pallet_two_phase_election_provider", Extrinsic: "on_initialize_nothing", Lowest values: [], Highest values: [], Steps: [50], Repeat: 20
|
…/node/cli/Cargo.toml -- benchmark --chain=dev --steps=50 --repeat=20 --pallet=pallet_two_phase_election_provider --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --output=./frame/two-phase-election-provider/src/weights.rs --template=./.maintain/frame-weight-template.hbs
as discussed offline it should be great to have signed solution having a weight limit too, because once they are executed in on_initialize it mustn't take more than 1 block. So in principle the signed solution maximum weight should be Actually the whole signed phase could have been done in a follow-up PR |
This PR shall be frozen and I will try to split it into smaller pieces. |
We're gonna stick to the split version, thus closed. |
PR review walkthrough video recording, slightly outdated, but still useful.
Problem
This is a major step toward reducing the technical debt of the bloated (mostly by me) staking pallet. A big component that is currently baked into staking is the election mechanism. This PR will decouple election and staking, allowing the election to happen (with whatever mechanism it may have) in a separate logical unit, and the results are communicated back to staking.
Solution
A new, potentially multi-pallet crate is introduced, called
frame-election-providers
. This crate contains different entities that can provide generic election functionality to pallets. To signal this, each of them needs to implement theElectionProvider
trait. Current PR provides two implementations:OnChainSequentialPhragmen
, which is a stateless struct that does election on the fly.TwoPhaseElection
, which is a stateful pallet that does the election in a more complicated process, as described in Tracking issue for next generation pallet-staking and elections #6242 .In the future, I plan to experiment with a new one called
MultiBlockSequentialPhragmen
, and if it works, it can solve a lot of future performance issues.The crux of the work finishes here. Albeit, many complications arise that I will discuss next.
Problems, Discussions
ElectionDataProvider
.After some consideration and interations, I've settled for a design in which we assume all elections are stateful. This has no implication on the stateless elections, expcet that they need a separate medium to communicate the election date, beause the main
fn elect()
takes no parameters.To make this a bit more strict, each
ElectionPrivder
must have atype DataProvider: ElectionDataProvider
. Further documentation and examples of this is provided inprimitives/election-providers
.Reward amount.
How much should we reward the best solution? Ideally, this should be proportional to the amount of improvement to the min-staker that the solution provides (
score[0]
) Given that we mint the reward out of thin air, I am worried that if there is a flaw, someone can use it to gain a lot of money. For now, I added a configurableMaxReward
. This should ensure that even in case of bugs, this cannot be abused.Weighing. The
two_phase
pallet is very challenging to be weighed correctly. An interesting example is closing the signed phase. We cannot know how many of the queued solutions need to go through a feasibility check. Theon_initialize
weight is also fairly complicated, and I am still not sure if it is good enough.Deposit: Speaking of weight, I think this is the first pallet that will attempt to reserve a deposit for future weight consumption. In detail, a signed submission should reserve a ratio of its future
feasibility_check
weight. This will get slashed if the solution is not valid.Challenge phase: We still don't check for a solution to be PJR, because it is too expensive to do so for now. An easy solution to this is to introduce a short challenge phase. While checking PJR on-chain is hard, it is quite easy to submit a proof to the chain to claim that a solution is not PJR. Ideally, we should have such a phase as well. I probably won't do it in this PR though.
Deployment: This is quite tricky to deploy, as it deeply alters staking. I recently had an idea about how to deploy this: I can revert these changes in staking, and only add new code in this PR. We let old-staking run next to two_phase and probably compare the solutions offchain to make sure they are both sane. Then, we progress by switching the staking into using an
ElectionProvider
.