Implement dkg command

[iamquang95]

Description

Implement cmd/dkg command

Acceptance criteria

Should port all tests from charon and pass these tests. Should have a demo/runnable example.

[iamquang95]

Sub issues

• Implement app/privkeylock #44
• dkg
  • Implement dkg/dkg #251
  • Implement dkg/bcast #132
  • Implement dkg/sync #133
  • Implement dkg/disk #252
  • Implement dkg/exchanger #253
  • Implement dkg/frost #254
  • Implement dkg/frostp2p #255
  • Implement dkg/nodesigs #256
  • Implement dkg/share #257
• Implement cmd/dkg #314
• Implement core/parsigdb #174
• Implement core/parsigex #175
• Implement app/utils #245
• Implement p2p/bootnode #130
• Implement cluster/helpers #246
• Implemenet Definition.verify_signatures #247
• Implement Lock.verify_signatures #248
• Finish cluster/version #249
• Implement core/signneddata #250

[varex83agent]

DKG Implementation Roadmap

This comment tracks the full implementation plan for the dkg command, decomposed from Charon's dkg/dkg.go into parallel work streams.

---

Current State

Component	Status	PR
Reliable broadcast (bcast)	✅ Merged	#290
Disk I/O + share types	✅ Merged	#285
Parsig DB	✅ Merged	#278
Sync protocol	🔄 In review	#311
DKG CLI command (entry point)	🔄 In review	#308
Parsigex	🔄 Draft	#291
FROST DKG	❌ Not started	—
Node signatures	❌ Not started	—
Sign & aggregate (deposit, registrations, lock hash)	❌ Not started	—
Write artifacts	❌ Not started	—
Ceremony orchestration	❌ Not started	—

---

Ceremony Sequence

The Run() function is a linear ceremony with 7 sync-gated steps. All peers must reach each barrier together before proceeding.

Init & validate
  → Setup P2P node
    → Start sync, await all peers connected
      ─── Step 1: FROST DKG (key generation) ───────────────── nextStepSync
      ─── Step 2: Sign & aggregate deposit data ─────────────── nextStepSync
      ─── Step 3: Sign & aggregate validator registrations ───── nextStepSync
      ─── Step 4: Sign & aggregate lock hash ─────────────────── nextStepSync
      ─── Step 5: Exchange node K1 signatures ─────────────────── nextStepSync
      ─── Step 6: Verify + write artifacts ────────────────────── nextStepSync
      ─── Step 7: Shutdown sync ───────────────────────────────────────────────

---

Work Streams

Each stream maps to a distinct module and can be developed independently.

Stream A — P2P Setup

Target: crates/dkg/src/p2p_setup.rs
Charon ref: setupP2P() (dkg.go:1281)

Boots the libp2p node for the DKG ceremony: relay connections, connection gating, relay reserver/router, and peerinfo registration. Mostly wiring existing p2p crate infrastructure.

Can start: immediately — no DKG-specific dependencies.

---

Stream B — Ceremony Initialization & Config

Target: crates/cli/src/commands/create_dkg.rs, crates/dkg/src/dkg.rs
Charon ref: Run() preamble (dkg.go:112–287), AppendConfig (dkg.go:94)

Validates all preconditions before the ceremony starts: private key locking, definition loading or append-mode config, version checks, keymanager connectivity, data-dir validation, peer/node index resolution, peer map construction.

Functions: validateKeymanagerFlags(), getExistingShares(), logPeerSummary(), AppendConfig struct.

Can start: after #308 merges.

---

Stream C — FROST DKG

Target: crates/dkg/src/frost.rs, crates/dkg/src/frost_p2p.rs
Charon ref: frost.go (271 LOC), frostp2p.go (558 LOC)

The actual key generation ceremony. FROST is a two-round protocol:

• Round 1: broadcast commitments + send peer-to-peer Shamir shares
• Round 2: broadcast verification keys

Runs in parallel for N validators. The FrostP2P transport wraps bcast to route messages by round and peer index.

Functions: newFrostP2P(), runFrostParallel(), round1(), round2(), makeShares().

Note: requires a Rust FROST library — frost-core + frost-bls12_381 are the closest equivalents to Charon's coinbase/kryptology.

Can start: after #311 merges (sync provides the step barrier between DKG and the next phase).

---

Stream D — Sign & Aggregate

Target: crates/dkg/src/signing.rs
Charon ref: signAndAgg* functions (dkg.go:629–1181)

Covers ceremony Steps 2, 3, and 4. All three follow the same pattern: sign locally → exchange partial sigs via parsigex → threshold aggregate.

Function	Step
signDepositMsgs + aggDepositData + signAndAggDepositData	Step 2
signValidatorRegistrations + aggValidatorRegistrations + signAndAggValidatorRegistrations	Step 3
signLockHash + aggLockHashSig + signAndAggLockHash + createDistValidators	Step 4

Also includes type conversion helpers: builderRegistrationFromETH2(), setRegistrationSignature().

Can start: after #291 (parsigex) merges.

---

Stream E — Node Signatures

Target: crates/dkg/src/nodesigs.rs
Charon ref: nodesigs.go (258 LOC)

After the lock is built, each operator signs the lock hash with their secp256k1 node key and broadcasts these K1 signatures to all peers via bcast. Proves each operator endorses the final lock file.

Functions: newNodeSigBcast(), NodeSigBcast::exchange(), message ID registration, deduplication.

Can start: immediately — only depends on bcast which is already merged.

---

Stream F — Write Artifacts

Target: extend crates/dkg/src/disk.rs, crates/dkg/src/publish.rs
Charon ref: Run() lines 401–459, writeLockToAPI() (dkg.go:1184)

After all signatures are collected and verified, persist everything:

• Write key shares to keymanager (HTTP) or encrypted keystores on disk
• Publish lock file to Obol API and return Launchpad dashboard URL
• Write deposit data files per amount (partial deposit support)
• Merge existing deposit data in append mode
• Optionally bundle output as dkg.tar.gz

Can start: after Stream D (needs the completed lock and deposit data).

---

Stream G — Ceremony Orchestration (integration point)

Target: crates/cli/src/commands/create_dkg.rs — the run() function body
Charon ref: Run() main body (dkg.go:112–489)

Wires all streams together in sequence, advancing the sync step barrier between each phase. This is the last stream to implement.

Depends on: all of A–F complete.

---

Dependency Graph

bcast ✅ ──────────────────────────── Stream E (node sigs)
                                             │
p2p ✅ ──── Stream A (P2P setup) ────────────┤
                                             │
#308 ──────── Stream B (init) ───────────────┤
                                             │
#311 ──────── Stream C (FROST) ──────────────┤
                                             ▼
#291 ──────── Stream D (sign & agg) ──► Stream F (artifacts)
                                             │
                                             ▼
                                       Stream G (orchestration)

---

Suggested Implementation Order

Priority	Stream	Parallelizable with
1	Merge #311, #291, #308	—
2	E — Node signatures	A — P2P setup
3	C — FROST DKG	D — Sign & aggregate
4	B — Ceremony init	—
5	F — Write artifacts	—
6	G — Ceremony orchestration	—

Streams E and A can begin immediately in parallel. Streams C and D can start as soon as their respective blocking PRs merge. G is the final integration step.