* use more efficient search through candidates in offchain-election
* mark linear accessors as test-only in election-provider-multi-phase
This prevents production code which uses them from compiling.
Also write an efficient helper for getting the target index.
* doc grammar
* use faster target_index_fn in benchmarks
* unbox helper functions
* remove unnecessary import
* write lifetime after primary trait
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* Improve complexity of CompactAssignments::unique_targets
Original implementation was O(n**2). Current impl is O(n log n).
Avoided the original proposed mitigation because it does not retain
the de-duplicating property present in the original implementation.
This implementation does a little more work, but retains that property.
* Explicitly choose sp_std Vec and BTreeSet
Ensures that the macro still works if someone uses it in a context
in which sp_std is not imported or is renamed.
* explicitly use sp_std vectors throughout compact macro
* Add PJR challenge functions
- Updates the PJR check to return a counterexample if one exists
- Adds functions to cheaply check counterexamples
This is in support of off-chain PJR challenges: if a miner discovers
that an accepted election solution does not satisfy PJR, it will be
eligible for substantial rewards. This helps ensure that validator
elections have an absolute quality floor, so even if someone manages
to censor well-behaved solutions to give themselves unfair representation,
we can catch them in the act and penalize them.
* counterexample -> counter_example
* reorganize: high -> low abstraction
* reorganize challenges high -> low abstraction
* add note justifying linear search
* Simplify max_pre_score validation
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* add minor test of pjr challenge validation
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* Apply.
* get rid of glob import
* use meaningful generic type name
* pjr_check operates on `Supports` struct used elsewhere
* improve algorithmic complexity of `prepare_pjr_input`
* fix rustdoc warnings
* improve module docs
* typo
* simplify debug assertion
* add test finding the phase-change threshold value for a constructed scenario
* add more threshold scenarios to disambiguate plausible interpretations
* add link to npos paper reference
* docs: staked_assignment -> supports
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* add utility method for generating npos inputs
* add a fuzzer which asserts that all unbalanced seq_phragmen are PJR
Note that this currently fails. I hope that this can be rectified
by calculating the threshold instead of choosing some arbitrary number.
* assert in all cases, not just debug
* leverage a native solution to choose candidates
* use existing helper methods
* add pjr-check and incorporate into the fuzzer
We should probably have one of the W3F people look at this to ensure
we're not misconstruing any definitions, but this seems like a
fairly straightforward implementation.
* fix compilation errors
* Enable manually setting iteration parameters in single run.
This gives us the ability to reproducably extract cases where
honggfuzz has discovered a panic. For example:
$ cargo run --release --bin phragmen_pjr -- --candidates 569 --voters 100
Tue 23 Feb 2021 11:23:39 AM CET
Compiling bitflags v1.2.1
Compiling unicode-width v0.1.8
Compiling unicode-segmentation v1.7.1
Compiling ansi_term v0.11.0
Compiling strsim v0.8.0
Compiling vec_map v0.8.2
Compiling proc-macro-error-attr v1.0.4
Compiling proc-macro-error v1.0.4
Compiling textwrap v0.11.0
Compiling atty v0.2.14
Compiling heck v0.3.2
Compiling clap v2.33.3
Compiling structopt-derive v0.4.14
Compiling structopt v0.3.21
Compiling sp-npos-elections-fuzzer v2.0.0-alpha.5 (/home/coriolinus/Documents/Projects/paritytech/substrate/primitives/npos-elections/fuzzer)
Finished release [optimized] target(s) in 6.15s
Running `/home/coriolinus/Documents/Projects/paritytech/substrate/target/release/phragmen_pjr -c 569 -v 100`
thread 'main' panicked at 'unbalanced sequential phragmen must satisfy PJR', primitives/npos-elections/fuzzer/src/phragmen_pjr.rs:133:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
This is still not adequate proof that seq_phragmen is broken; it could
very well be that our PJR checker is doing the wrong thing, or we've
somehow missed a parameter of interest. Still, it's concerning.
* update comment verbiage for accuracy
* it is valid in PJR for an elected candidate to have 0 support
* Fix phragmen_pjr fuzzer
It turns out that the fundamental problem causing previous implementations
of the fuzzer to fail wasn't in `seq_phragmen` _or_ in `pjr_check`: it was
in the rounding errors introduced in the various conversions between the
internal data representation and the external one.
Fixing the fuzzer is then simply an issue of using the internal representation
and staying in that representation. However, that leaves the issue that
`seq_phragmen` occasionally produces an output which is technically not
PJR due to rounding errors. In the future we will need to add some kind of
"close-enough" threshold. However, that is explicitly out of scope of
this PR.
* restart ci; it appears to be stalled
* use necessary import for no-std
* use a more realistic distribution of voters and candidates
This isn't ideal; more realistic numbers would be about twice these.
However, either case generation or voting has nonlinear execution
time, and doubling these values brings iteration time from ~20s to
~180s. Fuzzing 6x as fast should make up for fuzzing cases half the size.
* identify specifically which PJR check may fail
* move candidate collection comment into correct place
* standard_threshold: use a calculation method which cannot overflow
* Apply suggestions from code review (update comments)
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* clarify the effectiveness bounds for t-pjr check
* how to spell "committee"
* reorganize: high -> low abstraction
* ensure standard threshold calc cannot panic
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
Co-authored-by: kianenigma <kian.peymani@gmail.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
* 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>
* Factor out can_set_code
The motivation for this feature is parachain runtime upgrades, which
happen in two different moments: the initial call, when the checks
should be performed, and at the actual upgrade block. It's much
better and more maintainable to just call `can_set_code` in the
function than to manually copy those checks.
I'm not entirely thrilled with the interface, which requires
cloning the entire code vector in `set_code`. However, it looks
like something in `decl_module!` does not play nicely with
references in its function arguments. If `code` has a lifetime,
it _must_ be named, which gives us this signature.
```rust
pub fn can_set_code<'a>(origin, code: &'a [u8]) {
```
Unfortunately, attempting to compile with that signature generates
a very large and baffling collection of build errors, so I decided
to abandon that path for now.
* make can_set_code non-dispatchable per PR revew
Not only can we now borrow the `code` slice, but we also no longer
need to worry about people sending a `can_set_code` transaction because
of some misunderstanding.
* move into existing impl block
