Quantumnet — an experimental post-quantum testnet

Earlier this month, Arthur Breitman laid out why post-quantum, and why now. Now, there is something concrete to experiment with alongside that argument: Quantumnet, a running experimental Tezos network whose consensus, manager keys and Data Availability Layer are all post-quantum.

Stood up last week, Quantumnet is live in its first iteration and now open to community testing. It is not a preview of a finished post-quantum Tezos, nor a pre-production network. It is a place to experiment rigorously and in the open with what making Tezos post-quantum actually entails - across cryptography, algorithms, architecture, operations and, eventually, the transition itself.

Network dashboard: https://quantumnet.pqpark.dal.nomadic-labs.com/
Block explorer: https://quantumnet-tzkt.pqpark.dal.nomadic-labs.com/
Join it as a baker: https://quantumnet-tutorial.pqpark.dal.nomadic-labs.com

What is actually post-quantum here

Making Tezos post-quantum involves more than replacing user keys. Cryptography is used at several layers of the protocol, and replacing it has consequences for the algorithms and architecture built around it.

Quantumnet brings several of those changes together in a running network:

  • Manager keys are tz5 - ML-DSA-44, the lattice-based signature scheme standardized by NIST as FIPS 204. These keys sign operations such as transfers, delegation and staking.

  • Consensus keys are tz6 - XMSS, a stateful hash-based signature scheme. Bakers therefore run a tz5 manager key alongside a tz6 consensus key used for per-block consensus operations.

  • Consensus operation aggregation uses a post-quantum STARK-based approach, allowing the network to retain aggregation while moving away from the BLS signatures used on Mainnet today.

  • The DAL runs ZODA, a data-availability scheme based on hashes and erasure coding rather than the pairing-based KZG commitments used by the current DAL.

  • Baking rights no longer depend on protocol randomness. The VDF and lottery-based allocation have been replaced by Smooth Weighted Round Robin.

The tz6/tz5 split illustrates why this work is not simply a matter of swapping one cryptographic primitive for another.

Tezos aggregates consensus operations, and losing aggregation when moving to post-quantum cryptography would come with significant costs. ML-DSA does not provide the aggregation properties needed here, so Quantumnet uses XMSS signatures together with a post-quantum aggregation mechanism for consensus.

That introduces a new operational constraint: an XMSS key can only produce a finite number of signatures. It is a mutable state that a baker has to monitor and eventually rotate.

For this first iteration, the tutorial sizes the key for 131,071 signatures - roughly three days of baking - and provides the rotation commands. Rotation is still manual, and Octez does not currently warn the baker as the signature budget is depleted.

That is exactly the kind of constraint Quantumnet exists to expose and explore.

What works today

This first iteration is already a complete enough network to exercise the different components together.

Today you can:

  • run your own node and become a baker;

  • delegate and stake;

  • send transactions using post-quantum manager keys;

  • produce and attest DAL slots using the post-quantum DAL;

  • explore the chain through a block explorer;

  • use a faucet and public RPC endpoint;

  • inspect L1 and DAL metrics through the public network dashboard.

Blocks are 6 seconds and a cycle is 10 minutes, so you can start exercising the network quickly. Budget roughly 45 minutes to go through the complete baker tutorial, including the protocol-mandated wait for baking rights.

What is not there yet

Being explicit about this is part of the purpose of a first iteration.

  • No rollup is deployed yet. The plumbing for a smart rollup consuming data from the ZODA DAL exists and has been exercised, but no rollup is currently running on the public network.

  • DAL bandwidth is deliberately modest. Slot geometry and publication cadence are conservative while we measure the system. Later iterations will push this further.

  • The network topology is still highly controlled. This iteration is primarily about integrating and exercising the post-quantum components together, not reproducing a realistic Mainnet P2P topology.

  • Key-rotation UX is still an engineering workflow rather than a finished product. XMSS state management and rotation are among the operational questions this environment lets us investigate.

  • Hardware requirements are still being measured. This first iteration prioritizes experimentation over matching the requirements of the lightest Mainnet setups.

Most importantly, Quantumnet is not a preview of a post-quantum Tezos design that is already finished.

This is iteration 1. There will be further iterations, each giving us an opportunity to change assumptions, replace components, improve performance and explore the operational consequences of the design.

New iterations may start from a fresh chain, so participants should not expect balances, delegate registrations or history to persist between them.

Use throwaway keys. Nothing on this network has value.

What comes next

The purpose of Quantumnet is to give us time to learn before decisions need to become commitments.

Among the areas we expect future iterations to explore are:

  • higher DAL bandwidth;

  • more realistic network topology;

  • improved XMSS key management and operational UX;

  • stateful addresses and the user transition path;

  • a rollup supporting post-quantum encrypted private transactions;

  • continued performance, security and hardware-requirement evaluation.

We also intend to publish a series of engineering insights explaining what we learn along the way: the protocol changes, consensus aggregation, the XMSS state problem, ZODA in practice, performance trade-offs, and the broader transition challenges.

Back in 2014, the position paper recognised that Tezos would require new cryptographic primitives as the need developed. Every amendment so far has changed what Tezos does or how well it does it. Twenty-one upgrades later, this one reaches into the cryptographic foundations themselves.

The precise shape of a future post-quantum Tezos is not something Quantumnet assumes in advance. The point of running these experiments now is to have the time to discover it.

Come and experiment with it

Follow https://quantumnet-tutorial.pqpark.dal.nomadic-labs.com, join Quantumnet with your own node, bake a few cycles and tell us what you find.

Failure reports, performance measurements, operational pain points, and “this step of the tutorial makes no sense” are all useful results.

Quantumnet is an engineering playground in the open. This is the first iteration, not the destination. The faster we learn from it, the better informed the next iteration can be.

6 Likes

Are the bootstrap nodes online? I don’t get any peers.

root@quantumnet:~/pqnet-tezos# curl -s https://$NET.$BASE/network.json | jq '.default_bootstrap_peers, .dal_config.bootstrap_peers'
null
null
root@quantumnet:~/pqnet-tezos# curl -s https://$NET.$BASE/network.json | jq .
{
  "chain_name": "PQNET-pq-shownet-09-16",
  "genesis": {
    "block": "BLockGenesisGenesisGenesisGenesisGenesisijEt7hhj1BZ",
    "protocol": "ProtoGenesisGenesisGenesisGenesisGenesisGenesk612im",
    "timestamp": "2018-06-30T16:07:32Z"
  },
  "genesis_parameters": {
    "values": {
      "genesis_pubkey": "edpkuSLWfVU1Vq7Jg9FucPyKmma6otcMHac9zG4oU1KMHSTBpJuGQ2"
    }
  },
  "sandboxed_chain_name": "SANDBOXED_TEZOS"
}
root@quantumnet:~/pqnet-tezos# echo https://$NET.$BASE/network.json
https://quantumnet.pqpark.dal.nomadic-labs.com/network.json

2 Likes

Sorry, a last minute change broke network.json. This should be fixed now.
Thank you for trying out the tutorial!

3 Likes

yep, looking better now, thanks!

Explorer seems to be stuck on level 179828?

Sep 29 21:30:59.587 NOTICE │ injected preattestation for level 189776, round 0 for delegate tz5Mnup67A2PRsMRXAZ3JhVHPyGKFdXeFd4n with consensus key ‘consensus-2’ (tz6Qa9FrKnu2tKZeTS5MVLmxo7KCka61HEF5) (operation hash: onmLxzjt9DumvDBvwso1o97E6WPeFYrXGs6xcxSv7JJfNRwj1vV)

Thank you for reporting.
The self-hosted TzKT indexer was stalling on tz5/tz6 (post-quantum) addresses in smart-contract data (the chain itself was fine).
It’s now fixed: the explorer is un-stuck and has caught up.

1 Like

Appreciate the creation of this trial network. My baker is up and running. Regarding the slot limitations with the XMSS keys, is it expected that further research will eliminate this constraint and bakers and baking tools will not have to manage a rotation scheme?

I had an early problem with the baker on quantumnet. It would not attest or bake, even though running rpc get /chains/main/blocks/head/context/delegates/tz5fbi14ZunjW4V6WVYiGN1md82BNgjKW95f showed the manager key was associated with the active consensus key. Eventually, the rpc call showed that the manager account was deactivated. I managed to get it re-registered with a new consensus key, and it’s been working great…until now.

I decided to rotate the consensus key, running the steps at tz6 Key Rotation . Restarted the baker pointing to both active and pending consensus keys, but now it has stopped attesting. Running the python script xmss_status shows that the firsts consensus key counter is no longer decrementing. I restarted the baker without the new consensus key name in the argument, and it took about 3 minutes before it started attesting again and the first consensus key started decrementing. Restarted the baker yet again with the new consensus added back to the command line. First consensus key stopped decrementing again. About 3 minutes elapsed without decrements before the second consensus activated with the new cycle. The new consensus key started decrementing in less than a minute after the start of the cycle. Was I not allowing enough time for the first consensus key to load after baker restart? User error?

Glad it’s running!

The slot limit itself is inherent to XMSS: like every stateful hash-based signature scheme, a key can only produce a fixed number of signatures. It would only go away if consensus keys moved to a stateless post-quantum scheme that also supports aggregation. There is active research in this area but, to our knowledge, this remains an open research question.

What we plan to do in a next instance of this testnet, is take rotation off the baker’s hands, as is already done with our own in-cluster bakers, without anyone needing to step in.

1 Like

You most likely didn’t wait long enough after the restart, and the docs set the wrong expectation for how long that wait is.

The baker signs nothing until every tz6 key on its command line is loaded. At startup it rebuilds the Merkle tree of each XMSS key, and it only starts baking once all of them are built. So when you add the new consensus key, the old key can’t sign either until the new key’s tree is also ready. The trees are built in parallel and compete for the same cores, so two keys take roughly twice as long as one.

The runbook says loading takes ~9s per key, but that was measured on a 16-core i7. On your machine, one key apparently takes about 3 minutes (that’s how long the old-key-only restart took), so two keys would take ~6 minutes. That fits what you saw. On your first try you probably restarted again before loading finished. On your second try loading finished just after the cycle boundary. By then the new key was active, so it signed right away and the old key never got another signature. None of this used up any key slots: a slot is only spent when the baker actually signs.

It would help to know your CPU and RAM to confirm this. Memory may matter too: holding both keys during a rotation takes ~700 MB, which can be tight on a small VPS.

For next time:

  • Restart with both keys once, early in the ~30-minute window. Then wait about twice your single-key startup time (~6 min for you) before deciding something is wrong. During that time, top should show the baker using a lot of CPU.
  • If startup is still too slow, a smaller key (--xmss-slot-end 65535) cuts loading time roughly in half. The trade-off is rotating every ~1.5 days instead of ~3.

We’ll update the rotation runbook and the tutorials to say this explicitly. Also, key generation will be faster in a next instance of the testnet.

Orange PI 5, 8 core 2.25 GHz, 15GB RAM. Will give another rotation a try and restart with both keys

1 Like

This time, took about 3 minutes, 45 seconds after restart

1 Like

I’m about to shutdown operations. Any concerns with missing 5 - 12 attestations per cycle on Quantumnet? As mentioned earlier, for this experiment I’m using an Orange PI 5, wireless connection (ISP service up to 500MB). For comparison, I have an old Dell Inspiron laptop attesting nearly flawlessly on Bakingnet on a wireless connection at another location (ISP symmetrical service up to 300MB)

No concerns. Missing 5–12 attestations per cycle still puts you around 88–95% participation, so that does not affect your rewards.

The gap with your Bakingnet laptop most likely comes from the keys rather than your connection: tz6 (XMSS) signing is much slower than ed25519/BLS, even on fast hardware, and an Orange Pi adds to that.

Thank you for your participation!

1 Like

With these new keys, will it be recommended that bakers upgrade their hardware? Will hardware signers like Raspberry Pi Zero 2W be sufficient?

Exact hardware requirements are still being evaluated. Our current expectation, as mentioned in the Quantumnet announcement, is that post-quantum baking will need somewhat more than the lightest Tezos setups, while staying within the range of readily available consumer hardware. So bakers running on minimal hardware may need to upgrade, but nothing specialized should be required.

A Raspberry Pi Zero 2W sits at the very light end, and we expect it is likely to be on the tight side for the new consensus keys. They need more memory and CPU than today’s keys, both to load and to sign quickly enough. The new manager keys are much less demanding.

2 Likes

you’re still linking to private Trilitech repositories so color me skeptical. the only context someone might have for the decisions being made here is by reading about Quantumglow or leanXMSS. can we please not just wait till the end and publish something just to pad out everyones google scholars? get some information that would help builders into the world

1 Like