Comment les pairs dans un réseau blockchain peuvent-ils être sûrs que toutes les données d'un nouveau bloc proposé sont disponibles? Et pourquoi est-ce important?

Dans ce post, nous examinons en détail le problème de disponibilité des données et comment il peut avoir un impact sur la mise à l'échelle sur Ethereum.

Quel est le problème de disponibilité des données?

Le problème de disponibilité des données (DA) : Comment les pairs d'un réseau blockchain peuvent-ils être sûrs que toutes les données d'un nouveau bloc proposé sont effectivement disponibles ? Si les données ne sont pas disponibles, le bloc pourrait contenir des transactions malveillantes qui sont cachées par le producteur de blocs. Même si le bloc contient des transactions non malveillantes, les cacher pourrait compromettre la sécurité du système.

Pour donner un exemple, supposons qu'Alice est un opérateur d'un ZK-Rollup (ZKR). Elle soumet une preuve ZK sur Ethereum qui est vérifiée. Si elle ne soumet pas toutes les données transactionnelles sur Ethereum, bien que sa preuve prouve que toutes les transitions d'état prises dans le rollup sont valides, les utilisateurs du rollup pourraient être dans le flou concernant leurs soldes de compte actuels. La preuve soumise n'éclaire pas sur les états actuels en raison de sa nature de Zero-Knowledge.

Un exemple analogue existe dans le Optimistic Rollup (OPR)paramétrage, où Alice soumet une assertion sur Ethereum, mais aucun des participants de l'OPR ne peut la contester car les données transactionnelles ne sont pas disponibles et qu'ils sont donc incapables de recalculer ou de contester l'assertion.

Pour contrer les scénarios ci-dessus, les conceptions OPR et ZKR obligent les opérateurs à soumettre tous les détails transactionnels sur Ethereumcomme ‘calldata’. Bien que cela leur permette d'éviter le problème de DA à court terme, à mesure que le nombre de transactions augmente à l'intérieur des rollups, la quantité de données à soumettre augmenterait également, limitant la capacité de mise à l'échelle que ces rollups peuvent offrir.

Pour aggraver les choses, l'indisponibilité des données n'est pas une faute attribuable de manière unique. Cela signifie que les participants ne peuvent pas prouver à d'autres pairs qu'une partie spécifique des données est manquante. Cela est dû au fait que Bob peut diffuser le fait que le bloc soumis par Alice a des données manquantes, mais lorsque Charlie interroge Alice, elle peut lui fournir les données.

Comment cela affecte-t-il une blockchain aujourd'hui ?

Pour répondre à cette question, commençons par revoir la structure générale des blocs d'une blockchain similaire à Ethereum et les types de clients existant sur tout réseau blockchain.

Un bloc peut être divisé en deux parties principales:

• En-tête de bloc : Un petit en-tête de bloc contient le condensé et les métadonnées liés aux transactions incluses dans le bloc.
• Corps de bloc : il contient toutes les données transactionnelles et représente la majorité de la taille du bloc.

Dans les protocoles de blockchain conventionnels, tous les nœuds sont considérés comme des nœuds complets qui synchronisent l'ensemble du bloc et vérifient toutes les transitions d'état. Ils doivent dépenser une quantité considérable de ressources pour vérifier la validité des transactions et stocker les blocs. En revanche, ces nœuds ne peuvent pas être contraints d'accepter une transaction invalide.

Il pourrait y avoir une autre classe de nœuds qui n'ont pas (ou ne veulent pas dépenser) de ressources pour vérifier chaque transaction. Au lieu de cela, ils sont principalement intéressés à connaître l'état actuel de la blockchain et si certaines transactions, qui leur sont pertinentes, sont incluses dans la chaîne ou non. Idéalement, ces clients légers devraient également être protégés contre le suivi d'une chaîne contenant des transactions invalides. C'est en fait possible en utilisant ce que l'on appelle des preuves de fraude. Ce sont des messages succincts qui montrent qu'un corps de bloc particulier inclut une transaction qui est invalide. Tout nœud complet peut produire une telle preuve de fraude, et le client léger n'a donc pas à faire confiance à ce qu'un nœud complet particulier soit honnête. Ils doivent simplement s'assurer qu'ils sont bien connectés à un réseau de rumeurs qui garantit que s'il y a une preuve de fraude disponible pour un en-tête de bloc, ils la recevront.

Cependant, il y a un problème avec ce système : que se passe-t-il si un producteur de blocs ne révèle pas l'ensemble des données derrière un bloc ? Dans ce cas, les nœuds complets rejetteront évidemment le bloc car à leurs yeux, ce n'est même pas un bloc s'il ne s'accompagne pas du corps du bloc. Cependant, les clients légers peuvent se voir présenter la chaîne d'en-têtes et ne peuvent pas remarquer que les données manquent. En même temps, les nœuds complets ne peuvent pas produire de preuves de fraude, car ils manqueraient des données nécessaires pour créer des preuves de fraude.

Pour contrer cela, nous avons besoin d'un mécanisme permettant aux clients légers de vérifier la disponibilité des données. Cela garantirait qu'un producteur de blocs cachant des données ne puisse pas s'en sortir en convaincant un client léger du contraire. Cela obligerait également le producteur de blocs à révéler des parties des données, permettant à l'ensemble du réseau d'avoir accès à l'ensemble du bloc de manière collaborative.

Plongeons un peu plus profondément dans le problème avec l'aide d'un exemple. Supposons que le producteur de bloc Alice construise un bloc B avec les transactions tx1, tx2, …, txn. Supposons que tx1 soit une transaction malveillante. Si tx1 est diffusé, n'importe quel nœud complet peut vérifier qu'il est malveillant et l'envoyer à un client léger sous forme de preuve de fraude qui saurait immédiatement que le bloc est inacceptable. Cependant, si Alice veut cacher tx1, elle révèle l'en-tête et toutes les données transactionnelles sauf tx1. Les nœuds complets ne peuvent pas vérifier la correction de tx1.

On pourrait penser qu'une solution simple est que tous les clients légers échantillonnent simplement les transactions au hasard, et s'ils trouvent que leurs échantillons sont disponibles, ils peuvent être sûrs que le bloc est disponible. Laissez les nœuds légers interroger une transaction, uniformément au hasard. La probabilité que le client léger interroge tx1 est de 1/n. Ainsi, avec une probabilité écrasante, Alice est capable de tromper les clients légers pour qu'ils acceptent une transaction malveillante. En d'autres termes, la plupart des clients légers seront trompés. En raison de la nature non attribuable, les nœuds complets ne peuvent pas prouver de quelque manière que ce soit que tx1 n'est pas disponible. Malheureusement, augmenter le nombre d'échantillons ne résout pas vraiment ce problème.

Alors, que faisons-nous à ce sujet?

La solution à ce problème réside dans l'introduction de redondance dans un bloc. Il existe un ensemble riche de littérature sur la théorie du codage en général, et le codage d'effacement en particulier, qui peut nous aider avec ce problème.

En un mot, le codage d'effacement nous permet d'étendre n'importe quels n fragments de données en 2n fragments de données de telle manière que n'importe quel n parmi les 2n suffisent pour reconstruire la pièce de données originale (les paramètres sont ajustables, mais ici nous le considérons pour simplifier).

Si nous forçons le producteur de blocs à coder par effacement les transactions tx1, tx2, …, txn, alors, pour cacher une seule transaction, il faudrait cacher n+1 chunks de données car n'importe quel n est suffisant pour reconstruire l'ensemble des transactions. Dans ce cas, un nombre constant de requêtes donne au client léger une très grande confiance que les données sous-jacentes sont effectivement disponibles.

Woah, alors c'est ça?

Non. Bien que ce simple tour rende plus difficile la tâche de dissimulation, il est toujours possible que le producteur de blocs effectue délibérément le codage d'effacement de manière incorrecte. Cependant, un nœud complet peut vérifier si ce codage d'effacement a été correctement effectué et, si ce n'est pas le cas, il peut le prouver à un client léger. Il s'agit d'un autre type de preuve de fraude, tout comme dans le cas des transactions malveillantes ci-dessus. Il est intéressant de noter qu'il doit y avoir un voisin de nœud complet honnête unique d'un client léger pour être certain que si le bloc est malveillant, alors il recevra une preuve de fraude. Cela garantit que le client léger a accès à une chaîne sans transaction malveillante avec une probabilité très élevée.

Mais il y a un hic. Si cela est fait de manière naïve, la taille de certaines preuves de fraude peut être de l'ordre de la taille du bloc lui-même. L'hypothèse de ressource que nous avions sur le client léger nous empêche d'utiliser un tel design. Des améliorations ont été apportées à cet égard en utilisant des techniques de codage d'effacement multidimensionnelles qui réduisent la taille des preuves de fraude au détriment de la taille de l'engagement. Pour des raisons de concision, nous ne couvrons pas ces aspects, mais ce papiera une analyse détaillée de celle-ci.

Le problème avec les solutions basées sur la preuve de fraude est que les clients légers ne sont jamais complètement sûrs de tout bloc pour lequel ils n'ont pas encore reçu de preuve de fraude. De plus, ils font continuellement confiance à leurs pairs de nœuds complets pour être honnêtes. Les nœuds honnêtes ont également besoin d'être incités à continuer à auditer en permanence les blocs.

Nous avons concentré notre attention sur des systèmes garantissant que si le codage de bloc est invalide, les nœuds complets peuvent le détecter et fournir la preuve aux clients légers pour les convaincre de mauvaise conduite. Cependant, dans la section suivante, nous examinerons les codages de blocs qui garantissent que seuls les codages valides peuvent être engagés dans la chaîne. Cela élimine le besoin de preuves de fraude démontrant des erreurs de codage. Ces solutions basées sur les preuves de validité permettent aux applications d'utiliser le système sans attendre ces types de preuves de fraude des nœuds complets.

Alors comment fonctionnent ces solutions?

Récemment, les engagements polynomiaux ont suscité un intérêt renouvelé de la part de l'espace blockchain. Ces engagements polynomiaux, en particulier le engagements KZG/Kate de taille constante aux polynômes, peut être utilisé pour concevoir un schéma DA soigné sans avoir besoin de preuves de fraude. En bref, les engagements KZG nous permettent de nous engager à un polynôme en utilisant un seul élément de groupe de courbe elliptique. De plus, le schéma nous permet de prouver qu'à un certain point i le polynôme φ s'évalue en φ(i) en utilisant un témoin de taille constante. Le schéma d'engagement est computationnellement contraignant et est également homomorphe, ce qui nous permet d'éviter élégamment les preuves de fraude.

Nous forçons le producteur de blocs à prendre les données transactionnelles originales et à les organiser dans une matrice 2D de taille n x m. Il utilise l'interpolation polynomiale pour étendre chaque colonne de taille n en colonnes de taille 2n. Chaque ligne de cette matrice étendue génère un engagement polynomiale et envoie ces engagements comme partie de l'en-tête de bloc. Une représentation schématique du bloc est donnée ci-dessous.

Les clients légers interrogent n'importe quelle cellule de cette matrice étendue pour obtenir le témoin qui lui permet de le vérifier immédiatement par rapport à l'en-tête de bloc. Les preuves d'appartenance de taille constante rendent l'échantillonnage extrêmement efficace. La nature homomorphique de l'engagement garantit que la preuve ne vérifie que si le bloc est construit correctement et l'interpolation polynomiale garantit qu'un nombre constant d'échantillons réussis signifie que les données sont disponibles avec une très grande probabilité.

Une représentation schématique du bloc

Les détails plus fins du schéma ainsi que les optimisations supplémentaires et les estimations de coûts dépassent le cadre de cet article. Cependant, nous tenons à souligner que bien que nous discutions ici d'un schéma 2D, des garanties similaires peuvent être fournies avec un schéma 1D également, qui a une taille d'en-tête plus petite au prix d'une moindre parallélisme et d'une efficacité d'échantillonnage du client léger. Nous approfondirons la question dans des articles ultérieurs.

Quelles sont les autres alternatives et qu'est-ce qui suit?

Le code d'effacement de dimension supérieure et les engagements KZG ne sont pas les seules façons d'aborder le problème de la DA. Il existe d'autres façons que nous avons omis ici comme Arbres de Merkle codés, Arbre d'entrelacement codé, VEND, et les approches basées sur STARK, mais chacune a ses mérites et ses défauts.

Chez Avail, nous avons travaillé sur une solution de disponibilité des données en utilisant les engagements de KZG. Dans les prochains articles, nous aborderons les détails de la mise en œuvre, la façon dont vous pouvez l’utiliser aujourd’hui et la façon dont nous visons à transformer l’espace problématique de l’AD. Pour plus d’informations sur Avail, suivez-nous sur Twitteret rejoignez notreServeur Discord.

Avertissement：

1. Cet article est repris de [GateÉquipe Avail]. Tous les droits d'auteur appartiennent à l'auteur original [Équipe Avail]. S’il y a des objections à cette réimpression, veuillez communiquer avec le [Gate Learn] équipe, et ils s'en occuperont rapidement.

2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.

3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.