Peter Goodspeed-Niklaus
44d5aba80d
* Create a macro which automates creation of benchmark test suites. * bump impl_version * allow unused on test_bench_by_name * use proper doctest ignore attribute * Explicitly hand the Module to the test suite Much better practice than depending on it showing up implicitly in the namespace. * explicitly import what we need into `mod tests` * bench_module is `ident` not `tt` Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com> * allow end users to specify arguments for new_test_ext This turned out to be surprisingly easy. On reflection, it turns out that of course the compiler can't eagerly evaluate the function call, but needs to paste it in everywhere desired. * enable explicitly specifying the path to the benchmarks invocation also enable optional trailing commas * Revert "bump impl_version" This reverts commit 0209e4de33fd43873f8cfc6875815d0fd6151e63. * list failing benchmark tests and the errors which caused the failure * harden benchmark tests against internal panics * suppress warning about ignored profiles unfortunately, setting the profile here doesn't do anything; we'd need to set it in every leaf package anyway. However, as this was just making the default explicit anyway, I think it's safe enough to remove entirely. * impl_benchmark_test_suite for assets * impl_benchmark_test_suite for balances * impl_benchmark_test_suite for bounties * impl_benchmark_test_suite for Collective * impl_benchmark_test_suite for Contracts * impl_benchmark_test_suite for Democracy * don't impl_benchmark_test_suite for Elections-Phragmen * impl_benchmark_test_suite for Identity Note that Identity tests currently fail. They failed in an identical way before this change, so as far as I'm concerned, the status quo is good enough for now. * impl_benchmark_test_suite for ImOnline * impl_benchmark_test_suite for indices For this crate also, the test suite fails identically with and without this change, so we can say that this change is not the cause of the tests' failure to compile. * impl_benchmark_test_suite for lottery * impl_benchmark_test_suite for merkle-mountain-range * impl_benchmark_test_suite for Multisig These tests fail identically with and without the change, so the change seems unlikely to be the origin of the failures. * impl_benchmark_test_suite for offences * impl_benchmark_test_suite for Proxy Fails identically with and without this change. * impl_benchmark_test_suite for scheduler * impl_benchmark_test_suite for session It turns out to be important to be able to exclude items marked `#[extra]` sometimes. Who knew? * impl_benchmark_test_suite for staking * impl_benchmark_test_suite for system * impl_benchmark_test_suite for timestamp * impl_benchmark_test_suite for tips * impl_benchmark_test_suite for treasury * impl_benchmark_test_suite for utility Note that benchmark tests fail identically before and after this change. * impl_benchmark_test_suite for vesting * fix wrong module name in impl_benchmark_test_suite in Offences * address line length nits * enable optional keyword argument: exec_name Took a _lot_ of macro-wrangling to get the functionality that I want, but now you have the option to pass in ```rust impl_benchmark_test_suite!( Elections, crate::tests::ExtBuilder::default().desired_members(13).desired_runners_up(7), crate::tests::Test, exec_name = build_and_execute, ); ``` and have it expand out properly. A selected fragment of the expansion: ```rust fn test_benchmarks() { crate::tests::ExtBuilder::default() .desired_members(13) .desired_runners_up(7) .build_and_execute(|| { ``` * get rid of dead code Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
Democracy Pallet
Overview
The Democracy pallet handles the administration of general stakeholder voting.
There are two different queues that a proposal can be added to before it becomes a referendum, 1) the proposal queue consisting of all public proposals and 2) the external queue consisting of a single proposal that originates from one of the external origins (such as a collective group).
Every launch period - a length defined in the runtime - the Democracy pallet launches a referendum from a proposal that it takes from either the proposal queue or the external queue in turn. Any token holder in the system can vote on referenda. The voting system uses time-lock voting by allowing the token holder to set their conviction behind a vote. The conviction will dictate the length of time the tokens will be locked, as well as the multiplier that scales the vote power.
Terminology
- Enactment Period: The minimum period of locking and the period between a proposal being approved and enacted.
- Lock Period: A period of time after proposal enactment that the tokens of winning voters will be locked.
- Conviction: An indication of a voter's strength of belief in their vote. An increase of one in conviction indicates that a token holder is willing to lock their tokens for twice as many lock periods after enactment.
- Vote: A value that can either be in approval ("Aye") or rejection ("Nay") of a particular referendum.
- Proposal: A submission to the chain that represents an action that a proposer (either an account or an external origin) suggests that the system adopt.
- Referendum: A proposal that is in the process of being voted on for either acceptance or rejection as a change to the system.
- Delegation: The act of granting your voting power to the decisions of another account for up to a certain conviction.
Adaptive Quorum Biasing
A referendum can be either simple majority-carries in which 50%+1 of the votes decide the outcome or adaptive quorum biased. Adaptive quorum biasing makes the threshold for passing or rejecting a referendum higher or lower depending on how the referendum was originally proposed. There are two types of adaptive quorum biasing: 1) positive turnout bias makes a referendum require a super-majority to pass that decreases as turnout increases and 2) negative turnout bias makes a referendum require a super-majority to reject that decreases as turnout increases. Another way to think about the quorum biasing is that positive bias referendums will be rejected by default and negative bias referendums get passed by default.
Interface
Dispatchable Functions
Public
These calls can be made from any externally held account capable of creating a signed extrinsic.
Basic actions:
propose- Submits a sensitive action, represented as a hash. Requires a deposit.second- Signals agreement with a proposal, moves it higher on the proposal queue, and requires a matching deposit to the original.vote- Votes in a referendum, either the vote is "Aye" to enact the proposal or "Nay" to keep the status quo.unvote- Cancel a previous vote, this must be done by the voter before the vote ends.delegate- Delegates the voting power (tokens * conviction) to another account.undelegate- Stops the delegation of voting power to another account.
Administration actions that can be done to any account:
reap_vote- Remove some account's expired votes.unlock- Redetermine the account's balance lock, potentially making tokens available.
Preimage actions:
note_preimage- Registers the preimage for an upcoming proposal, requires a deposit that is returned once the proposal is enacted.note_preimage_operational- same but provided byT::OperationalPreimageOrigin.note_imminent_preimage- Registers the preimage for an upcoming proposal. Does not require a deposit, but the proposal must be in the dispatch queue.note_imminent_preimage_operational- same but provided byT::OperationalPreimageOrigin.reap_preimage- Removes the preimage for an expired proposal. Will only work under the condition that it's the same account that noted it and after the voting period, OR it's a different account after the enactment period.
Cancellation Origin
This call can only be made by the CancellationOrigin.
emergency_cancel- Schedules an emergency cancellation of a referendum. Can only happen once to a specific referendum.
ExternalOrigin
This call can only be made by the ExternalOrigin.
external_propose- Schedules a proposal to become a referendum once it is is legal for an externally proposed referendum.
External Majority Origin
This call can only be made by the ExternalMajorityOrigin.
external_propose_majority- Schedules a proposal to become a majority-carries referendum once it is legal for an externally proposed referendum.
External Default Origin
This call can only be made by the ExternalDefaultOrigin.
external_propose_default- Schedules a proposal to become a negative-turnout-bias referendum once it is legal for an externally proposed referendum.
Fast Track Origin
This call can only be made by the FastTrackOrigin.
fast_track- Schedules the current externally proposed proposal that is "majority-carries" to become a referendum immediately.
Veto Origin
This call can only be made by the VetoOrigin.
veto_external- Vetoes and blacklists the external proposal hash.
Root
cancel_referendum- Removes a referendum.cancel_queued- Cancels a proposal that is queued for enactment.clear_public_proposal- Removes all public proposals.
License: Apache-2.0