*Forward the Original Title: Vor dem Upgrade von Cancun müssen Entwickler einige Sicherheitsüberprüfungen durchführen

Zusammenfassung: Mit dem bevorstehenden Cancun-Upgrade umfasst es sechs von EIP vorgeschlagene Änderungen, hauptsächlich EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 und EIP-7516. EIP-4844 konzentriert sich darauf, die Skalierbarkeit von Ethereum zu verbessern, Transaktionskosten zu reduzieren und Transaktionen für Layer-2-Lösungen zu beschleunigen. Das Upgrade wurde auf Ethereum-Testnetzen getestet und ist für die Aktivierung auf dem Mainnet am 13. März geplant. Salus hat wichtige Sicherheitsüberlegungen für Entwickler zusammengestellt, die sie vor dem Upgrade überprüfen sollten.

Überprüfung von EIP-Vorschlägen

Offizielle Sicherheitsüberlegungen

Risiken im Zusammenhang mit Smart Contracts

Weitere Informationen

Überprüfung von EIP-Vorschlägen

EIP-1153

EIP-1153 führt temporäre Speicher-Opcodes ein, die verwendet werden, um den Status auf ähnliche Weise wie der Speicher zu manipulieren, jedoch wird der temporäre Speicher nach jeder Transaktion verworfen. Das bedeutet, dass der temporäre Speicher keine Werte aus dem Speicher deserialisiert oder Werte in den Speicher serialisiert, was zu geringeren Kosten aufgrund der Vermeidung von Festplattenzugriffen führt. Mit der Einführung von zwei neuen Opcodes, TLOAD und TSTORE (wobei "T" für "temporary" steht), können Smart Contracts auf temporären Speicher zugreifen. Dieser Vorschlag zielt darauf ab, eine dedizierte und effiziente Lösung für die Kommunikation zwischen mehreren verschachtelten Ausführungsrahmen während der Transaktionsausführung in Ethereum bereitzustellen.

EIP-4788

EIP-4788 zielt darauf ab, die Hashbaumwurzeln der Beacon-Chain-Blöcke dem EVM zugänglich zu machen, sodass diese Wurzeln innerhalb von Smart Contracts abgerufen werden können. Dies ermöglicht den Zugriff auf den Konsensschichtenstatus ohne Vertrauen und unterstützt verschiedene Anwendungsfälle wie Staking-Pools, Restaking-Strukturen, Smart-Contract-Brücken und MEV-Minderung. Der Vorschlag erreicht dies, indem diese Wurzeln in einem Smart Contract gespeichert und ein zirkulärer Puffer verwendet wird, um den Speicherverbrauch zu begrenzen und sicherzustellen, dass jeder Ausführungsblock nur konstanten Speicherplatz benötigt, um diese Informationen zu repräsentieren.

EIP-4844

EIP-4844 führt ein neues Transaktionsformat namens „Shard Blob Transactions“ ein, das darauf abzielt, die Datenverfügbarkeit von Ethereum in einfacher und rückwärtskompatibler Weise zu erweitern. Dieser Vorschlag erreicht sein Ziel, indem er „Blob-tragende Transaktionen“ einführt, die große Datenmengen enthalten, auf die die EVM nicht zugreifen kann, die aber über ihre Commitments zugänglich sind. Dieses Format ist vollständig kompatibel mit dem Format, das von zukünftigem Full-Sharding verwendet wird, und bietet eine vorübergehende, aber bedeutende Entlastung für die Skalierbarkeit des Rollups.

EIP-5656

EIP-5656 führt eine neue EVM-Anweisung, MCOPY, für effizientes Kopieren von Speicherbereichen ein. Dieser Vorschlag zielt darauf ab, den Overhead von Speicherkopieroperationen auf der EVM zu reduzieren, indem Daten direkt zwischen Speichern mit der MCOPY-Anweisung kopiert werden. MCOPY ermöglicht die Überlappung von Quell- und Zieladressen, ist auf Abwärtskompatibilität ausgelegt und zielt darauf ab, die Ausführungseffizienz in verschiedenen Szenarien zu verbessern, einschließlich Konstruktion von Datenstrukturen, effizientem Zugriff und Kopieren von Speicherobjekten.

EIP-6780

EIP-6780 ändert die Funktionalität des SELFDESTRUCT-Opcodes. In diesem Vorschlag löscht SELFDESTRUCT nur Konten und transferiert alle Ether in derselben Transaktion wie die Vertragsbildung. Darüber hinaus wird bei der Ausführung von SELFDESTRUCT der Vertrag nicht gelöscht, sondern transferiert alle Ether an ein spezifiziertes Ziel. Diese Änderung berücksichtigt die zukünftige Verwendung von Verkle-Bäumen, mit dem Ziel, die Implementierung des EVM zu vereinfachen, die Komplexität von Zustandsänderungen zu reduzieren und gleichzeitig einige gängige Anwendungsfälle von SELFDESTRUCT beizubehalten.

EIP-7516

EIP-7516 führt eine neue EVM-Anweisung, BLOBBASEFEE, ein, um den Basisgebührwert für Blobs in der aktuellen Blockausführung zurückzugeben. Diese Anweisung ähnelt der BASEFEE-Opcode, der in EIP-3198 eingeführt wurde, mit dem Unterschied, dass sie die Blob-Basisgebühr zurückgibt, die gemäß EIP-4844 definiert ist. Diese Funktionalität ermöglicht es Verträgen, den Gaspreis von Blob-Daten programmgesteuert zu berücksichtigen, wodurch Rollup-Verträge die Kosten für die Nutzung von Blob-Daten ohne Vertrauen berechnen oder Blob-Gas-Futures implementieren können, um die Kosten für Blob-Daten zu glätten.

Offizielle Sicherheitsüberlegungen

EIP-1153

Smart Contract-Entwickler sollten den Lebenszyklus von transienten Speichervariablen verstehen, bevor sie diese verwenden. Da der temporäre Speicher am Ende einer Transaktion automatisch gelöscht wird, könnten Smart Contract-Entwickler versuchen, Slots während eines Aufrufs nicht zu löschen, um Gas zu sparen. Dies könnte jedoch weitere Interaktionen mit dem Vertrag innerhalb derselben Transaktion verhindern (z. B. im Fall von rekursiven Sperren) oder zu anderen Fehlern führen. Daher sollten Smart Contract-Entwickler vorsichtig sein und nur nicht-null-Werte beibehalten, wenn der temporäre Speicherslot für zukünftige Aufrufe innerhalb derselben Transaktion reserviert ist. Andernfalls ist das Verhalten dieser Opcodes identisch mit SLOAD und SSTORE, sodass alle üblichen Sicherheitsüberlegungen gelten, insbesondere hinsichtlich Reentrancy-Risiken.

Smart Contract-Entwickler können auch versuchen, den transienten Speicher als Alternative zur Speicherzuordnung zu verwenden. Sie sollten sich darüber im Klaren sein, dass transienter Speicher nicht wie Speicher verworfen wird, wenn ein Aufruf zurückkehrt oder zurückgesetzt wird, und sollten in solchen Fällen den Speicher priorisieren, um unerwartetes Verhalten während einer Reentry im selben Transaktionsfall zu vermeiden. Die hohe Kosten des transienten Speichers im Speicher sollten dieses Nutzungsmuster bereits abschrecken. Die meisten Anwendungsfälle für Zuordnungen im Speicher können besser durch eine sortierte Liste von Einträgen nach Schlüssel implementiert werden, und transienter Speicher in Speicherzuordnungen ist in Smart Contracts selten erforderlich (d.h. keine bekannten Anwendungsfälle in der Produktion).

EIP-4844

Dieses EIP erhöht die Bandbreitenanforderungen für jeden Beacon-Block um bis zu ca. 0,75 MB. Dies entspricht einer Steigerung um 40% gegenüber der theoretischen maximalen Größe der heutigen Blöcke (30M Gas / 16 Gas pro Calldatenbyte = 1,875M Byte), sodass es die Bandbreite in Worst-Case-Szenarien nicht signifikant erhöht. Nach dem Zusammenführen sind die Blockzeiten statisch und nicht mehr unvorhersehbar poissonverteilt, was einen garantierten Zeitrahmen für die Verbreitung großer Blöcke bietet.

Auch bei begrenzten Aufrufdaten ist die aufrechterhaltene Last dieser EIP signifikant niedriger als alternative Lösungen, die die Kosten für Aufrufdaten reduzieren könnten, da der Blob-Speicher nicht für die gleiche Dauer wie die Auslastung aufrechterhalten werden muss. Dies ermöglicht die Implementierung von Strategien, die erfordern, dass diese Blobs für mindestens eine bestimmte Zeitdauer aufbewahrt werden. Der spezifische Wert, der gewählt wird, ist das MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS-Epochen, das ungefähr 18 Tage beträgt, viel kürzer als die vorgeschlagene (aber noch nicht implementierte) einjährige Rotationszeit für die Ausführung gültiger Nutzlasthistorien.

EIP-5656

Kunden sollten darauf achten, dass ihre Implementierungen keine Zwischenpuffer verwenden (z.B. die C-Standardbibliotheksfunktion memmove verwendet keine Zwischenpuffer), da dies ein potenzieller Denial-of-Service-(DoS)-Vektor ist. Die meisten in Sprachen eingebauten Funktionen/Standardbibliotheksfunktionen, die zum Verschieben von Bytes verwendet werden, haben hier die richtigen Leistungsmerkmale.

Zusätzlich ist die Analyse von Denial-of-Service (DoS)- und Memory-Exhaustion-Angriffen dieselbe wie bei anderen Memory-Touching-Operationen, da die Memory-Erweiterung den gleichen Preisregeln folgt.

EIP-6780

Die folgenden Anwendungen von SELFDESTRUCT werden zerstört, und Anwendungen, die es auf diese Weise verwenden, sind nicht mehr sicher:

Wo CREATE2 verwendet wird, um einen Vertrag an derselben Stelle neu bereitzustellen, um Verträge aktualisierbar zu machen. Diese Funktionalität wird nicht mehr unterstützt und sollte durch ERC-2535 oder andere Arten von Proxy-Verträgen ersetzt werden.

Wenn ein Vertrag darauf angewiesen ist, Ether an einen Vertrag durch SELFDESTRUCT zu verbrennen, ist der Vertrag nicht in derselben Transaktion erstellt.

Risiken im Zusammenhang mit Smart Contracts

EIP1153

Betrachten Sie zwei Szenarien unter Verwendung der Opcodes TLOAD und TSTORE:

1. Ruft Verträge verwenden diese Opcodes.
2. Rufverträge verwenden diese Opcodes.

Risiko 1:

Im Vergleich zu den traditionellen SSTORE und SLOAD ändert die Einführung des transienten Speichers hauptsächlich die Speicherdauer der Daten. Daten, die von TSTORE gespeichert werden, werden über TLOAD gelesen und nach der Ausführung einer Transaktion freigegeben, anstatt wie bei SSTORE dauerhaft im Vertrag aufgezeichnet zu werden. Entwickler sollten die Eigenschaften dieser Opcodes verstehen, um zu vermeiden, dass sie falsch verwendet werden, was zu einer fehlerhaften Schreibung der Daten im Vertrag und damit zu Verlusten führen kann. Darüber hinaus sind die von TSTORE gespeicherten Daten privat und können nur vom Vertrag selbst abgerufen werden. Wenn ein externer Zugriff auf diese Daten erforderlich ist, müssen sie durch Parameter übergeben oder vorübergehend in einer öffentlichen Speichervariable gespeichert werden.

Risiko 2:

Ein weiteres potenzielles Risiko besteht darin, dass, wenn die Entwickler von Smart Contracts die Lebensdauer von transienten Speicher variablen nicht korrekt verwalten, dies dazu führen kann, dass Daten zu ungeeigneten Zeiten gelöscht oder falsch beibehalten werden. Wenn ein Vertrag erwartet, Daten, die im transienten Speicher gespeichert sind, in nachfolgenden Aufrufen einer Transaktion zu verwenden, aber nicht ordnungsgemäß die Lebensdauer dieser Daten verwaltet, kann dies dazu führen, dass Daten zwischen verschiedenen Aufrufen fälschlicherweise gemeinsam genutzt oder verloren gehen, was zu logischen Fehlern oder Sicherheitslücken führt. Das Versäumnis, Daten korrekt zu speichern, wie beispielsweise Bilanz- oder Berechtigungsdaten in Tokenprojekten, kann zu logischen Fehlern in Verträgen führen, die zu Verlusten führen. Ebenso kann die Verwendung dieser Opcodes zur Festlegung der Besitzeradresse dazu führen, dass die privilegierte Adresse nicht korrekt erfasst wird, was dazu führt, dass Änderungen an wichtigen Parametern des Vertrags verloren gehen.

Betrachten Sie einen Smart-Vertrag, der den transienten Speicher verwendet, um den Transaktionspreis auf einer Kryptowährungs-Handelsplattform vorübergehend aufzuzeichnen. Der Vertrag aktualisiert den Preis nach jeder Transaktion und ermöglicht es den Benutzern, den neuesten Preis innerhalb kurzer Zeit abzufragen. Wenn das Vertragsdesign jedoch nicht das automatische Löschen des transienten Speichers am Ende einer Transaktion berücksichtigt, kann es eine Zeitspanne zwischen dem Ende einer Transaktion und dem Beginn der nächsten geben, in der Benutzer einen falschen oder veralteten Preis erhalten können. Dies könnte nicht nur dazu führen, dass Benutzer Entscheidungen auf der Grundlage falscher Informationen treffen, sondern auch böswillig ausgenutzt werden und sich negativ auf den Ruf der Plattform und die Sicherheit der Benutzer-Assets auswirken.

EIP-6780

Dieser Vorschlag ändert das Verhalten des vorherigen selfdestruct-Opcodes, bei dem der Vertrag nicht verbrannt wird, sondern nur ein Tokentransfer erfolgt, und nur Verträge, die im selben Transaktionskontext wie der selfdestruct-Vertrag erstellt wurden, werden verbrannt. Die Auswirkungen dieses EIP sind relativ signifikant.

Die Verwendung von create2 zum erneuten Bereitstellen von Verträgen an derselben Adresse für Vertragsupgrades wird nicht mehr unterstützt. Diese Funktionalität sollte durch ERC-2535 oder andere Arten von Proxy-Verträgen ersetzt werden. (Dies kann die Sicherheit von On-Chain-VerträgeImplementierung von aktualisierbaren Verträgen unter Verwendung von create2).

Die SELFDESTRUCT-Operation in Smart Contracts ermöglicht es, Verträge zu verbrennen und das Vertragsguthaben an eine angegebene Zieladresse zu senden. In diesem Fall verwendet der Vertrag SELFDESTRUCT, um Ether zu verbrennen und den verbrannten Ether an den Vertrag zu senden. Dieser Vertrag muss jedoch nur im selben Transaktionskontext wie andere Verträge erstellt werden (Verträge, die von diesem Vertrag oder anderen Verträgen in derselben Transaktion erstellt wurden). Andernfalls wird Ether nur übertragen, ohne den Vertrag zu verbrennen (zum Beispiel selfdestruct mit dem Begünstigten als der selfdestruct-Vertrag, was keine Änderungen bewirken wird). Dies wird sich auf alle Verträgedie sich auf die selfdestruct Funktion für Auszahlungen oder andere Operationen verlassen.

Ein Gas-Token ähnlich dem 1inch CHI-Token funktioniert wie folgt: Es hält eine Versatzposition aufrecht, setzt immer CREATE2 oder SELFDESTRUCT an diesem Versatz ein. Nach diesem Update können nachfolgende CREATE2 bei nicht korrekter Selbstzerstörung des Vertrags am aktuellen Versatz keine Verträge erfolgreich bereitstellen.

Diese Vorschlagsimplementierung kann Verträge nicht direkt angreifen, aber sie wird die normale Logik bestehender Verträge, die auf selfdestruct-Operationen angewiesen sind, beeinträchtigen (Verträge, die nur auf selfdestruct für Fondstransfers angewiesen sind, sind nicht betroffen, aber Verträge, die nachfolgende Operationen erfordern, um selfdestruct-Verträge zu löschen, sind betroffen), was dazu führt, dass Verträge unerwartet arbeiten und zu Vertragsstreiks, Geldverlust usw. führen kann (zum Beispiel können Verträge, die ursprünglich create2 zur Bereitstellung neuer Verträge an der ursprünglichen Adresse verwendet haben und den ursprünglichen Vertrag für ein Upgrade selbst zerstört haben, nicht mehr erfolgreich bereitgestellt werden). Langfristig kann die Änderung der Funktionalität eines Opcodes Zentralisierungsprobleme mit sich bringen.

Zum Beispiel gibt es einen bestehenden Vault-Vertrag für Updates:

• Temporäre Speicherverträge, create2, werden verwendet, um vorübergehend Mittel für den Tresor zu reservieren.
• Den Tresorvertrag selbstzerstören und die Mittel auf den temporären Vertrag übertragen (nur die Mittel werden übertragen, ohne den Vertrag zu löschen).
• Erstellen Sie einen neuen Tresorvertrag an der ursprünglichen Adresse mit create2 (schlägt fehl, weil der ursprüngliche Tresorvertrag nicht verbrannt wurde).
• Selbstzerstörung des temporären Vertrags, um die Gelder an den Tresor zurückzugeben (Gelder verloren, der Tresorvertrag wurde nicht erstellt).

Erweiterte Lektüre:

Das Cancun-Upgrade wird den Wettbewerbsvorteil von Ethereum weiter verbessern. Die Änderungen an der Kern-Smart-Vertrags-Schicht in diesem Upgrade bringen jedoch Risiken mit sich, die sich auf den sicheren Betrieb bestehender DApps auswirken werden. Während der Entwicklung von Smart Contracts müssen diese Änderungen und die potenziellen Risiken, die sie mit sich bringen können, genau überwacht werden. Sie können sich an Salus wenden, um Risikoprüfungen oder Auditunterstützung durchzuführen, oder weitere Informationen, um die Änderungen zu verstehen.

Cancun Netzwerk-Upgrade-Spezifikation

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

Metapod-Vertrag

GasToken2 Vertrag

Haftungsausschluss：

1. Dieser Artikel stammt aus [ Aicoin], Weiterleitung des Originaltitels 'Salus Insights: Vor dem Upgrade von Cancun sollten Entwickler einige wichtige Sicherheitschecks durchführen'. Alle Urheberrechte gehören dem Originalautor [Gate*Odaily Planet Daily]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die Gate LearnTeam, und sie werden es umgehend bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel geäußert werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel verboten.