Titre original : "Bedrock Explainer"
Écrit par : Officiel de l'Optimisme
Compilé par : Frank, Foresight News
Bedrock est le nom de la toute première version officielle d'OP Stack, un ensemble de composants modulaires gratuits et open source conçus pour alimenter la croissance d'Optimism.
Résumé des améliorations
Bedrock améliore son prédécesseur, notamment :
Réduisez les frais de transaction en utilisant la compression optimisée des transactions par lots et Ethereum comme couche de disponibilité des données ;
Latence réduite dans le regroupement des transactions L1 en cumuls grâce à une meilleure gestion des réorganisations L1 ;
Activer des systèmes de preuve modulaires grâce à la réutilisation du code ;
Améliorez les performances des nœuds en éliminant la dette de conception.
frais inférieurs
Bedrock utilise une stratégie de compression de données optimisée pour minimiser les coûts de données. Nous évaluons actuellement l'impact de ce changement, mais nous prévoyons qu'il réduira considérablement les frais.
Bedrock élimine également tous les coûts de gaz associés à l'exécution de l'EVM lors de la soumission des données à L1, ce qui réduira les coûts de 10 % supplémentaires par rapport aux versions précédentes du protocole.
Délai de crédit de dépôt plus court
Bedrock a introduit la prise en charge des réorganisations L1 dans le logiciel du nœud, ce qui réduit considérablement le temps que les utilisateurs doivent attendre pour que les dépôts soient crédités.
Les versions antérieures du protocole pouvaient prendre jusqu'à 10 minutes pour que les dépôts soient confirmés, alors qu'avec Bedrock, nous nous attendons à ce que les dépôts soient confirmés dans les 3 minutes.
Preuve modulaire améliorée
Bedrock extrait le système de preuve de la pile OP afin que le cumul puisse utiliser des preuves d'échec ou des preuves de validité (telles que zk-SNARK) pour prouver l'exécution correcte après la saisie sur le cumul. Cette abstraction permettra également d'utiliser Cannon pour prouver le système de preuve. défaillance du système.
Performances des nœuds améliorées
Les performances du logiciel de nœud sont considérablement améliorées par l'exécution de plusieurs transactions dans un seul « bloc » de cumul au lieu du modèle « une transaction par bloc » des versions précédentes.
Cela permet de répartir le coût des mises à jour de Merkle Trie sur plusieurs transactions, ce qui, avec les volumes de transactions actuels, réduit la croissance des données d'état d'environ 15 Go par an.
Les performances des nœuds ont également été améliorées en éliminant la dette technique des versions précédentes du protocole, notamment en éliminant le besoin d'un nœud de « couche de transport de données » distinct pour indexer L1 et en mettant à jour le logiciel du nœud pour interroger efficacement les transactions à partir des données L1.
Équivalence Ethereum améliorée
Bedrock a été conçu dès le début pour être aussi « cohérent » que possible avec Ethereum, et de nombreux écarts par rapport à Ethereum dans les versions précédentes du protocole ont été éliminés, notamment :
Modèle « une transaction par bloc » ;
Personnalisez l'opcode pour obtenir des informations sur le bloc L1 ;
Champs de frais L1/L2 séparés dans l'API JSON-RPC ;
Représentation ERC20 personnalisée des soldes ETH.
Bedrock a également ajouté la prise en charge d'EIP-1559, de la réorganisation de la blockchain et d'autres fonctionnalités Ethereum présentes sur L1.
Principes de conception
Bedrock est conçu pour être modulaire et évolutif tout en réutilisant le code Ethereum existant et en visant à atteindre une équivalence 100 % Ethereum dans la mesure du possible.
Modulaire
En utilisant des interfaces et des schémas de versionnement bien définis, Bedrock peut facilement remplacer différents composants de la pile OP et ajouter de nouvelles fonctionnalités.
Cela lui permet de s’adapter au développement futur de l’écosystème Ethereum avec une architecture flexible, telle que :
Le nœud de cumul est séparé du client d'exécution ;
Conception modulaire infaillible.
réutilisation du code
Bedrock utilise l'architecture et l'infrastructure Ethereum existantes dans la mesure du possible. Cette approche permet à OP Stack d'hériter des avantages en matière de sécurité et d'effet Lindy de la base de code testée au combat utilisée par le réseau principal Ethereum.
Vous en trouverez des exemples tout au long de la conception, notamment :
client d'exécution peu modifié ;
Contrats EVM au lieu du code client précompilé.
Équivalence Ethereum
Bedrock est conçu pour être compatible au maximum avec les expériences de développement Ethereum existantes, mais il existe quelques exceptions en raison de différences fondamentales entre L1 et rollup : différents modèles de frais, des temps de blocage plus rapides (2 secondes contre 12 secondes) et des types de transactions spéciales, y compris les transactions de dépôt L1.
Ces exceptions incluent :
Vérification des défauts des clients d'exécution Ethereum conçue pour prouver des modifications minimes ;
Ethereum effectue la réutilisation du code côté client pour une utilisation par les nœuds et les ordres du réseau L2.
protocole
Les rollups sont construits sur la disponibilité des données (généralement une blockchain L1 comme Ethereum). Dans la configuration la plus courante, le protocole de rollup dérive une « chaîne canonique L2 » à partir de deux sources principales d'informations :
Les données de transaction sont publiées sur L1 par le séquenceur ;
Les transactions de dépôt sont soumises par les comptes et les contrats intelligents au contrat relais sur L1.
Voici les éléments de base de l’accord :
En interagissant directement avec le contrat intelligent sur L1, le dépôt est écrit dans la « chaîne standard L2 » ;
Les retraits sont écrits dans la « chaîne canonique L2 » et déclenchent implicitement des interactions avec des contrats intelligents et des comptes sur L1 ;
Les lots sont des écritures de données correspondant aux lots lors du cumul ;
La dérivation de blocs consiste à interpréter les lectures de données sur L1 pour comprendre la « chaîne canonique L2 » ;
Le système de preuve définit la finalité des racines de sortie publiées sur L1 pour qu'elles puissent être exécutées (par exemple effectuer des retraits).
dépôt
Le dépôt est une transaction sur L1 et sera inclus dans le rollup. Par définition, les dépôts sont garantis d'être inclus dans la « chaîne canonique L2 » afin d'empêcher la censure ou le contrôle de la L2.
Tout message délivré depuis L1
Les transactions de dépôt sont des transactions de cumul effectuées dans le cadre d'un dépôt. Avec Bedrock, les dépôts sont des transactions Ethereum entièrement universelles, telles que les comptes sur Ethereum ou les contrats intelligents peuvent créer des contrats de « dépôt ».
Bedrock définit un contrat de dépôt disponible sur L1 : il s'agit d'un contrat intelligent avec lequel les comptes L1 et les contrats intelligents peuvent interagir pour écrire sur L2. Les transactions de dépôt sur L2 sont dérivées des transactions émises par ce contrat de dépôt et incluent des paramètres attendus tels que de, à et données.
Veuillez consulter la section Spécifications de l'accord de contrat de dépôt pour plus de détails.
Achetez du gaz L2 garanti sur L1
Bedrock a également clarifié le mécanisme de combustion du gaz et le marché des frais de dépôt. Le gaz dépensé sur L2 par les transactions de dépôt est acheté sur L1 via la combustion de gaz.
Ce gaz est spécifiquement acheté sur le marché des frais, et il existe un plafond strict sur le montant total de gaz fourni pour toutes les transactions de dépôt dans un seul bloc L1. Ce mécanisme est utilisé pour empêcher les attaques par déni de service (DoS) qui pourraient se produire. Lors de l'écriture de transactions de L1 vers L2, car ces transactions consomment beaucoup de Gas sur L2, mais sont très bon marché sur L1.
Le gaz fourni pour les opérations de dépôt est parfois appelé « Gaz Garanti ». Le gaz garanti est unique dans le sens où il est payé en brûlant du gaz sur L1 et n'est donc pas remboursable.
Et la quantité totale de gaz L1 devant être brûlée par unité de gaz L2 garanti dépend du prix du gaz L2 indiqué par le mécanisme de facturation de type EIP-1559. De plus, les utilisateurs reçoivent une allocation de gaz dynamique basée sur la quantité de gaz L1 dépensée pour calculer les mises à jour du mécanisme de frais.
Pour une explication plus approfondie, veuillez lire les spécifications du protocole dans la section dépôt.
Retirer de l'argent
Les retraits sont des transactions multicouches initiées sur L2 et complétées par des transactions exécutées sur L1. Il convient de noter que les comptes L2 peuvent utiliser des retraits pour appeler des contrats L1 ou transférer des ETH des comptes L2 vers des comptes L1.
Le retrait est initié en appelant le contrat pré-déployé Message Passer sur L2, qui enregistre les propriétés importantes du message dans son stockage, puis le retrait est complété sur L1 en appelant le contrat OptimismPortal pour prouver l'inclusion de ce message de retrait.
De cette manière, les retraits et les dépôts sont différents : les transactions de retrait doivent être effectuées à l'aide de contrats intelligents sur L1, plutôt que de s'appuyer sur des informations dérivées de blocs.
Processus de retrait en deux étapes
Les erreurs de validation de la preuve de retrait ont été à l’origine de nombreux piratages de ponts inter-chaînes au cours des dernières années. La version Bedrock introduit une étape supplémentaire dans le processus de retrait des versions précédentes conçue pour fournir une défense supplémentaire contre ce type d'erreurs.
Dans le processus de retrait en deux étapes, chaque retrait doit présenter la preuve Merkle correspondant au retrait 7 jours avant la sortie finale. Ce nouveau mécanisme de sécurité donne aux outils de surveillance 7 jours complets pour rechercher et détecter l'invalidité du certificat de retrait.
Si le certificat de retrait s'avère invalide pendant cette période, des réparations de contrats intelligents peuvent être déployées avant que les fonds ne soient perdus, ce qui réduit considérablement le risque de compromission du pont entre chaînes.
Veuillez consulter la section Spécifications de l'accord de retrait pour plus de détails.
Lots
Dans Bedrock, un format filaire est défini pour le message passant entre L1 et L2 (c'est-à-dire que L2 dérive des blocs de L1, L2 écrit les transactions sur L1), ce format filaire est conçu pour réduire le coût d'écriture sur L1 et la complexité logicielle au minimum.
Optimiser la compression des données
Pour optimiser la compression des données, les listes de transactions L2 (appelées lots de séquenceur) sont organisées en groupes d'objets (appelés canaux). La taille maximale de chaque canal peut être définie dans un paramètre configurable, qui sera initialement fixé à 9,5 M. devrait être compressé à l’aide de la fonction de compression et soumis à L1.
soumission parallèle par lots
Pour paralléliser les messages provenant de séquenceurs soumettant des données de canal compressées à L1, les canaux sont ensuite décomposés en « trames de canal », qui sont des morceaux de données de canal compressées pouvant tenir dans une seule transaction L1.
En supposant que les « trames de canal » soient indépendantes les unes des autres et que l'ordre soit connu, les transactions Ethereum envoyées à L1 par le séquenceur peuvent être envoyées en parallèle, minimisant ainsi la complexité du logiciel du séquenceur et permettant de remplir tout l'espace de données disponible sur L1.
Minimiser le gaz Ethereum
Bedrock supprime tout le gaz d'exécution utilisé par le système L1 pour soumettre les données de canal à L1 dans des transactions appelées « transactions batcher ». Toute logique de vérification qui se produisait auparavant sur les contrats intelligents L1 a été déplacée vers la logique de dérivation de bloc. Au lieu de cela, les « transactions par lots » sont envoyées à une seule adresse EOA sur Ethereum, appelée « adresse de boîte de réception par lots ».
Les lots sont toujours soumis à des contrôles de validité (c'est-à-dire qu'ils doivent être codés correctement), tout comme les transactions individuelles au sein du lot (par exemple, les signatures doivent être valides), les lots invalides et les transactions individuelles invalides au sein de lots valides sont considérés comme rejetés et sans rapport avec le système.
Remarque : Ethereum sera bientôt mis à niveau vers une nouvelle version incluant EIP-4844, qui introduit un marché distinct des frais d'écriture de données et augmente la limite supérieure de la quantité de données que le protocole Ethereum est prêt à stocker. Ce changement devrait encore réduire. le nombre de coûts associés à la publication sur L1.
Pour une explication plus détaillée, lisez la spécification du format de câble.
Fourche à bloc
Dans Bedrock, le protocole est conçu pour garantir que le timing des dépôts sur L1 est lié à la dérivation en bloc de la « chaîne canonique L2 ». Il s'agit d'une pure fonction d'écriture de données sur L1 via les propriétés du séquenceur, du dépôt et du bloc L1.
Pour y parvenir, le protocole définit des stratégies pour garantir les dépôts, gérer les horodatages L1 et L2 et gérer les fenêtres de commande dans le canal pour garantir une commande correcte.
Dépôt garanti sur compte
Les objectifs du protocole de dérivation de blocs sont définis comme suit :
Après chaque «intervalle de bloc L2», il doit y avoir un bloc L2 et l'horodatage du bloc L2 est synchronisé avec l'horodatage du bloc L1 (c'est-à-dire garantir que les dépôts sont inclus dans l'ordre chronologique logique).
Dans Bedrock, le concept d'« époque de séquençage » est introduit : il s'agit de la plage de blocs L2 dérivée d'une série de blocs L1. Chaque époque est identifiée par un « numéro d'époque », qui est égal au numéro dans la fenêtre de tri. Le numéro de séquence du premier bloc L1. La taille des époques peut varier, sous réserve de certaines restrictions.
Le canal dérivé par lots traite l'horodatage du bloc L1 associé au « numéro d'époque » comme point d'ancrage pour déterminer l'ordre des transactions sur L2. Le protocole garantit que le premier bloc L2 d'une époque ne sera jamais en retard sur l'horodatage du bloc L1 de l'époque correspondante. Le premier bloc d'une époque doit contenir des dépôts sur L1 pour garantir que le dépôt sera traité.
Notez que dans la version Bedrock, l'intervalle de blocage cible sur L2 est configuré à 2 secondes.
Gestion des horodatages L1 et L2
Bedrock tente de résoudre le problème de la réconciliation des horodatages sur L2 avec les horodatages sur L1 qui existent dans les transactions de dépôt.
Pour ce faire, il autorise une courte fenêtre de temps pour le tri afin d'appliquer librement des horodatages sur les transactions L2 entre les époques.
La fenêtre de séquençage est la séquence de blocs L1 à partir de laquelle les époques peuvent être dérivées. Dans une fenêtre de tri, le premier numéro de bloc L1 N contient les "transactions batcher" de l'époque.
La fenêtre de tri contient des blocs, qui dépendent de la taille de la fenêtre de tri : un paramètre de configuration de niveau de cumul fixe doit être d'au moins 2, son augmentation donnera au séquenceur plus de possibilités de trier les transactions L2 sur les dépôts, l'abaisser pour le séquençage. fenêtre introduite par le serveur pour soumettre des "transactions batcher". Il s’agit d’un compromis entre la création d’opportunités MEV et la complexité croissante des logiciels.
Une constante de protocole appelée « dérive maximale du séquenceur » contrôle l'horodatage maximum qu'un bloc peut avoir au cours de son époque. Avec cette dérive, le séquenceur peut avoir des problèmes temporaires de connexion à L1.
Bloquer le pipeline de fourche
La "chaîne canonique L2" peut être traitée à partir de zéro en commençant à partir de l'état de genèse L2, en réglant le début de la chaîne L2 à la première époque, puis en traitant toutes les fenêtres de tri pour déterminer les lots du séquenceur selon l'ordre simplifié suivant et la séquence correcte pour dépôt de tuyaux :
Preuve d'échec
Une fois que le séquenceur a traité un ou plusieurs blocs L2, les résultats des calculs de transaction exécutés dans ces blocs devront être écrits en L1 pour permettre l'exécution sans confiance des messages L2 à L1, tels que les retraits, etc.
Dans Bedrock, la sortie est hachée sous la forme d'une structure arborescente, minimisant ainsi le coût de preuve de toute donnée capturée par la sortie. Les proposants soumettent périodiquement des racines de sortie à L1 qui servent de racines Merkle pour l'ensemble de la « chaîne canonique L2 ».
Les futures mises à niveau de la pile OP devraient inclure une spécification d'une variante infaillible avec des liaisons pour inciter les proposants à proposer des racines de sortie correctes.
Pour plus de détails, lisez la spécification du protocole dans la section Proposition racine de sortie L2.
mettre en œuvre
Dans Bedrock, la pile OP doit s’appuyer fortement sur la séparation spécifiée par Ethereum des problèmes techniques en reflétant la séparation entre la couche d’exécution et la couche de consensus d’Ethereum.
Bedrock a donc introduit la séparation des clients d'exécution et des nœuds de cumul de la même manière.
Exécuter le client
Les clients d'exécution sont des systèmes que les séquenceurs et d'autres types d'opérateurs de nœuds exécutent pour déterminer l'état de la chaîne canonique L2. Il remplit également d'autres fonctions telles que la gestion des transactions entrantes et des communications peer-to-peer, ainsi que le traitement de l'état du système pour gérer les requêtes dirigées contre lui.
Avec Bedrock, OP Stack vise à réutiliser la propre spécification du client d’exécution d’Ethereum et bon nombre de ses opérations d’exécution. Dans cette version, Bedrock a démontré une modification extrêmement limitée du client Ethereum go-ethereum, avec une différence de moins de 2 000 lignes de code.
Il y a deux raisons fondamentales à cette différence : le traitement des transactions de dépôt et la facturation des frais de transaction.
Traiter les transactions de dépôt
Pour représenter les transactions déposées dans un rollup, un type de transaction supplémentaire est introduit. La mise en œuvre des clients mettant en œuvre ce nouveau type de transaction est basée sur la norme de transaction de type EIP-2718.
Facturer des frais de transaction
Les rollups comportent également essentiellement deux types de frais liés aux transactions :
L’un concerne les frais du séquenceur. Le coût de fonctionnement du séquenceur est calculé à l'aide de la même table de gaz et du même algorithme EIP-1559 qu'Ethereum. Ces frais sont utilisés dans le protocole pour faire fonctionner le séquenceur et fluctuent dans le temps en fonction de la congestion du réseau.
Un autre frais de disponibilité des données. Les coûts de disponibilité des données sont associés à l'écriture de transactions par lots sur L1 et sont destinés à couvrir les frais du séquenceur pour la soumission de transactions par lots sur L1.
Dans Bedrock, la partie disponibilité des données des frais est déterminée sur la base des informations contenues dans le contrat intelligent du système de cumul appelé GasPriceOracle, qui est basé sur les attributs de bloc L1 insérés au début de chaque époque pendant le processus de dérivation du bloc. Est mis à jour.
Bedrock précise que les deux coûts sont ajoutés dans un seul champ lors de l'utilisation de JSON-RPC.
nœud de cumul
Contrairement à Ethereum, Bedrock n’a pas de consensus PoS. En revanche, le consensus d'une « chaîne L2 canonique » est défini par dérivation de blocs. Le client d'exécution d'OP Stack communique avec un nouveau composant qui implémente le block forking appelé nœud de cumul, qui communique avec le client d'exécution en utilisant exactement la même API de moteur qu'Ethereum.
Le nœud de cumul est un composant sans état chargé de dériver l'état du système en lisant les données et les dépôts sur L1. Dans Bedrock, les nœuds de cumul peuvent être utilisés pour séquencer les transactions entrantes des utilisateurs ou d'autres nœuds de cumul, ou pour valider les transactions confirmées publiées sur L1 en s'appuyant uniquement sur L1.
Les différentes utilisations des nœuds de cumul sont résumées ci-dessous :
Vérifier la "chaîne canonique L2"
Le mode le plus simple pour exécuter des nœuds de cumul consiste simplement à suivre la « chaîne canonique L2 ». Dans ce mode, le nœud de cumul n'a pas de pairs et est strictement utilisé pour lire les données de L1 et interpréter les données conformément aux règles du protocole de dérivation de bloc.
L'un des objectifs d'un tel nœud est de vérifier que toutes les racines de sortie partagées par d'autres nœuds ou publiées sur L1 sont correctes conformément à la définition du protocole. De plus, les proposants qui ont l'intention de soumettre des racines de sortie à L1 peuvent eux-mêmes utiliser optimism_outputAtBlock pour générer les racines de sortie dont ils ont besoin et renvoyer le hachage de 32 octets correspondant à la racine de sortie L2.
Pour ce faire, les nœuds doivent uniquement suivre l’en-tête du bloc « finalisé ». Le terme « finalisé » fait référence au consensus Ethereum PoS (c'est-à-dire canonique et presque irréversible), et l'en-tête du bloc L2 « finalisé » est la zone de la « chaîne canonique L2 » dérivée uniquement du bloc L1 « finalisé ». tête.
Participer au réseau L2
La manière la plus courante d'utiliser un nœud de cumul consiste à participer à un réseau d'autres nœuds de cumul, en suivant les processus et l'état L2. Dans ce mode, le nœud de cumul lit et dépose simultanément les données qu'il observe à partir de L1, les interprète en blocs et accepte les transactions entrantes des utilisateurs et des pairs du réseau d'autres nœuds de cumul.
Les nœuds participant au réseau peuvent utiliser les en-têtes de bloc sécurisés et non sécurisés du L2 avec lequel ils se synchronisent.
Les en-têtes de bloc L2 sécurisés représentent des cumuls qui peuvent être construits dans lesquels chaque bloc (y compris les en-têtes) peut être entièrement dérivé de la chaîne de référence L1 avant que L1 ne doive être « finalisé » (c'est-à-dire qu'une réorganisation peut toujours se produire sur L1) ;
Les en-têtes de bloc L2 non sécurisés incluent les blocs non sécurisés qui n'ont pas été dérivés de L1. Ces blocs proviennent soit du fonctionnement du nœud rollup en tant que séquenceur, soit d'une synchronisation non sécurisée avec le séquenceur. Ceci est également appelé le « dernier » en-tête de bloc. En cas de désaccord, choisissez toujours l’en-tête de bloc L2 sécurisé plutôt que l’en-tête de bloc L2 non sécurisé. Lorsqu’un désaccord survient, la partie non sécurisée de la chaîne se réorganise ;
Dans la plupart des cas, pour les applications des utilisateurs finaux, les nœuds de cumul du réseau L2 feront référence à des en-têtes de bloc L2 non sécurisés.
Tri des transactions
La troisième façon d'utiliser les nœuds de cumul consiste à ordonner les transactions. Dans ce mode, les nœuds de cumul créeront de nouveaux blocs au-dessus des en-têtes de bloc L2 non sécurisés. Actuellement, il n’existe qu’un seul séquenceur par réseau OP Stack.
Le séquenceur est également responsable de la publication des lots de transactions sur L1 afin que les autres nœuds du réseau puissent se synchroniser à partir de celui-ci.
Doseur
Le rôle d'un séquenceur est de produire des lots de transactions. À cette fin, les séquenceurs peuvent exécuter des nœuds de cumul et disposer de processus distincts qui exécutent des lots en lisant à partir des nœuds de cumul de confiance sur lesquels ils s'exécutent.
Cela garantit qu'un composant complémentaire de la pile OP, appelé gestionnaire de transactions par lots, lit les données de transaction à partir du nœud de cumul et les interprète en une transaction par lots à écrire sur L1, le composant batcher est responsable de la lecture et de l'exécution par le séquenceur Le nœud regroupe l'en-tête de bloc L2 non sécurisé, crée des transactions de batcher et les écrit dans L1.
Contrat relais standard
Bedrock comprend également une paire de contrats-relais pour les types de dépôts les plus courants, appelés contrats-relais standard. Ces contrats encapsulent les contrats de dépôt et de retrait, fournissant une interface simple pour les dépôts et les retraits de jetons ETH et ERC-20.
Ces contrats de pontage sont conçus de telle sorte qu'un côté du pont inter-chaînes contient le jeton natif et que l'autre côté contient un jeton encapsulé qui peut gérer la frappe et la gravure. Le pontage du jeton natif implique de verrouiller le jeton natif dans le contrat, puis de verrouiller le. jeton natif dans le pont inter-chaînes. L’autre côté crée une quantité égale de jetons encapsulés.
Pour plus d’informations, consultez la section Spécification du protocole standard de pont inter-chaînes.
Canon
Bien que la construction et la vérification infaillibles soient implémentées dans Cannon, la spécification du jeu infaillible et l'intégration du challenger racine de sortie dans le nœud de cumul font partie des étapes de spécification ultérieures.
Lectures complémentaires
Spécification du protocole
La spécification du protocole définit les détails techniques de la pile OP et constitue la source de vérité la plus à jour sur le fonctionnement interne du protocole.
Différence du substrat rocheux
Pour un examen approfondi des différences entre Bedrock et les versions précédentes, voir En quoi Bedrock est différent.