### **Current Tooling Landscape** Today, validator keys are primarily managed using two popular tools: * [`staking-deposit-cli`](https://github.com/ethereum/staking-deposit-cli) * Native validator key management modules integrated into various consensus clients Both of these tools support BLS key generation and export in the standardized JSON format defined in [EIP-2335](https://eips.ethereum.org/EIPS/eip-2335). --- ### **Motivation for Change** Beam Chain is planning to adopt **WOTS+** (a hash-based, post-quantum signature scheme) in place of BLS. This transition necessitates meaningful changes to validator key infrastructure and tooling at the consensus layer. Given that multiple tools and clients interact with validator keystores, it's crucial to define a **common, forward-compatible key interchange format** to preserve interoperability across the ecosystem. --- ### **Proposal - 1: Post-Quantum Upgrade of EIP-2335** To support this evolution, we propose a quantum-secure upgrade of EIP-2335. This includes: * Support for post-quantum signature schemes (e.g., `dilithium3`, `dilithium5`, `kyber768`, `wots+`) * Improved cryptographic primitives for key derivation and encryption (`argon2id`, `xchacha20-poly1305`) * Explicit flag to indicate quantum security compliance A draft ERC can be reviewed here: [ERC Proposal – Quantum Secure Keystore Format](https://github.com/ch4r10t33r/ERCs/blob/pqs/ERCS/erc-new.md) --- ### **Proposed JSON Schema (Version 5)** ```json { "$schema": "http://json-schema.org/draft-07/schema#", "title": "Quantum-Secure Ethereum Keystore", "type": "object", "properties": { "version": { "type": "integer", "enum": [5] }, "crypto": { "type": "object", "properties": { "kdf": { "type": "string", "enum": ["argon2id"] }, "kdfparams": { "type": "object", "oneOf": [ { "properties": { "memory": { "type": "integer" }, "iterations": { "type": "integer" }, "parallelism": { "type": "integer" }, "salt": { "type": "string", "pattern": "^[a-fA-F0-9]+$" } }, "required": ["memory", "iterations", "parallelism", "salt"] }, { "properties": { "n": { "type": "integer" }, "r": { "type": "integer" }, "p": { "type": "integer" }, "salt": { "type": "string", "pattern": "^[a-fA-F0-9]+$" } }, "required": ["n", "r", "p", "salt"] } ] }, "cipher": { "type": "string", "enum": ["aes-256-gcm", "xchacha20-poly1305"] }, "cipherparams": { "type": "object", "properties": { "nonce": { "type": "string", "pattern": "^[a-fA-F0-9]+$" }, "tag": { "type": "string", "pattern": "^[a-fA-F0-9]+$" } }, "required": ["nonce", "tag"] }, "ciphertext": { "type": "string", "pattern": "^[a-fA-F0-9]+$" } }, "required": ["kdf", "kdfparams", "cipher", "cipherparams", "ciphertext"] }, "keytype": { "type": "string", "enum": ["poseidon2-ots"] }, "description": { "type": "string" }, "quantum_secure": { "type": "boolean", "const": true }, "uuid": { "type": "string", "format": "uuid" }, "path": { "type": "string" }, "meta": { "type": "object", "properties": { "created": { "type": "string", "format": "date-time" }, "version": { "type": "string" }, "network": { "type": "string" } } } }, "required": ["version", "crypto", "keytype", "quantum_secure", "uuid"] } ``` --- ### **Example Keystore (Argon2id + AES-256-GCM)** ```json { "version": 5, "uuid": "b86f38a7-7ea7-4a23-82d9-9c6d2c5ef3f7", "keytype": "secp256k1", "quantum_secure": true, "crypto": { "kdf": "argon2id", "kdfparams": { "memory": 65536, "iterations": 4, "parallelism": 2, "salt": "a1b2c3..." }, "cipher": "aes-256-gcm", "cipherparams": { "nonce": "3f2e4d...", "tag": "9fc8ac..." }, "ciphertext": "4ba69e..." }, "meta": { "created": "2025-06-17T21:00:00Z", "version": "v1.0.0", "network": "mainnet" } } ``` ### **Proposal - 2: New account management tool** Introduce a new account management utility that periodically generates multiple keys and stores them in the validator client's keystore automatically. - Supports key lifetimes configurable between 2¹⁸ and 2²⁸. - Uses a seed phrase to deterministically generate key material, with the first derived key serving as the default salt. - Upon expiry of a key's lifetime, the next ECDSA key derived from the seed is used as the salt for generating the next key batch. - Integrate the hash-sig and hash-sig-aggregation crates into a unified module to deliver the required functionality for Ream. - A useful feature would be for the account_manager to be automatically triggered by the validator when the current key's lifetime is nearing expiry. This threshold could be exposed as a configurable parameter within the validator. ---