Qu'est-ce qu'un contrat de proxy minimal (EIP-1167) et comment permet-il d'économiser du gaz lors du déploiement ?

Qu'est-ce qu'un contrat de procuration minimal (EIP-1167) ?

1. Un contrat de proxy minimal, standardisé dans le cadre de la proposition d'amélioration Ethereum (EIP) 1167, est un contrat léger conçu pour déléguer des appels à un contrat de mise en œuvre existant. Il sert de proxy qui transmet tous les appels de fonction et transactions vers un contrat principal sans stocker de logique en lui-même.

2. Le mécanisme de base repose sur les opcodes de bas niveau SUCCESS, RETURNDATA et DELEGATECALL . Lorsqu'un utilisateur interagit avec le proxy minimal, il utilise DELEGATECALL pour exécuter les fonctions du contrat d'implémentation tout en conservant le stockage et le contexte du proxy.

3. Contrairement aux modèles de proxy à part entière tels que les proxys transparents ou UUPS, EIP-1167 n'inclut pas de logique d'évolutivité, de contrôle de propriété ou de mécanismes de secours. Cela rend son bytecode extrêmement compact, souvent de seulement 45 octets.

4. Parce qu'il ne dispose pas d'un état mutable pour l'administration, le proxy minimal est immuable après le déploiement. Son objectif principal est de créer des clones bon marché d'une seule implémentation, ce qui le rend idéal pour les déploiements en usine où la prévisibilité et l'efficacité énergétique sont essentielles.

Comment l'EIP-1167 permet-il d'économiser du gaz pendant le déploiement ?

1. L'avantage le plus important de l'EIP-1167 réside dans son coût de déploiement. Les contrats standard contiennent souvent des centaines ou des milliers d'octets de bytecode, ce qui entraîne des dépenses élevées lors de la création. En revanche, le bytecode du proxy minimal est optimisé pour être aussi petit que possible.

2. Les coûts du gaz sur Ethereum sont partiellement déterminés par la taille du code déployé. Chaque octet de code d'initialisation entraîne un coût, et les contrats plus importants paient davantage. En réduisant le bytecode déployé à environ 45 octets, EIP-1167 réduit considérablement ce coût par rapport aux modèles proxy traditionnels.

3. Le processus de déploiement implique uniquement la copie d'un petit morceau de code d'exécution qui pointe vers l'adresse d'implémentation. Il n'y a pas de logique de constructeur au-delà du codage de l'adresse cible dans le bytecode, ce qui réduit encore davantage la surcharge d'exécution.

4. Les projets déployant de nombreuses instances de contrats similaires, tels que des collections NFT, des actifs tokenisés ou des paires d'échanges décentralisées, peuvent réutiliser la même implémentation sur des milliers de proxys minimaux. Ce modèle permet une évolutivité massive avec un encombrement minimal de la blockchain.

Cas d'utilisation dans l'industrie de la cryptographie

1. Les bourses décentralisées comme Uniswap exploitent un minimum de proxys pour instancier efficacement les paires de trading. Chaque paire est un clone pointant vers un contrat de routeur partagé, permettant un déploiement rapide sans duplication logique redondante.

2. Les plateformes NFT utilisent EIP-1167 pour générer des contrats de collecte individuels à partir d'un modèle central. Cela garantit la cohérence tout en minimisant les frais de gaz pour les créateurs qui lancent de nouvelles gouttes.

3. Les concepteurs de protocoles implémentent des usines qui déploient un minimum de proxys pour représenter les coffres-forts des utilisateurs, les positions de prêt ou les actifs synthétiques. Ces clones héritent du comportement d’une implémentation vérifiée, réduisant ainsi la surface d’audit et les vecteurs d’attaque.

4. Les environnements sensibles au gaz tels que les réseaux de couche 2 bénéficient énormément de coûts de déploiement réduits. Sur les chaînes où les frais de transaction restent un problème, l'optimisation de la taille des contrats améliore directement l'accessibilité et le débit.

Considérations et limites de sécurité

1. Étant donné que le proxy minimal n'a pas de mécanisme de mise à niveau, tout bug dans l'implémentation affecte définitivement tous les clones. Cette immuabilité nécessite des tests rigoureux avant le déploiement initial.

2. La procuration ne valide pas l'existence ou l'exactitude du contrat cible au moment de la construction. Si l'adresse d'implémentation est incorrecte ou est compromise, tous les proxys deviennent vulnérables.

3. Étant donné que tous les états résident dans le contrat de mise en œuvre, à moins qu'ils ne soient explicitement définis par instance, les développeurs doivent concevoir avec soin les configurations de stockage pour éviter les collisions lors du partage de logique entre proxys.

4. Les attaquants peuvent exploiter des modèles de déploiement prévisibles si les proxys générés en usine suivent des schémas d'adresses séquentielles. Garantir le caractère aléatoire ou le contrôle d’accès lors de l’instanciation permet d’atténuer les risques d’énumération.

Foire aux questions

R : Non, les proxys EIP-1167 ne peuvent pas être mis à niveau. Ils pointent vers une adresse d’implémentation fixe codée au moment du déploiement. Tout changement nécessite le redéploiement de la nouvelle implémentation et des nouvelles instances de proxy.

Q : Comment l'adresse du contrat cible est-elle stockée dans le proxy ?

R : L'adresse d'implémentation est intégrée directement dans le bytecode du proxy à l'aide de techniques de niveau assembleur. Au moment de l'exécution, cette adresse est chargée et utilisée comme destination pour les opérations DELEGATECALL.

Q : Le proxy minimal est-il compatible avec les normes ERC comme ERC-721 ou ERC-20 ?

R : Oui, un nombre minimal de proxys peut transférer les appels vers n'importe quel contrat de mise en œuvre conforme. Tant que la cible prend en charge les interfaces requises, le proxy se comportera en conséquence même s'il n'a aucune logique intrinsèque.

Q : Pourquoi tous les projets n'utilisent-ils pas un minimum de proxys pour chaque contrat ?

R : Bien qu’efficaces, les proxys minimaux manquent de fonctionnalités d’administration intégrées. Les projets nécessitant un accès basé sur les rôles, une pausabilité ou des mises à niveau dynamiques optent pour des modèles de proxy plus complexes malgré des coûts de déploiement plus élevés.