Skip to content
  1. Dec 07, 2022
  2. Dec 06, 2022
  3. Dec 05, 2022
  4. Dec 04, 2022
    • Bastian Köcher's avatar
      frame-executive: Reject invalid inherents in the executive (#12365) · 1943e25c
      Bastian Köcher authored
      
      
      * frame-executive: Reject invalid inherents in the executive
      
      We already had support for making a block fail if an inherent returned, but it was part of the
      signed extension `CheckWeight`. Rejecting blocks with invalid inherents should happen on the
      `frame-executive` level without requiring any special signed extension. This is crucial to prevent
      any kind of spamming of the network that could may happen with blocks that include failing inherents.
      
      * FMT
      
      * Update frame/executive/src/lib.rs
      
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      
      * Update primitives/runtime/src/transaction_validity.rs
      
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      
      Co-authored-by: parity-processbot <>
      Co-authored-by: default avatarKeith Yeung <[email protected]>
      1943e25c
  5. Dec 01, 2022
    • alexgparity's avatar
      Reduce provisioner work (#12749) · d20e4958
      alexgparity authored
      
      
      * Move create_inherent_data call to use side
      
      * Make provide_inherent_data async
      
      * Fix tests
      
      * Apply suggestions from code review
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      
      * Log errors
      
      * Fix test
      
      * Fix test
      
      * fix
      
      * Deduplicate test code
      
      * fix
      
      * flag
      
      * Update client/consensus/slots/src/lib.rs
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      
      * Revert "Deduplicate test code"
      
      This reverts commit ba46adbe089329c78cd69ccdb08e27ed67bd77cf.
      
      * Fix test
      
      * remove commented out code
      
      * minor to start CI run
      
      * start CI
      
      * Update client/consensus/slots/src/lib.rs
      
      Co-authored-by: default avatarMarcin S. <[email protected]>
      
      * Apply PR suggestions
      
      * Apply PR suggestions
      
      * Update client/consensus/slots/src/lib.rs
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      
      * minor
      
      * kickoff CI
      
      * PR suggestions
      
      * Compute remaining duration instead of using slot_info.duration
      
      * Don't rely on sub implementation for Instant
      
      * Apply PR suggestions
      
      * Use saturating_duration_since
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarMarcin S. <[email protected]>
      Co-authored-by: parity-processbot <>
      d20e4958
  6. Nov 30, 2022
  7. Nov 29, 2022
  8. Nov 27, 2022
    • Bastian Köcher's avatar
      ed25519_verify: Support using dalek for historical blocks (#12661) · 0c934a93
      Bastian Köcher authored
      
      
      * ed25519_verify: Support using dalek for historical blocks
      
      The switch from `ed25519-dalek` to `ed25519-zebra` was actually a breaking change. `ed25519-zebra`
      is more permissive. To support historical blocks when syncing a chain this pull request introduces
      an externalities extension `UseDalekExt`. This extension is just used as a signaling mechanism to
      `ed25519_verify` to use `ed25519-dalek` when it is present. Together with `ExtensionBeforeBlock` it
      can be used to setup a node in way to sync historical blocks that require `ed25519-dalek`, because
      they included a transaction that verified differently as when using `ed25519-zebra`.
      
      This feature can be enabled in the following way. In the chain service file, directly after the
      client is created, the following code should be added:
      
      ```
      use sc_client_api::ExecutorProvider;
      client.execution_extensions().set_extensions_factory(
      	sc_client_api::execution_extensions::ExtensionBeforeBlock::<Block, sp_io::UseDalekExt>::new(BLOCK_NUMBER_UNTIL_DALEK_SHOULD_BE_USED)
      );
      ```
      
      * Fix doc
      
      * More fixes
      
      * Update client/api/src/execution_extensions.rs
      
      Co-authored-by: default avatarAndré Silva <[email protected]>
      
      * Fix merge and warning
      
      * Fix docs
      
      Co-authored-by: default avatarAndré Silva <[email protected]>
      0c934a93
  9. Nov 25, 2022
  10. Nov 22, 2022
  11. Nov 21, 2022
    • Adrian Catangiu's avatar
      client/beefy: persist voter state (#12712) · 3e7a2778
      Adrian Catangiu authored
      
      
      * client/beefy: prepare worker for persisting state
      
      * client/beefy: persist voter state
      
      * client/beefy: initialize persistent state
      
      * client/beefy: try to vote from the very beginning
      
      Now that voter is initialized from persistent state, it makes
      sense that it can attempt voting right away. This also helps
      the genesis case when we consider block `One` as mandatory.
      
      * client/beefy: add tests for voter state db
      * client/beefy: persist voter state as soon as initialized
      * client/beefy: make sure min-block-delta is at least 1
      * client/beefy: persist state after voting
      
      Persist state after handling self vote to avoid double voting in case
      of voter restarts.
      
      * client/beefy: persist state after handling mandatory block vote
      
      For mandatory blocks we want to make sure we're not losing votes
      in case of crashes or restarts, since voter will not make further
      progress without finalizing them.
      
      * frame/beefy: use GENESIS_AUTHORITY_SET_ID on pallet genesis
      
      * client/beefy: initialize voter at either genesis or last finalized
      To guarantee unbroken chain of mandatory blocks justifications, voter
      will always resume from either last BEEFY-justified block or
      `pallet-beefy` genesis, whichever is more recent.
      
      Initialization walks back the chain from latest GRANDPA finalized
      block looking for one of the above. Along the way, it also records
      and enqueues for processing any BEEFY mandatory blocks that have
      been already GRANDPA finalized but not BEEFY finalized.
      
      * client/beefy: decouple voter init from aux db state load
      * client/beefy: fix voter init tests
      * remove debug prints
      * gadget future must be type ()
      * fix init from last justification
      
      Signed-off-by: default avatarAdrian Catangiu <[email protected]>
      3e7a2778
  12. Nov 18, 2022
  13. Nov 16, 2022
  14. Nov 15, 2022
  15. Nov 11, 2022
  16. Nov 10, 2022
  17. Nov 09, 2022
  18. Nov 08, 2022
    • cheme's avatar
      Remove partial key size limit from trie codec (#12566) · 8b2ca711
      cheme authored
      * remove size limit from trie codec
      
      * test previous upper limit is not enforced anymore
      
      * fmt
      
      * restore test
      8b2ca711
    • Bastian Köcher's avatar
      `payment_queryInfo`: Make it work with `WeightV2` (#12633) · ec6a428a
      Bastian Köcher authored
      * `payment_queryInfo`: Make it work with `WeighV2`
      
      The runtime api for querying the payment info depends on the `Weight` type and broke for old
      runtimes that still use the `WeighV1`. This pull requests fixes this by:
      
      1. Bumping the version of the runtime api.
      2. Making the node side code use the correct runtime api function depending on the version of the
      runtime api.
      3. Make the RPC always return `WeighV1`.
      
      Users of the api should switch to `state_call` and decide based on the version of the runtime api
      which `Weight` type is being returned.
      
      * Fix tests
      
      * Review comment
      ec6a428a
    • Bastian Köcher's avatar
      `sp_trie::Recorder`: Fix recording the same key for different tries (#12636) · 8fcc6f2e
      Bastian Köcher authored
      With `StateVersion::V1` values over a certain size are not inlined and being put into the backend
      with their own hash. When accessing a value in the trie with a recorder, we check if the value is maybe already
      recorded and thus, we can check the cache. To check if a value is already recorded, we use the key
      of the value to differentiate them. The problem is when there are multiple tries, like multiple
      child tries that all have different values under the same key. Before this pull request we didn't
      have differentiated for which trie we already had recorded a (key, value) pair. This is now done by also taking
      the storage root into account in the recorder to differentiate the different (key, value) pair in
      the tries.
      8fcc6f2e
    • Alexander Samusev's avatar
      Pipeline with ci image with rust 1.65 (#12628) · 698f415b
      Alexander Samusev authored
      * Pipeline with ci image with rust 1.65
      
      * fix tests
      
      * use image with sha
      698f415b
  19. Nov 07, 2022
  20. Nov 05, 2022
  21. Nov 03, 2022
  22. Nov 02, 2022
  23. Nov 01, 2022
  24. Oct 29, 2022
  25. Oct 28, 2022
    • clangenb's avatar
    • Bastian Köcher's avatar
      Aura: Adds some compatibility mode to support old chains (#12492) · 33b61f0e
      Bastian Köcher authored
      * Aura: Adds some compatibility mode to support old chains
      
      In https://github.com/paritytech/substrate/pull/9132
      
       we changed the way how we get the authorities
      from the runtime. Before this mentioned pr we would call `initialize_block` before calling the
      authorities runtime function. The problem with this was that when you have a block X that would
      switch the authority set, it would already be signed by an authority of the new set. This was wrong,
      as a block should only be signed by the current authority set. As this change is a hard fork, this
      pr brings back the possibility for users that have a chain running with this old logic to upgrade.
      
      They will need to use:
      ```
      CompatibilityMode::UseInitializeBlock { until: some_block_in_the_future }
      ```
      
      Using this compatibility mode will make the node behave like the old nodes, aka calling
      `initialize_block` before doing the actual runtime call to `authorities`. Then when the given
      `until` block is being build/imported the node switches to the new behaviour of not calling
      `initialize_block` before. This is a hard fork, so the `until` block should be chosen wisely as a
      point where all nodes in the network have upgraded.
      
      * Fixes
      
      * Make docs ready
      
      * Update client/consensus/aura/src/lib.rs
      
      Co-authored-by: default avatarAndré Silva <[email protected]>
      
      * Update client/consensus/aura/src/lib.rs
      
      Co-authored-by: default avatarAndré Silva <[email protected]>
      
      * Update client/consensus/aura/src/lib.rs
      
      Co-authored-by: default avatarAndré Silva <[email protected]>
      
      * FMT
      
      Co-authored-by: default avatarAndré Silva <[email protected]>
      33b61f0e