Ethereum Plans Cryptographic Shift For Future Validators

Ethereum specialists issue the proposal to rebuild the contract that gives validators the ability to deposit their ETH. Their intention is to authorize new cryptographic systems to relinquish the BLS signatures currently used. Nearly 42.4 million ETH, valued at nearly 104 billion dollars, depend on this format. The project remains a working document. It does not choose any post-quantum algorithm and does not yet ensure network protection against any attack.

The current deposit contract blocks any rapid migration

On August 24th, three researchers submitted a project for a deposit contract dedicated to Ethereum validators. Indeed, Kevaundray Wedderburn, Tom Wambsgans, and Thomas Coratger wish to prepare staking for the future adoption of signatures robust to quantum computers.

It should be noted that the deposit contract is the entry point of staking. The investor locks their ETH there before their validator can join the network, verify transactions, and participate in consensus. This procedure currently approves public keys as well as BLS signatures whose size is pre-determined.

The BLS public key used by Ethereum occupies 48 bytes, while the size of a signature is 96 bytes. This configuration offers a major advantage. Various signatures can be combined without their size increasing proportionally to the number of validators. Thus, Ethereum could efficiently perform the votes necessary for the operation of its Beacon chain.

However, this dependency can become restrictive during a future cryptographic migration. Post-quantum systems generally use large keys and signatures. Therefore, it will be complicated for the current contract to accept them without modification, even if the researchers immediately agree on a replacement algorithm.

This difficulty affects a significant part of the ecosystem. Nearly 42.4 million ETH are currently staked, worth about 104 billion dollars. The capital is not currently under threat, but the validators ensuring its security use cryptography that would become fragile in the long term.

An identifier would allow changing the cryptographic system

The contract submitted by developers could accept public keys, signatures, as well as metadata of variable length. Thus, each deposit would also contain an identifier specifying the cryptographic system used by the validator. The number zero would be reserved for the current BLS format to ensure compliance during the transition.

Future identifiers would potentially be compatible with post-quantum signatures or other devices still under development. This structure could give Ethereum a form of cryptographic flexibility. The blockchain would add a new architecture without having to rebuild the entire deposit contract.

However, the project does not intend to choose a post-quantum algorithm. It only designs the infrastructure capable of hosting one. A new protocol modification will be necessary to define rules for verification, aggregation, and processing of new signatures at the consensus level.

Various deposit data could also transit via execution layer requests. Introduced by EIP-7685, this mechanism ensures transmission of certain operations from the execution layer to the consensus layer. Note that Ethereum already uses it for deposits, withdrawals triggered from the execution layer, and validator consolidation.

The change would replace the historical architecture based on a Merkle tree. It would then gather future post-quantum deposits into the structure already adopted for multiple staking-related operations.

Ethereum could permanently close the door to BLS deposits

Several could follow this migration. The contract would first accept BLS deposits while progressively incorporating new signature formats. Ethereum clients, validators, and staking operators would thus benefit from time to adapt various tools.

A future protocol decision would contribute to disabling new deposits using the BLS system. This mechanism could be irreversible in the current version of the project. When this mode is activated, a validator can no longer join Ethereum with a key in the old format.

Already active BLS validators could not be immediately removed by this closure. Indeed, additional rules would be needed to manage migration of their keys, exits, or changes of their withdrawal identifiers. The document therefore fundamentally addresses future validators’ arrival, not the complete migration of existing operators.

Such a proposal does not take into account user wallets. While validators rely on BLS, conventional Ethereum accounts use ECDSA signatures. Accounts, KZG commitments used for data, and certain zero-knowledge proof systems require their own post-quantum solutions.

The new contract cannot be presented as a general Ethereum protection because of such a distinction. It is a piece of a broader migration affecting several layers of the protocol and much of its infrastructures.

Full protection remains scheduled around 2029

An exclusively dedicated post-quantum security team was established last January by the Ethereum Foundation. Its official action plan aims to gradually implement essential protections during 2029. This deadline remains a planning objective, not a guaranteed date.

For modifying BLS signatures, developers are notably working on leanXMSS. It is a system based on hash functions considered resistant to quantum attacks. However, the signatures are much larger than those currently used, which poses a bandwidth and processing problem.

This increase must be compensated by the LeanVM project. This type of specialized virtual machine could aggregate post-quantum signatures through cryptographic proofs. EIP-8292 proposes to entrust this task to aggregators who have the necessary hardware, without imposing this burden individually on all validators.

The infrastructure itself designs new trade-offs. Proofs will thus be produced very quickly by aggregators. They will have greater computing power than individual stakers. Researchers will therefore be called upon to prevent such a function from consolidating network centralization.

The immediate threat is not yet the quantum risk. Thus, Ethereum’s official documentation states that no current quantum computer can break the network’s cryptographic systems. Users and validators have no urgent operation to perform.

The project must now obtain publishers’ agreement, undergo technical discussion, receive an official number, and pass EIP repository checks. Implementations on clients, audits, tests on experimental networks, and selection for a future hard fork will then be necessary. Until these steps are completed, the new contract remains a first preparation, not an active protection.