Wie liest man einen Smart Contract auf Etherscan für Anfänger?

Die Grundlagen der intelligenten Vertragsüberprüfung verstehen

1. Auf Ethereum bereitgestellte Smart Contracts werden in Bytecode kompiliert und in der Kette gespeichert, was eine Rohprüfung ohne geeignete Tools schwierig macht.

2. Etherscan dient als öffentlicher Blockchain-Explorer, der Transaktionsdaten, Vertragsadressen und Quellcode indiziert, wenn Entwickler diese überprüfen und veröffentlichen möchten.

3. Bei verifizierten Verträgen wird neben dem Vertragsnamen ein grünes Abzeichen „Verifiziert“ angezeigt, das darauf hinweist, dass der übermittelte Quellcode mit dem bereitgestellten Bytecode übereinstimmt.

4. Nicht verifizierte Verträge zeigen nur Bytecode oder Assembly, was für Laien nahezu unmöglich sinnvoll zu interpretieren ist.

5. Für die Verifizierung sind übereinstimmende Compilerversionen, Optimierungseinstellungen und Eingabeparameter erforderlich. Nichtübereinstimmungen führen zu einer fehlgeschlagenen Verifizierung und der Anzeige von nicht vertrauenswürdigem Code.

Navigieren in der Benutzeroberfläche der Vertragsseite

1. Nach Eingabe einer Vertragsadresse in die Suchleiste von Etherscan gelangen Benutzer auf eine spezielle Vertragsseite mit Registerkarten wie „Vertrag“, „Transaktionen“, „Analyse“ und „Mehr“.

2. Die Registerkarte „Vertrag“ enthält die wichtigsten Informationen: ABI, Lese-/Schreibfunktionen und den Quellcodeabschnitt, sofern überprüft.

3. Der Abschnitt „Vertrag lesen“ ermöglicht die Interaktion mit Ansichts-/Reinfunktionen ohne Gasgebühren – Benutzer können Guthaben, Token-Namen oder Eigentumsstatus direkt abfragen.

4. Der Abschnitt „Vertrag schreiben“ ermöglicht Statusänderungsaktionen wie die Übertragung von Token oder die Aktualisierung von Berechtigungen, erfordert jedoch eine Wallet-Verbindung und eine Gaszahlung.

5. Im Bereich „Vertragsquellcode“ werden die ursprünglichen Solidity- (oder Vyper-)Dateien angezeigt, oft auf mehreren Registerkarten organisiert, wenn das Projekt Importe oder Bibliotheken verwendet.

Interpretation wichtiger Abschnitte des verifizierten Quellcodes

1. Der SPDX-Lizenzbezeichner erscheint oben und weist auf die rechtlichen Nutzungsbedingungen hin – Fehlen kann auf nicht überprüften oder möglicherweise riskanten Code hinweisen.

2. Pragma-Anweisungen der Compiler-Version wie Pragma Solidity ^0.8.20; muss mit der während der Bereitstellung verwendeten Version übereinstimmen – nicht übereinstimmende Versionen riskieren unerwartetes Verhalten.

3. Mit öffentlicher Sichtbarkeit deklarierte Zustandsvariablen generieren automatisch Getter-Funktionen, sichtbar unter „Vertrag lesen“.

4. Die Verwendung von Modifikatoren – wie „onlyOwner“ oder „whenNotPaused “ – enthüllt die Zugriffskontrolllogik, die für die Bewertung von Zentralisierungsrisiken von entscheidender Bedeutung ist.

5. Externe Funktionssignaturen legen offen, wie dApps von Drittanbietern mit dem Vertrag interagieren – ungewöhnliche Parametertypen oder undokumentierte Ereignisse können auf Verschleierung hinweisen.

Warnsignale im Vertragscode erkennen

1. Funktionen, die ohne klare Geschäftslogik als zahlbar gekennzeichnet sind, könnten unbeabsichtigte ETH-Transfers oder Wiedereintrittsvektoren ermöglichen.

2. Fehlende oder generische Ereignisemissionen verringern die Transparenz – legitime Protokolle geben Ereignisse für jede kritische Zustandsänderung wie Minting oder Burning aus.

3. Die Verwendung von Selfdestruct oder Delegatecall ohne gründliche Dokumentation wirft Bedenken hinsichtlich der Aktualisierbarkeit und der Vertrauensannahmen auf.

4. Hartcodierte Adressen anstelle konfigurierbarer Parameter deuten auf Inflexibilität und potenzielle Manipulationspunkte hin.

5. Das Fehlen von Standardschnittstellen wie ERC-20 oder ERC-721 trotz angeblicher Kompatibilität weist auf eine Abweichung von geprüften Mustern hin.

Häufig gestellte Fragen

F: Was bedeutet „Überprüfung nicht möglich“, wenn ich versuche, einen Vertrag zu überprüfen? Dies bedeutet, dass der übermittelte Quellcode unter den angegebenen Compilereinstellungen keinen identischen Bytecode erzeugt – entweder aufgrund von Versionskonflikten, Optimierungsunterschieden oder falschen Konstruktorargumenten.

F: Kann ich einem Vertrag vertrauen, nur weil er bei Etherscan als „Verifiziert“ angezeigt wird? Nein. Die Überprüfung bestätigt die Integrität des Codes, nicht die Richtigkeit oder Sicherheit – bösartige Logik kann vollständig überprüft werden und ist dennoch schädlich.

F: Warum haben einige Verträge mehrere Quellcode-Registerkarten? Sie nutzen eine modulare Architektur mit separaten Dateien für Bibliotheken, Schnittstellen oder Implementierungsverträge – jede Datei wird bei der Verifizierung einzeln hochgeladen.

F: Ist es möglich, nicht verifizierte Vertragslogik zu lesen? Nur durch dekompilierten Bytecode mit Tools wie Mythril oder evm-opcodes, aber die Ergebnisse sind sehr abstrakt und für das Funktionsverständnis unzuverlässig.