Le calcul généraliste fondé sur des preuves avec Magnetar remet en cause le compromis des zkVM

Microsoft Research a présenté le calcul généraliste fondé sur des preuves avec Magnetar le 15 octobre, revendiquant des gains de vitesse pouvant atteindre 39 fois ceux de machines virtuelles à divulgation nulle de connaissance comparables. Le système peut prouver des programmes écrits dans des langages familiers tout en gardant les entrées privées cachées. Il évite également plusieurs hypothèses cryptographiques que les conceptions concurrentes acceptent pour gagner en performances.

Cette combinaison compte, car les systèmes de preuve ont habituellement obligé les développeurs à choisir entre vitesse, généralité et sécurité prudente. Magnetar tente d'éliminer ce choix. Microsoft affirme pouvoir prouver des programmes RISC-V ordinaires à plusieurs millions de cycles processeur par seconde, avec une sécurité fondée sur des fonctions de hachage standard.

L'adversaire immédiat n'est pas une seule entreprise. Il s'agit du compromis d'ingénierie établi derrière des systèmes tels que Jolt, SP1 et d'autres zkVM généralistes. Certains proposent des preuves plus courtes, des outils pour développeurs matures ou des profils de performance différents. Magnetar affirme que les développeurs n'ont plus besoin de ces compromis pour rendre le calcul vérifiable pratique.

Le calcul généraliste fondé sur des preuves avec Magnetar change l'argument de performance

Magnetar est important parce qu'il combine du code ordinaire, un débit de génération de preuves élevé et une sécurité post-quantique dans un même système de recherche.

Une machine virtuelle à divulgation nulle de connaissance, ou zkVM, prouve qu'un programme s'est exécuté correctement sans obliger le vérificateur à le relancer. Lorsque la divulgation nulle de connaissance est activée, la preuve peut également dissimuler les entrées privées. Le destinataire obtient ainsi des éléments attestant d'un résultat sans révéler les données confidentielles sous-jacentes.

La recherche Magnetar de Microsoft présente le système comme une avancée sur trois problèmes liés. La génération de preuves doit être suffisamment rapide pour des charges de travail réalistes. Les développeurs doivent pouvoir utiliser des programmes normaux plutôt que des circuits cryptographiques construits à la main. La sécurité sous-jacente doit rester crédible durant toute la durée de vie prévue du système.

Magnetar cible les programmes compilés vers RV64I, le jeu d'instructions entier RISC-V 64 bits de base. RISC-V fournit au système un modèle de processeur conventionnel et l'accès à une infrastructure de compilation mature. Les développeurs peuvent écrire des logiciels en Rust, Go ou C, les compiler, puis prouver l'exécution obtenue.

Cela diffère des systèmes de preuve qui exigent qu'une application soit réécrite sous forme de circuit arithmétique. Un circuit décrit le calcul à travers des contraintes algébriques qu'un système de preuve peut traiter. Sa construction demande souvent des connaissances spécialisées, tandis que les modifications de la logique applicative peuvent nécessiter un travail correspondant sur le circuit.

Un zkVM déplace une grande partie de cette charge vers le processeur virtuel. Le système de preuve valide le comportement instruction par instruction du processeur, afin que les programmes puissent utiliser une chaîne de compilation standard. Les développeurs doivent toujours assurer le travail d'intégration, mais ils n'ont pas besoin d'exprimer chaque application comme un circuit personnalisé.

Microsoft indique que Magnetar prouve entre 7,2 millions et 8,7 millions de cycles par seconde sur un MacBook Pro M4 Max. L'expérience citée utilisait 12 cœurs de performance et des exécutions contenant 2²² cycles. Les preuves faisaient environ 600 KiB et leur vérification prenait entre 11 et 13 millisecondes.

Une configuration optimisée atteindrait entre 9,5 millions et 12,8 millions de cycles par seconde. Microsoft affirme que cette amélioration augmente ses accélérations comparatives mesurées d'environ 1,3 fois. Il s'agit de benchmarks de recherche, et non de mesures d'un service en production.

L'article technique qui accompagne l'annonce compare Magnetar à SP1 Hypercube, Jolt-Dory et Jolt-Akita sur 15 charges de travail. L'ensemble de tests inclut le hachage cryptographique, des opérations sur arbres de Merkle, des signatures et des transferts de jetons au sein d'un petit interpréteur Ethereum Virtual Machine.

Selon ces résultats, Magnetar a obtenu un avantage de débit en moyenne géométrique d'environ 39 fois sur SP1 Hypercube. Les moyennes rapportées étaient d'environ 18 fois sur Jolt-Dory et 9,6 fois sur Jolt-Akita. Les comparaisons individuelles variaient fortement selon la charge de travail.

Ces chiffres expliquent pourquoi l'annonce est plus importante qu'un autre benchmark incrémental de divulgation nulle de connaissance. Magnetar ne revendique pas simplement une exécution plus rapide dans un circuit personnalisé étroit. Il affirme qu'un système généraliste fondé sur le hachage peut surpasser des alternatives reposant sur des composants cryptographiques moins prudents.

Cet argument de performance a toutefois des limites. Les benchmarks ont été menés par le créateur de Magnetar sur une configuration d'ordinateur portable. Les environnements de production introduisent des limites mémoire, des modèles de concurrence, des coûts réseau et des tailles d'application différents. Des reproductions indépendantes détermineront si cette avance résiste à ces conditions.

Les résultats rapportés déplacent néanmoins la charge de la preuve. Les systèmes fondés sur le hachage ont souvent été considérés comme prudents mais coûteux. Magnetar affirme que des fondations prudentes et une vitesse de génération de preuves compétitive peuvent coexister.

Les langages standard rapprochent les preuves des logiciels ordinaires

Le changement pratique ne réside pas seulement dans une cryptographie plus rapide, mais dans un chemin allant du code applicatif maintenu à une exécution vérifiable.

La manière la plus simple de comprendre le zkVM Magnetar est de suivre un programme à travers celui-ci. Un développeur écrit une application dans un langage pris en charge et compile cette application pour RISC-V. Magnetar crée ensuite une preuve que l'exécution du processeur résultante a suivi le programme spécifié.

Le vérificateur ne répète pas chaque instruction. Il vérifie une preuve compacte qui représente la correction de l'exécution. Microsoft indique que cette vérification prend environ 12 millisecondes dans sa configuration de benchmark, quelle que soit la charge de travail bien plus grande représentée par la preuve.

Cela change les personnes susceptibles de créer des applications soutenues par des preuves. Les circuits personnalisés concentrent les connaissances dans des équipes qui comprennent à la fois l'application et le système de preuve. Un zkVM généraliste permet aux ingénieurs logiciels conventionnels de conserver davantage de leurs pratiques existantes en matière de langages, de compilateurs, de tests et de revue de code.

La distinction est particulièrement importante pour les logiciels qui changent fréquemment. Les politiques métier, les pipelines de données, les interpréteurs et les règles d'agents évoluent au fil du temps. Reconstruire des circuits personnalisés à chaque changement peut faire de l'assurance cryptographique un goulot d'étranglement du développement.

Magnetar ne fait pas disparaître l'ingénierie des preuves. Les équipes doivent choisir quelles affirmations prouver, définir les entrées publiques et privées, et exploiter l'infrastructure de génération de preuves. Elles doivent également vérifier que le comportement compilé correspond à la politique de haut niveau prévue.

Le système déplace plutôt la frontière de la spécialisation. Les cryptographes peuvent travailler sur le zkVM et son moteur de preuve, tandis que les développeurs d'applications ciblent une architecture de processeur familière. Cette répartition ressemble à la relation entre ingénieurs compilateurs et programmeurs d'applications.

Microsoft met en avant un interpréteur Ethereum Virtual Machine comme exemple. Une implémentation EVM écrite en Rust ou en Go peut s'exécuter dans Magnetar. La construction obtenue peut prouver l'exécution de contrats intelligents existants sans implémenter chaque contrat directement comme un nouveau circuit de preuve.

Cette approche est pertinente au-delà des blockchains. Une institution financière pourrait prouver qu'un programme de traitement des transactions a appliqué des règles spécifiées sans révéler chaque transaction. Un service de données pourrait prouver qu'il a appliqué une transformation convenue à des enregistrements privés.

Les agents d'IA représentent un autre cas d'usage possible. Un agent pourrait fournir des éléments attestant qu'une action est passée par un programme de politique défini. La preuve établirait l'exécution de cette politique, sans toutefois démontrer automatiquement que la politique était complète ou pertinente.

Cette réserve est essentielle. Une preuve confirme une affirmation encodée avec précision. Elle n'établit pas que les données sources étaient exactes, que la politique couvrait tous les risques ou que le système environnant n'était pas compromis.

Le calcul fondé sur des preuves complète donc les audits, les contrôles d'accès et la sécurité opérationnelle. Il ne les remplace pas. Sa contribution spécifique consiste à réduire la confiance requise pour un calcul dont les entrées et le programme ont été correctement définis.

L'expression "Magnetar zkVM explained" peut évoquer un tutoriel produit, mais l'information importante est architecturale. Microsoft soutient que l'exécution vérifiable devrait devenir une propriété des logiciels ordinaires soutenue par les compilateurs, plutôt qu'une catégorie d'application distincte.

Cette ambition met sous pression chaque projet de zkVM généraliste. L'expérience développeur ne suffit plus si la génération de preuves reste coûteuse. La vitesse brute est également insuffisante si elle dépend d'hypothèses que les acheteurs s'attendent à devoir remplacer plus tard.

Magnetar vs Jolt expose le véritable compromis cryptographique

Le concours central ne se résume pas à Magnetar vs Jolt en matière de vitesse, mais oppose les hachages standard aux preuves plus courtes et aux hypothèses alternatives.

Jolt est une comparaison utile car les projets partagent des racines intellectuelles et architecturales. Tous deux utilisent RISC-V pour prendre en charge des programmes généralistes, et tous deux s'appuient sur des recherches qui rendent les instructions processeur et les opérations mémoire moins coûteuses à prouver.

Jolt utilise des arguments de consultation, qui permettent à un système de preuve d'établir que des valeurs appartiennent à des tables prédéfinies. Cela peut représenter les instructions processeur plus efficacement que l'expression de chaque instruction par une vaste collection de contraintes de bas niveau.

Le dépôt Jolt open source décrit le projet comme un zkVM RISC-V extensible. Il qualifie également le logiciel actuel d'alpha et d'inadapté à une utilisation en production. Cet avertissement illustre l'écart plus large entre une recherche prometteuse sur les preuves et une infrastructure fiable.

Microsoft a évalué deux configurations de Jolt. Jolt-Dory utilise des hypothèses sur les courbes elliptiques, tandis que Jolt-Akita utilise une cryptographie fondée sur les réseaux. L'article de Magnetar indique que les deux produisent des preuves inférieures à 100 KiB, contre des preuves d'environ 600 KiB pour Magnetar.

Des preuves plus petites peuvent réduire les coûts de stockage et de transmission. Cet avantage est important lorsque les preuves traversent des réseaux contraints ou s'accumulent en grand nombre. La taille des preuves peut également affecter la manière dont un système compose la vérification entre différentes couches.

Magnetar accepte une preuve plus volumineuse en échange d'une fondation de sécurité plus étroite. Microsoft affirme que sa sécurité repose sur des fonctions de hachage standard telles que SHA-256 ou SHA-3. Il ne dépend ni des courbes elliptiques, ni d'hypothèses sur les réseaux, ni de hachages algébriques spécialisés, ni d'une configuration de confiance.

Une configuration de confiance est un processus ponctuel qui crée des paramètres secrets pour certains systèmes de preuve. Si le matériel secret est conservé ou compromis, un attaquant pourrait forger des preuves. Les systèmes transparents évitent cette cérémonie et la charge de gouvernance associée.

Les systèmes à courbes elliptiques peuvent fournir des preuves compactes et une vérification efficace, mais des ordinateurs quantiques suffisamment puissants menaceraient leur sécurité. Les systèmes fondés sur les réseaux sont conçus pour résister aux attaques quantiques connues, bien qu'ils reposent sur des hypothèses mathématiques différentes.

La position de Magnetar est plus prudente. Les fonctions de hachage standard ont bénéficié de décennies d'analyse et de déploiement. Elles sont également présentes dans les logiciels et matériels existants, ce qui offre aux implémenteurs des voies d'optimisation éprouvées.

Cela ne rend pas les fonctions de hachage infaillibles. Magnetar dépend toujours de leurs propriétés de sécurité et de la justesse de son implémentation. « Post-quantique » signifie une résistance aux attaques quantiques actuellement connues, et non une garantie permanente contre toute découverte future.

Les conceptions fondées sur le hachage bénéficient néanmoins d’un soutien institutionnel. Le NIST a normalisé SLH-DSA, un schéma de signature à base de hachage sans état dérivé de SPHINCS+, dans FIPS 205 en 2024. Cette norme concerne les signatures numériques, et non les zkVM, mais elle montre pourquoi les organisations considèrent les hachages comme une base post-quantique prudente.

SP1 Hypercube offre un autre point de comparaison. L’article de Microsoft le décrit comme « hash-and-more-based », car son mécanisme central inclut des hypothèses allant au-delà de la sécurité habituelle des hachages. Selon les chercheurs, les preuves mesurées de Magnetar étaient environ 4,6 fois plus petites que celles de SP1 Hypercube.

La comparaison des performances est frappante, mais elle ne doit pas être confondue avec un classement exhaustif des produits. Les outils de développement, les instructions prises en charge, l’accélération matérielle, le coût de la récursion, la fiabilité opérationnelle et l’intégration à l’écosystème influencent tous les choix de déploiement.

Magnetar contre Jolt représente donc une confrontation entre ensembles de choix en matière de sécurité et d’ingénierie, et non entre colonnes de benchmarks isolées. Les configurations Jolt offrent des preuves nettement plus petites. Magnetar revendique un débit mesuré supérieur et moins d’hypothèses sous-jacentes.

Ce résultat pousse les concurrents à expliquer plus clairement leurs choix. Une équipe qui sélectionne désormais un zkVM a des raisons de se demander quelles hypothèses sécurisent le prouveur, à quel point ces hypothèses peuvent évoluer et quels coûts se cachent en dehors du débit mis en avant.

BinarySpartan transforme une sécurité prudente en vitesse

Le mécanisme central de Magnetar aligne le calcul binaire, les hachages standard et la vérification récursive, au lieu de les traiter comme des problèmes distincts.

Magnetar s’appuie sur BinarySpartan, un système de preuve qui transpose la conception Spartan antérieure dans des corps binaires. Un corps binaire représente les valeurs par une arithmétique orientée bits, ce qui en fait un cadre naturel pour la logique des processeurs et les fonctions de hachage standard.

Introduit en 2019, Spartan fournissait des preuves généralistes sans exiger de configuration de confiance. Il utilisait un protocole sum-check, qui permet à un vérificateur de contrôler un vaste calcul structuré grâce à un échange bien plus restreint d’informations algébriques.

Des projets ultérieurs ont traité différents goulets d’étranglement des performances. Phalanx exploitait la structure répétitive de l’exécution des processeurs. Brakedown a développé une approche rapide d’engagement fondée sur le hachage. Lasso, Twist, Shout et des travaux associés ont réduit le coût des preuves de consultations et d’opérations mémoire.

Magnetar combine ces axes de recherche plutôt que de dépendre d’une invention isolée. Sa description du processeur profite de la structure répétée des cycles d’instruction. Sa vérification de mémoire utilise des techniques conçues pour des lectures et écritures efficaces au sein d’une preuve.

BinarySpartan fonctionne également avec Ligerito, un schéma d’engagement issu de Brakedown. Un engagement permet à un prouveur de se lier à des données sans les révéler immédiatement. Le vérificateur peut ensuite contrôler les ouvertures par rapport à la valeur engagée.

Le changement d’anneau apporte un autre composant. Il permet au système de s’engager efficacement sur des vecteurs de bits tout en passant entre des représentations algébriques adaptées à différentes étapes. Cette technique aide à relier les traces du processeur à l’arithmétique binaire du système de preuve.

Ces composants comptent car un zkVM doit prouver davantage que des instructions arithmétiques. Il doit prendre en compte le décodage des instructions, les registres, la cohérence mémoire, les branches et la relation entre des états successifs de la machine.

La mémoire a historiquement été particulièrement coûteuse. Une preuve doit montrer que chaque lecture a renvoyé la bonne valeur écrite précédemment, sans rejouer un système mémoire ordinaire à l’intérieur du vérificateur. Des arguments mémoire efficaces compressent cette vérification de cohérence.

Magnetar prend également en charge la récursion, ce qui signifie qu’une preuve peut attester de la vérification d’une autre preuve. Cela permet de diviser un long calcul en parties gérables, puis de les combiner.

Les systèmes de preuves récursives rencontrent parfois une incompatibilité délicate. La vérification utilise des opérations que la machine virtuelle du prouveur traite inefficacement. Prouver le vérificateur peut alors devenir un coût majeur.

Magnetar tente d’éviter cette incompatibilité. Son travail de vérification consiste principalement en l’évaluation de hachages standard et en arithmétique sur corps binaires. Ce sont précisément les opérations que BinarySpartan est conçu pour prouver efficacement.

Le résultat est une forme d’alignement architectural. Le système prouve le comportement binaire ordinaire d’un processeur, sécurise les engagements avec des hachages standard et peut prouver efficacement son propre vérificateur. Chaque couche renforce le même modèle de calcul.

Microsoft affirme que cette conception peut prendre en charge des calculs de longueur arbitraire en prouvant des segments puis en les combinant. L’entreprise cite également les registres distribués et les blockchains de longue durée comme cibles potentielles.

Une longueur arbitraire ne signifie pas un coût constant. Quelqu’un doit toujours effectuer le calcul et générer chaque segment de preuve. La récursion modifie l’échelle de la vérification et de l’agrégation, mais elle n’élimine pas le travail de production des preuves.

Le mécanisme explique toutefois la vitesse annoncée. Magnetar n’ajoute pas une sécurité post-quantique à une conception existante orientée courbes. Il organise dès le départ le processeur, les engagements, les arguments mémoire et la récursion autour d’opérations adaptées aux bits.

C’est l’aspect le plus convaincant de Magnetar zkVM lorsqu’on l’explique comme une histoire d’ingénierie. Ses affirmations de vitesse et de sécurité découlent de la même décision de conception, plutôt que de deux optimisations sans rapport.

Les benchmarks laissent d’importantes questions sans réponse

Magnetar a modifié la comparaison en matière de recherche, mais n’a pas encore démontré sa maturité pour la production ni une supériorité universelle.

La première incertitude concerne la validation indépendante. Les chiffres de performance disponibles proviennent de Microsoft Research et de son article technique. Des équipes externes doivent reproduire ces résultats avec du matériel, des versions logicielles et des entrées de charge de travail comparables.

Le choix des benchmarks compte également. Quinze applications apportent davantage d’éléments qu’un seul test synthétique, mais elles ne représentent pas toutes les charges de travail de production. Les programmes intensifs en bases de données, les grands interpréteurs, les schémas mémoire inhabituels et les services soutenus multi-utilisateurs peuvent révéler d’autres goulets d’étranglement.

Le débit en cycles n’est qu’une métrique parmi d’autres. Les équipes s’intéressent aussi à la consommation mémoire maximale, à la latence de génération des preuves, aux coûts de démarrage, à la montée en charge parallèle, à l’efficacité dans le cloud et à la reprise après défaillance. Ces facteurs peuvent dominer l’économie d’un prouveur déployé.

La taille de preuve de 600 KiB mérite une attention particulière. Elle est inférieure à celle de la comparaison avec SP1 Hypercube dans l’article, mais supérieure aux preuves Jolt rapportées. Les applications qui publient ou transmettent de gros volumes de preuves doivent évaluer directement cette différence.

La prise en charge des langages doit aussi être interprétée avec prudence. Rust, Go et C peuvent compiler vers RISC-V, mais chaque fonctionnalité de langage, bibliothèque, appel au système d’exploitation ou comportement d’exécution ne fonctionne pas automatiquement dans un zkVM. Un langage source familier ne garantit pas une compatibilité sans restriction.

Les développeurs ont besoin de chaînes d’outils documentées, de débogueurs, d’outils de profilage, de builds reproductibles et de rapports d’erreurs clairs. La maturité du support des compilateurs aide, mais le zkVM définit toujours un environnement d’exécution contraint.

L’examen de sécurité demeure une autre exigence. La base de Magnetar peut ne dépendre que de hachages standard au niveau des hypothèses cryptographiques. L’implémentation inclut toujours un modèle de processeur, du code de preuve, des compilateurs, des interfaces hôtes et de la logique applicative.

Une faille dans l’un de ces composants pourrait produire une affirmation incorrecte ou une intégration exploitable. Des primitives prudentes réduisent une catégorie de risque. Elles ne retirent pas l’assurance logicielle du plan de déploiement.

L’affirmation de résistance quantique requiert également une formulation précise. Microsoft indique que Magnetar évite les courbes elliptiques et repose sur des fonctions de hachage considérées comme résistantes aux attaques quantiques connues. Les algorithmes quantiques peuvent tout de même affecter le niveau de sécurité effectif des hachages ; les choix de paramètres doivent donc tenir compte de cette réduction.

Microsoft inscrit Magnetar dans un effort de migration plus large. Sa chronologie de sécurité quantique vise la transition des produits et services vers la cryptographie post-quantique d’ici 2029. Magnetar s’aligne sur cette orientation, mais l’annonce de recherche n’en fait pas un service Microsoft déployé.

La disponibilité commerciale reste donc une question majeure. L’annonce décrit des résultats de recherche et invite les organisations à discuter de cas d’usage. Elle ne fournit ni date de sortie en production, ni engagement de niveau de service, ni feuille de route de déploiement étendue.

L’absence de ces détails n’affaiblit pas le résultat technique. Elle modifie ce que les acheteurs doivent en déduire. Magnetar établit actuellement une nouvelle référence de recherche, et non un remplacement clé en main de l’infrastructure de preuve existante.

Il existe aussi une limite sémantique partagée par tous les systèmes de preuve. Magnetar peut prouver qu’un code spécifié a été exécuté sur des entrées engagées. Il ne peut pas déterminer si ce code représentait la bonne politique ni si une source d’entrée disait la vérité.

Prenons un agent d’IA qui prouve sa conformité à une règle d’approbation. La preuve peut montrer que la règle a été exécutée. Elle ne peut pas montrer qu’une règle omise aurait dû bloquer l’action, ni qu’un flux de données externe était exact.

Le même problème s’applique à la finance. Une preuve peut établir qu’un programme de traitement des transactions a respecté des contraintes encodées sans révéler les détails des transactions. Les régulateurs et les contreparties doivent toujours évaluer les règles, la provenance des entrées, la gouvernance et les conditions exceptionnelles.

Ces limites doivent orienter l’adoption. L’informatique fondée sur les preuves est la plus robuste lorsque l’énoncé, le programme et les engagements d’entrée peuvent être définis précisément. Elle est moins efficace lorsque les organisations attendent de la cryptographie qu’elle résolve des politiques ambiguës ou des données peu fiables.

Trois signaux montreront si Magnetar dépasse le stade de la recherche

Le prochain test consistera à voir si des développeurs indépendants peuvent reproduire les gains de Magnetar et les transformer en applications durables.

Le premier signal sera la disponibilité d’éléments publics sur l’implémentation. Les chercheurs et développeurs ont besoin de suffisamment de code, de paramètres, d’entrées de benchmark et d’instructions de build pour reproduire la plage de 7,2 à 8,7 millions de cycles par seconde.

Une reproduction sur d’autres processeurs renforcerait les arguments de performance de Microsoft. Des résultats variant fortement selon le matériel ou les configurations mémoire les nuanceraient. Les comparaisons devraient aussi employer des niveaux de sécurité et des définitions de charges de travail équivalents.

Ce détail est important car les benchmarks de systèmes de preuve sont particulièrement sensibles aux choix d’implémentation. Une configuration peut échanger taille de preuve, mémoire, sécurité ou prétraitement contre un débit supérieur. Des libellés comparables ne signifient pas toujours des garanties comparables.

Le deuxième signal sera une application réelle maintenue par une équipe extérieure au groupe de recherche. Un déploiement crédible devrait utiliser du code Rust, Go ou C ordinaire et générer des preuves dans des contraintes opérationnelles réalistes.

Un interpréteur EVM constitue un test possible. Un flux de traitement de données réglementé ou un moteur de politiques pour agents serait tout aussi instructif. L’exemple le plus probant publierait des données sur la latence, l’usage mémoire, la taille des preuves et les défaillances opérationnelles.

Un tel déploiement testerait l’affirmation selon laquelle le calcul généraliste fondé sur les preuves avec Magnetar réduit le travail de développement spécialisé. La compatibilité des compilateurs, le débogage et les procédures de mise à jour comptent autant que le débit des benchmarks.

Le troisième signal sera la réponse des projets zkVM concurrents. Jolt, SP1, RISC Zero et d’autres équipes peuvent contester les résultats de Microsoft au moyen de nouveaux benchmarks, de preuves plus petites, d’accélération matérielle ou d’analyses de sécurité alternatives.

Une réponse centrée uniquement sur le nombre maximal de cycles par seconde renforcerait le discours de Magnetar. Une réponse mettant en évidence un coût total inférieur ou une meilleure fiabilité en production pourrait au contraire l’affaiblir. Le marché a besoin de comparaisons couvrant l’ensemble de la chaîne de preuve.

Les concurrents pourraient également adopter des composants plus conservateurs. Si la sécurité fondée sur des hachages standard devient un critère d’achat, les projets devront proposer des modes compatibles ou expliquer pourquoi leurs hypothèses offrent une alternative acceptable.

Le travail de Microsoft pourrait donc influencer la conception des zkVM sans nécessairement devenir l’implémentation dominante. Il relève le niveau d’exigence attendu pour expliquer conjointement les hypothèses de sécurité, la compatibilité de programmation et les coûts de récursion.

Les développeurs devraient surveiller l’arrivée d’une version exploitable, de suites de benchmarks indépendantes et d’applications démontrant davantage que des transactions en cryptomonnaies. Ces éléments montreraient si l’architecture se généralise au-delà de charges de travail de recherche soigneusement contrôlées.

Les acheteurs en entreprise devraient poser un autre ensemble de questions. Quel énoncé exact la preuve établit-elle ? Quelles données restent privées ? Quelles hypothèses protègent la preuve, et comment le système réagira-t-il si ces hypothèses évoluent ?

Les équipes qui évaluent cette technologie ont également besoin d’un historique durable des conditions de benchmark et des décisions de sécurité. Une base de connaissances d’ingénierie consultable peut relier articles de recherche, résultats de tests, notes d’implémentation et conclusions de revue, sans réduire la décision à un seul chiffre phare.

L’informatique généraliste fondée sur les preuves avec Magnetar a déjà remis en question une hypothèse familière : une sécurité post-quantique conservatrice n’exige pas nécessairement des programmes lents et spécialisés. La prochaine étape consiste à vérifier Magnetar lui-même. Des équipes indépendantes peuvent-elles reproduire les résultats, maintenir des applications ordinaires et préserver le niveau de sécurité annoncé sous la pression de la production ?