! [Évolutivité DA : état actuel de la disponibilité] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
Au fur et à mesure que les utilisateurs commencent à intégrer Avail dans la conception de leurs chaînes, la question se pose souvent : « Combien de transactions Avail peut-il traiter ? » Dans cet article, nous allons comparer le débit d’Ethereum et d’Avail en fonction de l’architecture actuelle des deux chaînes.
Il s’agit du premier d’une série sur l’évolutivité d’Avail qui traitera des performances actuelles d’Avail et de sa capacité à évoluer à court et à long terme.
Avail vs Ethereum
Les blocs d’Ethereum peuvent contenir jusqu’à 1,875 Mo de données et ont un temps de blocage d’environ 13 secondes. Cependant, les blocs d’Ethereum ne sont généralement pas remplis. Presque tous les blocs n’atteindront pas la limite supérieure des données car ils atteignent la limite de gaz, car l’exécution et le règlement consomment du gaz. Par conséquent, la quantité de données stockées dans chaque bloc est variable.
La nécessité de combiner l’exécution, le règlement et la disponibilité des données dans un même bloc est un problème central avec une architecture blockchain unique. Les rollups L2 ont lancé le mouvement pour les blockchains modulaires, permettant aux opérations d’exécution d’être gérées sur une seule chaîne, et les blocs de la chaîne sont dédiés à l’exécution. Avail va encore plus loin en adoptant une conception modulaire qui dissocie également la disponibilité des données, ce qui permet aux blocs d’une chaîne d’être dédiés à la disponibilité des données.
! [Évolutivité DA : état actuel de la disponibilité] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Actuellement, le temps de blocage d’Avail est de 20 secondes, et chaque bloc peut contenir environ 2 Mo de données. En supposant une taille de transaction moyenne de 250 octets, chaque bloc Avail peut contenir environ 8 400 transactions aujourd’hui (420 transactions par seconde).
De plus, Avail peut toujours remplir les blocs jusqu’à la limite de stockage et augmenter la taille si nécessaire. Nous disposons d’un certain nombre de leviers qui peuvent être rapidement ajustés pour augmenter le nombre de transactions par bloc à plus de 500 000 (25 000 transactions par seconde) en cas de besoin.
Peut-on augmenter le débit ?
Afin d’augmenter le débit (en particulier les transactions par seconde), les architectes de la chaîne doivent augmenter la taille des blocs ou diminuer le temps de bloc.
Pour être ajouté à la chaîne, chaque bloc doit générer des engagements, créer des preuves, les propager et demander à tous les autres nœuds de vérifier ces preuves. Ces étapes prennent toujours du temps, ce qui définit une limite supérieure naturelle au temps nécessaire pour que les blocs soient générés et confirmés.
Par conséquent, nous ne pouvons pas simplement réduire le temps de blocage à, disons, une seconde. Cela n’a tout simplement pas assez de temps pour générer des engagements, générer des preuves et propager ces parties à tous les participants du réseau. Dans un bloc de temps théorique d’une seconde, même si chaque acteur du réseau fait fonctionner la machine la plus puissante capable de produire des engagements et des preuves en un instant, le goulot d’étranglement réside dans la propagation des données. En raison des limitations de vitesse d’Internet, le réseau n’est pas en mesure de notifier suffisamment rapidement tous les nœuds complets des blocs. Nous devons donc nous assurer que le temps de bloc est suffisamment élevé pour permettre aux données d’être distribuées au réseau une fois le consensus atteint.
Inversement, il est également possible d’augmenter le débit en augmentant la taille du bloc, c’est-à-dire en augmentant la quantité de données que l’on peut contenir dans chaque bloc.
Architecture actuelle : Ajouter un bloc à la chaîne
Tout d’abord, examinons les étapes nécessaires pour ajouter un bloc à la chaîne. Trois étapes principales sont nécessaires pour ajouter chaque bloc à la chaîne. Cela inclut le temps nécessaire pour générer un bloc, le propager et le valider.
! [Évolutivité DA : état actuel de la disponibilité] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Génération de blocs
Cette étape comprend le temps nécessaire à la collecte et au tri des transactions Avail, à la création d’engagements et à la mise à l’échelle (codage d’effacement) de la matrice de données.
La génération de blocs mesure le temps qu’il faut pour générer un bloc, car cela prendra toujours au moins un certain temps. Par conséquent, nous devons prendre en compte non seulement le temps dans le meilleur des cas, mais aussi la situation moyenne et le temps dans le pire des cas sur différentes machines.
La machine la plus faible qui peut participer à la génération de nouveaux blocs est celle qui atteint la limite de performance en moyenne. Toutes les machines les plus lentes finiront par prendre du retard parce qu’elles ne peuvent pas rattraper les machines plus rapides.
2. Délai de propagation
Le délai de propagation est une mesure du temps nécessaire pour propager un bloc d’un producteur à un validateur et à un réseau peer-to-peer.
Actuellement, la taille de bloc d’Avail est de 2 Mo. Dans la limite de temps de bloc actuelle de 20 secondes, une telle taille de bloc peut être propagée. Des blocs de plus grande taille rendent la propagation plus délicate.
Par exemple, si nous augmentons Avail pour prendre en charge un bloc de 128 Mo, le calcul peut être mis à l’échelle (environ 7 secondes). Cependant, le goulot d’étranglement devient le temps nécessaire pour envoyer et télécharger ces blocs sur le réseau.
L’envoi d’un bloc de 128 Mo au monde entier sur un réseau peer-to-peer en 5 secondes peut être la limite de ce qui est actuellement réalisable.
La limite de 128 Mo n’a rien à voir avec la disponibilité des données ou notre scénario d’engagement, mais plutôt avec les limitations de la bande passante de communication.
Ce besoin de prendre en compte la latence de propagation nous donne la limite théorique actuelle de taille de bloc d’Avail.
3. Validation des blocs
Une fois propagés, les validateurs participants ne se contentent pas de faire confiance aux blocs qui leur sont fournis par le proposant du bloc, ils doivent vérifier que le bloc produit contient réellement les données revendiquées par le producteur.
Il y a une certaine tension entre ces trois étapes. Nous pouvons faire en sorte que tous les validateurs soient des machines puissantes et étroitement connectées par un excellent réseau dans le même centre de données, ce qui réduira le temps de production et de validation, et nous permettra de propager beaucoup plus de données. Cependant, comme nous voulons également avoir un réseau décentralisé et diversifié avec différents types de participants, ce n’est pas une approche idéale.
Au lieu de cela, l’augmentation du débit sera obtenue en comprenant les étapes nécessaires pour ajouter des blocs à la chaîne Avail et les étapes qui peuvent être optimisées.
! [Évolutivité DA : état actuel de la disponibilité] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Actuellement, les validateurs utilisant Avail prennent l’intégralité du bloc et copient tous les engagements générés par le proposant pour valider le bloc. Cela signifie que les producteurs de blocs et tous les validateurs doivent effectuer chacune des étapes du tableau ci-dessus.
Dans une seule blockchain, c’est la pratique par défaut pour chaque validateur de reconstruire l’ensemble du bloc. Cependant, sur une chaîne comme Avail, où les transactions ne sont pas exécutées, cette reconstruction n’est pas nécessaire. Par conséquent, l’une des façons d’optimiser Avail est de permettre aux validateurs d’obtenir leurs propres garanties de disponibilité des données par le biais de l’échantillonnage, plutôt que de la reconstruction de blocs. Cela demande moins de ressources aux validateurs que de les obliger à reproduire tous les engagements. Nous y reviendrons dans un prochain article.
Comment fonctionne l’échantillonnage exploratoire de la disponibilité des données ?
Dans Avail, les clients légers utilisent trois outils principaux pour confirmer la disponibilité des données : les échantillons, les engagements et les preuves.
Actuellement, les clients légers effectuent des opérations d’échantillonnage qui demandent la valeur d’une cellule particulière et sa preuve de validité associée au réseau Avail. Plus ils prélèvent d’échantillons, plus ils sont sûrs que toutes les données sont disponibles.
Les engagements sont générés par les proposants de blocs et résument une ligne entière de données dans un bloc Avail. (Astuce : il s’agit de l’étape que nous optimiserons plus tard dans cette série.) ）
Chaque cellule du réseau génère une épreuve. Les clients légers utilisent des attestations et des promesses pour vérifier que les valeurs des cellules qui leur sont fournies sont correctes.
À l’aide de ces outils, le client léger effectue ensuite trois étapes.
Décision : le degré de confiance de disponibilité requis détermine le nombre d’échantillons pour l’exécution du client léger. Ils n’ont pas besoin de beaucoup d’échantillons (8 à 30 échantillons) pour obtenir une garantie de disponibilité de plus de 99,95 %.
Téléchargement : Le client léger demande ensuite ces échantillons et leurs preuves associées et les télécharge depuis le réseau (nœud complet ou autre client léger).
Validation : Ils regardent la promesse dans l’en-tête du bloc (qui est toujours accessible aux clients légers) et vérifient la preuve de chaque cellule par rapport à la promesse.
Rien qu’avec cela, les clients légers peuvent confirmer la disponibilité de toutes les données d’un bloc sans avoir à télécharger la plupart du contenu du bloc. D’autres mesures prises par les clients légers contribuent également à la sécurité d’Avail, mais ne sont pas répertoriées ici. Par exemple, les clients légers peuvent partager des échantillons et des épreuves qu’ils téléchargent avec d’autres clients légers au cas où ils en auraient besoin. Mais c’est la procédure à suivre pour les clients légers afin de confirmer la disponibilité des données !
Dans la deuxième partie de cette série, nous explorerons les moyens d’augmenter le débit d’Avail à court terme. Nous expliquerons pourquoi nous pensons qu’Avail peut répondre aux besoins de n’importe quel réseau au cours de l’année à venir, et comment nous pouvons améliorer le réseau pour relever les défis des années à venir.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Évolutivité DA : état actuel d’Avail
! [Évolutivité DA : état actuel de la disponibilité] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
Au fur et à mesure que les utilisateurs commencent à intégrer Avail dans la conception de leurs chaînes, la question se pose souvent : « Combien de transactions Avail peut-il traiter ? » Dans cet article, nous allons comparer le débit d’Ethereum et d’Avail en fonction de l’architecture actuelle des deux chaînes.
Il s’agit du premier d’une série sur l’évolutivité d’Avail qui traitera des performances actuelles d’Avail et de sa capacité à évoluer à court et à long terme.
Avail vs Ethereum
Les blocs d’Ethereum peuvent contenir jusqu’à 1,875 Mo de données et ont un temps de blocage d’environ 13 secondes. Cependant, les blocs d’Ethereum ne sont généralement pas remplis. Presque tous les blocs n’atteindront pas la limite supérieure des données car ils atteignent la limite de gaz, car l’exécution et le règlement consomment du gaz. Par conséquent, la quantité de données stockées dans chaque bloc est variable.
La nécessité de combiner l’exécution, le règlement et la disponibilité des données dans un même bloc est un problème central avec une architecture blockchain unique. Les rollups L2 ont lancé le mouvement pour les blockchains modulaires, permettant aux opérations d’exécution d’être gérées sur une seule chaîne, et les blocs de la chaîne sont dédiés à l’exécution. Avail va encore plus loin en adoptant une conception modulaire qui dissocie également la disponibilité des données, ce qui permet aux blocs d’une chaîne d’être dédiés à la disponibilité des données.
! [Évolutivité DA : état actuel de la disponibilité] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Actuellement, le temps de blocage d’Avail est de 20 secondes, et chaque bloc peut contenir environ 2 Mo de données. En supposant une taille de transaction moyenne de 250 octets, chaque bloc Avail peut contenir environ 8 400 transactions aujourd’hui (420 transactions par seconde).
De plus, Avail peut toujours remplir les blocs jusqu’à la limite de stockage et augmenter la taille si nécessaire. Nous disposons d’un certain nombre de leviers qui peuvent être rapidement ajustés pour augmenter le nombre de transactions par bloc à plus de 500 000 (25 000 transactions par seconde) en cas de besoin.
Peut-on augmenter le débit ?
Afin d’augmenter le débit (en particulier les transactions par seconde), les architectes de la chaîne doivent augmenter la taille des blocs ou diminuer le temps de bloc.
Pour être ajouté à la chaîne, chaque bloc doit générer des engagements, créer des preuves, les propager et demander à tous les autres nœuds de vérifier ces preuves. Ces étapes prennent toujours du temps, ce qui définit une limite supérieure naturelle au temps nécessaire pour que les blocs soient générés et confirmés.
Par conséquent, nous ne pouvons pas simplement réduire le temps de blocage à, disons, une seconde. Cela n’a tout simplement pas assez de temps pour générer des engagements, générer des preuves et propager ces parties à tous les participants du réseau. Dans un bloc de temps théorique d’une seconde, même si chaque acteur du réseau fait fonctionner la machine la plus puissante capable de produire des engagements et des preuves en un instant, le goulot d’étranglement réside dans la propagation des données. En raison des limitations de vitesse d’Internet, le réseau n’est pas en mesure de notifier suffisamment rapidement tous les nœuds complets des blocs. Nous devons donc nous assurer que le temps de bloc est suffisamment élevé pour permettre aux données d’être distribuées au réseau une fois le consensus atteint.
Inversement, il est également possible d’augmenter le débit en augmentant la taille du bloc, c’est-à-dire en augmentant la quantité de données que l’on peut contenir dans chaque bloc.
Architecture actuelle : Ajouter un bloc à la chaîne
Tout d’abord, examinons les étapes nécessaires pour ajouter un bloc à la chaîne. Trois étapes principales sont nécessaires pour ajouter chaque bloc à la chaîne. Cela inclut le temps nécessaire pour générer un bloc, le propager et le valider.
! [Évolutivité DA : état actuel de la disponibilité] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Génération de blocs
Cette étape comprend le temps nécessaire à la collecte et au tri des transactions Avail, à la création d’engagements et à la mise à l’échelle (codage d’effacement) de la matrice de données.
La génération de blocs mesure le temps qu’il faut pour générer un bloc, car cela prendra toujours au moins un certain temps. Par conséquent, nous devons prendre en compte non seulement le temps dans le meilleur des cas, mais aussi la situation moyenne et le temps dans le pire des cas sur différentes machines.
La machine la plus faible qui peut participer à la génération de nouveaux blocs est celle qui atteint la limite de performance en moyenne. Toutes les machines les plus lentes finiront par prendre du retard parce qu’elles ne peuvent pas rattraper les machines plus rapides.
2. Délai de propagation
Le délai de propagation est une mesure du temps nécessaire pour propager un bloc d’un producteur à un validateur et à un réseau peer-to-peer.
Actuellement, la taille de bloc d’Avail est de 2 Mo. Dans la limite de temps de bloc actuelle de 20 secondes, une telle taille de bloc peut être propagée. Des blocs de plus grande taille rendent la propagation plus délicate.
Par exemple, si nous augmentons Avail pour prendre en charge un bloc de 128 Mo, le calcul peut être mis à l’échelle (environ 7 secondes). Cependant, le goulot d’étranglement devient le temps nécessaire pour envoyer et télécharger ces blocs sur le réseau.
L’envoi d’un bloc de 128 Mo au monde entier sur un réseau peer-to-peer en 5 secondes peut être la limite de ce qui est actuellement réalisable.
La limite de 128 Mo n’a rien à voir avec la disponibilité des données ou notre scénario d’engagement, mais plutôt avec les limitations de la bande passante de communication.
Ce besoin de prendre en compte la latence de propagation nous donne la limite théorique actuelle de taille de bloc d’Avail.
3. Validation des blocs
Une fois propagés, les validateurs participants ne se contentent pas de faire confiance aux blocs qui leur sont fournis par le proposant du bloc, ils doivent vérifier que le bloc produit contient réellement les données revendiquées par le producteur.
Il y a une certaine tension entre ces trois étapes. Nous pouvons faire en sorte que tous les validateurs soient des machines puissantes et étroitement connectées par un excellent réseau dans le même centre de données, ce qui réduira le temps de production et de validation, et nous permettra de propager beaucoup plus de données. Cependant, comme nous voulons également avoir un réseau décentralisé et diversifié avec différents types de participants, ce n’est pas une approche idéale.
Au lieu de cela, l’augmentation du débit sera obtenue en comprenant les étapes nécessaires pour ajouter des blocs à la chaîne Avail et les étapes qui peuvent être optimisées.
! [Évolutivité DA : état actuel de la disponibilité] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Actuellement, les validateurs utilisant Avail prennent l’intégralité du bloc et copient tous les engagements générés par le proposant pour valider le bloc. Cela signifie que les producteurs de blocs et tous les validateurs doivent effectuer chacune des étapes du tableau ci-dessus.
Dans une seule blockchain, c’est la pratique par défaut pour chaque validateur de reconstruire l’ensemble du bloc. Cependant, sur une chaîne comme Avail, où les transactions ne sont pas exécutées, cette reconstruction n’est pas nécessaire. Par conséquent, l’une des façons d’optimiser Avail est de permettre aux validateurs d’obtenir leurs propres garanties de disponibilité des données par le biais de l’échantillonnage, plutôt que de la reconstruction de blocs. Cela demande moins de ressources aux validateurs que de les obliger à reproduire tous les engagements. Nous y reviendrons dans un prochain article.
Comment fonctionne l’échantillonnage exploratoire de la disponibilité des données ?
Dans Avail, les clients légers utilisent trois outils principaux pour confirmer la disponibilité des données : les échantillons, les engagements et les preuves.
À l’aide de ces outils, le client léger effectue ensuite trois étapes.
Rien qu’avec cela, les clients légers peuvent confirmer la disponibilité de toutes les données d’un bloc sans avoir à télécharger la plupart du contenu du bloc. D’autres mesures prises par les clients légers contribuent également à la sécurité d’Avail, mais ne sont pas répertoriées ici. Par exemple, les clients légers peuvent partager des échantillons et des épreuves qu’ils téléchargent avec d’autres clients légers au cas où ils en auraient besoin. Mais c’est la procédure à suivre pour les clients légers afin de confirmer la disponibilité des données !
Dans la deuxième partie de cette série, nous explorerons les moyens d’augmenter le débit d’Avail à court terme. Nous expliquerons pourquoi nous pensons qu’Avail peut répondre aux besoins de n’importe quel réseau au cours de l’année à venir, et comment nous pouvons améliorer le réseau pour relever les défis des années à venir.