Introduction

Avec le développement rapide de la technologie de la blockchain, les blockchains monolithiques sont confrontées à de sérieux défis en termes de scalabilité et d'interopérabilité. Les principales plateformes telles qu'Ethereum connaissent une flambée des frais de transaction en période de forte demande, ce qui entrave considérablement l'adoption des applications décentralisées. Pour résoudre ces problèmes, les développeurs cherchent continuellement des solutions innovantes, et l'émergence d'Avail offre une nouvelle direction pour résoudre ces problèmes. Suite à la mise à niveau de Cancun, les coûts de transaction dans l'écosystème Ethereum ont considérablement diminué, et la technologie modulaire est devenue un élément clé du développement de la blockchain. Au cours du premier semestre, des blockchains modulaires comme Celestia et EigenDA ont mené la tendance, et le 23 juillet, Avail a franchi une étape majeure dans le domaine modulaire en lançant le réseau principal Avail DA.

En tant que l'un des projets principaux dans les chaînes de blocs modulaires, Avail, EigenDA et Celestia couvrent des domaines similaires. Cependant, chacun a ses caractéristiques uniques en termes d'infrastructure, de modèles d'exécution et de conceptions économiques de jetons.

Antécédents de l'équipe

Avail est originaire de Polygon et est devenue une entité indépendante et neutre en 2023. Avant que la disponibilité des données (DA) ne devienne un point central de l'industrie, Anurag Arjun avait collaboré avec d'autres pour développer la chaîne Plasma, dans le but de résoudre les problèmes de scalabilité d'Ethereum. Bien que cette chaîne ait permis à Polygon de générer 19 milliards de dollars de revenus, elle n'est finalement pas devenue la solution d'échelle idéale. Tout au long de ce processus, Anurag a réalisé que toutes les blockchains finiraient par être confrontées au même défi - la disponibilité des données. Environ 80% des coûts de transaction de Rollup sont liés à la DA, ce qui l'a amené à envisager la création d'une couche de DA rentable qui pourrait résoudre les problèmes de scalabilité pour plusieurs blockchains.

Cette idée n'était pas unique à Anurag; de nombreux projets blockchain Layer 1 (L1) ont également tenté de se positionner en tant que couches DA. Ethereum, par exemple, explore des solutions DA grâce à l'approche Rollup, tandis que d'autres projets L1 innovent dans cet espace. Anurag estime qu'une blockchain L1 spécifiquement conçue pour la DA offre des avantages distincts.

Pendant son séjour chez Matic, Anurag a rencontré Prabal Banerjee, actuel co-fondateur de Avail, qui poursuivait un doctorat en cryptographie et sécurité. Prabal a ensuite rejoint l'équipe en tant que chercheur et ensemble, ils se sont consacrés à la création d'une couche DA évolutive. Avec l'avènement de la technologie de preuve de connaissance nulle (ZK), les deux ont intégré des conceptions de blockchain basées sur des preuves de validité. En s'appuyant sur l'expérience d'Anurag dans la création d'un protocole de plusieurs milliards de dollars chez Polygon, ils ont fait avancer le développement de solutions pour relever les défis de disponibilité des données.

De Monolithique à Modulaire

Source : Documentation officielle disponible

À mesure que la concurrence pour les ressources informatiques sous-jacentes s'intensifie, l'architecture monolithique d'Ethereum - qui gère l'exécution, le règlement, l'ordonnancement et la disponibilité des données (DA) sur une seule chaîne - a de plus en plus révélé ses limites, en particulier en termes de scalabilité. Cela a incité l'industrie à réévaluer le modèle monolithique et à explorer de nouvelles solutions.

Les Rollups ont introduit une architecture modulaire en déplaçant l'exécution hors chaîne, ce qui a soulagé la congestion sur les réseaux de la couche 1 (L1), réduit les coûts de transaction pour les utilisateurs et amélioré le débit des transactions. Bien que cette architecture ait considérablement amélioré l'efficacité on-chain, l'espace limité du bloc d'Ethereum reste un goulot d'étranglement et, à mesure que la demande augmente, ce problème pourrait resurgir. Actuellement, les applications décentralisées (Dapps) s'appuient sur L1 pour la transmission de données et le règlement, tandis que les Rollups utilisent L1 pour gérer ces processus. Bien que les Rollups aient optimisé l'utilisation de l'espace de bloc, l'espace de bloc lui-même reste une ressource rare.

L'analyse des transactions L1 des Rollups Ethereum révèle que les coûts DA représentent 90% des dépenses des Rollups, ce qui en fait la plus grande source de dépenses. La majeure partie de ce coût provient du paiement des frais L1 pour publier les données de transaction.

Tout comme les Rollups déchargent l'exécution hors chaîne, l'architecture d'Avail permet de déplacer la disponibilité des données vers une couche dédiée. Avail fournit aux développeurs une couche DA flexible, conviviale et sécurisée qui répond aux défis de la scalabilité, de la gouvernance et de la décentralisation.

Architecture modulaire d'Avail

Avail vise à accélérer l'unification de Web3 en exploitant sa pile technologique modulaire, qui intègre la disponibilité des données, l'agrégation et la sécurité partagée. Les Rollups qui utilisent Avail pour publier des données de transaction hors chaîne formeront des systèmes tels que Validium (pour les Rollups Optimistes, cela s'appelle Optimium). Les Validiums et les Sovereign Rollups peuvent compter sur Avail pour des services de disponibilité et d'ordonnancement de données à faible confiance.

Voici un aperçu de la façon dont Avail prend en charge les Validiums et les Sovereign Rollups :

1. Soumission de transaction : Comme la plupart des Rollups existants, les données de transaction sont regroupées et la racine de l'état est soumise à Avail DA (Disponibilité des données). Chaque lot est associé à un identifiant d'application unique pour représenter l'origine du Rollup.
2. Expansion des données et codage d'effacement : Les transactions soumises à Avail DA subissent un codage d'effacement. Le bloc de données est divisé en n morceaux d'origine et étendu en 2n morceaux. N'importe quel ensemble de n morceaux parmi les 2n peut être utilisé pour reconstruire les données d'origine, garantissant la redondance et la tolérance aux pannes.
3. Création d'engagement : Avail DA applique des engagements de polynômes KZG aux données redondantes, garantissant leur intégrité par des preuves cryptographiques. Ces engagements assurent que les données stockées sont précises et inviolables.
4. Propagation des blocs: les validateurs reçoivent des blocs contenant des engagements KZG et les régénèrent pour vérifier leur exactitude. La validité du bloc est ensuite décidée par consensus.
5. Réseau de client léger : Les clients légers utilisent l'échantillonnage de disponibilité des données (DAS) pour vérifier l'intégrité des données de bloc. Cela est fait en effectuant une vérification d'ouverture de polynôme KZG sur les engagements des en-têtes de bloc, éliminant ainsi le besoin de reconstruire l'engagement complet de KZG ou de s'appuyer sur des preuves de fraude.
6. Vérification de la preuve : Les clients légers exécutent la vérification de la preuve en utilisant des preuves de niveau cellulaire générées à partir de la matrice de données. Cela garantit que les données sont disponibles et correctes sans que le client ait à télécharger ou vérifier le bloc complet.

Étant donné qu'Avail utilise des preuves de validité plutôt que des preuves de fraude, les clients légers peuvent vérifier immédiatement la disponibilité des données et leur exactitude après la finalisation de l'état. Le réseau des clients légers garantit également une grande disponibilité des données grâce à l'échantillonnage de disponibilité des données. Plus il y a de clients légers, meilleure est la capacité d'échantillonnage, ce qui permet au réseau de prendre en charge des blocs plus volumineux. Ces clients légers peuvent même fonctionner sur des ordinateurs portables ou des appareils mobiles, ce qui améliore l'efficacité du réseau.

Source : Disponible dans la documentation officielle

Caractéristiques techniques

Cas d'utilisation de client léger

Actuellement, de nombreuses applications blockchain reposent sur des intermédiaires pour maintenir des nœuds complets, les utilisateurs interagissant indirectement via ces intermédiaires plutôt que de se connecter directement à la blockchain. En raison du manque de disponibilité des données garantie, les clients légers ne sont pas encore devenus l'alternative idéale aux architectures traditionnelles. Avail résout ce problème en permettant aux applications d'interagir directement avec le réseau blockchain sans se fier aux intermédiaires.

Bien qu'Avail prenne en charge le fonctionnement de nœuds complets, la plupart des applications n'ont pas besoin de les exécuter ou nécessitent seulement un nombre minimal de nœuds pour fonctionner en douceur. Cela réduit considérablement les ressources nécessaires pour participer au réseau blockchain et améliore la décentralisation en permettant à un plus grand nombre de participants d'interagir directement avec la chaîne grâce à une infrastructure légère.

Échantillonnage de disponibilité des données (DAS)

Similaire aux clients légers traditionnels, les clients légers d'Avail n'ont besoin de télécharger que les données d'en-tête de bloc. De plus, ils effectuent un échantillonnage aléatoire de parties des données de bloc pour vérifier leur disponibilité grâce à l'échantillonnage de disponibilité des données (DAS). En combinant le codage d'effacement avec les engagements polynomiaux KZG, les clients légers peuvent garantir une disponibilité des données presque à 100 % sans avoir recours à des preuves de fraude, ne nécessitant qu'un nombre réduit et fixe de requêtes.

Codage d'effacement et disponibilité des données

Le codage d'effacement fonctionne en divisant les données en fragments, restaurant le contenu original même si certaines parties des données sont perdues. Dans les applications de blockchain, même si des acteurs malveillants tentent de masquer certaines parties des données, le système peut toujours les récupérer à partir d'autres fragments. Ce mécanisme améliore considérablement la fiabilité de l'échantillonnage de disponibilité des données et renforce davantage la résistance du système à la falsification des données.

Engagements de KZG

Les engagements KZG, développés par Aniket Kate, Gregory M. Zaverucha et Ian Goldberg en 2010, sont une méthode d'engagement de polynôme efficace qui a connu une adoption généralisée dans les systèmes de preuve à divulgation nulle ces dernières années. Dans l'architecture d'Avail, les engagements KZG offrent les avantages suivants:

• Ils permettent un engagement concis envers les valeurs enregistrées dans l'en-tête du bloc.
• Les clients légers peuvent vérifier la disponibilité des données grâce à ces engagements.
• Les propriétés de liaison cryptographique des engagements KZG rendent presque impossible de générer de faux engagements, réduisant ainsi considérablement le besoin de preuves de fraude.

Couche unifiée d'Avail

Avail construit la « Couche Unifiée », une pile technologique complète commençant par la couche de disponibilité des données (DA) fondamentale, la couche unifiée Nexus, et une couche de sécurité supplémentaire appelée Fusion. Avec sa couche de disponibilité des données évolutive, Avail vise à soutenir l'ensemble de l'écosystème Web3. En utilisant des preuves de validité basées sur des engagements de polynômes KZG, Avail assure la disponibilité en temps réel et fiable des données, permettant aux rollups de croître, de s'interconnecter, de maintenir la sécurité et de s'adapter.

Disponible DA

Source: Documentation officielle disponible

Avail DA est une architecture sous-jacente spécifiquement optimisée pour la disponibilité des données. Elle utilise les algorithmes de consensus GRANDPA et BABE, ce qui la distingue des autres couches de disponibilité des données. Cette conception confère à Avail DA une grande évolutivité, garantissant des garanties de données fiables à faible coût grâce à l'échantillonnage de la disponibilité des données (DAS) et aux preuves de validité.

Au cœur de Avail DA, il met l'accent sur la priorisation et la publication des transactions tout en permettant aux utilisateurs de vérifier la disponibilité des données de bloc sans télécharger l'intégralité du bloc. Une des caractéristiques déterminantes de Avail DA est sa nature agnostique aux données. Il prend en charge une variété d'environnements d'exécution, y compris EVM, WASM et de nouveaux runtimes personnalisés, offrant ainsi une base polyvalente pour une large gamme d'applications blockchain.

Disponible Nexus

Source : Disponible dans la documentation officielle

Avail Nexus, le deuxième pilier de l'univers de la cryptomonnaie Avail, est un cadre sans permission conçu pour unifier l'univers Web3. Il connecte à la fois les blockchains internes et externes, en utilisant Avail DA comme fondation de confiance et agissant comme un hub de validation. Nexus intègre un système de Rollup coordonné par ZK, qui consolide l'agrégation des preuves, une couche de vérification, un mécanisme de sélection de séquenceur et un système d'enchères de slot. Nexus soumet périodiquement des preuves aggreGated à Ethereum et à la couche Avail DA pour vérification, garantissant la fiabilité des opérations inter-chaînes.

Avail Fusion

Source : Disponible dans la documentation officielle

Avail Fusion, le troisième pilier, fournit une sécurité supplémentaire pour l'écosystème Avail et l'univers de la cryptomonnaie. Le concept central derrière Fusion est qu'un système unifié exige une sécurité unifiée au niveau économique. La sécurité Fusion renforce le consensus d'Avail en utilisant des actifs natifs d'écosystèmes établis tels que BTC et ETH, contribuant à la sécurité du consensus Avail. Il s'agit de la première tentative d'utiliser des tokens externes pour parvenir à un consensus entre les blockchains.

Fusion prend en charge deux types de mise en jeu d'actifs : les cryptomonnaies établies et les jetons Rollup émergents. Actuellement, le prototype de Fusion comprend deux modules de mise en jeu : l'un fonctionnant sur la blockchain Avail et un autre pour la mise en jeu de conversion d'actifs. Il est important de noter que le premier prototype public d'Avail Fusion est encore en cours de développement.

Types de nœuds dans Avail

Bien que l'architecture d'Avail diffère des blockchains monolithiques traditionnelles, elle prend toujours en charge différents types de nœuds, y compris les nœuds complets, les clients légers, les nœuds d'archive et les nœuds de validation.

• Full Node: Les nœuds complets sont responsables du téléchargement et de la vérification de la correction des blocs, mais ils ne participent pas au processus de consensus. Bien que les nœuds complets fournissent une redondance et une résilience supplémentaires au système, ils ne sont pas essentiels pour la fonctionnalité du réseau.
• Nœud validateur : Les nœuds validateurs sont cruciaux dans la génération de blocs, la détermination des transactions à inclure et le maintien de l'ordre. Ces nœuds aident le réseau à atteindre un consensus.
• Client léger: Les clients légers permettent aux utilisateurs d'interagir avec la couche de disponibilité des données (DA) d'Avail sans exécuter un nœud complet ou dépendre de nœuds pairs distants. Ils y parviennent en effectuant un échantillonnage de disponibilité de données (DAS) sur chaque bloc nouvellement créé, assurant ainsi la disponibilité des données sans télécharger l'intégralité du bloc.
• Nœud RPC : les nœuds RPC fournissent une API pour l’interaction à distance, agissant comme une passerelle permettant aux développeurs et aux utilisateurs externes d’interagir avec le réseau Avail.

Les clients légers surveillent les blocs confirmés sur le réseau Avail et effectuent DAS sur des unités de données pré-désignées dans chaque nouveau bloc. Après une vérification réussie, le système calcule la certitude d'un sous-ensemble d'unités de données dans le bloc, en fonction du niveau de confiance requis par l'utilisateur.

Modèle économique

Distribution de jetons

Avec le lancement du réseau principal Avail DA, l’équipe a distribué des jetons AVAIL aux utilisateurs éligibles, avec une offre totale de 10 milliards de jetons. La répartition de la distribution est la suivante :

• 6% pour les airdrops et l'allocation publique
• 30% pour le développement de l'écosystème
• 23,88 % pour la communauté et la recherche
• 14,12 % alloués aux investisseurs
• 20% alloués aux contributeurs principaux

Source : Documentation officielle disponible

Staking

Le token AVAIL sert à plusieurs fins, y compris la gouvernance de l'écosystème et le staking liquide. Bien que le cadre de gouvernance officiel n'ait pas été entièrement détaillé, n'importe qui peut miser AVAIL sur l'infrastructure d'Avail pour gagner des récompenses de staking.

Pour le staking, Avail adopte le mécanisme de consensus Nominated Proof-of-Stake (NPoS), hérité de l'écosystème Substrate. Le staking joue un rôle crucial dans ce système, car les utilisateurs misent des jetons AVAIL pour renforcer la sécurité du réseau et gagner des récompenses. Plus il y a de jetons misés, plus le réseau devient sécurisé, car le coût pour attaquer le réseau augmente avec la quantité de jetons misés.

Les applications de mise comprennent:

• Staking DA disponible : les utilisateurs peuvent miser des jetons AVAIL sur des validateurs ou des pools de nomination pour sécuriser le réseau et soutenir différentes applications, telles que les jeux Web3 et les plateformes DeFi. Les stakers gagnent des récompenses pour leurs contributions.
• Disponibilité du Nexus Staking : Les séquenceurs doivent miser des jetons AVAIL pour participer à la soumission et à l'ordonnancement des transactions. Les séquenceurs performants sont récompensés tandis que ceux qui sous-performent sont pénalisés.
• Disponibilité de la mise en jeu de Fusion : En plus des jetons AVAIL, les utilisateurs peuvent mettre en jeu d'autres actifs crypto majeurs tels que BTC et ETH pour renforcer la sécurité du réseau, les stakers recevant des récompenses.

Il est important de noter que les utilisateurs souhaitant retirer leurs jetons doivent subir une période de désengagement de 28 jours, pendant laquelle leurs jetons AVAIL ne peuvent pas être utilisés ou transférés.

Défis

Risque de concurrence Rollup

La croissance d'Avail pourrait être mise à mal par des rollups généraux de grande envergure qui disposent d'écosystèmes établis et de solutions d'interopérabilité internes. Ces rollups pourraient finir par ne plus dépendre des systèmes d'interopérabilité externes, ce qui pourrait diminuer la valeur d'Avail Nexus. Cependant, la montée en puissance des rollups spécifiques aux applications et le degré élevé de fragmentation auquel les utilisateurs sont confrontés rendent ce scénario moins probable.

Concurrence dans les solutions DA

Avec plusieurs solutions de disponibilité des données (DA), telles que Celestia et EigenDA, ainsi que l'EIP-4844 à venir d'Ethereum, qui introduit les “blobs” comme option de publication de données, la concurrence dans la couche DA s'intensifie. La sensibilité des Rollups aux coûts de publication de données et la concurrence féroce entre les solutions DA peuvent les pousser à préférer des systèmes DA établis ou à compter sur la disponibilité native des données d'Ethereum, surtout une fois que le danksharding complet sera mis en œuvre. Cela pourrait potentiellement avoir un impact sur l'adoption de la solution DA d'Avail.

Risque de sécurité partagé

Le modèle de sécurité partagée fourni par Avail Fusion repose sur la mise en jeu de plusieurs actifs aux côtés du jeton AVAIL, ce qui peut susciter des inquiétudes chez les utilisateurs quant à la sécurité de ces différents actifs. Certains développeurs peuvent préférer tirer la sécurité d'un seul actif bien établi comme l'ETH ou le BTC plutôt que de dépendre de plusieurs jetons. De plus, les développeurs peuvent se tourner vers des solutions DA avec une sécurité économique plus solide si Avail Fusion ne parvient pas à offrir une sécurité suffisante.

Concurrence des Écosystèmes de Services à Valeur Ajoutée

D'autres produits de répartition ou de sécurité partagée peuvent développer des écosystèmes de services à valeur ajoutée adaptés aux rollups. Par exemple, EigenLayer pourrait offrir des services de séquençage décentralisés, de disponibilité des données et de finalité rapide, ce qui le rendrait plus compétitif. Ces fonctionnalités supplémentaires peuvent attirer les développeurs à la recherche d'une solution plus complète et sécurisée.