Exchange storage key DKG artifacts over Iroh - #2434
Conversation
1e1d453 to
4550f53
Compare
| - --admin.listen=0.0.0.0:50102 | ||
|
|
||
| services: | ||
| golden-dkg-check: |
There was a problem hiding this comment.
Could you explain what this is doing?
I assume it actually runs the dkg if it wasn't done before? If so, shouldn't this go under bootstrap?
There was a problem hiding this comment.
This always runs a fresh DKG. It is an opt-in Compose integration check for the Iroh exchange, not validator provisioning. PR #2433 owns bootstrap.
| #[tokio::test] | ||
| async fn final_confirmation_cannot_be_copied_between_validator_slots() -> anyhow::Result<()> { |
There was a problem hiding this comment.
Could you add a comment to this test explaining what its guarding against
There was a problem hiding this comment.
Added. It guards against copying one validator’s signed final confirmation into another (the wrong) validator’s slot.
| #[tokio::test] | ||
| async fn iroh_board_restarts_a_runner_and_completes_three_validator_ceremony() -> TestResult { |
There was a problem hiding this comment.
Could you also add a comment here explaining what this is for?
From the name it sounds like the iroh restarts a runner, and then somehow completes a ceremony. I don't know what a runner is?
There was a problem hiding this comment.
Renamed and documented. It stops one validator after saving its identity, then proves all three validators can complete after it restarts.
There was a problem hiding this comment.
I'm finding this quite inscrutable - I don't know the goal; nor the terminology used so its really difficult to follow and hold in my head.
Can this be broken up into a simpler state machine?
There was a problem hiding this comment.
The board is the bounded transport, not the ceremony state machine. A slot is empty, valid with one value, or poisoned by a conflict. runner.rs owns the ceremony order. I added this contract at the module start. iroh-docs also has extensive doc.
| The command writes one board ticket. Send the file to each genesis validator through the authenticated bootstrap | ||
| channel. The ticket grants read access and permission to upload bounded ceremony artifacts. Do not publish it. Keep the | ||
| board running until every validator reports ceremony completion, then stop it with Ctrl-C. |
There was a problem hiding this comment.
Could you explain what a board ticket actually is?
There was a problem hiding this comment.
Documented. It contains the Iroh address, a read-only document capability, and a bearer upload secret. It contains no private DKG share.
The ticket lets validators read shared ceremony artifacts and upload their own. Since this access is shared, we send the ticket only to participating validators through the authenticated bootstrap channel.
|
I think broadly speaking this would benefit from an explanation/goal and having the code model that. |
3258fcb to
48e8586
Compare
huitseeker
changed the title
df7aa83 to
008bd45
Compare
2 participants
Stacked on #2433.
This replaces manual public file exchange with one shared Iroh document. One operator starts
dkg boardfrom the genesis file, threshold, and epoch, then sends the private ticket to each validator through the trusted bootstrap channel. Each operator runsdkg runwith that ticket, the genesis file, its signing key, a private work directory, and an output directory.The runners exchange signed public artifacts, resume after restarts, and write local storage key bundles. Operators compare the shared public output, keep each secret share private, and start validators only after every runner succeeds. An opt-in Compose check runs the full three-validator flow.
Changelog