In the previous two blog posts, we covered what quantum computing means for cryptography and where Nimiq stands on the road to post-quantum security. This exploration and its next steps are guided by two principles: never weaken the security that protects the network today, and give the community plenty of lead time. This is the first concrete decision along that road.
Current State of Nimiq's ZKP Scheme
Before going deeper into Nimiq's ZKP Scheme, let's first look at how users use it today via light clients. Light clients are clients, such as wallets, browsers, or lightweight services, that sync specific information from the blockchain, such as balances, transaction history, or state updates, without downloading and validating the full chain. Light clients sync optimistically through pico. Only when pico cannot complete do they fall back to light sync, which lets them download a ZKP that proves the requested information against the blockchain's verified state. If the security of this proof system weakens, the client’s ability to reject false information is reduced, meaning its soundness is weakened. That soundness rests on pairing-based assumptions over the MNT4/6-753 elliptic curves, the same Shor-vulnerable cryptography the post-quantum transition retires.
As mentioned in the previous blog post, "the Zero-Knowledge Proof scheme used in the protocol (Groth16 zkSNARKs) might be the most clearly quantum-broken…" On top of this, we recently discovered a bug in the proving circuit, specifically in how it maps hashes to elliptic-curve points. The flaw could let someone construct a valid-looking proof for a statement that is false, in effect forging a proof that the network would accept, which is a soundness failure. This proof is used only for chain validity verification, the recursive proof that lets light and web clients sync to a recent point without replaying the whole chain. It plays no part in validating transactions or issuing NIM, both of which every full node checks independently, so a forged proof cannot mint NIM or alter the coin supply. At worst, it could mislead a light client about the chain's recent state.
If you've been following Nimiq for some time now, you might remember that the current ZKP scheme was implemented through a process called the ZKP Ceremony, which took several months. Fixing the issue that surfaced recently would require performing a similar process, organizing community members to participate, and investing months again on this topic. For this reason, it also makes sense to consider other approaches and weigh the benefits and drawbacks of each potential decision.
How we've decided to move on
After pondering how to approach a solution for this bug, we have weighed two options:
- Rerun the second phase of the ZKP ceremony, or
- Remove the ZKP scheme from the blockchain entirely
- For option 1, rerunning that second phase is no quick redo. The circuit first has to be fixed and re-audited, then a fresh multi-party ceremony has to generate new proving and verifying keys. The security of that ceremony rests on at least one honest participant destroying their secret contribution, so a credible run needs many independent, reputable participants, with transcripts verified and published and the new keys baked into every client and prover. All told, up to weeks of work that will become obsolete with the future PQ transition.
- For option 2, we considered removing the ZKP scheme from the blockchain entirely. What that scheme gave us was a recursive proof that let any node verify the validity of the election blocks on its own, rather than replaying the entire chain. Removing it is therefore not a simple deletion: the chain's recent state is still trusted through normal block-by-block validation, so what we give up is a timing advantage, the fast catch-up, and removal becomes a commitment to restoring that fast path by another route.
We have decided to remove Groth16, our current Zero-Knowledge Proof scheme, from chain-validity verification for light and full sync.
With this change, we are introducing a pinned election block sync only for pico fallback clients, allowing them to sync with the most recent election block by requesting this pinned block and verifying that the chain is valid up to that point, so the client can continue syncing.
The pinned election block keeps syncing just as secure: a light or web client still reaches a recent point and checks the chain is valid up to the tip, just by a different route. The check is now anchored to a pinned election block shipped in the client rather than to a cryptographic proof, and any full or history node confirms that block for itself by validating the chain from genesis. So the anchor is a value the whole network can verify and vouch for. It is a change of method, not a loss of capability, and because it no longer rests on elliptic-curve cryptography, it does not carry the ZKP's built-in expiry.
Sync without Zero-knowledge Proofs
With the ZKPs gone, how a node catches up to the chain depends on what kind of node it is. Full nodes validate the whole history themselves; light and web clients rely on pico, with a fallback for the rare cases pico cannot complete. History nodes will remain unchanged in this regard.
Full nodes take the thorough route. There is no pinned election block for them and no proof to skip ahead with, so a full node syncs every election block from genesis and validates the chain on its own. It is more work and a longer initial sync, on the order of minutes following our benchmarks, but the node ends up fully self-sufficient, trusting nothing but its own validation.
Light and web clients take the fast route, and for most of them, nothing really changes, because pico consensus itself is not changing. Pico is an optimistic method: the client asks peers for proof of the chain's state, one peer at a time, and once enough peers return the same proof, it syncs to that state. What changes is only pico's fallback, the path it takes when that agreement does not come together. That fallback used to be the ZKP; now it is a pinned election block.
When a light or web client falls back to the pinned election block, the flow is:
- The client already knows which pinned election block to ask for, because it is written into its own code. It does not learn it from the network.
- It asks a full or history node for that specific pinned election block.
- Those nodes can serve it because they verified the same pinned election block themselves during sync, so their copies are known good.
- The client receives the pinned election block and checks it against the reference it shipped with, rather than taking the peer's word for what the pinned election block is.
- From there, it requests everything up to the current tip: all election blocks between the pinned election block and the tip, plus the election block for the last epoch.
- The peers send that data, and the client completes the sync.
Because the pinned election block lives on the client side, a peer cannot lie about it: the client already holds the right reference and matches the incoming data against it. So trust does not sit with the peers you connect to, it sits with the pinned election block shipped in the client, which is the same trust you already place in running Nimiq's software.
And the two routes reinforce each other: because full and history nodes validate the chain from genesis and verify that the built-in pinned election block is valid, they can serve and vouch for the pinned election block that a light or web client falls back to.
What this means for you
This eliminates the bug by removing ZKPs and moves Nimiq a step closer to post-quantum security. For you, it is simple: the change goes live with the new release, and every client, history and non-history alike, needs to update to it with a new minor release.
Regarding prover nodes, they are no longer needed since proof generation will no longer occur. If you run a prover node, you can retire it.
What's next?
Everything above happened without a hard fork: removing the ZKPs was a software change. Separately, we have been preparing a series of hard forks, and this is a good time to give a heads-up.
The first will bundle a few security fixes with something we plan to add: a smoother way to implement future hard forks. Hard forks are a normal part of how a chain like Nimiq evolves, so making each one easier to coordinate is worth doing early.
When it lands, it will ask for action across the network. Validators, in particular, will need to take steps, as will other node operators and exchanges. We will walk through exactly what that involves in a dedicated post closer to the time. For now, nothing here requires anything from you, and we will keep you posted.
Pura Vida
Team Nimiq