[DRAFT] Support publishing DKG definitions with ENRs

[bussyjd]

Enable publishing DKG definitions with ENRs using --auto-p2p-key

🎯 Problem to be solved

Currently, charon create dkg supports two distinct workflows:

1. Local workflow: charon create dkg --operator-enrs XXX,YYY creates a local cluster-definition.json file
2. Published workflow: charon create dkg --operator-addresses XXX,YYY --publish publishes to API and provides a Launchpad link

The problem is that when using --operator-enrs with --publish, there's no way to automatically handle creator signing. Users who have all operator ENRs upfront should be able to publish directly to the API and allow operators to immediately run DKG without manual ENR upload via the Launchpad.

🛠️ Proposed solution

Enable the command:

charon create dkg --operator-enrs XXX,YYY --publish --auto-p2p-key

Implementation Details

1. Add --auto-p2p-key flag

• Add new boolean flag --auto-p2p-key to the create dkg command
• This flag enables automatic P2P key handling for creator signing

2. Auto P2P Key Logic

When --auto-p2p-key is provided with --publish:

• Try to load existing P2P key from .charon/charon-enr-private-key
• If not found, generate a temporary P2P key
• Use this address for creator signing

3. Output Messages

Provide clear, differentiated output based on the workflow:

When publishing with ENRs:

INFO Cluster Definition Published
INFO Operators can run the following command from folders containing their private keys:
INFO charon dkg --definition-file https://api.obol.tech/dv/<definition-hash>

When publishing with addresses (existing behavior):

INFO Cluster Invitation Prepared
INFO Direct the Node Operators to: https://launchpad.obol.org/dv#<hash>

🧪 Tests

Required Test Coverage

1. Test auto-p2p-key with existing key

   • Create a p2p key at .charon/charon-enr-private-key
   • Verify it's loaded and used for creator signing
   • Verify appropriate log message

2. Test auto-p2p-key without existing key

   • Ensure no key exists at expected path
   • Verify temporary key is generated
   • Verify creator signing works with generated key

3. Test flag validation

   • --auto-p2p-key without --publish should be ignored or error
   • --publish with --operator-enrs but without --auto-p2p-key should fail with clear error message

4. Integration test

   • Full workflow from command to published definition
   • Verify output messages are correct

📝 Example Usage

Creator with existing P2P key:

When the creator already has a charon node setup with an existing P2P key at .charon/charon-enr-private-key:

• The existing P2P key will be loaded
• An Ethereum address will be derived from this key for creator signing
• The cluster definition will be published with ENRs ready for immediate DKG

Creator without P2P key:

When running from a fresh environment without an existing charon setup:

• A temporary P2P key will be generated
• An Ethereum address will be derived from this temporary key for creator signing
• The cluster definition will be published with ENRs ready for immediate DKG
• The temporary key is not persisted (unless future requirements change)

✅ Acceptance Criteria

• --auto-p2p-key flag is added to create dkg command
• When used with --publish and --operator-enrs, automatically handles creator signing
• Loads existing P2P key from .charon/charon-enr-private-key if available
• Comprehensive test coverage for all scenarios
• Documentation updated to explain the new flag and workflow

🚫 Out of Scope

• Modifying the existing Launchpad workflow
• Changing behavior when --auto-p2p-key is not provided
• Persisting generated temporary keys

📚 Context

• PR *: allow --operator-enrs on publishing definition to API #3993 adds basic support for --operator-enrs with --publish
• This issue adds the missing --auto-p2p-key mechanism for creator signing
• Enables fully automated DKG ceremonies without Launchpad interaction

Implementation Notes

• Build on top of PR *: allow --operator-enrs on publishing definition to API #3993 which adds basic --operator-enrs with --publish support
• The P2P key serves dual purpose: libp2p identity and creator authentication source
• Ethereum address derivation follows standard: keccak256(pubkey)[12:] with EIP55 checksum
• This approach maintains security boundaries between networking/authentication and validator operations