Un prototype d’ethereum qui répartit les tâches de récupération des blobs entre les nœuds a rapporté une réduction de 11 à 18 fois du travail de calcul estimé pour la reconstruction dans des simulations de 1 000 nœuds. Les résultats suggèrent que les opérateurs pourraient réduire le travail dupliqué grâce à un changement plus petit que la proposition complète de réseau RowDAS.
Le rapport du chercheur Csaba Kiraly du 3 septembre décrit la conception réduite comme une première étape possible vers RowDAS. Il attribue les fonctions de récupération sans introduire les nouveaux canaux de réseau en ligne dans la proposition complète.
Les blobs contiennent les données utilisées par les rollups de niveau 2. PeerDAS, le système d'Ethereum pour vérifier que les données des blobs sont disponibles, permet aux nœuds de télécharger uniquement une partie d'entre elles. Les nœuds à haute custody conservent au moins 64 des 128 colonnes de données, suffisamment pour reconstituer les données de blobs manquantes ; les supernœuds en conservent toutes les 128.
De nombreux nœuds à haute custody peuvent répéter la même reconstruction. La conception réduite attribue d'abord des blobs particuliers à ces nœuds, permettant aux autres de recevoir les données récupérées au lieu de les reconstruire immédiatement eux-mêmes.
Ce que montrent les simulations de récupération de blobs Ethereum
Dans une configuration avec quatre blobs, 10 % de supernœuds et aucune colonne retenue, le coût estimé de reconstruction au niveau du réseau est passé de 48,6 secondes CPU selon le modèle PeerDAS à 2,75 secondes CPU selon la conception réduite. À une part de 20 % de supernœuds, les chiffres correspondants étaient de 91 et 6,6 secondes CPU.
Ces totaux décrivent le travail informatique accumulé sur le réseau simulé, et non le temps de récupération écoulé. La comptabilisation applique un coût mesuré de 162 millisecondes par récupération de blob sur un processeur Ryzen 9 8945HS. Les vitesses de transaction et les économies de frais n'ont pas été incluses dans les mesures rapportées.
Le baseline PeerDAS inclut déjà des attentes aléatoires et des vérifications qui empêchent la reconstruction dupliquée. La comparaison accorde donc aux comportements clients existants le crédit pour le travail que ces délais permettent d'économiser.
Dans la variante réduite, les nœuds assignés partagent les cellules récupérées via les canaux de distribution par colonne existants. Les nœuds à haute garde conservent un rôle de récupération différée pour tout ce qui manque encore, préservant une sauvegarde de type PeerDAS.
Full RowDAS, spécifié dans le projet d'EIP-8371, ajouterait une autre voie de récupération : les canaux de ligne permettent aux nœuds plus petits de regrouper leurs données et de les reconstruire collectivement lorsque leurs holdings combinés dépassent le seuil de récupération. La conception réduite conserve la dépendance actuelle envers les nœuds à haute custody et ne peut pas offrir cette résilience supplémentaire.
Les mesures restent limitées à des réseaux simulés en cours d'utilisation avec une cryptographie réelle. Kiraly n'a pas rapporté de résultats sur devnet, et la configuration à 128 lignes du réseau complet reste une extrapolation à partir de nombres plus petits de sous-réseaux. Des simulations plus grandes et des tests sur réseau réel sont encore à venir.
EIP-8371 conserve les limites de blob inchangées, et la séparation proposée entre l'affectation des tâches et le réseau de lignes n'a pas encore été intégrée dans son texte provisoire. L'opportunité immédiate est plus limitée : réduire le travail du processeur nécessaire à la récupération, les avantages plus larges en matière de résilience dépendant d'une couche de lignes ultérieure.
Le post Ethereum pourrait avoir une méthode plus simple pour alléger la charge de calcul de son écosystème de rollups en croissance est apparu en premier sur CryptoSlate.