I have been sitting with the protocol upgrade problem in Midnight for the last few days and the more I think about it the more I realize it is one of the most uniquely difficult challenges a privacy network faces and almost nobody is treating it with the seriousness it deserves 😂
let me explain why this one is different from the regular blockchain upgrade problem because the difference matters enormously.
on a regular blockchain protocol upgrades are complicated but the complication is mostly social and political. you have to get the community to agree on the change. you have to coordinate miners or validators to adopt the new software. you have to manage the risk of a chain split if a meaningful portion of the network disagrees. those are real challenges and they have played out publicly and sometimes painfully across the history of Bitcoin and Ethereum and dozens of other networks.
but the underlying data model on a transparent chain survives an upgrade intact. the transaction history is still there. the account balances are still there. the smart contract state is still readable. the upgrade changes the rules going forward but it doesn't touch what already exists in a way that creates fundamental discontinuity for users.
Midnight has a different problem underneath the regular upgrade coordination challenge. and it comes directly from the private state model.
here is what I mean.
when a Midnight application generates a zero knowledge proof that proof is tied to a specific version of the proving system. the mathematical relationship between the private inputs, the computation, and the proof output is defined by the circuit — the specific mathematical structure that encodes what the proof is proving and how.
circuits are not forward compatible by default. a proof generated by circuit version one cannot be verified by circuit version two unless the new circuit was specifically designed to accept the old proof format. and circuit redesigns — the kind that happen when the underlying cryptographic assumptions are updated or the proof system is improved or new capabilities are added — typically produce incompatible proof formats precisely because the improvement required changing the mathematical structure.
so what happens to a user's private state when the proving system gets upgraded.
on the public chain side the answer is relatively clean. the ledger records what needs to be recorded and the upgrade path can be designed to maintain continuity of the public state. hard work but tractable.
on the private side the answer is genuinely uncomfortable.
if your private state was generated under circuit version one and the network upgrades to circuit version two your old proofs may not be verifiable under the new system. your private credentials, your shielded balances, your confidential application state — all of that was structured around the old circuit. migrating it to the new circuit requires re-proving it. generating new proofs of the same private facts under the new proving system.
and re-proving requires you to have the original private inputs available on your device at the moment of migration. the raw private data that went into generating the original proofs. not just the proofs themselves. the underlying private state.
for a user who has been holding shielded assets or private credentials for an extended period and whose device situation has changed — new phone, hardware upgrade, anything that involved moving between devices — having the original private inputs available at a specific moment for a migration event is not guaranteed.
the user who managed their private state carefully, maintained good backups, kept their cryptographic material organized across device transitions — that user can participate in a proving system migration. they have what they need.
the user who held private state for two years on a phone they no longer have, whose backup situation was imperfect, whose migration between devices didn't go completely smoothly — that user may find that a protocol upgrade has made their old private state unrecoverable not because of a hack or a theft but because the proving system moved on without them.
and here is the deeper problem.
the users most likely to be in that second category are not negligent users or unsophisticated users in some abstract sense. they are ordinary people living ordinary lives where devices break and situations change and the idea of maintaining cryptographic migration readiness across a multi-year holding period is simply not something that maps to how they actually live.
I keep thinking about what a reasonable upgrade strategy looks like for a network with this constraint.
one answer is long overlap periods. rather than a hard cutover from one proving system to another you run both systems in parallel for an extended period — long enough that essentially every active user has had multiple opportunities to migrate their private state. users who are active on the network regularly will encounter the migration prompt and complete it while their private inputs are available. the overlap period catches everyone who is paying attention.
but overlap periods have costs. running two proving systems simultaneously is computationally expensive. verification logic that accepts two different proof formats is more complex and more potentially buggy. the security assumptions of the old proving system have to be maintained even after you've moved to the new one because old proofs are still being accepted.
if the reason for the upgrade was a weakness discovered in the old proving system — a cryptographic assumption that turned out to be less secure than expected — then the overlap period is a period where you know your security is weaker than you want it to be and you cannot close that gap until the migration is complete.
another answer is user-side migration tooling that is extremely robust and extremely accessible. wallets and applications that make the migration process as close to automatic as possible. detect that a user has old-format private state, guide them through re-proving it under the new system, handle the complexity invisibly in the background, require nothing from the user beyond being online and authenticated.
that is the right product direction and I genuinely hope it is the direction being invested in.
but automatic migration tooling has limits. it can handle the migration for users whose private inputs are accessible on their current device. it cannot recover private inputs that are no longer available. and for the users whose inputs aren't there — because the device is gone, because the backup failed, because the migration window passed during a period when they weren't actively using the application — the tooling cannot help them.
the third answer is designing the proving system from the beginning with upgrade compatibility in mind. recursive proof structures and proof system designs that allow new proving systems to wrap and verify old proofs rather than requiring re-proving from scratch. this is an active area of research in the ZK cryptography community and some of the most interesting recent work in the space is pointed exactly at this problem.
if Midnight's proving system architecture supports this kind of forward-compatible upgrade path it changes the analysis significantly. users wouldn't need to have their original private inputs available during migration because the migration wouldn't require re-proving — it would require wrapping. old proofs would be verifiable under the new system without the user having to do anything.
that is the most user-friendly answer. it is also the most technically demanding and the most constrained by the specific choices made in the original circuit design.
I genuinely don't know enough about the specific proof system architecture Midnight has chosen to know which of these paths is available. the technical documentation I've been able to get to doesn't go deep enough into the circuit design to answer that question clearly.
but it matters. enormously.
because the upgrade problem is not a future hypothetical. it is a certainty. cryptographic systems get upgraded. zero knowledge proof systems in particular are evolving rapidly — the field has moved dramatically even in the last three years and there is no reason to expect that pace to slow. a network that launches today on a specific proof system will face pressure to upgrade that system within the next several years either because better options exist or because vulnerabilities emerge or both.
how Midnight handles that first major proving system upgrade will tell you more about the long term viability of the network as a custody-grade privacy system than almost anything else you could observe.
a network that manages the upgrade smoothly — that brings its users through the transition without private state loss, without compromising the security guarantees during the migration window, without creating a two-tier ecosystem of users who migrated successfully and users who got left behind — that is a network that has demonstrated it can be trusted with the long term custody of private information.
a network that handles the upgrade badly — that loses user private state, that extends the insecure overlap period longer than intended, that creates confusion and loss for ordinary users who didn't understand what the migration required of them — that is a network that has answered the most important question about itself in the most expensive way possible.
the cryptographic foundation is strong today. the question is whether it is designed to be upgradeable in a way that carries users forward rather than leaving them behind.
that question doesn't have a visible answer yet. but it is the one I would most want answered before trusting a privacy network with anything I genuinely needed to keep private for years. 🤔