Das Cancun-Upgrade steht bald bevor. Worauf ist zu achten und welche Risiken bestehen?

Lange Rede, kurzer Sinn: Das Cancun-Upgrade rückt näher und 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, die zur Zustandsmanipulation verwendet werden und sich fast genauso verhalten wie Speicher, aber der temporäre Speicher wird nach jeder Transaktion verworfen. 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 „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. Dieser Vorschlag zielt darauf ab, die Kosten für Speicherkopiervorgänge auf dem EVM zu reduzieren und Daten über den MCOPY-Befehl direkt zwischen Speichern zu kopieren. 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 und dem effizienten Zugriff und Kopieren von Speicherobjekten zu optimieren.

EIP-6780

EIP-6780 Die Funktionalität des SELFDESTRUCT-Opcodes wurde geändert. In diesem Vorschlag löscht SELFDESTRUCT nur das Konto und überträgt den gesamten Ether in derselben Transaktion, in der der Vertrag erstellt wurde. Darüber hinaus wird bei der Ausführung von SELFDESTRUCT der Vertrag nicht gelöscht, sondern der gesamte Ether wird 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 den Blob-Basisgebührenwert in der aktuellen Blockausführung zurückgibt. Dieser Befehl ähnelt dem BASEFEE-Opcode von EIP-3198, außer dass er die Blob-Basisgebühr zurückgibt, wie in EIP-4844 definiert. 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. Ansonsten verhalten sich diese Opcodes genau wie SSTORE und SLOAD , sodass alle üblichen Sicherheitsüberlegungen gelten, insbesondere im Hinblick auf Wiedereintrittsrisiken.

Smart-Contract-Entwickler 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 M Gas / 16 Gas pro Anrufdatenbyte = 1,875 M Bytes), 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 Wert ist die MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS-Epoche, die etwa 18 Tage beträgt, was eine viel kürzere Latenz als die empfohlene (aber noch nicht implementierte) einjährige Rotation für die Ausführung des Nutzlastverlaufs darstellt.

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 folgenden Anwendungen SELFDESTRUCT werden beschädigt und Anwendungen, die es 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 Verbrennung von Äther basiert und ein SELFDESTRUCT-Vertrag als Begünstigter vorliegt, wurde der Vertrag nicht in derselben Transaktion erstellt. Risiken im Zusammenhang mit Smart Contracts

Verglichen Bei herkömmlichem SSTORE und SLOAD ändert sich durch die neue vorübergehende Speicherung hauptsächlich die Speicherdauer der in tstore gespeicherten Daten, und die Daten werden nach der Ausführung einer Transaktion freigegeben. Der schriftliche Vertrag wird nicht dauerhaft aufgezeichnet . 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 gelöscht werden, wenn dies nicht der Fall sein sollte, oder dass sie 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 die 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 in einem Smart Contract 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 er 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 für den Geldtransfer 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 der Gelder werden übertragen, ohne den Vertrag zu zerstören)
• Erstellen2 eines neuen Tresorvertrags an der ursprünglichen Adresse (fehlgeschlagen, weil der ursprüngliche Tresorvertrag nicht zerstört wurde)
• Der selbstzerstörende temporäre Vertrag gibt die Gelder an den Tresor zurück (Gelder gehen verloren, der Tresor Vertrag kommt nicht zustande)

Das obige ist der detaillierte Inhalt vonDas Cancun-Upgrade steht bald bevor. Worauf ist zu achten und welche Risiken bestehen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!