Was ist der CREATE2-Opcode und wie ermöglicht er deterministische Vertragsadressen?

Den CREATE2-Opcode in Ethereum verstehen

1. Der CREATE2-Opcode wurde in Ethereum durch EIP-1014 während des Constantinople-Upgrades eingeführt. Es dient als Alternative zum herkömmlichen CREATE-Opcode, der intelligente Verträge mithilfe einer Absender-Nonce bereitstellt, um die resultierende Vertragsadresse zu ermitteln. Im Gegensatz zu CREATE können Entwickler mit CREATE2 die Adresse eines Vertrags vor der Bereitstellung berechnen, indem sie bestimmte Eingaben außer der Nonce berücksichtigen.

2. Diese Funktionalität ist in Szenarien von entscheidender Bedeutung, in denen die Vorhersehbarkeit von Vertragsadressen erforderlich ist. Beispielsweise müssen Off-Chain-Systeme oder Layer-2-Lösungen möglicherweise auf einen Vertrag verweisen, der noch nicht bereitgestellt wurde. Durch die Vorabberechnung von Adressen unterstützt CREATE2 vertrauenswürdige Interaktionen und verbessert die Koordination zwischen dezentralen Komponenten.

3. Die Struktur der von CREATE2 generierten Adresse basiert auf einem kryptografischen Hash mit vier Elementen: der Adresse des Bereitstellers, einem benutzerdefinierten Salt (ein 32-Byte-Wert), dem Bytecode des Vertrags (auch als init_code bekannt) und dem keccak256-Hash dieses Bytecodes. Da keine dieser Eingaben von der Transaktionsanzahl des Absenders abhängt, ergibt dieselbe Kombination immer dieselbe Adresse.

4. Ein wesentlicher Vorteil dieses Mechanismus ist die Möglichkeit, Verträge unter bestimmten Bedingungen bereitzustellen. Ein Vertrag kann nur dann umgesetzt werden, wenn bestimmte Bedingungen erfüllt sind, seine zukünftige Adresse bleibt jedoch im Voraus bekannt. Dies ermöglicht Anwendungsfälle wie die kontrafaktische Instanziierung, bei der Anwendungen die Existenz eines Vertrags an einem bekannten Ort annehmen, noch bevor er in der Kette aktiv ist.

Deterministische Adressgenerierung erklärt

1. Deterministische Vertragsadressen bedeuten, dass bei gleichen Eingaben die Ausgabeadresse immer identisch ist. Bei CREATE2 lautet die verwendete Formel keccak256(0xff + address + salt + keccak256(init_code))[12:] . Das Präfix 0xff gewährleistet die Trennung des Namensraums von den über CREATE erstellten Adressen und reduziert so das Kollisionsrisiko.

2. Der Salzparameter spielt eine entscheidende Rolle. Es wird vom Entwickler ausgewählt und kann aussagekräftige Daten wie Benutzerkennungen, Zeitstempel oder anwendungsspezifische Schlüssel kodieren. Solange der Salt und andere Komponenten unverändert bleiben, führt die erneute Bereitstellung desselben Bytecodes von derselben Erstelleradresse zu genau demselben Ziel.

3. Da die Adresse vom Hash des Initialisierungscodes und nicht vom Laufzeitcode abhängt, ändert jede Änderung der Konstruktorargumente oder des kompilierten Bytecodes die endgültige Adresse. Dies macht Bereitstellungen sehr empfindlich gegenüber Kompilierungsdetails und erfordert eine sorgfältige Versionskontrolle und reproduzierbare Builds.

4. Entwickler nutzen häufig die deterministische Adressierung für Wallet-Fabriken, bei denen jeder Benutzer ein eindeutig abgeleitetes Smart-Contract-Wallet erhält. Diese Wallets können außerhalb der Kette erwartet werden, sodass Transaktionen bereits vor der Bereitstellung korrekt weitergeleitet werden können.

Anwendungen in dezentralen Finanz- und Layer-2-Systemen

1. Bei dezentralen Börsen und automatisierten Market Makern erleichtert CREATE2 die Erstellung von Pools mit vorhersehbaren Adressen. Dies vereinfacht die Integration für Frontends und Bots, die Pooldaten abfragen können, ohne auf Ereignisprotokolle warten oder sich auf Registrierungen verlassen zu müssen.

2. Layer-2-Skalierungslösungen wie State Channels und Rollups nutzen CREATE2 für die kontrafaktische Vertragsbereitstellung. Teilnehmer eines Kanals können mit einer virtuellen Vertragsinstanz interagieren und wissen genau, wo sie sich befinden würde, wenn sie jemals in der Kette zustande käme. Dadurch wird der Fußabdruck in der Kette reduziert und gleichzeitig die Sicherheitsgarantien gewahrt.

3. Smart-Contract-Wallets wie jene, die mit ERC-4337 (Kontoabstraktion) kompatibel sind, basieren auf deterministischen Adressen, um ein nahtloses Benutzererlebnis zu ermöglichen. Benutzer können Gelder an ihre zukünftige Wallet-Adresse erhalten, bevor diese existiert, da die Finanzierungstransaktionen auf den vorab berechneten Standort abzielen.

4. Ein weiterer Anwendungsfall betrifft aktualisierbare Proxy-Muster, bei denen der Implementierungsvertrag deterministisch bereitgestellt wird. Obwohl Proxys normalerweise CREATE verwenden, verbessert die Kombination mit CREATE2-basierten Fabriken die Modularität und Überprüfbarkeit über Bereitstellungen hinweg.

Häufig gestellte Fragen

A: Nein. Wenn an einer berechneten CREATE2-Adresse bereits ein Vertrag vorhanden ist, schlägt der Versuch, dort einen anderen Vertrag bereitzustellen, fehl. Das EVM verhindert das Überschreiben von vorhandenem Code und sorgt so für Unveränderlichkeit, sobald eine Adresse belegt ist.

F: Wie wirkt sich der Salt-Wert auf die Sicherheit in CREATE2-Bereitstellungen aus?

A: Das Salz muss sorgfältig ausgewählt werden. Vorhersehbare Salze können es Angreifern ermöglichen, vorab bösartige Verträge an erwarteten Adressen bereitzustellen. Durch die Verwendung sicherer Zufälligkeiten oder eindeutiger Kennungen wird dieses Risiko gemindert, insbesondere in Umgebungen ohne Berechtigungen.

F: Ist CREATE2 in Bezug auf Gas teurer als CREATE?

A: Ja. CREATE2 verbraucht aufgrund der zusätzlichen Hashing-Vorgänge, die zur Berechnung der deterministischen Adresse erforderlich sind, im Allgemeinen mehr Gas. Die genauen Kosten hängen von der Größe des init_code und den Netzwerkbedingungen zum Zeitpunkt der Bereitstellung ab.