Zum Inhalt springen
Financial Context Wiki

Eine CREATE2-Vertragsadresse verifizieren

CREATE2 prognostiziert eine Adresse aus Deployer, Salt und dem Hash des Init-Codes; die Verifizierung erfordert jedoch weiterhin kettenbezogene Nachweise zu Factory, Bytecode, Deployment, Proxy und Kontrolle.

Aktualisiert

Nur zu Bildungszwecken; keine Anlage- oder Sicherheitsberatung. Eine vorhergesagte Adresse, ein leeres Konto, ein Checksum oder ein Factory-Label beweisen weder Deployment, Code, Kontrolle, Eigentum noch Sicherheit.

Direkte Antwort

CREATE2 prognostiziert die von einem bestimmten Deployer-Vertrag erzeugte Adresse aus einem 32-byte salt und dem Hash des exakten init_code. Die Protokollformel lautet address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:]: Zuerst wird ein 85-byte preimage gehasht, dann werden die letzten 20 bytes behalten. Der Deployer ist die Factory, die CREATE2 ausführt, nicht unbedingt das Wallet, das die Factory aufgerufen hat.

init_code ist der Creation-Bytecode einschließlich ABI-kodierter Konstruktorargumente; er wird einmal ausgeführt und erzeugt den Runtime-Bytecode. Compiler-Version, Optimierung, verknüpfte Bibliotheken, Metadaten, Konstruktorargumente oder der Factory-Einstiegspunkt können den Hash ändern. Runtime-Code ist ein Ergebnis, nicht die CREATE2-Eingabe. Dieselbe Adresse ist nur bei identischem Deployer, Salt, Init-Code, EVM-Regeln und Chain-State vergleichbar.

Eine kontrafaktische Adresse kann vor dem Vorhandensein von Code Geld empfangen, besitzt aber noch keine verifizierte Kontrolllogik. Die Vorhersage beweist weder Deployment, Eigentum, Autorisierung, Finalität noch Sicherheit. Prüfe Factory-Bytecode und Calldata, Receipt und Events, eth_getCode, Nonce, Storage, Guthaben, Proxy-Implementierung, Initializer und Owner auf der vorgesehenen Chain und in dem vorgesehenen Block.

Funktionsweise

Fixiere Chain oder Domain, Fork-Regeln, RPC und Block, Factory-Adresse und Runtime-Hash, rohen Salt, exakte Init-Bytes, Konstruktor-Encoding, Compiler und verknüpfte Bibliotheken. Berechne keccak256(init_code) und das 85-byte preimage erneut; normalisiere ABI-Padding, Endianness, Checksum und die Extraktion der letzten 20 Bytes.

Dekodiere anschließend den Factory-Call und den übertragenen Wert. Bestätige, dass vorgesehene Factory, Entry Point, Salt-Domain, Konstruktor, Owner und Initializer gebunden sind. Bei einem Minimal-Proxy wird der Creation-Bytecode des Clones gehasht, der die Implementierungsadresse enthält, nicht der Runtime-Code der Implementierung. Bei einem Proxy sind Implementierung, Admin, Storage-Slots und Upgrade-Policy separat zu prüfen.

EIP-684 lässt die Erstellung revertieren, wenn die Ziel-Nonce ungleich null oder der Code nicht leer ist. Auch ein fehlgeschlagener Konstruktor hinterlässt kein gültiges Deployment. Annahmen zu SELFDESTRUCT und späterem Redeployment hängen von den Fork-Regeln ab; verlasse dich niemals auf die veraltete Behauptung, Code könne jederzeit beliebig ersetzt werden.

Deployment-Nachweise haben Ebenen: Transaktionseinschluss und Status, emittierte Events, Code und Nonce, Storage und Guthaben und anschließend ein sicherer oder finaler Chain-State. Eine erfolgreiche RPC-Antwort oder vorhergesagte Checksum ersetzt nicht die Prüfung von Receipt und State. Kopien derselben Adresse auf verschiedenen Chains können unterschiedlichen Code, Owner, Storage und unterschiedliche Assets haben.

Nutze diesen Ablauf:

  1. Fixiere Chain, Fork, RPC und Block; Factory- oder Deployer-Adresse und Runtime-Hash; Salt-Bytes; Init-Code, Konstruktorargumente, Compiler und verknüpfte Bibliotheken.
  2. Berechne Init-Code-Hash und exaktes CREATE2-Preimage und prüfe Breiten, Padding, 0xff, die letzten 20 Bytes und die Checksum.
  3. Dekodiere Factory-Calldata und Wert; vergleiche vorhergesagte Adresse, Owner, Initializer, Proxy-Ziel und vorgesehene Berechtigungen.
  4. Prüfe Receipt, Status, Events, eth_getCode, Nonce, Guthaben und Storage auf der richtigen Chain; erfasse Nicht-Deployment und Collision-Zustände.
  5. Untersuche Factory, Proxy, Implementierung, Admin, Initializer, Upgrades und Singleton-Factory-Annahmen einschließlich ERC-1167-Zielen.
  6. Teste Konstruktorfehler, Nonce-/Code-Collision, Fork-abhängiges Redeployment, verschachtelte Factories und Chain-Domain- oder Replay-Annahmen.
  7. Vor Funding oder Signatur gleiche menschliche und rohe Beträge ab; nach dem Deployment Code-Hash, Owner, Implementierung, Rollen, Events und Finalität überwachen.

Beispiele

  • EIP-1014-Vektor: Deployer 0x0000000000000000000000000000000000000000, nuller Salt, Init 0x00 ergibt 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38.
  • Konstruktorbindung: Bei festem Deployer und Salt ändert ein anderes ABI-kodiertes Konstruktorargument keccak256(init_code) und damit die vorhergesagte Adresse; das Hashen des Runtime-Codes würde das falsche Objekt verifizieren.
  • Collision: Ist die Ziel-Nonce größer als 0 oder der Code nicht leer, muss CREATE2 nach EIP-684 revertieren. Eine finanzierte Adresse mit leerem Code und Nonce null ist nur kontrafaktisch und weiterhin unverifiziert.
  • Minimal-Proxy: Die Adresse eines ERC-1167-Clones hasht den Creation-Bytecode des Clones mit der Implementierungsadresse. Das Hashen des Runtime-Codes der Implementierung ergibt eine andere Vorhersage.

Risiken

  • Die falsche Factory oder der falsche Deployer wird verwendet.
  • Salt-Breite, Padding, Endianness oder Domain-Encoding sind falsch.
  • Init-Code wird mit Runtime-Bytecode verwechselt.
  • Konstruktorargumente fehlen oder sind falsch angeordnet.
  • Factory-Entry-Point, Wert oder Calldata weichen ab.
  • Proxy- oder Delegatecall-Ziel ist nicht die vorgesehene Implementierung.
  • Chain, Fork oder EVM-Domain unterscheiden sich.
  • Eine vorhandene Nonce verursacht eine Collision.
  • Vorhandener Code verursacht eine Collision.
  • Veraltete Annahmen zu Redeployment nach SELFDESTRUCT werden genutzt.
  • Verschachteltes CREATE2 ändert den effektiven Deployer.
  • CREATE- und CREATE2-Formeln werden vermischt.
  • Das ERC-1167-Implementierungsziel wird nicht geprüft.
  • Singleton-Factory-Adresse oder Deployment-Annahmen sind ungeprüft.
  • Implementierungs-Upgrade oder Admin-Kontrolle ändert das Verhalten.
  • Compiler, Metadaten, Bibliothek oder Source-Artefakt weichen ab.
  • Receipt, Mempool, Fehler und Finalitätszustand werden verwechselt.
  • Checksum oder UI-Poisoning verbirgt eine falsche Adresse.
  • Vorfinanzierte kontrafaktische Gelder haben keinen Eigentumsnachweis.
  • Annahmen zu EIP-7702, Replay, Gas, Denial-of-Service oder veralteter Überwachung sind falsch.

Häufige Irrtümer

  • „Eine leere Adresse ist sicher oder gehört jemandem.“ Sie kann ohne Code und verifizierten Controller sein.
  • „Allein der Salt bestimmt die Adresse.“ Deployer und Init-Code-Hash sind ebenfalls bindend.
  • „CREATE2 hasht Runtime-Bytecode.“ Gehasht wird Creation-Code einschließlich Konstruktorargumenten.
  • „Dieselbe Adresse auf zwei Chains bedeutet gleichen Code und gleiche Kontrolle.“ State und Deployment jeder Chain müssen unabhängig geprüft werden.
  • „Eine erfolgreiche Vorhersage beweist Deployment und Sicherheit.“ Erst Receipt, Code, State, Berechtigungen und Finalität belegen, was existiert.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...