Was ist der Unterschied zwischen Call, Delegatecall und Staticcall in Solidity?

Das Verständnis der Unterschiede zwischen Call, Delegatecall und Staticcall ist für die sichere und effiziente Entwicklung intelligenter Verträge in Solidity von entscheidender Bedeutung. Diese Low-Level-Funktionen ermöglichen die Interaktion mit anderen Verträgen oder externen Konten, verhalten sich jedoch in Bezug auf Kontext, Statusänderung und Ausführungsumgebung unterschiedlich.

Anruf

1. Die Aufruffunktion ruft die Funktion eines anderen Vertrags auf, leitet dabei eine bestimmte Menge Ether weiter und führt Code im Kontext des aufgerufenen Vertrags aus.

2. Es nutzt den Speicher, den Code und das Guthaben des Aufgerufenen, was bedeutet, dass alle Zustandsänderungen innerhalb des Geltungsbereichs des Zielvertrags stattfinden.
3. Diese Methode wird häufig bei der Interaktion mit externen Verträgen verwendet, deren ABI zum Zeitpunkt der Kompilierung möglicherweise nicht bekannt ist.
4. Entwickler müssen sorgfältig mit Rückgabedaten umgehen, da der Aufruf einen booleschen Wert zurückgibt, der Erfolg oder Misserfolg anzeigt, zusammen mit optionalen Rückgabebytes.
5. Missbrauch kann zu Wiedereintrittsschwachstellen führen, wenn die ordnungsgemäßen Prüf-Effekte-Interaktionsmuster nicht befolgt werden.

Delegatecall

1. Delegatecall führt Code aus einem anderen Vertrag aus, behält jedoch den Speicher, den Kontext und das Guthaben des Aufrufers bei.

2. Es wird häufig in Proxy-Mustern verwendet, bei denen Logik von Daten getrennt ist, wodurch aktualisierbare Verträge ermöglicht werden.
3. Da sich Zustandsänderungen auf den Speicher des aufrufenden Vertrags auswirken, ist bei der Abstimmung der Speicherlayouts zwischen Proxy und Implementierung äußerste Vorsicht geboten.
4. Im Gegensatz zu call wird bei einem Delegatecall kein Ether übertragen, es sei denn, er wird explizit über zusätzliche Mechanismen gesendet.
5. Zu den Sicherheitsrisiken gehören böswillige Implementierungsverträge, die kritische Variablen wie Eigentum oder Guthaben im Proxy ändern.

statischer Aufruf

1. staticcall dient zum Aufrufen von Funktionen, die den Status der Blockchain nicht ändern.

2. Jeder Versuch, in den Speicher zu schreiben, Ereignisse auszugeben oder Vorgänge auszuführen, die den Status ändern, führt dazu, dass der Aufruf zurückgesetzt wird.
3. Diese Funktion ist nützlich, um Daten aus externen Verträgen sicher auszulesen, ohne das Risiko unbeabsichtigter Nebenwirkungen einzugehen.
4. Wie call arbeitet es innerhalb des Codes des Zielvertrags, erzwingt jedoch bei der Ausführung einen schreibgeschützten Modus.
5. Zu den Hauptanwendungsfällen gehören die Abfrage von Token-Salden, die Überprüfung von Freibeträgen oder das Abrufen unveränderlicher Werte aus Verträgen Dritter.

Häufige Fragen

Was passiert, wenn ein Delegatecall auf einen Vertrag mit nicht übereinstimmendem Speicherlayout abzielt? Wenn die Speicherplätze im aufrufenden Vertrag nicht mit denen übereinstimmen, die von der Logik im aufgerufenen Vertrag erwartet werden, können Variablen fälschlicherweise überschrieben werden. Beispielsweise könnte eine in einem Steckplatz gespeicherte Adresse als uint256 interpretiert werden, was zu beschädigten Daten oder unbefugtem Zugriff führt.

Kann staticcall zur Interaktion mit kostenpflichtigen Funktionen verwendet werden? Ja, staticcall kann auf kostenpflichtige Funktionen abzielen, solange sie den Status nicht tatsächlich ändern. Das Senden von Ether über staticcall ist jedoch überflüssig, da Wertübertragungen von Natur aus Zustandsänderungen beinhalten und dazu führen würden, dass der Anruf fehlschlägt.

Warum gilt ein Anruf in bestimmten Szenarien als riskanter als ein statischer Anruf? Da der Aufruf sowohl Zustandsänderungen als auch Ether-Transfers zulässt, eröffnet er Angriffsvektoren wie Wiedereintrittsangriffe. Ohne strikte Eingabevalidierung und Kontrollflussverwaltung könnte ein externer Vertrag während eines Rückrufs rekursiv Gelder abziehen.

Ist Delegatecall mit allen Arten von Vertrags-Upgrades kompatibel? Delegatecall ermöglicht zwar die Aufrüstbarkeit, erfordert jedoch ein sorgfältiges Design. Speicherkollisionen, Konflikte bei der Funktionsauswahl und Initialisierungsprobleme können die Funktionalität beeinträchtigen. Transparente Proxys und UUPS-Muster helfen, diese Risiken zu mindern, erfordern jedoch strenge Tests und Prüfungen.