Lange Rede, kurzer Sinn: Das Cancun-Upgrade rückt näher. Dieses Upgrade enthält hauptsächlich Änderungen der Ausführungsschicht, 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 Testnetzen Ethereum 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-Vorschlagsüberprüfung
Offiziell offengelegte Sicherheitsaspekte
Smart Contract-bezogene Risiken
Erweiterte Lektüre
EIP-1153 führt temporäre Speicher-Opcodes für diese Vorgänge ein. Codes werden verwendet für den Betriebszustand und verhalten sich fast genauso wie Speicher, der temporäre Speicher wird jedoch nach jeder Transaktion verworfen. Dies bedeutet, dass der temporäre Speicher keine Werte aus dem Speicher deserialisiert oder 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). Dieser Vorschlag zielt darauf ab, eine dedizierte und effiziente Lösung für die Kommunikation zwischen mehreren verschachtelten Ausführungsframeworks bei der Transaktionsausführung von Ethereum bereitzustellen.
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 führt ein neues Transaktionsformat namens „Sharded Blob Transactions“ ein, das die Datenverfügbarkeit von Ethereum auf einfache, vorwärtskompatible Weise erweitern soll. 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 führt einen neuen EVM-Befehl MCOPY zum effizienten Kopieren von Speicherbereichen ein. Dieser Vorschlag zielt darauf ab, den Overhead beim Durchführen von Speicherkopiervorgängen auf dem EVM zu reduzieren und Daten direkt zwischen Speichern über den MCOPY-Befehl zu kopieren. MCOPY ermöglicht die Überlappung von Quell- und Zieladressen. Es wurde unter Berücksichtigung der Abwärtskompatibilität entwickelt und zielt darauf ab, die Ausführungseffizienz in einer Vielzahl von Szenarien zu verbessern, einschließlich der Erstellung von Datenstrukturen, des effizienten Zugriffs und des Kopierens von Speicherobjekten.
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 führt eine neue EVM-Anweisung BLOBBASEFEE ein, die zur Rückgabe des Blob-Basisgebührenwerts in der aktuellen Blockausführung verwendet wird. Diese Anweisung ähnelt dem BASEFEE-Opcode in EIP-3198, außer dass sie 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.
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 vorübergehenden Speicherkosten 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).
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 Zusammenführung sind die Blockzeiten statisch und nicht unvorhersehbar Poisson-verteilt, 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 ungefähr 18 Tage beträgt, was eine viel kürzere Verzögerung im Vergleich zur empfohlenen (aber noch nicht implementierten) einjährigen Rotation für die Ausführung des Nutzlastverlaufs darstellt.
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.
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.
Betrachten Sie zwei Szenarien mit den Opcodes TLOAD und TSTORE:
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 nicht die Funktion 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.
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 den Vertrag zu zerstören (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 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 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)
den temporären Vertrag selbst zerstören und die Gelder an zurückgeben der Tresor (Gelder gehen verloren, der Tresorvertrag wird nicht erstellt)
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.
Das obige ist der detaillierte Inhalt vonWichtige Sicherheitskontrollen vor dem Upgrade in Cancun. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Formelle Handelsplattform für digitale Währungen
Was ist Kryptowährung Kol
Die vielversprechendste Münze im Jahr 2024
Wie hoch wird Ethereum steigen?
Ethereum-Preisangebote
Der heutige Marktpreis von Ethereum
Schauen Sie sich die zehn Kryptowährungen an, in die sich eine Investition lohnt
Warum kann ich nicht auf den Ethereum-Browser zugreifen?
