Depuis sa sortie l'année dernière, l'OP Stack a gagné en popularité auprès des développeurs de rollup. Il est adopté par les développeurs qui créent de nouveaux rollups et par les fournisseurs d'infrastructure modulaire comme Caldera et Conduit, permettant aux développeurs de créer rapidement leurs propres rollups.
Comme indiqué dans l'annonce de l'année dernière, la modularité est un aspect fondamental de la vision OP Stack :
Chaque couche de la pile OP est décrite par une API bien définie, peuplée de modules au niveau de cette couche. [...] Vous voulez échanger Ethereum contre Celestia comme couche de disponibilité des données ? certainement! Vous voulez exécuter Bitcoin comme couche d'exécution ? pourquoi pas!
La mise à niveau rapide de Bedrock d'Optimism modularisera la couche d'exécution et le système de preuve d'OP Stack, permettant la compatibilité avec les futures preuves de fraude et de validité.
Inspiré par cela, Celestia Labs s'est concentré sur l'amélioration de la modularité de la pile OP. Donc, aujourd'hui, nous sommes ravis d'annoncer la version bêta de l'interface de disponibilité des données modulaires (DA) d'OP Stack, le premier OP Stack Mod d'OP Labs à se concentrer sur les commentaires des développeurs. Cette interface permet aux développeurs de définir des couches DA et d'hériter de la sécurité de n'importe quelle blockchain qu'ils aiment, que ce soit Ethereum, Celestia ou Bitcoin.
Les développeurs peuvent commencer à expérimenter aujourd'hui avec une version de la pile OP qui utilise Celestia pour DA et "s'installe" sur Ethereum. Caldera publiera bientôt le réseau de test Taro, qui permet aux développeurs et aux utilisateurs d'essayer le premier réseau de test public d'OP Stack à l'aide de Modular DA.
La couche de disponibilité des données est la base de l'architecture de cumul, garantissant la disponibilité des données requises pour vérifier de manière indépendante la chaîne de cumul. Ci-dessous, nous explorons les bases de la disponibilité des données dans la pile OP et comment nous la modularisons pour publier et récupérer des données de L1 via des interfaces DA bien définies.
Disponibilité des données dans la pile OP : aujourd'hui
Comment OP Stack gère-t-il la disponibilité actuelle des données ? Pour nos besoins, nous nous sommes penchés sur deux composants de base, le nœud Rollup et le batcher, comme décrit ci-dessous.
Pour une meilleure compréhension de la façon dont le reste de la pile OP fonctionne dans les coulisses, consultez la documentation Optimism.
Nœud de cumul
Les nœuds de cumul sont les composants responsables de la création de la chaîne L2 correcte à partir des blocs L1 (et de leurs reçus associés). Un nœud cumulatif récupère les blocs L1, filtre les transactions de données (généralement sous la forme de données d'appel de transaction) et dérive la chaîne L2 correcte à partir de ces données.
### Batcher : émetteur de lots
Les soumissionnaires par lots, également connus sous le nom de processeurs par lots, sont des entités qui soumettent les données du trieur L2 à L1 pour une utilisation par les validateurs. Le nœud cumulatif et le batcher fonctionnent tous deux dans une boucle de sorte que les données de bloc L2 nouvellement soumises par le batcher sont extraites de L1 par le nœud cumulatif et utilisées pour dériver le bloc L2 suivant.
Chaque transaction soumise par un programme batch contient des données d'appel, qui sont des données de séquenceur L2 divisées en octets appelés trames, le niveau d'abstraction le plus bas pour les données dans Optimism.
Interface DA modulaire pour OP Stack
Lors de la création de l'interface DA modulaire pour OP Stack, notre objectif était simple : permettre aux développeurs de rollup de spécifier n'importe quelle blockchain comme couche de disponibilité des données, que ce soit Ethereum, Celestia ou Bitcoin. En l'absence d'une telle interface, chaque intégration d'une nouvelle couche DA peut obliger les développeurs à implémenter et à maintenir une branche distincte de la pile OP.
L'OP Stack inclut déjà des abstractions spécifiant L1;Chain et L;2C;hain dans la base de code, nous permettant de modéliser une nouvelle interface indépendante de la blockchain pour les chaînes de disponibilité des données, que nous appelons DAChain.
En utilisant l'interface définie ci-dessous, les développeurs peuvent implémenter DAChain pour lire et écrire des données à partir de n'importe quelle blockchain sous-jacente ou même d'un backend centralisé comme S;3.
Phase d'écriture
L'exemple suivant d'écriture d'une implémentation Celestia de l'interface décrit l'intégration avec le programme batch :
SimpleTxManager.send, la fonction responsable de la création et de l'envoi de la transaction réelle, est modifiée pour appeler WriteFrame afin d'écrire la trame à Celestia et de renvoyer une référence.
La référence est ensuite soumise en tant que données d'appel à l'adresse de la boîte de réception du lot à la place des données de trame habituelles.
Phase de lecture
Voici un aperçu de l'implémentation Celestia de l'interface qui s'intègre au nœud rollup :
DataFromEVMTransactions est la fonction chargée de renvoyer les données de trame à partir de la liste des transactions. Il est modifié pour utiliser la référence de trame extraite des données d'appel de la boîte de réception du lot pour récupérer réellement la trame et l'ajouter aux données de retour.
Notez que l'appel à NamespacedData renvoie un tableau de tranches d'octets de tous les blobs soumis à la hauteur de bloc donnée, nous renvoyons donc uniquement le TxIndex qui nous intéresse.
Intégrer Celestia en tant que couche DA
Schéma montrant l'architecture de la pile OP par rapport à l'intégration de la pile Celestia + OP.
Avec quelques modifications mineures du nœud Rollup et du programme batch, nous pouvons faire en sorte que la pile OP utilise Celestia pour DA.
Cela signifie que toutes les données nécessaires pour bifurquer la chaîne L2 peuvent être mises à disposition sur Celestia en tant que données blob locales au lieu d'être publiées sur Ethereum, bien qu'une petite référence de trame de taille fixe soit toujours publiée sur Ethereum en tant que données d'appel de programme batch. La référence de trame est utilisée pour rechercher la trame correspondante sur Celestia en utilisant le nœud ;celestia-node; light.
Comment intégrer et exploiter ?
Phase d'écriture
Comme mentionné ci-dessus, le programme batch soumet les données du séquenceur L2 sous forme d'octets appelés trames à l'adresse de contrat de la boîte de réception batch sur Ethereum L1.
Nous préservons les transactions batcher et calldata pour garantir l'ordre des trames, mais nous remplaçons les trames dans calldata par des références de trame de taille fixe. Qu'est-ce qu'un référentiel ? Il s'agit d'une référence à une transaction de données Celestia qui a réussi à inclure des données de trame dans Celestia.
Pour ce faire, nous intégrons un nœud léger de nœud céleste dans le service batch. Chaque fois qu'un nouveau lot attend d'être soumis, nous soumettons d'abord la transaction de données à Celestia à l'aide de nœuds légers, puis nous soumettons uniquement les références de trame dans batchercalldata.
Phase de lecture
Dans la phase de lecture, nous faisons l'inverse, c'est-à-dire que nous utilisons la référence de trame dans les données d'appel de la transaction par lots pour l'analyser et récupérer les données de trame réelles correspondantes de Celestia. De même, nous intégrons un nœud léger céleste dans le nœud cumulatif pour interroger ses transactions.
Lors de la bifurcation de la chaîne L2, les nœuds cumulatifs lisent désormais de manière transparente les données des nœuds légers et peuvent continuer à construire de nouveaux blocs. Les nœuds légers ne téléchargent que les données soumises par le cumul, au lieu de télécharger toute la chaîne comme Ethereum.
Perspectives
Les preuves de fraude sont un élément clé de la feuille de route post-Optimisme de Bedrock, et nous souhaitons explorer la mise à niveau de notre intégration OP Stack x Celestia pour utiliser des preuves de fraude sur le réseau principal Ethereum.
Pour ce faire, nous pouvons tirer parti du Quantum Gravity Bridge (QGB), qui relaie les preuves DA inter-chaînes à Ethereum pour permettre la vérification en chaîne que les données agrégées sont disponibles sur Celestia afin que les données agrégées puissent être utilisées dans les preuves de fraude. Cela permettra à OP Stack Rollup de tirer directement parti de la garantie DA fournie par Celestia.
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.
Analyse de la disponibilité des données modulaires pour les piles OP dans Celestia
Auteur original : Javed Khan, blog Celestia
Compilation du texte original : Lu Jue Lin
Introduction
Depuis sa sortie l'année dernière, l'OP Stack a gagné en popularité auprès des développeurs de rollup. Il est adopté par les développeurs qui créent de nouveaux rollups et par les fournisseurs d'infrastructure modulaire comme Caldera et Conduit, permettant aux développeurs de créer rapidement leurs propres rollups.
Comme indiqué dans l'annonce de l'année dernière, la modularité est un aspect fondamental de la vision OP Stack :
La mise à niveau rapide de Bedrock d'Optimism modularisera la couche d'exécution et le système de preuve d'OP Stack, permettant la compatibilité avec les futures preuves de fraude et de validité.
Inspiré par cela, Celestia Labs s'est concentré sur l'amélioration de la modularité de la pile OP. Donc, aujourd'hui, nous sommes ravis d'annoncer la version bêta de l'interface de disponibilité des données modulaires (DA) d'OP Stack, le premier OP Stack Mod d'OP Labs à se concentrer sur les commentaires des développeurs. Cette interface permet aux développeurs de définir des couches DA et d'hériter de la sécurité de n'importe quelle blockchain qu'ils aiment, que ce soit Ethereum, Celestia ou Bitcoin.
Les développeurs peuvent commencer à expérimenter aujourd'hui avec une version de la pile OP qui utilise Celestia pour DA et "s'installe" sur Ethereum. Caldera publiera bientôt le réseau de test Taro, qui permet aux développeurs et aux utilisateurs d'essayer le premier réseau de test public d'OP Stack à l'aide de Modular DA.
La couche de disponibilité des données est la base de l'architecture de cumul, garantissant la disponibilité des données requises pour vérifier de manière indépendante la chaîne de cumul. Ci-dessous, nous explorons les bases de la disponibilité des données dans la pile OP et comment nous la modularisons pour publier et récupérer des données de L1 via des interfaces DA bien définies.
Disponibilité des données dans la pile OP : aujourd'hui
Comment OP Stack gère-t-il la disponibilité actuelle des données ? Pour nos besoins, nous nous sommes penchés sur deux composants de base, le nœud Rollup et le batcher, comme décrit ci-dessous.
Pour une meilleure compréhension de la façon dont le reste de la pile OP fonctionne dans les coulisses, consultez la documentation Optimism.
Nœud de cumul
Les nœuds de cumul sont les composants responsables de la création de la chaîne L2 correcte à partir des blocs L1 (et de leurs reçus associés). Un nœud cumulatif récupère les blocs L1, filtre les transactions de données (généralement sous la forme de données d'appel de transaction) et dérive la chaîne L2 correcte à partir de ces données.
### Batcher : émetteur de lots
Les soumissionnaires par lots, également connus sous le nom de processeurs par lots, sont des entités qui soumettent les données du trieur L2 à L1 pour une utilisation par les validateurs. Le nœud cumulatif et le batcher fonctionnent tous deux dans une boucle de sorte que les données de bloc L2 nouvellement soumises par le batcher sont extraites de L1 par le nœud cumulatif et utilisées pour dériver le bloc L2 suivant.
Chaque transaction soumise par un programme batch contient des données d'appel, qui sont des données de séquenceur L2 divisées en octets appelés trames, le niveau d'abstraction le plus bas pour les données dans Optimism.
Interface DA modulaire pour OP Stack
Lors de la création de l'interface DA modulaire pour OP Stack, notre objectif était simple : permettre aux développeurs de rollup de spécifier n'importe quelle blockchain comme couche de disponibilité des données, que ce soit Ethereum, Celestia ou Bitcoin. En l'absence d'une telle interface, chaque intégration d'une nouvelle couche DA peut obliger les développeurs à implémenter et à maintenir une branche distincte de la pile OP.
L'OP Stack inclut déjà des abstractions spécifiant L1;Chain et L;2C;hain dans la base de code, nous permettant de modéliser une nouvelle interface indépendante de la blockchain pour les chaînes de disponibilité des données, que nous appelons DAChain.
En utilisant l'interface définie ci-dessous, les développeurs peuvent implémenter DAChain pour lire et écrire des données à partir de n'importe quelle blockchain sous-jacente ou même d'un backend centralisé comme S;3.
Phase d'écriture
L'exemple suivant d'écriture d'une implémentation Celestia de l'interface décrit l'intégration avec le programme batch :
SimpleTxManager.send, la fonction responsable de la création et de l'envoi de la transaction réelle, est modifiée pour appeler WriteFrame afin d'écrire la trame à Celestia et de renvoyer une référence.
La référence est ensuite soumise en tant que données d'appel à l'adresse de la boîte de réception du lot à la place des données de trame habituelles.
Phase de lecture
Voici un aperçu de l'implémentation Celestia de l'interface qui s'intègre au nœud rollup :
DataFromEVMTransactions est la fonction chargée de renvoyer les données de trame à partir de la liste des transactions. Il est modifié pour utiliser la référence de trame extraite des données d'appel de la boîte de réception du lot pour récupérer réellement la trame et l'ajouter aux données de retour.
Notez que l'appel à NamespacedData renvoie un tableau de tranches d'octets de tous les blobs soumis à la hauteur de bloc donnée, nous renvoyons donc uniquement le TxIndex qui nous intéresse.
Intégrer Celestia en tant que couche DA
Schéma montrant l'architecture de la pile OP par rapport à l'intégration de la pile Celestia + OP.
Avec quelques modifications mineures du nœud Rollup et du programme batch, nous pouvons faire en sorte que la pile OP utilise Celestia pour DA.
Cela signifie que toutes les données nécessaires pour bifurquer la chaîne L2 peuvent être mises à disposition sur Celestia en tant que données blob locales au lieu d'être publiées sur Ethereum, bien qu'une petite référence de trame de taille fixe soit toujours publiée sur Ethereum en tant que données d'appel de programme batch. La référence de trame est utilisée pour rechercher la trame correspondante sur Celestia en utilisant le nœud ;celestia-node; light.
Comment intégrer et exploiter ?
Phase d'écriture
Comme mentionné ci-dessus, le programme batch soumet les données du séquenceur L2 sous forme d'octets appelés trames à l'adresse de contrat de la boîte de réception batch sur Ethereum L1.
Nous préservons les transactions batcher et calldata pour garantir l'ordre des trames, mais nous remplaçons les trames dans calldata par des références de trame de taille fixe. Qu'est-ce qu'un référentiel ? Il s'agit d'une référence à une transaction de données Celestia qui a réussi à inclure des données de trame dans Celestia.
Pour ce faire, nous intégrons un nœud léger de nœud céleste dans le service batch. Chaque fois qu'un nouveau lot attend d'être soumis, nous soumettons d'abord la transaction de données à Celestia à l'aide de nœuds légers, puis nous soumettons uniquement les références de trame dans batchercalldata.
Phase de lecture
Dans la phase de lecture, nous faisons l'inverse, c'est-à-dire que nous utilisons la référence de trame dans les données d'appel de la transaction par lots pour l'analyser et récupérer les données de trame réelles correspondantes de Celestia. De même, nous intégrons un nœud léger céleste dans le nœud cumulatif pour interroger ses transactions.
Lors de la bifurcation de la chaîne L2, les nœuds cumulatifs lisent désormais de manière transparente les données des nœuds légers et peuvent continuer à construire de nouveaux blocs. Les nœuds légers ne téléchargent que les données soumises par le cumul, au lieu de télécharger toute la chaîne comme Ethereum.
Perspectives
Les preuves de fraude sont un élément clé de la feuille de route post-Optimisme de Bedrock, et nous souhaitons explorer la mise à niveau de notre intégration OP Stack x Celestia pour utiliser des preuves de fraude sur le réseau principal Ethereum.
Pour ce faire, nous pouvons tirer parti du Quantum Gravity Bridge (QGB), qui relaie les preuves DA inter-chaînes à Ethereum pour permettre la vérification en chaîne que les données agrégées sont disponibles sur Celestia afin que les données agrégées puissent être utilisées dans les preuves de fraude. Cela permettra à OP Stack Rollup de tirer directement parti de la garantie DA fournie par Celestia.