Récemment, on a constaté une tendance notable où un nombre croissant de dApps annoncent le lancement de leurs propres rollups. De plus, on observe une augmentation du nombre de rollups génériques qui s'apprêtent à être mis en service.

Les rollups génériques répondent aux problèmes de scalabilité d'Ethereum alors qu'il fait face à une augmentation des volumes de transactions et à la croissance des dApps. Ces solutions de couche 2 traitent plus de transactions hors chaîne, les sécurisant ensuite sur la chaîne principale, équilibrant la scalabilité avec la sécurité. Leur polyvalence prend en charge diverses dApps, éliminant le besoin de solutions de mise à l'échelle uniques pour chaque application.

Les rollups spécifiques à une application sont des solutions sur mesure qui répondent aux besoins uniques des applications individuelles. Ils offrent une vitesse accrue en optimisant le traitement des transactions pour des cas d'utilisation spécifiques. En termes de coûts, ils peuvent fournir une alternative plus efficace aux solutions génériques, surtout en cas de congestion du réseau. Leur caractéristique principale est la flexibilité. Contrairement aux solutions de couche 2 à usage général qui sont rigides et plus contraintes par la conception EVM consacrée, les rollups spécifiques à une application peuvent être personnalisés, ce qui les rend idéaux pour des applications comme les jeux qui nécessitent des précompilations spécifiques. De plus, ils permettent aux dApps de mieux capturer de la valeur, en offrant plus de contrôle sur l'économie des jetons et les flux de revenus.

Avec le consensus se formant autour de la prolifération des rollups, en regardant un an dans le futur où plusieurs rollups dominent le marché, le besoin d'une infrastructure robuste devient primordial. Cette infrastructure servira de "béton armé" d'un monde multi-rollup.

Cet article explorera quatre piliers fondamentaux qui façonneront l'avenir de l'écosystème multi-rollup :

1. Sécurité comme fondation : La couche de sécurité est la pierre angulaire de la confiance dans le monde décentralisé. Dans cette section, nous explorons le rôle vital qu'elle joue pour garantir l'intégrité des transactions de la couche 2, identifier les hypothèses de confiance et traiter les éventuels pièges de sécurité.
2. Équilibrer la personnalisation et l'interopérabilité : Parvenir à une interopérabilité transparente entre les divers rollups est essentiel pour un monde de blockchain modulaire. Dans cette section, nous plongeons dans les problèmes d'interopérabilité causés par une structure modulaire et discutons des solutions actuelles pour résoudre la fragmentation et promouvoir un écosystème cohérent.
3. Analyse des coûts : Réduire les coûts est crucial pour l'adoption plus large et la viabilité des rollups, car cela abaisse les barrières économiques par rapport à l'utilisation de contrats intelligents. L'efficacité des coûts dans les rollups est principalement obtenue en exploitant les économies d'échelle en s'agrégeant avec d'autres rollups pour partager les frais, et en adoptant la division du travail en déléguant certaines tâches à des prestataires de services externes.
4. Sécurité partagée: Une couche de sécurité partagée est essentielle car elle soulage le processus intensif en temps et en ressources de démarrage de la sécurité pour de nouveaux protocoles ou couches modulaires, garantissant une sécurité robuste comparable à des plates-formes établies comme Ethereum. De nombreuses solutions telles que Eigenlayer, Babylon, ICS de Cosmos et Mesh Security ont émergé, mettant en valeur une variété d'applications

Ensemble, ces quatre couches fourniront un plan complet pour l'infrastructure nécessaire pour soutenir un monde blockchain modulaire prospère et cohérent.

Sécurité comme fondation

Au cœur de tout système décentralisé se trouve la confiance et la sécurité. Leur absence mine la promesse même d'un écosystème sans confiance. C'est pourquoi la couche de sécurité est primordiale ; sans elle, les utilisateurs et la TVL sont en danger. Le déclin de Plasma et des Sidechains offre un récit de mise en garde. Autrefois perçus comme le sauveur de l'expansion d'Ethereum, ses problèmes, comme le "problème de disponibilité des données", ont érodé la confiance et ont conduit à sa popularité déclinante. C'est pourquoi la couche de sécurité devient la partie I de cet article.

Pour comprendre les subtilités des rollups et leurs vulnérabilités potentielles, il est essentiel de disséquer le cycle de vie d'une transaction de couche 2. En utilisant les rollups de contrats intelligents comme référence, plongeons dans chaque phase et identifions les hypothèses de confiance et les pièges de sécurité potentiels :

1. Soumission de TX via RPC :
   1. Trust Assumption: The RPC endpoint is reliable and secure. Users and dapps are now trusting rpc providers eg alchemy, infura, etc.
   2. Problème de sécurité : les utilisateurs pourraient être censurés par les fournisseurs rpc, par exemple infura et alchemy bloquant les demandes rpc à Gate.iotornardo cashLes fournisseurs de RPC pourraient être confrontés à des attaques DDOS, par exemple, ankr étant compromis viaHijack DNS.
   3. Solutions : Les fournisseurs de RPC, tels qu'Infura, poursuivent activement une feuille de route décentralisée. De plus, les utilisateurs ont la possibilité de choisir des solutions décentralisées comme le Pocket Network.
2. Le séquenceur ordonne la Tx, fournit des engagements doux: état non sécurisé
   1. Trust Assumption: Les utilisateurs s'attendent à ce que les séquenceurs ordonnent équitablement les transactions et fournissent de véritables engagements souples.
   2. Préoccupation en matière de sécurité : le système doit résister à la censure, garantissant que toutes les transactions sont traitées sans parti pris. Il est crucial que le système reste opérationnel en continu, et il serait préférable de se protéger contre les séquenceurs qui obtiennent de mauvaises MEV aux dépens de l'utilisateur final.
   3. Solutions :
      1. CR et vivacité :
         1. classement des solutions actuelles basé sur le CR et le niveau de vivacité (du plus bas au plus élevé) : séquenceur unique - POA - séquenceurs POS sans permission - séquenceurs partagés - Rollups basés sur l'agrégation (séquencés par l1)
            1. Notez que POA avec des autorités limitées sans prise en charge des transactions forcées peut avoir un CR inférieur à un séquenceur centralisé avec la transaction forcée activée.
            2. En ce qui concerne la vivacité, une autre mesure cruciale à prendre en compte est l'échec du proposant, qui se produit lorsque le proposant se déconnecte. Dans de tels cas, il est essentiel de s'assurer que les utilisateurs peuvent toujours retirer leurs fonds.
               1. Même si les séquenceurs censurent ou refusent de fonctionner, certains rollups permettent aux utilisateurs de soumettre directement leurs txs aux L1 par eux-mêmes, c'est-à-dire la trappe de sortie (la vivacité pour les txs forcés dépend de l'implémentation spécifique). Le problème est que cela pourrait être trop cher pour les utilisateurs aux fonds limités et que les utilisateurs pourraient s'attendre à une CR et une vivacité en temps réel.
               2. Certaines solutions de rollup, telles que Arbitrum et Fuel, offrent la possibilité à quiconque de devenir un proposant après un certain délai, c'est-à-dire s'auto-proposer.
               3. Vérifiez cet indicateur pour chaque rollup :https://l2beat.com/scaling/risk
         2. Plus de détails sur d'autres solutions différentes peuvent être consultés dans mon fil précédent : https://twitter.com/yuxiao_deng/status/1666086091336880128
      2. Protection MEV :
         1. Différentes solutions de confidentialité peuvent aider à protéger les utilisateurs contre le front-running ou le sandwiching car les informations sur les transactions sont cachées (aident également avec CR). Les méthodes associées pour cacher les informations sur les transactions incluent FCFS avec un mempool privé (ce que arbitrum et optimism implémentent actuellement), la solution TEE de SUAVE, le chiffrement seuil (shutter network travaille sur cela), etc. Plus la solution est sophistiquée, moins les calculs compliqués sur les transactions peuvent être effectués.

MEV Roast | Pools de mémoire chiffrés - Justin Drake (Fondation Ethereum) - YouTube

1. Notez que ce que nous voulons, c'est la protection de MEV, pas l'élimination de MEV. Recherche par @tarunchitrarésume deux principales directions pour réduire le MEV : réduire la flexibilité du mineur à réorganiser les transactions en imposant des règles d'ordonnancement et introduire un marché concurrentiel pour le droit de réorganiser, ajouter et/ou censurer les transactions. Cependant, l'article conclut que ni l'ordonnancement équitable ni les mécanismes économiques seuls ne peuvent atténuer efficacement le MEV pour toutes les fonctions de paiement. Il existe des limites inférieures sur la manière dont vous ne pouvez pas supprimer le MEV au-delà d'un certain point.
2. Le séquenceur exécute et publie un lot de transactions et des racines d'état sur la couche DA lorsqu'il est économiquement raisonnable; état sécurisé
   1. Hypothèse de confiance : les producteurs de blocs publient l'ensemble du bloc sur la couche DA afin que d'autres puissent les télécharger et les valider.
   2. Préoccupation en matière de sécurité : si une partie des données n'est pas disponible, le bloc pourrait contenir des transactions malveillantes cachées par le producteur de bloc. Même si le bloc contient des transactions non malveillantes, les cacher pourrait compromettre la sécurité du système. Il est très important que les séquenceurs aient des données tx disponibles, car le Rollup doit connaître l'état du réseau et les soldes des comptes.
   3. Solutions :
   4. Publier sur Ethereum est actuellement la solution la plus sûre mais la plus coûteuse (serait 90% moins chère après protodankshadring, mais même une augmentation de 10x du débit pourrait ne pas suffire pour les rollups) : les txs des rollups sont téléchargées et diffusées par tous les nœuds Ethereum. Comme Ethereum possède un grand nombre de nœuds qui répliquent et vérifient les données de transaction, il est très peu probable que les données disparaissent ou deviennent entièrement indisponibles.
      1. Après le danksharding, les nœuds Ethereum ne téléchargeront pas toutes les données tx, mais seulement des parties des données en utilisant le DAS et le KZG (similaire à la solution d'avail mentionnée ci-dessous)
      2. Sous le concept modulaire, il pourrait être plus efficace pour les rollups de poster des données de transaction à une couche DA qui est uniquement responsable de DA (La performance théorique d'Ethereum pourrait être légèrement inférieure car, en plus de DA, elle conserve toujours l'exécution de L1, voir la comparaison des performances entre eigenDA et Ethereum ci-dessous).

1. Les solutions DA modulaires actuelles présentent des compromis entre la sécurité et les performances. Il est difficile de comparer la sécurité de l'AD en utilisant une seule dimension :
   1. Avail et Celestia utilisent DAS pour garantir la disponibilité des données ; tant qu'il y a suffisamment d'échantillonnage, les données sont sécurisées. Les LC peuvent échantillonner et obtenir une garantie élevée de DA car l'indisponibilité des données serait facilement détectée et récupérée par de très petites portions de LC. Ceci n'est pas possible sans DAS. La décentralisation de la couche DA, c'est-à-dire le nombre de nœuds dans le réseau, détermine le niveau de sécurité et également la répartition des enjeux. EigenDA n'utilise pas DAS mais utilise un mécanisme de preuve de garde pour empêcher les restakeurs d'être paresseux, c'est-à-dire que les opérateurs de DA doivent régulièrement calculer une fonction qui ne peut être complétée que s'ils ont téléchargé toutes les données requises et sont pénalisés s'ils échouent à attester correctement aux blobs (pas besoin de stocker une fois que la preuve a été effectuée cependant).
   2. Assurez-vous que le processus de duplication des données, c'est-à-dire le codage d'effacement, est précis. EigenDA, Ethereum après 4844 et Avail utilisent des engagements kzg pour garantir la précision, mais ils sont intensifs en calcul. Celestia utilise des preuves de fraude. Les nœuds légers doivent attendre un bref intervalle avant de pouvoir confirmer qu'un bloc a été correctement encodé, le finalisant de leur point de vue. (*Celestia pourrait potentiellement passer à des preuves de validité si c'est une meilleure option de compromis)
   3. Sécurité économique de la couche DA (risques de réorg et de collusion) : dépend de la valeur misée dans la couche DA, =2/3 de la valeur misée dans Avail et Celestia
   4. Relayer l'attestation de la couche DA de la DA vers Ethereum. Si les données sont postées sur une autre couche DA alors que le contrat de règlement est toujours sur Ethereum, alors nous avons besoin d'un contrat de pont pour valider que la DA est disponible dans la couche DA pour le règlement final.
      1. Le blobstream de Celestia vérifie les signatures sur l'attestation DA de Celestia. L'attestation est une racine de Merkle des données L2 signée par les validateurs de Celestia attestant que les données sont disponibles sur Celestia. Cette fonctionnalité est disponible sur testneten ce moment.
      2. Avail utilise une approche optimiste pour vérifier l'attestation DA. Une fois que l'attestation est postée sur le contrat de pont sur Ethereum, une période d'attente commence pendant laquelle l'attestation est supposée être valide sauf contestation.
      3. Succinct travaille avec Avail et Celestia sur un pont d'attestation de données basé sur zk-SNARK, ce qui rend le processus d'attestation plus sécurisé et moins cher en vérifiant simplement la preuve zk.
      4. Pour EigenDA, le répartiteur divise et publie des tâches aux nœuds EigenDA, puis agrège les signatures d'entre eux et relaie les données à Ethereum
2. Règlement final : état finalisé
   1. Hypothèse de confiance 1:
      1. Les nœuds complets Rollup (un nœud qui peut calculer entièrement l'état sans se fier à d'autres preuves) peuvent finaliser le premier bloc Rollup valide à sa hauteur dès qu'il est publié sur la chaîne parente car ils ont les données nécessaires et les ressources de calcul pour vérifier rapidement la validité du bloc. Cependant, ce n'est pas le cas pour d'autres tiers tels que les clients légers, qui se fient à des preuves de validité, des preuves de fraude ou des protocoles de résolution des litiges pour vérifier l'état de manière décentralisée sans avoir besoin d'exécuter eux-mêmes une réplique complète de la chaîne.
   2. Préoccupation de sécurité 1:
      1. Pour les Rollups ZK, l1 vérifie le zkp et n'accepte que les racines d'état correctes. La difficulté réside principalement dans le coût et le processus de génération du zkp.
      2. D'autre part, les Rollups Optimistes dépendent de l'hypothèse qu'au moins une partie honnête soumettra rapidement une preuve de fraude pour contester toute transaction malveillante. Cependant, la plupart des systèmes actuels de preuve de fraude ne sont pas encore sans permission, et la soumission de preuves de fraude repose uniquement sur quelques validateurs.
   3. Solutions 1:
      1. Preuve de fraude sans permission activée par le protocole BOLD d'Arbitrum. La principale raison pour laquelle la preuve de fraude est actuellement autorisée est la préoccupation des attaques de retard :
         1. Pendant la période de défi, tous les validateurs autres que le demandeur peuvent lancer un défi. Le demandeur est alors tenu de défendre son affirmation contre chaque challenger individuellement, un par un. À la fin de chaque défi, la partie perdante perd sa mise.
         2. Dans une attaque par retard, une partie malveillante (ou un groupe de parties) peut empêcher ou retarder la confirmation des résultats vers la chaîne L1 en posant des défis et en perdant délibérément le litige et les enjeux)
         3. Le protocole de défi 𝐁𝐎𝐋𝐃 aborde cette question en garantissant des limites supérieures fixes sur les temps de confirmation pour le règlement des Rollups Optimistes en veillant à ce qu'une seule partie honnête dans le monde puisse gagner contre tout nombre de revendications malveillantes.
      2. La chaîne de témoins peut agir comme une tour de guet pour les nouveaux rollups optimistes afin de garantir qu'au moins une partie honnête contesterait un état invalide :
         1. Pour les rollups établis tels que Arbitrum et Optimism, il existe suffisamment d'incitations intrinsèques pour plusieurs fournisseurs tiers tels que des explorateurs, des services similaires à Infura et leur fondation pour surveiller l'état de la chaîne et soumettre une preuve de fraude lorsque cela est nécessaire. Cependant, les nouveaux rollups ou appchains pourraient manquer de ce niveau de sécurité.
         2. Witness Chain utilise un mécanisme d’incitation unique, la « preuve de diligence », qui garantit que les tours de guet (validateurs) sont constamment motivées à surveiller et à vérifier les transactions, en s’assurant que l’état soumis à la chaîne mère est correct. Ce mécanisme garantit que chaque tour de guet effectue sa due diligence puisque les récompenses qu’elle reçoit sont spécifiques et indépendantes pour chaque nœud. En d’autres termes, si une tour de guet découvre une prime, elle ne peut pas partager le paiement exact de l’incitation avec d’autres tours de guet, ce qui garantit que chaque nœud effectue sa vérification indépendante. De plus, Witness Chain offre de la flexibilité en permettant aux rollups de spécifier des exigences personnalisées, telles que le nombre de tours de guet et leur répartition géographique alimentée par une « preuve de localisation » - leur service indépendant. Cette flexibilité assure un équilibre entre sécurité et efficacité. \
            Le réseau Watchtower émerge également comme une nouvelle couche dans la pile rollup elle-même, fournissant une sécurité mutualisée à l'exécution utilisée par d'autres applications connexes - telles que la sécurité rollup elle-même, les protocoles d'interopérabilité, le service de notification et le réseau de gardiens, etc. Plus de détails seront lancés à l'avenir.
   4. Hypothèse de confiance 2:
      1. L'ensemble du processus de règlement pour les rollups de contrats intelligents est écrit dans un contrat intelligent sur L1. Le contrat intelligent sur la couche DA est censé être logiquement exact, sans bug et pas malveillamment mis à jour.
   5. Préoccupation de sécurité 2 : Les ponts et les mises à niveau des contrats intelligents sont contrôlés par des portefeuilles multi-sig. Le pont a la capacité de voler arbitrairement des fonds aux utilisateurs via une mise à niveau malveillante.
   6. Solutions 2 :
      1. L'idée la plus populaire aujourd'hui est d'ajouter des retards temporels qui permettent aux utilisateurs de sortir s'ils ne sont pas d'accord avec une mise à niveau prévue. Cependant, cette solution exige que les utilisateurs surveillent continuellement toutes les chaînes sur lesquelles ils ont des jetons au cas où ils auraient besoin de sortir un jour.
      2. La couche Beacon d'Altlayer peut agir comme une couche sociale pour les mises à niveau de tous les rollups qui lui sont consacrés. Les séquenceurs qui s'inscrivent pour faire fonctionner un rollup avec les validateurs du rollup de la couche Beacon peuvent bifurquer socialement le rollup, que le contrat de pont consacré sur Ethereum soit mis à niveau ou non.
      3. Rollups consacrés à long terme: le rollup consacré est l'objectif final de la feuille de route d'Ethereum depuis plusieurs années maintenant. À l'exception du pont de consécration/du vérificateur de preuve de fraude sur L1, le contrat de règlement est également consacré.
         1. Ethereum PSE travaille dans cette direction

En ce qui concerne les rollups souverains, la principale différence est que l'état de la chaîne est réglé par les nœuds complets de rollup au lieu du contrat intelligent consacré dans le L1. Une comparaison plus détaillée peut être consultée surhttps://www.cryptofrens.info/p/settlement-layers-ethereum-rollups

Il est important de noter que plus de sécurité ne signifie pas nécessairement de meilleures performances. En général, à mesure que les mesures de sécurité augmentent, il y a un compromis avec la scalabilité. Par conséquent, il est essentiel de trouver un équilibre entre les deux. En conclusion, les rollups offrent la flexibilité de sélectionner des niveaux variables d'hypothèses de sécurité en fonction des préférences individuelles. Cette adaptabilité est l'une des caractéristiques remarquables du monde modulaire, permettant une approche sur mesure pour répondre à des besoins spécifiques tout en maintenant l'intégrité du système.

Équilibrer la personnalisation et l'interopérabilité

C'est un adage bien connu dans le monde modulaire : "Modularisme, pas de maximalisme." Si les rollups ne peuvent pas interopérer de manière sécurisée et efficace, alors le modularisme ≠ le maximalisme mais = la fragmentation. Il est crucial de comprendre comment gérer l'interopérabilité entre différents rollups.

Revisitons d'abord comment les chaînes monolithiques parviennent à l'interopérabilité. En termes simples, elles réalisent des opérations inter-chaînes en vérifiant le consensus ou l'état de l'autre chaîne. Il existe différentes approches disponibles sur le marché, et les différences résident dans la personne responsable de la vérification (entités officielles, mécanismes multi-signatures, réseaux décentralisés, etc.) et dans la manière dont la vérification de la justesse est assurée (à travers des tiers externes, des garanties économiques, des mécanismes optimistes, des preuves zk, etc.). Pour une plongée plus profonde dans ce sujet, consultez mes articles de pont préférés :Réflexions sur l'interopérabilité.

Avec la montée de la modularisation, la question de l'interopérabilité est devenue plus complexe:

1. Problème de fragmentation :
   1. La prolifération des rollups devrait surpasser de manière significative le nombre de L1 car il est beaucoup plus facile d'atterrir sur un L2 que sur un L1. Cela pourrait-il conduire à un réseau hautement fragmenté ?
   2. Alors que les blockchains monolithiques offrent un consensus et un état cohérents pour une vérification simple, quel sera le processus de vérification pour les blockchains modulaires qui ont trois (ou peut-être quatre) composants distincts (DA, exécution, règlement et séquençage)?
      1. DA et la couche de règlement deviennent la principale source de vérité. La vérification de l'exécution est déjà disponible car les rollups fournissent intrinsèquement des preuves d'exécution. Le séquençage se produit avant la publication sur DA.
2. Problème extensible :
   1. À mesure que de nouveaux rollups sont introduits, la question se pose : pouvons-nous rapidement offrir des services de pont pour les accommoder ? Même si la construction d'un rollup est sans autorisation, vous pourriez avoir besoin de passer 10 semaines à convaincre d'autres personnes d'en ajouter un. Les services de pont actuels s'adressent principalement aux rollups et tokens grand public. Avec l'afflux potentiel de nombreux rollups, il y a une inquiétude quant à savoir si ces services peuvent évaluer et lancer efficacement des solutions correspondantes pour soutenir ces rollups émergents sans compromettre la sécurité et la fonctionnalité.
3. Problème d'expérience utilisateur :
   1. Le règlement final des rollups optimistes prend sept jours, ce qui est beaucoup plus long que les autres L1. Le défi consiste à résoudre le délai d'attente de sept jours pour les ponts officiels des rollups optimistes. La soumission de zkp prend également du temps car les rollups attendent généralement d'accumuler un grand lot de transactions avant de soumettre la preuve pour économiser sur les coûts de vérification. Les rollups populaires comme StarkEx publient généralement des preuves sur L1 seulement une fois toutes les quelques heures.
   2. Les données de tx des Rollups soumises à la couche DA/règlement auront un délai pour économiser des coûts (1 à 3 minutes pour les rollups optimistes et quelques heures pour les zk rollups comme mentionné ci-dessus. Cela doit être abstrait pour les utilisateurs qui ont besoin d'une finalité plus rapide et plus sûre.

La bonne nouvelle est qu'il existe des solutions émergentes à ces défis :

1. Problème de fragmentation :
   1. Alors qu'il y a une prolifération de rollups dans l'écosystème, il est à noter que la majorité des rollups de contrats intelligents partagent actuellement une couche de règlement commune, à savoir Ethereum. Les principales distinctions entre ces rollups résident dans leurs couches d'exécution et de séquençage. Pour parvenir à l'interopérabilité, ils doivent simplement vérifier mutuellement l'état final de la couche de règlement partagée. Cependant, le scénario devient légèrement plus complexe pour les rollups souverains. Leur interopérabilité est quelque peu difficile en raison de différences dans les couches de règlement. Une approche pour résoudre cela consiste à établir un mécanisme de règlement Peer-to-Peer (P2P), où chaque chaîne intègre directement un client léger de l'autre, facilitant la vérification mutuelle. Alternativement, ces rollups souverains peuvent d'abord se connecter à un hub de règlement centralisé, qui sert alors de conduit pour se connecter à d'autres chaînes. Cette approche centrée sur le hub rationalise le processus et garantit une interconnexion plus cohésive parmi les différents rollups (similaire à l'état de l'interopérabilité de Cosmos).

1. Outre Ethereum qui sert de l'un des centres de règlement, d'autres centres de règlement potentiels incluent Arbitrum, zkSync et StarkNet, qui agissent en tant que centres de règlement pour les L3s construits sur eux. La couche d'interopérabilité de Polygon 2.0 fonctionne également comme un hub central pour les rollups zk construits dessus.
2. En conclusion, bien que le nombre de rollups et de leurs variations augmente, la quantité de hubs de règlement reste limitée. Cela simplifie efficacement la topologie, réduisant le problème de fragmentation à quelques hubs clés. Bien qu'il y ait plus de rollups que d'altl1s, les interactions entre rollups sont moins compliquées que les interactions entre L1 car les rollups se situent généralement dans la même zone de confiance/sécurité.
3. Comment les différents centres de règlement interagissent les uns avec les autres peut faire référence à la façon dont les chaînes monolithiques actuelles interagissent les unes avec les autres, comme mentionné au début.

De plus, dans le but d'éliminer la fragmentation du côté utilisateur, certains Layer 2, comme ZKSync, ont intégré l'Abstraction de Compte native pour faciliter une expérience fluide de cross-rollup.

1. Problème extensible
   1. Hyperlane(fournir une sécurité modulaire pour les chaînes modulaires) et Catalyst(Liquidité inter-chaînes sans permission) sont nés pour résoudre le problème d'interopération sous permission.
      1. L'essence de Hyperlane est de créer une couche de sécurité standardisée qui peut être appliquée sur diverses chaînes, les rendant intrinsèquement interopérables.
      2. Catalyst est conçu pour offrir une liquidité sans autorisation pour les chaînes modulaires. Il agit comme un pont, permettant à toute nouvelle chaîne de se connecter à la liquidité et d'échanger avec des principaux hubs comme Ethereum et Cosmos de manière transparente.
   2. Les fournisseurs de SDK/RAAS Rollup offrent des services de pontage natif au sein de leur écosystème
      1. Maintenant, les nouveaux rollups sont principalement lancés via des SDK de rollup existants ou des services RAAS, ce qui les rend intrinsèquement interopérables avec d'autres rollups utilisant les mêmes services. Par exemple, pour l'infrastructure construite avec la pile OP, le niveau fondamental est une norme de pontage partagée, permettant le mouvement transparent des actifs entre tout ce qui partage le code source de la pile OP. Pour les rollups lancés via l'altlayer, ils sont tous consacrés à la couche beacon, qui agit comme un hub de règlement et garantit une interopérabilité sûre. Pour les rollups lancés via sovereign labs ou zksync, ils sont interopérables les uns avec les autres dès le départ, basés sur l'agrégation de preuves (sera expliqué plus tard).

Problème UE :

1. Avant de plonger dans cette partie, commençons par reconnaître les différents niveaux d'engagements et leur décalage temporel :

1. Certain parties are comfortable with stage1 soft commitments by l2, eg exchanges like Binance only wait for a certain number of Layer2 blocks to consider transactions as confirmed, without the need to wait for batch processing to be submitted to Layer12. Certain bridge providers like protocol hop would take as many blocks on the sending chain and determine finality based on L1 consensus (stage 2). For trust-minimized bridges and for users to withdraw the funds from l2-l1 using the official bridge, it might take too long (several hours & 7 days)

1. La réduction de l’étape 2 ou de l’étape 3 offrirait des avantages significatifs, offrant une garantie plus forte dans un délai plus court pour une expérience utilisateur plus sûre et plus rapide. De plus, la réalisation d’un pont minimisant la confiance a toujours été un objectif convoité, en particulier à la lumière des incidents de sécurité fréquents avec les ponts.
2. Réduire le temps de règlement final (7 jours pour les rollups optimistes et plusieurs heures pour les rollups zk), c'est-à-dire raccourcir la phase 3
   1. Hybrid Rollups (Preuve de fraude + ZK) : Cette approche combine les forces des preuves ZK et des rollups optimistes. Bien que la génération et la vérification des preuves puissent être gourmandes en ressources, elles ne sont exécutées que lorsqu'une transition d'état est contestée. Au lieu de publier une preuve ZK pour chaque lot de transactions, la preuve est calculée et publiée uniquement lorsqu'un état proposé est contesté, à l'instar d'un rollup optimiste. Cela permet une période de contestation plus courte, car la preuve de fraude peut être générée en une seule étape, et le coût des preuves ZK est évité dans la plupart des scénarios.
      1. Notamment, les agrégats SVM d'Eclipse et LayerN utilisent risc0 pour générer la preuve de fraude zk. Le Stack OP a apporté son soutien à Risc0 et Mina pour le développement de la preuve de fraude zk. De plus, Fuel a récemment introduit une méthode hybride similaire qui prend en charge plusieurs vérificateurs.
   2. Après avoir posté des données à la couche DA, vérifiez encore l'exécution pour augmenter le niveau de confiance - des exigences élevées, comme un nœud complet
      1. Lorsque le séquenceur regroupe les txs dans les couches DA des rollups optimistes, il garantit un ordre canonique et DA pour les txs de x-rollup. Par conséquent, la seule chose à confirmer est l'exécution : S1 == STF(S0, B1). Bien sûr, vous pouvez simplement exécuter un nœud complet (exigences élevées) pour vérifier la tx, mais ce que nous voulons vraiment, c'est réduire la latence pour les clients légers. Les réseaux de prouveurs comme @SuccinctLabset@RiscZeropeut confirmer l'état post-exécution en fournissant des preuves d'état succinctes. Cela fournit une confirmation robuste pour les dapps et les utilisateurs.
      2. Altlayer a une couche de balise entre les rollups et L1. Les séquenceurs de la couche de balise sont responsables du séquençage, de l'exécution et de la génération de la preuve de validité (POV). La POV permet aux vérificateurs de vérifier une transition d'état pour un rollup ultérieurement sans avoir accès à l'ensemble de l'état. Avec des vérificateurs décentralisés effectuant des vérifications périodiques, nous avons atteint une finalité de transaction très robuste. Pas besoin d'attendre 7 jours car les vérificateurs ont déjà effectué les vérifications nécessaires. En conséquence, la messagerie inter-chaînes est devenue plus rapide et plus sécurisée.
      3. EigenSettle garantit la vérification grâce à des mécanismes économiques. Les nœuds EigenLayer participants avec des enjeux effectuent les calculs pour garantir la validité de l'état et utilisent leur garantie pour soutenir leurs engagements. Tout montant inférieur à la somme des enjeux que ces opérateurs ont postée peut être considéré comme réglé en toute sécurité et permet l'interopérabilité soutenue économiquement.
   3. Vérification instantanée avec les cumuls ZK :
      1. Sovereign Labs et Polygon 2.0 adoptent une approche innovante pour atteindre une finalité rapide en contournant la couche de règlement. Au lieu d'attendre pour soumettre la preuve à Ethereum, nous pouvons instantanément diffuser les preuves zk générées à travers un réseau peer-to-peer et mener des opérations cross-chain basées sur les zkps propagés. Plus tard, nous pouvons utiliser la récursivité pour les consolider en une preuve en lot et la soumettre à la couche 1 lorsqu'elle devient économiquement viable.
         1. Ce n'est pas entièrement réglé cependant, nous devons encore faire confiance à l'agrégation correcte de la zkp. L'Aggregator de Polygon 2.0 peut être exploité de manière décentralisée, impliquant les validateurs de Polygon du pool de validateurs partagé, améliorant ainsi la vivacité du réseau et la résistance à la censure. Néanmoins, l'utilisation de cette méthode entraînera également un temps de finalité plus court car l'agrégation des zkps de plusieurs chaînes est certainement plus rapide que d'attendre suffisamment de zkps sur une seule chaîne.
      2. Les hyperchaînes de Zksync utilisent la méthode de superposition pour agréger zkp et atteindre une finalité plus courte. Contrairement à un règlement sur L1, les hyperchaînes peuvent régler leurs preuves sur L2 (devenir un l3). Cette approche facilite la messagerie rapide, car l'environnement économique de L2 permet une vérification rapide et économiquement viable.
         1. Pour améliorer davantage la scalabilité, nous pouvons remplacer le règlement de la couche 2 par un programme minimal nécessaire pour faire fonctionner la couche 3 avec la messagerie. Ce concept a été étayé par des preuves spécialisées permettant l'agrégation.
3. Traitement du délai de publication dans la couche DA (certains méthodes peuvent également être appliquées pour réduire la période de règlement), c'est-à-dire raccourcir la phase 2
   1. Couche de séquençage partagée : Si les rollups partagent une couche de séquençage (par exemple, via un service de séquenceur partagé ou en utilisant le même ensemble de couches de séquençage), ils peuvent obtenir une confirmation douce du séquenceur. Cela, combiné à un mécanisme économique, garantit l'intégrité de l'état final. Les combinaisons possibles incluent :
      1. Le séquenceur partagé sans état + le constructeur garantit l'exécution en misant proposé par Espresso; Cette approche est plus adaptée aux rollups avec une structure PBS, en supposant que le constructeur de blocs a déjà les droits nécessaires sur certaines parties des blocs. Étant donné que le constructeur a un état et sert de rôle d'exécution sous-jacent pour les séquenceurs partagés, il est naturel qu'il fasse des promesses supplémentaires.
      2. Séquençage de validité partagée proposé par la recherche Umbra : séquenceur partagé étatique + preuve de fraude pour garantir un bon comportement. Les séquenceurs acceptent les demandes de chaînes croisées. Pour éviter les comportements malhonnêtes des séquenceurs, un mécanisme de preuve de fraude partagée est utilisé, impliquant de légères modifications au mécanisme de preuve de fraude original du rollup. Pendant la période de contestation, les contestataires vérifieraient également l'exécution correcte des actions atomiques. Cela peut impliquer la vérification des racines des contrats de pontage sur différents rollups ou l'examen de la preuve de Merkle fournie par les séquenceurs. Les séquenceurs malhonnêtes sont pénalisés.
   2. Intervention de tiers : des entités externes telles que Hop, Connext et Across peuvent intervenir pour atténuer les risques. Ils valident les messages et fournissent le capital pour les activités financières inter-chaînes des utilisateurs, réduisant ainsi efficacement la période d'attente. Par exemple, Boost (GMP Express) est une fonctionnalité spéciale d'Axelar et de Squid qui réduit le temps de transaction entre les chaînes à 5-30 secondes pour les échanges d'une valeur inférieure à 20 000 USD.
   3. Infrastructure d'intention pour le pontage en tant que forme spécifique d'intervention tierce : cette infrastructure repensée peut accueillir davantage de tiers pour intervenir et résoudre les intentions inter-domaines pour les utilisateurs.
      1. Grâce à une architecture axée sur l'intention (éliminant les frictions et la complexité des utilisateurs en impliquant des acteurs sophistiqués tels que les MMs et les constructeurs), les utilisateurs transmettent leur objectif ou leur résultat souhaité sans détailler les transactions précises nécessaires pour le réaliser. Les individus ayant une tolérance élevée au risque peuvent intervenir, fournir le capital nécessaire et percevoir des frais accrus.
      2. Il est plus sûr car les fonds des utilisateurs ne seraient libérés que lorsque le résultat est valide. Il pourrait être plus rapide et plus flexible car plus de parties (solvants) sont impliquées de manière permissionless dans le processus de résolution et rivalisent pour offrir un meilleur résultat aux utilisateurs.
      3. UniswapX, flashbots’ SUAVE, and essential are all working in this direction. More on intents: \
         nft://10/0x9351de088B597BA0dd2c1188f6054f1388e83578/?showBuying=true&showMeta=true
      4. L'aspect difficile de cette solution tourne autour de l'oracle de règlement. Prenons UniswapX comme exemple. Pour faciliter les échanges inter-chaînes, nous nous appuyons sur un oracle de règlement pour déterminer quand libérer les fonds aux solveurs. Si l'oracle de règlement opte pour le pont natif (qui est lent), ou si un pont tiers est utilisé (suscitant des inquiétudes en matière de confiance), ou même s'il s'agit d'un pont Light Client (pas encore prêt à être utilisé), nous nous retrouvons essentiellement dans la même boucle qu'auparavant. Ainsi, UniswapX propose également des "échanges inter-chaînes rapides" similaires à un pont optimiste.
      5. Simultanément, l'efficacité de la résolution des intentions repose sur la concurrence entre les solveurs. Comme les solveurs doivent rééquilibrer leur inventaire à travers différentes chaînes, cela pourrait potentiellement entraîner des problèmes de solveurs centralisés, limitant ainsi le plein potentiel des intentions.

Pour résumer, on peut observer qu'il existe trois façons de résoudre les problèmes de l'UE :

1. Utilisez la magie de zk :
   1. Le défi principal réside dans les performances de la technologie zk, englobant à la fois le temps nécessaire à la génération et les coûts associés. De plus, lorsqu'il s'agit de blockchains modulaires hautement personnalisables, la question se pose : possédons-nous un système de preuve zk capable d'accommoder la myriade de différences ?
2. Utilisez un schéma de réduction économique pour garantir :
   1. Le principal inconvénient de cette approche est le retard inhérent à la méthode décentralisée (par exemple, dans le cas d'EigenSettle, nous devons attendre que le plafond soit atteint). De plus, l'approche centralisée offre des engagements limités (comme l'illustre la séquence partagée), en s'appuyant sur les constructeurs/séquenceurs pour prendre des engagements, qui peuvent être restreints et manquer d'extensibilité.
3. Faites confiance à un tiers :
   1. Bien que faire confiance à un tiers puisse introduire des risques supplémentaires, car les utilisateurs doivent avoir confiance dans le pont, les échanges inter-domaines activés par l'intention représentent une forme quelque peu plus "décentralisée" de pont tiers. Cependant, cette approche doit encore faire face à la latence des oracles, aux problèmes de confiance et aux retards potentiels, car vous devez attendre que quelqu'un accepte votre intention.

Il est intéressant que la modularisation introduise également de nouvelles possibilités pour les expériences d'interopérabilité :

1. Vitesse améliorée avec des composants modulaires : En se décomposant en modules plus fins, les utilisateurs peuvent obtenir des confirmations plus rapides au niveau de la couche 2 (peut déjà être suffisamment sécurisé pour les utilisateurs ordinaires)
2. Séquenceur partagé pour les transactions atomiques : Le concept d'un séquenceur partagé pourrait potentiellement permettre une nouvelle forme de transactions atomiques, telles que les prêts flash. Plus de détails sur : https://twitter.com/sanjaypshah/status/1686759738996912128

Les solutions d'interopérabilité modulaire connaissent une croissance rapide, et actuellement, il existe différentes approches, chacune ayant ses propres forces et faiblesses. Peut-être que la solution ultime est encore loin, mais il est encourageant de voir autant de personnes s'efforcer de créer un monde modulaire plus sûr et connecté avant l'explosion des rollups.

Analyse des coûts

Un facteur contribuant au nombre limité de rollups en existence est la considération économique associée à leur lancement, par rapport à l'utilisation de contrats intelligents. Fonctionnant via des contrats intelligents adopte un modèle de coût plus variable, où la dépense principale est la frais de gaz, tandis que le lancement et la maintenance d'un rollup entraîne à la fois des coûts fixes et variables. Cette dynamique de coût suggère que les applications avec un volume de transactions substantiel ou des frais de transaction relativement élevés sont mieux positionnées pour tirer parti des rollups, car elles ont une plus grande capacité à amortir les coûts fixes impliqués. En conséquence, les initiatives visant à réduire le coût associé aux rollups, à la fois fixes et variables, sont primordiales. Plonger dans les composants de coût des rollups, tels qu'élucidés par Neel et Yaoqi lors de leur intervention à l'ETHCC, fournit une image plus claire:

En utilisant un modèle financier, comme l'analyse des flux de trésorerie actualisés (DCF), peut être essentiel pour évaluer la viabilité du lancement d'un rollup pour une application. La formule :

DCF(Revenue - Expenses)>Investissement Initial

sert de référence pour déterminer si le revenu opérationnel dépasse l'investissement initial, rendant ainsi le lancement d'un rollup une décision financièrement judicieuse. Les protocoles qui réussissent à réduire les coûts opérationnels tout en augmentant les revenus sont essentiels pour encourager l'adoption accrue des rollups. Explorons un par un :

1. Frais initiaux de développement et de déploiement
   1. La configuration initiale, malgré la disponibilité de SDK open source tels que Opstack et Rollkit, demande toujours une quantité importante de temps et de capital humain pour l'installation et le débogage. Les besoins de personnalisation, par exemple, l'intégration d'une machine virtuelle dans un SDK, augmentent encore les ressources nécessaires pour aligner la machine virtuelle sur les différentes interfaces fournies par chaque SDK.
   2. Les services RAAS comme AltLayer et Caldera peuvent considérablement atténuer ces complexités et efforts, encapsulant les avantages économiques de la division du travail.
2. Frais/Renvenue récurrent
   1. Revenu （++++）
      1. Frais d'utilisateur
         1. = Frais de publication de données L1 + Frais d'opérateur L2 + Frais de congestion L2
         2. Bien que certains frais d'utilisateur puissent être compensés par des dépenses, il est vital de les examiner et de s'efforcer de les réduire, car les rollups pourraient devenir intenables si les frais d'utilisateur sont prohibitivement élevés pour les utilisateurs. (Exploré dans la section des dépenses)
      2. Valeur extractible par les mineurs (MEV) capturée
         1. Principalement liée à la valeur des transactions provenant de la chaîne, celle-ci peut être augmentée soit en améliorant l'efficacité de l'extraction de la MEV, soit en augmentant la MEV inter-domaines.
         2. En partenariat avec des chercheurs établis, en utilisant une enchère PBS pour favoriser la concurrence, ou en tirant parti de la construction de blocs de SUAVE en tant que service sont des stratégies viables pour optimiser l'efficacité de capture de la MEV.
         3. Pour capturer plus de MEV inter-chaînes, l'utilisation d'une couche de séquenceur partagée ou SUAVE (mempool partagé et construction de blocs partagée) est bénéfique car elles se connectent à plusieurs domaines.
            1. Selon recherches récentespar Akaki, les séquenceurs partagés sont précieux pour les chercheurs d'arbitrage visant à saisir les opportunités d'arbitrage à travers différentes chaînes, car ils garantissent la victoire dans des courses simultanées sur toutes les chaînes.
            2. SUAVE sert de couche d’agrégation de flux d’ordres multi-domaines, aidant le constructeur/chercheur à explorer le MEV inter-domaines.
   2. Dépenses （- - - -)
      1. Frais d'exploitation de la couche 2 (L2)
         1. Commande : Il peut être difficile de comparer les solutions de commande centralisées et décentralisées. La concurrence dans des solutions plus décentralisées comme la preuve d'efficacité peut aider à réduire les coûts en maintenant la marge de l'opérateur minimale et en incitant également à poster des lots le plus souvent possible. D'autre part, les solutions centralisées impliquent généralement moins de parties, ce qui peut simplifier le processus mais ne pas bénéficier des mêmes dynamiques de réduction des coûts.
         2. Exécution: C'est là que les nœuds complets utilisent des VM/EVM pour exécuter les modifications de l'état d'un Rollup en fonction des nouvelles transactions d'utilisateurs.
            1. L'efficacité peut être renforcée grâce à des alt-VM optimisées comme Fuel et la VM Solana d'Eclipse, qui permettent une exécution parallèle. Cependant, s'écarter de la compatibilité EVM pourrait introduire des frictions pour les développeurs et les utilisateurs finaux, ainsi que des problèmes de sécurité potentiels. La compatibilité du Stylus d'Arbitrum avec à la fois EVM et WASM (qui est plus efficace que EVM) est louable.
         3. Prouver
            1. Marché Prover
               1. Théoriquement, l'utilisation d'un marché de prouveurs spécialisé comme Risc0, =nil et marlin, au lieu de créer un réseau de prouveurs centralisé ou décentralisé propriétaire, peut entraîner des économies de coûts pour plusieurs raisons :
                  1. Il peut y avoir un niveau plus élevé de participation sur un marché de prover dédié, ce qui favorise à son tour une concurrence accrue, entraînant finalement des prix plus bas.
                  2. Les validateurs peuvent optimiser l'utilisation du matériel et être réaffectés lorsque une application spécifique ne nécessite pas la génération immédiate de preuves, réduisant ainsi les coûts d'exploitation et offrant un service moins cher.
                  3. Naturellement, il y a des inconvénients, y compris la capture potentiellement moins d'utilité de jeton et en comptant sur la performance d'une tierce partie. De plus, des rollups zk distincts peuvent imposer des prérequis matériels variés pour le processus de génération de preuves. Cette variabilité pourrait poser un défi pour les prouveurs cherchant à étendre leurs opérations de preuve.
                  4. plus sur le marché du prover et le réseau du prover : https://figmentcapital.medium.com/march%C3%A9s-de-preuve-d%C3%A9centralis%C3%A9s-et-infrastructure-zk-f4cce2c58596
      2. Couche 1 (L1) publication de données
         1. Opter pour une couche de disponibilité des données (DA) plus rentable que Ethereum ou même utiliser une solution DAC peut réduire considérablement les dépenses, bien que cela puisse entraîner une baisse potentielle de la sécurité (explorée plus en détail dans la couche de sécurité). Pour les jeux et les réseaux sociaux qui ont généralement une faible valeur mais une bande passante élevée, la scalabilité pourrait être un facteur plus important que la sécurité pour eux.
         2. Employer Ethereum en tant que couche DA permet de tirer parti du protodansharing et du dansharding pour atteindre une efficacité de coût. De plus, étant donné que les frais de publication du blob sont fixés par bloc, indépendamment de l'utilisation du blob par le rollup, il existe un besoin d'équilibre entre le coût et le délai : Alors qu'un rollup devrait idéalement publier un blob complet, un faible taux d'arrivée de transactions conduisant à occuper complètement un espace de blob entraîne des coûts de retard excessifs.
            1. Solutions potentielles : coût de publication de blob conjoint pour les petits rollups ;
      3. Frais de règlement L1
         1. Pour les rollups optimistes, le coût de règlement est relativement faible. Après bedrock, Optimism ne paie que ~5$ par jour à Ethereum;
         2. Pour le règlement zk, il est relativement coûteux pour la vérification zkp
            1. agrégation de preuve zk
               1. Selon le système de preuve sous-jacent, un rollup sur Ethereum peut dépenser entre 300 000 et 5 millions de gaz pour valider une seule preuve. Mais comme les tailles de preuve augmentent très lentement (ou pas du tout) avec le nombre de transactions, les rollups peuvent réduire leur coût par transaction en attendant d'accumuler un grand lot de transactions avant de soumettre une preuve.
               2. Les laboratoires souverains, la couche d'interopérabilité de polygon 2.0 mentionnée précédemment agrège des preuves provenant de plusieurs rollups, chaque rollup peut ensuite vérifier l'état de plusieurs rollups en même temps, ce qui permet d'économiser sur les coûts de vérification. La structure de superposition de Zksync combinée à l'agrégation de preuves réduit encore davantage les coûts de vérification.
               3. Néanmoins, cette méthode est la plus efficace lorsque deux domaines utilisent le même ZKVM ou un schéma de prouveur partagé (les hyperchaînes de zksync utilisent le même zkEVM avec des circuits zkp entièrement identiques) ; sinon, cela pourrait compromettre les performances.
                  1. Les laboratoires NEBRA apportent l'économie d'échelle et la composition de la vérification des preuves sur Ethereum. NEBRA UPA (Universal Proof Aggregator) agrège universellement des preuves hétérogènes afin que le coût de vérification puisse être amorti. UPA peut être utilisé pour composer des preuves provenant de différentes sources afin de permettre de nouveaux cas d'utilisation.

Pour résumer, les méthodes principales pour économiser sur les coûts de regroupement comprennent :

1. Co-agréger avec d'autres rollups pour partager les frais ou exploiter les économies d'échelle :
   1. Il est à noter que cette agrégation est également potentiellement cruciale pour atteindre l'interopérabilité. Comme mentionné précédemment, l'utilisation d'une couche ou d'un cadre congruent à travers divers rollups simplifie l'interaction entre eux, garantissant un échange d'informations sans heurts. Cette stratégie consolidée favorise une infrastructure de couche 2 plus intégrée et unifiée.
2. Déléguer certaines tâches à des prestataires de services externes, en capitalisant sur le principe de la division du travail.

À mesure que de plus en plus de rollups émergent (ce qui signifie que vous pouvez collaborer avec des parties supplémentaires pour diviser les frais) et que de plus en plus de fournisseurs de services Rollup proposent des services plus affinés (offrant une plus large sélection de fournisseurs amont matures), nous anticipons que les dépenses associées à l'établissement d'un Rollup vont diminuer.

Sécurité partagée

Si vous visez à atteindre un niveau équivalent de sécurité (à la fois économiquement et en termes de décentralisation) comme la chaîne source, déployez simplement un contrat intelligent ou un rollup de contrat intelligent. Si exploiter une partie de la sécurité fournie par la chaîne source est suffisant pour améliorer les performances, il existe actuellement plusieurs solutions de sécurité partagée à votre disposition.

Les solutions de sécurité partagées facilitent grandement le processus de démarrage de la sécurité de la plupart des protocoles ou couches modulaires qui nécessitent une sécurité initiale. Cela est très important pour un monde modulaire futur, car nous envisageons l'émergence de plus d'infrastructures/protocoles pour faciliter la fonctionnalité d'un monde modulaire et que davantage de parties d'un rollup deviennent modulaires, à l'exception de DA, de l'exécution, du règlement et du séquençage. Si un rollup utilise une certaine couche modulaire (comme DA) ou un service dont la sécurité n'est pas à la hauteur de celle d'Ethereum, la sécurité globale de l'ensemble de la chaîne modulaire pourrait être compromise. Nous avons besoin d'une sécurité partagée pour permettre une économie de services SAAS décentralisée et fiable.

La couche propre, l'ICS de Babylon et Cosmos et la sécurité en maillage d'Osmosis jouent un rôle essentiel en offrant une confiance décentralisée en tant que service à d'autres entités infrastructurelles.

1. Eigenlayer permet aux validateurs d'Ethereum de réaffecter leur $ETH mis en jeu pour sécuriser d'autres applications construites sur le réseau.
2. ICS de Cosmos permet au Cosmos Hub ("chaîne fournisseur") de prêter sa sécurité à d'autres blockchains ("chaînes consommatrices") en échange de frais.
3. Mesh Security, mis en avant par osmose, permet aux délégants de tokens (et non aux validateurs) de retaker leurs tokens stakés sur une chaîne partenaire au sein de l’écosystème. Cela permet un flux de sécurité bidirectionnel ou multilatéral, car différentes chaînes d’applications peuvent combiner leurs mcaps pour améliorer la sécurité globale.
4. Babylon permet aux détenteurs de BTC de mettre en jeu leurs BTC au sein du réseau BTC et de fournir une sécurité à d'autres chaînes POS en optimisant l'utilisation du langage de script Bitcoin et en utilisant un mécanisme cryptographique avancé

ICS et Mesh Security, tous deux intégrés à l'écosystème Cosmos, ont principalement pour objectif de faciliter l'emprunt inter-chaînes de sécurité. Ces solutions répondent principalement aux besoins de sécurité des appchains Cosmos, leur permettant de tirer parti de la sécurité d'autres chaînes au sein de l'écosystème. Plus précisément, cosmos hub ICS propose des chaînes cosmos qui ne souhaitent pas initialiser des ensembles de validateurs (sécurité répliquée), tandis que la sécurité en maillage exige que chaque chaîne ait son propre ensemble de validateurs, mais permet une plus grande possibilité de gouvernance de la chaîne.

D’autre part, Babylon présente une approche unique en libérant le potentiel latent des actifs inactifs des détenteurs de BTC sans déplacer le BTC hors de sa chaîne native. En optimisant l’utilisation du langage de script de Bitcoin et en intégrant des mécanismes cryptographiques avancés, Babylon offre une sécurité supplémentaire aux mécanismes de consensus d’autres chaînes avec des fonctionnalités intéressantes telles que des périodes de déliaison plus rapides. Les validateurs d’autres chaînes de points de vente avec BTC peuvent verrouiller leurs BTC sur le réseau Bitcoin et signer des blocs de point de vente avec des clés privées BTC. Des performances non valides telles que la double signature feraient fuiter la clé privée btc du validateur et brûleraient ses BTC sur le réseau bitcoin. Le staking de BTC serait lancé dans le 2e testnet de Babylone.

Alors que Babylon navigue dans les contraintes du manque de support de contrat intelligent de Bitcoin, les opérateurs d'Eigenlayer sur la plateforme Ethereum complète de Turing, Non seulement Eigenlayer offre une sécurité économique aux nouveaux rollups et chaînes, mais son environnement sur Ethereum permet également une gamme plus diversifiée de AVS. Selon l'article d'eigenlayer sur confiance programmable,la couche eigenlayer de sécurité peut en réalité être subdivisée en 3 types :

1. Confiance économique : Confiance des validateurs qui prennent des engagements et soutiennent leurs promesses par des enjeux financiers. Ce modèle de confiance assure la cohérence quel que soit le nombre de parties impliquées. Il doit y avoir des conditions de slashing objectives qui peuvent être soumises et vérifiées sur la chaîne et c’est généralement lourd pour les restakers.
2. Confiance décentralisée : la confiance résultant d'un réseau décentralisé exploité par des opérateurs indépendants et géographiquement isolés. Cet aspect met en avant la valeur intrinsèque de la décentralisation et permet des cas d'utilisation qui ne sont pas objectivement prouvables car la décentralisation accroît la difficulté de collusion. Pour utiliser la confiance décentralisée, il est généralement léger.
3. Confiance d’inclusion Ethereum : ayez confiance dans le fait que les validateurs d’Ethereum construiront et incluront vos blocs comme promis, ainsi que le logiciel de consensus qu’ils exécutent. Cela peut spécifiquement être validé par les validateurs d’Ethereum (et non par les restakers LST). Ils exécutent des side-cars logiciels pour effectuer des calculs supplémentaires et recevoir des récompenses supplémentaires.

Maintenant que nous sommes clairs avec le matériel de sécurité, à quoi pouvons-nous nous attendre ?

1. La sécurité ICS et le maillage abaissent les barrières de sécurité pour les chaînes d’applications cosmos telles que neutron, stride et axelar.
2. Eigenlayer peut s'intégrer dans de nombreuses solutions qui ont été mentionnées auparavant :
   1. Sécurité de cumul : réseau de relais ; tour de guet, séquençage, mev-protection, eigenDA
   2. interop rollup: eigensettle; bridges
   3. analyse des coûts : réseau prover
   4. plus à explorer, vérifiezhttps://www.blog.eigenlayer.xyz/eigenlayer-universe-15-unicorn-ideas/
3. Babylon exécute un testnet pour augmenter le niveau de sécurité des autres chaînes pos. Son premier testnet fournit un service d'horodatage pour ajouter une sécurité supplémentaire aux activités defi de grande valeur provenant de plusieurs chaînes cosmos comme akash, osmosis, juno, etc.

L'idée centrale derrière ces solutions de sécurité partagée est d'améliorer l'efficacité du capital des actifs mis en jeu ou illiquides en introduisant des responsabilités supplémentaires. Cependant, il est essentiel d'être vigilant quant aux risques supplémentaires lors de la recherche de rendements plus élevés :

1. Une complexité accrue introduit plus d'incertitudes. Les validateurs sont exposés à des conditions de réduction supplémentaires qui peuvent manquer de suffisamment de garde-boue, ce qui peut être précaire.
   1. Eigenlayer vise à résoudre ce problème en proposant la mise en place d'un comité de veto. Ce comité sert d'entité mutuellement fiable entre les stakers, les opérateurs et les développeurs de AVS. En cas de bug logiciel au sein de AVS, les stakers et les opérateurs ne seront pas pénalisés car le comité de veto peut voter un veto. Bien que cette approche puisse ne pas être intrinsèquement évolutive et pourrait être subjective si les AVS ne sont pas strictement alignés avec les cas d'utilisation basés sur des actions attribuables de manière fiable, elle peut néanmoins servir de moyen précieux pour initier une stratégie d'atténuation des risques au cours des premières étapes.
2. Une complexité accrue apporte également des charges supplémentaires. Il peut être accablant pour les validateurs moins expérimentés de déterminer quel service partager la sécurité. De plus, la période de configuration initiale peut comporter un risque accru d'erreurs. En outre, des mécanismes doivent être mis en place pour permettre aux validateurs et aux stakers moins familiers de la technologie de bénéficier de rendements plus élevés, à condition qu'ils soient prêts à accepter des risques relativement élevés, sans être limités par leurs capacités opérationnelles.
   1. Rio Network et Renzo travaillent tous deux à relever efficacement ce défi pour Eigenlayer en proposant une approche structurée pour sélectionner prudemment des opérateurs de nœuds sophistiqués et des services AVS pour des restakes potentiels, élevant les niveaux de sécurité et réduisant les barrières à l'entrée pour les participants.

De plus, à mesure que Eigenlayer gagne une plus large adoption, il pourrait potentiellement ouvrir de nouveaux horizons dans le domaine de la financiarisation de la sécurité. Cela pourrait faciliter la valorisation de la sécurité partagée et des diverses applications qui en découlent.

1. Une limitation qui est présentée à EigenLayer est sa capacité à mettre à l'échelle l'allocation de capital à son système en surpassant les opportunités de rendement en DeFi pour les mêmes actifs qu'il supporte (LSTs). EigenLayer commoditise la valeur de sécurité et cela ouvre la porte à de nombreuses primitives pour garantir cette valeur et fournir la possibilité aux restakers de à la fois restaker et participer à l'écosystème DeFi plus large.
   1. Le protocole Ion est un produit qui tente de le faire afin de développer la portée que le rééquilibrage peut avoir. Ion construit une plateforme de prêt sans tenir compte du prix qui est construite pour soutenir spécifiquement les actifs mis en jeu et remis en jeu en utilisant l'infrastructure ZK pour garantir le risque de réduction de niveau inférieur présent dans de tels actifs (systèmes de preuve d'état ZK + ZKML). Cela pourrait initier le début de la naissance de nombreux nouveaux primitives DeFi construits sur la valeur sous-jacente de la sécurité que EigenLayer commoditize, permettant ainsi à la capacité de rééquilibrage de se développer dans l'ensemble de l'écosystème.

Alors que nous nous tenons au seuil de transformations significatives, il est crucial d'adopter les principes de sécurité, d'interopérabilité et de rentabilité. Ces piliers guideront non seulement le développement de solutions blockchain plus évolutives et efficaces, mais ouvriront également la voie à un monde numérique plus interconnecté et accessible. Adopter ces changements avec clairvoyance et adaptabilité conduira sans aucun doute à des avancées révolutionnaires dans l'écosystème blockchain.

Avertissement：

1. Cet article est reproduit à partir de [miroir]. Tous les droits d'auteur appartiennent à l'auteur original [SevenX Ventures]. Si des objections sont soulevées concernant cette republication, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Avertissement de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.