Lustige Sache ist letzte Woche passiert: Ich habe einen Arbeitslaptop zurückgesetzt, der nach einem BIOS-Update ständig beim Secure Boot scheiterte. Irgendeine Einstellung war umgesprungen, und die Maschine weigerte sich, ihrer eigenen Firmware zu vertrauen, bis ich sie manuell wieder aktiviert habe. Ich brauchte zwanzig Minuten Googeln, um überhaupt zu verstehen, was „measured boot“ bedeutet. Und natürlich hat mein Gehirn offenbar keine Fähigkeit mehr, sich ordentlich zu sortieren: Durch diese Umleitung bin ich direkt wieder in die Doku von Newton Protocol zurückgesprungen – in den Abschnitt, den ich bei jeder früheren Gelegenheit einfach überflogen hatte: die Oracle Adapter Layer.
Newtons Pitch, den ich in jedem Stück, das ich dazu schreibe, immer wieder wiederhole, ist: Vertrauen wird durch Beweise ersetzt. Richtlinien werden überprüft, überprüfte Ergebnisse werden signiert, Signaturen werden aggregiert, und das Ganze hängt von keinem einzelnen Akteur ab, an den man glauben müsste. Darin liegt der Reiz. Außer der Oracle Adapter Layer – dem Bauteil, das Echtzeitdaten von On-Chain- und Off-Chain-Quellen in diese Richtlinienevaluierungen einspeist – läuft innerhalb einer Trusted Execution Environment. Und eine TEE ist, wie auch immer man sie anpreist, eine Wette auf einen Chip.
So heißt das eigentlich, wenn man es sich auf den Punkt vor Augen führt. Eine TEE ist eine hardwareisolierte Enklave – etwas in der Art von Intels oder AMDs sicheren Prozessoren. Sie verspricht, dass Code und Daten darin privat und unmanipuliert bleiben – selbst gegenüber dem Betriebssystem, das daneben läuft. Das weist sie über Remote Attestation nach, im Grunde indem der Chip eine Quittung signiert, auf der steht: „Ja, genau dieser Code lief unverändert in mir.“ Das ist eine wirklich nützliche Grundfunktion. Und darunter, jenseits der Kryptografie, steckt trotzdem ein Versprechen des Hardwareherstellers: Du vertraust Intels oder AMDs Fertigungsprozess, deren Firmware, deren Microcode-Patches – in demselben Atemzug, in dem du behauptest, das System sei trustless.
Diese Lücke ist nicht hypothetisch. TEEs haben eine echte Geschichte von Side-Channel-Angriffen: Methoden, um zu erschließen, was in der „Black Box“ passiert, indem man von außen Leistungsaufnahme oder Ausführungszeiten beobachtet. Dazu kommen ganz offenliegende Schwachstellen, für die Notfall-Patches nötig waren. Keines davon macht TEEs unbrauchbar. Es bedeutet nur: Die ehrliche Beschreibung einer TEE-gesicherten Oracle-Layer lautet „kryptografisch verifiziert, abhängig davon, dass die Hardware, die ich nicht selbst gebaut habe, korrekt funktioniert“ – nicht „trustless“.
Was ich wirklich interessant fand, ist: Das ist nicht einzigartig für Newton, und es ist auch keine Kritik, die ausschließlich Newton betrifft. Es ist eine Spannung, die gerade branchenweit existiert. Die sorgfältiger geplanten Projekte, die TEEs für Oracle-Arbeit einsetzen, sagen explizit, dass sich auf einen einzigen Enklaventyps eines einzelnen Anbieters zu verlassen ein echtes Risiko ist. Und die Abmilderung lautet nicht „vertrau dem Chip noch mehr“, sondern: Dezentralisierung über verschiedene Hardware-Anbieter und Node-Operatoren hinweg, damit keine einzelne Schwachstelle den gesamten Feed kompromittieren kann. Und das wirft die naheliegende Frage auf, auf die ich keine saubere Antwort finden konnte: Diversifiziert die Oracle Adapter Layer von Newton über TEE-Anbieter und Node-Operatoren – oder stützt sie sich derzeit auf eine einzelne Hardware-Annahme unter einer Policy-Engine, die damit beworben wird, genau solche Art von Single Point of Trust zu entfernen?
Vielleicht ist das in Ordnung. Vielleicht ist die tatsächlich gemachte Behauptung enger als das Marketing: „verifizierbar“ bedeutet Beweise dafür, dass die Ausgaben auf dem Weg und bei der Speicherung nicht manipuliert wurden – kein Versprechen, dass die zugrunde liegende Hardware nicht kompromittierbar ist. Das ist eine nachvollziehbare Sache, auf der man aufbauen kann. Es ist nur etwas anderes als das, was „trustless automation“ bei jemandem, der es schnell liest, typischerweise impliziert.
Ich glaube nicht, dass Newton hier unehrlich ist. Ich denke, die gesamte Branche hat diesen Kompromiss aus TEEs allgemein übernommen, und niemand möchte derjenige sein, der sagen muss: Das trustless System hat immer noch den Namen eines Herstellers an einem Teil davon hängen.
Weiß eigentlich irgendjemand, wie viele unabhängige Hardware-Anbieter hinter Newtons Oracle-Attestierungen derzeit stehen, oder ist das immer noch ein einzelner Punkt, der still und leise unter einem System ruht, das doch genau Single Points entfernen soll?