Align DKG skipped-self-share flow with protocol spec and benchmarks

[hmzakhalid]

Context

PR #1529 changes DKG share handling so a ciphernode no longer encrypts and sends its own DKG share to itself. This should reduce redundant ZkShareEncryption work from n * n * L * 2-style behavior to the intended n * (n - 1) * L * 2 behavior, assuming the rest of the DKG flow correctly treats the node's own share as local material.

Discussion around the PR raised two related concerns:

1. The implementation and theoretical protocol flow should match as closely as possible, especially around which shares are encrypted, which shares are local, and how C4 / aggregation consumes those shares.
2. Benchmark results from the branch currently do not appear to make sense, and the new parameter set still needs to be applied before relying on the numbers.

Problem

We need to verify that the skipped-self-share implementation is correct end-to-end and that the resulting benchmark metrics are meaningful.

In particular, the new flow should make it explicit that each node:

• encrypts and sends shares only for the other n - 1 parties;
• keeps its own share locally instead of round-tripping it through encryption/decryption;
• still provides C4 / DKG aggregation with the full set of n shares, consisting of n - 1 decrypted remote shares plus the local self share;
• preserves the expected proof indexing, witness layout, and validation semantics after moving from dense to sparse recipient encryption;
• does not accidentally weaken the intended binding between party identity, DKG material, proofs, and commitments.

There is also a related protocol-description issue for the paper: the written/theoretical flow should not claim stronger checks than the implementation actually performs. For example, current discussion suggests that off-chain signatures cover signed proof payloads, while the on-chain aggregator submission verifies a combined proof rather than per-party signatures over every commitment. We should confirm the exact implementation behavior before describing it.

Tasks

• Review PR feat: stop encrypting DKG shares to self #1529 end-to-end and confirm the skipped-self-share flow is correct for DKG.
• Confirm C4 input construction still receives exactly one share per party: n - 1 decrypted remote shares plus the node's local share.
• Check proof counts and indexing after sparse recipient encryption, especially for ZkShareEncryption / C3a / C3b.
• Verify validation and error paths for malformed sparse layouts, missing plaintexts, or mismatched proof counts.
• Apply the new parameter set before running final benchmarks.
• Re-run benchmarks for the target configurations, including n = 5 if feasible.
• Compare expected proof counts against observed benchmark counters.
• Investigate any benchmark numbers that still do not make sense after applying the new parameter set.
• Document the exact implementation-level DKG aggregation flow so the paper does not overstate signature / commitment checks.
• Decide whether additional binding checks are required between party slots, signed proof payloads, and aggregated DKG material.

Expected outcome

The PR should either:

1. land with benchmarks and documentation that clearly show the optimized skipped-self-share flow is correct; or
2. identify the remaining implementation/protocol gaps that need to be fixed before relying on the optimization or describing it in the paper.

Related

• PR feat: stop encrypting DKG shares to self #1529: feat: stop encrypting DKG shares to self