Skip to content
Snippets Groups Projects
  1. Feb 02, 2024
  2. Jan 11, 2024
  3. Jan 10, 2024
    • ordian's avatar
      statement-distribution: validator disabling (#1841) · a4195326
      ordian authored
      
      Closes #1591.
      
      The purpose of this PR is filter out backing statements from the network
      signed by disabled validators. This is just an optimization, since we
      will do filtering in the runtime in #1863 to avoid nodes to filter
      garbage out at block production time.
      
      - [x] Ensure it's ok to fiddle with the mask of manifests
      - [x] Write more unit tests
      - [x] Test locally
      - [x] simple zombienet test
      - [x] PRDoc
      
      ---------
      
      Co-authored-by: default avatarTsvetomir Dimitrov <tsvetomir@parity.io>
  4. Jan 08, 2024
  5. Dec 15, 2023
    • Javier Viola's avatar
      fix zombienet test (#2719) · ddd5434e
      Javier Viola authored
      Remove old version for `cli_args`, since this was fixed in the latest
      version of zombienet and the `latest` version of polkadot introduce the
      new flag `--insecure-validator-i-know-what-i-do`.
      
      Fix jobs like
      https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4726174
      Thx!
  6. 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 <alexandru.gheorghe@parity.io>
  7. 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 <javier@parity.io>
      Co-authored-by: default avatarMarcin S. <marcin@realemail.net>
      Co-authored-by: default avatarTsvetomir Dimitrov <tsvetomir@parity.io>
  8. Nov 16, 2023
  9. Nov 15, 2023
    • Alexander Samusev's avatar
      [CI] Prepare CI for Merge Queues (#2308) · 5b0622bc
      Alexander Samusev authored
      PR prepares CI to the GitHub Merge Queues. All github actions that were
      running in PR adjusted so they can run in the merge queues. Zombienet
      jobs will do nothing during PRs but they will run during merge queues.
      
      Jobs that will be skipped during PR:
       - all zombienet jobs
       - all publish docker jobs
      
      Jobs that will be skipped during merge queue:
       - check-labels
       - check-prdoc
       - pr-custom-review
       - review trigger
      
      cc https://github.com/paritytech/ci_cd/issues/862
  10. 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-di...
  11. Sep 27, 2023
  12. Sep 13, 2023
  13. Sep 06, 2023
  14. Aug 30, 2023
  15. Aug 29, 2023
  16. Aug 25, 2023