Wenn AI-Agenten On-Chain-Ausführungsrechte erhalten: Wer überprüft die Informationen, die sie sehen, und die Befehle, die sie ausgeben?

I. Was der KelpDAO-Vorfall offenbart hat

Am 18. April 2026 wurde die rsETH-Cross-Chain-Brücke von KelpDAO angegriffen, wobei 116.500 rsETH unrechtmäßig freigegeben wurden, was zum Zeitpunkt des Vorfalls etwa 292 Millionen US-Dollar wert war. Der Vorfallbericht von LayerZero zeigt, dass der Angreifer durch Social Engineering den Sitzungsschlüssel des Entwicklers erlangte, die interne RPC, auf die LayerZero Labs DVN angewiesen war, kompromittierte und durch einen Denial-of-Service-Angriff externe RPC unterdrückte, wodurch der Signaturdienst auf der Grundlage falscher Daten gefälschte Nachrichten bestätigte. KelpDAO hatte zu diesem Zeitpunkt den Verifizierungsweg von 2-of-2 auf 1-of-1 DVN geändert. Wenn der einzig benannte DVN einen falschen Nachweis erbringt, ist das System nicht mehr auf einen zweiten unabhängigen DVN angewiesen, um die gleiche Nachricht zu validieren. CrowdStrike und Mandiant haben den Vorfall mit hoher Zuversicht TraderTraitor (UNC4899), das mit Nordkorea in Verbindung steht, zugeordnet.

Diese Art von Vorfall ist kein Einzelfall. Viele bedeutende Sicherheitsvorfälle auf der Blockchain zeigen, dass die Probleme oft nicht darin liegen, dass die kryptographischen Annahmen selbst widerlegt werden, sondern in den Bereichen Schlüsselkontrolle, Datenquelle, Konfiguration der Validierer, Protokollimplementierung und Betriebsrechte. Das System muss nicht nur die Frage beantworten: „Ist diese Signatur gültig?“, sondern auch: „Wer hat das Recht zu signieren, auf welcher Grundlage wird signiert und ob der Zustand, auf den sich die Signatur bezieht, tatsächlich eingetreten ist?".

Immer mehr AI-Agenten erhalten On-Chain-Ausführungsfähigkeiten durch intelligente Konten, strategische Wallets oder eingeschränkte Signaturdienste. Eine gültige Signatur kann nur beweisen, dass ein bestimmter autorisierter Weg aufgerufen wurde, kann jedoch nicht garantieren, dass die Daten, auf denen der Agent basiert, zuverlässig sind, die Entscheidungen den festgelegten Strategien entsprechen oder dass diese Transaktion tatsächlich zu diesem Zeitpunkt hätte stattfinden sollen. Das Objekt der Validierung erweitert sich von „Echtheit der Signatur“ zu „Ob Eingaben, Entscheidungen und Ausführungen übereinstimmen".

II. Was bestehende Lösungen gelöst haben und was sie hinterlassen haben

Die bestehenden Lösungen haben jeweils einen Teil des Vertrauensproblems gelöst und das verbleibende Vertrauen auf unterschiedliche Rollen übertragen:

Orakel und Streitentscheidungen: Die Marktergebnisse von Polymarket werden zunächst von den Teilnehmern vorgeschlagen und gelangen nur dann in die Abstimmung der Tokeninhaber von UMA, wenn sie während der Anfechtungsfrist in Frage gestellt werden. Das Problem liegt nicht darin, dass es keine Überprüfung gibt, sondern darin, ob die Überprüfung zuverlässig ist. Wenn die Regeln vage sind, reale Ereignisse mehrere Interpretationen zulassen oder die Stimmrechte auf wenige Adressen konzentriert sind, überträgt das System tatsächlich die Frage „Wer definiert die Fakten?“ an eine andere Governance-Struktur.

Cross-Chain-Brücken-Multi-Signatur und DVN: Beide Implementierungsarten sind unterschiedlich, erfordern jedoch, dass die Anwendung die Validierergruppe und den Schwellenwert klar konfiguriert. Nachdem KelpDAO den Pfad auf 1-of-1 DVN konfiguriert hatte, hing der gesamte Verifizierungsweg von einem einzigen Validierungsdienst ab; die Datenquelle und die Fehlermanagementmechanismen, auf die dieser Dienst angewiesen ist, könnten jedoch einen weiteren Single Point of Failure bilden.

MPC-Hosting: Der Vorteil der Schwellenwertsignatur besteht darin, dass der Schlüssel nicht vollständig an einem Ort existiert, aber die kryptographische Fragmentierung führt nicht automatisch zu einer Machtverteilung auf organisatorischer Ebene. Laut dem Multichain-Team verlor das Team sofort den Zugriff auf die entsprechenden MPC-Knotenserver, nachdem der Gründer von der chinesischen Polizei festgenommen wurde; diese Server liefen unter dem persönlichen Cloud-Konto des Gründers. Wenn Cloud-Konten, Betriebsrechte und Notfallreaktionen in einer Person konzentriert sind, kann das Design der Schwellenwerte von MPC immer noch einen organisatorischen Single Point of Failure hinterlassen.

TEE: Eine vertrauenswürdige Ausführungsumgebung kann Code und sensible Daten isolieren, beseitigt jedoch nicht das Vertrauen, sondern verändert nur den Vertrauenspunkt. Hardware-Wurzelvertrauen und Mikrocodes-Updates hängen normalerweise von den Chip-Herstellern ab, während Enklave-Code, Upgrade-Rechte und Authentifizierungsrichtlinien möglicherweise von den Projekt- oder Betriebsführern kontrolliert werden. TEE kann den Berechnungsprozess schützen, kann jedoch diese Governance-Rechte nicht automatisch dezentralisieren.

Diese Lösungen haben unterschiedliche Fehlermuster, weisen jedoch auf dieselbe Art von Problemen hin: Die in den Whitepapers festgelegten Schwellenwerte und die Dezentralisierung müssen tatsächlich auf Datenquellen, Kontoberechtigungen, Upgrade-Schlüssel und Governance-Prozesse angewendet werden, um echte Sicherheitsgrenzen zu bilden.

III. CRVA: Neugestaltung der Verteilung von Verifizierungsrechten

DeepSafe wurde 2025 von Bool Network umbenannt. CRVA setzt die technische Denkweise fort, die Forscher von Bool Network 2022 vorgeschlagen haben. Die zugehörige Arbeit wurde in den IEEE Transactions on Information Forensics and Security (IEEE TIFS, Dokument-ID 9903072) veröffentlicht und schlägt eine Cross-Chain-Notarplattform vor, die auf einem „evolvierenden versteckten Komitee“ basiert.

Die spezifische Vorgehensweise besteht darin, dass Knoten durch Ring-VRF an einer zufälligen Auswahl teilnehmen, die Ausgewählten Nachweise und temporäre öffentliche Schlüssel einreichen, wobei externe Beobachter ihre Qualifikation überprüfen, jedoch schwer ihre langfristige Identität erkennen können. Das ausgewählte temporäre Komitee signiert dann gemeinsam durch Schwellenwert-MPC, wobei kein einzelner Knoten unabhängig Ergebnisse erzeugen kann. Schlüsselmanagement und andere kritische Prozesse laufen gemäß dem Entwurf der Arbeit in TEE (z. B. Intel SGX), um die Möglichkeit zu verringern, dass der Host-Betreiber Schlüsselanteile liest oder manipuliert. Das Komitee wird auch nach Epochs gewechselt, wobei die neue Gruppe durch überprüfbare Schlüsselübergaben neue Anteile erhält, während die alten Anteile ungültig werden; der spezifische Wechselzyklus wird durch die tatsächlichen Netzwerkparameter bestimmt.

Das Projektteam hofft auch, den Arbeitsstatus des versteckten Komitees durch TEE zu verbergen, sodass Knotenbetreiber schwer erkennen können, ob ihr Knoten an einer bestimmten Validierung teilgenommen hat. Inwieweit dieses Ziel erreicht werden kann, hängt von bestehendem Code, Fernzertifizierung, Host-Metadaten und Schutz vor Seitenkanälen ab; es ist nicht einfach zu sagen, dass „die Verwendung von TEE“ automatisch zu diesem Ergebnis führt.

Diese Mechanismen lösen jedoch die Fragen „Wer validiert und wie wird sicher gemeinsam ein Ergebnis erstellt?“, definieren jedoch nicht automatisch „Welches Ergebnis ist korrekt?“. Im Kontext von AI-Agenten muss das Komitee weiterhin auf der Grundlage vordefinierter Strategien, Datenquellen und ausführbarer Entscheidungsregeln zu Schlussfolgerungen kommen. Wenn diese Regeln selbst problematisch sind, die Datenquelle unzuverlässig ist oder das Validierungsobjekt keine objektiv feststellbare Antwort hat, kann selbst das sicherste Komitee zu einem falschen Schluss kommen.

CRVA versucht, die Risiken zu verringern, die sich aus der langfristigen Exposition fester Validierer und der Konzentration von Signaturrechten ergeben, kann jedoch nicht vollständig die Single Points of Failure auf Governance- und Implementierungsebene beseitigen. Der Zugang zu Knoten, Protokoll-Upgrades, TEE-Zertifizierungen und Software-Sicherheit müssen weiterhin regelmäßigen Audits unterzogen werden. Unter der Voraussetzung, dass alte Anteile zuverlässig ungültig werden und neue Komitees ausreichend unabhängig bleiben, kann der Wechsel das Angriffsfenster auf feste Signaturgruppen verkürzen, jedoch nicht systemische Risiken wie Software-Lieferketten oder Upgrade-Rechte abdecken.

IV. Technische Grundlagen und Fortschritte bei der Umsetzung

Die technische Entwicklung von CRVA lässt sich bis zu einem Artikel zurückverfolgen, der in Band 17 der IEEE TIFS (2022) veröffentlicht wurde, DOI 10.1109/TIFS.2022.3209546. Das Protokollmodell, die Sicherheitsnachweise und die Prototypbewertung in der Arbeit wurden einer Peer-Review unterzogen und bieten akademische Grundlagen für dynamische versteckte Komitees, Ring-VRF, Schwellenwert-Schlüsselmanagement und TEE-Schutz. Es ist wichtig zu unterscheiden, dass die Peer-Review sich auf die Modelle und Implementierungen in der Arbeit bezieht; wie die derzeit implementierte CRVA von DeepSafe mit dem in der Arbeit vorgeschlagenen Ansatz übereinstimmt, muss weiterhin anhand der aktuellen technischen Spezifikationen, Code-Audits und Netzwerkparameter beurteilt werden.

Laut DeepSafe wurden bis Oktober 2025 insgesamt fast 120 Millionen Validierungen verarbeitet, und es gab über 2,65 Millionen aktive Konten. Das Projektteam gab auch an, dass seine Ökosystembeziehungen über 70 umfassen, die verschiedene Arten von Wallet-Kompatibilität, technische Integration, Investitionen und Marktkooperationen betreffen.

Im Oktober 2025 gab DeepSafe bekannt, dass es eine Seed-Runde in Höhe von 3 Millionen US-Dollar abgeschlossen hat, an der Investoren wie Antalpha Global, ViaBTC Capital und Gate beteiligt sind. Zeitlich gesehen entspricht diese Finanzierungsrunde hauptsächlich der technischen Entwicklung und der Erweiterung des Ökosystems nach der Umbenennung.

V. Von Verifizierungslösungen zu universeller Infrastruktur

Mit der schrittweisen Modularisierung der Blockchain-Infrastruktur übernehmen Konsens, Ausführung, Datenverfügbarkeit, Interoperabilität und Kontosysteme unterschiedliche Komponenten. Die Modularisierung hat das Vertrauensproblem nicht beseitigt, sondern die Sicherheitsgrenzen jeder Ebene klarer gemacht. Entwickler müssen nicht nur entscheiden, welche Technologie sie verwenden, sondern auch beurteilen, wer die Sicherheitsgarantie für diese Ebene bereitstellt und wer im Falle von Problemen verantwortlich ist. Nachdem AI-Agenten On-Chain-Ausführungsfähigkeiten erhalten haben, treten neue Fragen auf: Wer bestätigt, dass die Daten, die sie lesen, vertrauenswürdig sind, dass die Entscheidungen nicht über das hinausgehen, was autorisiert ist, und dass die endgültige Transaktion mit der Benutzerautorisierung übereinstimmt? Diese Fragen werden nicht automatisch durch eine gültige Signatur beantwortet.

DeepSafe möchte die Validierungsfähigkeiten von einem internen Modul einer einzelnen Anwendung abstrahieren und als Infrastruktur bereitstellen, die von verschiedenen Protokollen und AI-Agenten aufgerufen werden kann – „Proof, Not Promises“, um überprüfbare Beweise anstelle von Versprechungen des Ausführenden zu verwenden. CRVA hat bereits anonyme Auswahlen, Schwellenwert-Kooperation und TEE zu einem technischen Ansatz kombiniert. Ob es weiter auf verschiedene Szenarien wie Orakel, Cross-Chain und AI-Agenten ausgeweitet werden kann und sich zu einer universellen Validierungsinfrastruktur entwickelt, hängt von den bestehenden Netzwerkfähigkeiten, unabhängigen Audits und der kontinuierlichen Integration in der Praxis ab.

Dieser Artikel stammt aus einem Beitrag und spiegelt nicht die Ansichten von BlockBeats wider.