fix: enode field should contain node ID, not private key

[saeeddawod]

Summary

The enode field in GeneratedNodeKey was incorrectly set to the private key instead of the node ID (public key with 0x04 prefix stripped).

Issues Fixed

• Individual validator enode ConfigMaps contained private keys instead of node IDs
• Duplicate private key data (stored in both privateKey and enode fields)
• Misleading ConfigMap names (besu-node-validator-X-enode contained private key)

Changes

1. Fixed src/keys/node-key-factory.ts: Strip the 0x04 prefix from the public key to derive the node ID
2. Fixed src/keys/node-key-factory.test.ts: Updated test to validate correct behavior (enode should be 128-char hex node ID)

Testing

• ✅ All 90 tests pass
• ✅ Verified enode field now contains correct node ID format

Note

This bug only affected the individual validator enode field. The static-nodes.json generation was not affected because it used the correct deriveNodeId() function.

Links

• Bug in code:

  network-bootstrapper/src/keys/node-key-factory.ts

  Line 30 in 184bc94

  const enode = privateKey;

• Test that validated bug:

  network-bootstrapper/src/keys/node-key-factory.test.ts

  Line 15 in 184bc94

  expect(first.enode).toBe(first.privateKey);

Summary by Sourcery

Fix incorrect enode field derivation by using the public key (node ID) instead of the private key, and update tests to validate the new behavior.

Bug Fixes:

• Derive enode node ID by stripping the 0x04 prefix from the uncompressed public key instead of reusing the private key

Tests:

• Update NodeKeyFactory tests to assert enode is a 128-character hex node ID without 0x prefix and unique per key

[gemini-code-assist]

Summary of Changes

Hello @saeeddawod, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a significant bug that led to sensitive private key information being stored in the "enode" field of generated node keys. The fix ensures that the "enode" field now correctly contains the public node ID, improving security, eliminating data redundancy, and clarifying the purpose of validator configuration maps. This change is crucial for maintaining the integrity and security of node key generation.

Highlights

• Critical Enode Field Correction: Resolved a bug where the "enode" field in "GeneratedNodeKey" was erroneously storing the private key instead of the public node ID, addressing security and data duplication concerns.
• Node ID Derivation Logic: Implemented logic in "node-key-factory.ts" to correctly derive the "enode" by stripping the "0x04" prefix from the public key, ensuring the "enode" represents the node's identifier.
• Enhanced Test Validation: Updated "node-key-factory.test.ts" to include explicit assertions verifying that the "enode" field now contains the 128-character hex node ID, without the "0x" prefix, and is distinct from the private key.
• Dependency Updates: Several development and runtime dependencies were updated in "bun.lock" to their latest versions, including "@adraffy/ens-normalize", "@trpc/server", "@types/bun", "@types/node", "b4a", "bare-events", "bare-fs", "bun-types", "oauth4webapi", "openid-client", "streamx", and "typescript".

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[sourcery-ai]

Hey there - I've reviewed your changes and they look great!

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location> `src/keys/node-key-factory.test.ts:17-19` </location>
<code_context>
-    expect(first.enode).toBe(first.privateKey);
+
+    // enode should be the node ID (public key with 0x04 prefix stripped)
+    expect(first.enode).toBe(first.publicKey.slice(4));
+    expect(first.enode).not.toContain("0x");
+    expect(first.enode.length).toBe(128); // 64 bytes hex-encoded

     expect(first.privateKey).not.toBe(second.privateKey);
</code_context>

<issue_to_address>
**issue (testing):** The test assumes the public key always starts with '0x04', which may not be universally true.

To prevent unexpected test failures, update the test to verify the prefix before slicing or align its logic with the implementation's handling of public keys.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[gemini-code-assist]

Code Review

This pull request correctly fixes a critical security issue where a private key was being exposed in the enode field. The change to derive the node ID from the public key is appropriate, and the corresponding test updates are well-written to validate the new behavior. I have one suggestion to improve the robustness of the node ID derivation logic.

[gemini-code-assist]

While the current logic works because privateKeyToAccount provides an uncompressed public key (prefixed with 0x04), the fallback case publicKey.slice(2) is potentially misleading. It could lead to incorrect node IDs if the public key format ever changes (e.g., to a compressed key), and this fallback is not covered by tests. A more robust approach would be to explicitly handle only the expected format and throw an error for unexpected formats. This makes the code's intent clearer and prevents silent failures in the future.

    const enode = (() => {
      // `privateKeyToAccount` is expected to return an uncompressed key starting with "0x04".
      if (!publicKey.startsWith("0x04")) {
        throw new Error(
          `Failed to derive node ID: public key has unexpected format. Expected \"0x04...\" prefix.`
        );
      }
      return publicKey.slice(4);
    })();

[cubic-dev-ai]

No issues found across 3 files