1. Dec 13, 2023
    • Alexandru Gheorghe's avatar
      Approve multiple candidates with a single signature (#1191) · a84dd0db
      Alexandru Gheorghe authored
      Initial implementation for the plan discussed here: https://github.com/paritytech/polkadot-sdk/issues/701
      Built on top of https://github.com/paritytech/polkadot-sdk/pull/1178
      v0: https://github.com/paritytech/polkadot/pull/7554,
      
      ## Overall idea
      
      When approval-voting checks a candidate and is ready to advertise the
      approval, defer it in a per-relay chain block until we either have
      MAX_APPROVAL_COALESCE_COUNT candidates to sign or a candidate has stayed
      MAX_APPROVALS_COALESCE_TICKS in the queue, in both cases we sign what
      candidates we have available.
      
      This should allow us to reduce the number of approvals messages we have
      to create/send/verify. The parameters are configurable, so we should
      find some values that balance:
      
      - Security of the network: Delaying broadcasting of an approval
      shouldn't but the finality at risk and to make sure that never happens
      we won't delay sending a vote if we are past 2/3 from the no-show time.
      - Scalability of the network: MAX_APPROVAL_COALESCE_COUNT = 1 &
      MAX_APPROVALS_COALESCE_TICKS =0, is what we have now and we know from
      the measurements we did on versi, it bottlenecks
      approval-distribution/approval-voting when increase significantly the
      number of validators and parachains
      - Block storage: In case of disputes we have to import this votes on
      chain and that increase the necessary storage with
      MAX_APPROVAL_COALESCE_COUNT * CandidateHash per vote. Given that
      disputes are not the normal way of the network functioning and we will
      limit MAX_APPROVAL_COALESCE_COUNT in the single digits numbers, this
      should be good enough. Alternatively, we could try to create a better
      way to store this on-chain through indirection, if that's needed.
      
      ## Other fixes:
      - Fixed the fact that we were sending random assignments to
      non-validators, that was wrong because those won't do anything with it
      and they won't gossip it either because they do not have a grid topology
      set, so we would waste the random assignments.
      - Added metrics to be able to debug potential no-shows and
      mis-processing of approvals/assignments.
      
      ## TODO:
      - [x] Get feedback, that this is moving in the right direction. @ordian
      @sandreim @eskimor @burdges, let me know what you think.
      - [x] More and more testing.
      - [x]  Test in versi.
      - [x] Make MAX_APPROVAL_COALESCE_COUNT &
      MAX_APPROVAL_COALESCE_WAIT_MILLIS a parachain host configuration.
      - [x] Make sure the backwards compatibility works correctly
      - [x] Make sure this direction is compatible with other streams of work:
      https://github.com/paritytech/polkadot-sdk/issues/635 &
      https://github.com/paritytech/polkadot-sdk/issues/742
      
      
      - [x] Final versi burn-in before merging
      
      ---------
      
      Signed-off-by: default avatarAlexandru Gheorghe <[email protected]>
      a84dd0db
  2. Dec 12, 2023
  3. Dec 06, 2023
  4. Dec 05, 2023
  5. Dec 01, 2023
  6. Nov 30, 2023
  7. Nov 29, 2023
  8. Nov 28, 2023
  9. 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
  10. Nov 25, 2023
  11. Nov 24, 2023
  12. Nov 23, 2023
  13. Nov 22, 2023
  14. Nov 21, 2023
  15. Nov 17, 2023
  16. Nov 16, 2023
  17. Nov 15, 2023
  18. Nov 13, 2023
  19. 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
  20. Nov 05, 2023
  21. Nov 02, 2023
  22. Oct 31, 2023
  23. Oct 30, 2023
  24. Oct 24, 2023
  25. Oct 19, 2023
  26. Oct 18, 2023
  27. Oct 17, 2023
  28. Oct 11, 2023
  29. 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