Nach mehreren DeFi-Angriffen im April verschiebt sich die Sicherheitsdebatte in der dezentralen Finanzbranche deutlich. Früher wurden DeFi-Protokolle am häufigsten daraufhin geprüft, ob ihre Smart Contracts auditiert wurden und ob es Schwachstellen im Code gab; Andre Cronje, Mitgründer von Flying Tulip, sagte jedoch in einem kürzlichen Cointelegraph-Interview, dass viele der Risiken bei heutigen DeFi-Protokollen nicht nur im On-Chain-Code liegen, sondern aus Upgrade-Berechtigungen, Multi-Sig-Governance, Off-Chain-Infrastruktur und den Team-Betriebsabläufen stammen.
DeFi ist nicht mehr nur nicht veränderbarer Code
Cronje stellte klar, dass, wenn man die strengen frühen DeFi-Definitionen von „dezentral, unveränderlich, vertrauensfrei“ zugrunde legt, viele aktuelle Protokolle eigentlich nicht länger als reines DeFi bezeichnet werden können. Sogar Flying Tulip ordnete er in dieses Urteil ein und sagte, die Branche ähnele heute eher von Teams betriebenen gewinnorientierten Finanzdienstleistungen als vollständig unveränderlicher öffentlicher Finanzinfrastruktur.
Er sagte: „Ich glaube, dass das, was wir heute haben, einschließlich Flying Tulip, kein DeFi mehr ist. Es ist weder dezentrale Finanzwirtschaft noch nicht manipulierbarer Code, sondern ein gewinnorientiertes Geschäft, das von einem Team betrieben wird.“
Diese Aussage verdeutlicht die unangenehmste Realität der DeFi-Industrie: Viele Protokolle nutzen weiterhin die Erzählung, Bewertungslogik und Marken-Sprache von DeFi, verlassen sich in der Praxis aber längst auf massiven menschlichen Einfluss und Off-Chain-Prozesse.
Das größte Risiko von DeFi ist nicht mehr nur ein Vertrags-Fehler
Cronje ist der Ansicht, dass das Sicherheitsmodell des frühen DeFi vergleichsweise einfach war: Nach der Bereitstellung ist der Smart Contract unveränderlich, und Nutzer tragen vor allem das Risiko der Code-Logik. Heutzutage sind DeFi-Systeme jedoch oft deutlich komplexer. Ein Protokoll kann zum Beispiel Proxy-Upgrades für Vertragsänderungen nutzen, kritische Berechtigungen über ein Multisig verwalten, sich auf externe Infrastruktur-Anbieter stützen und im Ernstfall von einem Kernteam durch Krisenmanagement abgefangen werden.
Das bedeutet, dass Sicherheitsprobleme sich von „Gibt es Bugs im Code?“ zu „Wer hat die Berechtigung zum Upgraden des Contracts?“, „Wer kontrolliert das Multisig?“, „Reicht das Time-Lock aus?“, „Können Off-Chain-Server oder Management-Oberflächen angegriffen werden?“, „Kann das Team in Ausnahmefällen korrekt reagieren?“ ausgeweitet haben.
Cronje weist darauf hin, dass die Branche in der Vergangenheit weiterhin zu stark den Fokus auf Smart-Contract-Audits gelegt habe, während viele jüngste Angriffe inzwischen eher traditionellen Web2- oder TradFi-Sicherheitsproblemen ähneln. Dazu zählen etwa ein Eindringen in Zugriffsrechte der Infrastruktur, Social-Engineering-Angriffe, die missbräuchliche Nutzung von Management-Prozessen oder das Kompromittieren eines einzelnen, zentralen Berechtigungsknotens.
Kurz gesagt: DeFi braucht zwar weiterhin Audits, aber nur Audits reichen nicht mehr aus. Wenn ein Protokoll upgradebar, verwaltbar und von Menschen beeinflussbar ist, muss es anerkennen, dass es auch Betriebsrisiken trägt, wie sie traditionelle Finanzinstitutionen haben.
Flying Tulip ergänzt einen Withdrawal Circuit Breaker
Vor diesem Hintergrund hat Flying Tulip kürzlich einen Withdrawal-Circuit-Breaker-Mechanismus (withdrawal circuit breaker) hinzugefügt. Damit kann das Protokoll, wenn es einen ungewöhnlichen Abfluss von Mitteln erkennt, Abhebungen verzögern oder in eine Warteschlange einreihen. Cronje betonte, dass dieser Mechanismus nicht dazu gedacht ist, Abhebungen dauerhaft zu verhindern, noch um das Team Mittel nach Belieben einzufrieren. Er verschaffe dem Protokoll vielmehr bei Anomalien ein kurzes Zeitfenster zur Reaktion.
Am Beispiel von Flying Tulip könne dieser Mechanismus dem Team etwa 6 Stunden Zeit verschaffen. Cronje ist der Meinung, dass das bei kleineren Teams und weniger global verteilten Mitgliedern eher 12 bis 24 Stunden, oder sogar länger, dauern könnte, um nach dem Angriff interne Bestätigungen, Signaturen und das Vorgehen zur Abwehr abzuschließen.
Die Logik solcher Designs ähnelt stark dem traditionellen Finanzmarkt: Wenn es zu ungewöhnlicher Liquidität oder zum Abfluss von Vermögenswerten kommt, werden nicht sofort alle Transaktionen für ungültig erklärt. Stattdessen wird das System erst einmal abgebremst, um zu verhindern, dass Angreifer in wenigen Minuten sämtliche Gelder abziehen.
Cronje betonte jedoch auch, dass der Circuit-Breaker nur ein Baustein in einem mehrschichtigen Sicherheitskonzept sein kann und nicht als Allheilmittel betrachtet werden darf. Echte Absicherung muss weiterhin Audits, dezentrale Multi-Sigs, Time-Locks, Governance-Prozesse, Monitoring sowie die Kontrolle von Berechtigungen umfassen.
Der Preis des Circuit Breakers: Schutz der Nutzer oder die Schaffung neuer zentralisierter Hintertüren?
Dennoch löst der Circuit-Breaker in der DeFi-Entwickler-Community sofort eine Richtungsdebatte aus. Curve Finance und Yield Basis-Gründer Michael Egorov stimmen zu, dass die jüngsten Angriffe tatsächlich Off-Chain-Zentralisierungsrisiken offengelegt haben, stehen aber der Lösung „mehr menschliche Notfallkontrolle“ mit großer Skepsis gegenüber.
Egorov sagte, viele der jüngsten großen DeFi-Vorfälle seien nicht deshalb passiert, weil der Smart Contract selbst geknackt wurde, sondern wegen eines Off-Chain-Single-Point-of-Failure. Er nannte als Beispiel rsETH-bezogene Ereignisse und erklärte, dass die Smart Contracts von Aave, Kelp und LayerZero nicht angegriffen worden seien; das eigentliche Problem liege in der Off-Chain-Infrastruktur.
Daher sieht Egorov es so: Wenn das größte Risiko ohnehin von Menschen und Off-Chain-Berechtigungen ausgeht, könnte ein zusätzlicher, von Menschen kontrollierter Circuit-Breaker lediglich dazu führen, dass noch mehr Macht bei einer kleinen Zahl von Signern oder Administratoren gebündelt wird.
Egorov befürchtet, dass, wenn Notfallkontrollrechte es Signern erlauben, den Smart Contract zu ändern, Abhebungen zu pausieren oder in den Geldfluss einzugreifen, der Mechanismus, der ursprünglich zur Absicherung der Nutzer gedacht war, im Fall eines Angriffs auf die Signer möglicherweise zum Werkzeug wird, mit dem Hacker Gelder abziehen, oder zu einer Hintertür für zentralisierte Vermögenssperren. Sein Fazit lautet: DeFi-Design sollte so wenig wie möglich menschliche Single-Points-of-Failure enthalten, statt das durch mehr menschliche Rechte verursachte Problem mit weiteren menschlichen Rechten zu lösen.
DeFi muss anerkennen, was es geworden ist
Die Differenzen zwischen Cronje und Egorov wirken auf den ersten Blick wie eine Debatte über Circuit-Breaker-Mechanismen. In Wirklichkeit ist es jedoch ein Streit um die Identität von DeFi. Cronjes Position ist stärker realistisch: Wenn viele Protokolle bereits keine unveränderlichen Contracts mehr sind, sondern Finanzprodukte mit Upgrade-Berechtigungen, Management-Prozessen und Team-Betrieb, dann sollte man diese Realität anerkennen und entsprechendere Risiko-Kontrollmaßnahmen einführen.
Egorov steht näher an den DeFi-„Urgrundsätzen“: Wenn die Sicherheit von DeFi aus Dezentralisierung kommt, dann darf die Lösung nicht darin bestehen, mehr Kontrolle an Menschen zu geben, sondern in Systemen, die weniger auf manuellen Eingriff angewiesen sind.
Beide erkennen im Grunde dasselbe an: Das größte Problem von DeFi ist heute nicht mehr nur, ob der Code gut geschrieben ist, sondern wen Nutzer wirklich vertrauen. Wenn ein Protokoll upgradebar ist, pausieren kann, Abhebungen aufreiht und die Kernlogik über Multisig ändern kann, dann tragen Nutzer nicht nur das Risiko eines reinen Smart-Contract-Codes, sondern auch Governance-Risiken des Teams, Risiken der Signer, Infrastruktur-Risiken und Betriebsrisiken.
Ist dieser Artikel noch dezentralisiertes DeFi? Andre Cronje: Anerkennen, denn die meisten Protokolle sind austauschbarer Code. Erstmals erschienen in: Kettennachrichten ABMedia.
