Développeurs principaux d'Ethereum Classic – Série de développement Olympia (Première partie)
Mise en œuvre d'ECIP-1111 et ECIP-1112 : Redirection des frais de base et Trésor immuable
1. Introduction – Du concept au code
Cette section donne un aperçu de l'architecture globale d'Olympia : son objectif, son historique de développement, et comment les ECIP 1111-1115 s'intègrent dans une voie de mise à niveau modulaire à plusieurs couches. Cet article se penche sur les pratiques d'ingénierie actuelles pour deux ECIP qui définissent ensemble les limites de consensus d'Olympia :
ECIP-1111 – Mise à niveau de l'EVM et du protocole
ECIP-1112 – Contrat de trésor immuable
Ces deux propositions sont les seuls composants d'Olympia qui modifient le comportement de consensus. Les autres parties du cadre – la gouvernance (ECIP-1113), les propositions de financement (ECIP-1114) et le mécanisme de lissage optionnel (ECIP-1115) – fonctionnent tous au niveau du contrat, n'affectant pas la validité des blocs ou le choix de fork. Le 11 novembre 2025, les développeurs principaux d'Ethereum Classic ont lancé la phase de mise en œuvre, préparant la logique de consensus et l'infrastructure cliente de référence pour un déploiement potentiel sur le testnet Mordor.
Cet article donne un aperçu de :
Ce qu'introduit ECIP-1111
Comment ECIP-1112 définit l'adresse cible du trésor
Comment ces composants fonctionnent ensemble
Ce qui est actuellement prototypé dans le développement du client de référence
Cet article décrit uniquement les conceptions et les travaux de mise en œuvre, et ne présage pas de leur future activation ou adoption via le processus ECIP-1000. Avant de déployer les modifications de la couche de consensus d'ECIP-1111 ou d'ECIP-1112 sur Mordor ou le mainnet, les clients ETC doivent d'abord vérifier leur stabilité et leur compatibilité dans des conditions de référence.
2. ECIP-1111 – Modernisation des frais, perturbation minimale du réseau
ECIP-1111 intègre deux améliorations largement adoptées de l'EVM :
Un mécanisme de frais de type EIP-1559 (frais de base + pourboire optionnel) Ce mécanisme introduit :
Des frais de base (BASEFEE) à ajustement dynamique,
Des frais de priorité élevée optionnels (pourboire) toujours payés directement aux mineurs
Et un marché des frais plus prévisible pour les outils modernes.
2. Prise en charge des transactions de type 2 (style 1559) : Cette fonctionnalité est désormais standard pour la plupart des portefeuilles et infrastructures.
3. Opcode BASEFEE (0x48) : Expose le BASEFEE du bloc actuel à la logique des contrats (estimateurs de gas, routeurs DEX, chaînes d'outils, etc.).
Qu'est-ce qui change pour Ethereum Classic (ETC) ?
Une seule différence de comportement avec Ethereum mainnet :
Fondation Ethereum (ETH) : Le BASEFEE est brûlé.
Ethereum Classic (ETC) : Le BASEFEE est redirigé vers le trésor défini par ECIP-1112. Le reste de la sémantique EIP-1559 reste inchangé.
Qu'est-ce qui reste inchangé ?
Les pourboires des mineurs restent inchangés.
La récompense de bloc reste inchangée.
La politique monétaire (ECIP-1017) reste inchangée.
Les types de transaction traditionnels (Type-0 et Type-1) restent entièrement valides.
Les contrats existants ne sont pas interrompus ; les applications existantes n'ont pas besoin d'être modifiées.
Aucune hypothèse de confiance supplémentaire ou mécanisme d'autorisation n'est introduit.
ECIP-1111 est additif, minimal et strictement limité à la modernisation du mécanisme de frais et à l'activation de la fonctionnalité de redirection BASEFEE.
3. ECIP-1112 – Le trésor déterministique et immuable
ECIP-1112 définit l'adresse de réception des frais de base redirigés : un contrat intelligent minimaliste et immuable déployé à une adresse déterministe. Ces définitions restent théoriques jusqu'à ce que les logiciels clients démontrent un comportement cohérent dans un environnement multi-clients, jalon qui nécessite des tests complets pour évaluer en toute sécurité les composants d'Olympia.
Caractéristiques principales
Immuabilité : Aucune clé de mise à niveau, aucun administrateur, aucun modèle de procuration.
Adresse déterministe (par exemple via CREATE2) : Tous les clients s'accordent sur la même destination de trésor.
Réception seule à l'activation : Le trésor peut accumuler de la valeur, mais ne peut pas libérer de fonds avant l'activation ultérieure de la gouvernance.
Aucune logique de gouvernance interne : Agit purement comme une couale de custodie, pas une couche de décision.
À l'activation (testnet ou mainnet) :
Le trésor ne peut que recevoir des fonds.
Aucun mécanisme de retrait n'est activé avant qu'ECIP-1113 et ECIP-1114 ne soient déployés, audités et intentionnellement activés. Cette séparation assure la prédictibilité de la mise à niveau du consensus et l'indépendance vis-à-vis de la mise en œuvre de tout futur système de gouvernance.
4. Limites de consensus claires
Bien qu'Olympia comprenne cinq propositions ECIP, seules ECIP-1111 et ECIP-1112 modifient le comportement de consensus.
Résumé des limites de consensus
ECIP-1111 — Couche protocole. Introduit des changements de consensus : nouveau mécanisme de frais de base, transactions de type 2 et opcode de frais de base.
ECIP-1112 — Couche protocole/contrat. Introduit des changements de consensus : définit l'adresse de réception déterministe du trésor pour la redirection des frais de base.
ECIP-1113 — Couche contrat/application. Aucun changement de consensus.
ECIP-1114 — Couche contrat/application. Aucun changement de consensus.
ECIP-1115 — Couche contrat/application. Aucun changement de consensus.
Cette structure modulaire assure :
Que la logique critique de consensus reste mince et auditable,
Que les mécanismes de gouvernance et de financement peuvent évoluer au niveau du contrat,
Que les améliorations apportées aux ECIP-1113 à 1115 ne nécessitent pas de changements de consensus supplémentaires.
S'ils sont adoptés, les clients mettant en œuvre ECIP-1111 et ECIP-1112 resteront compatibles en termes de consensus, indépendamment des déploiements ultérieurs de la couche de gouvernance. Les implémentations de référence peuvent commencer à prototyper la logique de consensus au stade du brouillon, mais ces changements devront subir des tests complets (y compris la validation par des clients de référence comme Gorgoroth, décrite dans la deuxième partie) avant de pouvoir être fusionnés dans des clients de production.
5. Pourquoi l'activation de la gouvernance est retardée
Si ECIP-1111 et ECIP-1112 sont activés, les frais de base commenceront à affluer vers le trésor – mais les dépenses du trésor resteront désactivées.
Ce déploiement par étapes permet :
Des tests indépendants des frais de base
Un audit complet d'ECIP-1113 et ECIP-1114
Une coordination précise entre les implémenteurs de clients et les fournisseurs d'infrastructure
Une prédictibilité du comportement des opérateurs de nœuds
Si les contrats de gouvernance sont déployés et activés ultérieurement, le trésor sera connecté aux exécutants autorisés entièrement au niveau du contrat (et non au niveau du consensus).
6. Transactions de type 2 et interopérabilité EVM à long terme
La prise en charge des transactions de type 2 est cruciale pour qu'Ethereum Classic reste compatible avec :
Les portefeuilles modernes
Les exchanges et services de custodie
L'infrastructure RPC
Les frameworks d'outils (Hardhat, Foundry, etc.)
Les explorateurs de blocs
L'interopérabilité inter-chaînes
Les transactions de type 2 ne modifient pas les besoins des utilisateurs ni n'introduisent de mécanismes d'autorisation. Les types de transaction traditionnels resteront entièrement pris en charge.
Le type 2, en tant que fonctionnalité incrémentale, assure qu'ETC reste interopérable avec les formats de transaction principaux de l'écosystème EVM.
7. Contexte plus large – Maintenir une couche de base programmable en Proof of Work durable
ECIP-1111 et ECIP-1112 constituent ensemble une étape fondamentale vers un modèle opérationnel durable et programmable en Proof of Work pour Ethereum Classic – à condition que la communauté choisisse d'adopter ces propositions.
Ces propositions n'altèrent pas :
Les incitations des mineurs
N'introduisent pas d'inflation
Ne modifient pas la politique monétaire
N'ajoutent pas de couche de gouvernance au consensus
Ne changent pas les hypothèses de sécurité d'Ethereum Classic
Leur objectif se limite à :
Moderniser le marché des frais
Établir un mécanisme transparent d'attribution de valeur au niveau du protocole
S'ils sont adoptés, ces changements ouvriront la voie aux futurs systèmes de gouvernance et de financement au niveau des contrats proposés dans Olympia, sans nécessiter de nouvelles règles de consensus.
8. Conclusion – Minimal, sécurisé et compatible vers l'avant
ECIP-1111 et ECIP-1112 définissent les composants de la couche de consensus proposés dans le cadre d'Olympia. Ils :
Ajoutent le type 2 et le mécanisme de frais de base
Redirigent les frais de base vers un trésor déterministe
Maintiennent tous les comportements existants des utilisateurs et des mineurs
Préparent le terrain pour les futurs composants contractuels d'ETC
Ces propositions n'introduisent pas de logique de gouvernance dans le mécanisme de consensus, ni n'ajoutent d'hypothèses de confiance aux sémantiques existantes d'EIP-1559/EIP-3198. Leur objectif est de maintenir le conservatisme du protocole central d'ETC et la compatibilité avec l'écosystème EVM, tout en permettant des flux de valeur durables au niveau du contrat.
9. Clarté de la procédure ECIP
Les spécifications ECIP d'Olympia (1111–1115) sont actuellement au stade de brouillon et font l'objet de discussions actives. Le travail de mise en œuvre précoce d'ECIP-1111 et ECIP-1112 a commencé sur le client de référence, ce qui est entièrement conforme aux dispositions du stade de brouillon d'ECIP-1000. Les implémentations de référence ne seront envisagées pour une activation sur le mainnet qu'après des tests réussis sur le testnet Mordor. Une fois les résultats du testnet qualifiés, les proposants d'ECIP pourront soumettre des mises à jour de spécification. Toute décision d'avancer vers un "statut accepté" ou de planifier une activation sur le mainnet devra passer par un examen communautaire et la procédure d'évaluation complète d'ECIP-1000. Cet article décrit les travaux de conception et de mise en œuvre en cours au stade de brouillon.
10. Prochaines étapes de la série
Le cadre de conception du consensus étant établi, le prochain article se concentrera sur la couche cliente – le plan de test alpha Fukuii est sur le point de commencer, visant à valider l'interopérabilité des clients ETC avant toute intégration liée à Olympia.
Clause de non-responsabilité : Le contenu de cet article ne constitue aucun conseil en investissement ou financier. Le contenu est republié depuis EthereumClassic, à titre informatif pour l'industrie. Pour toute question ou problème de droits d'auteur, veuillez nous contacter pour suppression.
