feat: CON-1665 Include NiDKG dealings into blocks based on priority

[eichhorl]

Background

At the start of each interval, nodes broadcast NiDKG dealings for key generation and resharing. These dealings are included into data blocks. Once enough dealings exist on chain, they may be aggregated into a full NiDKG transcript. #8469 allows the subnet to aggregate dealings not only in the following summary block, but already as part of data blocks, as soon as enough dealings exist on the parent chain.

Problem

Due to size and validation time, the number of dealings to be included on chain is limited (currently to 1 dealing per block). Additionally, the current behavior of selecting dealings to be included is sub-optimal:

1. The subnet attempts to include all (up to N) dealings on chain, even if only f+1 (fresh key) or 2f+1 (high threshold re-sharing) dealings are required to create the transcript.
2. The dealings are selected pseudo-randomly (based on the order of their hashes). This means, on average, all transcripts will complete at roughly the same time, once enough dealings for all of them exist on chain. This has an adverse effect on latency.

Proposed Changes

This PR proposes to stop including more dealings for a config once the config's collection_threshold has been reached. Additionally, dealings receive priority to be included based on the following conditions (in order of precedence):

1. While there are less than MAX_REMOTE_DKGS_PER_INTERVAL (currently set to 1) completed remote targets in the current interval, prioritize remote dealings. Otherwise, prioritize local dealings. This is to improve the latency of remote DKG requests such as SetupInitialDKG and ReshareChainKey. The number of prioritized remote DKGs is limited to avoid starving local DKG. Note that currently, the number of remote DKG configs per interval is also limited to 1 (by the same constant). This may however disappear in the future.
2. Among remote targets, prioritize dealings for targets that are closer to their collection threshold. This ensures progress is being made for one specific target (instead of all of them at once), which improves best- and average-case latency of remote DKG requests.

Future Work

Instead of only starting to work on remote DKG requests at the beginning of an interval, we will do so also as part of data blocks, as soon as the remote DKG request appears in the replicated state.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR improves NiDKG dealing selection for data block payloads by capping inclusion per config at collection_threshold and introducing a priority scheme that favors remote DKG progress (within limits) to reduce latency.

Changes:

• Replaces the previous “include any new dealer not on-chain yet” selection with select_dealings_for_payload, enforcing collection_threshold and prioritizing remote targets.
• Adds extensive unit tests covering selection capping, duplicate filtering, remote prioritization, and tie-breaking.
• Updates an existing test to use 4 nodes (was 3), aligning with new selection behavior/assumptions.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
rs/consensus/dkg/src/payload_builder.rs	Introduces prioritized dealing selection logic and adds unit tests for the new behavior.
rs/consensus/dkg/src/lib.rs	Adjusts an existing test setup (node count) to match updated dealing selection expectations.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[pierugo-dfinity]

Looks great, nice!