Technologie & IA
Ethereum : l’EIP-7954 propose de relever à 64 Kio la taille maximale du code des contrats
La dernière consultation affiche une échéance au 1er novembre. La proposition augmenterait aussi la limite du code d’initialisation à 128 Kio, mais nécessiterait une mise à niveau du réseau avant de permettre ces déploiements.
Adrien VauclairNom de plume de la rédaction
Deux plafonds de taille soumis à consultation
L’EIP-7954 atteint le 1er novembre 2026 l’échéance de dernière consultation affichée dans son document officiel. Créée le 9 juin 2025 par Giulio Rebuffo et Ben Adams, cette proposition Ethereum reste au statut Last Call lors de la vérification. Elle prévoit de relever deux limites : la taille du code conservé après le déploiement d’un contrat, puis celle du code utilisé pour l’initialiser. Cette étape ne démontre ni une adoption définitive ni une capacité nouvelle déjà disponible sur le réseau principal.
Le premier plafond passerait de 24 576 à 65 536 octets, soit de 24 à 64 kibioctets. Le second évoluerait de 49 152 à 131 072 octets, soit de 48 à 128 kibioctets. Ces mesures portent sur la taille du code, pas sur le volume de liquidités qu’un contrat peut gérer ou sur le nombre de ses utilisateurs. Les unités binaires importent ici : le document donne les seuils exacts en octets, qui servent de référence aux logiciels.
Le code déployé et l’initialisation ne jouent pas le même rôle
Le code déployé est celui que le réseau conserve pour les appels ultérieurs au contrat. Le code d’initialisation intervient pendant sa création et peut contenir les opérations nécessaires pour préparer le contrat avant de retourner son code final. L’EIP-170 encadre historiquement la taille de ce résultat. L’EIP-3860 a ajouté une limite au code d’initialisation et un coût destiné à mesurer une partie du travail effectué sur celui-ci. Ces mécanismes expliquent pourquoi le projet traite deux plafonds séparés.
L’objectif annoncé est de donner davantage de marge aux contrats complexes. Les auteurs estiment qu’un plafond de 24 Kio peut contraindre certaines applications ; passer à 64 Kio autoriserait des programmes plus riches dans l’enveloppe prévue. La proposition ne garantit toutefois pas qu’une application donnée deviendrait plus simple, moins chère ou plus sûre. Elle modifie les limites de taille et ne remplace pas les autres contraintes d’exécution, de stockage et de consommation de gas auxquelles un déploiement reste soumis.
Une ouverture qui conserve un enjeu de ressources
Les plafonds ne sont pas de simples préférences d’interface. La lecture et le traitement de code plus volumineux mobilisent les clients du réseau. Le texte de l’EIP-170 rappelait déjà ce lien entre taille du code, travail des nœuds et vérification des preuves. L’EIP-7954 reconnaît qu’une limite plus élevée peut augmenter marginalement le risque de déni de service par de grands contrats, tout en présentant son nouveau seuil comme conservateur. Il ne faut pas convertir cette appréciation des auteurs en absence de risque démontrée.
Les contrats déjà déployés ne seraient pas modifiés par ce changement de plafond. En revanche, la nouvelle possibilité de déployer du code entre 24 et 64 Kio requerrait une activation lors d’une mise à niveau du réseau, car les règles de consensus changent. Pour les équipes de développement, l’intérêt immédiat est donc de suivre la consultation et ses paramètres exacts. La date du 1er novembre ne vaut ni feu vert pour déployer aujourd’hui un contrat plus grand, ni promesse générale d’accélération du réseau.