How Ethereum plans to replace BLS with Post-Quantum signatures

For many happy years we've built our digital world, including the decentralized digital world, on the shoulders of Diffie-Hellman, RSA, ElGamal and elliptic curves. The classic public key cryptography that most of us use for key exchange and digital signatures is unfortunately under threat. Well, the threat might be multiple with the uprising of AI, but in this case we're focusing on the threat of quantum computers. If a quantum computer is built that can execute Shor's algorithm (which breaks both elliptic curve cryptography and RSA), secret keys can be deduced from the public keys and thus digital signatures can be forged.

Ethereum is exposed to this threat as well, since it uses pairing-based signatures throughout the stack which are based on elliptic curves and thus not quantum-safe. As part of the lean Ethereum roadmap, Ethereum aims to upgrade all its cryptography to be quantum-safe. It is important to note that the threat of quantum computers in the case of Ethereum is not just the realization of quantum computers itself, it is the fear of this potentially happening that can jeopardize the system, since it ultimately depends on people and their trust in the system.

In this post we'll dive into research progress that has been shared by the lean Ethereum team. Blockchains are proudly built on cryptography and in the case of Ethereum there is usage of various cryptographic algorithms in the consensus, execution and data layer. All of which are not quantum-secure. We're going to focus on the cryptography used for consensus on Ethereum and what is currently planned for the movement to post-quantum cryptography in this area.

How signatures are used in Ethereum consensus now

Since The Merge, Ethereum's consensus relies on a proof-of-stake consensus mechanism. Validators need to re-execute the transactions in the block and check that those, as well as the block signature, are valid. Then the validator sends an attestation regarding the block's correctness across the network, which in itself is a signature. Since there are 900k-1M active validators for the Ethereum network at the time of writing (ref 1, 2), having to verify each signature separately becomes a huge overhead. This is where the BLS signature scheme comes to the rescue.

We provide a brief introduction to BLS signatures based on bilinear pairings. You can look at the references at the end of this article for a more complete introduction.

A bilinear pairing on groups G₁ = ⟨g₁⟩, G₂ = ⟨g₂⟩ and Gₜ of prime order q is a map e : G₁ × G₂ → Gₜ which satisfies the following three conditions:

• Bilinear. For all r ∈ G₁, s ∈ G₂ and a, b ∈ ℤq:

e(rᵃ, sᵇ) = e(r, s)ᵃᵇ

• Non-degenerate. e(g₁, g₂) ≠ 1_Gₜ.

• Efficiently computable.

To define the BLS signature scheme (for a single signature) in addition we need a hash function H: {0,1}* → G₁. The signature scheme works as follows:

1. KeyGen. Choose random sk ←ᴿ ℤq and let pk = g₂ˢᵏ ∈ G₂. Output (sk, pk).

2. Sign(sk, m). Set σ = H(m)ˢᵏ ∈ G₁. Output σ.

3. Verify(pk, m, σ). Check e(σ, g₂) ≟ e(H(m), pk). If this holds accept, otherwise reject.

Notice that the signature consists of a single element in group G₁. To verify why the signature verification makes sense, use the bilinearity property of the pairing:

e(σ, g₂) = e(H(m)ˢᵏ, g₂)

= e(H(m), g₂)ˢᵏ

= e(H(m), g₂ˢᵏ)

= e(H(m), pk)

Now, as we discussed before, in the case of Ethereum we're dealing with a lot of signatures that need to be verified. So ideally we would have a mechanism that lets us verify signatures in batch without adding any overhead such as additional communication between the parties or adding a trusted third party. Also keep in mind that for this usecase, every party aims to sign the same message m.

There is actually a simple extension to do signature aggregation on BLS signatures. Say we want to aggregate signatures of parties 1,…,n and their respective public keys pk₁,…,pkₙ. The KeyGen and the Sign procedures stay the same as above. We just add a way to combine signatures σ₁,…,σₙ over m using secret keys sk₁,…,skₙ and then verify that combined signature:

Signature aggregation(σ₁,…,σₙ). Output ∏ᵢ₌₁ⁿ σᵢ.

Aggregated-signature verification({pk₁,…,pkₙ}, m, σ). Compute apk = ∏ᵢ₌₁ⁿ pkᵢ. Then, check e(σ, g₂) ≟ e(H(m), apk). If this holds accept, otherwise reject.

Note that the aggregated public key can be calculated separately from the verification phase and served as an input directly. Again, with the bilinear properties we can see that this correctly verifies the aggregated signature:

e(σ, g₂) = e(∏ σᵢ, g₂)

= ∏ e(σᵢ, g₂)

= ∏ e(H(m)^(skᵢ), g₂)

= ∏ e(H(m), g₂^(skᵢ))

= e(H(m), ∏ g₂^(skᵢ))

= e(H(m), ∏ pkᵢ)

= e(H(m), apk)

This naive aggregation is vulnerable to the rogue public-key attack, where an attacker crafts a public key from an existing key, never knowing the underlying secret key. This allows the attacker to create fake aggregated signatures. The fix for this is a proof-of-possession when registering the public key as a validator, which shows the validator knows the secret key belonging to the public key.

So to recap: we have a signature scheme that lets all validators individually sign blocks and has a cheap aggregation mechanism which can batch all those signatures into a single signature. In practice there are a few final signatures, all of which batch a large number of individual signatures.
This very practical scheme leaves big shoes to fill for the post-quantum replacement in terms of size and computation overhead.

LeanSig: the custom Post-Quantum signature for Ethereum consensus

LeanSig is the hash-based signature scheme currently under consideration as the replacement for BLS. This scheme is being preferred because of:

• minimal assumptions (hashes)

• simplicity. No moon math and easy implementation

• one hash for everything

For Ethereum consensus, there is a very specific situation that we are optimizing for; validators sign the same message and they should sign only once per epoch. A "stateful" signature scheme is a perfect fit here; this is a scheme where tracking of state occurs to not reuse private keys. The NIST-standardized SPHINCS variants are also hash-based, but add overhead to prevent state tracking - overhead that we can avoid here.

In this section we'll introduce the high-level idea of LeanSig and review the design choices. Keep in mind that everything is ongoing research and changes large and small to this plan are to be expected. Also, while we focus on understanding functionality and why this covers Ethereum's use-case, a lot of work from the Lean Ethereum team is actually going into the security analysis, aiming for very conservative assumptions.

One-time signatures from hash chains

The base of LeanSig is XMSS, proposed in 2011 and itself based on the Merkle Signature Scheme which originates from 1979. It uses One-Time Signatures (OTS), which allow a user to only use a secret key once to sign a message, and combines them into a general "many-time signing" signature scheme using merkle trees.

For a single signature the idea is as follows; generate a secret value x and hash it repeatedly:

sk = x → H(x) → H²(x) → … → Hᵏ(x) = pk

Then let the public/private keypair be (Hᵏ(x), x), so the first element of the chain is the private key and the last element in the public key. Because of the properties of hash functions, it is easy to go forward in the chain, but it is hard to go back.

A signature over (a short) message m is obtained by converting the message into an index i in [1,…,k−1] and outputting σ = Hⁱ(x). For example if i = 2, we have the following hash chain, with the encircled element being the signature:

The verifier will check this signature by repeating the conversion of message m into index i, and then checking whether the completion of the hashchain equals the public key of the signer:

Hᵏ⁻ⁱ(σ) ≟ pk

Why is this a one-time signature? Once a single message has been signed, any message that maps to an index greater than the signed message can be signed as well, since we can just apply the additional amount of hashes.

At first sight this doesn't seem like a very practical scheme, since we need to use many different keys in order to sign many different messages. And then we haven't even taken into account that the above example assumes that the message can directly map onto a single index between 1 and k−1, while in practice it will map onto several indices, and we can't reuse the secret key for any of them. But it turns out that extending this core idea to many-time signing isn't all that difficult and it (surprisingly?) leaves us with a practical scheme.

From one-time to many-time: Merkle trees and multiple chains

To support a large amount of keypairs, we'll use a good old Merkle tree; each leaf contains a public key and we end up with a public key root. A signer commits to a tree and thus a collection of keypairs by publishing the root on-chain.

To extend to multiple signatures we simply take multiple chains. If we want to sign a message m, first hash it and then split it into v chunks of a chosen length (add padding at the end if needed). Then, use v hash-chains to sign each chunk by converting the chunk to an index in the chain and adding the element at that index to the signature.

Thus, for each epoch we use v public/private keypairs and end up with v hashes that are added to the signature. For example in the picture below the signature consists of indices 1,2,k−1,…,1 (more indices in between). The used public key can be hashed together to form a single public key pk that is present in the larger Merkle tree.

A signature contains the elements from the hash-chains and the Merkle proof showing it is part of all the public keys the validator committed to.

Combining these two concepts, we end up with hash chains to generate and verify signatures and merkle trees to support many keys. Do we see an overlapping force here? Indeed, it is the hash function.

Adding a target-sum

However, there is an issue in the current description of the signature scheme; an attacker could forge a valid signature using the different chains. Let's look at a small example using three chains. If validator V intends to sign message m which encodes to indices (1,2,4), then the valid signature would be (H(x₀), H²(x₁), H⁴(x₂)). In this case, an attacker can pretend validator V actually signed a different message, m′ if that message encodes to (2,2,5), since each index is equal to or larger than the original ones. The forged signature would be (H(H(x₀)), H²(x₁), H(H⁴(x₂))) and the attacker can create it without knowing the secret keys x₀, x₁, x₂.

This can be fixed by adding a checksum over the indices used; in above example (1,2,4) would give checksum 1+2+4=7 and any forged signature over a different (fake) message would be at least larger than 7 and not verify. Note however, that this value itself needs to be signed as well, requiring even more hash-chains to solve this issue. As a solution, LeanSig uses a "target sum" approach where there is a fixed target value T that the checksum should add up to, eliminating the need for additional chains to sign the checksum. Getting the checksum to equal T is done by hashing the message with a random value in the beginning, and resampling the randomness as often as needed.

The full picture

This is the high-level idea of leanSig; a validator commits to L keypairs upon registration via the Merkle root. Then, in each epoch it uses v public keys to sign the hashed block which has been encoded into v indices. A signature then consists of the v hashes and accompanying Merkle proofs for the used public keys. The verifier completes the hashchains and consequently verifies that the public keys are indeed part of the Merkle tree the validator committed to.

Additional note. How exactly to do this encoding from m to an array of indices (i₀,…,iᵥ₋₁) securely and with optimal performance for this case is under active research. What we know is that an "incomparable encoding" is needed, where for two messages m₁ and m₂ it is not possible that for the resulting indices each of the indices for m₂ is larger than those of m₁. Without this property, forging signatures would be possible.

Aggregation for LeanSig: introducing the leanVM

The signature scheme defined works for a single party, a single validator in the use-case we are considering for Ethereum, and just like the case for BLS we want to have an aggregation option. Unfortunately, hashes do not have algebraic structure we can make use of. However, there is always the option to aggregate signatures using a succinct argument of knowledge (SNARK). In this case, the public inputs are the public keys, the witness consists of the signatures to verify and the resulting proof convinces us all the signatures check out. Of course, since the goal of migrating to a post-quantum signature must then also be combined with a SNARK that is quantum resistant; a pqSNARK.

To solve this, the team has been working on a minimal zkVM called leanVM that itself is hash-based. The design of the zkVM is inspired by Cairo. The main design goals were to create a very simple zkVM, that could be completely formally verified and is aimed at the specific task of aggregating hash-based signatures and support recursion. Let's say this again: the aim is to completely formally verify this zkVM! The formal verification effort will use Lean, and the fact that these names overlap is apparently a total coincidence. Note that the aim is to formally verify both the zkVM itself and the programs that will be run on top, such as the XMSS signature aggregation.

And if you're making such an effort to build a secure and fast zkVM for hash-based signature aggregation, why not use it for more than just the XMSS signatures? That's why it will also be used for the execution layer, where the plan is to use SPHINCS signatures, which are also hash-based and require aggregation.

The zkVM (see docs) has a very small Instruction Set Architecture with only 4 opcodes for addition (ADD), multiplication (MUL), jumping instruction (JUMP) and a memory instruction (DEREF). In addition, there are currently 2 precompiles to do hashing and extension field operations. Once again, bear in mind that all of this research is in constant development and changes to this are to be expected.

For proving, Plonky3 is used and the Lean Ethereum team has collaborated with the Plonky3 team to make optimizations to gain performance improvements for CPU-related architectures and the low-level functionalities the zkVM uses. While many zkVM teams are optimizing for GPUs, since all this work is aimed at Ethereum validators and the hardware they use should be able to be very simple, CPU optimizations have been a main focus. In addition, every improvement on the low-level functions such as multiplication is a gain because these functions get used repeatedly in the circuit.

What are we optimizing for

Now that we've seen the various interconnected parts, let's take a step back and see what we're trying to optimize for.

Since signatures need to be shared over the network, we aim for smaller signature size. A smaller signature means fewer hash-chains and how this influences the amount of hashing that needs to be done depends on the chosen encoding approach.

A separate parameter is the lifetime parameter L for the number of leaves in the public key Merkle tree. If L = 2²⁶, this gives around 10 years of validator activity for Ethereum (ref). You don't want to regenerate keys too often, but a larger tree also means increased signature size, additional hashing and most importantly the effect on memory for storing such large trees.

In addition, because aggregation of signatures is done using the zkVM, we aim for minimal hashing in the verifier. Everything is done in-circuit for the verification and this is expensive. Additionally, the choice of hash function is important here; Poseidon is more performant within a circuit.

For the leanVM benchmarks it is important to keep in mind how many XMSS signatures can be aggregated per second, how fast recursion can be done and the proof size. While it is important to optimize the performance of a single hash function within the circuit, the team explains in ZK Podcast Episode 394 that the total performance is also determined by the "glue logic" such as forming the hash-chains and Merkle tree involvement and the encoding of the message to the indices.

One of the improvements proposed for leanSig was focused on the encoding method, aiming to generate indices that lower the verifier's workload. However, instantiating that encoding algorithm in a circuit turned out quite expensive and to abort a non-negligible amount of time; giving the team more research work to support this improvement.

A bit on the choice of hash function

There are more details with respect to the actual hashfunction(s) used in all of this. First of all, it is not exactly the same (instantiation of the) hash function used at different points. Within the hash-chain is slightly different than within the Merkle proof and the hashing for the zkVM can be different as well.

About the choice of hash function the jury is still out. We already discussed that Poseidon is preferred for in-circuit hashing, while SHA-3 might be preferred not because of performance, but because of security; it has been around for a good while.

Poseidon2 seemed to be the best candidate because of the performance, but in EthProofs call #8 it was announced that Lean Ethereum is shifting focus to Poseidon1, because it was shown that the attack surface of Poseidon2 is different than Poseidon1, and thus it cannot inherit the security analysis as was assumed previously. The reasoning for considering Poseidon2 had been that it had received $7$ years of scrutiny and this seemed reasonable, considering that SHA-256 was picked by Satoshi when it was $7$ years old and Keccak by Vitalik when it was $7$ years old as well (ref). With this new insight, the clock has been reset to $3$ years, to when the Poseidon2 paper actually came out.
(Meme was shown at EthProofs call #8)

As there is so much riding on the hash function choice, Ethereum has been giving out many grants and prizes to encourage cryptanalysis research efforts (Read this website for more info). After the shift of focus, this is now mainly considering Poseidon1.

Wrapping up

In future posts, we hope to dive deeper into the leanVM and the encoding mechanism research progress. All these efforts might also serve other blockchains or even other types of technologies where the use-case aligns with the case of Ethereum. To dive into many more details we recommend these resources from the leanVM/PQ workshops from October 2025, the short series on Lean Ethereum on the Zero Knowledge Podcast and Lean Consensus R&D website.

While we opened this blog post with the description as the quantum threat, the overall tone of this research effort is much more positive. We didn't dive into the full scope of the Lean Ethereum upgrade proposals (which are an ongoing effort) but the main idea is that they are making use of the fact that big changes are needed anyway, so let's make the most of it. Instead of degrading performance because post-quantum signatures are much larger, we can end up with a faster and stronger system.

References

[1] Boneh, D., Lynn, B., & Shacham, H. (2001). Short signatures from the Weil pairing. ASIACRYPT 2001. https://www.iacr.org/archive/asiacrypt2001/22480516.pdf

[2] Boneh, D., Drijvers, M., & Neven, G. (2018). Compact multi-signatures for smaller blockchains. ASIACRYPT 2018. https://eprint.iacr.org/2018/483.pdf

[3] Drake, J. Pragmatic signature aggregation with BLS. Ethereum Research. https://ethresear.ch/t/pragmatic-signature-aggregation-with-bls/2105

[4] Drake, J., Khovratovich, D., Kudinov, M., & Wagner, B. (2025). Hash-Based Multi-Signatures for Post-Quantum Ethereum. Cryptology ePrint Archive, Paper 2025/055. https://eprint.iacr.org/2025/055

[5] Goldberg, L., Papini, S., & Riabzev, M. (2021). Cairo - a Turing-complete STARK-friendly CPU architecture. Cryptology ePrint Archive, Paper 2021/1063. https://eprint.iacr.org/2021/1063

[6] Khovratovich, D., Kudinov, M., & Wagner, B. (2025). At the Top of the Hypercube - Better Size-Time Tradeoffs for Hash-Based Signatures. Cryptology ePrint Archive, Paper 2025/889. https://eprint.iacr.org/2025/889

[7] Drake, J., Khovratovich, D., Kudinov, M., & Wagner, B. (2025). Technical Note: LeanSig for Post-Quantum Ethereum. Cryptology ePrint Archive, Paper 2025/1332. https://eprint.iacr.org/2025/1332

[8] Buchmann, J., Dahmen, E., & Hülsing, A. (2011). XMSS - A Practical Forward Secure Signature Scheme based on Minimal Security Assumptions. Cryptology ePrint Archive, Paper 2011/484. https://eprint.iacr.org/2011/484

[9] Merkle, R. C. (1979). A Certified Digital Signature. https://scispace.com/pdf/a-certified-digital-signature-2quebo9evb.pdf