Rust DKG/reshare orchestration over the new session runtime - #178
Merged
Merged
Conversation
Drive wire-mesh-threshold's existing dkg/reshare round functions over real manage-request traffic, matching threshold-dkg.ts's own choreography: round1 broadcast, round2 pairwise exchange, round3 local computation, and an echo-broadcast confirm round; resharing's own asymmetry where only survivors deal and every member of the new participant set independently derives and confirms. Since Session (wire-mesh#173) is scoped to one already-established connection rather than TS's single addressable mesh session, this orchestration layer holds one PerDeviceCollector per round (round1, round2, confirm) keyed by peer device-id, fed by plain handle_keygen_round1/round2/confirm functions a caller's own ManageRequestHandler dispatches into. Those functions, and the collectors themselves, stay free of any dependency on wire_mesh_core::domain::session (a "net"-gated module) by implementing PerDeviceCollector's async wait as a hand-rolled Future over a plain std::sync::Mutex rather than a tokio::sync::oneshot -- keeping wire-mesh-threshold's own [dependencies] runtime-free, matching the existing constraint that wire-mesh-threshold-wasm's wasm32-unknown-unknown build needs wire-mesh-core's "net" feature off to succeed at all.
…tion Exercise run_fresh_threshold_dkg, compute/send_reshare_contribution, and join_threshold_reshare over an in-process ManageRequestSender that dispatches directly into a peer's own collectors, covering a 3-party fresh DKG, a reshare to a different committee (one device dropped, one added) verified by signing against the original group key, and a tampered confirm digest aborting only the receiving device. WIP: the reshare/tamper tests currently hang under cargo test and need further debugging before this is safe to merge.
…ommittee The reshare test previously modelled survivor 2 as leaving the new committee (only running contribute_threshold_reshare) while also listing it in new_participants, so survivor 1 and the new device would send survivor 2 a keygen-confirm and then wait forever for a confirm back that a non-joining device never sends. Both remaining survivors now run compute_reshare_contribution + send_reshare_contribution + join_threshold_reshare concurrently, matching the actual "one dropped, one added" scenario wire-mesh#177 asks for, where neither retained survivor ever leaves the committee.
…ssions End-to-end proof that keygen_network's orchestration drives real Session/HandlerRegistry dispatch, matching the discipline session_runtime_network.rs already established for threshold signing: a fresh 2-of-3 DKG across three real TCP connections (A, B, C), then a reshare to a different 2-of-3 committee that drops C and adds a brand-new device D, then signing with the reshared committee (B and D, who never held a share together before the reshare) and verifying the aggregate signature against the ORIGINAL group's public key. Each phase establishes its own fresh connections rather than reusing one across phases, since a Session's HandlerRegistry is fixed at accept time and the signing phase's handler needs the post-reshare KeyPackage, which does not exist yet when the reshare's own connections are first accepted.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds the Rust equivalents of threshold-dkg.ts's runFreshThresholdDkg/computeReshareContribution/sendReshareContribution/joinThresholdReshare (wire_mesh_threshold::keygen_network), driving the crate's existing dkg/reshare round functions over real manage-request traffic via the same ManageRequestSender contract network.rs already uses for signing.
Since Session (wire-mesh#173) is scoped to one already-established connection rather than TS's single addressable mesh session, a device running a ceremony among N peers holds N per-peer collectors fed by plain handle_keygen_round1/round2/confirm functions; a caller's own ManageRequestHandler dispatches into them, exactly the pattern tests/session_runtime_network.rs already established for threshold signing. The collectors themselves are a hand-rolled Future over a std::sync::Mutex rather than tokio::sync::oneshot, keeping wire-mesh-threshold's [dependencies] runtime-free so wire-mesh-threshold-wasm's wasm32-unknown-unknown build stays unaffected.
Proven end to end exactly as #173 did for signing: tests/keygen_network_session.rs runs a fresh 2-of-3 DKG across three real TCP connections (A, B, C), reshares to a different 2-of-3 committee that drops C and adds a brand-new device D, then signs with B and D -- who never held a share together before the reshare -- and verifies the aggregate signature against the ORIGINAL group's public key.
Closes #177