Il calcolo generico basato su prove con Magnetar sfida il compromesso degli zkVM

Microsoft Research ha presentato il calcolo generico basato su prove con Magnetar il 15 ottobre, dichiarando incrementi di velocità fino a 39 volte rispetto a macchine virtuali zero-knowledge comparabili. Il sistema può provare programmi scritti in linguaggi familiari mantenendo nascosti gli input privati. Evita inoltre diverse assunzioni crittografiche che i progetti concorrenti accettano per ottenere prestazioni migliori.

Questa combinazione è importante perché i sistemi di prova hanno solitamente costretto gli sviluppatori a scegliere tra velocità, generalità e sicurezza prudente. Magnetar tenta di eliminare questa scelta. Microsoft afferma che può provare normali programmi RISC-V a milioni di cicli del processore al secondo, con una sicurezza fondata su funzioni hash standard.

Il concorrente immediato non è una singola azienda. È il consolidato compromesso ingegneristico alla base di sistemi come Jolt, SP1 e altri zkVM per uso generico. Alcuni offrono prove più brevi, strumenti per sviluppatori maturi o profili prestazionali diversi. La tesi di Magnetar è che gli sviluppatori non debbano più accettare tali compromessi per rendere pratico il calcolo verificabile.

Il calcolo generico basato su prove con Magnetar cambia l'argomento delle prestazioni

Magnetar è rilevante perché combina codice ordinario, un'elevata velocità di generazione delle prove e sicurezza post-quantistica in un unico sistema di ricerca.

Una macchina virtuale zero-knowledge, o zkVM, prova che un programma è stato eseguito correttamente senza richiedere al verificatore di rieseguirlo. Quando la zero knowledge è abilitata, la prova può anche celare gli input privati. Ciò offre al destinatario evidenza di un risultato senza rivelare i dati riservati sottostanti.

La ricerca su Magnetar di Microsoft presenta il sistema come un progresso su tre problemi correlati. La generazione delle prove deve essere sufficientemente rapida per carichi di lavoro realistici. Gli sviluppatori devono poter usare programmi normali invece di circuiti crittografici costruiti a mano. La sicurezza sottostante deve rimanere credibile per l'intera durata prevista del sistema.

Magnetar si rivolge ai programmi compilati in RV64I, il set di istruzioni intere RISC-V base a 64 bit. RISC-V fornisce al sistema un modello di processore convenzionale e accesso a un'infrastruttura di compilazione matura. Gli sviluppatori possono scrivere software in Rust, Go o C, compilarlo e poi provare l'esecuzione risultante.

Questo differisce dai sistemi di prova che richiedono la riscrittura di un'applicazione come circuito aritmetico. Un circuito descrive il calcolo attraverso vincoli algebrici che un sistema di prova può elaborare. Costruirne uno richiede spesso conoscenze specialistiche, mentre le modifiche alla logica dell'applicazione possono richiedere un corrispondente lavoro sul circuito.

Uno zkVM trasferisce gran parte di questo onere nel processore virtuale. Il sistema di prova convalida il comportamento del processore istruzione per istruzione, così i programmi possono seguire un percorso di compilazione standard. Gli sviluppatori devono comunque affrontare il lavoro di integrazione, ma non devono esprimere ogni applicazione come circuito personalizzato.

Microsoft riporta che Magnetar prova tra 7,2 milioni e 8,7 milioni di cicli al secondo su un MacBook Pro M4 Max. L'esperimento citato ha usato 12 core ad alte prestazioni ed esecuzioni contenenti 2²² cicli. Le prove erano di circa 600 KiB e richiedevano tra 11 e 13 millisecondi per la verifica.

Una configurazione ottimizzata raggiungerebbe tra 9,5 milioni e 12,8 milioni di cicli al secondo. Microsoft afferma che questo miglioramento aumenta di circa 1,3 volte i vantaggi comparativi di velocità misurati. Si tratta di benchmark di ricerca, non di misurazioni di servizi in produzione.

Il paper tecnico allegato confronta Magnetar con SP1 Hypercube, Jolt-Dory e Jolt-Akita su 15 carichi di lavoro. Il set di test include hashing crittografico, operazioni su alberi Merkle, firme e trasferimenti di token all'interno di un piccolo interprete Ethereum Virtual Machine.

Secondo questi risultati, Magnetar ha ottenuto un vantaggio di throughput medio geometrico di circa 39 volte rispetto a SP1 Hypercube. Le medie riportate erano di circa 18 volte rispetto a Jolt-Dory e 9,6 volte rispetto a Jolt-Akita. I singoli confronti variavano sostanzialmente in base al carico di lavoro.

Questi dati spiegano perché l'annuncio è più rilevante di un altro benchmark incrementale zero-knowledge. Magnetar non rivendica semplicemente un'esecuzione più rapida in un circuito personalizzato ristretto. Sostiene che un sistema per uso generico basato su hash possa superare alternative costruite intorno a componenti crittografici meno conservativi.

Questo argomento sulle prestazioni ha comunque dei limiti. I benchmark sono stati condotti dal creatore di Magnetar su una sola configurazione laptop. Gli ambienti di produzione introducono limiti di memoria, schemi di concorrenza, costi di rete e dimensioni delle applicazioni diversi. Repliche indipendenti determineranno se il vantaggio resiste in tali condizioni.

Ciononostante, i risultati riportati spostano l'onere della prova. I sistemi basati su hash sono stati spesso considerati conservativi ma costosi. Magnetar afferma che fondamenti conservativi e una velocità di generazione delle prove competitiva possono coesistere.

I linguaggi standard avvicinano le prove al software ordinario

Il cambiamento pratico non è semplicemente una crittografia più rapida, ma un percorso dal codice applicativo mantenuto a un'esecuzione verificabile.

Il modo più semplice per comprendere lo zkVM Magnetar è seguire un programma al suo interno. Uno sviluppatore scrive un'applicazione usando un linguaggio supportato e la compila per RISC-V. Magnetar crea quindi evidenza che l'esecuzione risultante del processore abbia seguito il programma specificato.

Il verificatore non ripete ogni istruzione. Controlla una prova compatta che rappresenta la correttezza dell'esecuzione. Microsoft afferma che questa verifica richiede circa 12 millisecondi nella propria configurazione di benchmark, indipendentemente dal carico di lavoro molto più ampio rappresentato dalla prova.

Ciò cambia chi può creare applicazioni supportate da prove. I circuiti personalizzati concentrano le conoscenze in team che comprendono sia l'applicazione sia il sistema di prova. Uno zkVM per uso generico permette agli ingegneri software convenzionali di conservare più delle loro pratiche esistenti relative a linguaggi, compilatori, test e revisione del codice.

La distinzione è particolarmente importante per il software che cambia frequentemente. Politiche aziendali, pipeline di dati, interpreti e regole degli agenti evolvono nel tempo. Ricostruire circuiti personalizzati per ogni modifica può trasformare la garanzia crittografica in un collo di bottiglia dello sviluppo.

Magnetar non fa scomparire l'ingegneria delle prove. I team devono scegliere quali affermazioni provare, definire input pubblici e privati e gestire l'infrastruttura di generazione delle prove. Devono inoltre verificare che il comportamento compilato corrisponda alla politica di alto livello prevista.

Il sistema sposta invece il confine della specializzazione. I crittografi possono lavorare sullo zkVM e sul suo motore di prova, mentre gli sviluppatori di applicazioni si rivolgono a un'architettura di processore familiare. Questa divisione ricorda il rapporto tra ingegneri dei compilatori e programmatori di applicazioni.

Microsoft evidenzia un interprete Ethereum Virtual Machine come esempio. Un'implementazione EVM scritta in Rust o Go può essere eseguita all'interno di Magnetar. La costruzione risultante può provare le esecuzioni di smart contract esistenti senza implementare ogni contratto direttamente come un nuovo circuito di prova.

Questo approccio è rilevante oltre le blockchain. Un istituto finanziario potrebbe provare che un programma di elaborazione delle transazioni ha applicato regole specificate senza rivelare ogni transazione. Un servizio dati potrebbe provare di aver applicato una trasformazione concordata a record privati.

Gli agenti AI rappresentano un altro possibile utilizzo. Un agente potrebbe fornire evidenza che un'azione è passata attraverso un programma di policy definito. La prova stabilirebbe l'esecuzione di tale policy, anche se non dimostrerebbe automaticamente che la policy fosse completa o sensata.

Questa precisazione è essenziale. Una prova conferma un'affermazione codificata con precisione. Non stabilisce che i dati di origine fossero accurati, che la policy coprisse ogni rischio o che il sistema circostante non fosse stato compromesso.

Il calcolo basato su prove integra quindi audit, controlli di accesso e sicurezza operativa. Non li sostituisce. Il suo contributo specifico è ridurre la fiducia richiesta per un calcolo i cui input e programma siano stati adeguatamente definiti.

L'espressione "Magnetar zkVM explained" può sembrare il titolo di un tutorial sul prodotto, ma la notizia importante è architetturale. Microsoft sostiene che l'esecuzione verificabile debba diventare una proprietà del software ordinario supportata dal compilatore, anziché una categoria applicativa separata.

Questa ambizione mette sotto pressione ogni progetto zkVM per uso generico. L'esperienza per sviluppatori non è più sufficiente se la generazione delle prove rimane costosa. Anche la velocità pura è insufficiente se dipende da assunzioni che gli acquirenti prevedono di sostituire in seguito.

Magnetar vs Jolt espone il vero compromesso crittografico

La competizione centrale non è semplicemente Magnetar vs Jolt sulla velocità, ma hash standard contro prove più brevi e assunzioni alternative.

Jolt è un confronto utile perché i progetti condividono radici intellettuali e architetturali. Entrambi usano RISC-V per supportare programmi per uso generico ed entrambi si basano su ricerche che rendono meno costoso provare istruzioni del processore e operazioni di memoria.

Jolt usa argomenti di lookup, che permettono a un sistema di prova di stabilire che i valori appartengano a tabelle predefinite. Questo può rappresentare le istruzioni del processore in modo più efficiente rispetto all'espressione di ciascuna istruzione attraverso una grande raccolta di vincoli di basso livello.

Il repository open-source Jolt descrive il progetto come uno zkVM RISC-V estensibile. Etichetta inoltre il software attuale come alpha e inadatto all'uso in produzione. Questo avvertimento illustra il più ampio divario tra una ricerca sulle prove promettente e un'infrastruttura affidabile.

Microsoft ha valutato due configurazioni Jolt. Jolt-Dory usa assunzioni sulle curve ellittiche, mentre Jolt-Akita usa crittografia basata su reticoli. Il paper di Magnetar riporta che entrambe producono prove inferiori a 100 KiB, rispetto alle prove di Magnetar di circa 600 KiB.

Prove più piccole possono ridurre i costi di archiviazione e trasmissione. Questo vantaggio è importante quando le prove attraversano reti con vincoli o si accumulano in grandi quantità. La dimensione delle prove può anche influire sul modo in cui un sistema compone la verifica tra diversi livelli.

Magnetar accetta la prova più grande in cambio di una base di sicurezza più ristretta. Microsoft afferma che la sua sicurezza poggia su funzioni hash standard come SHA-256 o SHA-3. Non si basa su curve ellittiche, assunzioni sui reticoli, hash algebrici specializzati o una configurazione fidata.

Una configurazione fidata è un processo una tantum che crea parametri segreti per alcuni sistemi di prova. Se il materiale segreto viene conservato o compromesso, un attaccante potrebbe falsificare le prove. I sistemi trasparenti evitano quella cerimonia e il relativo onere di governance.

I sistemi a curve ellittiche possono fornire prove compatte e una verifica efficiente, ma computer quantistici sufficientemente capaci ne minaccerebbero la sicurezza. I sistemi basati su reticoli sono progettati per resistere agli attacchi quantistici noti, sebbene dipendano da assunzioni matematiche diverse.

La posizione di Magnetar è più conservativa. Le funzioni hash standard hanno ricevuto decenni di analisi e diffusione. Sono inoltre presenti in tutto il software e l'hardware esistenti, offrendo agli implementatori percorsi di ottimizzazione consolidati.

Ciò non rende le funzioni hash infallibili. Magnetar dipende comunque dalle loro proprietà di sicurezza e dalla correttezza della sua implementazione. “Post-quantum” indica resistenza agli attacchi quantistici attualmente noti, non una garanzia permanente contro ogni scoperta futura.

Esiste nondimeno un sostegno istituzionale ai progetti basati su hash. Nel 2024 NIST ha standardizzato SLH-DSA, uno schema di firma stateless basato su hash derivato da SPHINCS+, in FIPS 205. Lo standard riguarda le firme digitali, non le zkVM, ma mostra perché le organizzazioni considerino gli hash una base post-quantum prudente.

SP1 Hypercube offre un altro termine di confronto. Il paper di Microsoft lo descrive come “hash-and-more-based” perché il suo meccanismo centrale include ipotesi ulteriori rispetto alla normale sicurezza degli hash. Secondo i ricercatori, le proof misurate di Magnetar erano circa 4,6 volte più piccole di quelle di SP1 Hypercube.

Il confronto delle prestazioni è notevole, ma non va scambiato per una classifica completa dei prodotti. Strumenti per sviluppatori, istruzioni supportate, accelerazione hardware, costi della ricorsione, affidabilità operativa e integrazione nell’ecosistema influenzano tutti le scelte di deployment.

Magnetar vs Jolt è quindi un confronto fra pacchetti di sicurezza e ingegneria, non fra colonne isolate di benchmark. Le configurazioni Jolt offrono proof sensibilmente più piccole. Magnetar dichiara throughput misurato più elevato e meno ipotesi sottostanti.

Il risultato spinge i concorrenti a spiegare più chiaramente le loro scelte. Un team che seleziona una zkVM ha ora motivo di chiedersi quali ipotesi proteggano il prover, quanto facilmente tali ipotesi possano cambiare e quali costi emergano al di fuori del throughput in evidenza.

BinarySpartan trasforma la sicurezza prudente in velocità

Il meccanismo centrale di Magnetar allinea il calcolo binario, gli hash standard e la verifica ricorsiva, anziché trattarli come problemi separati.

Magnetar si basa su BinarySpartan, un sistema di proof che porta il precedente progetto Spartan nei campi binari. Un campo binario rappresenta i valori attraverso aritmetica orientata ai bit, rendendolo un ambiente naturale per la logica dei processori e le funzioni hash standard.

Spartan, introdotto nel 2019, forniva proof general-purpose senza richiedere un trusted setup. Utilizzava un protocollo sum-check, che consente a un verifier di controllare un grande calcolo strutturato attraverso uno scambio molto più ridotto di informazioni algebriche.

I progetti successivi hanno affrontato diversi colli di bottiglia prestazionali. Phalanx ha sfruttato la struttura ripetitiva dell’esecuzione del processore. Brakedown ha sviluppato un approccio rapido ai commitment basato su hash. Lasso, Twist, Shout e lavori correlati hanno ridotto il costo di dimostrare lookup e operazioni di memoria.

Magnetar combina queste linee di ricerca anziché dipendere da una singola innovazione isolata. La sua descrizione del processore beneficia della struttura ripetuta dei cicli di istruzione. Il controllo della memoria usa tecniche progettate per letture e scritture efficienti all’interno di una proof.

BinarySpartan funziona anche con Ligerito, uno schema di commitment derivato da Brakedown. Un commitment consente a un prover di vincolarsi a dati senza rivelarli immediatamente. Il verifier può in seguito controllare le aperture rispetto al valore vincolato.

Il ring switching fornisce un altro componente. Consente al sistema di effettuare commitment efficienti a vettori di bit passando tra rappresentazioni algebriche adatte a fasi diverse. La tecnica aiuta a collegare le tracce del processore con l’aritmetica binaria del sistema di proof.

Questi componenti sono importanti perché una zkVM deve dimostrare più delle istruzioni aritmetiche. Deve rendere conto della decodifica delle istruzioni, dei registri, della coerenza della memoria, delle diramazioni e della relazione fra stati consecutivi della macchina.

Storicamente, la memoria è stata particolarmente costosa. Una proof deve mostrare che ogni lettura abbia restituito il valore corretto scritto in precedenza, senza rieseguire un normale sistema di memoria all’interno del verifier. Argomenti di memoria efficienti comprimono quel controllo di coerenza.

Magnetar supporta anche la ricorsione, cioè una proof può attestare la verifica di un’altra proof. Ciò consente di dividere un calcolo lungo in parti gestibili e poi combinarle.

I sistemi di proof ricorsivi talvolta incontrano una scomoda incompatibilità. La verifica utilizza operazioni che la macchina virtuale del prover gestisce in modo inefficiente. Dimostrare il verifier può quindi diventare un costo rilevante.

Magnetar cerca di evitare tale incompatibilità. Il suo lavoro di verifica consiste principalmente nella valutazione di hash standard e nell’aritmetica su campi binari. Sono le stesse operazioni che BinarySpartan è progettato per dimostrare in modo efficiente.

Il risultato è una sorta di allineamento architetturale. Il sistema dimostra il normale comportamento binario del processore, protegge i commitment con hash standard e può dimostrare in modo efficiente il proprio verifier. Ogni livello rafforza lo stesso modello computazionale.

Microsoft afferma che questo progetto può supportare calcoli di lunghezza arbitraria dimostrando le singole parti e combinandole. Indica inoltre ledger e blockchain a lunga esecuzione come possibili destinazioni.

Lunghezza arbitraria non significa costo costante. Qualcuno deve comunque eseguire il calcolo e generare ciascun segmento di proof. La ricorsione modifica il modo in cui verifica e aggregazione scalano, ma non elimina il lavoro di proving.

Il meccanismo spiega la velocità riportata. Magnetar non aggiunge la sicurezza post-quantum a un progetto esistente orientato alle curve. Organizza fin dall’inizio processore, commitment, argomenti di memoria e ricorsione attorno a operazioni favorevoli ai bit.

Questa è la parte più solida di Magnetar zkVM spiegata come storia di ingegneria. Le sue dichiarazioni di velocità e sicurezza derivano dalla stessa decisione progettuale, anziché da due ottimizzazioni non correlate.

I benchmark lasciano senza risposta questioni importanti

Magnetar ha cambiato il confronto nella ricerca, ma non ha ancora stabilito la prontezza per la produzione o una superiorità universale.

La prima incertezza riguarda la validazione indipendente. Le cifre disponibili sulle prestazioni provengono da Microsoft Research e dal suo paper tecnico. Team esterni devono riprodurre tali risultati su hardware, versioni software e input di workload comparabili.

Anche la selezione dei benchmark è importante. Quindici applicazioni forniscono più evidenza di un singolo test sintetico, ma non rappresentano ogni workload di produzione. Programmi incentrati sui database, grandi interpreti, schemi di memoria insoliti e servizi multiutente prolungati possono rivelare colli di bottiglia diversi.

Il throughput dei cicli è soltanto una metrica. I team considerano anche il consumo massimo di memoria, la latenza di generazione delle proof, i costi di avvio, la scalabilità parallela, l’efficienza nel cloud e il recupero dai guasti. Questi fattori possono dominare l’economia di un prover distribuito.

La dimensione di proof di 600 KiB merita particolare attenzione. È più piccola rispetto al confronto del paper con SP1 Hypercube, ma più grande delle proof Jolt riportate. Le applicazioni che pubblicano o trasmettono grandi volumi di proof devono valutare direttamente questa differenza.

Anche il supporto linguistico richiede un’interpretazione attenta. Rust, Go e C possono compilare in RISC-V, ma non ogni funzionalità del linguaggio, libreria, chiamata al sistema operativo o comportamento del runtime funziona automaticamente all’interno di una zkVM. Un linguaggio sorgente familiare non equivale a compatibilità illimitata.

Gli sviluppatori hanno bisogno di toolchain documentate, debugger, supporto per il profiling, build riproducibili e report chiari degli errori. Un supporto maturo del compilatore aiuta, ma la zkVM definisce comunque un ambiente di esecuzione vincolato.

La revisione della sicurezza resta un altro requisito. La base di Magnetar può dipendere soltanto da hash standard a livello di ipotesi crittografiche. L’implementazione include comunque un modello di processore, codice di proof, compilatori, interfacce host e logica applicativa.

Un difetto in uno qualsiasi di questi componenti potrebbe produrre un’affermazione errata o un’integrazione sfruttabile. Primitive prudenti riducono una categoria di rischio. Non eliminano la garanzia del software dal piano di deployment.

Anche l’affermazione di resistenza quantistica richiede una formulazione precisa. Microsoft afferma che Magnetar evita le curve ellittiche e si basa su funzioni hash considerate resistenti agli attacchi quantistici noti. Gli algoritmi quantistici possono comunque influire sul livello effettivo di sicurezza degli hash, pertanto la scelta dei parametri deve tenere conto di tale riduzione.

Microsoft colloca Magnetar in un più ampio sforzo di migrazione. La sua timeline quantum-safe punta a trasferire prodotti e servizi alla crittografia post-quantum entro il 2029. Magnetar è coerente con questa direzione, ma l’annuncio della ricerca non lo rende un servizio Microsoft già distribuito.

La disponibilità commerciale è quindi una questione aperta rilevante. L’annuncio descrive risultati di ricerca e invita le organizzazioni a discutere casi d’uso. Non fornisce una data di rilascio per la produzione, un impegno sul livello di servizio né una roadmap di deployment ampia.

L’assenza di tali dettagli non indebolisce il risultato tecnico. Cambia ciò che gli acquirenti dovrebbero dedurne. Magnetar stabilisce attualmente una nuova base di riferimento per la ricerca, non un sostituto chiavi in mano dell’infrastruttura di proof esistente.

Esiste anche una limitazione semantica condivisa da tutti i sistemi di proof. Magnetar può dimostrare che un codice specificato sia stato eseguito su input vincolati. Non può determinare se il codice rappresentasse la policy corretta o se una fonte di input abbia riferito il vero.

Si consideri un agente AI che dimostri la conformità a una regola di approvazione. La proof può mostrare che la regola sia stata eseguita. Non può mostrare che una regola omessa avrebbe dovuto bloccare l’azione, né che un feed di dati esterno fosse accurato.

La stessa questione si applica alla finanza. Una proof può stabilire che un programma di elaborazione delle transazioni abbia seguito vincoli codificati senza rivelare i dettagli delle transazioni. Regolatori e controparti devono comunque valutare le regole, la provenienza degli input, la governance e le condizioni eccezionali.

Queste limitazioni dovrebbero orientare l’adozione. Il calcolo basato su proof è più forte quando l’affermazione, il programma e gli impegni sugli input possono essere definiti con precisione. È più debole quando le organizzazioni si aspettano che la crittografia risolva policy ambigue o dati inaffidabili.

Tre segnali mostreranno se Magnetar andrà oltre la ricerca

Il prossimo test è verificare se sviluppatori indipendenti possano riprodurre i vantaggi di Magnetar e trasformarli in applicazioni durature.

Il primo segnale è l’evidenza di implementazione pubblica. Ricercatori e sviluppatori hanno bisogno di codice, parametri, input dei benchmark e istruzioni di build sufficienti per riprodurre l’intervallo fra 7,2 milioni e 8,7 milioni di cicli al secondo.

La riproduzione su altri processori rafforzerebbe il caso prestazionale di Microsoft. Risultati che variano nettamente fra configurazioni hardware o di memoria lo circoscriverebbero. I confronti dovrebbero anche usare livelli di sicurezza e definizioni dei workload equivalenti.

Questo dettaglio è importante perché i benchmark dei sistemi di proof sono insolitamente sensibili alle scelte di implementazione. Una configurazione può sacrificare dimensione della proof, memoria, sicurezza o preprocessing per ottenere un throughput più elevato. Etichette comparabili non implicano sempre garanzie comparabili.

Il secondo segnale è un’applicazione reale mantenuta da un team esterno al gruppo di ricerca. Un deployment credibile dovrebbe utilizzare normale codice Rust, Go o C e generare proof sotto vincoli operativi realistici.

Un interprete EVM è un possibile test. Un workflow regolamentato di elaborazione dati o un motore di policy per agenti sarebbe altrettanto informativo. L’esempio più solido pubblicherebbe dati su latenza, uso della memoria, dimensione delle proof e guasti operativi.

Un simile deployment testerebbe l’affermazione secondo cui il calcolo general-purpose basato su proof con Magnetar riduce il lavoro di sviluppo specializzato. Compatibilità del compilatore, debugging e procedure di aggiornamento contano quanto il throughput dei benchmark.

Il terzo segnale è la risposta dei progetti zkVM concorrenti. Jolt, SP1, RISC Zero e altri team possono contestare i risultati di Microsoft attraverso nuovi benchmark, proof più piccole, accelerazione hardware o analisi di sicurezza alternative.

Una risposta incentrata solo sul massimo numero di cicli al secondo rafforzerebbe la posizione di Magnetar. Una risposta che dimostrasse un costo totale inferiore o una migliore affidabilità in produzione potrebbe indebolirla. Il mercato ha bisogno di confronti che coprano l’intera pipeline di proving.

Anche i concorrenti potrebbero adottare componenti più conservativi. Se la sicurezza basata su hash standard dovesse diventare un requisito d’acquisto, i progetti dovranno offrire modalità compatibili oppure spiegare perché le loro assunzioni costituiscono un’alternativa accettabile.

Il lavoro di Microsoft potrebbe quindi influenzare la progettazione delle zkVM anche senza diventare l’implementazione dominante. Alza il livello di riferimento atteso per spiegare insieme le assunzioni di sicurezza, la compatibilità di programmazione e i costi della ricorsione.

Gli sviluppatori dovrebbero tenere d’occhio una release utilizzabile, suite di benchmark indipendenti e applicazioni che dimostrino qualcosa di più delle transazioni in criptovalute. Questi eventi mostrerebbero se l’architettura è generalizzabile oltre carichi di lavoro di ricerca attentamente controllati.

Gli acquirenti aziendali dovrebbero porre una serie diversa di domande. Quale affermazione esatta stabilisce la prova? Quali input restano privati? Quali assunzioni proteggono la prova e come reagirà il sistema se tali assunzioni cambiano?

I team che valutano la tecnologia necessitano inoltre di una registrazione duratura delle condizioni dei benchmark e delle decisioni di sicurezza. Una base di conoscenza ingegneristica ricercabile può collegare paper, risultati dei test, note di implementazione e conclusioni delle revisioni senza ridurre la decisione a un unico dato in evidenza.

Il calcolo generico basato su prove con Magnetar ha già messo in discussione un’assunzione consolidata: una sicurezza post-quantistica conservativa non richiede necessariamente programmi lenti e specializzati. Il passo successivo è la verifica di Magnetar stesso. Team indipendenti riusciranno a riprodurre i risultati, a mantenere applicazioni ordinarie e a preservare la sicurezza dichiarata sotto la pressione della produzione?