Vai al contenuto
Financial Context Wiki

Come verificare un indirizzo di contratto CREATE2

CREATE2 prevede un indirizzo a partire dal deployer, dal salt e dall'hash del codice di inizializzazione, ma la verifica richiede comunque prove specifiche della chain su factory, bytecode, deployment, proxy e controllo.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Nota di sicurezza: un indirizzo previsto, un account vuoto, un checksum o un’etichetta della factory non dimostrano deployment, codice, controllo, proprietà o sicurezza.

Risposta diretta

CREATE2 prevede l’indirizzo creato da uno specifico contratto deployer a partire da un 32-byte salt e dall’hash del suo init_code esatto. La formula del protocollo è address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:]: calcola l’hash di un 85-byte preimage e conserva gli ultimi 20 bytes. Il deployer è la factory che esegue CREATE2, non necessariamente il wallet che ha chiamato la factory.

init_code è il bytecode di creazione più gli argomenti del costruttore codificati ABI; viene eseguito una volta e produce il bytecode di runtime. La versione del compilatore, l’ottimizzazione, le librerie collegate, i metadati, gli argomenti del costruttore o l’entry point della factory possono cambiare l’hash. Il codice di runtime è un risultato, non l’input di CREATE2. Lo stesso indirizzo è confrontabile solo con lo stesso deployer, salt, codice di inizializzazione, regole EVM e stato della chain.

Un indirizzo controfattuale può ricevere fondi prima che esista il codice, ma non ha ancora una logica di controllo verificata. La previsione non dimostra deployment, proprietà, autorizzazione, finalità o sicurezza. Verifica bytecode e calldata della factory, receipt ed eventi, eth_getCode, nonce, storage, saldo, implementazione del proxy, initializer e owner sulla chain e al blocco previsti.

Come funziona

Fissa chain o dominio, regole del fork, RPC e blocco, indirizzo della factory e hash del runtime, salt grezzo, byte esatti dell’init, codifica del costruttore, compilatore e librerie collegate. Ricalcola keccak256(init_code) e il 85-byte preimage; normalizza padding ABI, endianess, checksum ed estrazione degli ultimi 20 byte.

Poi decodifica la chiamata e il valore inviati alla factory. Conferma che factory, entry point, dominio del salt, costruttore, owner e initializer previsti siano vincolati. Per un minimal proxy, calcola l’hash del bytecode di creazione del clone che contiene l’indirizzo dell’implementazione, non del runtime dell’implementazione. Per un proxy, verifica separatamente implementazione, admin, storage slot e policy di upgrade.

EIP-684 fa revertire la creazione quando il nonce di destinazione è diverso da zero o il codice non è vuoto. Anche un costruttore fallito non lascia un deployment valido. Le assunzioni su SELFDESTRUCT e sul redeployment dipendono dalle regole del fork; non fare affidamento sulla vecchia affermazione che il codice possa essere sostituito a piacere.

Le prove del deployment hanno livelli: inclusione e stato della transazione, eventi emessi, codice e nonce, storage e saldi, poi uno stato sicuro o finalizzato. Una risposta RPC riuscita o un checksum previsto non sostituisce la verifica di receipt e stato. Copie dello stesso indirizzo su chain diverse possono avere codice, owner, storage e asset diversi.

Usa questo flusso:

  1. Fissa chain, fork, RPC e blocco; indirizzo di factory o deployer e hash del runtime; byte del salt; codice init, argomenti del costruttore, compilatore e librerie collegate.
  2. Calcola l’hash del codice init e il preimage CREATE2 esatto, controllando larghezze, padding, 0xff, gli ultimi 20 byte e il checksum.
  3. Decodifica calldata e valore della factory; confronta indirizzo previsto, owner, initializer, destinazione del proxy e permessi desiderati.
  4. Verifica receipt, stato, eventi, eth_getCode, nonce, saldo e storage sulla chain corretta; registra stati non deployed e di collisione.
  5. Ispeziona factory, proxy, implementazione, admin, initializer, upgrade e assunzioni sulla Singleton Factory, inclusi i target ERC-1167.
  6. Testa errore del costruttore, collisione per nonce/codice, redeployment sensibile al fork, factory annidate e assunzioni su dominio della chain o replay.
  7. Prima di finanziare o firmare, riconcilia importi umani e grezzi; dopo il deployment monitora hash del codice, owner, implementazione, ruoli, eventi e finalità.

Esempi

  • Vettore EIP-1014: deployer 0x0000000000000000000000000000000000000000, salt nullo, init 0x00 produce 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38.
  • Vincolo del costruttore: con deployer e salt fissi, cambiare un argomento del costruttore codificato ABI cambia keccak256(init_code) e quindi l’indirizzo previsto; fare l’hash del runtime verificherebbe l’oggetto sbagliato.
  • Collisione: se il nonce di destinazione è maggiore di 0 o il codice non è vuoto, CREATE2 deve fare revert secondo EIP-684. Un indirizzo finanziato con codice vuoto e nonce zero è solo controfattuale e resta non verificato.
  • Minimal proxy: l’indirizzo di un clone ERC-1167 fa l’hash del bytecode di creazione del clone che contiene l’indirizzo dell’implementazione. Fare l’hash del runtime dell’implementazione produce una previsione diversa.

Rischi

  • Viene usata la factory o il deployer sbagliato.
  • Larghezza, padding, endianess o codifica del dominio del salt sono errati.
  • Il codice init viene confuso con il bytecode di runtime.
  • Gli argomenti del costruttore sono omessi o riordinati.
  • Entry point, valore o calldata della factory differiscono.
  • Proxy o destinazione delegatecall non è l’implementazione prevista.
  • Chain, fork o dominio EVM differiscono.
  • Un nonce esistente causa una collisione.
  • Un codice esistente causa una collisione.
  • Si usano assunzioni obsolete sul redeployment dopo SELFDESTRUCT.
  • CREATE2 annidato cambia il deployer effettivo.
  • Le formule CREATE e CREATE2 vengono confuse.
  • Il target di implementazione ERC-1167 non è verificato.
  • Indirizzo o assunzioni di deployment della Singleton Factory non sono verificati.
  • Un upgrade dell’implementazione o il controllo dell’admin cambia il comportamento.
  • Compilatore, metadati, libreria o artefatto sorgente differiscono.
  • Receipt, mempool, errore e stato finalizzato vengono confusi.
  • Checksum o avvelenamento dell’interfaccia nascondono un indirizzo sbagliato.
  • Fondi prefinanziati controfattuali non hanno prova di proprietà.
  • Sono errate le assunzioni su EIP-7702, replay, gas, denial-of-service o monitoraggio obsoleto.

Idee sbagliate comuni

  • «Un indirizzo vuoto è sicuro o posseduto». Potrebbe non avere codice né un controller verificato.
  • «Il salt da solo determina l’indirizzo». Anche deployer e hash del codice init sono vincolanti.
  • «CREATE2 fa l’hash del bytecode di runtime». Fa l’hash del codice di creazione, inclusi gli argomenti del costruttore.
  • «Lo stesso indirizzo su due chain implica stesso codice e controllo». Stato e deployment di ogni chain vanno verificati separatamente.
  • «Una previsione riuscita prova deployment e sicurezza». Solo receipt, codice, stato, permessi e finalità stabiliscono cosa esiste.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...