Beweisgestütztes General-Purpose Computing mit Magnetar stellt den zkVM-Kompromiss infrage

Microsoft Research stellte am 15. Oktober beweisgestütztes General-Purpose Computing mit Magnetar vor und behauptet Geschwindigkeitsvorteile von bis zu 39-mal gegenüber vergleichbaren Zero-Knowledge Virtual Machines. Das System kann Programme in vertrauten Sprachen beweisen und dabei private Eingaben verborgen halten. Zudem vermeidet es mehrere kryptografische Annahmen, die konkurrierende Designs zugunsten höherer Leistung akzeptieren.

Diese Kombination ist relevant, weil Beweissysteme Entwickler bislang meist zu einer Wahl zwischen Geschwindigkeit, Allgemeingültigkeit und konservativer Sicherheit gezwungen haben. Magnetar versucht, diese Entscheidung aufzuheben. Microsoft zufolge kann das System gewöhnliche RISC-V-Programme mit mehreren Millionen Prozessorzyklen pro Sekunde beweisen und stützt seine Sicherheit auf Standard-Hashfunktionen.

Der unmittelbare Gegner ist nicht ein einzelnes Unternehmen. Es ist der etablierte technische Kompromiss hinter Systemen wie Jolt, SP1 und anderen General-Purpose-zkVMs. Einige bieten kürzere Beweise, ausgereifte Entwicklerwerkzeuge oder andere Leistungsprofile. Magnetar behauptet, Entwickler müssten diese Kompromisse nicht länger eingehen, um überprüfbares Computing praktisch nutzbar zu machen.

Beweisgestütztes General-Purpose Computing mit Magnetar verändert die Leistungsdebatte

Magnetar ist relevant, weil es gewöhnlichen Code, hohen Beweisdurchsatz und Post-Quanten-Sicherheit in einem Forschungssystem vereint.

Eine Zero-Knowledge Virtual Machine, kurz zkVM, beweist die korrekte Ausführung eines Programms, ohne dass der Verifizierer es erneut ausführen muss. Ist Zero Knowledge aktiviert, kann der Beweis zudem private Eingaben verbergen. So erhält der Empfänger Nachweise über ein Ergebnis, ohne die zugrunde liegenden vertraulichen Daten offenzulegen.

Microsofts Magnetar-Forschung beschreibt das System als Fortschritt bei drei miteinander verbundenen Problemen. Die Beweiserzeugung muss schnell genug für realistische Workloads sein. Entwickler müssen normale Programme statt handgefertigter kryptografischer Schaltkreise verwenden können. Und die zugrunde liegende Sicherheit muss während der vorgesehenen Lebensdauer des Systems glaubwürdig bleiben.

Magnetar zielt auf Programme, die nach RV64I kompiliert werden, dem grundlegenden 64-Bit-RISC-V-Befehlssatz für Ganzzahlen. RISC-V verschafft dem System ein konventionelles Prozessormodell und Zugang zu ausgereifter Compiler-Infrastruktur. Entwickler können Software in Rust, Go oder C schreiben, kompilieren und anschließend die daraus resultierende Ausführung beweisen.

Das unterscheidet sich von Beweissystemen, die eine Anwendung als arithmetischen Schaltkreis neu formulieren müssen. Ein Schaltkreis beschreibt die Berechnung durch algebraische Einschränkungen, die ein Beweissystem verarbeiten kann. Seine Erstellung erfordert oft Spezialwissen, während Änderungen an der Anwendungslogik entsprechende Arbeiten am Schaltkreis nach sich ziehen können.

Eine zkVM verlagert einen Großteil dieser Last in den virtuellen Prozessor. Das Beweissystem validiert das Verhalten des Prozessors Befehl für Befehl, sodass Programme einen Standard-Kompilierungspfad nutzen können. Entwickler müssen weiterhin Integrationsarbeit leisten, aber sie müssen nicht jede Anwendung als maßgeschneiderten Schaltkreis ausdrücken.

Microsoft berichtet, dass Magnetar auf einem M4 Max MacBook Pro zwischen 7,2 Millionen und 8,7 Millionen Zyklen pro Sekunde beweist. Das zitierte Experiment verwendete 12 Performance-Kerne und Ausführungen mit 2²² Zyklen. Die Beweise waren ungefähr 600 KiB groß und benötigten zur Verifizierung zwischen 11 und 13 Millisekunden.

Eine optimierte Konfiguration erreicht Berichten zufolge zwischen 9,5 Millionen und 12,8 Millionen Zyklen pro Sekunde. Microsoft zufolge erhöht diese Verbesserung die gemessenen vergleichenden Geschwindigkeitsvorteile um etwa das 1,3-Fache. Es handelt sich um Forschungsbenchmarks, nicht um Messwerte eines Produktionsdienstes.

Das begleitende technische Paper vergleicht Magnetar über 15 Workloads hinweg mit SP1 Hypercube, Jolt-Dory und Jolt-Akita. Der Testsatz umfasst kryptografisches Hashing, Merkle-Tree-Operationen, Signaturen und Token-Transfers innerhalb eines kleinen Ethereum-Virtual-Machine-Interpreters.

Diesen Ergebnissen zufolge erzielte Magnetar gegenüber SP1 Hypercube einen geometrisch gemittelten Durchsatzvorteil von etwa dem 39-Fachen. Die berichteten Durchschnittswerte lagen bei ungefähr dem 18-Fachen gegenüber Jolt-Dory und dem 9,6-Fachen gegenüber Jolt-Akita. Die einzelnen Vergleiche unterschieden sich je nach Workload erheblich.

Diese Werte erklären, warum die Ankündigung folgenreicher ist als ein weiterer schrittweiser Zero-Knowledge-Benchmark. Magnetar behauptet nicht nur eine schnellere Ausführung in einem eng zugeschnittenen Schaltkreis. Es behauptet, dass ein General-Purpose-System auf Basis von Hashfunktionen Alternativen übertreffen kann, die auf weniger konservativen kryptografischen Komponenten beruhen.

Dieses Leistungsargument hat jedoch Grenzen. Die Benchmarks wurden vom Ersteller von Magnetar auf einer einzelnen Laptop-Konfiguration durchgeführt. Produktionsumgebungen bringen andere Speichergrenzen, Parallelisierungsmuster, Netzwerkkosten und Anwendungsgrößen mit sich. Unabhängige Replikationen werden zeigen, ob der Vorsprung unter diesen Bedingungen bestehen bleibt.

Dennoch verändern die berichteten Ergebnisse die Beweislast. Hash-basierte Systeme galten oft als konservativ, aber kostspielig. Magnetar zufolge können konservative Grundlagen und wettbewerbsfähige Beweisgeschwindigkeit koexistieren.

Standardsprachen bringen Beweise näher an gewöhnliche Software

Der praktische Wandel liegt nicht nur in schnellerer Kryptografie, sondern in einem Weg von gepflegtem Anwendungscode zu einer überprüfbaren Ausführung.

Der einfachste Weg, die Magnetar-zkVM zu verstehen, besteht darin, einem Programm durch das System zu folgen. Ein Entwickler schreibt eine Anwendung in einer unterstützten Sprache und kompiliert sie für RISC-V. Magnetar erzeugt dann Nachweise dafür, dass die daraus resultierende Prozessorausführung dem festgelegten Programm folgte.

Der Verifizierer wiederholt nicht jeden Befehl. Er prüft einen kompakten Beweis, der die Korrektheit der Ausführung repräsentiert. Microsoft zufolge dauert diese Verifizierung in der Benchmark-Konfiguration etwa 12 Millisekunden, unabhängig von dem wesentlich größeren Workload, den der Beweis abbildet.

Das verändert, wer beweisgestützte Anwendungen entwickeln kann. Maßgeschneiderte Schaltkreise bündeln Wissen in Teams, die sowohl die Anwendung als auch das Beweissystem verstehen. Eine General-Purpose-zkVM ermöglicht es konventionellen Softwareingenieuren, mehr ihrer bestehenden Praktiken für Sprache, Compiler, Tests und Code Reviews beizubehalten.

Die Unterscheidung ist besonders wichtig für Software, die sich häufig verändert. Geschäftspolitiken, Datenpipelines, Interpreter und Agentenregeln entwickeln sich über die Zeit weiter. Maßgeschneiderte Schaltkreise für jede Änderung neu zu erstellen, kann kryptografische Absicherung zu einem Entwicklungsengpass machen.

Magnetar lässt das Beweis-Engineering nicht verschwinden. Teams müssen entscheiden, welche Aussagen sie beweisen möchten, öffentliche und private Eingaben definieren und die Beweisinfrastruktur betreiben. Sie müssen außerdem überprüfen, ob das kompilierte Verhalten der beabsichtigten übergeordneten Richtlinie entspricht.

Stattdessen verschiebt das System die Grenze der Spezialisierung. Kryptografen können an der zkVM und ihrer Proof Engine arbeiten, während Anwendungsentwickler auf eine vertraute Prozessorarchitektur zielen. Diese Aufteilung ähnelt der Beziehung zwischen Compiler-Ingenieuren und Anwendungsprogrammierern.

Microsoft hebt einen Ethereum-Virtual-Machine-Interpreter als Beispiel hervor. Eine in Rust oder Go geschriebene EVM-Implementierung kann innerhalb von Magnetar laufen. Die daraus resultierende Konstruktion kann Ausführungen bestehender Smart Contracts beweisen, ohne jeden Contract unmittelbar als neuen Beweisschaltkreis zu implementieren.

Dieser Ansatz ist auch außerhalb von Blockchains relevant. Ein Finanzinstitut könnte beweisen, dass ein Programm zur Transaktionsverarbeitung festgelegte Regeln durchsetzte, ohne jede Transaktion offenzulegen. Ein Datendienst könnte beweisen, dass er eine vereinbarte Transformation auf private Datensätze angewandt hat.

KI-Agenten stellen einen weiteren möglichen Anwendungsfall dar. Ein Agent könnte Nachweise liefern, dass eine Aktion ein definiertes Richtlinienprogramm durchlaufen hat. Der Beweis würde die Ausführung dieser Richtlinie belegen, jedoch nicht automatisch zeigen, dass die Richtlinie vollständig oder sinnvoll war.

Diese Einschränkung ist wesentlich. Ein Beweis bestätigt eine präzise codierte Aussage. Er belegt nicht, dass die Quelldaten korrekt waren, die Richtlinie jedes Risiko erfasste oder das umgebende System nicht kompromittiert wurde.

Beweisgestütztes Computing ergänzt daher Audits, Zugriffskontrollen und Betriebssicherheit. Es ersetzt sie nicht. Sein spezifischer Beitrag besteht darin, das notwendige Vertrauen für eine Berechnung zu verringern, deren Eingaben und Programm ordnungsgemäß definiert wurden.

Die Formulierung „Magnetar zkVM erklärt“ kann wie ein Produkttutorial klingen, doch die wichtige Nachricht ist architektonischer Natur. Microsoft argumentiert, dass überprüfbare Ausführung zu einer compiler-gestützten Eigenschaft gewöhnlicher Software werden sollte, statt eine separate Anwendungskategorie zu bleiben.

Dieser Anspruch setzt jedes General-Purpose-zkVM-Projekt unter Druck. Entwicklererfahrung reicht nicht länger aus, wenn die Beweiserzeugung kostspielig bleibt. Reine Geschwindigkeit genügt ebenfalls nicht, wenn sie von Annahmen abhängt, die Käufer später ersetzen wollen.

Magnetar vs Jolt legt den eigentlichen kryptografischen Kompromiss offen

Im Zentrum steht nicht einfach Magnetar vs Jolt bei der Geschwindigkeit, sondern Standard-Hashfunktionen gegenüber kürzeren Beweisen und alternativen Annahmen.

Jolt ist ein sinnvoller Vergleich, weil die Projekte intellektuelle und architektonische Wurzeln teilen. Beide nutzen RISC-V zur Unterstützung von General-Purpose-Programmen und bauen auf Forschung auf, die Prozessorbefehle und Speicheroperationen kostengünstiger beweisbar macht.

Jolt verwendet Lookup-Argumente, mit denen ein Beweissystem belegen kann, dass Werte zu vordefinierten Tabellen gehören. Dadurch lassen sich Prozessorbefehle effizienter darstellen, als jeden Befehl durch eine große Sammlung niedrigstufiger Einschränkungen auszudrücken.

Das Open-Source-Jolt-Repository beschreibt das Projekt als erweiterbare RISC-V-zkVM. Es kennzeichnet die aktuelle Software außerdem als Alpha und für den Produktionseinsatz ungeeignet. Diese Warnung verdeutlicht die breitere Lücke zwischen vielversprechender Beweisforschung und zuverlässiger Infrastruktur.

Microsoft bewertete zwei Jolt-Konfigurationen. Jolt-Dory verwendet Annahmen zu elliptischen Kurven, während Jolt-Akita auf gitterbasierter Kryptografie beruht. Magnetars Paper berichtet, dass beide Beweise unter 100 KiB erzeugen, verglichen mit Magnetars Beweisen von ungefähr 600 KiB.

Kleinere Beweise können Speicher- und Übertragungskosten senken. Dieser Vorteil ist relevant, wenn Beweise eingeschränkte Netzwerke überqueren oder sich in großer Zahl ansammeln. Die Beweisgröße kann außerdem beeinflussen, wie ein System die Verifizierung über mehrere Ebenen hinweg zusammensetzt.

Magnetar akzeptiert den größeren Beweis im Austausch für eine engere Sicherheitsgrundlage. Microsoft zufolge beruht seine Sicherheit auf Standard-Hashfunktionen wie SHA-256 oder SHA-3. Es stützt sich nicht auf elliptische Kurven, Gitterannahmen, spezialisierte algebraische Hashfunktionen oder ein Trusted Setup.

Ein Trusted Setup ist ein einmaliger Prozess, der geheime Parameter für einige Beweissysteme erzeugt. Wenn das geheime Material aufbewahrt oder kompromittiert wird, könnte ein Angreifer Beweise fälschen. Transparente Systeme vermeiden diese Zeremonie und den damit verbundenen Governance-Aufwand.

Systeme auf Basis elliptischer Kurven können kompakte Beweise und effiziente Verifizierung bieten, doch ausreichend leistungsfähige Quantencomputer würden ihre Sicherheit bedrohen. Gitterbasierte Systeme sind darauf ausgelegt, bekannten Quantenangriffen zu widerstehen, beruhen jedoch auf anderen mathematischen Annahmen.

Magnetars Position ist konservativer. Standard-Hashfunktionen wurden über Jahrzehnte analysiert und eingesetzt. Sie finden sich zudem in bestehender Software und Hardware, was Implementierern etablierte Optimierungspfade verschafft.

Das macht Hash-Funktionen nicht unfehlbar. Magnetar hängt weiterhin von ihren Sicherheitseigenschaften und der Korrektheit seiner Implementierung ab. „Post-Quantum“ bedeutet Widerstandsfähigkeit gegen derzeit bekannte Quantenangriffe, keine dauerhafte Garantie gegen jede künftige Entdeckung.

Dennoch gibt es institutionelle Unterstützung für hashbasierte Entwürfe. NIST standardisierte 2024 mit FIPS 205 SLH-DSA, ein zustandsloses hashbasiertes Signaturverfahren, das von SPHINCS+ abgeleitet ist. Der Standard betrifft digitale Signaturen, nicht zkVMs, zeigt aber, warum Organisationen Hashes als konservatives Fundament für Post-Quantum-Sicherheit betrachten.

SP1 Hypercube bietet einen weiteren Vergleichspunkt. Microsofts Paper bezeichnet es als „hash-and-more-based“, weil seine Kernmechanik Annahmen umfasst, die über die gewöhnliche Sicherheit von Hashes hinausgehen. Die gemessenen Beweise von Magnetar waren laut den Forschern etwa 4,6-mal kleiner als die von SP1 Hypercube.

Der Leistungsvergleich ist auffällig, sollte aber nicht als vollständiges Produktranking missverstanden werden. Entwicklerwerkzeuge, unterstützte Instruktionen, Hardwarebeschleunigung, Rekursionskosten, operative Zuverlässigkeit und Ökosystemintegration beeinflussen allesamt die Bereitstellungsentscheidung.

Magnetar vs. Jolt ist daher ein Wettbewerb zwischen Sicherheits- und Engineering-Gesamtpaketen, nicht zwischen isolierten Benchmark-Spalten. Jolt-Konfigurationen bieten deutlich kleinere Beweise. Magnetar beansprucht einen höheren gemessenen Durchsatz und weniger zugrunde liegende Annahmen.

Das Ergebnis setzt Wettbewerber unter Druck, ihre Entscheidungen klarer zu erklären. Teams, die nun eine zkVM auswählen, haben Grund zu fragen, welche Annahmen den Prover absichern, wie leicht sich diese Annahmen ändern können und welche Kosten außerhalb des Schlagzeilen-Durchsatzes entstehen.

BinarySpartan verwandelt konservative Sicherheit in Geschwindigkeit

Der Kernmechanismus von Magnetar verbindet binäre Berechnungen, Standard-Hashes und rekursive Verifikation, statt sie als getrennte Probleme zu behandeln.

Magnetar baut auf BinarySpartan auf, einem Beweissystem, das das frühere Spartan-Design auf binäre Körper überträgt. Ein binärer Körper stellt Werte über bitorientierte Arithmetik dar und bietet damit eine natürliche Grundlage für Prozessorlogik und Standard-Hash-Funktionen.

Spartan, 2019 vorgestellt, ermöglichte universell einsetzbare Beweise ohne vertrauenswürdiges Setup. Es nutzte ein Sum-Check-Protokoll, mit dem ein Verifizierer eine große strukturierte Berechnung durch einen wesentlich kleineren Austausch algebraischer Informationen prüfen kann.

Spätere Projekte befassten sich mit verschiedenen Leistungsengpässen. Phalanx nutzte die wiederkehrende Struktur der Prozessorausführung. Brakedown entwickelte einen schnellen hashbasierten Commitment-Ansatz. Lasso, Twist, Shout und verwandte Arbeiten senkten die Kosten für den Nachweis von Lookups und Speicheroperationen.

Magnetar kombiniert diese Forschungslinien, statt sich auf eine einzelne isolierte Erfindung zu stützen. Seine Prozessorbeschreibung profitiert von der wiederholten Struktur von Instruktionszyklen. Seine Speicherprüfung verwendet Verfahren, die für effiziente Lese- und Schreibvorgänge innerhalb eines Beweises ausgelegt sind.

BinarySpartan arbeitet auch mit Ligerito, einem von Brakedown abgeleiteten Commitment-Verfahren. Ein Commitment ermöglicht es einem Prover, sich an Daten zu binden, ohne diese sofort offenzulegen. Der Verifizierer kann spätere Öffnungen gegen den festgelegten Wert prüfen.

Ring Switching liefert eine weitere Komponente. Es ermöglicht dem System, effizient Commitments für Bit-Vektoren zu erstellen und dabei zwischen algebraischen Darstellungen zu wechseln, die für verschiedene Phasen geeignet sind. Die Technik hilft, Prozessor-Traces mit der binären Arithmetik des Beweissystems zu verbinden.

Diese Komponenten sind wichtig, weil eine zkVM mehr als arithmetische Instruktionen beweisen muss. Sie muss Instruktionsdekodierung, Register, Speicherkonsistenz, Verzweigungen und die Beziehung zwischen aufeinanderfolgenden Maschinenzuständen abbilden.

Speicher war historisch besonders teuer. Ein Beweis muss zeigen, dass jeder Lesevorgang den korrekten zuvor geschriebenen Wert zurückgab, ohne ein gewöhnliches Speichersystem im Verifizierer erneut auszuführen. Effiziente Speicherargumente komprimieren diese Konsistenzprüfung.

Magnetar unterstützt auch Rekursion, also die Möglichkeit, dass ein Beweis die Verifikation eines anderen Beweises bestätigt. So lässt sich eine lange Berechnung in handhabbare Teile zerlegen und anschließend zusammenführen.

Rekursive Beweissysteme stoßen mitunter auf eine ungünstige Diskrepanz. Die Verifikation verwendet Operationen, die die virtuelle Maschine des Provers ineffizient verarbeitet. Der Nachweis des Verifizierers kann dadurch zu einem erheblichen Kostenfaktor werden.

Magnetar versucht, diese Diskrepanz zu vermeiden. Seine Verifikationsarbeit besteht hauptsächlich aus der Auswertung von Standard-Hashes und Arithmetik über binären Körpern. Genau diese Operationen soll BinarySpartan effizient beweisen.

Das Ergebnis ist eine Art architektonische Ausrichtung. Das System beweist gewöhnliches binäres Prozessorverhalten, sichert Commitments mit Standard-Hashes und kann seinen eigenen Verifizierer effizient beweisen. Jede Ebene stärkt dasselbe Rechenmodell.

Microsoft zufolge kann dieses Design Berechnungen beliebiger Länge unterstützen, indem es Teile beweist und zusammenfaltet. Das Unternehmen nennt außerdem langlaufende Ledger und Blockchains als mögliche Ziele.

Beliebige Länge bedeutet nicht konstante Kosten. Jemand muss die Berechnung weiterhin ausführen und jedes Beweissegment erzeugen. Rekursion verändert, wie Verifikation und Aggregation skalieren, beseitigt die Beweisarbeit jedoch nicht.

Der Mechanismus erklärt die berichtete Geschwindigkeit. Magnetar setzt Post-Quantum-Sicherheit nicht nachträglich auf ein bestehendes kurvenorientiertes Design. Es organisiert Prozessor, Commitments, Speicherargumente und Rekursion von Beginn an um bitfreundliche Operationen.

Das ist der stärkste Teil der Magnetar-zkVM als Engineering-Geschichte. Ihre Geschwindigkeits- und Sicherheitsansprüche ergeben sich aus derselben Designentscheidung statt aus zwei unabhängigen Optimierungen.

Die Benchmarks lassen wichtige Fragen offen

Magnetar hat den Forschungsvergleich verändert, aber noch keine Produktionsreife oder universelle Überlegenheit belegt.

Die erste Unsicherheit betrifft die unabhängige Validierung. Die verfügbaren Leistungswerte stammen von Microsoft Research und dessen technischem Paper. Externe Teams müssen diese Ergebnisse auf vergleichbarer Hardware, mit vergleichbaren Softwareversionen und Workload-Eingaben reproduzieren.

Auch die Auswahl der Benchmarks ist relevant. Fünfzehn Anwendungen liefern mehr Evidenz als ein einzelner synthetischer Test, repräsentieren aber nicht jede Produktions-Workload. Datenbankintensive Programme, große Interpreter, ungewöhnliche Speichermuster und dauerhaft betriebene Mehrbenutzerdienste können andere Engpässe offenlegen.

Der Zyklendurchsatz ist nur eine Kennzahl. Teams interessieren sich auch für maximalen Speicherverbrauch, Latenz der Beweiserzeugung, Startkosten, parallele Skalierung, Cloud-Effizienz und Wiederherstellung nach Fehlern. Diese Faktoren können die Wirtschaftlichkeit eines eingesetzten Provers dominieren.

Die Beweisgröße von 600 KiB verdient besondere Aufmerksamkeit. Sie ist kleiner als im Vergleich des Papers mit SP1 Hypercube, aber größer als die berichteten Jolt-Beweise. Anwendungen, die große Beweismengen veröffentlichen oder übertragen, müssen diesen Unterschied direkt bewerten.

Auch die Sprachunterstützung erfordert eine sorgfältige Interpretation. Rust, Go und C können zu RISC-V kompiliert werden, doch nicht jedes Sprachfeature, jede Bibliothek, jeder Betriebssystemaufruf oder jedes Laufzeitverhalten funktioniert automatisch innerhalb einer zkVM. Eine vertraute Quellsprache bedeutet keine uneingeschränkte Kompatibilität.

Entwickler benötigen dokumentierte Toolchains, Debugger, Profiling-Unterstützung, reproduzierbare Builds und klare Fehlermeldungen. Reife Compilerunterstützung hilft, doch die zkVM definiert weiterhin eine eingeschränkte Ausführungsumgebung.

Die Sicherheitsprüfung bleibt eine weitere Anforderung. Das Fundament von Magnetar hängt auf Ebene kryptografischer Annahmen möglicherweise nur von Standard-Hashes ab. Die Implementierung umfasst jedoch weiterhin ein Prozessormodell, Beweiscode, Compiler, Host-Schnittstellen und Anwendungslogik.

Ein Fehler in einer dieser Komponenten könnte zu einer falschen Aussage oder einer ausnutzbaren Integration führen. Konservative Primitive reduzieren eine Risikokategorie. Sie ersetzen keine Softwareabsicherung im Bereitstellungsplan.

Auch die Behauptung der Quantenresistenz braucht präzise Formulierungen. Microsoft erklärt, Magnetar vermeide elliptische Kurven und stütze sich auf Hash-Funktionen, die als resistent gegen bekannte Quantenangriffe gelten. Quantenalgorithmen können das effektive Sicherheitsniveau von Hashes dennoch beeinflussen, sodass die Parameterwahl diese Reduktion berücksichtigen muss.

Microsoft ordnet Magnetar in eine breitere Migrationsinitiative ein. Seine quantum-safe timeline sieht vor, Produkte und Dienste bis 2029 auf Post-Quantum-Kryptografie umzustellen. Magnetar passt zu dieser Richtung, doch die Forschungsankündigung macht es nicht zu einem bereitgestellten Microsoft-Dienst.

Die kommerzielle Verfügbarkeit bleibt daher eine wichtige offene Frage. Die Ankündigung beschreibt Forschungsergebnisse und lädt Organisationen dazu ein, Anwendungsfälle zu erörtern. Sie nennt weder einen Veröffentlichungstermin für die Produktion, noch eine Service-Level-Zusage oder eine umfassende Roadmap für die Bereitstellung.

Das Fehlen dieser Details schwächt das technische Ergebnis nicht. Es verändert, was Käufer daraus ableiten sollten. Magnetar setzt derzeit einen neuen Forschungsmaßstab, nicht einen schlüsselfertigen Ersatz für bestehende Beweisinfrastruktur.

Es gibt außerdem eine semantische Einschränkung, die alle Beweissysteme teilen. Magnetar kann beweisen, dass bestimmter Code mit festgelegten Eingaben ausgeführt wurde. Es kann nicht entscheiden, ob der Code die richtige Richtlinie abbildete oder ob eine Eingabequelle die Wahrheit sagte.

Man betrachte einen KI-Agenten, der die Einhaltung einer Genehmigungsregel beweist. Der Beweis kann zeigen, dass die Regel ausgeführt wurde. Er kann nicht zeigen, dass eine ausgelassene Regel die Aktion hätte blockieren müssen oder dass ein externer Datenfeed korrekt war.

Dasselbe gilt für Finanzanwendungen. Ein Beweis kann belegen, dass ein Transaktionsverarbeitungsprogramm codierten Einschränkungen folgte, ohne Transaktionsdetails offenzulegen. Aufsichtsbehörden und Gegenparteien müssen dennoch die Regeln, die Herkunft der Eingaben, Governance und Ausnahmebedingungen bewerten.

Diese Einschränkungen sollten die Einführung prägen. Beweisbasierte Datenverarbeitung ist am stärksten, wenn Aussage, Programm und Input-Commitments präzise definiert werden können. Sie ist schwächer, wenn Organisationen erwarten, dass Kryptografie mehrdeutige Richtlinien oder unzuverlässige Daten löst.

Drei Signale werden zeigen, ob Magnetar über die Forschung hinausgeht

Der nächste Test besteht darin, ob unabhängige Entwickler die Gewinne von Magnetar reproduzieren und in dauerhafte Anwendungen überführen können.

Das erste Signal sind öffentliche Implementierungsnachweise. Forschende und Entwickler benötigen genügend Code, Parameter, Benchmark-Eingaben und Build-Anweisungen, um den Bereich von 7,2 Millionen bis 8,7 Millionen Zyklen pro Sekunde zu reproduzieren.

Eine Reproduktion auf anderen Prozessoren würde Microsofts Leistungsargument stärken. Ergebnisse, die je nach Hardware- oder Speicherkonfiguration stark variieren, würden es einschränken. Vergleiche sollten außerdem gleichwertige Sicherheitsniveaus und Workload-Definitionen verwenden.

Dieses Detail ist wichtig, weil Benchmarks für Beweissysteme ungewöhnlich empfindlich auf Implementierungsentscheidungen reagieren. Eine Konfiguration kann für höheren Durchsatz Beweisgröße, Speicher, Sicherheit oder Vorverarbeitung eintauschen. Vergleichbare Bezeichnungen bedeuten nicht immer vergleichbare Garantien.

Das zweite Signal ist eine reale Anwendung, die von einem Team außerhalb der Forschungsgruppe gepflegt wird. Eine glaubwürdige Bereitstellung sollte gewöhnlichen Rust-, Go- oder C-Code verwenden und Beweise unter realistischen Betriebsbedingungen erzeugen.

Ein EVM-Interpreter wäre ein möglicher Test. Ein regulierter Datenverarbeitungs-Workflow oder eine Agent-Policy-Engine wäre ebenso aufschlussreich. Das stärkste Beispiel würde Latenz, Speichernutzung, Beweisgröße und Daten zu Betriebsfehlern veröffentlichen.

Eine solche Bereitstellung würde die Behauptung prüfen, dass beweisbasierte Allzweckdatenverarbeitung mit Magnetar spezialisierte Entwicklungsarbeit reduziert. Compiler-Kompatibilität, Debugging und Update-Verfahren sind ebenso wichtig wie der Benchmark-Durchsatz.

Das dritte Signal ist die Reaktion konkurrierender zkVM-Projekte. Jolt, SP1, RISC Zero und andere Teams können Microsofts Ergebnisse mit neuen Benchmarks, kleineren Beweisen, Hardwarebeschleunigung oder alternativen Sicherheitsanalysen in Frage stellen.

Eine Antwort, die sich nur auf die maximale Zahl von Zyklen pro Sekunde konzentriert, würde Magnetars Darstellung stärken. Eine Antwort, die niedrigere Gesamtkosten oder eine höhere Produktionszuverlässigkeit zeigt, könnte sie schwächen. Der Markt braucht Vergleiche, die die gesamte Proof-Pipeline abdecken.

Wettbewerber könnten zudem konservativere Komponenten einsetzen. Wenn Sicherheit auf Basis von Standard-Hashfunktionen zu einer Beschaffungsanforderung wird, müssen Projekte kompatible Modi anbieten oder erklären, warum ihre Annahmen eine akzeptable Alternative darstellen.

Die Arbeit von Microsoft könnte daher das zkVM-Design beeinflussen, selbst wenn sie nicht zur dominierenden Implementierung wird. Sie erhöht den erwarteten Mindeststandard dafür, Sicherheitsannahmen, Programmierkompatibilität und Rekursionskosten gemeinsam zu erläutern.

Entwickler sollten auf eine nutzbare Veröffentlichung, unabhängige Benchmark-Suites und Anwendungen achten, die mehr als Kryptowährungstransaktionen nachweisen. Solche Ereignisse würden zeigen, ob sich die Architektur über sorgfältig kontrollierte Forschungsworkloads hinaus verallgemeinern lässt.

Unternehmenskäufer sollten andere Fragen stellen. Welche genaue Aussage belegt der Proof? Welche Eingaben bleiben privat? Welche Annahmen schützen den Proof, und wie reagiert das System, falls sich diese Annahmen ändern?

Teams, die die Technologie bewerten, benötigen außerdem eine belastbare Dokumentation der Benchmark-Bedingungen und Sicherheitsentscheidungen. Eine durchsuchbare Engineering-Wissensdatenbank kann Papers, Testergebnisse, Implementierungsnotizen und Review-Erkenntnisse verknüpfen, ohne die Entscheidung auf eine einzige Schlagzeilenzahl zu reduzieren.

Proof-basierte Universalberechnung mit Magnetar hat bereits eine vertraute Annahme infrage gestellt: Konservative Post-Quantum-Sicherheit erfordert nicht zwangsläufig langsame, spezialisierte Programme. Der nächste Schritt ist die Überprüfung von Magnetar selbst. Können unabhängige Teams die Zahlen reproduzieren, gewöhnliche Anwendungen betreiben und die behauptete Sicherheit unter Produktionsdruck bewahren?