Habt ihr in den letzten Tagen den kleinen Aufsatz über Newton Protocol gesehen? Deren wichtigster Verkaufsschlager, den sie in letzter Zeit ständig betonen, lautet: angeblich eine „dezentrale, verifizierbare Automatisierungsschicht“. Klingt das nicht besonders hart, besonders Web3?
Ich habe da eine Gewohnheit: Sobald ich solche hochtrabenden Begriffe sehe, will ich sofort an die zugrunde liegende technische Architektur heran. Also habe ich mich durch deren Entwicklungspapiere durchgearbeitet und alles einmal nachverfolgt – und dann war ich direkt baff. Da stimmt nämlich ein grundlegender Logik-Zirkel nicht: Newton ruft doch jeden Tag nach Dezentralisierung, aber die darunterliegende TEE (Trusted Execution Environment, vertrauenswürdige Ausführungsumgebung) läuft komplett auf AWS (Amazon Web Services). Das heißt: Du denkst, du vertraust der Blockchain – tatsächlich gibst du am Ende alle Sicherheits-Keys an Amazon ab.
Heute sprechen wir ganz ohne Branchenbrille, in ganz normalen Worten darüber, wie viel „Schmu“ in dieser angeblichen „dezentralisierten Automatisierung“ steckt.
Erstens: Was „verifizierbar“ genannt wird, hängt im letzten Schritt sogar davon ab, wie Amazon drauf ist.
Zuerst müssen alle den Grundgedanken von TEE verstehen. Der Code ist tatsächlich unveränderbar, und die generierten Beweisdateien lassen sich auch tatsächlich auf die Kette hochladen, um sie zu verifizieren – das klingt erst mal plausibel. Aber das Problem ist: Bei Newton läuft das verwendete TEE in den AWS Nitro Enclaves von Amazon, und der entfernte/weitreichende Beweis, der am Ende herauskommt, wird von AWS ausgestellt!
Was bedeutet das?
AWS muss das anerkennen – erst dann gilt deine Verifikation.
Wenn AWS es nicht anerkennt – oder wenn es aus bestimmten Gründen angewiesen wird, es nicht anzuerkennen – werden deine automatisierten Aktionen direkt zu einem Witz.
Ist das nicht ganz klar eine „Verschiebung des Vertrauens“? Du überträgst nur dein Vertrauen in das Projektteam auf den größten traditionellen Internet-Giganten der Welt – Amazon. Wenn das auch Dezentralisierung heißen soll, dann lasst doch alle das Spielen mit der Chain sein und entwickelt einfach mit den Web2-Servern weiter.
Zweitens: Wenn es zu höherer Gewalt kommt, hat Newton überhaupt keinen Plan B.
Noch besorgniserregender ist, dass ich in den offiziellen technischen Unterlagen regelrecht alles durchsucht habe und nirgends Beschreibungen zu „alternativen Hardware-Lösungen“ oder zu Mechanismen für Multi-Cloud-Resilienz/Outage-Protection gefunden habe.
Das ist keine unnötige Sorge von mir. Leute, die Technik machen, wissen: Eine Architektur mit so starker Abhängigkeit von nur einem Anbieter – das Risiko lässt sich nicht durch Code lösen, sondern wird durch die dahinterliegenden wirtschaftlichen Interessen oder durch externe geopolitische Entscheidungen bestimmt.
Angenommen, in einem extremen Szenario: > An einem bestimmten Tag verlangt die US-Regierung aufgrund von Compliance-Richtlinien oder irgendeiner Art höherer Gewalt, dass AWS bei einer Überprüfung mitmacht. AWS braucht nur einmal die Hand zu heben und die Ausstellung aller TEE-Beweise zu stoppen, die auf Nitro Enclaves laufen – und die Verifizierungsfähigkeit des gesamten Newton-Netzwerks liegt im Handumdrehen komplett lahm.
Angesichts solcher äußerst zerstörerischer Black-Swan-Ereignisse scheint es für das Projektteam derzeit offenbar keinerlei Notfallplan zu geben.
Jemand wird vielleicht einwenden und widersprechen: „Aber wenigstens sorgt TEE-Hardware-Isolation dafür, dass man nicht komplett vom Projektteam mit Black-Box-Aktionen abhängig ist, oder?“
Man kann das nicht so sagen. Wenn du den Vertrauensanker vom Projektteam an Amazon übergibst, tauschst du de facto gegen ein riesiges Ding, das du viel weniger verstehst und das du noch weniger kontrollieren kannst. Die internen Betriebsstrategien von AWS, Compliance-Standards und sogar die Ausfallhistorie – als normaler Nutzer hast du davon praktisch keine Ahnung. Wie oft gab es in der Internetgeschichte große, flächendeckende Ausfälle bei AWS? Und bei welchem dieser Ausfälle ist nicht gleich mit mehreren hundert Diensten, die von AWS abhängen, alles auf einmal stillgelegt worden? Sobald AWS ausfällt, können TEE-Beweise gar nicht erst erzeugt werden, und deine automatisierten Strategien bleiben auf halber Strecke direkt stecken – in einer Sackgasse aus „hin und zurück“.
Drittens: Die Vertrauenskette ist viel zu lang – dazwischen wird alles zu den „Hardware-Matroschkas“ eines US-Unternehmens.
Du glaubst, du müsstest nur Amazon vertrauen – das war’s? Wenn wir diese TEE-Vertrauensketten einmal genau auseinandernehmen, wirst du sehen, dass da eine „Matroschka“-Kette drinsteckt, die einen wirklich gruseln kann.
Die zentrale Sicherheit der TEE-Hardware hängt letztlich von den Root-Schlüsseln ab, die vom Chip-Hersteller ab Werk injiziert werden. Aktuell sind die gängigen Hardwareplattformen Intel (Intel) und AMD. Also, wenn wir eine sogenannte „verifizierbare automatisierte Transaktion“ durchführen wollen, dann ist der tatsächliche Vertrauenspfad im Grunde dieser:
Schritt 1: Deine automatischen Trading-Befehle werden an das Newton-Protokoll übergeben.
Schritt 2: Newton lässt die Strategie in den Cloud-Servern von AWS laufen.
Schritt 3: Die TEE-Ausführungsumgebung von AWS hängt von Hardware-Schlüsseln der Intel- oder AMD-Chips ab, um die Verschlüsselungstrennung vorzunehmen.
Schritt 4: Nach Abschluss wird der weitreichende Beweis vom AWS-Compliance-System ausgestellt.
Schritt 5: Der Beweis wird zurück zur Newton-Chain gesendet und die finale On-Chain-Verifikation wird abgeschlossen.
Lasst uns zählen: Das sind ganze fünf Vertrauensebenen. Nur die letzte Ebene – also der Schritt, bei dem die Verifikation on-chain erfolgt – ist auf der Blockchain öffentlich und transparent. Die ersten vier Ebenen (Newton-Knoten, AWS-Cloud-Plattform, Intel-Chips, AMD-Chips) sind allesamt zu 100 % zentralisierte Entitäten. Nach einigem Hin und Her wechseln wir nicht nur von „Vertrauen in das Newton-Team“ zu „Vertrauen in Amazon + Intel + AMD“. Ist das für eine Krypto-Community, die Dezentralisierung anstrebt, wirklich eine Verbesserung im Erleben?
Viertens: Das „Zukunft wird übergehen“ klingt eher nach einer weit entfernten, endlosen Wunschvorstellung.
Eigentlich haben das in der Community schon sehr früh ein paar ältere Hasen herausgefunden und das Projektteam damit konfrontiert: „Wenn Newton sich doch als dezentralisierte, automatisierte Schicht vermarktet – warum baut ihr dann nicht selbst einen verteilten TEE-physikalischen Hardware-Cluster auf, statt euch die Arbeit zu sparen und auf AWS zu setzen?“
Damals lautete die offizielle Antwort sinngemäß: „Für die Effizienz in der frühen Entwicklungs- und Betriebsphase haben wir zunächst eine Lösung mit etablierten Cloud-Anbietern gewählt. In Zukunft werden wir schrittweise zu einem vollständig dezentralisierten physischen Hardware-Netzwerk übergehen.“
Das ist wirklich spannend. „Wie weit“ ist die „Zukunft“ überhaupt? Drei Monate, ein Jahr – oder bis das Projekt nicht mehr weiterläuft und man es erst dann merkt? In seinem öffentlichen offiziellen Roadmap-Dokument hat Newton für diese entscheidend wichtige „Hardware-Dezentralisierungs-Übergangsphase“ nicht einmal konkrete Meilenstein-Zeitpunkte notiert. Das heißt: Bis dahin bleibt die entscheidende Tür, durch die jede einzelne „verifizierbare Strategie“, die gerade im Netzwerk läuft und groß beworben wird, am Ende geht, fest in der Hand eines zentralisierten Großkonzerns.
Zusammenfassung
Ein Netzwerk, das sich mit lauter Worten als dezentral bezeichnet, dessen zentralstes automatisiertes Verifizierungsmodul aber auf dem größten zentralisierten Cloud-Server der Welt läuft – das ist an sich schon eine riesige Ironie.
TEE ist in der Tat eine gute Technologie und sehr nützlich für Privacy Computing. Aber man muss sich darüber im Klaren sein: TEE löst als Technik an sich das Web3-„Trustless/Ent-Trust“-Problem nicht. Es verlagert nur unser Vertrauen von „Menschen“ auf „Hardware-Giganten“ und „Cloud-Dienstanbieter“. Wenn du den Krypto-Space nur wegen absoluter Kontrolle und Schutz gegen Zensur spielst, ist die aktuelle, stark auf AWS angewiesene technische Architektur von Newton für dich eine nicht zu ignorierende Schwachstelle.
(Dieser Artikel ist eine Plattformaufgabe und stellt keine Anlageberatung dar.)