Im Sommer 2026 klang die Frage noch sauber: Welches Verfahren setzt sich durch, um KI-Berechnungen on-chain beweisbar zu machen? zkML mit kryptografischen Beweisen, opML mit Betrugsbeweisen, TEE mit Hardware-Attestierung oder die krypto-\u00f6konomische Variante mit Einsatz und Slashing? Ende 2026 ist diese Frage \u00fcberholt. Niemand kauft opML mehr als Produkt. Man schaltet es als Modus zu, als eines von f\u00fcnf Backends hinter einer gemeinsamen Schnittstelle.<\/p>
Der Ausl\u00f6ser ist ein n\u00fcchternes St\u00fcck Ethereum-Standardisierung: ERC-8274<\/a>, ein Entwurf, der zkML, opML, TEE, Oracle-Netze und AVS-L\u00f6sungen hinter eine gemeinsame verify()-Funktion stellt. Das klingt technisch, und das ist es auch. Aber es ver\u00e4ndert, wie man opML \u00fcberhaupt betrachten sollte, und es wirft eine unbequeme Frage auf: Wenn jeder Beweis am Ende gleich aussieht, hei\u00dft das noch lange nicht, dass jeder Beweis dasselbe garantiert.<\/p> ERC-8274 tr\u00e4gt den Titel „AI Inference Proof Verification“ und wurde am 26. M\u00e4rz 2026 vom Pseudonym JimmyShi22 als Entwurf eingereicht (Pull Request #1771 im ERCs-Repository). Der Status ist bis heute Draft, also kein verabschiedeter Standard, sondern ein Vorschlag, \u00fcber den die Ethereum-Community diskutiert. Trotzdem ist er aufschlussreich, weil er ein Problem benennt, das 2026 real geworden ist, und weil er opML eine sehr bestimmte Rolle zuweist.<\/p> Das Problem hei\u00dft im Entwurf das „N mal M“-Integrationsproblem. Es gibt f\u00fcnf grundverschiedene Verfahren, eine KI-Berechnung beweisbar zu machen, und eine wachsende Zahl von Anwendungen, die so einen Beweis pr\u00fcfen wollen. Ohne gemeinsamen Standard muss jede Anwendung f\u00fcr jedes Verfahren einen eigenen Adapter schreiben. Bei f\u00fcnf Verfahren und vielen Konsumenten explodiert die Zahl der Integrationen. ERC-8274 l\u00f6st das, wie ERC-20 einst das Problem der Token gel\u00f6st hat: mit einer gemeinsamen Schnittstelle, gegen die alle bauen.<\/p> Konkret definiert der Entwurf zwei Schnittstellen. IProofVerifier verlangt eine Funktion verify(inputHash, outputHash, metadata, proof), die ein schlichtes true oder false zur\u00fcckgibt, dazu Angaben zu Name, Version und Beweisprofil. IVerificationMethod erg\u00e4nzt eine getVerifier()-Funktion und ein VerifierUpdated-Ereignis, damit ein Vertrag den hinterlegten Pr\u00fcfer austauschen kann. F\u00fcr opML bedeutet das eine stille Degradierung: Es ist nicht mehr der Ansatz, um den herum man seine Anwendung baut, sondern ein Wert, den eine Funktion zur\u00fcckgibt. Eines von f\u00fcnf. Austauschbar.<\/p> Bevor opML zum Steckmodul wird, lohnt der Blick darauf, was es eigentlich tut. Der Begriff steht f\u00fcr optimistic Machine Learning. Ein Knoten rechnet ein KI-Modell off-chain, ver\u00f6ffentlicht das Ergebnis und eine kryptografische Zusammenfassung (einen Merkle-Commitment) on-chain und erkl\u00e4rt es nach einem Einspruchsfenster f\u00fcr endg\u00fcltig, falls niemand widerspricht. Wer das Ergebnis anzweifelt, kann es mit einem Betrugsbeweis anfechten. Der Name ist kein Zufall: opML ist den Optimistic Rollups nachempfunden, die Arbitrum, Optimism und Base bekannt gemacht haben.<\/p> Das urspr\u00fcngliche opML-Paper<\/a> (arXiv 2401.17555, ver\u00f6ffentlicht Ende Januar 2024 vom Team hinter Hyper Oracle, dem heutigen Ora) beschreibt den Kern als ein interaktives Betrugsbeweis-Protokoll, das an die Optimistic-Rollup-Systeme erinnert. Die Idee ist \u00e4lter als die Rollups selbst: Sie geht auf Truebit<\/a> von Jason Teutsch und Christian Reitwiessner zur\u00fcck, das das Verifikationsspiel mit interaktiver Bisektion einf\u00fchrte. Bei einem Streit halbieren Ankl\u00e4ger und Verteidiger die Berechnung so lange, bis genau der eine Schritt gefunden ist, an dem sie sich uneinig sind; diesen Schritt f\u00fchrt die Kette in einer schlanken virtuellen Maschine selbst aus und entscheidet.<\/p> Technisch steckt hinter diesem Nachrechnen die Fraud Proof Virtual Machine. Im einphasigen Modus wird jeder Rechenschritt in einer eingeschr\u00e4nkten VM wiederholt, was einfach, aber langsam ist. Der mehrphasige Modus l\u00e4sst die unstrittige Berechnung nativ auf der GPU laufen und zieht nur den einen umstrittenen Mikroschritt in die VM, was die Komplexit\u00e4t des Merkle-Baums drastisch senkt. Oras eigene Benchmarks sprachen von Modell-Inferenz im Sekundenbereich und einem vollst\u00e4ndigen Anfechtungszyklus in Minuten, gemessen allerdings an kleinen Modellen im Testnetz, nicht unter realer Last.<\/p> Der Sicherheitsmodus lautet also: annehmen, dass das Ergebnis stimmt, und jedem erlauben, eine L\u00fcge anzufechten. Das funktioniert nur unter einer Bedingung, die man leicht \u00fcberliest: Mindestens ein ehrlicher W\u00e4chter muss die Berechnung nachrechnen und bereit sein, Einspruch einzulegen. Diese Bauweise teilt opML mit jeder optimistischen Konstruktion, und wie bei der Debatte dar\u00fcber, was einen echten Layer 2 ausmacht<\/a>, steckt der Teufel nicht im Marketing, sondern in der Frage, ob der Anfechtungspfad je wirklich benutzt wird.<\/p> ERC-8274 nennt die f\u00fcnf Verfahren beim Namen und ordnet jedem konkrete Projekte zu. Das ist n\u00fctzlich, weil es die Landschaft 2026 ehrlich abbildet: Es gibt nicht den einen Gewinner, sondern f\u00fcnf Familien mit je eigener Vertrauensannahme. Wer zkML sagt, meint kryptografische Gewissheit; wer TEE sagt, meint Vertrauen in einen Chiphersteller; wer opML sagt, meint \u00f6konomische Abschreckung plus einen wachsamen Dritten. Dieselbe verify()-Funktion, f\u00fcnf grundverschiedene Versprechen.<\/p>Was 2026 mit opML passiert ist<\/h2>
opML in einem Satz: optimistische KI mit Betrugsbeweisen<\/h2>
Die f\u00fcnf Backends hinter verify()<\/h2>