Skip to content
  1. Jan 13, 2021
  3. Jan 12, 2021
  5. Jan 11, 2021
  7. Jan 08, 2021
  9. Jan 07, 2021
  11. Jan 06, 2021
    • ordian's avatar
      upgrade a few dependencies (companion for 7831) (#2205) · e9866d55
      ordian authored 
      * upgrade a few dependencies

* "Update Substrate"

Co-authored-by: parity-processbot <>
      e9866d55
    • Denis_P's avatar
      CI: remove squash and fix buildah push (#2212) · 51d55338
      Denis_P authored
      51d55338
    • Pierre Krieger's avatar
      Make order consistent (#2215) · 107673eb
      Pierre Krieger authored
      107673eb
    • felix's avatar
      added new bootnode to chain spec's (#2204) · 00c1ef88
      felix authored 
      * added new bootnode to chain spec's

* remove trailing newline
      00c1ef88
    • Peter Goodspeed-Niklaus's avatar
      Add metrics timing message passing from OverseerSubsystemContext to Overseer::route_message (#2201) · 004dc50d
      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.
      004dc50d
    • dependabot[bot]'s avatar
      Bump trie-db from 0.22.1 to 0.22.2 (#2208) · 0253be89
      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: default avatardependabot[bot] <[email protected]>

Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      0253be89
    • André Silva's avatar
      runtime: add Babe::next_epoch runtime api method (#2200) · bf8e07e8
      André Silva authored 
      * runtime: add Babe::next_epoch runtime api method

* "Update Substrate"

Co-authored-by: parity-processbot <>
      bf8e07e8
    • dependabot[bot]'s avatar
      Bump pin-project from 1.0.2 to 1.0.3 (#2209) · 6b7f1f15
      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: default avatardependabot[bot] <[email protected]>

Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      6b7f1f15
    • Shawn Tabrizi's avatar
      Companion PR for 7822 (Remove `_{}` from benchmarks) (#2202) · dbd9e9ec
      Shawn Tabrizi authored 
      * Remove `_{}` from benchmarks macro

* "Update Substrate"

Co-authored-by: parity-processbot <>
      dbd9e9ec
  13. Jan 05, 2021
    • Bastian Köcher's avatar
      Improve the `unbacked-span` (#2206) · 4f41fb74
      Bastian Köcher authored 
      This ensures that we also record the first `import_statement` that will
lead to the creation of the `unbacked-span`.
      4f41fb74
    • Peter Goodspeed-Niklaus's avatar
      Reduce the inclusion inherent's actual weight if the block is already heavy (#2060) · 0508b6f2
      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: default avatarGuillaume 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: default avatarGuillaume Thiolliere <[email protected]>
      0508b6f2
    • dependabot[bot]'s avatar
      Bump smallvec from 1.5.1 to 1.6.0 (#2183) · 09c43bb8
      dependabot[bot] authored 
      

Bumps [smallvec](https://github.com/servo/rust-smallvec) from 1.5.1 to 1.6.0.
- [Release notes](https://github.com/servo/rust-smallvec/releases)
- [Commits](https://github.com/servo/rust-smallvec/compare/v1.5.1...v1.6.0)

Signed-off-by: default avatardependabot[bot] <[email protected]>

Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      09c43bb8
    • Bastian Köcher's avatar
      Add one Jaeger span per relay parent (#2196) · 17344327
      Bastian Köcher authored 
      

* Add one Jaeger span per relay parent

This adds one Jaeger span per relay parent, instead of always creating
new spans per relay parent. This should improve the UI view, because
subsystems are now grouped below one common span.

* Fix doc tests

* Replace `PerLeaveSpan` to `PerLeafSpan`

* More renaming

* Moare

* Update node/subsystem/src/lib.rs

Co-authored-by: default avatarAndronik Ordian <[email protected]>

* Skip the spans

* Increase `spec_version`

Co-authored-by: default avatarAndronik Ordian <[email protected]>
      17344327
    • Sergey Pepyakin's avatar
      Parachains well known keys and abridged primitives (#2194) · 6b688dd5
      Sergey Pepyakin authored 
      * Add well_known_keys

* Reorder HrmpChannel and HostConfiguration members

* abridged versions and well known keys tests

* Add some comments

* Add a note on generation of the prefixes

and other magic values

* Recommend accessing the well known values through abridged structs
      6b688dd5
  15. Jan 04, 2021