Aller au contenu
Financial Context Wiki

Vérifier une adresse de contrat CREATE2

CREATE2 prédit une adresse à partir du déployeur, du salt et du hachage du code d'initialisation, mais la vérification exige aussi des preuves propres à la chaîne sur la factory, le bytecode, le déploiement, le proxy et le contrôle.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Note de sécurité : une adresse prédite, un compte vide, une somme de contrôle ou un libellé de factory ne prouvent ni le déploiement, ni le code, ni le contrôle, ni la propriété, ni la sécurité.

Réponse directe

CREATE2 prédit l’adresse créée par un contrat déployeur précis à partir d’un 32-byte salt et du hachage de son init_code exact. La formule du protocole est address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:] : elle hache un 85-byte preimage et conserve les derniers 20 bytes. Le déployeur est la factory qui exécute CREATE2, pas nécessairement le portefeuille qui a appelé la factory.

init_code est le bytecode de création auquel s’ajoutent les arguments de constructeur encodés en ABI ; il s’exécute une fois et produit le bytecode d’exécution. La version du compilateur, l’optimisation, les bibliothèques liées, les métadonnées, les arguments du constructeur ou le point d’entrée de la factory peuvent modifier le hachage. Le code d’exécution est une sortie, pas l’entrée de CREATE2. Une même adresse n’est comparable qu’avec le même déployeur, salt, code d’initialisation, règles EVM et état de la chaîne.

Une adresse contrefactuelle peut recevoir des fonds avant que du code existe, mais elle n’a pas encore de logique de contrôle vérifiée. La prédiction ne prouve ni déploiement, ni propriété, ni autorisation, ni finalité, ni sécurité. Vérifiez le bytecode et le calldata de la factory, le reçu et les événements, eth_getCode, le nonce, le stockage, le solde, l’implémentation du proxy, l’initialiseur et le propriétaire sur la chaîne et au bloc prévus.

Fonctionnement

Figez la chaîne ou le domaine, les règles du fork, le RPC et le bloc, l’adresse de la factory et le hash du runtime, le salt brut, les octets init exacts, l’encodage du constructeur, le compilateur et les bibliothèques liées. Recalculez keccak256(init_code) et le 85-byte preimage ; normalisez le padding ABI, l’endianness, la somme de contrôle et l’extraction des 20 derniers octets.

Décodez ensuite l’appel et la valeur envoyés à la factory. Confirmez que la factory, le point d’entrée, le domaine du salt, le constructeur, le propriétaire et l’initialiseur prévus sont bien liés. Pour un proxy minimal, hachez le bytecode de création du clone qui contient l’adresse de l’implémentation, et non le runtime de l’implémentation. Pour un proxy, vérifiez séparément l’implémentation, l’administrateur, les slots de stockage et la politique de mise à niveau.

L’EIP-684 fait échouer la création lorsque le nonce de destination n’est pas nul ou que le code n’est pas vide. Un constructeur qui échoue ne laisse pas non plus de déploiement valide. Les hypothèses sur SELFDESTRUCT et le redéploiement ultérieur dépendent des règles du fork ; ne vous fiez jamais à l’ancienne idée selon laquelle le code peut toujours être remplacé à volonté.

Les preuves de déploiement se vérifient par couches : inclusion et statut de la transaction, événements émis, code et nonce, stockage et soldes, puis état sûr ou finalisé. Une réponse RPC réussie ou une somme de contrôle prédite ne remplace pas la vérification du reçu et de l’état. Des copies de la même adresse sur des chaînes différentes peuvent avoir un code, des propriétaires, un stockage et des actifs différents.

Suivez ce flux :

  1. Figez la chaîne, le fork, le RPC et le bloc ; adresse de la factory ou du déployeur et hash du runtime ; octets du salt ; code init, arguments du constructeur, compilateur et bibliothèques liées.
  2. Calculez le hash du code init et le préimage CREATE2 exact, en vérifiant les largeurs, le padding, 0xff, les 20 derniers octets et la somme de contrôle.
  3. Décodez le calldata et la valeur de la factory ; comparez l’adresse prédite, le propriétaire, l’initialiseur, la cible du proxy et les permissions prévues.
  4. Vérifiez reçu, statut, événements, eth_getCode, nonce, solde et stockage sur la bonne chaîne ; consignez les états non déployé et de collision.
  5. Inspectez factory, proxy, implémentation, administrateur, initialiseur, mises à niveau et hypothèses de Singleton Factory, y compris les cibles ERC-1167.
  6. Testez l’échec du constructeur, la collision par nonce/code, le redéploiement sensible au fork, les factories imbriquées et les hypothèses de domaine de chaîne ou de replay.
  7. Avant de financer ou de signer, rapprochez les montants lisibles et bruts ; après le déploiement, surveillez le hash du code, le propriétaire, l’implémentation, les rôles, les événements et la finalité.

Exemples

  • Vecteur EIP-1014 : déployeur 0x0000000000000000000000000000000000000000, salt nul, init 0x00 donne 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38.
  • Liaison du constructeur : avec déployeur et salt fixes, modifier un argument de constructeur encodé en ABI modifie keccak256(init_code) et donc l’adresse prédite ; hacher le runtime vérifierait le mauvais objet.
  • Collision : si le nonce de destination est supérieur à 0 ou si le code n’est pas vide, CREATE2 doit échouer selon l’EIP-684. Une adresse financée avec un code vide et un nonce nul est seulement contrefactuelle et reste non vérifiée.
  • Proxy minimal : l’adresse d’un clone ERC-1167 hache le bytecode de création du clone qui contient l’adresse de l’implémentation. Hacher le runtime de l’implémentation produit une autre prédiction.

Risques

  • La mauvaise factory ou le mauvais déployeur est utilisé.
  • La largeur, le padding, l’endianness ou le domaine du salt sont incorrects.
  • Le code init est confondu avec le bytecode d’exécution.
  • Les arguments du constructeur sont omis ou mal ordonnés.
  • Le point d’entrée, la valeur ou le calldata de la factory diffèrent.
  • La cible du proxy ou du delegatecall n’est pas l’implémentation prévue.
  • La chaîne, le fork ou le domaine EVM diffèrent.
  • Un nonce existant provoque une collision.
  • Un code existant provoque une collision.
  • Des hypothèses obsolètes sur le redéploiement après SELFDESTRUCT sont utilisées.
  • Un CREATE2 imbriqué modifie le déployeur effectif.
  • Les formules CREATE et CREATE2 sont mélangées.
  • La cible d’implémentation ERC-1167 n’est pas vérifiée.
  • L’adresse ou les hypothèses de déploiement de Singleton Factory ne sont pas vérifiées.
  • Une mise à niveau ou le contrôle de l’administrateur de l’implémentation modifie le comportement.
  • Le compilateur, les métadonnées, la bibliothèque ou l’artefact source diffèrent.
  • Reçu, mempool, échec et état finalisé sont confondus.
  • Une somme de contrôle ou un empoisonnement de l’interface masque une mauvaise adresse.
  • Les fonds préfinancés de l’adresse contrefactuelle n’ont aucune preuve de propriété.
  • Les hypothèses sur EIP-7702, le replay, le gas, le déni de service ou une surveillance obsolète sont erronées.

Idées reçues

  • « Une adresse vide est sûre ou possède un propriétaire. » Elle peut ne contenir aucun code ni contrôleur vérifié.
  • « Le salt seul détermine l’adresse. » Le déployeur et le hash du code init sont également contraignants.
  • « CREATE2 hache le bytecode d’exécution. » Il hache le code de création, y compris les arguments du constructeur.
  • « La même adresse sur deux chaînes signifie le même code et le même contrôle. » L’état et les déploiements de chaque chaîne doivent être vérifiés séparément.
  • « Une prédiction réussie prouve le déploiement et la sécurité. » Seuls le reçu, le code, l’état, les permissions et la finalité établissent ce qui existe.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...