chore(dkg): add debug logging for DKG deal flow and proof verification#79
chore(dkg): add debug logging for DKG deal flow and proof verification#79yingyangxu2026 wants to merge 1 commit into
Conversation
Logging-only (no behavior change). Adds debug/forensic logging across the DKG
deal path, resharing committee construction, and the verified-query proof
checks, so dealing/finalization issues are diagnosable from logs:
- new debug_dump helpers (fmtPubKeys/fmtRegs/fmtAddrs/hexHead) produce compact,
comparable fingerprints of committees and keys.
- query_client.go: getDKGRegistration names the validator being proven;
getStoreData logs key/height/is_non_existence (success debug, failure warn);
verifyModuleNonExistenceProof dumps proof key, expected vs calculated root and
the Left/Right neighbor keys on both success and failure (shared
nonExistProofFields); GetAllParticipantDKGRegistrations dumps the resulting
committee plus the dropped/unregistered members.
- round_context.go: fetchRoundContext dumps the committee and sorted pub keys.
- dist_key_gen.go: build/rebuild Resharing{Prev,Next}DKG dump OldNodes/NewNodes
with a source label; replayMessages logs the committee on a deal replay failure.
- dkg_generate_deals.go: GenerateDeals logs this node's dealer index and recipients.
- dkg_process_deals.go: logs the previously-silent out-of-range deal rejection and
enumerates rejected sender indices.
- dkg_finalize.go: dumps the committee on "distributed key not certified" and on success.
High-frequency per-item logs are at debug level (off by default in production);
per-operation committee dumps and summaries at info; rejections/failures at warn/error.
|
Logging-only PR — no behavioral changes to the DKG protocol itself. The helper functions in Review iteration 1 · Commit 2b8e0bd · 2026-06-18T10:05:37Z |
There was a problem hiding this comment.
Do we need this dump file in our repo?
| "num_deals": len(st.Deals), | ||
| "error": err, | ||
| }).Warn("failed to replay deal") | ||
| }).Warn("failed to replay deal (likely committee divergence: compare new_nodes vs chain-fetch committee)") |
There was a problem hiding this comment.
Likely committee divergence when error is returned while processing deal? Isn't it enough to log error here?
There was a problem hiding this comment.
Same question. Do we need this included in the repo?
| // committee (which keeps them). noReg = absence-proven (never registered, e.g. | ||
| // the non-TEE validator); dropped = registered but NOT in VERIFIED/FINALIZED | ||
| // (the INVALIDATED nodes that vanish here but persist in sealed state). | ||
| var noReg, dropped []string |
There was a problem hiding this comment.
Why do we need to track noReg and dropped here?
3 participants
Motivation
While debugging DKG bootstrap failures on devnet, the existing kernel logging was too sparse to localize what was happening during dealing/finalization — committee construction, deal/response certification, and the verified-query proof checks. This adds debug/forensic logging so those paths are diagnosable from logs.
Logging-only — no behavior change.
What's added
debug_dumphelpers (fmtPubKeys/fmtRegs/fmtAddrs/hexHead) — compact, comparable fingerprints of committees and keys.query_client.go—getDKGRegistrationnames the validator being proven;getStoreDatalogs key/height/is_non_existence(success at debug, failure at warn);verifyModuleNonExistenceProofdumps proof key, expected vs calculated root and the Left/Right neighbor keys on both success and failure (sharednonExistProofFields);GetAllParticipantDKGRegistrationsdumps the resulting committee plus dropped/unregistered members.round_context.go—fetchRoundContextdumps the committee and sorted pub keys.dist_key_gen.go— build/rebuildResharing{Prev,Next}DKGdumpOldNodes/NewNodeswith a source label;replayMessageslogs the committee on a deal replay failure.dkg_generate_deals.go—GenerateDealslogs this node's dealer index and recipients.dkg_process_deals.go— logs the previously-silent out-of-range deal rejection and enumerates rejected sender indices.dkg_finalize.go— dumps the committee ondistributed key not certifiedand on success.Log levels
High-frequency per-item logs at
debug(off by default in production); per-operation committee dumps and summaries atinfo; rejections/failures atwarn/error.Context
These logs were used to localize #76 and #77 (and complement piplabs/story#845). Pairs with the story-side debug-logging PR.