20 000 mots : le débat sur la sécurité des rollups

Les cumuls héritent-ils de la sécurité ?

Écrit à l’origine par Jon Charbonneau

Compilé à l’origine par Frank, Foresight News

Préambule

Qu’on l’aime ou qu’on le déteste, Twitter n’arrêtera probablement jamais de se disputer pour savoir si « L2 » ou « Rollup » est « hériter de la sécurité ».

Alors que la plupart des débats sont des batailles sémantiques indiscernables, si vous parvenez à réduire l’argument, les points sous-jacents sont précieux car ils touchent aux questions fondamentales de quand, où et pourquoi le Rollup a du sens.

La L2 évolutive élimine-t-elle le besoin de L1 sur le marché ? Est-il possible de transformer un L1 comme Solana en L2 ?

Ces débats se résument principalement à des questions de sécurité. Malheureusement, la définition de la « sécurité » a toujours été très insaisissable. Nous utilisons généralement ce terme avec désinvolture, et la plupart des gens savent à peu près de quoi nous parlons, mais pas complètement. Ici, nous allons détailler la sécurité dans différentes architectures.

Définition du mot à la mode

Cumul

J’ai précédemment utilisé la définition suivante de Mustafa : « Rollup est une blockchain qui publie ses blocs sur une autre blockchain et hérite du consensus et de la disponibilité des données (DA) de cette blockchain ».

Ce qui suit est une définition plus générale donnée par James Prestwich : « Le cumul est un moyen d’opter pour un autre mécanisme de consensus en personnalisant les fonctions de transition d’état et en préservant l’état de surensemble. »

Ni l’un ni l’autre ne nécessite de pont de vérification, et la possibilité de créer des ponts inter-chaînes avec des hypothèses de confiance minimales est un avantage majeur du Rollup, mais il est crucial de les analyser séparément.

Nous pouvons prendre en compte les critères de cumul suivants :

• Le cumul est un système avec état (par exemple, blockchain) dérivé de l’exécution d’une fonction de transition d’état personnalisée (STF) sur l’entrée de données sur la chaîne principale (couche DA).
• Toutes les données d’entrée (c’est-à-dire les données de transaction complètes ou les différences d’état) utilisées pour dériver l’état de confirmation final de la chaîne distante (c’est-à-dire le cumul) sont confirmées sur la chaîne principale.
• Étant donné que l’état de cumul est dérivé de la fonction de transition d’état (STF) qui s’exécute sur les données de la chaîne principale, la validité du cumul dépend de la validité de la chaîne principale. Le nœud Rollup doit alors vérifier pleinement le consensus et la validité de la chaîne principale (ou faire une hypothèse majoritaire honnête sur la chaîne principale) ;

Le nœud Rollup détermine l’état du Rollup sur le résultat du consensus de la chaîne principale (par exemple, la chaîne principale confirmant l’ordre et la disponibilité des blocs de données) en appliquant sa propre fonction de transition d’état (STF).

Pont cross-chain

Un pont inter-chaînes est un système qui permet à deux blockchains de communiquer entre elles. La chaîne A (la chaîne cible) doit être convaincue que quelque chose s’est passé sur la chaîne B (la chaîne source) et vice versa. Idéalement, nous voulons que cette communication soit bidirectionnelle, avec des attributs de sécurité fortement corrélés (par exemple, une grande confiance dans la validité du message, la chaîne source ne sera pas annulée, etc.).

Fondamentalement, le pont inter-chaînes agit comme un « observateur » d’une autre blockchain (comme tout autre utilisateur humain typique). Le pont inter-chaînes implémente une règle de confirmation donnée par laquelle il est convaincu de l’état de la chaîne connectée (par exemple, le nombre de blocs Ethereum qui doivent passer pour accepter les entrées de transfert).

• Les ponts inter-chaînes traditionnels exécutent généralement des nœuds légers de validation de consensus sur la chaîne de la chaîne source (c’est-à-dire tout ce à quoi ils font confiance pour la plupart des signes de consensus) ;
• Les ponts inter-chaînes peuvent fournir des attributs de sécurité plus forts en agissant comme des nœuds légers de validation complets (c’est-à-dire en ajoutant l’échantillonnage de la disponibilité des données (DAS) + validité/preuve de défaillance). Par exemple, le validateur d’une chaîne peut avoir besoin de s’exécuter sur tous les nœuds légers DAS qui connectent la chaîne, ce qui est une alternative plus légère qu’un nœud complet qui nécessite que le validateur exécute la chaîne connectée ;
• Le pont inter-chaînes Rollup peut également conserver l’activité et la résistance de la chaîne principale (car Rollup doit partager le consensus de la chaîne principale) ;

Pont à partir de la chaîne principale → Rollup

Cette direction est très simple, car le nœud Rollup vérifie entièrement la chaîne principale.

Les nœuds de cumul savent tout ce qui se passe sur la chaîne principale, ils savent donc quand des transactions pontées entre chaînes se produisent, et le nœud complet de cumul Ethereum actuel doit également exécuter le nœud complet pour la couche de base Ethereum elle-même.

Notez que les nœuds de cumul peuvent également exécuter un nœud léger de validation complet de leur chaîne principale à la place, s’ils sont pris en charge. Prenons un exemple hypothétique où Ethereum a entièrement mis en œuvre les mises à niveau suivantes :

• Blocs d’exécution Ethereum avec preuve de validité (la recherche zkEVM au niveau de la couche de base est en cours) ;
• Ethereum a mis en place un DAS complet, afin que les nœuds puissent échantillonner le DA ;
• La couche d’exécution Ethereum publie ses données sous forme d’objets blob dans la couche de données, comme n’importe quel autre rollup sur Ethereum (par exemple, les données de la couche d’exécution de Celestia seront publiées sur sa couche DA, de sorte que les nœuds DAS vérifieront la disponibilité des données de Rollup et de la propre couche d’exécution de Celestia) ;
• Ethereum fournit une preuve complète de consensus au lieu de s’appuyer sur des comités de synchronisation (par exemple, grâce à l’intégration de validateurs, à une meilleure agrégation de signatures, à une éventuelle preuve de consensus ZK, etc.) ;

Maintenant, en supposant que vous souhaitiez exécuter un nœud complet pour un cumul basé sur Ethereum, pour suivre une chaîne de cumul valide, vous devez comprendre la chaîne canonique d’Ethereum, ce qui nécessite de vérifier le consensus et la validité d’Ethereum lui-même :

• Consensus Ethereum - n’importe quel client de nœud léger peut suivre le consensus signé en tant que blockchain, en-tête de bloc ;
• DA de la couche d’exécution d’Ethereum - Les nœuds de cumul échantillonnent la couche DA d’Ethereum, vérifiant la disponibilité des données de cumul et les données de la couche d’exécution d’Ethereum (notez que les nœuds DAS font toujours des hypothèses supplémentaires sur les nœuds complets, comme nous le verrons plus tard) ;
• La validité de l’état propre d’Ethereum - avec zkEVM, chaque bloc Ethereum est accompagné d’une preuve de validité ;

Les nœuds de cumul doivent vérifier la validité de l’état et la DA de la couche d’exécution d’Ethereum, car ce sont les conditions de validité des blocs Ethereum. Le nœud Rollup doit savoir qu’il suit non seulement Ethereum là où le consensus a été signé, mais aussi qu’il s’agit d’un en-tête de bloc valide. Par exemple, ils peuvent accidentellement suivre des blocs Ethereum qui sont signés par consensus mais invalides (par exemple, ils génèrent beaucoup d’ETH).

Si la couche d’exécution sous-jacente publie elle-même ses données sur la couche DA (tout comme les autres cumuls) et ajoute une validité ou une preuve d’échec, elle devient un cumul intégré.

Pont de la chaîne principale Rollup →

Cette direction est délicate, car la chaîne principale ne connaît pas l’état de Rollup et STF par défaut (c’est-à-dire que les nœuds Ethereum n’ont pas besoin d’exécuter des nœuds Rollup). Pour que la chaîne principale croie en l’état du rollup, vous pouvez implémenter la logique du rollup dans le smart contract déployé sur la chaîne principale (c’est-à-dire le contrat de pont de vérification du rollup). Ce contrat intelligent vérifie la validité des états DA et Rollup.

Encore une fois, ce pont à chaîne croisée est facultatif. Les contrats intelligents sur la chaîne principale sont utilisés pour convaincre tous les nœuds de la chaîne principale de la validité du Rollup, qui permet une communication bidirectionnelle sous de bonnes hypothèses de confiance.

Cumuls, coprocesseurs et intentions

Comme nous l’avons vu, les Rollups enregistrent une partie de leur propre état (l’état du Rollup) en plus de posséder l’état de leur chaîne principale (par exemple, Ethereum). Alors, CoW Swap a-t-il son propre état qui ne fait pas partie de l’état Ethereum ? Si oui, alors cela ressemble à un rollup. Si ce n’est pas le cas, il pourrait s’agir d’un « coprocesseur ».

Cependant, même cette question n’est pas aussi simple qu’il n’y paraît :

Au lieu de cela, vous pourriez penser que le facteur distinctif est la persistance de l’état :

Si CoW Swap permet à des participants spécifiques de fournir aux utilisateurs des pré-confirmations rapides (plus rapides que le temps de bloc d’Ethereum) et promet des commandes qui incluent des lots – puisque le traitement par lots d’Ethereum prend plus de temps que la plupart des utilisateurs ne le souhaiteraient, s’agit-il maintenant d’un cumul ?

Chris Goes a abordé ce sujet dans son intervention au Modularity Summit, en commençant par une définition approximative des intentions : « l’engagement d’une fonction de préférence pour un espace d’état système donné ».

Notez les similitudes entre la résolution partielle (intention de correspondance) et le tri cumulatif. L’opérateur obtient le message signé hors chaîne de l’utilisateur → publie les données résultantes sur la chaîne principale.

• Applications basées sur l’intention – les changements d’état qui en résultent sont résolus sur la chaîne (par exemple, dans l’exemple CoW Swap, l’application est sur la chaîne sous-jacente, de sorte que les jetons y sont échangés) ;
• Application de cumul – utilise les données soumises à la chaîne principale pour calculer les changements d’état générés par le cumul ;

Les architectures centrées sur l’intention et les architectures centrées sur le cumul permettent d’atteindre des objectifs similaires dans des directions opposées. L’approche centrée sur l’intention aborde ce problème de manière générale du point de vue des utilisateurs et des applications, et l’approche centrée sur le cumul aborde ce problème de manière générale du point de vue des différentes blockchains.

Ici, il n’est pas important de fixer des limites distinctives spécifiques. De plus, nous avons constaté que le cumul n’est en fait pas très différent des applications auxquelles nous nous sommes habitués avec la correspondance d’intention hors chaîne !

Vous comptez sur des participants hors chaîne (séquenceurs vs. solveurs/remplissages, etc.) pour obtenir des garanties plus faibles, telles que fournir la meilleure exécution et une bonne expérience utilisateur → déterminer le résultat en fonction des données publiées sur la chaîne principale. Cependant, ils ne détiennent pas vos fonds en garde.

Au fur et à mesure que le calcul hors chaîne vérifiable devient plus important, les frontières entre les deux peuvent devenir floues :

Si vous souhaitez que le solveur d’intention ou l’ordonneur de cumul soit moins fiable...

Blockchain modulaire et blockchain monolithique

Les blockchains monolithiques (alias blockchains intégrées) sont souvent définies comme des chaînes qui intègrent verticalement toutes les fonctions de base, c’est-à-dire le consensus, l’AD et l’exécution. Ils assument l’entière responsabilité de leur propre sécurité, et Solana et Cosmos Hub en sont de parfaits exemples.

Les couches DA (telles qu’Ethereum et Celestia) sont souvent appelées blockchains « modulaires » car elles externalisent l’exécution à Rollup, mais ce n’est pas tout à fait exact. Ils sont également responsables de manière indépendante de leur propre consensus, de leur AD et de leur application.

Même l’exécution de Celestia sera limitée (par exemple, les transferts, le staking, le cross-chain). De même, si quelqu’un démarre Rollup au-dessus de Solana, il ne deviendra pas comme par magie une blockchain « modulaire ».

Ainsi, lorsque vous entendez des gens qualifier des chaînes comme Ethereum ou Celestia de blockchains « modulaires », sachez qu’il s’agit plus d’une distinction pratique que strictement technique. Les deux optimisent souvent leurs propres architectures pour prendre en charge le cumul. Ces rollups sont censés gérer la majeure partie de l’exécution des transactions dans leur champ d’application.

Même le Rollup n’est pas nécessairement complètement « modulaire » : le séquenceur Rollup peut se mettre d’accord sur le séquençage des transactions, fournir un DA et exécuter des transactions avant que la chaîne principale ne fasse quoi que ce soit. C’est ainsi que les utilisateurs sont pré-confirmés. La chaîne principale fournit ensuite un autre engagement « final », déclarant à nouveau le DA et le consensus sur l’ordre des transactions de Rollup.

Rollups et chaînes intégrées

Pour nos besoins, la distinction la plus importante est « Rollup » ou « Non-Rollup ». L’état final de la chaîne provient-il des données publiées dans une chaîne principale distincte (c’est-à-dire une couche DA) ?

Bien que nous associions aujourd’hui DAS et validité/preuve d’échec aux cumuls traditionnels, nous devons noter qu’il s’agit de concepts logiquement différents. En théorie, n’importe quelle « chaîne d’intégration » (telle qu’une chaîne d’applications Cosmos typique) peut être mise à niveau pour ajouter des DAS et des preuves de validité sans avoir à publier ses données sur d’autres chaînes principales externes telles qu’Ethereum. Le noeud échantillonnera et vérifiera la chaîne séparément.

Vitalik parle de cette différence dans son Endgame :

Vous remarquerez peut-être qu’une « grande blockchain traditionnelle » (chaîne d’intégration) avec DAS + validité/preuve de défaillance peut finir par ressembler à un « rollup enchâssé » ! De même, « un rollup évolutif et dominant » pourrait connaître un tel succès qu’il fusionnera simplement avec sa chaîne principale pour s’adapter à ce rollup.

Les frontières de la distinction s’estompent à la limite.

Par conséquent, si vous pensez que l’efficacité/la preuve de défaillance du DAS+ est le résultat final, alors le « cumul » est inévitable dans un sens. Il existe une différence valable entre les deux méthodes dans le diagramme précédent :

• « Rollups » alias « modularité » - construisez des chaînes logiquement indépendantes, publiez des données sur sa chaîne principale (couche DA) et réutilisez le consensus de la chaîne principale ;
• « Blockchain intégrée » alias « blockchain monolithique » - intégrez tout dans un protocole avec son propre consensus, sans publier de données dans une chaîne principale distincte (même si la couche DA et la couche d’exécution sont logiquement des parties distinctes du protocole partagé dans un sens) ;

Lorsque nous parlons de « Rollup » dans ce rapport, nous faisons référence au premier (c’est-à-dire qu’il ne s’agit pas d’une chaîne d’intégration avec DAS + validité/preuve d’échec, que l’on peut appeler Rollup intégré).

Bien que le Rollup « traditionnel » n’ait pas le monopole du DAS ou des preuves (c’est-à-dire que les grandes blockchains intégrées peuvent les ajouter), notez que nous négligeons de nombreux détails techniques ici, et que vous ne pouvez pas simplement choisir Solana et décider « Oh, je suppose que nous allons ajouter du DAS aujourd’hui ».

Cela nécessite une refonte fondamentale du protocole pour commencer à se rapprocher de ce que nous voyons Ethereum et Celestia faire :

Changer la façon dont les données sont encodées pour prendre en charge DAS équivaudra à ralentir l’encodage et la propagation des blocs, en commençant à se rapprocher de la couche DA traditionnelle :

Pour cette raison, nous voyons l’équipe construire ce qui suit :

• Couches DA spécialisées (par exemple, Danksharding d’Ethereum, Celestia, etc.) - blocs lents + DAS ;
• Séquenceurs partagés (par exemple Espresso, Astria ou même Solana) - vraiment juste des couches DA rapides, pas de DAS requis ;

Cependant, si vous séparez le temps des blocs rapides et du DAS, ils ne sont pas nécessairement compatibles. Par exemple, vous pouvez imaginer qu’une chaîne comme Solana propose deux chemins différents :

• Voie rapide - continuer à exécuter des transactions et à diffuser des données aussi rapidement que possible (comme c’est le cas aujourd’hui) ;
• Chemin lent - encoder les données après coup de manière à ce que l’échantillonnage asynchrone puisse être effectué, ce qui donne l’assurance que les nœuds DAS sont légèrement en retard sur le consensus ;

Anatoly explique dans le podcast comment Eclipse rassemble Ethereum, Celestia et Solana, et à l’autre extrémité du spectre, vous pouvez imaginer que la couche DA ajoute un chemin plus rapide avant de rendre les données disponibles pour l’échantillonnage :

Le fait de fournir deux chemins dans le même protocole de couche de base permet d’internaliser efficacement le tri partagé rapide, ce qui permet d’obtenir une conception intéressante basée sur le cumul. Notez qu’à l’heure actuelle, il s’agit encore d’une idée très exploratoire.

Confirmer la règle

Dans ce contexte, nous pouvons maintenant commencer à décomposer les attributs de sécurité de ces différentes architectures.

Tout d’abord, les nœuds interagissent avec n’importe quelle blockchain en exécutant des « règles de confirmation » :

« Les règles de confirmation font référence à l’algorithme qui est exécuté par un nœud pour indiquer si un bloc est confirmé ou non. Dans ce cas, sous certaines hypothèses, impliquant principalement la synchronisation du réseau et le pourcentage d’actions honnêtes, lorsque ces conditions seront remplies, le blocage sera garanti qu’une réorganisation n’aura jamais lieu ».

Il peut y avoir un nombre illimité de règles de confirmation pour une chaîne donnée :

• Combien de blocs devez-vous attendre avant de confirmer une transaction Bitcoin ? 1 ？ 6 ？ 10 ？
• Utilisez-vous LMD GHOST pour confirmer les blocs en fonction du registre utilisable d’Ethereum, ou attendez-vous que le gadget final (Casper FFG) confirme ?
• Exécutez-vous des nœuds complets qui vérifient directement chaque bloc, ou uniquement des nœuds légers qui vérifient la signature de consensus ?
• Vous venez de demander à Inpura ?

Étant donné que chaque règle d’accusé de réception peut faire des hypothèses très différentes, elles peuvent avoir des propriétés de sécurité très différentes, même lorsqu’elles interagissent avec la même chaîne :

Cette distinction est subtile mais importante :

Sécurité = Sécurité + Activité

Voyons maintenant si Rollup « hérite de la sécurité » de sa chaîne principale.

L’héritage, et peut-être plus clairement, Rollup « loue » toujours plutôt que « hérite » de tout ce qui se trouve dans sa chaîne principale, paie un coût permanent pour les ressources consommées (DA), et l’une ou l’autre des parties peut choisir de mettre fin à la relation. Mais ce n’est pas la partie intéressante du problème.

La sécurité, à partir de maintenant, nous allons nous concentrer sur la sécurité. La sécurité d’un algorithme consiste en la sécurité et la vivacité :

• Sécurité (rien de mal ne se produira), l’état final déterminé par deux nœuds sains n’entrera jamais en conflit ;
• Vivacité (de bonnes choses finiront par arriver), tous les nœuds sains compléteront un nouvel état reflétant les transactions incluses dans un temps limité ;

À l’aide de l’excellent cadre de Sreeram, nous pouvons les décomposer en cinq attributs qui fonctionnent ensemble pour sécuriser les règles de confirmation :

Prenons l’exemple d’une chaîne d’intégration hypothétique avec DAS + validité/preuve d’échec. Ses données ne sont publiées sur aucune autre chaîne principale externe. Pour simplifier, nous supposons une finalisation instantanée (par exemple, Tendermint), de sorte qu’il n’y a pas de distinction utilisable entre un grand livre disponible et un registre finalisé (par exemple, Gasper d’Ethereum).

Nous allons considérer trois règles de confirmation qui peuvent être utilisées pour tracer la chaîne à l’aide de différents types de nœuds :

• Nœud léger du validateur de consensus - vérifie la preuve du consensus (c’est-à-dire qu’il fait confiance au consensus de la majorité honnête).
• Nœud léger de validation complet - vérifier le consensus + vérifier DA (à l’aide de DAS) + vérifier la validité de l’état (à l’aide de la validité / preuve d’échec) ;
• Nœud complet - consensus de vérification + vérification directe de DA (téléchargement de toutes les données) et de validité (exécution de toutes les transactions et calcul du statut) ;

Confirmez que la règle a des attributs de sécurité, la chaîne n’en a pas

Encore une fois, « nous parlons familièrement qu’une chaîne est sécurisée, mais en fait, il s’agit d’une règle de confirmation attachée à l’attribut de sécurité ».

Voyons quelques exemples.

Théorème CAP

En guise de contexte, le théorème CAP nous dit qu’aucun registre ne peut satisfaire ces deux conditions en même temps :

Adaptabilité (c’est-à-dire disponibilité dynamique) - rester actif avec une participation dynamique (c’est-à-dire si la plupart des nœuds sont hors ligne) ; Finalité (c’est-à-dire cohérence) – maintien de la sécurité sous les partitions réseau ;

Les protocoles de consensus ont tendance à être divisés en deux parties, chacune d’entre elles satisfaisant à l’une des conditions ci-dessus :

• Protocoles à chaîne la plus longue - ces protocoles (par exemple, le consensus Satoshi de Bitcoin) garantissent l’activité même lorsque le nombre de nœuds participants actifs est variable (c’est-à-dire qu’ils sont adaptatifs), mais ils ne sont pas sécurisés (c’est-à-dire non définitifs) dans le cadre du partitionnement du réseau ; Protocoles de type BFT - Les protocoles de consensus classiques (par exemple, PBFT) atteignent la finalité mais n’atteignent pas l’adaptabilité ;

Règles de confirmation Bitcoin

Le consensus de Bitcoin ne fournit aucune finalité économique stricte.

Les nœuds observent la chaîne la plus longue dans leur vue locale, et chaque utilisateur est libre d’appliquer n’importe quelle règle de confirmation qu’il souhaite (par exemple, accepter des blocs avec des confirmations >k). La norme est d’attendre que 6 blocs soient confirmés, mais c’est à vous de décider.

Pour les transactions de plus grande valeur, il est raisonnable d’attendre plus longtemps. Il y a un compromis entre le temps d’attente et la sécurité, c’est-à-dire la possibilité d’une réorganisation.

Règles de confirmation d’Ethereum

Le consensus PoS d’Ethereum (Gasper) semble à première vue contourner le théorème CAP. Toutefois, il implémente ces deux propriétés, car il contient deux registres imbriqués :

• Grand livre disponible dynamiquement - si le réseau n’est pas partitionné, il est sûr et actif avec une participation dynamique ;
• Registre de préfixe finalisé - toujours sûr et sécurisé. Si le réseau n’est pas partitionné et qu’un nombre suffisant de nœuds y participent, il reste actif ;

Gasper appartient à la famille des protocoles « flux et reflux » (également connus sous le nom de double registre ou règle de double confirmation). La conception à deux registres n’entre pas dans le champ d’application du théorème CAP (c’est-à-dire qu’elle suppose une seule règle de confirmation). Lorsque le réseau est partitionné, le registre finalisé est à la traîne par rapport au registre adaptatif, mais il rattrape son retard lorsque le réseau est réparé.

Cela permet de trouver un compromis entre l’adaptabilité et la finalité au niveau de l’utilisateur plutôt qu’à l’échelle du système. Il s’agit d’une caractéristique du protocole de la « plus longue chaîne de points de contrôle » proposée par le théorème blockchain CAP en termes d’adaptabilité et de finalité sur laquelle les utilisateurs peuvent compter. Ces protocoles offrent aux utilisateurs individuels le choix entre la finalité et l’adaptabilité, plutôt que de l’imposer au niveau global du système.

Gasper expose explicitement deux règles de confirmation différentes, mappées aux deux registres mentionnés ci-dessus :

• Règles disponibles dynamiquement - adaptabilité garantie. Respectez l’en-tête de bloc de la chaîne la plus longue. LMD GHOST est une règle de sélection de fork utilisée pour déterminer le sous-arbre le plus lourd ;
• Règles de finalisation - Garantit la certitude finale. Respectez les blocs confirmés par les gadgets finaux. Les FFG Casper sont des gadgets finaux qui s’appliquent en plus des règles de sélection des fourches ;

Comme nous l’avons vu dans le document :

« Des règles adaptatives plus optimistes confirment toujours les blocs marqués comme finalisés par des règles plus conservatrices, et peuvent confirmer plus de blocs lors de niveaux de participation variables. Les clients (utilisateurs) choisissent localement entre les règles de confirmation en fonction de leurs préférences personnelles, tandis que les mineurs suivent des règles de proposition de bloc fixes qui sont cohérentes avec ces deux règles de confirmation.

Cela permet à tous les noeuds (honnêtes) du système :

• Suivre un mécanisme commun de proposition de bloc ;
• Cependant, différents nœuds peuvent choisir des règles de confirmation différentes ;

Les validateurs continuent d’allonger la chaîne la plus longue (en minant de nouveaux blocs à des hauteurs toujours plus élevées), quel que soit le niveau de participation, mais ce n’est que lorsqu’il y a suffisamment de participation que de nouveaux points de contrôle apparaîtront.

La chaîne la plus longue (contenant le point de contrôle le plus récent) peut alterner entre différentes chaînes (c’est-à-dire réassembler des blocs incomplets), mais le point de contrôle est garanti d’être sur une seule chaîne, quelles que soient les conditions du réseau (c’est-à-dire la finalité).

La sécurité des utilisateurs dépend des règles de confirmation qu’ils suivent. Il existe un compromis entre un accusé de réception rapide des blocs et des garanties de sécurité plus solides. Les utilisateurs qui vendent du café peuvent préférer l’activité à la sécurité, mais les utilisateurs qui vendent des yachts peuvent préférer la sécurité à l’activité.

Les nœuds Ethereum peuvent également appliquer d’autres heuristiques de règles de confirmation intermédiaires à des fins pratiques. Au lieu d’utiliser des blocs k naïfs comme règle de confirmation adaptative, comme le fait Bitcoin, nous pouvons ajouter d’autres heuristiques qui incluent des hypothèses sur la synchronisation du réseau et l’honnêteté du validateur.

C’est exactement ce qui est proposé dans les règles de confirmation du protocole de consensus Ethereum, qui proposent des règles de confirmation avec les propriétés suivantes :

• Dans des conditions idéales - la règle confirmera un nouveau bloc immédiatement après son emplacement ;
• Dans les conditions typiques du réseau principal, la règle devrait être en mesure de confirmer la plupart des nouveaux blocs en moins d’une minute ;

Cette règle de confirmation ne se substitue pas à la finalité économique. Au lieu de cela, il fournit des heuristiques utiles pour les utilisateurs qui pensent que la synchronisation réseau restera dans un avenir proche. Comparons les deux :

Prenons quelques exemples, par exemple si vous vendez un yacht pour 2,5 millions de dollars en ETH, voici quelques règles de confirmation possibles :

• Nœud complet + attente du résultat final - même une majorité malveillante de validateurs ne peut pas vous inciter à accepter des blocs invalides (par exemple, produire de faux ETH). S’ils vous paient 2,5 millions de dollars en ETH et qu’ils essaient ensuite de restructurer le bloc finalisé, ils encourront un coût énorme (au moins un tiers de l’équité est une réduction punissable) ;
• Nœud complet + attente d’un blocage - la plupart des validateurs malveillants ne peuvent toujours pas vous inciter à accepter un bloc invalide, mais ils peuvent vous envoyer 2,5 millions de dollars en ETH dans un bloc valide, partir sur un yacht, puis le bloc est immédiatement réorganisé, ce qui est possible s’il y a suffisamment de poids de mise ou de mauvaises conditions de réseau, ils ne sont pas coupés de manière punitive ;
• Client de nœud léger - Les tableaux de synchronisation malveillants peuvent vous mentir sans pénalité et les acheteurs peuvent partir sur le yacht (notez que ce comité de synchronisation est exclusif à Ethereum en tant que sous-ensemble du consensus, d’autres chaînes PoS avec un support client de nœud léger plus efficace peuvent vérifier tous les votes de consensus avec un petit nombre de validateurs) ;
• MetaMask - Vous faites simplement confiance à Infura, la personne qui vous a acheté le yacht a promis à l’employé d’Infura qu’ils pourraient prendre le yacht le week-end, alors ils vous ont menti, vous pensiez avoir obtenu 2,5 millions de dollars en ETH, puis vous avez remis les clés ;

Le cumul confirme les règles

Comme pour toute chaîne, les nœuds interagissent avec le cumul à l’aide de différentes règles d’accusé de réception. Les règles de confirmation les plus strictes de Rollup seront finalisées en même temps que le consensus de sa chaîne principale. Le séquenceur de cumul peut exposer des règles de confirmation plus faibles pour une meilleure expérience utilisateur (c’est-à-dire fournir une pré-confirmation rapide pour les utilisateurs impatients), mais les utilisateurs peuvent également attendre la sécurité totale des règles de confirmation de la chaîne principale.

Un flux de transaction de cumul typique ressemble à ceci :

• L’utilisateur soumet une transaction au séquenceur ;
• Le séquenceur trie les transactions et donne une pré-confirmation ;
• Le STF déterministe doit être appliqué aux transactions ordonnées pour calculer le nouvel état de cumul ;
• L’engagement de statut de cumul mis à jour et les données de transaction associées sont enfin publiés dans la chaîne principale ;

Une fois les données de transaction publiées dans la chaîne principale :

• Rollup Full Node - vérifie directement que l’état de la chaîne proposé est correct ;
• Nœuds d’éclairage d’enroulement (y compris les ponts de vérification) - ne peuvent pas être vérifiés directement ;
• Différents observateurs d’un même Rollup utilisent des règles de confirmation différentes, de sorte qu’ils finalisent leur point de vue à des moments différents :
• Supposer la publication de données complètes sur les transactions (pas seulement les différences d’état) ;
• Comme mentionné précédemment, les nœuds de cumul doivent également exécuter des nœuds complets de la chaîne principale ou des nœuds légers de validation complets (ou utiliser des nœuds légers de validation de consensus pour faire des hypothèses de majorité honnêtes). Les noeuds légers de cumul peuvent s’exécuter en tant que logiciel supplémentaire ou implicitement dans le noeud de la chaîne principale (c’est-à-dire le cumul de vérification du contrat de pont inter-chaînes sur la chaîne principale) ;

Les utilisateurs peuvent également confirmer les transactions plus rapidement en faisant confiance au séquenceur pour confirmer à l’avance, avant même que le lien principal ne reçoive les données. Si le séquenceur ne se comporte pas correctement, la sécurité peut échouer. Ensuite, une fois que les données sont sur la chaîne principale (et que vous avez vérifié la validité de DA+), seule une défaillance de la chaîne principale (telle qu’une réorganisation d’Ethereum) affectera votre sécurité.

Par conséquent, même les donneurs d’ordre centralisés ne réduisent pas vraiment la sécurité du « Rollup ». Vous bénéficiez toujours d’une sécurité conforme aux règles de confirmation dont vous avez besoin. Que le Rollup ait une conception basée sur un séquenceur ou autre, vous pouvez utiliser les mêmes règles de confirmation (par exemple, attendre que la chaîne principale soit finalisée et vérifier la validité du Rollup). En supposant une mise en œuvre correcte (par exemple, l’application de l’inclusion des transactions via la chaîne principale), vous pouvez obtenir les mêmes attributs de sécurité dans le même laps de temps tout en conservant les mêmes conditions.

De même, vous pouvez imaginer que les producteurs de blocs Ethereum L1 fournissent une pré-confirmation en raison de la lenteur des temps de blocage, ce qui ne rend pas « Ethereum » moins sûr. Il vous suffit de décider d’utiliser une autre règle de confirmation (moins sécurisée) jusqu’à ce que le validateur Ethereum finalise la sécurité la plus élevée.

L’idée de préconfirmation s’inscrit bien dans la logique de Gasper décrite par Vitalik :

Le principe général est que vous voulez fournir « autant de consensus que possible » à l’utilisateur : s’il y a > 2/3, alors nous arrivons à un consensus sur une base régulière, mais s’il y a < 2/3, alors il n’y a aucune raison de retarder sans rien fournir, car évidemment la chaîne continuera à croître malgré le niveau de sécurité temporairement plus bas du nouveau bloc. Si une seule application n’est pas satisfaite d’un niveau de sécurité inférieur, n’hésitez pas à ignorer ces blocs jusqu’à ce qu’ils soient finalisés.

En mettant tout cela ensemble, lorsque toutes les règles de confirmation s’accordent sur le même état du référentiel en même temps, nous avons une « zone de cohérence » :

Confirmer la règle - sécurité et accessibilité

Si votre règle de confirmation est de faire confiance à un seul séquenceur géré par un SBF, plutôt qu’à un séquenceur décentralisé composé des validateurs les plus réputés au monde, alors votre sécurité peut être pire, et la défaillance active et la réorganisation sont des défaillances de sécurité.

Vous pouvez également attendre que des règles de confirmation (mainchain) plus strictes soient disponibles. Ensuite, toutes choses étant égales par ailleurs, un séquenceur non fiable n’affectera pas votre sécurité. Si vous vendez du café, vous y allez probablement tout de suite, mais si vous vendez un yacht, vous devrez vérifier la confirmation de la chaîne principale.

Cependant, si tout le monde utilise réellement cette règle de confirmation pour vendre son yacht, nous ne pouvons pas complètement ignorer la sécurité potentiellement faible de la règle de confirmation « faire confiance à une personne aléatoire exécutant un séquenceur séparé ». La conception précise est basée sur un équilibre entre le niveau d’engagement progressif requis pour un cas d’utilisation donné.

Encore une fois, cela touche à une véritable critique des blockchains à haut débit comme Solana. Quelles règles de confirmation les gens peuvent-ils réellement utiliser ? Vous pouvez avoir de bonnes conditions de sécurité pour exécuter des nœuds complets Solana, mais la plupart des gens peuvent ne pas avoir accès à cette règle de confirmation (c’est-à-dire en fonction des besoins en ressources et/ou du coût).

La vérification directe (c’est-à-dire le fait de ne pas faire confiance à la majorité honnête) est un attribut essentiel de ces systèmes. Ainsi, pour une règle de confirmation donnée, nous nous soucions vraiment de deux aspects : la sécurité et l’accessibilité :

En un mot :

• Les utilisateurs interagissent avec n’importe quelle chaîne par le biais de règles de confirmation ;
• Une chaîne peut avoir n’importe quel nombre de règles de confirmation ;
• La sécurité est un attribut de la règle de confirmation, et non de la chaîne elle-même ;
• Nous nous soucions de la sécurité et de l’accessibilité des règles de confirmation pour une chaîne donnée ;

En fait, lorsque nous disons qu’une chaîne donnée est sécurisée, nous essayons d’exprimer l’idée que les règles de confirmation qui lui sont associées sont à la fois sécurisées et accessibles.

Rollups avec sécurité de la chaîne d’intégration

1 , chaîne d’intégration avec preuve de validité du DAS+

On voit aujourd’hui que la sécurité concernant le DA et la validité de l’état peuvent être vérifiées directement par cryptographie (DAS + validité / preuve de défaillance) sans faire d’hypothèses fortes sur les opérateurs de la chaîne. N’importe quel protocole peut techniquement les mettre en œuvre. Les nœuds complets peuvent également vérifier la validité de DA et d’état sans hypothèses externes.

Concentrons-nous maintenant sur d’autres propriétés - l’activité et la résistance à la recombinaison. Comme nous l’avons vu précédemment, ceux-ci peuvent échouer, quel que soit le type de règle de confirmation que vous exécutez. Regardons une autre chaîne d’intégration qui prouve la finalité de l’efficacité DAS+ du socket unique +PoS :

Le choix de règles d’accusé de réception fortes est particulièrement efficace pour un sous-ensemble de défaillances de sécurité, où même la plupart des validateurs malveillants ne peuvent pas tromper des nœuds complets ou des nœuds légers de validation complets en leur faisant croire que :

• Les données non disponibles sont effectivement disponibles ;
• ou les transitions d’état invalides sont valides ;

Qu’Ethereum ait 1 validateur ou d’innombrables validateurs, tous les nœuds croient plus ou moins au DA ou à la validité du bloc, qu’ils sont garantis en vérifiant. Les nœuds légers de validation complets peuvent être vérifiés d’une manière plus simple (mais notez que DAS fait d’autres hypothèses, dont nous parlerons plus tard).

Cependant, une majorité malveillante de validateurs peut empêcher le registre de croître, de vous censurer ou de réorganiser la chaîne (les échecs qui se produisent dépendent des règles de confirmation). DAS + ZK ne vous sauvera pas. La résistance à la réorganisation et à l’activité dépend toujours, dans une certaine mesure, des différents attributs sous-jacents d’une chaîne donnée (par exemple, des opérateurs fiables, des incitations économiques, un consensus social, etc.).

De manière moins évidente, l’activité et la résistance à la réorganisation sont toujours des attributs d’une règle d’accusé de réception donnée, puisque chaque nœud fait l’objet de la même attaque que dans le tableau ci-dessus. Quelles que soient les règles de confirmation ici, ils ont la même garantie.

Cependant, cela devient à nouveau évident lorsque vous supprimez l’hypothèse de finalité d’un seul emplacement. Dans Gasper d’Ethereum, en fonction du registre que vous suivez (c’est-à-dire le plus long registre de chaîne ou point de contrôle disponible), vous aurez à nouveau des propriétés différentes de résistance à l’activité et à la réorganisation. La plupart des validateurs malveillants provoquent différentes défaillances de sécurité en fonction des règles de confirmation que vous exécutez.

Quoi qu’il en soit, le fait est que la construction sous-jacente de la chaîne est ici très importante. Vous avez besoin d’opérateurs forts, d’incitations économiques et d’un consensus social pour maintenir la chaîne active et résistante à la restructuration. De plus, les protocoles de consensus à double registre tels qu’Ethereum offrent aux utilisateurs une flexibilité précieuse pour calculer la disponibilité et la finalité en fonction de leurs besoins.

2, Preuve de cumul à l’aide de DAS + validité

Modifions maintenant un peu cet exemple :

• Exemple précédent - une chaîne d’intégration avec une preuve de validité de DAS +, imaginez prendre le Solana d’aujourd’hui, mais en ajoutant une preuve de DAS + ;
• Nouvel exemple - Le Rollup est déployé sur une chaîne principale externe (par exemple Ethereum) avec preuve de validité + DAS (notez qu’Ethereum DAS n’est pas encore en ligne), Rollup dispose d’un ensemble de séquenceurs décentralisés qui peut atteindre un consensus avec une pré-confirmation rapide ;

Vous remarquerez que le cumul a deux types de règles de confirmation complètement distincts pour des périodes différentes (c’est-à-dire que vous opérez sur la base du pré-consensus du séquenceur ou que vous attendez le consensus final de la chaîne principale), examinons maintenant chaque chemin.

Fast Path - Avant le consensus de la chaîne principale

Les noeuds de cumul peuvent s’appuyer sur la confirmation du séquenceur (avant de publier dans la chaîne principale), et nous supposons qu’ils peuvent exécuter les noeuds de cumul suivants :

• Rollup Consensus Validator Light Node - Faites confiance à la majorité honnête dans le consensus du séquenceur Rollup ;
• Rollup Full Validator Light Node - exécute DAS + sur le flux du séquenceur pour vérifier la preuve de validité avant de publier quoi que ce soit sur Ethereum ;
• Rollup Full Node - Téléchargez toutes les données du flux du séquenceur et exécutez toutes les transactions pour vérifier directement le DA et la validité ;

Techniquement, le séquenceur Rollup peut faciliter le DAS et fournir une preuve de validité avant de publier sur la chaîne principale, mais cela ne se produit pas réellement. Les nœuds légers de validation complets sont généralement conçus pour les vérifier à travers la chaîne principale, mais je suppose que les preuves DAS+ « en direct » peuvent être comparées plus clairement à la même que la chaîne intégrée.

Le tableau suivant présente les modifications par rapport à l’exemple de la chaîne d’intégration :

• S’appuyer sur le séquenceur Rollup pour l’activité et l’anti-recombinaison, plutôt que sur l’ensemble de validateurs de la chaîne intégrée ;
• Suppression de l’attribut d’activité finale uniquement, car seule la plage de temps avant le consensus de la chaîne principale est affichée ici (ces attributs d’activité « finale » appartiendront à l’utilisateur plus tard dans le futur) ;

Les suppressions sont barrées en rouge et les ajouts sont indiqués en bleu :

Chemin lent - Attendre le consensus de la chaîne principale

Pour plus de sécurité, les nœuds peuvent attendre le consensus de la chaîne principale (par exemple, Ethereum), c’est là qu’il entre en jeu plus clairement, c’est-à-dire que les nœuds de cumul doivent également exécuter le nœud de la chaîne principale :

• Nœud léger de validation du consensus de la chaîne principale - faites confiance au consensus de la majorité honnête de la chaîne principale ;
• Nœud léger de validateur complet de la chaîne principale - vérifier la preuve de validité de la chaîne principale + exécuter DAS sur la chaîne principale (y compris les données Rollup + données de la chaîne principale) ;
• Nœud complet de la chaîne principale - télécharger toutes les données de la chaîne principale (y compris la vérification des données de cumul) + exécuter toutes les transactions de la chaîne principale pour vérifier directement la validité ;
• Notez que la validité de l’état du cumul peut être vérifiée par deux chemins différents :
• En dehors de la chaîne principale (exécutant un logiciel de nœud de cumul supplémentaire) - Le cumul n’exige pas de sa chaîne principale qu’il vérifie son état ou son STF, n’a pas besoin de déployer un pont de vérification, mais peut vérifier la preuve de cumul par une autre méthode (par exemple, la réception de la preuve de cumul via p2p), ce qui nécessite l’exécution d’un logiciel de nœud de cumul supplémentaire pour vérifier la preuve (c’est-à-dire les nœuds légers de cumul) ;
• À l’intérieur de la chaîne principale (implémenter le nœud Rollup à l’intérieur de la chaîne principale) - c’est la norme aujourd’hui, la logique de validation du nœud léger Rollup est déployée dans la chaîne principale elle-même (c’est-à-dire le contrat de pont intégré de Rollup), puisque ce nœud de validation Rollup s’exécute dans le STF de la chaîne principale, valider le STF de la chaîne principale signifie également vérifier le STF du cumul ;

Si nous obtenons une chaîne principale à l’épreuve de la preuve à divulgation nulle de connaissance (par exemple, Ethereum L1 zkEVM) + tous les rollups prouvent leur état à l’intérieur de la chaîne principale→ nous obtenons la vision de Vitalik de la preuve de singularité. Une preuve de validation d’Ethereum à divulgation nulle de connaissance signifie la validation de toutes les autres chaînes et la validation des nœuds de leurs implémentations internes :

Pour simplifier, nous supposons ici que la validité de l’état du cumul est vérifiée au sein de la chaîne principale elle-même (par exemple, le cumul a un pont intégré avec la chaîne principale), nous pouvons donc ignorer explicitement l’exécution explicite d’un logiciel de nœud de cumul supplémentaire en dehors du protocole.

Les modifications apportées par rapport à la table de cumul Fast Path précédente sont les suivantes :

Ceci est réalisé par la chaîne principale forçant les transactions à inclure ou imposant la substitution séquenceur/prouveur, que nous appelons ici activité « finale », car du point de vue de Rollup, il s’agit d’un chemin lent, mais du point de vue de la chaîne principale, cela peut être considéré comme une activité « en temps réel ».

Rollup avec blockchain intégrée

Nous pouvons maintenant voir les changements dans les attributs de sécurité liés à la blockchain intégrée et au Rollup :

• Validité de l’AD et de l’état : si elle est mise en œuvre, la preuve de validité DAS+ peut fournir des garanties de sécurité applicables, qu’il s’agisse d’une chaîne intégrée ou d’un cumul traditionnel. En fait, ces technologies sont aujourd’hui dominées par le Rollup ; Résistance à la réorganisation - Les blockchains intégrées en sont responsables indépendamment dans tous les scénarios. Au lieu de cela, le cumul offre un choix de règles de confirmation dans différents délais. Vous pouvez utiliser des règles de confirmation moins sécurisées (consensus du séquenceur de confiance) pour obtenir des garanties rapides, ou attendre des règles de confirmation plus sécurisées (attendre le consensus de la chaîne principale) ;

Activité et résistance à la recombinaison

Ces attributs ne peuvent pas être garantis par un mot de passe, et même entre les règles d’accusé de réception (par exemple, si vous exécutez un nœud complet ou léger), vous pouvez être vulnérable aux défaillances de sécurité.

Si l’opérateur est complètement hors de contrôle, aucun nœud complet ou preuve ZK ne peut vous protéger contre les échecs d’activité ou la réorganisation.

Ces attributs sont obtenus grâce à des opérateurs forts et décentralisés, des mécanismes résistants à la censure, un consensus propice à l’activité, un « coût » élevé de la restructuration, un fort consensus social, etc. Il est souvent difficile de les comparer objectivement.

Comment mesurez-vous la décentralisation des opérateurs et le consensus social ? Il n’y a pas qu’une seule bonne réponse. Ce sont sans doute les aspects les plus difficiles à concevoir, et ils sont en effet très uniques à une chaîne donnée.

Il est important de noter que le correctif cumulatif peut déléguer l’anti-réorganisation et l’activité à la chaîne principale, et que les règles de confirmation utilisées sur le correctif cumulatif peuvent avoir les mêmes attributs de sécurité que si elles s’exécutaient sur la chaîne principale dans le même laps de temps.

Les chaînes peuvent même choisir les attributs à déléguer à quelle chaîne, et différents types d’architectures « L2 » (telles que les validiums, l’optimisme et les sidechains) peuvent absorber différents sous-ensembles d’attributs de sécurité. Par exemple:

• Anti-restructuration - Rollup peut déléguer l’anti-restructuration à Ethereum, et ses règles de sélection de fork sont basées sur ce que le consensus Ethereum confirme pour sélectionner la « chaîne canonique ». Si Ethereum se réorganise, Rollup se réorganisera également.
• Vivacité - Cependant, si le Rollup ne dispose pas d’un mécanisme d’inclusion forcée et de remplacement forcé de l’opérateur, les utilisateurs du Rollup ne reçoivent toujours pas l’attribut de vivacité d’Ethereum ;

Rollup peut également fournir aux utilisateurs une voie d’évacuation pour quitter Rollup, tout en conservant la possibilité de vérifier les utilisateurs et d’empêcher les dépôts d’entrer dans Rollup (c’est ainsi que fonctionne Loopring, par exemple). Si le dépôt n’est pas traité après un certain temps, l’utilisateur peut retirer les fonds bloqués du contrat L1.

Cela souligne l’importance de tels mécanismes.

Disponibilité des données et validité de l’état

Contrairement à l’activité et à l’anti-recombinaison, les nœuds peuvent garantir la validité de DA et d’état sans faire d’hypothèses de seuil importantes (ou de compromis de sécurité entre les deux). Les producteurs de blocs majoritaires malveillants peuvent provoquer des échecs d’activité et de réorganisation, mais ils ne provoqueront pas d’échecs de DA ou de validité pour les nœuds complets ou les nœuds légers de validation complets.

Cependant, les nœuds légers du validateur de consensus sont bien sûr affectés par la validité de l’état des majorités honnêtes et des échecs de DA. Ils croient tout ce que dit le consensus. C’est pourquoi DA et la validité de l’état sont ce qui rend les règles de confirmation de sécurité accessibles et fonctionnent vraiment. C’est souvent l’énorme différence idéologique entre les Rollups traditionnels et les grandes blockchains qui n’accordent pas beaucoup d’importance à la vérification des utilisateurs.

Dans l’ordre, voici souvent les moyens privilégiés pour équilibrer la sécurité et l’accessibilité :

• Rendre le DAS et la preuve d’efficacité largement disponibles ;
• Si vous n’avez pas de DAS et/ou de preuve de validité, rendez les nœuds complets largement accessibles (c’est-à-dire nécessitant peu de ressources, faciles à exécuter, etc.) ;
• Si vous n’avez pas de DAS et/ou de preuve de validité, et que le nœud complet est en grande partie inaccessible, alors veuillez rendre le nœud léger du validateur de consensus largement accessible et avoir un consensus majoritaire honnête et digne de confiance ;
• Visite d’Infura ;

Notez que 2 (nœud complet) est en fait le plus sécurisé. La vérification ZK est simple, mais les nœuds DAS font des hypothèses supplémentaires que les nœuds complets ne font pas. Cependant, ils offrent presque la même sécurité que les nœuds complets, et avec des besoins en ressources à une fraction de cela, ils sont évolutifs.

Les nœuds complets n’ont besoin que de télécharger toutes les données, ils sont donc sûrs à 100 %. Ils ne signent le bloc que lorsque tout est là. Aucune hypothèse n’a été formulée au sujet des parties externes.

L’objectif du DAS est d’atteindre une sécurité presque aussi bonne que les nœuds complets, tout en nécessitant des ressources nettement inférieures (c’est-à-dire une échelle plus élevée). Cet article sur les niveaux de sécurité de la disponibilité des données des nœuds légers couvre bien cette question.

En bref, vous faites généralement des hypothèses sur la synchronisation du réseau et sur la question de savoir s’il y a suffisamment de nœuds pour reconstruire les données. Si les producteurs de blocs hostiles cachent des données, même un petit groupe de nœuds de lumière honnêtes devrait être en mesure de reconstruire collectivement des blocs. Il existe également des hypothèses sur la divulgation sélective des actions, dans laquelle les producteurs de blocs hostiles peuvent tromper un petit nombre de nœuds légers individuellement, mais pas collectivement.

Ces hypothèses « N-en-2 » (p. ex., une minorité honnête de noeuds peut obtenir un DAS) sont très avantageuses par rapport à l’hypothèse approximative typique de « N/2 » (p. ex., 51 % des producteurs de blocs peuvent conduire à une réorganisation). Vitalik a une bonne introduction à ce sujet dans son article sur le modèle de confiance.

Dans l’ensemble, l’AD et l’efficacité de l’état ne sont pas « commanditées » par Rollup en tant qu’activité et résistance recombinante. La validité de l’AD et de l’état peut être vérifiée directement par l’utilisateur, tandis que d’autres attributs dépendent davantage des participants consensuels de la chaîne et de leurs incitations.

Examinez un exemple de validation précédente de l’épreuve de cumul :

• Publiez la preuve de ZK de Rollup dans un contrat intelligent Ethereum, où vous exécutez un nœud complet Ethereum et vérifiez implicitement la preuve ;
• Envoyez la preuve ZK de Rollup à mon nœud de lumière Rollup pour vérifier directement la preuve ;

Dans les deux cas, vous pouvez garantir l’efficacité. Peu importe où vous le vérifiez, vous ne pouvez pas déterminer son efficacité. Ethereum n’a pas la même efficacité véritablement « forcée » que les nœuds Ethereum « forcent » les propriétés anti-restructuration ou actives. L’anti-restructuration et la vitalité dépendent en grande partie de la personne qui vous les obtient.

Prenons l’exemple d’un cumul basé sur une chaîne d’escroquerie :

• Les règles de sélection des fourches de Rollup suivent la pointe de la chaîne→ Si la chaîne est réorganisée, Rollup se réorganisera également ;
• Le mécanisme d’inclusion obligatoire du cumul et la suppression du séquenceur sont appliqués par le biais de contrats de pontage inter-chaînes sur la chaîne d’escroquerie→ Si le registre de la chaîne d’escroquerie s’arrête, le registre du cumul s’arrête également. Si la chaîne d’escroquerie veut censurer votre Rollup, vous serez censuré ;

Le cumul est capable d’exposer des règles de confirmation avec les mêmes attributs de sécurité que sa chaîne principale, qu’il peut recevoir au maximum au rythme du consensus de sa chaîne hôte (en fait, il sera généralement plus lent, en fonction de la fréquence à laquelle le cumul est publié sur la chaîne principale).

Les cumuls peuvent également fournir un « chemin heureux » avec des règles de confirmation plus souples (c’est-à-dire des séquenceurs) pour une meilleure expérience utilisateur, mais ils conservent les annulations de transaction en cas d’échec. Si votre séquenceur s’arrête, vous pouvez continuer à avancer. Cependant, ce n’est pas le cas si votre chaîne repose entièrement sur votre propre ensemble de validateurs (c’est-à-dire en tant que chaîne d’intégration).

Choisir judicieusement la chaîne principale de Rollup peut avoir un impact concret sur les attributs de sécurité. Il est particulièrement utile de tirer parti d’une backchain avec une forte activité (croissance du registre + CR) et une résistance à la réorganisation.

Différentes hypothèses de sécurité pour différentes périodes

Prenons un exemple simple. La chaîne X décide de se déployer en tant que Rollup sur une chaîne principale existante ou en tant que sa propre blockchain intégrée.

Le cumul présente les caractéristiques suivantes :

• Temps de blocage de 10 secondes ;
• Les nœuds d’éclairage DAS sont pris en charge
• Des règles de confirmation de « haute sécurité » pour l’activité et l’anti-réorganisation (par exemple, des validateurs de confiance décentralisés, etc.) peuvent être fournies ;

La blockchain intégrée présente les caractéristiques suivantes :

• Le temps de sortie du bloc est de 1 seconde ;
• Le nœud léger DAS et la preuve de validité peuvent être mis en œuvre, qu’il soit lancé en tant que blockchain intégrée ou en tant que rollup ;
• Si un séquenceur centralisé est mis en œuvre, il fournira des règles de confirmation de « faible sécurité » sur l’activité et la résistance à la recombinaison ;
• S’il met en œuvre son propre consensus décentralisé (soit sous la forme d’un ensemble de séquenceurs Rollup préconfirmés, soit sous la forme d’un ensemble de validateurs de chaîne intégrés), il fournira des règles de confirmation de « sécurité moyenne » pour l’activité et l’anti-réorganisation ;

Le tableau suivant donne une représentation visuelle simplifiée des meilleures garanties de sécurité que les utilisateurs peuvent avoir dans le cadre de diverses implémentations (c’est-à-dire qu’ils utilisent les règles d’accusé de réception les plus strictes disponibles). En particulier, nous nous concentrons ici sur l’activité et la résistance à la recombinaison (car nous supposons que la chaîne n’atteindra la preuve d’efficacité DAS+ que dans ces deux cas) :

La « sécurité ultime » de Rollup est supérieure à sa « sécurité en temps réel » car la chaîne principale ne peut pas nous garantir plus que son propre temps de bloc. Même si vous pouvez vérifier que les pré-acquittements du séquenceur sont des transitions d’état valides, vous ne pouvez pas garantir entièrement leur finalité tant qu’ils n’ont pas atteint la couche DA.

Mais comme nous l’avons vu, le déploiement sur une chaîne principale forte de manière cumulative améliore la sécurité. Ils peuvent louer des garanties à la vitesse de leur chaîne principale. Fondamentalement, il n’y a aucun moyen d’obtenir tous les attributs de sécurité de la chaîne principale plus rapidement que le consensus de la chaîne principale elle-même.

Cependant, les utilisateurs ont tendance à être impatients. Par conséquent, le cumul fournira généralement une pré-confirmation plus rapide, mais la garantie sera plus faible pendant cette période. Rollup peut choisir une conception de séquenceur équilibré :

• Fonctionnalité pratique et efficacité. Par exemple, les séquenceurs centralisés peuvent fournir une pré-validation rapide et réduire les frais généraux opérationnels ;
• Forte garantie. Par exemple, un ensemble incroyable de séquenceurs décentralisés peut fournir une meilleure activité en temps réel, mais au prix de coûts opérationnels et de latence plus élevés (dans le cas le plus extrême, vous laissez simplement la couche DA gérer l’ordre du cumul, en choisissant de ne pas exposer le chemin le plus rapide) ;

Il est intéressant de noter que vous pouvez affirmer que les cumuls d’ordre L1 sont moins actifs que les séquenceurs centralisés, en fonction de votre échelle de temps. Jusqu’à présent, nous avons parlé de l’activité, en l’incluant dans une sorte de concept de « temps fini ». Cependant, c’est tout à fait relatif et subjectif. Par rapport à quoi ? Combien de temps cela prend-il ?

Un cumul séquentiel L1 pur ne sera inclus qu’à la vitesse des blocs L1 (par exemple 10 secondes), et vous n’avez aucune garantie d’activité entre ces blocs lorsque le monde autour de vous change. Cela dépend donc de votre benchmark :

• Si la ligne de base = fonctionnement à l’intérieur du cumul, le cumul séquentiel L1 peut fournir une meilleure activité. Personne d’autre sur la chaîne ne devrait être promis jusqu’à ce que la chaîne principale soit confirmée, de sorte que vous êtes tous sur un pied d’égalité ;
• Si la ligne de base = opération en dehors du cumul - Le cumul avec préqualification douce peut fournir une meilleure activité. La pré-confirmation n’est qu’une option gratuite, et vous revenez toujours à la garantie de la chaîne principale à la vitesse de la chaîne principale, mais vous pouvez obtenir une garantie plus faible entre-temps. Si vous ne leur faites pas confiance, attendez simplement la confirmation de la chaîne principale. Le monde ne se fige pas entre les blocs Ethereum, et pour de nombreuses applications, les prix périmés entre les longs blocs peuvent être inacceptables ;

Si vous essayez d’implémenter un cumul basé sur le « réel » sans pré-confirmation, il est même possible que la pré-confirmation se produise de toute façon. Pour les participants, tels que les constructeurs et les validateurs d’Ethereum, il existe une incitation financière pour qu’ils prennent eux-mêmes cet engagement. C’est exactement la raison pour laquelle il y a des discussions sur la façon dont les constructeurs et les parties prenantes d’Ethereum tentent de fournir une pré-confirmation rapide au niveau de la couche de base.

Voici une dernière remarque importante. En supposant que les utilisateurs de Rollup peuvent revenir au même niveau d’activité que la chaîne principale, en supposant que vous puissiez forcer l’inclusion entièrement à la vitesse du bloc de la chaîne principale (par exemple, si le donneur de Rollup vous examine, vous pouvez forcer les transactions à être incluses dans le prochain bloc Ethereum de la chaîne principale).

Dans la pratique, il y a généralement un court délai. Si vous autorisez l’inclusion obligatoire immédiate, vous risquez d’exposer des MEV de censure rentables ainsi que d’autres complexités. Cependant, certaines conceptions peuvent fournir des garanties d’activité en temps quasi réel à partir de la chaîne principale (par exemple, peut-être à la vitesse de plusieurs blocs de la chaîne principale au lieu d’un seul bloc).

Quelle que soit l’échelle de temps exacte, l’activité ultime d’absorption de la chaîne principale est très forte, et l’utilisation d’une chaîne principale forte comme mécanisme de coordination fournit des menaces crédibles et des droits de sortie. La simple exposition de cette menace crédible à elle seule rend hautement improbable qu’elle soit nécessaire pour prévenir les comportements malveillants en premier lieu.

Par exemple, si l’utilisateur dispose d’un mécanisme fiable pour forcer la sortie ou même l’expulser de force, le séquenceur de cumul centralisé ne peut pas extraire arbitrairement la rente de l’utilisateur et l’enfermer. Il s’agit d’un domaine général abordé dans Chris Goes dans sa conférence sur MEV, le coût de conversion, l’avantage et le jeu lent.

Bien entendu, une activité inattendue peut également se produire, auquel cas ce chemin de sauvegarde peut à nouveau être très précieux.

La preuve ne protège pas la chaîne, mais protège l’utilisateur

Suite à tout cela, nous pouvons voir que pour une règle de confirmation donnée, il s’avère qu’il est plus juste de protéger les différents « observateurs » (utilisateurs) du Rollup que de protéger le « Rollup » lui-même. La sécurité du « Rollup » n’existe pas en tant que mesure spécifique unique.

Assurer la sécurité de l’observateur est bien sûr la chose la plus importante, car nous sommes tous des observateurs de la chaîne ! Cette chaîne est tout ce que disent ses observateurs. Si vous ne pouvez pas l’observer en toute sécurité, vous devez faire confiance à quelqu’un d’autre (comme un vérificateur) pour vous dire la « vérité » à ce sujet. Mais nous ne voulons pas faire confiance, nous voulons la vérification→ nous voulons des preuves.

Pour comprendre pourquoi il est important de faire la distinction entre « preuve de chaîne » et « observateur de chaîne de preuve », considérez ce qui suit :

• Nœuds de lumière - Les nœuds de lumière enroulables sont plus sûrs s’il y a des preuves, ils n’ont pas à faire confiance à la validité des mots de quelqu’un ;
• Nœud complet - s’il y a une preuve, la sécurité du nœud complet de Rollup n’augmentera ni ne diminuera, vous pouvez démarrer le Rollup (« cumul pessimiste ») sans pont intégré ni même aucune preuve, si vous commencez à envoyer une preuve de validité, la sécurité du nœud complet n’augmentera ni ne diminuera ;

Proven ajoute de la sécurité aux observateurs de chaîne (c’est-à-dire les nœuds légers) dont la validité ne peut pas être vérifiée directement. Nous ne voulons pas que les utilisateurs aient à exécuter des nœuds complets puissants, c’est pourquoi ces preuves sont importantes.

L’attestation sécurise le pont Rollup

Le pont de vérification de Rollup est un observateur extrêmement important ! Les preuves garantissent la sécurité du pont !

Comme pour n’importe quel nœud léger typique, le pont ne peut pas vérifier directement la validité du Rollup. Nous ne croyons pas aux majorités honnêtes, mais nous protégeons les ponts avec des preuves. Le protocole de consensus pour la base de données A (la couche DA) trie les objets blob de données, puis vérifie que le pont vérifie indépendamment la validité de la mise à jour correspondante de la base de données B (Rollup) :

Le pont est un observateur d’une autre chaîne, et chaque actif qu’il frappe porte toujours l’hypothèse de sécurité des règles de confirmation du pont correspondant. La sécurité de ses règles de confirmation peut avoir de vastes implications. C’est pourquoi il est si important de construire des ponts sécurisés (ou, idéalement, de réduire le besoin d’un si grand nombre de ponts en augmentant davantage l’exécution sur une seule chaîne).

Si vous exécutez des nœuds complets pour la chaîne, les parties malveillantes ne peuvent pas vous inciter à accepter des transitions d’état non valides. Cependant, si la partie malveillante a des règles de confirmation différentes, elle peut toujours usurper le pont. Si vous détenez des actifs adossés à des garanties dans le pont, vos fonds peuvent devenir non supportés. En ce sens, la défaillance de la sécurité du pont d’usurpation d’identité est « contagieuse ».

Considérons un vieux scénario hypothétique à propos de Terra :

• Terra a son propre ensemble de validateurs, son jeton natif est LUNA, et l’UST natif peut être émis ;
• Osmosis a son propre ensemble de validateurs, et son jeton natif est OSMO.
• Nous avons un pont IBC Terra ←→ Osmosis standard où chaque côté exécute le nœud léger du validateur de consensus de l’autre chaîne (c’est-à-dire que chaque côté du pont dépend d’une majorité honnête de l’ensemble de validateurs de l’autre chaîne) ;
• Vous exécutez votre propre nœud complet pour chaque chaîne en tant qu’utilisateur ;
• Nous nous référons à l’UST sur l’osmose pontée sur IBC sous le nom d’osmoUST ;
• Nous nous référons à OSMO sur Terra ponté via IBC sous le nom de terraOSO ;
• Vous possédez terraOSMO sur Terra ;
• Vous faites des LPs dans un pool osmoUST/OSMO sur Osmosis ;

Avec l’effondrement de Terra, le prix de LUNA s’effondre et, finalement, le profit de l’ensemble des validateurs qui devient théoriquement malveillant dépassera la valeur de la LUNA mise en jeu, et le validateur Terra peut signer des blocs invalides et faire ce qui suit :

• Mint faux UST → cross-chain to Osmosis to mint osmoUST, utilisez-le pour épuiser toutes les paires de trading osmoUST (par exemple, retirez tout OSMO du pool osmoUST/OSMO ;
• La création d’un faux terraOSMO → d’une chaîne croisée vers l’osmose pour retirer tous les supports OSMO natifs verrouillés sur Osmosis qui prennent en charge terraOSMO, tous les terraOSMO restants sur Terra ne seront désormais plus pris en charge ;
• Eh bien, la sécurité échoue ici :
• Nœud complet (moi) - mon nœud complet reconnaît les blocs Terra comme invalides et les rejette, les validateurs Terra ne peuvent pas voler mes positions terraOSMO ou osmoUST/OSMO LP ;
• Nœud léger (pont) - le pont vérifie simplement que le consensus de Terra est signé sur le bloc (ne vérifiant pas les transitions d’état valides) afin qu’il ne les rejette pas, les validateurs de Terra peuvent voler les garanties OSMO soutenant mon terraOSMO et drainer tout OSMO du pool osmoUST/OSMO (laissant un tas d’osmoUST sans valeur) ;

Le pont utilise des règles d’accusé de réception avec des hypothèses de confiance plus fortes.

Les validateurs de Terra ne peuvent pas voler de grandes quantités d’actifs de Terra à partir de nœuds complets (ils ne seront pas trompés), ils rejetteront ces blocs. Cependant, les validateurs peuvent tromper les validateurs de consensus en clients légers (y compris les ponts), c’est pourquoi les erreurs de consensus affectent les actifs inter-chaînes.

Notez qu’il est important que ces défauts n'« infectent » pas le reste de la chaîne, c’est-à-dire que le défaut « infecte » les actifs d’osmose exposés à la route du pont Terra, mais il n’y a pas de défaut de sécurité dans la chaîne d’osmose elle-même.

Cependant, nous voulons évidemment faire le pont (en général, la communication inter-chaînes), il serait mauvais de nous limiter à l’utilisation d’actifs natifs sur leur chaîne principale, nous avons besoin de chaînes pour communiquer en toute sécurité et faire le pont entre les chaînes.

À titre d’expérience de pensée, la solution la plus simple consiste à demander à chaque utilisateur d’exécuter des nœuds complets de chaque chaîne, ce qui inclut le pont inter-chaînes lui-même. Gardez à l’esprit que nous avons vu des ponts à nœud complet embarqués unidirectionnels :

• Les cumuls Ethereum exigent actuellement que leurs nœuds exécutent des nœuds complets Ethereum, et ces cumuls partagent le consensus d’Ethereum ; Namada (une chaîne Tendermint distincte, pas une chaîne Rollup) exigera de ses nœuds qu’ils exécutent des nœuds complets Ethereum, mais Namada n’est pas d’accord avec le consensus d’Ethereum (c’est-à-dire qu’il ne publie pas de données sur Ethereum ou ne dérive pas son état sur cette base) ;

Cela fonctionne pour les nœuds complets Ethereum, mais cela n’est évidemment pas évolutif. Vous ne pouvez pas commencer à avoir chaque chaîne Cosmos qui a juste besoin d’exécuter des nœuds complets pour toutes les autres chaînes Cosmos. Ces ponts bidirectionnels à nœud complet ne sont pas évolutifs, ils ne font qu’augmenter les exigences matérielles.

Heureusement, il existe une option plus évolutive. Nous pouvons déployer des ponts pour vérifier pleinement la validité de l’état et l’AD d’une autre chaîne (en plus de toujours vérifier le consensus).

Validité de l’état - Bien que l’IBC soit actuellement utilisé avec la preuve traditionnelle de consensus, il peut être modifié pour ajouter une preuve de validité pour les chaînes de connexion, et désormais les ponts ne sont pas usurpés par des transitions d’état non valides. Cela aurait empêché exactement l’attaque décrite précédemment, et si le pont avait été en mesure de vérifier la validité de la transition d’état, il aurait rejeté le bloc du validateur Terra comme invalide.

Cela ressemble beaucoup à la façon dont le pont Rollup sur Ethereum vérifie les preuves Rollup, sauf qu’il peut également être bidirectionnel.

DA - En outre, une chaîne peut exiger de ses nœuds qu’ils exécutent des nœuds légers DAS qui connectent la chaîne. Par exemple, vous pouvez avoir deux chaînes Cosmos qui nécessitent leurs propres validateurs pour exécuter les nœuds légers DAS de l’autre chaîne (si chaque chaîne implémente des clients légers DAS, qui ne sont pas actuellement pris en charge). Une fois que cela est fait, chaque chaîne peut maintenant connaître la validité et l’AD de l’autre sans avoir à exécuter des nœuds complets.

Pour le cumul, par définition, vous possédez toutes les données de la chaîne principale, de sorte que le pont qui s’y trouve peut y accéder. Les nœuds de cumul, quant à eux, exécutent les nœuds de la chaîne principale.

Chaînes dépendantes et indépendantes

Examinons à nouveau nos cinq attributs de sécurité, maintenant dans le contexte de l’observation du pont de vérification Rollup de Rollup sur Ethereum :

• Croissance du registre - Les validateurs Ethereum peuvent forcer le grand livre de Rollup à continuer de croître (par exemple, forcer les transactions d’inclusion) ;
• Résistant à la censure - Les validateurs d’Ethereum peuvent forcer les opérateurs de Rollup à ne pas censurer indéfiniment (par exemple, forcer l’inclusion de transactions ou la substitution de séquenceurs) ;
• Anti-restructuration - L’anti-restructuration de Rollup est liée à Ethereum. Si Ethereum se réorganise, tous les rollups sur Ethereum seront regroupés ;
• Disponibilité des données - Le DA du Rollup est garanti car le Rollup est par définition dérivé des données confirmées par le consensus de la chaîne principale (où se trouve le contrat de Rollup), le Rollup et la chaîne principale partagent le consensus de fusion, le DA est une condition de validité d’Ethereum lui-même, donc si les données ne sont pas disponibles, alors le bloc Ethereum lui-même est invalide. Le pont peut accéder aux données de la chaîne principale sans ajouter d’hypothèses de confiance ;
• Validité de l’état - le contrat vérifiera la preuve de validité de la transition d’état du Rollup (ou attendra que la fenêtre de contestation soit passée), ce qui prouve que la mise à jour de l’état déclaré est un résultat valide de l’application du STF du Rollup sur les données correspondantes confirmées sur la chaîne principale ;

Notez que la sécurité d’un pont n’est pas seulement maximisée par des règles de confirmation très strictes pour des chaînes supplémentaires (par exemple, un pont de validateur complet vers une chaîne avec un ensemble de validateurs super fiables). Si le pont a les mêmes hypothèses de sécurité que la chaîne principale, vous pouvez obtenir le plus de sécurité lors de l’utilisation de ressources natives inter-chaînes.

Vitalik fournit un exemple illustratif utile :

« Vous transférez 100 ETH sur un pont sur Solana et obtenez 100 Solana-WETH, et Ethereum est attaqué à 51 %. L’attaquant dépose une partie de ses ETH dans Solana-WETH, puis reprend la transaction du côté d’Ethereum dès que le côté Solana la confirme. Le contrat Solana-WETH n’est plus entièrement pris en charge, et peut-être que vos 100 Solana-WETH ne valent plus que 60 ETH. Même avec un pont parfait basé sur ZK-SNARK validant pleinement le consensus, il est toujours vulnérable à une attaque à 51% comme celle-ci.

Par conséquent, il est toujours plus sûr de détenir des actifs natifs Ethereum sur Ethereum ou des actifs natifs Solana sur Solana que de détenir des actifs natifs Ethereum sur Solana ou des actifs natifs Solana sur Ethereum. Dans ce contexte, « Ethereum » fait référence non seulement à la chaîne sous-jacente, mais aussi à toute L2 appropriée construite sur celle-ci.

Si Ethereum est attaqué à 51 % et se rétablit, Arbitrum et Optimism se rétabliront également, donc même si Ethereum est attaqué à 51 %, les applications « cross-rollup » qui sauvent l’état sur Arbitrum et Optimism sont garanties de rester cohérentes. Si Ethereum n’avait pas été attaqué à 51 %, il n’y aurait aucun moyen de faire une attaque à 51 % sur Arbitrum et Optimism, respectivement. Par conséquent, il est toujours tout à fait sûr de détenir des actifs émis par Optimism, basé sur Arbitrum.

Vous pouvez remplacer Solana par n’importe quelle chaîne que vous voulez - même une chaîne hypothétique où vous surpassez un validateur Ethereum en termes de confiance, et fondamentalement, toutes les hypothèses de sécurité sont additives lorsque vous parlez de cross-chain d’actifs avec leur registre d’enregistrement (par exemple, ETH d’Ethereum), et il y a toujours la possibilité d’une réorganisation de la chaîne connectée ou d’une défaillance de l’activité.

Cependant, les chaînes avec consensus fusionné (c’est-à-dire les cumuls qui partagent le consensus de leur chaîne principale) peuvent contourner ces hypothèses de sécurité supplémentaires. Les ponts inter-chaînes entre ces différentes régions peuvent avoir la même activité finale et les mêmes propriétés anti-recombinaison que la chaîne principale elle-même. Le consensus partagé minimise les hypothèses de confiance inter-chaînes au sein de cette zone de sécurité partagée.

C’est à vous de décider quelles sont les hypothèses de sécurité raisonnables. En fait, il n’y a pas eu d’échec de consensus similaire entre les grandes chaînes. Ce serait évident et coûteux, mais il pourrait s’agir d’une hypothèse plus forte sur la connexion de chaînes plus faibles.

Il y a aussi quelques inconvénients à lier une chaîne Rollup à la chaîne principale. Comparons deux scénarios inter-chaînes, dans les deux cas, nous avons deux chaînes qui utilisent le pontage inter-chaînes bidirectionnel du validateur complet :

• Dépendance - la chaîne distante (c’est-à-dire Rollup) partage le consensus de la chaîne principale (c’est-à-dire la couche DA) et dérive son propre état des données de la chaîne principale, la chaîne distante doit bifurquer avec la chaîne principale et déterminer sa finalité en fonction de la chaîne principale ;
• Indépendant - Ces chaînes ont leur propre consensus indépendant, elles ne dérivent pas leur propre état sur la base de données sur d’autres chaînes. Ils ne partagent pas de relation entre la chaîne distante (c’est-à-dire le cumul) ←→ la chaîne principale (c’est-à-dire la couche DA). Ils ne se regroupent pas et ne dépendent pas de l’activité de l’autre ;
• Il est intéressant de noter que ceux-ci sont à la fois bons et mauvais :
• Mauvais - Réorganiser votre chaîne avec d’autres chaînes ou avoir des échecs d’activité peut sembler être un inconvénient à première vue, pourquoi ma chaîne a-t-elle des problèmes parce que votre chaîne est cassée ?
• Bon - si cette divergence cause de graves problèmes sur votre chaîne, il s’agit en fait d’un avantage important (par exemple, si vous avez un grand nombre d’actifs inter-chaînes de la chaîne source, elle sera réorganisée du point de vue de votre pont inter-chaînes, laissant des garanties non garanties), la chaîne et son pont inter-chaînes doivent être cohérents les uns avec les autres ;

De même, les blocages et la recherche excessive de rentes ont des effets positifs et négatifs potentiels, ce qui souligne pourquoi une couche de base neutre et résistante à la censure est si importante :

• Bon - Une bonne chaîne principale protège les utilisateurs de Rollup contre les opérateurs de Rollup qui leur soutirent trop de valeur, en appliquant des privilèges de sortie ;
• Mauvais - Les mauvaises chaînes arrière peuvent gonfler arbitrairement le prix et extraire cette valeur de Rollup et de ses utilisateurs eux-mêmes ;
• La preuve de soumission + l’exécution du DAS dans les deux sens au lieu de partager une chaîne principale commune présente également quelques inefficacités :
• Vous ne voulez pas exiger de votre nœud qu’il exécute un tas de nœuds légers DAS d’autres chaînes, et avoir à ajouter manuellement de nouvelles chaînes, l’exécution de DAS sur une énorme couche DA partagée est beaucoup plus efficace ;
• Il est inefficace pour chaque chaîne de vérifier la validité de nombreuses chaînes différentes, cependant, il est théoriquement possible d’agréger des preuves entre plusieurs chaînes afin que l’ensemble du cluster de la chaîne n’ait besoin de publier qu’une seule preuve pour la chaîne ;

Il y a des compromis et des avantages ici, mais gardez également à l’esprit qu’il existe une énorme dépendance du chemin en fonction de l’endroit où se trouvent les actifs intéressants, et si vous souhaitez utiliser un tas d’actifs natifs d’Ethereum (y compris ceux de son Rollup), il est logique d’enraciner votre chaîne dans Ethereum et ses ponts inter-chaînes.

En conclusion

« Sécurité de l’héritage des cumuls » est un bon raccourci, mais rappelez-vous que ce sont les points clés que nous voulons vraiment dire :

• Rollup paie un loyer à sa chaîne principale, telle qu’Ethereum, pour les ressources qu’il consomme (DA) ;
• Le cumul peut exposer des règles de confirmation avec des propriétés de sécurité jusqu’à la chaîne principale (c’est-à-dire que les utilisateurs peuvent obtenir les mêmes garanties de sécurité que lorsqu’ils opèrent sur la chaîne principale elle-même) ;
• Les utilisateurs obtiennent ces attributs de sécurité de la chaîne principale à la vitesse du consensus de la chaîne principale ;
• Si les utilisateurs de Rollup veulent être plus rapides que la confirmation fournie par la chaîne principale, ils peuvent utiliser des règles de confirmation, qui font des hypothèses de sécurité temporaires supplémentaires ;
• L’observateur (c’est-à-dire l’utilisateur) interagit avec le Rollup par le biais de règles de confirmation, et le pont de vérification avec l’hypothèse de moindre confiance est un tel observateur (facultatif mais très précieux) ;

Considérez maintenant les avantages du déploiement du cumul sur la chaîne d’intégration :

Sécurité de l’utilisateur - Que vous souhaitiez implémenter des ponts inter-chaînes ou non, les Rollups peuvent louer DA à sa chaîne principale et récupérer son consensus, ce qui permet à Rollup d’exposer les règles de confirmation qui correspondent à la chaîne principale à ses utilisateurs sans avoir à atteindre son propre consensus ;

Sécurité inter-chaînes - Le cumul peut créer un système inter-chaînes dans le domaine de sécurité partagé de la chaîne principale (c’est-à-dire la chaîne principale elle-même et son Rollup), et ses propriétés de sécurité sont comparables à celles de la chaîne principale elle-même.

Nous devrions voir qu’il s’agit en fait des deux faces d’une même médaille, et que le Rollup permet simplement à la chaîne de fournir des règles de confirmation, et que sa sécurité peut atteindre la sécurité de la chaîne principale. Les ponts inter-chaînes et les utilisateurs normaux sont des observateurs de chaînes avec des règles d’accusé de réception données. Les ponts sont peut-être les « observateurs » les plus importants de ces chaînes, car leur sécurité a de vastes implications.

Lorsque nous essayons de créer un système sécurisé, nous devons nous soucier de la sécurité des règles de confirmation données ainsi que de leur accessibilité. Si la plupart des observateurs (utilisateurs) qui interagissent avec ces chaînes sont hors de portée, les règles de confirmation de sécurité ne sont pas d’une grande aide.

Bien que nous associions aujourd’hui le DAS et les preuves de validité au Rollup, il s’agit de concepts logiquement distincts. N’importe quelle chaîne peut intégrer ces technologies, et la distinction entre ce qui est un cumul et ce qui n’en est pas commence à s’effondrer à la fin du jeu (c’est-à-dire que pour un seul cumul intégré, il peut avoir des couches DA et d’exécution logiquement séparées sous un seul protocole).

Cependant, les couches « rollup traditionnelles » et DA dominent clairement ces technologies de vérification et de mise à l’échelle aujourd’hui.