L'état actuel du développement de la piste de disponibilité des données : L1, L2 et l'architecture modulaire forment un équilibre triangulaire
TechFlow SélectionTechFlow Sélection
L'état actuel du développement de la piste de disponibilité des données : L1, L2 et l'architecture modulaire forment un équilibre triangulaire
J'espère pouvoir voir davantage d'excellentes équipes de startups explorer le domaine de la disponibilité des données.
Dédié à des analyses Web3 approfondiesLa disponibilité des données (Data Availability) se pose principalement dans le contexte des nœuds légers par rapport aux nœuds complets. Pour ce qui concerne la problématique de disponibilité des données des nœuds légers, un consensus existe déjà au sein de l'industrie : recourir aux codes d'effacement (erasure codes).
Non seulement les nœuds légers rencontrent cette question, mais aussi bien la narration « Layer1 + Layer2 » que celle de la blockchain modulaire comportent toutes deux des enjeux liés à la disponibilité des données.
À l’heure actuelle, trois grandes catégories de solutions existent dans l’industrie pour traiter la disponibilité des données :
Premièrement : Réduire le coût du stockage des données sur la chaîne L1 — EIP-4488 et EIP-4844
Lorsqu'Ethereum utilise Rollup pour s'agrandir, une transaction entraîne trois types de frais : frais d'exécution (tous les nœuds du réseau exécutent la transaction et vérifient sa validité), frais de stockage/état (frais mis à jour pour le nouvel état), et frais de disponibilité des données (publication des données sur L1).
Parmi ceux-ci, les frais liés à la disponibilité des données représentent la part majoritaire.
Actuellement, les Rollups publient leurs données sur L1 sous forme de Calldata, une méthode très coûteuse. Ainsi, l’EIP-4488 a été proposé afin de réduire le coût par octet non nul de Calldata de 16 Gas à 3 Gas, mais ce coût reste tout de même élevé.
Par la suite, la proposition EIP-4844, également appelée Proto-Danksharding, a été avancée. Elle introduit un nouveau format de transaction appelé Blob-carrying Transactions. Comparé aux transactions classiques, ce format inclut un espace supplémentaire appelé « Blob », destiné à stocker les données L2. De plus, les données Blob sont supprimées automatiquement par les nœuds après un mois, ce qui permet d’économiser considérablement l’espace de stockage.Ce format de transaction Blob offre une disponibilité des données nettement moins chère que le Calldata.
Deux raisons principales expliquent cela :
-
D'une part, le Calldata fait partie du payload d’exécution, tandis que les données Blob sont stockées dans des nœuds Prysm ou Lighthouse (et non dans Geth). Le Calldata nécessite donc davantage de ressources lorsqu’il est lu par un contrat ;
-
D'autre part, les données Blob sont conservées temporairement, puis effacées après un mois.
En somme, ceci constitue une solution d’Ethereum visant à réduire le coût de disponibilité des données directement sur la chaîne L1.
En complément, une solution de vérification de la disponibilité des données a été proposée — l'échantillonnage de disponibilité des données (DAS, Data Availability Sampling). Grâce au DAS, les nœuds peuvent télécharger aléatoirement certains blocs pour vérifier si un bloc entier a bien été publié. Puisque le DAS permet une validation parallèle des blocs, même avec un grand nombre de fragments de données (data sharding), la charge pour chaque nœud de validation ne s’accroît pas. Au contraire, cela pourrait inciter davantage de nœuds à participer, assurant ainsi une décentralisation suffisante. Pour implémenter le DAS, la technologie des codes d’effacement a été adoptée ; et pour garantir que ces codes soient correctement encodés, les engagements polynomiaux KZG (KZG Polynomial Commitments) ont été introduits.
Grâce à cet ensemble de solutions, les nœuds Ethereum (ou les clients légers) peuvent désormais valider la disponibilité complète des données en ne téléchargeant qu’une petite partie aléatoire de celles-ci.
Deuxièmement : Les solutions de disponibilité des données proposées par les Rollups au niveau exécutif
Les principaux Rollups exécutifs disposent également de leurs propres solutions de disponibilité des données, comme StarkEx, zkSync2.0, Polygon zkEVM, etc.
StarkEx
StarkEx est un cadre permettant de créer des solutions de mise à l’échelle personnalisées et autorisées. Plusieurs projets comme dYdX, Immutable, Sorare, DeversiFi ou Reddio utilisent aujourd’hui StarkEx.
StarkEx propose plusieurs modes de disponibilité des données : Rollup, Validium et Volition. Ces trois modes reposent tous sur des preuves d’effectivité.
-
Dans le mode Rollup, toutes les données sont publiées sur la chaîne (data on-chain) ;
-
Dans le mode Validium, les données restent hors chaîne (data off-chain), seule la preuve de validité de l’état le plus récent étant publiée sur la chaîne ;
-
Le mode Volition est hybride : chaque utilisateur peut choisir, transaction par transaction, si ses données seront stockées sur ou hors chaîne.
Étant donné que Validium conserve les données hors chaîne, ne publiant que la preuve de l’état le plus récent, il bénéficie de frais de transaction plus bas et d’un TPS plus élevé. En revanche, les opérateurs (Operators) de StarkEx Validium peuvent bloquer les fonds des utilisateurs. StarkEx introduit donc un comité de disponibilité des données autorisé (DAC, Data Availability Committees). Ce DAC doit signer chaque mise à jour d’état après avoir confirmé la réception des données, selon un quorum prédéfini. Actuellement, le DAC de StarkEx compte huit participants.
zkSync
zkSync 2.0 introduit une nouvelle architecture globale combinant deux types de comptes : zkRollup et zkPorter. Ces deux composantes sont interopérables et composites : les contrats et comptes zkRollup peuvent interagir sans friction avec ceux de zkPorter, et inversement. Pour l’utilisateur, la seule différence notable est que les frais des comptes zkPorter sont environ 100 fois inférieurs.
L’état zkRollup garantit la disponibilité des données sur chaîne, tandis que zkPorter opte pour une disponibilité hors chaîne. Plus précisément, les données zkRollup sont disponibles sur L1, alors que celles de zkPorter le sont sur L2. Les données des transactions zkRollup sont publiées via Calldata sur Ethereum — une pratique courante. Ce qui distingue zkPorter, c’est sa propre approche de disponibilité des données.
zkPorter traite la disponibilité des données selon une méthode hybride combinant zkRollup et le principe du sharding. Il peut supporter un nombre arbitraire de shards, chaque shard ayant sa propre stratégie de disponibilité des données, définie par son contrat intelligent. Le choix du shard est contrôlé au niveau du compte utilisateur. Autrement dit, la responsabilité de la disponibilité des données est déléguée à chaque shard, libre de choisir sa propre solution.
Les shards zkPorter comprennent notamment : Shard 0, Guardians Shard et Protocol X Shard.
Shard 0 est un shard zkRollup simple, bénéficiant de la disponibilité complète des données et de la sécurité fournie par Ethereum L1. C’est donc le shard le plus coûteux à exploiter dans zkPorter, avec des frais environ 100 fois inférieurs à ceux du réseau principal.
Les autres shards définissent leur propre politique de disponibilité des données via leurs contrats intelligents. En échangeant la disponibilité des données sur chaîne, zkPorter réduit encore les frais de transaction de 10 à 100 fois et augmente le TPS au-delà du shard de base. zkPorter introduit un mécanisme optionnel de validateur — les Guardians de zkPorter — permettant au protocole d’inviter des parties prenantes à garantir la disponibilité des données sur les shards.
La disponibilité des données de zkPorter est protégée par les détenteurs du jeton zkSync (les gardiens). Ces derniers signent les blocs pour suivre l’état du côté zkPorter, confirmant ainsi la disponibilité des données des comptes. Les gardiens utilisent le jeton zkSync dans un mécanisme de preuve d’enjeu (PoS). On parle ici de garantie économique cryptographique pour la disponibilité des données.
Polygon zkEVM
Polygon zkEVM est une solution de mise à l’échelle décentralisée de type Layer2 pour Ethereum, basée sur des preuves cryptographiques, offrant rapidité et détermination des transactions. Comme Polygon Avail, c’est une solution de scalabilité lancée par Polygon, mais avec un angle différent. Bien qu’ils aient développé Polygon Avail comme solution universelle de disponibilité des données, Polygon zkEVM dispose néanmoins de sa propre solution.
Polygon zkEVM adopte également un modèle hybride pour la disponibilité des données, permettant de choisir entre Validium ou Volition. En mode Validium, les données sont stockées hors chaîne, seule la preuve de validité étant publiée sur chaîne. En mode Volition, certaines transactions voient leurs données et preuves conservées sur chaîne, tandis que pour les autres, seule la preuve l’est.
Scroll
Certains zkRollups, comme Scroll, n’ont pas encore conçu leur propre solution de disponibilité des données.
Son CTO, Ye Zhang, a déclaré dans un entretien avec Chain Catcher : « Pour l’instant, Scroll n’a pas conçu de solution spécifique de disponibilité des données. Nous sommes relativement optimistes quant à l’évolution technique d’Ethereum, que ce soit Danksharding ou Proto-Danksharding.
En outre, ajouter une solution supplémentaire de disponibilité des données compromettrait légèrement la sécurité globale du système. À long terme, nous pensons qu’il vaut mieux utiliser Ethereum comme couche native de disponibilité des données. »
Troisièmement : Solutions générales de disponibilité des données
Outre Ethereum L1 et les Rollups L2 qui cherchent à résoudre la disponibilité des données et à réduire ses coûts, certains projets tentent de proposer des solutions générales de disponibilité des données.
Ces projets pourraient jouer un rôle clé en tant que couche de disponibilité des données dans les architectures modulaires futures. Actuellement, deux projets dominent ce domaine : Celestia et Polygon Avail.
Celestia
Celestia est une blockchain modulaire axée sur la couche de disponibilité des données. La couche DA de Celestia repose sur deux caractéristiques essentielles : l’échantillonnage de disponibilité des données (DAS) et les arbres de Merkle nommés (NMT). Le DAS permet aux nœuds légers de vérifier la disponibilité des données sans télécharger l’intégralité du bloc ; les NMT permettent aux couches d’exécution et de règlement sur Celestia de ne télécharger que les transactions pertinentes pour elles.
Pour devenir une couche indépendante de disponibilité des données, Celestia repose sur trois éléments fondamentaux :
-
Les Rollups transmettent toutes les données de transaction à Celestia ;
-
Celestia publie ces données sur son réseau ;
-
Ethereum confirme que Celestia a bien stocké et publié ces données, et qu’elles restent accessibles à tout moment.
En résumé, Celestia met en œuvre une solution universelle de disponibilité des données grâce aux codes d’effacement (Erasure Code), aux preuves de fraude (fraud proofs), et à des contraintes économiques accompagnées de mécanismes d’incitation.
Polygon Avail
Polygon est un projet doté d’une grande longévité, avec une équipe forte en vision stratégique et en capacité de R&D. Le projet a traversé l’évolution des techniques de scalabilité, passant des canaux d’état et Plasma aux Optimistic Rollups puis aux zk Rollups. L’équipe interne de Polygon a exploré de multiples directions, et continue d’avancer simultanément sur plusieurs fronts : Polygon Avail, Polygon Zero, Polygon Miden, Polygon zkEVM, etc. Polygon agit presque comme un agrégateur de solutions Layer2.
Polygon Avail est un projet conçu pour répondre au problème de disponibilité des données dans les solutions de scalabilité d’Ethereum. Officiellement, Polygon Avail est défini comme une blockchain modulaire, dédiée à la couche de disponibilité des données.
Avail peut fournir une forte garantie de disponibilité des données aux clients légers. Toutefois, ses documents officiels précisent honnêtement qu’il « n’offre pas une garantie DA supérieure à celle des autres réseaux pour les clients légers ». Avail se concentre sur l’utilisation d’engagements polynomiaux KZG, de codes d’effacement et d’autres technologies, permettant aux clients légers de prélever efficacement de petits échantillons aléatoires pour prouver la disponibilité des données sans avoir à télécharger l’intégralité du bloc.
Tout comme Celestia, Polygon Avail constitue une solution universelle de disponibilité des données. Contrairement à Celestia qui utilise des preuves de fraude pour valider les codes d’effacement, Polygon Avail s’appuie sur les engagements KZG. Celestia est plus simple à mettre en œuvre, mais nécessite une bande passante de communication plus élevée en raison de la taille importante des codes d’effacement et des échantillons prélevés par les nœuds légers. Avail implique une réalisation cryptographique plus complexe, plus difficile à développer, mais présente l’avantage d’utiliser des codes d’effacement plus compacts, réduisant ainsi la taille des échantillons et les exigences en bande passante.
Conclusion
Les trois catégories de solutions mentionnées ci-dessus visent toutes à résoudre la disponibilité des données sur chaîne, à introduire de nouvelles façons de stocker des données sur L1, à adopter une vision modulaire du développement blockchain pour construire une couche universelle de disponibilité des données, ou à concevoir sur L2 des solutions peu coûteuses de disponibilité des données hors chaîne.
Je pense que ces solutions coexisteront pendant une longue période.
Dans l’architecture Layer1 + Layer2, le « Blob » remplace progressivement le « Calldata » pour assurer la disponibilité des données de Layer2, tandis que Validium, Volition ou zkPorter s’appuient sur des mécanismes économiques limités à certaines parties prenantes pour garantir que Layer2 dispose elle-même d’une solution de disponibilité des données.
Dans le cadre de la narration de la blockchain modulaire, des solutions universelles telles que Polygon Avail et Celestia assumeront à terme, de manière relativement plus décentralisée, la responsabilité de la couche DA.
Par ailleurs, j’espère voir davantage d’excellentes équipes de startups explorer ce domaine. Les solutions actuelles sont des pionnières, mais je sens qu’il leur manque encore un certain « frisson ».
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@iobc_capital
