Vor dem Upgrade von Ethereum Cancun müssen die Projektentwickler mehrere Sicherheitsüberprüfungen durchführen

Lange Rede, kurzer Sinn: Das Cancun-Upgrade rückt näher. Dieses Upgrade enthält hauptsächlich Änderungen auf der Führungsebene, die von sechs EIPs vorgeschlagen werden: EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 und EIP-7516. EIP-4844 ist der Protagonist dieses Upgrades, das darauf abzielt, die Skalierbarkeit von Ethereum zu verbessern, Transaktionskosten zu senken und die Transaktionsgeschwindigkeit für L2 zu erhöhen. Das Cancun-Upgrade wurde auf den Ethereum-Testnetzen Goerli, Sepolia und Holesky am 17. Januar, 30. Januar bzw. 7. Februar abgeschlossen und soll am 13. März im Ethereum-Hauptnetz aktiviert werden. Vor dem Upgrade hat Salus wichtige Sicherheitsvorkehrungen für dieses Upgrade zusammengestellt, damit Entwickler diese selbst überprüfen können.

EIP Proposal Review

EIP-1153

EIP-1153 führt temporäre Speicher-Opcodes ein. Diese Opcodes werden zum Betreiben des Status verwendet. Ihr Verhalten ist fast das gleiche wie bei der Speicherung, aber der temporäre Speicher wird nach jedem Vorgang entfernt Transaktion wegwerfen. Dies bedeutet, dass der temporäre Speicher keine Werte aus dem Speicher deserialisiert oder Werte in den Speicher serialisiert, sodass temporärer Speicher kostengünstiger ist, da kein Festplattenzugriff erforderlich ist. Intelligente Verträge können über zwei neue Opcodes auf temporären Speicher zugreifen: TLOAD und TSTORE (wobei das „T“ für „temporär“ steht). Ziel dieses Vorschlags ist es, eine dedizierte und effiziente Lösung für die Kommunikation zwischen mehreren verschachtelten Ausführungsframeworks bei der Transaktionsausführung von Ethereum bereitzustellen.

EIP-4788

EIP-4788 wurde entwickelt, um die Hash-Baumwurzeln von Beacon-Chain-Blöcken dem EVM zugänglich zu machen, um den Zugriff auf diese Wurzeln innerhalb von Smart Contracts zu ermöglichen. Dies ermöglicht einen vertrauenswürdigen Zugriff auf den Status der Konsensschicht und unterstützt mehrere Anwendungsfälle wie Absteckpools, erneute Absteckstrukturen, intelligente Vertragsbrücken, MEV-Minderung und mehr. Der Vorschlag speichert diese Wurzeln über einen Smart Contract und nutzt einen Ringpuffer, um den Speicherverbrauch zu begrenzen, wodurch sichergestellt wird, dass jeder Ausführungsblock nur konstanten Speicherplatz zur Darstellung dieser Informationen benötigt.

EIP-4844

EIP-4844 führt ein neues Transaktionsformat namens „Sharded Blob Transactions“ ein, das darauf ausgelegt ist, die Datenverfügbarkeit von Ethereum auf einfache, vorwärtskompatible Weise zu erweitern. Dieser Vorschlag funktioniert durch die Einführung von „Blob-tragenden Transaktionen“, die große Datenmengen enthalten, auf die die EVM-Ausführung nicht zugreifen kann, die aber auf ihre Verpflichtungen zugreifen kann. Dieses Format ist vollständig kompatibel mit dem Format, das künftig beim vollständigen Sharding verwendet wird, und bietet eine vorübergehende, aber erhebliche Erleichterung für die fortlaufende Erweiterung.

EIP-5656

EIP-5656 führt einen neuen EVM-Befehl, MCOPY, ein, der das effiziente Kopieren von Speicherbereichen verbessern soll. Der Zweck dieses Vorschlags besteht darin, die Kosten für die Durchführung von Speicherkopiervorgängen auf dem EVM zu reduzieren und ein direktes Kopieren von Speicherdaten über den MCOPY-Befehl zu erreichen. MCOPY ermöglicht die Überlappung von Quell- und Zieladressen unter Berücksichtigung der Abwärtskompatibilität und zielt darauf ab, die Ausführungseffizienz in verschiedenen Szenarien wie dem Aufbau von Datenstrukturen, dem Zugriff auf Speicherobjekte und dem Kopieren zu verbessern.

EIP-6780

EIP-6780 ändert die Funktionalität des SELFDESTRUCT-Opcodes. In diesem Vorschlag löscht SELFDESTRUCT nur das Konto und überträgt alle Ether-Coins in derselben Transaktion wie die Vertragserstellung. Darüber hinaus wird bei der Ausführung von SELFDESTRUCT der Vertrag nicht gelöscht, sondern alle Ether-Coins werden an das angegebene Ziel übertragen. Diese Änderung dient der Anpassung an die zukünftige Verwendung von Verkle-Bäumen und zielt darauf ab, die EVM-Implementierung zu vereinfachen und die Komplexität von Zustandsänderungen zu verringern, während einige gängige Szenarien der Selbstzerstörung beibehalten werden.

EIP-7516

EIP-7516 führt eine neue EVM-Anweisung BLOBBASEFEE ein, die verwendet wird, um den Blob-Basisgebührenwert in der aktuellen Blockausführung zurückzugeben. Diese Anweisung ähnelt dem BASEFEE-Opcode in EIP-3198, außer dass sie die in EIP-4844 definierte Blob-Basisgebühr zurückgibt. Mit dieser Funktion können Verträge den Gaspreis von Blob-Daten programmgesteuert berücksichtigen. So können Rollup-Verträge beispielsweise die Kosten für die Nutzung von Blob-Daten zuverlässig berechnen oder auf dieser Grundlage Blob-Gas-Futures implementieren, um die Kosten für Blob-Daten zu glätten.

Offiziell offengelegte Sicherheitsüberlegungen

EIP-1153

Smart-Contract-Entwickler sollten vor der Verwendung den Lebenszyklus transienter Speichervariablen verstehen. Da der temporäre Speicher am Ende einer Transaktion automatisch gelöscht wird, versuchen Smart-Contract-Entwickler möglicherweise, das Löschen von Slots während Anrufen zu vermeiden, um Gas zu sparen. Dies kann jedoch eine weitere Interaktion mit dem Vertrag innerhalb derselben Transaktion verhindern (z. B. im Fall von wiedereintretenden Sperren) oder andere Fehler verursachen, daher sollten Smart-Contract-Entwickler darauf achten, nicht-temporäre Speicherplätze nur dann zu reservieren, wenn sie reserviert sind. Nullwert. Zur Verwendung durch zukünftige Aufrufe innerhalb derselben Transaktion vorgesehen. SSTORE Ansonsten verhalten sich diese Opcodes genau wie SLOAD und SLOAD , sodass alle üblichen Sicherheitsüberlegungen gelten, insbesondere im Hinblick auf Wiedereintrittsrisiken.

Entwickler intelligenter Verträge versuchen möglicherweise auch, transienten Speicher als Alternative zur Speicherzuordnung zu verwenden. Sie sollten sich darüber im Klaren sein, dass temporärer Speicher nicht wie Speicher verworfen wird, wenn ein Anruf zurückkehrt oder fortgesetzt wird, und dass in diesen Anwendungsfällen Speicher bevorzugt werden sollte, um unerwartetes Verhalten beim Wiedereintritt innerhalb derselben Transaktion zu vermeiden. Die Kosten für die vorübergehende Speicherung im Arbeitsspeicher sind zwangsläufig hoch, was dieses Nutzungsmuster hätte verhindern sollen. Die meisten Anwendungen von In-Memory-Mapping lassen sich besser mit einer nach Schlüsseln geordneten Liste von Einträgen implementieren, und In-Memory-Mapping wird in Smart Contracts selten benötigt (d. h. den Autoren sind keine bekannten Anwendungsfälle in der Produktion bekannt).

EIP-4844

Dieses EIP erhöht den Bandbreitenbedarf um bis zu etwa 0,75 MB pro Beacon-Block. Dies ist 40 % größer als die theoretische Maximalgröße heutiger Blöcke (30 MB Gas / 16 Gas pro Anrufdatenbyte = 1,875 MB), sodass die Bandbreite im ungünstigsten Fall nicht wesentlich erhöht wird. Nach der Fusion sind die Blockzeiten eher statisch als unvorhersehbare Poisson-Verteilungen, was einen garantierten Zeitraum für die Ausbreitung großer Blöcke bietet.

Selbst bei begrenzten Anrufdaten ist die Dauerlast dieses EIP viel geringer als bei Alternativen, die die Kosten für Anrufdaten senken, da die Blobs nicht gespeichert werden müssen, solange die Last ausgeführt wird. Dadurch ist es möglich, eine Richtlinie zu implementieren, bei der diese Blobs zumindest für einige Zeit aufbewahrt werden müssen. Der ausgewählte spezifische Wert ist die MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS-Epoche, die etwa 18 Tage beträgt, eine viel kürzere Verzögerung im Vergleich zur empfohlenen (aber noch nicht implementierten) einjährigen Rotation für die Ausführung des Nutzlastverlaufs.

EIP-5656

Kunden sollten sich darüber im Klaren sein, dass ihre Implementierungen keine Zwischenpuffer verwenden (z. B. verwendet die C-Funktion stdlibmemmove keine Zwischenpuffer), da dies ein potenzieller Denial-of-Service-Vektor (DoS) ist. Die meisten der in der Sprache integrierten/Standardbibliotheksfunktionen zum Verschieben von Bytes weisen hier die richtigen Leistungsmerkmale auf.

Ansonsten ist die Analyse von Denial of Service (DoS)- und Speichererschöpfungsangriffen dieselbe wie für andere Opcodes, die den Speicher berühren, da für Speichererweiterungen dieselben Preisregeln gelten.

EIP-6780

Die folgende Anwendung SELFDESTRUCT wird beschädigt und Anwendungen, die sie auf diese Weise verwenden, sind nicht mehr sicher:

WhereCREATE2 wird verwendet, um den Vertrag am selben Ort erneut bereitzustellen, um den Vertrag aktualisierbar zu machen. Diese Funktion wird nicht mehr unterstützt und stattdessen sollte ERC-2535 oder eine andere Art von Proxy-Vertrag verwendet werden.

Wenn ein Vertrag auf der Zerstörung von Ether basiert und der SELFDESTRUCT-Vertrag der Begünstigte ist, wurde der Vertrag nicht in derselben Transaktion erstellt. Risiken im Zusammenhang mit Smart Contracts S 1:

Im Vergleich zu herkömmlichem SSTORE und SLOAD ändert sich beim neuen transienten Speicher hauptsächlich die Speicherdauer der in tstore gespeicherten Daten, und die Daten werden nach der Ausführung einer Transaktion freigegeben, anstatt den Vertrag zu schreiben wie im Store dauerhaft aufgezeichnet werden. Entwickler sollten die Eigenschaften dieses Opcodes kennen, wenn sie ihn verwenden, um eine falsche Verwendung zu vermeiden, die dazu führen kann, dass Daten falsch in den Vertrag geschrieben werden und Verluste verursachen. Darüber hinaus sind die Daten in tstore private Variablen, auf die nur der Vertrag selbst zugreifen kann. Wenn Sie die Daten extern nutzen möchten, können Sie diese nur in Form von Parametern übergeben oder in einer öffentlichen Speichervariablen zwischenspeichern.

Risiko 2:

Ein weiteres potenzielles Risiko besteht darin, dass, wenn Smart-Contract-Entwickler den Lebenszyklus transienter Speichervariablen nicht ordnungsgemäß verwalten, dies dazu führen kann, dass Daten unrechtmäßig gelöscht oder falsch aufbewahrt werden. Wenn ein Vertrag vorsieht, in nachfolgenden Aufrufen einer Transaktion im vorübergehenden Speicher gespeicherte Daten zu verwenden, den Lebenszyklus dieser Daten jedoch nicht ordnungsgemäß verwaltet, können Daten zwischen Aufrufen falsch geteilt werden oder verloren gehen, was zu logischen Fehlern oder Sicherheitslücken führt. Da die Saldo- oder Vergütungsdaten ähnlich wie beim Token-Projekt nicht korrekt gespeichert werden können, führt dies zu Fehlern in der Vertragslogik und verursacht Verluste. Oder die Verwendung dieses Opcodes beim Festlegen der Eigentümeradresse führt dazu, dass die privilegierte Adresse nicht korrekt erfasst wird und somit die Änderung wichtiger Vertragsparameter verloren geht.

Stellen Sie sich einen Smart Contract vor, der transiente Speicherung nutzt, um Transaktionspreise an einer Kryptowährungsbörse vorübergehend aufzuzeichnen. Der Vertrag aktualisiert den Preis, wenn jeder Trade abgeschlossen ist, und ermöglicht es Benutzern, für einen kurzen Zeitraum den aktuellen Preis abzufragen. Wenn die Vertragsgestaltung jedoch die Funktion nicht berücksichtigt, dass vorübergehender Speicher am Ende einer Transaktion automatisch gelöscht wird, kann es sein, dass Benutzer im Zeitraum vom Ende einer Transaktion bis zum Beginn der nächsten eine falsche oder veraltete Transaktion erhalten Transaktion. Preis. Dies kann nicht nur dazu führen, dass Benutzer Entscheidungen auf der Grundlage falscher Informationen treffen, sondern kann auch in böswilliger Absicht genutzt werden, was die Glaubwürdigkeit der Plattform und die Sicherheit der Vermögenswerte der Benutzer beeinträchtigt.

• EIP-6780

Dieser Vorschlag ändert das Verhalten des vorherigen Selbstzerstörungs-Opcodes. Der Vertrag wird nicht zerstört, nur der Token wird übertragen. Nur Verträge, die in derselben Transaktion wie Selbstzerstörung erstellt wurden, werden zerstört. Die Auswirkungen dieser EIP sind relativ groß.

• Verwenden Sie create2, um den Vertrag an derselben Adresse erneut bereitzustellen und den Vertrag zu aktualisieren. Diese Funktion wird nicht mehr unterstützt und stattdessen sollte ERC-2535 oder eine andere Art von Proxy-Vertrag verwendet werden. (Dies kann sich auf die Sicherheit von On-Chain-Verträgen auswirken, die create2 verwenden, um aktualisierbare Verträge zu implementieren.)

Die SELFDESTRUCT-Operation im Smart-Vertrag ermöglicht die Zerstörung des Vertrags und das Senden des Vertragssaldos an die angegebene Zieladresse. In diesem Fall verwendet der Vertrag SELFDESTRUCT, um den Ether zu zerstören und sendet den zerstörten Ether an den Vertrag. Der Vertrag kann jedoch nur ein Vertrag sein, der in derselben Transaktion erstellt wurde (ein Vertrag, der durch diesen Vertrag oder andere Verträge in derselben Transaktion erstellt wurde). Andernfalls wird nur Ether übertragen, ohne dass der Vertrag zerstört wird (z. B. Selbstzerstörung und der Begünstigte ist der selbstzerstörende Vertrag, der keine Änderungen hervorruft). Dies betrifft alle Verträge, die bei Abhebungen oder anderen Vorgängen auf Selbstzerstörung basieren.

Ein Gas-Token ähnlich dem 1-Zoll-CHI-Token funktioniert, indem es einen Offset beibehält und immer CREATE2 oder SELFDESTRUCT bei diesem Offset ausführt. Wenn sich der Vertrag am aktuellen Offset nach diesem Update nicht korrekt selbst zerstört hat, kann nachfolgendes CREATE2 den Vertrag nicht erfolgreich bereitstellen.

Die Umsetzung dieses Vorschlags wird nicht zu direkten Angriffen auf den Vertrag führen, sondern die normale Logik der ursprünglich eingesetzten Verträge beschädigen, die auf Selbstzerstörungsvorgängen basieren (Verträge, die bei Geldtransfers nur auf Selbstzerstörung basieren, sind nicht betroffen. Wenn nachfolgende Vorgänge eine Selbstzerstörung erfordern (Wenn der zerstörte Vertrag gelöscht wird, ist er betroffen), was dazu führt, dass der Vertrag unerwartet funktioniert. Nur für den Vertrag und den Benutzer kann dies dazu führen, dass der Vertrag in Kraft tritt, Gelder verloren gehen und andere Gefahren auftreten ( Beispielsweise wurde ursprünglich create2 verwendet, um einen neuen Vertrag an der ursprünglichen Adresse bereitzustellen, wodurch der ursprüngliche Vertrag selbst zerstört wurde. Der aktualisierte Vertrag kann nicht mehr erfolgreich bereitgestellt werden. Langfristig kann die Änderung der Funktionalität eines Opcodes zu Zentralisierungsproblemen führen.

Zum Beispiel wird ein bestehender Tresor für Treasury-Verträge aktualisiert:

• Der temporäre Speichervertrag „create2“ wird verwendet, um vorübergehend Gelder im Tresor zu reservieren.

• Zerstören Sie den Tresorvertrag selbst und die Gelder werden in den temporären Vertrag übertragen (nur die Gelder werden übertragen, ohne den Vertrag zu zerstören) )

• 2 neuen Tresorvertrag an der ursprünglichen Adresse erstellen (fehlgeschlagen, weil der ursprüngliche Tresorvertrag nicht zerstört wurde)

• Zerstören Sie den temporären Vertrag selbst und geben Sie die Gelder an zurück der Tresor (Gelder gehen verloren, der Tresorvertrag wird nicht erstellt)

Erweiterte Lektüre

Das Cancun-Upgrade wird den Wettbewerbsvorteil von Ethereum weiter verbessern. Allerdings birgt dieses Upgrade Risiken für die Änderungen an der Kern-Smart-Contract-Schicht, die sich auf den sicheren Betrieb bestehender DApps auswirken. Bei der Entwicklung von Smart Contracts erfordern diese Veränderungen und die damit verbundenen Risiken ebenfalls große Aufmerksamkeit. Sie können Salus kontaktieren, um Unterstützung bei der Risikobewertung oder Prüfung zu erhalten, oder weiterlesen, um mehr über Änderungen zu erfahren. „Cancun Network Upgrade Specification“

GasToken2-Vertrag

Das obige ist der detaillierte Inhalt vonVor dem Upgrade von Ethereum Cancun müssen die Projektentwickler mehrere Sicherheitsüberprüfungen durchführen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!