- Jan 07, 2021
- Jan 06, 2021
-
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Denis_P authored
-
Pierre Krieger authored
-
felix authored
* added new bootnode to chain spec's * remove trailing newline
-
Peter Goodspeed-Niklaus authored
* add timing setup to OverseerSubsystemContext * figure out how to initialize the rng * attach a timer to a portion of the messages traveling to the Overseer This timer only exists / logs a fraction of the time (configurable by `MESSAGE_TIMER_METRIC_CAPTURE_RATE`). When it exists, it tracks the span between the `OverSubsystemContext` receiving the message and its receipt in `Overseer::run`. * propagate message timing to the start of route_message This should be more accurate; it ensures that the timer runs at least as long as that function. As `route_message` is async, it may not actually run for some time after it is called (or ever). * fix failing test * rand_chacha apparently implicitly has getrandom feature * change rng initialization The previous impl using `from_entropy` depends on the `getrandom` crate, which uses the system entropy source, and which does not work on `wasm32-unknown-unknown` because it wants to fall back to a JS implementation which we can't assume exists. This impl depends only on `rand::thread_rng`, which has no documentation stating that it's similarly limited. * remove randomness in favor of a simpler 1 of N procedure This deserves a bit of explanation, as the motivating issue explicitly requested randomness. In short, it's hard to get randomness to compile for `wasm32-unknown-unknown` because that is explicitly intended to be as deterministic as practical. Additionally, even though it would never be used for consensus purposes, it still felt offputting to intentionally introduce randomness into a node's operations. Except, it wasn't really random, either: it was a deterministic PRNG varying only in its state, and getting the state to work right for that target would have required initializing from a constant. Given that it was a deterministic sequence anyway, it seemed much simpler and more explicit to simply select one of each N messages instead of attempting any kind of realistic randomness. * reinstate randomness for better statistical properties This partially reverts commit 0ab8594c. `oorandom` is much lighter than the previous `rand`-based implementation, which makes this easier to work with. This implementation gives each subsystem and each child RNG a distinct increment, which should ensure they produce distinct streams of values.
-
dependabot[bot] authored
Bumps [trie-db](https://github.com/paritytech/trie) from 0.22.1 to 0.22.2. - [Release notes](https://github.com/paritytech/trie/releases) - [Commits](https://github.com/paritytech/trie/compare/trie-db-v0.22.1...trie-db-v0.22.2 ) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
-
André Silva authored
* runtime: add Babe::next_epoch runtime api method * "Update Substrate" Co-authored-by: parity-processbot <>
-
dependabot[bot] authored
Bumps [pin-project](https://github.com/taiki-e/pin-project) from 1.0.2 to 1.0.3. - [Release notes](https://github.com/taiki-e/pin-project/releases) - [Changelog](https://github.com/taiki-e/pin-project/blob/master/CHANGELOG.md) - [Commits](https://github.com/taiki-e/pin-project/compare/v1.0.2...v1.0.3 ) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
-
Shawn Tabrizi authored
* Remove `_{}` from benchmarks macro * "Update Substrate" Co-authored-by: parity-processbot <>
-
- Jan 05, 2021
-
-
Bastian Köcher authored
This ensures that we also record the first `import_statement` that will lead to the creation of the `unbacked-span`.
-
Peter Goodspeed-Niklaus authored
* don't modify inherent data on heavy block * write up current thinking on block weight detection * extract inherent inclusion check into its own function * put heavy block check into runtime * the `inclusion` inherent call is Operational, not Mandatory This resolves a lot of the trickiness about this issue, because we no longer need to override or supplant any existing proposer logic; the existing logic should exhibit these behaviors: - the `inclusion` inherent is prioritized over standard transactions - but if it's too heavy, i.e. in case of runtime upgrade, it'll be dropped in favor of that. It is my belief that allowing the proposer to just not include this data won't have any adverse effects: it's equivalent to replacing them with empty versions of themselves, which the `ProvideInherent` impl already does. * Revert "the `inclusion` inherent call is Operational, not Mandatory" This reverts commit e58858d1. * Revert "write up current thinking on block weight detection" This reverts commit fd587b80. * Revert "don't modify inherent data on heavy block" This reverts commit 38299d3c . * add backed candidate block weight assumption to configuration * Limit backed candidates according to a candidate weight heuristic. This approach replaces making the inclusion inherent non-mandatory. It's still not ideal in that we have to configure a heuristic for how much each backed candidate 'weighs', instead of directly measuring it somehow. This approach also never truncates the signed bitfields. The rationale for that depends on some assumptions: - processing the signed bitfields is cheap compared to the backed candidates - it is beneficial to the progress of the relay chain to update the signed bitfields even if not all backed candidates are updated * simplify limit_backed_candidates and weight assumption * don't trust the provisioner to fairly distribute candidates * use saturating subtraction * empty commit to restart ci * use new mechanism for getting max block weight * apply weight refunds to the inclusion inherent This makes some assumptions about fundamental weights, which are encapsulated as constants. From there, it lets Substrate know what the actual computed weight of the inherent is. * use a correct fixed weight for the inclusion inherent Co-authored-by: Guillaume Thiolliere <[email protected]> * use dynamic inclusion weight so we reduce calculated weight when excluding candidates * don't double-count this intrinsic's weight in the block weight * add unit tests of fn limit_backed_candidates * add tests that the inclusion inherent's weight correctly updates Co-authored-by: Guillaume Thiolliere <[email protected]>
-