• Le chercheur de la Fondation Ethereum Francesco Risitano a publié le 1er novembre une ébauche d’EIP visant à remplacer KZG dans PeerDAS.
• L’ébauche remplace les engagements KZG par des engagements Merkle Keccak-256 propres à chaque blob, vérifiés au moyen de chemins d’authentification.
• La taille des blobs peut être choisie entre 2 048 et 524 288 octets, répartis en 128 unités de données.
Un chercheur de la Fondation cible la dépendance à KZG
Un chercheur de la Fondation Ethereum a publié une ébauche d’EIP qui reconstruirait la vérification des données dans PeerDAS sur une cryptographie résistante aux ordinateurs quantiques et donnerait au réseau Ethereum (ETH) des tailles de blobs variables. La proposition est de Francesco Risitano et a été soumise à l’examen public le 1er novembre. Son premier pilier remplace les engagements et preuves KZG qui sécurisent actuellement PeerDAS par des engagements Merkle Keccak-256 propres à chaque blob, vérifiés au moyen de chemins d’authentification. Le texte de l’ébauche indique que cela supprime la procédure de configuration de confiance à l’origine de KZG et renforce la résistance quantique de la couche de disponibilité des données. PeerDAS, le mécanisme pair-à-pair d’échantillonnage de la disponibilité des données qui sous-tend les projets de mise à l’échelle d’Ethereum, permet aux nœuds de confirmer l’existence des données des blobs en échantillonnant des fragments plutôt qu’en téléchargeant chaque blob dans son intégralité. L’échantillonnage permet de limiter les besoins matériels des nœuds, car un nœud vérifie la disponibilité de manière probabiliste au lieu de stocker les données de chaque rollup. Dans la conception actuelle, une preuve KZG confirme qu’un fragment échantillonné appartient à son blob d’origine. Ces preuves reposent sur une chaîne de référence structurée produite lors d’une cérémonie multipartite unique, un ensemble de paramètres dont les participants doivent garantir l’intégrité au lieu de la recalculer eux-mêmes. Un engagement Merkle fonctionne différemment : un vérificateur présente la branche de hachages reliant un fragment à une racine unique et fixe, de sorte que l’appartenance peut être vérifiée sans recourir au résultat d’une cérémonie. Dans ce contexte, la résistance quantique signifie que le mécanisme devrait rester sûr même si des ordinateurs quantiques à grande échelle finissent par briser les hypothèses actuelles fondées sur les couplages. Le deuxième pilier concerne l’économie des blobs : les blobs sont l’espace de données dédié que les rollups de couche 2 utilisent pour publier les données de transaction sur la chaîne, et l’ébauche permet de configurer chaque blob à une taille comprise entre 2 048 et 524 288 octets. Ces deux changements poursuivent un même objectif : revoir la façon dont le réseau Ethereum engage, transmet et tarifie les données des blobs. Le texte, qui en est au stade de la consultation publique, ne prévoit ni calendrier d’activation ni fork.
Vérification Merkle et règles de gaz
Le mécanisme de remplacement se déroule en deux étapes. Les chemins d’authentification vérifient d’abord chaque fragment échantillonné par rapport à la racine de Merkle du blob. Les preuves STARK de LeanDA recalculent ensuite cette racine, ce qui permet à un nœud de vérifier la relation d’encodage Reed-Solomon et la cohérence entre les données publiées et leur engagement. Ensemble, ces deux vérifications confirment que le fragment, l’encodage et l’engagement correspondent tous. Les règles de dimensionnement ont leurs propres contraintes. Chaque blob doit avoir une taille en octets qui est une puissance de deux et doit être divisible en 128 unités de données. Le projet maintient le nombre d’unités à 128 et adapte la taille de chacune à celle du blob choisi : un blob de 524 288 octets contient ainsi 128 unités de 4 096 octets, tandis qu’un blob de 2 048 octets contient 128 unités de 16 octets. Le calcul reste uniforme, car chaque taille autorisée est un multiple de la plus petite, ce qui rend prévisible l’indexation des fragments sur toute la plage. Cela préserve la conception de l’échantillonnage autour de laquelle PeerDAS a été conçu, tout en permettant à l’empreinte d’un blob de s’adapter à la demande. La transmission et la tarification suivent les tailles. Sur la couche d’exécution, les transactions contiendraient une racine de Merkle et la longueur du blob en octets, plutôt que le hachage versionné utilisé aujourd’hui. Les logiciels clients qui lisent les hachages versionnés devraient donc suivre un champ différent. Le projet prévoit également de réviser les règles de transmission réseau pour l’échange de blobs, puisque des fragments de tailles très différentes ne circulent pas de la même manière sur la couche pair-à-pair. La proposition ajoute le calcul du gaz à la liste des éléments à réviser, et le tarif du gaz pour les blobs évoluerait avec les paramètres redéfinis. Pour les validateurs, le travail concret concerne l’échantillonnage : le code qui vérifie aujourd’hui les preuves KZG vérifierait plutôt les branches de Merkle et les racines recalculées. Tous les clients participant à l’échantillonnage de disponibilité des données devraient donc intégrer ce changement. Rien de tout cela ne modifiera le consensus dès demain : le texte est un projet ouvert aux commentaires, sans bloc d’activation ni fork indiqué.
Pourquoi le mécanisme de configuration de confiance est important
La suppression du mécanisme de configuration de confiance est le changement fondamental de ce projet. Chaque engagement KZG actuellement utilisé en production remonte à une cérémonie dont les participants sont supposés — sans que cela ait jamais été prouvé — avoir détruit leurs contributions secrètes. Le schéma de Merkle élimine cette hypothèse à la source. Par ailleurs, la taille variable des blobs rapproche leur tarification de la quantité réelle de données publiées, ce qui compte à mesure que le débit des rollups augmente. Pour ceux qui suivent le cours de l’Ethereum, il s’agit d’une évolution du protocole, et non d’une opération de trading : le projet ne comporte aucune date d’activation et devra faire l’objet d’un examen public et de tests sur un réseau de test avant que quoi que ce soit ne soit intégré à un hard fork, selon le parcours par étapes suivi par le réseau lors de la mise à niveau Ethereum 2.0.