Direkt zum Hauptinhalt

Move VM Speicher-Sicherheit vs. EVM-Reentrancy: Warum das Ressourcenmodell von Aptos und Sui ganze Klassen von Schwachstellen in Smart Contracts eliminiert

· 10 Min. Lesezeit
Dora Noda
Dora Noda
Software Engineer

Der DAO-Hack von 2016 entzog Ethereum an einem einzigen Nachmittag 60 Millionen .NeunJahrespa¨terkostenReentrancy−AngriffeDeFi−ProtokollealleinimJahr2024immernoch35,7Millionen. Neun Jahre später kosten Reentrancy-Angriffe DeFi-Protokolle allein im Jahr 2024 immer noch 35,7 Millionen in 22 separaten Vorfällen. Dieselbe Klasse von Schwachstellen – ein Angreifer ruft einen Contract zurück, bevor dessen Status aktualisiert wird – sucht das EVM-Ökosystem trotz jahrelanger Entwicklerschulungen, Audit-Tools und kampferprobter Muster weiterhin heim.

Aptos und Sui, beide auf der Sprache Move basierend, verfolgen einen grundlegend anderen Ansatz: Sie machen ganze Kategorien von Schwachstellen durch ihr Design unmöglich.

Die Ursache: Wie EVM-Reentrancy entsteht​

Um zu verstehen, warum Move anders ist, hilft es zu verstehen, warum Reentrancy auf Ethereum überhaupt möglich ist.

Solidity-Contracts können während der Ausführung externe Contracts aufrufen. Wenn Contract A den Contract B aufruft, geht die Ausführung vollständig auf B über. B kann dann A zurückrufen – ein „Re-entering“ – bevor A die Aktualisierung seines internen Status abgeschlossen hat. Wenn die Auszahlungslogik von A so aussieht:

// Anfälliges Muster
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}(""); // Externer Aufruf zuerst
    balances[msg.sender] -= amount;                         // Status-Update als Zweites
}

Der Contract eines Angreifers kann ETH im Callback empfangen, sofort erneut withdraw aufrufen und Gelder abziehen, bevor balances[msg.sender] jemals verringert wird. Genau das ist bei The DAO passiert – der Contract des Angreifers rief die Auszahlungsfunktion rekursiv 3,6 Millionen Mal in einer Schleife auf.

Die Lösung klingt einfach: Den Status aktualisieren, bevor externe Aufrufe getätigt werden (das „Checks-Effects-Interactions“-Muster). Aber Entwickler vergessen es. Auditoren übersehen es. Das Muster ist eine Konvention, die nur durch menschliche Sorgfalt erzwungen wird, nicht durch die Sprache selbst.

Der Move-Ansatz: Ressourcen können nicht dupliziert oder zerstört werden​

Move wurde von Grund auf so konzipiert, dass diese Fehlerklasse auf der Ebene des Typsystems verhindert wird. Das Kernkonzept ist das lineare Typsystem und Ressourcentypen.

In Move ist eine Ressource eine spezielle Art von Wert, die:

  • Nicht kopiert werden kann – sie kann nur zwischen Speicherorten verschoben werden
  • Nicht verworfen werden kann – sie muss explizit verbraucht oder irgendwo gespeichert werden
  • Einen einzigen Besitzer zu jedem Zeitpunkt hat – verfolgt von der VM, nicht durch ein Mapping

Das klingt abstrakt, aber die Auswirkungen sind konkret. Betrachten Sie, wie ein Token-Transfer funktioniert:

  • In Solidity ist ein Token-Guthaben ein uint256 in einem Mapping. Die Zahl kann theoretisch manipuliert werden, wenn die Reihenfolge der Aktualisierungen falsch ist.
  • In Move ist ein Token ein tatsächliches Ressourcenobjekt, das im Speicher eines Kontos lebt. Man verschiebt es physisch von einem Ort zum anderen – es gibt keinen Zwischenzustand, in dem die Ressource an zwei Orten oder an gar keinem Ort existiert.

Die Move VM erzwingt diese Invarianten auf Bytecode-Ebene, nicht auf Quellcode-Ebene. Selbst wenn ein Entwickler fehlerhaften Code schreibt, wird die VM jede Transaktion ablehnen, die versucht, eine Ressource zu duplizieren oder stillschweigend zu verwerfen.

Warum Reentrancy in Move strukturell unmöglich ist​

Reentrancy erfordert zwei Bedingungen: die Fähigkeit, während der Ausführung externen Code aufzurufen, und einen veränderbaren gemeinsamen Status, der während dieses Callbacks manipuliert werden kann. Move bricht beides.

Move erlaubt keinen dynamischen Dispatch in der Art und Weise, wie Solidity es tut. Es gibt keine willkürlichen externen Aufrufe, die die Kontrolle an unbekannten Code übergeben. Funktionen müssen statisch aufgerufen werden – der Aufgerufene ist zum Zeitpunkt der Kompilierung bekannt. Das bedeutet, dass ein Angreifer keinen Contract bereitstellen kann, der während eines Callbacks wieder in Ihr Modul eintritt, da Ihr Modul die Ausführung niemals an einen unbekannten externen Contract übergibt.

Zusätzlich verwendet das Objektmodell von Move auf Sui und Aptos ein Ownership-System, bei dem Objekte explizit in Funktionen hinein- und herausgegeben werden. Ein Objekt, das in eine Funktion „verschoben“ wurde, ist nirgendwo anders zugänglich, bis die Funktion es zurückgibt. Ein gleichzeitiger Zugriff auf dieselbe Ressource in einer einzigen Transaktion ist schlichtweg nicht möglich.

Eine im Jahr 2025 veröffentlichte Studie bestätigt: „In Move ist Reentrancy nicht möglich, da dynamische Callbacks nicht möglich sind – ein grundlegender Unterschied zu Solidity, wo Reentrancy weiterhin eine große Bedrohung darstellt.“

Double-Spend-Prävention ohne Mutex-Sperren​

In EVM-basierten Systemen beruht der Schutz vor Double-Spending auf sorgfältiger Programmierung. Entwickler müssen manuell sicherstellen, dass ein Token in einer Transaktion nicht zweimal ausgegeben werden kann, indem sie Statusaktualisierungen gewissenhaft verfolgen.

Das lineare Typsystem von Move macht Double-Spending strukturell unmöglich. Da eine Ressource nicht kopiert werden kann, entfernt das Ausgeben einer Coin diese buchstäblich aus dem Speicher Ihres Kontos. Es gibt keine Möglichkeit, dieselbe Ressource in einer Transaktion zweimal auszugeben, da die Ressource nach der ersten Ausgabe nicht mehr unter Ihrer Kontrolle existiert. Die VM erzwingt dies – es ist keine Konvention, sondern eine Einschränkung.

Dies erstreckt sich auch auf Capability-Objekte auf Sui. Eine Capability-Ressource kann, sobald sie verbraucht wurde, nicht erneut verwendet werden. Vergleichen Sie dies mit EVM-Zugriffskontrollmustern, bei denen eine Berechtigung (Capability) typischerweise eine Rolle ist, die in einem Boolean- oder Address-Mapping kodiert ist und mehrfach überprüft werden kann.

Ein realer Vorfall auf Sui hebt eine Nuance hervor: Bei einer DEX wurde ein Fehler gefunden, bei dem die Auszahlungslogik es versäumte, Single-Use-Beschränkungen für eine veränderbare Referenz auf eine Capability durchzusetzen – nicht auf die Capability selbst. Dies zeigt, dass das Ressourcenmodell von Move zwar ganze Klassen von Fehlern eliminiert, Entwickler aber dennoch Logikfehler einführen können, wenn sie mit Referenzen statt mit eigenen Ressourcen arbeiten. Die Angriffsfläche wird drastisch verkleinert, aber nicht auf null.

Integer-Overflow: Ein weiteres Problem, das Move standardmäßig löst​

In frühen Solidity-Versionen (vor 0.8.0) führte die Ganzzahlarithmetik bei einem Überlauf geräuschlos zu einem Umbruch. Dies ermöglichte es Angreifern, Token-Guthaben zu manipulieren, indem sie Overflow-Bedingungen auslösten – eine Schwachstelle, die zu mehreren aufsehenerregenden DeFi-Exploits beitrug.

Solidity 0.8.0 führte eine automatische Überlaufprüfung ein, jedoch erst nach jahrelangen Schäden. Move enthält diesen Schutz seit seiner Entstehung: Jede Transaktion, die einen Integer-Overflow verursacht, wird automatisch abgebrochen. Es gibt standardmäßig keine Opt-out-Möglichkeit, kein Äquivalent zu unchecked und keine Legacy-Contracts mit altem Verhalten, um die man sich Sorgen machen müsste.

Formale Verifizierung: Move Prover vs. EVM-Auditing​

Die Sicherheitsgeschichte von Move erstreckt sich über die Sprache hinaus auf ihre Tooling-Landschaft. Der Move Prover ist ein Werkzeug zur formalen Verifizierung, das zusammen mit der Sprache selbst entwickelt wurde – kein nachträglicher Einfall.

Mit dem Move Prover schreiben Entwickler Spezifikationen direkt in ihre Move-Quelldateien unter Verwendung einer Spezifikationssprache. Diese Spezifikationen werden dann mathematisch gegen die Implementierung verifiziert. Eine Spezifikation könnte beispielsweise zusichern: „Nach Ausführung dieser Funktion bleibt das Gesamtangebot an Coins unverändert.“ Der Prover wird dies entweder bestätigen oder ein Gegenbeispiel liefern, das genau zeigt, wann die Bedingung fehlschlägt.

Dies unterscheidet sich kategorisch von der Art und Weise, wie die meisten Solidity-Audits funktionieren:

AspektMove ProverSolidity-Auditing-Tools
VerifizierungstypMathematischer BeweisMusterabgleich / Fuzzing
AbdeckungVollständig (innerhalb des Spezifikationsumfangs)Bestmögliche Bemühung
IntegrationTeil der Toolchain der SpracheDrittanbieter-Tools (Slither, Certora)
ZeitpunktEntwicklungszeitAudit vor dem Deployment
KostenKostenlos, im RepositoryTeure manuelle Audits

Tools wie Slither für Solidity führen statische Analysen durch und erkennen bekannte Schwachstellenmuster. Der Certora Prover für Solidity unterstützt zwar die formale Verifizierung und kann eine breitere Palette von Eigenschaften ausdrücken – einschließlich transaktionsübergreifender Invarianten. Aber Certora erfordert das Schreiben von Spezifikationen in einer separaten Sprache und das Ausführen einer separaten Pipeline, was es eher zu einem spezialisierten Audit-Schritt als zu einem alltäglichen Entwicklungswerkzeug macht.

Die engere Integration des Move Prover bedeutet, dass die formale Verifizierung etwas ist, das Aptos- und Sui-Entwickler während der Entwicklung lokal ausführen können, und nicht nur als teure Audit-Hürde. Das Aptos-Framework selbst wird mit Move-Prover-Spezifikationen für seine Standardbibliothek ausgeliefert und bietet so eine Sicherheits-Baseline, die Anwendungsentwickler erben.

Das Restrisiko: Was Move nicht eliminiert​

Das Design von Move ist keine universelle Sicherheitsgarantie. Reale Audits von Move-Contracts zeigen, dass Entwickler immer noch Folgendes einführen können:

  • Logikfehler in Geschäftsregeln (die häufigste Kategorie)
  • Bugs bei der Zugriffskontrolle, wenn veränderliche Referenzen anstelle von eigenen Ressourcen verwendet werden
  • Fehler im wirtschaftlichen Design in DeFi-Protokollen (Preis-Orakel-Manipulation, Flash-Loan-Angriffe)
  • Bugs bei der Interaktion zwischen Modulen, wenn mehrere Module auf unerwartete Weise interagieren

Eine Studie aus dem Jahr 2024 untersuchte manuell 652 Move-Contracts und identifizierte acht Fehlertypen, von denen die Hälfte zuvor nicht gemeldet worden war. Die Angriffsfläche ist kleiner als bei Solidity, aber sie existiert weiterhin.

Die beste Sicherheitsstrategie auf Aptos und Sui kombiniert Move-Prover-Spezifikationen, Audits durch Drittanbieter und ökonomische Sicherheitsanalysen – nicht nur das Vertrauen auf die integrierten Schutzmaßnahmen der Sprache.

Warum dies für DeFi-Entwickler im Jahr 2025 wichtig ist​

Die Zahlen sprechen eine deutliche Sprache. Im Jahr 2024 kosteten Schwachstellen in Smart Contracts den DeFi-Sektor über $ 1,4 Milliarden. Reentrancy trug $ 35,7 Millionen dazu bei – eine Kategorie, die auf einer Move-basierten Chain mit äquivalentem TVL strukturell bei null liegen würde.

Für Entwickler, die Finanzanwendungen erstellen, ist die Wahl der VM effektiv eine Entscheidung über Ihr standardmäßiges Bedrohungsmodell. Das Bauen auf der EVM bedeutet, das Checks-Effects-Interactions-Muster als erforderliche Disziplin zu übernehmen. Das Bauen auf Move bedeutet, dass Reentrancy einfach nicht Teil Ihres Bedrohungsmodells ist – Ihr Team kann seine Aufmerksamkeit in puncto Sicherheit stattdessen auf Logikfehler und das wirtschaftliche Design richten.

Dies ist kein kleiner Unterschied. Formale Verifizierungstools funktionieren besser, wenn die Bedrohungsfläche kleiner ist. Auditoren können tiefer gehen, wenn sie keine Zyklen für gut verstandene Schwachstellenklassen aufwenden müssen. Die kognitive Belastung für Entwickler, die korrekten Code schreiben wollen, sinkt, wenn die Sprache kritische Invarianten automatisch erzwingt.

Die Infrastrukturebene​

Sicherheitsgarantien spielen nur dann eine Rolle, wenn Entwickler tatsächlich in großem Maßstab auf diesen Chains aufbauen können. Das Betreiben eines eigenen Aptos- oder Sui-Nodes für den Netzwerkzugriff ist mit erheblichem operativem Aufwand verbunden – Hardware-Bereitstellung, Software-Upgrades, Monitoring und Incident Response.

BlockEden.xyz bietet API-Zugriff auf Unternehmensebene für Aptos und Sui, sodass Entwickler auf den Sicherheitsgarantien von Move aufbauen können, ohne die Node-Infrastruktur verwalten zu müssen. Erkunden Sie unsere Dienste, um sicherere Web3-Anwendungen zu erstellen.

Die Kombination aus einer speichersicheren Sprache, struktureller Reentrancy-Prävention und integrierter formaler Verifizierung macht Aptos und Sui zu einer überzeugenden Plattform für hochriskante DeFi-Anwendungen. Move macht es nicht nur einfacher, sichere Smart Contracts zu schreiben – es macht bestimmte Klassen katastrophaler Fehler mathematisch unmöglich.

Konsultierte Quellen:

Share on Twitter