Ethereum : un brouillon propose des blobs de taille variable et une nouvelle vérification pour PeerDAS

Un texte déposé, sans numéro définitif ni adoption

Francesco Risitano a ouvert le 1er novembre à 03 h 51 UTC une proposition de modification dans le dépôt Ethereum EIPs. Son texte, intitulé « Post-Quantum PeerDAS and Variable-Size Blobs », décrit une autre manière de vérifier les données associées aux blobs. Au contrôle de la rédaction, la demande numéro 12604 est ouverte, marquée comme brouillon et non fusionnée. Ce numéro identifie la demande GitHub : il ne constitue pas le numéro définitif d’un standard Ethereum.

Le fichier porte une date de création interne du 26 octobre, distincte de son dépôt public du 1er novembre. Il présente une architecture à discuter, avec plusieurs dépendances techniques et des éléments encore à définir. La procédure EIP distingue précisément un document de conception de sa mise en œuvre. Ni ce dépôt ni son étiquette de brouillon ne signifient que les clients Ethereum ont adopté les règles proposées ou qu’une activation sur le réseau principal a été décidée.

Changer les preuves tout en conservant l’échantillonnage

Le projet remplacerait les engagements KZG des blobs par des engagements de Merkle fondés sur Keccak-256. Chaque fragment échantillonné serait authentifié par un chemin de hachages relié à la racine de son blob. Une preuve STARK LeanDA servirait à vérifier la relation d’encodage Reed–Solomon et la dérivation correcte des engagements. Le texte conserve toutefois les mécanismes de garde des colonnes, d’échantillonnage et les seuils de reconstruction de PeerDAS : il ne propose pas de les supprimer.

L’objectif annoncé est de sortir des hypothèses de sécurité sur les courbes elliptiques et de la cérémonie de paramètres de confiance associées à KZG. L’auteur précise cependant que la résistance post-quantique dépend de la sécurité de toute la construction, y compris du hachage, de la preuve et de son agrégation. Il distingue aussi deux fonctions : démontrer que l’encodage et l’engagement sont corrects ne prouve pas, à lui seul, que les données restent disponibles sur le réseau.

Des tailles ajustables, avec des coûts à tester

Les blobs pourraient mesurer de 2 048 à 524 288 octets, selon des tailles autorisées en puissances de deux. Chaque blob conserverait 128 cellules ; c’est la longueur de chaque cellule qui varierait. Le projet cherche ainsi à éviter qu’un expéditeur ayant peu de données doive payer une capacité inutilisée ou attendre de réunir un lot plus important. Cette motivation ne constitue pas une mesure de baisse des frais déjà observée : les nouvelles règles ne sont pas déployées.

La comptabilisation proposée additionne la longueur du blob et une charge fixe correspondant aux nœuds internes de son arbre de Merkle. Elle s’accompagnerait de changements dans les transactions, les échanges réseau et les interfaces entre clients. Le document prévoit une transition nécessitant une modification du consensus, des tests et des mesures de performance. Il relève également que les chemins d’authentification augmentent la bande passante et l’exposition au déni de service par rapport aux preuves KZG. Ces compromis restent à évaluer avant toute décision d’intégration.