Comment PeerDAS va-t-il améliorer la disponibilité des données sur Ethereum ?

Afin d'assurer une gestion efficace des données et une vérification sécurisée, Ethereum a évolué du DA vers le DAS, pour finalement introduire PeerDAS.

Auteur : 0XNATALIE

Lors de la récente réunion des développeurs Ethereum, une proposition visant à diviser le hard fork Pectra d’Ethereum en deux parties a été discutée. Cette proposition avait auparavant été rejetée, car il y avait des inquiétudes concernant un éventuel retard dans la mise à niveau des arbres Verkle. Cependant, lors de cette réunion, les développeurs ont de nouveau évoqué cette idée, car ils souhaitent inclure davantage de propositions d'amélioration (EIP) dans le fork Pectra. Il est proposé de diviser le hard fork en deux parties : la première inclurait tous les EIP actuellement présents sur Pectra Devnet 3, tandis que la seconde inclurait EOF (EVM Object Format) et PeerDAS. Pour mieux comprendre PeerDAS, commençons par le concept fondamental de la disponibilité des données.

DA : garantir que les nœuds accèdent aux données on-chain

La disponibilité des données (Data Availability, DA) signifie qu’il faut garantir que les blocs publiés par les proposeurs de blocs, ainsi que toutes les données de transactions qu’ils contiennent, soient effectivement accessibles et récupérables par les autres participants du réseau. La disponibilité des données est un facteur clé de la sécurité de la blockchain, car si les données ne sont pas disponibles, même si le bloc est valide, les autres nœuds ne peuvent pas vérifier son contenu, ce qui peut entraîner des problèmes de consensus et des attaques sur le réseau. Par exemple, un attaquant pourrait ne publier qu’une partie des données d’un bloc, empêchant ainsi les autres nœuds de procéder à la vérification.

Lorsqu’un nouveau bloc est diffusé, tous les nœuds participants téléchargent et vérifient les données du bloc. Ce modèle fonctionne lorsque le réseau est de petite taille, mais à mesure que la blockchain grandit, la quantité de données devient énorme, le stockage de chaque nœud augmente continuellement et les exigences matérielles s’élèvent. Pour permettre aux light nodes (comme les téléphones portables ou les ordinateurs portables) de participer également à la validation des blocs, la blockchain a introduit la technologie du sharding.

Le sharding consiste à diviser l’ensemble du réseau blockchain en plusieurs petits « shards ». Chaque shard ne traite que ses propres données et n’a pas besoin de gérer l’ensemble des données de la blockchain. Ainsi, un nœud individuel ne traite que les données de son shard. Mais comme chaque shard ne traite qu’une partie des données, cela signifie que les nœuds des autres shards n’ont pas un accès direct à l’ensemble des données. Comment garantir alors que les données dans un shard sont disponibles et que les autres nœuds peuvent vérifier la validité de ces données ? Par exemple, un nœud d’un shard publie un nouveau bloc généré, mais il se peut qu’il ne publie qu’une partie des données. Si les autres nœuds ne peuvent pas obtenir toutes les données du bloc, ils ne peuvent pas vérifier si ce bloc est authentique et valide.

DAS : vérifier la disponibilité globale des données via un échantillonnage partiel

Pour répondre au problème de disponibilité des données dans le sharding, la technique de Data Availability Sampling (DAS) a été proposée. Son idée centrale est de vérifier la disponibilité des données d’un bloc par échantillonnage, sans exiger que chaque nœud stocke ou télécharge l’intégralité des données du bloc.

L’échantillonnage de la disponibilité des données permet aux nœuds de n’obtenir qu’une partie aléatoire des données du bloc pour vérifier la disponibilité des données. Si un nœud parvient à obtenir et à vérifier avec succès ces fragments de données aléatoires, il peut en déduire que l’ensemble des données du bloc est disponible.

Pour permettre cette vérification par échantillonnage, les données des blocs sont généralement encodées avec le RS encoding. Ce codage permet de reconstituer l’intégralité des données même en cas de perte partielle. Ainsi, même si un nœud ne télécharge qu’une partie des données du bloc, il peut déduire et confirmer la validité de l’ensemble des données du bloc. Le DAS réduit la quantité de données que chaque nœud doit traiter grâce à la vérification par échantillonnage, permettant ainsi aux light nodes de participer à la validation des blocs.

La couche DA, comme celle de Celestia, est réalisée grâce à ces techniques. Elle implique principalement le RS encoding + validity proof + DAS.

• RS encoding (Reed-Solomon Encoding) : Ce mode de codage permet à un nœud qui ne reçoit qu’une partie des fragments de données de reconstruire l’ensemble du bloc de données. Il s’apparente à un code de correction d’erreur, offrant une certaine tolérance aux pannes : même si une partie des données est perdue, le reste suffit à reconstituer l’ensemble.
• Validity Proof (preuve de validité) : Utilisation de la preuve à connaissance nulle pour garantir qu’aucune erreur ne s’est produite lors du codage et du transfert des données. Si la vérification réussit, l’ensemble des données peut être décodé sans erreur.
• DAS (Data Availability Sampling) : Les light nodes procèdent à un échantillonnage aléatoire de certains fragments RS encodés dans le bloc, vérifient la disponibilité de ces fragments et en déduisent que l’ensemble du bloc de données est disponible.

PeerDAS : validation collaborative des données entre nœuds

PeerDAS est une implémentation concrète du DAS, qui réalise l’échantillonnage de la disponibilité des données via un réseau peer-to-peer. Un réseau peer-to-peer est un réseau composé de plusieurs nœuds qui communiquent directement entre eux. Dans le DAS, chaque nœud effectue indépendamment l’échantillonnage et la vérification des données, tandis que PeerDAS optimise ce processus en permettant aux nœuds de collaborer pour partager et vérifier les données des blocs, améliorant ainsi l’efficacité de la vérification. Les nœuds ne sont pas isolés : ils peuvent partager les tâches et les résultats de la vérification des données, et s’appuyer sur les données déjà vérifiées par d’autres nœuds. Ainsi, un nœud n’a pas à assumer seul toute la charge de vérification, mais partage la tâche avec d’autres, ce qui réduit encore la charge de chaque nœud. De plus, la validation collaborative rend la falsification des données plus difficile, car un attaquant devrait compromettre simultanément plusieurs nœuds de validation pour réussir à altérer les données.

Actuellement, selon la dernière réunion Ethereum sur PeerDAS, l’équipe du client Ethereum Lighthouse a déjà fusionné la branche DAS dans la branche principale et est en train de tester pour garantir la compatibilité avec PeerDAS. Une branche est généralement une version de code indépendante utilisée pour développer et tester de nouvelles fonctionnalités ou améliorations. La fusion dans la branche principale signifie que cette fonctionnalité ou amélioration a été développée, est considérée comme stable et peut être intégrée au code principal.