1. Dec 05, 2023
  2. Dec 01, 2023
  3. Nov 30, 2023
  4. Nov 29, 2023
  5. Nov 28, 2023
  6. Nov 27, 2023
    • Maciej's avatar
      Zombienet tests - disputes on finalized blocks (#2184) · dc69dbba
      Maciej authored
      
      
      **Overview:**
      Adding an extra malus variant focusing on disputing finalized blocks. It
      will:
      - wrap around approval-voting
      - listen to `OverseerSignal::BlockFinalized` and when encountered start
      a dispute for the `dispute_offset`th ancestor
      - simply pass through all other messages and signals
      
      Add zombienet tests testing various edgecases:
      - disputing freshly finalized blocks
      - disputing stale finalized blocks
      - disputing eagerly pruned finalized blocks (might be separate PR)
      
      **TODO:**
      - [x] Register new malus variant
      - [x] Simple pass through wrapper (approval-voting)
      - [x] Simple network definition
      - [x] Listen to block finalizations
      - [x] Fetch ancestor hash
      - [x] Fetch session index
      - [x] Fetch candidate
      - [x] Construct and send dispute message
      - [x] zndsl test 1 checking that disputes on fresh finalizations resolve
      valid Closes #1365
      - [x] zndsl test 2 checking that disputes for too old finalized blocks
      are not possible Closes #1364
      - [ ] zndsl test 3 checking that disputes for candidates with eagerly
      pruned relay parent state are handled correctly #1359 (deferred to a
      separate PR)
      - [x] Unit tests for new malus variant (testing cli etc)
      - [x] Clean/streamline error handling
      - [ ] ~~Ensure it tests properly on session boundaries~~
      
      ---------
      
      Co-authored-by: default avatarJavier Viola <[email protected]>
      Co-authored-by: default avatarMarcin S. <[email protected]>
      Co-authored-by: default avatarTsvetomir Dimitrov <[email protected]>
      dc69dbba
  7. Nov 25, 2023
  8. Nov 24, 2023
  9. Nov 23, 2023
  10. Nov 22, 2023
  11. Nov 21, 2023
  12. Nov 17, 2023
  13. Nov 16, 2023
  14. Nov 15, 2023
  15. Nov 13, 2023
  16. Nov 06, 2023
    • Andrei Sandu's avatar
      approval-voting improvement: include all tranche0 assignments in one certificate (#1178) · 0570b6fa
      Andrei Sandu authored
      **_PR migrated from https://github.com/paritytech/polkadot/pull/6782_** 
      
      This PR will upgrade the network protocol to version 3 -> VStaging which
      will later be renamed to V3. This version introduces a new kind of
      assignment certificate that will be used for tranche0 assignments.
      Instead of issuing/importing one tranche0 assignment per candidate,
      there will be just one certificate per relay chain block per validator.
      However, we will not be sending out the new assignment certificates,
      yet. So everything should work exactly as before. Once the majority of
      the validators have been upgraded to the new protocol version we will
      enable the new certificates (starting at a specific relay chain block)
      with a new client update.
      
      There are still a few things that need to be done:
      
      - [x] Use bitfield instead of Vec<CandidateIndex>:
      https://github.com/paritytech/polkadot/pull/6802
      
      
        - [x] Fix existing approval-distribution and approval-voting tests
        - [x] Fix bitfield-distribution and statement-distribution tests
        - [x] Fix network bridge tests
        - [x] Implement todos in the code
        - [x] Add tests to cover new code
        - [x] Update metrics
        - [x] Remove the approval distribution aggression levels: TBD PR
        - [x] Parachains DB migration 
        - [x] Test network protocol upgrade on Versi
        - [x] Versi Load test
        - [x] Add Zombienet test
        - [x] Documentation updates
      - [x] Fix for sending DistributeAssignment for each candidate claimed by
      a v2 assignment (warning: Importing locally an already known assignment)
       - [x]  Fix AcceptedDuplicate
       - [x] Fix DB migration so that we can still keep old data.
       - [x] Final Versi burn in
      
      ---------
      
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      Signed-off-by: default avatarAlexandru Gheorghe <[email protected]>
      Co-authored-by: default avatarAlexandru Gheorghe <[email protected]>
      0570b6fa
  17. Nov 05, 2023
  18. Nov 02, 2023
  19. Oct 31, 2023
  20. Oct 30, 2023
  21. Oct 24, 2023
  22. Oct 19, 2023
  23. Oct 18, 2023
  24. Oct 17, 2023
  25. Oct 11, 2023
  26. Oct 02, 2023
    • Liam Aharon's avatar
      Init System Parachain storage versions and add migration check jobs to CI (#1344) · db3fd687
      Liam Aharon authored
      Makes SPs first class citizens along with the relay chains in the
      context of our CI runtime upgrade checks.
      
      ## Code changes
      
      - Sets missing current storage version in `uniques` pallet
      - Adds multisig V1 migration to run where it was missing
      - Removes executed migration whos pre/post hooks were failing from
      collectives runtime
      - Initializes storage versions for SP pallets added after genesis
      - Originally I was going to wait for
      https://github.com/paritytech/polkadot-sdk/pull/1297 to be merged so
      this wouldn't need to be done manually, but it doesn't seem like it'll
      be merged any time soon so I've decided to set them manually to unblock
      this
      
      ## CI changes
      
      - Removed dependency of `westend` runtime upgrades being complete prior
      to other ones running. I assume it is supposed to cache the
      `try-runtime` build for a performance benefit, but it seems it wasn't
      working. Maybe someone from the CI team can look into this or explain
      why it needs to be there?
      
      - Adds check-runtime-migration jobs for Parity asset-hubs, bridge-hubs
      and contract chains
      
      - Updated VARIABLES to accomodate the `kusama-runtime` package being
      renamed to `staging-kusama-runtime` in
      https://github.com/paritytech/polkadot-sdk/pull/1241
      
      - Added `EXTRA_ARGS` variable to `check-runtime-migration`, and set
      `--no-weight-warnings` to the relay chain runtime upgrade checks (relay
      chains don't have weight restrictions).
      db3fd687
  27. Sep 29, 2023
    • Bastian Köcher's avatar
      Remove kusama and polkadot runtime crates (#1731) · bf90cb0b
      Bastian Köcher authored
      This pull request is removing the Kusama and Polkadot runtime crates. As
      still some crates dependent on the runtime crates, this pull request is
      doing some more changes.
      
      - It removes the `hostperfcheck` CLI command. This CLI command could
      compare the current node against the standard hardware by doing some
      checks. Later we added the hardware benchmark feature to Substrate. This
      hardware benchmark is running on every node startup and prints a warning
      if the current node is too slow. This makes this CLI command a duplicate
      that was also depending on the kusama runtime.
      
      - The pull request is removing the emulated integration tests that were
      requiring the Kusama or Polkadot runtime crates.
      bf90cb0b
  28. Sep 28, 2023
    • Michal Kucharczyk's avatar
      rococo-runtime: `RococoGenesisExt` removed (#1490) · 50242a61
      Michal Kucharczyk authored
      [`RococoGenesisExt`](https://github.com/paritytech/polkadot-sdk/blob/a414ea7515c9cdc81f1d12410e646afc148250e8/polkadot/node/service/src/chain_spec.rs#L152-L171
      
      )
      is removed. It was the hack to allow overwriting
      `EpochDurationInBlocks`. Removal of `RococGenesisExt` prevents from
      manipulating the state to change the runtime constants.
      
      Changes:
      - Environment variable which controls the `time::EpochDurationInBlocks`
      value was added: `ROCOCO_EPOCH_DURATION` (epoch duration will be set to
      the value of env),
      - `10,100,600` versions of rococo-runtime are built in CI and put into `polkadot-debug` docker image.
      
      `rococo-runtime` building examples:
      - to build runtime for `versi_staging_testnet` which had
      EpochDurationInBlocks set to 100:
        ```
      ROCOCO_EPOCH_DURATION=100 cargo build --features=fast-runtime -p
      rococo-runtime
        ```
      - to build runtime for `wococo_development`
        ```
      ROCOCO_EPOCH_DURATION=10 cargo build --features=fast-runtime -p
      rococo-runtime
        ```
      - to build `versi-staging` chain spec:
        ```
      ROCOCO_EPOCH_DURATION=100 cargo run -p polkadot --features=fast-runtime
      -- build-spec --chain versi-staging --raw
        ```
      - to build `wococo-dev` chain spec:
        ```
      ROCOCO_EPOCH_DURATION=10 cargo run -p polkadot --features=fast-runtime
      -- build-spec --chain wococo-dev --raw
        ```
      
      It is also possible to change the epoch duration by replacing the `code` field in the chain spec with the hex dump of pre-built runtime wasm blob (because the epoch duration is hard-coded into wasm blob).
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      50242a61
  29. Sep 27, 2023
  30. Sep 26, 2023
    • Dónal Murray's avatar
      Allow debug_assertions in short-benchmarks CI job (#1711) · 7d3ce4df
      Dónal Murray authored
      Add debug_assertions to WASM builds in the short-benchmarks CI job.
      
      Disallow warnings, show a full backtrace and remove the WASM output
      colour to improve information from this CI step in the event of a failure.
      
      This is motivated by a
      [case](https://github.com/paritytech/polkadot-sdk/pull/1676/commits/23d64918be3ca68413050383c5d8a73f63d451dd)
      where a benchmark was misconfigured in master and failing to send
      notifications, but passing CI. We don't want this to fail if the problem
      happens in production, but ideally we'd know from the CI if it was
      misconfigured and the messages weren't getting sent, as that could
      (would?) affect the weights that the benchmark generates.
      
      Enabling debug-assertions in WASM builds for the short-benchmarks would
      catch "soft" failures like this in future.
      7d3ce4df
  31. Sep 22, 2023