BlockBeats x Zhihu Web 4.0 Salon: Wenn KI-Agenten On-Chain-Berechtigungen übernehmen
BlockBeats x Zhihu Web 4.0 Salon: Wenn KI-Agenten On-Chain-Berechtigungen übernehmen
Die meisten Gespräche über Web 4.0 beginnen am falschen Ende.
Man fragt, ob Web 4.0 "der nächste Marketingzyklus" ist oder nur eine weitere Erzählung. Diese Fragen verfehlen die einzige, die für Krypto zählt:
Von wem und zu wem verschiebt sich die zugrunde liegende Berechtigungsebene des Internets?
Wenn wir dies auf einer historischen Achse darstellen, war die Richtung immer konstant:
- Web 1.0 war schreibgeschützt: Nutzer konsumierten Informationen, hatten aber wenig bis keine Schreibrechte.
- Web 2.0 führte Schreibrechte ein: Man konnte posten, hochladen, kommentieren und zusammenarbeiten, aber die Plattformen kontrollierten weitgehend Identität, Verbreitung und Daten.
- Web 3.0 verlagerte den Besitz von Berechtigungen: Mit Self-Custody können Nutzer private Schlüssel halten und Aktionen auf offenen Netzwerken direkt autorisieren.
- Web 4.0 dreht sich um delegierte Berechtigungen auf Maschinengeschwindigkeit: KI-Agenten werden zunehmend On-Chain in Ihrem Namen agieren, kontinuierlich, kontextbezogen und über viele Protokolle hinweg.
Dies ist nicht nur ein UI-Upgrade. Es ist eine Veränderung des Standard-"Betreibers" von On-Chain-Konten.
Der Kernwechsel: Von "Du unterschreibst" zu "Du delegierst"
In Web 3.0 ist die atomare Einheit der Macht der private Schlüssel: Wer unterschreiben kann, kann handeln.
In Web 4.0 wird die atomare Einheit zur richtliniengesteuerten Delegation:
- Sie definieren Ziele, Einschränkungen und Budgets.
- Ein KI-Agent entdeckt Routen, vergleicht Ergebnisse und führt Aktionen aus.
- Die Kette erzwingt, was der Agent tun darf, nicht was er tun will.
Deshalb werden On-Chain-Berechtigungen zum Schlachtfeld. Agenten werden nicht nur Trades "empfehlen" oder Märkte "zusammenfassen", sondern sie werden delegierte Autorität innehaben, um Positionen neu auszubalancieren, Belohnungen zu beanspruchen, Schulden zu verlängern, Liquidität zu überbrücken und Strategien zu rotieren.
Die Frage ist nicht, ob Agenten mit DeFi interagieren werden. Die Frage ist, ob ihre Autorität sein wird:
- Übermäßig weitreichend (eine Genehmigung löscht alles), oder
- Kompositorisch eingeschränkt (Agenten können handeln, aber nur innerhalb fester Grenzen).
Warum Krypto der erste Ort ist, an dem Web 4.0 Realität wird
Das traditionelle Finanzwesen hat bereits Delegation (Broker, Mandate, diskretionäre Konten), aber die Durchsetzung ist institutionell und langsam.
Blockchains sind anders: Delegation kann programmierbar, prüfbar und automatisch durchsetzbar sein.
Drei Krypto-Primitive machen Web 4.0 möglich:
1) Smart Accounts und Account Abstraction
Smart Contract Wallets ermöglichen es Ihnen, Regeln direkt in das Konto zu kodieren: Ausgabenlimits, Rollentrennung, Wiederherstellungslogik und mehrstufige Genehmigungen. Standards und Ökosysteme rund um Account Abstraction machen dies für Mainstream-Nutzer und Apps praktikabler. Für Hintergründe siehe EIP 4337 auf der Ethereum-Standardsite: Account Abstraction via Entry Point Contract specification.
2) Intent-basierte Ausführung
Anstatt eine bestimmte Transaktion zu signieren, können Nutzer (oder Agenten) eine Absicht äußern (z.B. "tausche, um diese Zielallokation mit einer maximalen Slippage von X zu erreichen"), und Solver konkurrieren darum, diese zu erfüllen. Dies passt natürlich zu Agenten, da Agenten in Zielen denken, nicht in Calldata. Ein nützlicher konzeptioneller Überblick findet sich im Bildungszentrum von Ethereum: Ethereum and account abstraction.
3) Berechtigungstoken: Genehmigungen, Permits und delegierte Ausgaben
DeFi läuft bereits auf delegierter Autorität: Token-Genehmigungen, Betreiberrollen und signaturbasierte Berechtigungen. Der Unterschied in Web 4.0 liegt in Volumen und Häufigkeit: Agenten werden häufiger mehr Berechtigungen anfordern, und Angreifer werden diese Berechtigungsflächen aggressiv ins Visier nehmen. Ein konkretes Beispiel für moderne Berechtigungstools in DeFi finden Sie in der Uniswap-Dokumentation zu Permit2.
Das neue Bedrohungsmodell: "Agent Rug" ist ein Berechtigungsfehler, kein KI-Fehler
Wenn Nutzer sich Sorgen machen, dass KI-Agenten "aus dem Ruder laufen", stellen sie sich oft vor, dass das Modell bösartig wird.
In der Praxis werden die meisten Ausfälle wie klassische Sicherheitsvorfälle aussehen – nur schneller:
- Zu allgemeine Genehmigungen: Der Agent erhält unbegrenzte Token-Ausgaben und eine einzelne kompromittierte Abhängigkeit leert die Gelder.
- Prompt Injection und Tool Hijacking: Ein Angreifer manipuliert die Eingaben des Agenten, sodass er den falschen Vertrag aufruft oder die falsche Nachricht signiert.
- Bösartige Weiterleitung: Der Agent wählt eine Route, die für die Gegenpartei (oder den Solver) profitabel, aber für den Benutzer schädlich ist.
- Schlüsselsexfiltration: Die Agenten-Hostmaschine leakt Schlüssel oder Sitzungsgeheimnisse.
- Stille Berechtigungsdrift: Kleine "temporäre" Berechtigungen sammeln sich an, bis die effektive Autorität nahezu vollständig ist.
Die Lösung ist also nicht "vertraue der KI mehr". Die Lösung ist: Mache Berechtigungen kleiner als Vertrauen.
Eine praktische Web 4.0 Checkliste: Der Agent-Berechtigungsstapel
Wenn ein KI-Agent On-Chain ausführen soll, wünschen Sie sich einen geschichteten Stapel, der die "Vertrauensbasis" außer Reichweite hält.
Ebene 1: Root-Custody (menschengesteuert)
- Langfristige Schlüssel offline und bestätigungsbasiert aufbewahren.
- Eine Hardware-Wallet als Root-Signierer für risikoreiche Aktionen verwenden (neue Delegierte, große Überweisungen, Vertrags-Upgrades).
Ebene 2: Delegation (agentengesteuert, aber eingeschränkt)
Anstatt einem Agenten Ihren Hauptschlüssel zu übergeben, delegieren Sie eng begrenzte Autorität:
- Sitzungsschlüssel mit Ablaufdatum
- Allowlists (spezifische Verträge, spezifische Token-Paare)
- Ausgabenlimits (pro Stunde, pro Tag, pro Strategie)
- Time Locks für sensible Änderungen (wie das Erhöhen von Limits)
- Rollentrennung: Ein Schlüssel schlägt vor, ein anderer Schlüssel führt aus
Ebene 3: Ausführungssicherheit (vor der Kette)
- Transaktionssimulation und lesbare Risikozusammenfassungen
- Slippage-Caps und MEV-aware Routing-Beschränkungen
- Ein Notfall-"Kill Switch", der Delegierte schnell widerruft
Ebene 4: Auditierbarkeit (nach der Kette)
- Kontinuierliche Überwachung von Genehmigungen und Delegierten
- Regelmäßiges Bereinigungsmanagement von Berechtigungen
- Post-Trade-Verifizierung gegen Richtlinien
Für Nutzer ist die einfachste Gewohnheit, die sich sofort auszahlt, Berechtigungshygiene: Überprüfen und widerrufen Sie periodisch Genehmigungen, die Ihnen nicht mehr dienen. Ein weit verbreitetes öffentliches Tool ist Revoke.cash, das Ihnen hilft, Token-Allowances zu inspizieren und zu entfernen.
Was "Web 4.0 Identität" wirklich bedeutet: Das Konto wird zum Team
In Web 2.0 ist "Identität" ein Login.
In Web 3.0 ist Identität ein Konto.
In Web 4.0 wird Ihr Konto zu einem Team von Akteuren:
- Sie (Root-Autorität)
- Ein oder mehrere KI-Agenten (delegierte Betreiber)
- Automatisierungen (Timer, Keeper, Rebalancer)
- Protokollrollen (Vault Manager, Vertragsstrategien)
Das ist leistungsstark – weil es Ihre On-Chain-Operationen skaliert –, aber es bedeutet auch, dass sich Ihr Sicherheitsmodell von entwickeln muss:
"Schütze meinen privaten Schlüssel"
zu:
"Verwalte kontinuierlich einen Graphen von Berechtigungen"
Dies ist die mentale Verschiebung, die viele Nutzer im Jahr 2025 und darüber hinaus benötigen werden: Die größten Risiken werden nicht von einem einzelnen gestohlenen Schlüssel ausgehen, sondern von der Verbreitung von Berechtigungen über Ketten, Apps und Agenten hinweg.
Wohin das im Jahr 2025 geht: Von Wallets zu Richtlinien-Engines
Im Jahr 2025 laufen die Nutzeranforderungen auf einige nicht verhandelbare Punkte hinaus:
- Weniger blinde Signaturen, mehr menschenlesbare Absichten und Simulationen
- Sicherere Delegation (begrenzt, ablaufend, widerrufbar)
- Kettenübergreifende Erlebnisse ohne Verlust von Self-Custody-Garantien
- Datenschutzorientierte Agenten, die standardmäßig keine Portfolio- und Verhaltensdaten lecken
Das Wallet-Erlebnis wird zunehmend wie eine Richtlinien-Engine aussehen: nicht nur "senden" und "tauschen", sondern "wer darf was tun, wie lange, unter welchen Einschränkungen".
Warum das für OneKey-Nutzer wichtig ist (und für jeden, der Self-Custody betreibt)
Wenn Web 4.0 darum geht, dass KI-Agenten delegierte Macht innehaben, dann ist das wichtigste Designprinzip:
Halten Sie den Root-Schlüssel für nicht umkehrbare Entscheidungen unter direkter menschlicher Kontrolle.
Hier passt eine Hardware-Wallet-Konfiguration sauber auf den Web 4.0 Berechtigungsstapel:
- Verwenden Sie eine Hardware-Wallet als Root-Autorität für das Hinzufügen oder Austauschen von Agenten-Delegierten
- Lassen Sie Agenten mit begrenzten Sitzungsberechtigungen agieren, nicht mit permanenter voller Zugriffsberechtigung
- Bestätigen Sie wirkungsvolle Änderungen (Limit-Erhöhungen, neue Vertrags-Allowlists, große Überweisungen) auf einem vertrauenswürdigen Signaturgerät
Die Positionierung von OneKey in diesem Kontext ist unkompliziert: Eine Hardware-Wallet ist nicht "Anti-Agent"; sie ist die Art und Weise, wie Sie Agenten nutzbar machen, ohne Delegation in Kapitulation zu verwandeln.
Abschluss: Web 4.0 ist eine Berechtigungs-Migration
Web 4.0 ist keine Parole. Es ist eine Migration operativer Macht:
- von Plattformen zu Nutzern (Web 3.0),
- und von Nutzern zu ihrer delegierten Software (Web 4.0).
Die Gewinner werden nicht die lautesten Erzähler sein. Es werden die Teams sein, die die beste Berechtigungsminimierung, Delegationsstandards und Ausfallschutz-Wiederherstellung bauen – damit KI-Agenten im großen Stil agieren können, ohne Self-Custody in selbstverschuldete Risiken zu verwandeln.
Wenn Sie einen Satz aus diesem Veranstaltungsthema behalten möchten, machen Sie ihn zu diesem:
In Web 4.0 geht es bei Sicherheit nicht mehr um einen Schlüssel; es geht um die Grenzen, die Sie um jede delegierte Aktion ziehen.
