La disponibilité des données est l'un des principaux goulots d'étranglement dans l'expansion de la blockchain.
**Écrit par : **zer0kn0wledge.era
Compilé par : Kate, Marsbit
Remarque : Cet article provient de @expctchaos Twitter, qui est un chercheur de @ChaosDAO. Le contenu du tweet original est organisé par MarsBit comme suit :
0/ La disponibilité des données (DA) est le principal goulot d'étranglement de la mise à l'échelle
Heureusement @CelestiaOrg, @AvailProject et @eigenlayer vont changer le jeu DA et permettre de nouveaux niveaux d'évolutivité
Mais comment ça marche et en quoi #EigenDA est différent de DA 15 comme #Celestia et #Avail ?
1/ Si vous n'êtes pas familier avec les problèmes de disponibilité des données, veuillez consulter mon article ci-dessous où je décris en détail la situation de la disponibilité des données 👇
2/ De manière générale, il existe deux grands types de solutions informatiques
🔷DA en chaîne
🔷DA hors chaîne
3/ Et la "vérification de la validité pure" signifie que le traitement des données peut être hors chaîne sans garanties, car les fournisseurs de services de données hors chaîne peuvent se déconnecter à tout moment...
4/ …#StarkEx, #zkPorter et #Arbitrum Nova sont des exemples de scénarios de vérification qui s'appuient sur DAC, un groupe de tiers bien connus pour garantir la disponibilité des données
5/ En revanche, #EigenDA, @CelestiaOrg et @AvailProject sont ce qu'on pourrait appeler une solution DA universelle
Cependant, il existe quelques différences entre EigenDA et les deux autres solutions
6/ Si vous voulez savoir comment fonctionne @CelestiaOrg, consultez le lien ci-dessous
7/ J'ai également couvert @AvailProject dans le passé, alors pour en savoir plus, consultez-le ici
8/ Si vous avez besoin d'un rappel sur @eigenlayer, consultez le fil ci-dessous 👇
9/ Donc, dans le post d'aujourd'hui, nous voulons nous concentrer sur la comparaison entre les chaînes #EigenDA et DA L1 de @eigenlayer comme @CelestiaOrg ou @AvailProject
10/ Supposons un rollup basé sur Ethereum et utilisant Celestia pour DA (alias Celestium)
Ainsi, les contrats L2 sur Ethereum vérifient la preuve de validité ou la preuve de fraude comme d'habitude, et DA est fourni par Celestia
11/ Sur @CelestiaOrg et @AvailProject, il n'y a pas de contrats intelligents ou de calculs, seules les données sont garanties d'être disponibles
12/ Mais regardons de plus près
Sur @CelestiaOrg, les données tx sont publiées sur Celestia par le trieur L2, le vérificateur Celestia signe la racine Merkle de la preuve DA, puis envoyées au contrat de pont DA sur Ethereum pour vérification et stockage
13/ Par rapport au stockage de DA en chaîne, cela réduit considérablement le coût d'avoir une garantie DA solide, tout en offrant également des garanties de sécurité de Celestia (plutôt qu'un DAC centralisé)
14/ La réduction des coûts va changer les règles du jeu dans l'ensemble du champ de cumul, car le coût des données d'appel générées par la publication de données sur Ethereum L1 représente 80 à 90 % du coût de cumul
Pour plus d'informations sur le coût des données d'appel, consultez l'article ci-dessous 👇
15/ Mais qu'est-ce qui s'est passé sur #Celestia ?
Les blobs de données publiés sur @CelestiaOrg (essentiellement sous forme de données brutes) sont propagés via le réseau P2P et un consensus sur le blob de données est atteint à l'aide du consensus Tendermint
16/ Chaque nœud complet #Celestia doit télécharger l'intégralité du blob de données. Ceci est différent pour les nœuds légers qui peuvent utiliser l'échantillonnage de la disponibilité des données (DAS) pour garantir la disponibilité des données
17/ Pour plus d'informations sur les DAS et les nœuds légers, veuillez consulter le post ci-dessous
18/ Nous reviendrons également sur DAS plus tard dans ce fil, mais pour l'instant l'accent est mis sur les nœuds complets
Revenons donc à @CelestiaOrg, qui continue de se comporter de manière L1, en s'appuyant sur la diffusion et le consensus sur les blobs de données
19/ Par conséquent, il impose des exigences élevées sur l'ensemble des nœuds du réseau (128 Mo/s en téléchargement et 12,5 Mo/s en envoi).
Pourtant, @CelestiaOrg visait un débit modéré (1,4 Mo/s) au départ, ce qui semble faible compte tenu des exigences complètes du nœud
20/ Cependant, le réseau peut augmenter le débit en ajoutant des nœuds légers. Plus il y a de nœuds légers d'échantillonnage de données, plus la taille du bloc peut être grande à condition d'assurer la sécurité et la décentralisation
21/ En revanche, @eigenlayer a une architecture différente, pas de consensus propre, et pas de réseau peer-to-peer
Alors, comment ça marche?
Tout d'abord, le nœud EigenDA doit réallouer $ETH dans le contrat @eigenlayer. Par conséquent, les nœuds #EigenDA sont un sous-ensemble de validateurs Ethereum
22/ Après avoir reçu le data blob, un acheteur DA (comme un rollup, aussi appelé disperser) l'encode alors avec un code d'effacement et génère un engagement KZG…
23/…où la taille de la preuve dépend du taux de redondance du code d'effacement et publie l'engagement de KZG envers le contrat intelligent #EigenDA
24/ Engagement KZG codé distribué par le disperseur aux nœuds #EigenDA
Après avoir reçu l'engagement KZG, ces nœuds le comparent avec l'engagement KZG du contrat intelligent EigenDA et signent la preuve après confirmation
25/ Après cela, le disperseur collecte ces signatures une par une, génère une signature agrégée, et la publie dans le smart contract #EigenDA, et le smart contract vérifie la signature
26/ Mais si le nœud #EigenDA signe simplement une preuve affirmant qu'il a stocké le blob de données encodé dans ce workflow, et que le contrat intelligent EigenDA vérifie uniquement l'exactitude de la signature agrégée, comment pouvons-nous être sûrs que le nœud EigenDA a réellement stocké des données ?
27/ #EigenDA utilise une méthode de preuve d'entiercement pour y parvenir
Mais prenons du recul et regardons cette scène où ça devient important
28/ Supposons que certains validateurs paresseux ne font pas les tâches qui leur sont assignées (par exemple, s'assurer que les données sont disponibles)
Au lieu de cela, ils prétendent avoir fait le travail et approuvent le résultat final (rapportant faussement la disponibilité des données lorsqu'elles ne sont pas disponibles).
29/ Conceptuellement, une preuve de garde est comme une preuve de fraude :
N'importe qui peut soumettre une preuve (validateur paresseux) au contrat intelligent #EigenDA qui sera vérifié par le contrat intelligent
29/ Le validateur paresseux est barré si la validation est réussie (car il s'agit d'une erreur objectivement attribuable)
30/ Qu'en est-il du consensus ?
@CelestiaOrg utilise Tendermint comme protocole de consensus, qui a une finalité à un seul emplacement. Autrement dit, une fois qu'un bloc passe le consensus #Celestia, c'est fait. Cela signifie que la finalité est fondamentalement aussi rapide que le temps de bloc (15 secondes).
31/ @AvailProject utilise la composition du protocole pour atteindre la finalité. BABE est un mécanisme de production de blocs à finalité probabiliste, et GRANDPA est un gadget final. Alors que GRANDPA peut compléter des blocs dans un seul emplacement, il peut également compléter plusieurs blocs en un tour
32/ Étant donné que @eigenlayer est un ensemble de contrats intelligents sur Ethereum, il hérite également du même temps de finalisation qu'Ethereum (12 - 15 minutes) pour les données qui doivent être transmises au contrat rollup pour prouver la disponibilité des données
33/ Cependant, si le cumul utilise @eigenlayer, cela pourrait être fait plus rapidement, selon le mécanisme de consensus utilisé, etc.
De plus, le middleware sécurisé par les validateurs de reprise de @eigenlayer se concentre sur la fourniture de règlements rapides, par exemple EigenSettle peut fournir de solides garanties de sécurité économique permettant la pré-confirmation de la finalité. Cependant, les garanties de finalité absolue proviennent toujours d'Ethereum L1
34/ Il est temps de revoir les concepts d'échantillonnage de la disponibilité des données
Dans la plupart des blockchains, les nœuds doivent télécharger toutes les données de transaction pour vérifier la disponibilité des données. Le problème que cela crée est que lorsque la taille du bloc augmente, le nombre de nœuds de données qui doivent être vérifiés augmente également
35/ L'échantillonnage de la disponibilité des données (DAS) est une technique qui permet aux nœuds légers de vérifier la disponibilité des données en ne téléchargeant qu'une petite partie des données du bloc
36/ Cela fournit une sécurité aux nœuds légers afin qu'ils puissent valider les blocs invalides (DA et consensus uniquement) et permet à la blockchain d'adapter la disponibilité des données sans augmenter les exigences des nœuds
37/ DAS nécessite au moins un nœud complet honnête et un nombre suffisant de clients légers
38/ Mais comment assurer la sécurité des nœuds légers ?
Les clients légers traditionnels ont des hypothèses de sécurité plus faibles que les nœuds complets, car ils ne valident que les en-têtes de bloc
Par conséquent, les clients légers ne peuvent pas détecter si un bloc invalide a été produit par une majorité malhonnête de producteurs de blocs
39/ Les nœuds légers avec échantillonnage de la disponibilité des données sont mis à niveau en sécurité, car si la couche DA ne fait que le consensus et la disponibilité des données, ils peuvent vérifier si des blocs invalides sont produits
40/ @CelestiaOrg et @AvailProject auront un échantillonnage de la disponibilité des données afin que leurs nœuds légers aient une sécurité minimisée par la confiance.
41/ C'est différent d'Ethereum et @eigenlayer
Ethereum avec # EIP4844 n'a pas d'échantillonnage de la disponibilité des données, de sorte que ses clients légers n'auront pas une sécurité minimisée par la confiance
42/ Étant donné qu'Ethereum dispose également de son environnement de contrats intelligents, les clients légers doivent également vérifier l'exécution (par fraude ou preuve de validité), plutôt que de se fier à la plupart des hypothèses d'honnêteté
43/ Le client léger @eigenlayer (sauf s'il existe un DAS), s'il est pris en charge, s'appuiera sur une majorité honnête de nœuds de reprise
Par conséquent, la sécurité de #EigenDA repose principalement sur l'ensemble de validateurs Ethereum, héritant de la primitive de slashing Ethereum et assurant la sécurité économique de DA
44/ Ainsi, une plus grande participation des parties prenantes à #EigenDA signifie une plus grande sécurité. La réduction des besoins en nœuds contribue également à une meilleure décentralisation
45/ Le codage d'effacement est un mécanisme important qui permet l'échantillonnage de la disponibilité des données. Le codage d'effacement étend les blocs en créant des copies supplémentaires des données. Des données supplémentaires créent une redondance, offrant des garanties de sécurité plus fortes pour le processus d'échantillonnage
46/ Cependant, les nœuds peuvent tenter de mal coder les données afin de perturber le réseau. Pour se défendre contre cette attaque, les nœuds ont besoin d'un moyen de vérifier que l'encodage est correct - c'est là qu'interviennent les preuves.
47/ Ethereum, @eigenlayer et @AvailProject utilisent tous un schéma de preuve de validité pour s'assurer que les blocs sont correctement encodés. L'idée est similaire aux preuves de validité utilisées par zk rollup. @eigenlayer en a discuté plus tôt dans ce fil
48/ Chaque fois qu'un bloc est généré, le vérificateur doit s'engager sur les données vérifiées par le nœud à l'aide de la preuve KZG pour prouver que le bloc est correctement encodé
49/ Bien que la génération d'engagements pour les preuves KZG nécessite plus de surcharge de calcul pour les producteurs de blocs, lorsque les blocs sont petits, la génération d'engagements n'entraîne pas beaucoup de surcharge. Cependant, cela a changé...
50/… à mesure que les blocs grossissent, le fardeau de l'engagement de la preuve KZG est beaucoup plus élevé
Par conséquent, le type de nœud responsable de la génération de ces engagements peut avoir des exigences matérielles plus élevées
51/ D'autre part, @CelestiaOrg implémente des preuves de fraude pour le codage d'effacement. Par conséquent, les nœuds #Celestia n'ont pas besoin de vérifier que les blocs sont correctement encodés. ils sont corrects par défaut
52/ L'avantage est que les producteurs de blocs n'ont pas besoin de faire le travail coûteux de générer des engagements codés d'effacement
Mais il y a un compromis, car les nœuds légers doivent attendre un peu de temps avant de supposer qu'un bloc est correctement encodé et de le terminer à leur avis
53/ La principale différence entre les schémas de codage à l'épreuve de la fraude et à l'épreuve de la validité est le compromis entre la surcharge du nœud pour générer des engagements et la latence pour les nœuds légers
54/ Ce tableau résume bien la comparaison
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Comment fonctionnent les solutions de disponibilité des données et en quoi diffèrent-elles ?
**Écrit par : **zer0kn0wledge.era
Compilé par : Kate, Marsbit
Remarque : Cet article provient de @expctchaos Twitter, qui est un chercheur de @ChaosDAO. Le contenu du tweet original est organisé par MarsBit comme suit :
0/ La disponibilité des données (DA) est le principal goulot d'étranglement de la mise à l'échelle
Heureusement @CelestiaOrg, @AvailProject et @eigenlayer vont changer le jeu DA et permettre de nouveaux niveaux d'évolutivité
Mais comment ça marche et en quoi #EigenDA est différent de DA 15 comme #Celestia et #Avail ?
1/ Si vous n'êtes pas familier avec les problèmes de disponibilité des données, veuillez consulter mon article ci-dessous où je décris en détail la situation de la disponibilité des données 👇
2/ De manière générale, il existe deux grands types de solutions informatiques
3/ Et la "vérification de la validité pure" signifie que le traitement des données peut être hors chaîne sans garanties, car les fournisseurs de services de données hors chaîne peuvent se déconnecter à tout moment...
4/ …#StarkEx, #zkPorter et #Arbitrum Nova sont des exemples de scénarios de vérification qui s'appuient sur DAC, un groupe de tiers bien connus pour garantir la disponibilité des données
5/ En revanche, #EigenDA, @CelestiaOrg et @AvailProject sont ce qu'on pourrait appeler une solution DA universelle
Cependant, il existe quelques différences entre EigenDA et les deux autres solutions
6/ Si vous voulez savoir comment fonctionne @CelestiaOrg, consultez le lien ci-dessous
7/ J'ai également couvert @AvailProject dans le passé, alors pour en savoir plus, consultez-le ici
8/ Si vous avez besoin d'un rappel sur @eigenlayer, consultez le fil ci-dessous 👇
9/ Donc, dans le post d'aujourd'hui, nous voulons nous concentrer sur la comparaison entre les chaînes #EigenDA et DA L1 de @eigenlayer comme @CelestiaOrg ou @AvailProject
10/ Supposons un rollup basé sur Ethereum et utilisant Celestia pour DA (alias Celestium)
Ainsi, les contrats L2 sur Ethereum vérifient la preuve de validité ou la preuve de fraude comme d'habitude, et DA est fourni par Celestia
11/ Sur @CelestiaOrg et @AvailProject, il n'y a pas de contrats intelligents ou de calculs, seules les données sont garanties d'être disponibles
12/ Mais regardons de plus près
Sur @CelestiaOrg, les données tx sont publiées sur Celestia par le trieur L2, le vérificateur Celestia signe la racine Merkle de la preuve DA, puis envoyées au contrat de pont DA sur Ethereum pour vérification et stockage
13/ Par rapport au stockage de DA en chaîne, cela réduit considérablement le coût d'avoir une garantie DA solide, tout en offrant également des garanties de sécurité de Celestia (plutôt qu'un DAC centralisé)
14/ La réduction des coûts va changer les règles du jeu dans l'ensemble du champ de cumul, car le coût des données d'appel générées par la publication de données sur Ethereum L1 représente 80 à 90 % du coût de cumul
Pour plus d'informations sur le coût des données d'appel, consultez l'article ci-dessous 👇
15/ Mais qu'est-ce qui s'est passé sur #Celestia ?
Les blobs de données publiés sur @CelestiaOrg (essentiellement sous forme de données brutes) sont propagés via le réseau P2P et un consensus sur le blob de données est atteint à l'aide du consensus Tendermint
16/ Chaque nœud complet #Celestia doit télécharger l'intégralité du blob de données. Ceci est différent pour les nœuds légers qui peuvent utiliser l'échantillonnage de la disponibilité des données (DAS) pour garantir la disponibilité des données
17/ Pour plus d'informations sur les DAS et les nœuds légers, veuillez consulter le post ci-dessous
18/ Nous reviendrons également sur DAS plus tard dans ce fil, mais pour l'instant l'accent est mis sur les nœuds complets
Revenons donc à @CelestiaOrg, qui continue de se comporter de manière L1, en s'appuyant sur la diffusion et le consensus sur les blobs de données
19/ Par conséquent, il impose des exigences élevées sur l'ensemble des nœuds du réseau (128 Mo/s en téléchargement et 12,5 Mo/s en envoi).
Pourtant, @CelestiaOrg visait un débit modéré (1,4 Mo/s) au départ, ce qui semble faible compte tenu des exigences complètes du nœud
20/ Cependant, le réseau peut augmenter le débit en ajoutant des nœuds légers. Plus il y a de nœuds légers d'échantillonnage de données, plus la taille du bloc peut être grande à condition d'assurer la sécurité et la décentralisation
21/ En revanche, @eigenlayer a une architecture différente, pas de consensus propre, et pas de réseau peer-to-peer
Alors, comment ça marche?
Tout d'abord, le nœud EigenDA doit réallouer $ETH dans le contrat @eigenlayer. Par conséquent, les nœuds #EigenDA sont un sous-ensemble de validateurs Ethereum
22/ Après avoir reçu le data blob, un acheteur DA (comme un rollup, aussi appelé disperser) l'encode alors avec un code d'effacement et génère un engagement KZG…
23/…où la taille de la preuve dépend du taux de redondance du code d'effacement et publie l'engagement de KZG envers le contrat intelligent #EigenDA
24/ Engagement KZG codé distribué par le disperseur aux nœuds #EigenDA
Après avoir reçu l'engagement KZG, ces nœuds le comparent avec l'engagement KZG du contrat intelligent EigenDA et signent la preuve après confirmation
25/ Après cela, le disperseur collecte ces signatures une par une, génère une signature agrégée, et la publie dans le smart contract #EigenDA, et le smart contract vérifie la signature
26/ Mais si le nœud #EigenDA signe simplement une preuve affirmant qu'il a stocké le blob de données encodé dans ce workflow, et que le contrat intelligent EigenDA vérifie uniquement l'exactitude de la signature agrégée, comment pouvons-nous être sûrs que le nœud EigenDA a réellement stocké des données ?
27/ #EigenDA utilise une méthode de preuve d'entiercement pour y parvenir
Mais prenons du recul et regardons cette scène où ça devient important
28/ Supposons que certains validateurs paresseux ne font pas les tâches qui leur sont assignées (par exemple, s'assurer que les données sont disponibles)
Au lieu de cela, ils prétendent avoir fait le travail et approuvent le résultat final (rapportant faussement la disponibilité des données lorsqu'elles ne sont pas disponibles).
29/ Conceptuellement, une preuve de garde est comme une preuve de fraude :
N'importe qui peut soumettre une preuve (validateur paresseux) au contrat intelligent #EigenDA qui sera vérifié par le contrat intelligent
29/ Le validateur paresseux est barré si la validation est réussie (car il s'agit d'une erreur objectivement attribuable)
30/ Qu'en est-il du consensus ?
@CelestiaOrg utilise Tendermint comme protocole de consensus, qui a une finalité à un seul emplacement. Autrement dit, une fois qu'un bloc passe le consensus #Celestia, c'est fait. Cela signifie que la finalité est fondamentalement aussi rapide que le temps de bloc (15 secondes).
31/ @AvailProject utilise la composition du protocole pour atteindre la finalité. BABE est un mécanisme de production de blocs à finalité probabiliste, et GRANDPA est un gadget final. Alors que GRANDPA peut compléter des blocs dans un seul emplacement, il peut également compléter plusieurs blocs en un tour
32/ Étant donné que @eigenlayer est un ensemble de contrats intelligents sur Ethereum, il hérite également du même temps de finalisation qu'Ethereum (12 - 15 minutes) pour les données qui doivent être transmises au contrat rollup pour prouver la disponibilité des données
33/ Cependant, si le cumul utilise @eigenlayer, cela pourrait être fait plus rapidement, selon le mécanisme de consensus utilisé, etc.
De plus, le middleware sécurisé par les validateurs de reprise de @eigenlayer se concentre sur la fourniture de règlements rapides, par exemple EigenSettle peut fournir de solides garanties de sécurité économique permettant la pré-confirmation de la finalité. Cependant, les garanties de finalité absolue proviennent toujours d'Ethereum L1
34/ Il est temps de revoir les concepts d'échantillonnage de la disponibilité des données
Dans la plupart des blockchains, les nœuds doivent télécharger toutes les données de transaction pour vérifier la disponibilité des données. Le problème que cela crée est que lorsque la taille du bloc augmente, le nombre de nœuds de données qui doivent être vérifiés augmente également
35/ L'échantillonnage de la disponibilité des données (DAS) est une technique qui permet aux nœuds légers de vérifier la disponibilité des données en ne téléchargeant qu'une petite partie des données du bloc
36/ Cela fournit une sécurité aux nœuds légers afin qu'ils puissent valider les blocs invalides (DA et consensus uniquement) et permet à la blockchain d'adapter la disponibilité des données sans augmenter les exigences des nœuds
37/ DAS nécessite au moins un nœud complet honnête et un nombre suffisant de clients légers
38/ Mais comment assurer la sécurité des nœuds légers ?
Les clients légers traditionnels ont des hypothèses de sécurité plus faibles que les nœuds complets, car ils ne valident que les en-têtes de bloc
Par conséquent, les clients légers ne peuvent pas détecter si un bloc invalide a été produit par une majorité malhonnête de producteurs de blocs
39/ Les nœuds légers avec échantillonnage de la disponibilité des données sont mis à niveau en sécurité, car si la couche DA ne fait que le consensus et la disponibilité des données, ils peuvent vérifier si des blocs invalides sont produits
40/ @CelestiaOrg et @AvailProject auront un échantillonnage de la disponibilité des données afin que leurs nœuds légers aient une sécurité minimisée par la confiance.
41/ C'est différent d'Ethereum et @eigenlayer
Ethereum avec # EIP4844 n'a pas d'échantillonnage de la disponibilité des données, de sorte que ses clients légers n'auront pas une sécurité minimisée par la confiance
42/ Étant donné qu'Ethereum dispose également de son environnement de contrats intelligents, les clients légers doivent également vérifier l'exécution (par fraude ou preuve de validité), plutôt que de se fier à la plupart des hypothèses d'honnêteté
43/ Le client léger @eigenlayer (sauf s'il existe un DAS), s'il est pris en charge, s'appuiera sur une majorité honnête de nœuds de reprise
Par conséquent, la sécurité de #EigenDA repose principalement sur l'ensemble de validateurs Ethereum, héritant de la primitive de slashing Ethereum et assurant la sécurité économique de DA
44/ Ainsi, une plus grande participation des parties prenantes à #EigenDA signifie une plus grande sécurité. La réduction des besoins en nœuds contribue également à une meilleure décentralisation
45/ Le codage d'effacement est un mécanisme important qui permet l'échantillonnage de la disponibilité des données. Le codage d'effacement étend les blocs en créant des copies supplémentaires des données. Des données supplémentaires créent une redondance, offrant des garanties de sécurité plus fortes pour le processus d'échantillonnage
46/ Cependant, les nœuds peuvent tenter de mal coder les données afin de perturber le réseau. Pour se défendre contre cette attaque, les nœuds ont besoin d'un moyen de vérifier que l'encodage est correct - c'est là qu'interviennent les preuves.
47/ Ethereum, @eigenlayer et @AvailProject utilisent tous un schéma de preuve de validité pour s'assurer que les blocs sont correctement encodés. L'idée est similaire aux preuves de validité utilisées par zk rollup. @eigenlayer en a discuté plus tôt dans ce fil
48/ Chaque fois qu'un bloc est généré, le vérificateur doit s'engager sur les données vérifiées par le nœud à l'aide de la preuve KZG pour prouver que le bloc est correctement encodé
49/ Bien que la génération d'engagements pour les preuves KZG nécessite plus de surcharge de calcul pour les producteurs de blocs, lorsque les blocs sont petits, la génération d'engagements n'entraîne pas beaucoup de surcharge. Cependant, cela a changé...
50/… à mesure que les blocs grossissent, le fardeau de l'engagement de la preuve KZG est beaucoup plus élevé
Par conséquent, le type de nœud responsable de la génération de ces engagements peut avoir des exigences matérielles plus élevées
51/ D'autre part, @CelestiaOrg implémente des preuves de fraude pour le codage d'effacement. Par conséquent, les nœuds #Celestia n'ont pas besoin de vérifier que les blocs sont correctement encodés. ils sont corrects par défaut
52/ L'avantage est que les producteurs de blocs n'ont pas besoin de faire le travail coûteux de générer des engagements codés d'effacement
Mais il y a un compromis, car les nœuds légers doivent attendre un peu de temps avant de supposer qu'un bloc est correctement encodé et de le terminer à leur avis
53/ La principale différence entre les schémas de codage à l'épreuve de la fraude et à l'épreuve de la validité est le compromis entre la surcharge du nœud pour générer des engagements et la latence pour les nœuds légers
54/ Ce tableau résume bien la comparaison