Ethereum : l'EIP-8390 viser une baisse d'émission de 33 000 ETH et la suppression du Sync Committee

Une nouvelle proposition Ethereum, intégrée au dépôt officiel des EIP, veut supprimer le "sync committee" de 512 validateurs, mettre fin aux récompenses associées et rendre obsolète l'interface actuelle des light clients issue d'Altair, au profit de preuves à divulgation nulle de connaissance (zero-knowledge) produites hors chaîne. Selon l'EIP-8390 (statut "Draft"), retirer le poids des récompenses du sync committee dans la formule de rémunération du consensus ferait baisser l'émission annuelle d'environ 33 800 ETH. Le document rappelle que la formule actuelle attribue au sync committee un poids de 2 dans un dénominateur de 64. La suppression de ce poids, sans redistribution, représente une réduction de 2/64 (soit 1/32) de l'émission de consensus. Sur la base d'un instantané cité de 901 505 validateurs et 42 328 615 ETH en staking, et d'une estimation d'environ 1,082 million d'ETH émis par an au niveau du consensus, la part supprimée correspond à près de 33 800 ETH par an. Le texte précise que ce calcul (1/32) ne signifie pas une baisse mécanique de 3,125 % du rendement total réalisé par chaque validateur. Il porte sur l'émission de consensus dédiée aux récompenses du sync committee, alors que les rendements effectifs peuvent inclure d'autres revenus de consensus et des recettes de la couche d'exécution. Au-delà de l'émission, la proposition modifie l'équilibre de sécurité. Le sync committee est un échantillon de 512 validateurs dont les messages permettent aux light clients de suivre la beacon chain sans traiter l'ensemble des validateurs. Or, la spécification Altair ne prévoit pas de condition de slashing spécifique lorsqu'un validateur signe un message malveillant du sync committee. Une proposition distincte, l'EIP-7657, qui visait à introduire cette pénalité, est désormais marquée "Stagnant". Elle avertissait notamment que des applications sécurisant plus de 512 × 32 ETH (soit 16 384 ETH) devraient combiner le protocole light client avec d'autres protections. L'EIP-8390 propose de remplacer ce mécanisme par une vérification, par les light clients, d'une preuve zk de finalité Casper FFG couvrant l'ensemble des validateurs. Cette preuve deviendrait le signal de finalité pour les clients qui ne traitent pas le set complet. La contrepartie est une dépendance à une infrastructure externe encore non spécifiée. Sur le plan technique, l'EIP-8390 supprimerait les devoirs des validateurs liés au sync committee, les messages réseau, les conteneurs de données light client et plusieurs endpoints de la Beacon API. Le document indique que les light clients Altair déployés qui se synchronisent via "LightClientUpdate" cesseraient de fonctionner au moment du fork. Sont cités comme exemples Helios (intégrable dans des wallets et applications décentralisées), Lodestar (package light client côté consommateur), Nimbus (interface light client) et le client Ethereum IBC de Datachain, qui construit des en-têtes à partir de "LightClientUpdate" et "FinalityUpdate" via Beacon RPC. L'impact réel dépendrait de l'usage de ces interfaces au moment d'un éventuel fork et des migrations proposées par les mainteneurs. Le projet retire donc le flux de mise à jour défini par Altair sans proposer, à ce stade, de contrat de remplacement pour la Beacon API ni de spécification de migration pour les clients. L'EIP affirme qu'une finalité Casper FFG pourrait être prouvée en un epoch sur un GPU et vérifiée en quelques millisecondes, mais ne fournit ni implémentation reproductible, ni circuit, ni profil matériel, ni benchmark. Une conception publique comparable évoque un prétraitement inférieur à une minute sur un CPU 64 cœurs sans accélération GPU, et décrit encore certaines étapes de composition de preuve comme des travaux futurs. Le texte ne définit pas non plus le service de génération des preuves, l'interface côté client, le modèle de fiabilité, les opérateurs ou le financement. Il n'introduit explicitement aucun mécanisme d'incitation dans le protocole pour produire ces preuves, même si des financements hors protocole ou de type "public goods" pourraient émerger. Déposée dans le repository officiel des EIP à 02:04 UTC le 24 août, la proposition reste au stade "Draft" : aucune époque d'activation n'est indiquée, aucun engagement sur la feuille de route n'est mentionné, et la planification est laissée aux équipes clientes. Le fil de discussion de l'auteur ne faisait état d'aucune revue externe lors de la mise à jour initiale du draft. En l'état, les économies d'émission avancées par l'EIP sont chiffrées, mais la disponibilité du remplacement, le chemin de migration et le modèle économique restent ouverts. Pour envisager une activation, le dossier devra au minimum inclure une interface testée pour les light clients, des migrations fonctionnelles pour les implémentations Altair existantes, et une production publique de preuves capable de rester accessible lorsque les utilisateurs en dépendent.