SevenX Ventures : Quelles infrastructures de pointe sont nécessaires pour un monde multi-Rollup ?
TechFlow SélectionTechFlow Sélection
SevenX Ventures : Quelles infrastructures de pointe sont nécessaires pour un monde multi-Rollup ?
Cet article explorera en profondeur les quatre piliers fondamentaux qui façonneront l'avenir de l'écosystème multi-Rollup.
Dédié à des analyses Web3 approfondiesRédaction : Grace, SevenX
Un phénomène clair est apparu récemment : un nombre croissant de dApp annoncent le lancement de leur propre Rollup dédié. Par ailleurs, le nombre de Rollups généralistes sur le point d’être lancés ne cesse également d’augmenter.
Face à la croissance constante du volume des transactions et au nombre croissant de dApps, Ethereum fait face à des problèmes de mise à l'échelle. Les Rollups généralistes sont apparus comme une réponse à ce besoin. Ces solutions de couche 2 traitent les transactions en dehors de la chaîne principale puis enregistrent ces opérations de manière sécurisée sur la blockchain principale, équilibrant ainsi parfaitement évolutivité et sécurité. La polyvalence des Rollups permet de prendre en charge diverses dApps, chaque application n'ayant plus besoin d'une solution de mise à l’échelle unique.
Les Rollups spécifiques à une application (app-specific Rollups) constituent des solutions personnalisées répondant aux besoins uniques d’une seule application, améliorant ainsi la vitesse grâce à une optimisation du traitement des transactions pour des cas d’usage particuliers. En matière de coûts, ce type de Rollup peut offrir une alternative plus efficace, surtout précieuse en période de congestion réseau. Un atout majeur des Rollups réside dans leur flexibilité. Contrairement aux solutions généralistes de couche 2, souvent rigides et fortement limitées par la conception de l'EVM, les Rollups dédiés peuvent être adaptés précisément, ce qui les rend idéaux pour des applications telles que les jeux vidéo nécessitant des pré-compilations spécifiques. De plus, les Rollups permettent aux dApps de capter plus efficacement de la valeur, tout en exerçant un meilleur contrôle sur leur économie de jetons et leurs flux de revenus.
Alors que l'adoption généralisée de la technologie Rollup gagne en consensus, il devient crucial, à l’horizon de l’année à venir, de construire une infrastructure robuste agissant comme un « béton armé », car plusieurs Rollups domineront alors le marché.
Cet article explore en profondeur les quatre piliers fondamentaux qui façonneront l'avenir d'un écosystème multi-Rollup :
-
Sécurité fondamentale : La couche de sécurité constitue la pierre angulaire de la confiance dans un monde décentralisé. Nous examinerons ici le rôle crucial joué par cette couche dans l’intégrité des transactions de niveau 2, la définition des hypothèses de confiance et la gestion des risques de sécurité potentiels.
-
Équilibre entre personnalisation et interopérabilité : L’interopérabilité fluide entre différents Rollups est essentielle dans un monde de blockchains modulaires. Cette section abordera les défis posés par l’interopérabilité dans une architecture modulaire, ainsi que les moyens de résoudre la fragmentation pour construire un écosystème cohérent.
-
Analyse des coûts : Pour rendre les Rollups largement accessibles et viables, réduire les coûts est primordial, car cela diminue les barrières économiques comparé aux contrats intelligents. L’efficacité économique des Rollups s’obtient principalement de deux manières : en regroupant plusieurs Rollups pour partager les frais, réalisant ainsi des économies d’échelle, ou en externalisant certaines tâches vers des fournisseurs de services spécialisés, favorisant ainsi la division du travail.
-
Sécurité partagée : Une couche de sécurité partagée est indispensable car elle réduit le temps et les ressources nécessaires pour sécuriser de nouveaux protocoles ou couches modulaires, leur offrant une sécurité solide comparable à celle de plateformes matures comme Ethereum. De nombreuses solutions existent déjà, telles qu’Eigenlayer, Babylon, ICS de Cosmos ou encore Mesh Security.
Ces quatre dimensions dessinent ensemble un plan complet, propulsant le développement d’une infrastructure nécessaire à un monde blockchain modulaire prospère et cohérent.
Sécurité fondamentale
La confiance et la sécurité sont au cœur de tous les systèmes décentralisés. Sans elles, un écosystème sans confiance devient une eau sans source. La couche de sécurité est cruciale : sans elle, utilisateurs et valeur totale verrouillée (TVL) sont exposés à des risques. Plasma et les sidechains ont un temps été perçus comme la solution miracle pour la mise à l’échelle d’Ethereum, mais leur déclin nous a sonné l’alerte. Des problèmes comme la « disponibilité des données » ont sapé la confiance, entraînant la perte d’utilisateurs. C’est pourquoi cet article traite la couche de sécurité en premier lieu.
Pour comprendre la complexité des Rollups et leurs vulnérabilités potentielles, il est essentiel d’analyser le cycle de vie d’une transaction de niveau 2. Prenons l’exemple d’un Rollup basé sur contrat intelligent et examinons chaque étape, en identifiant les hypothèses de confiance et les risques de sécurité associés :
Soumission de la transaction via RPC :
-
Hypothèse de confiance : Le point d’accès RPC est fiable et sécurisé. Actuellement, les utilisateurs et dApps font confiance à des fournisseurs RPC comme Alchemy ou Infura.
-
Problèmes de sécurité : Les utilisateurs peuvent subir de la censure de la part du fournisseur RPC. Par exemple, Infura et Alchemy ont bloqué les requêtes RPC vers Tornado Cash. Les fournisseurs RPC peuvent aussi être victimes d’attaques DDOS, comme ANKR lors d’un détournement DNS.
-
Solutions : Des fournisseurs RPC comme Infura développent activement des feuilles de route vers la décentralisation. En outre, les utilisateurs peuvent opter pour des solutions décentralisées comme Pocket Network.
Le séquenceur trie les transactions et fournit un engagement préalable : état non sécurisé
-
Hypothèse de confiance : Les utilisateurs supposent que le séquenceur trie équitablement les transactions et fournit un engagement honnête.
-
Problèmes de sécurité : Le système doit résister à la censure, garantissant un traitement impartial de toutes les transactions. Il doit rester opérationnel en permanence, et idéalement empêcher le séquenceur de tirer un maximum de valeur extractible malhonnête (MEV) au détriment des utilisateurs finaux.
-
Solutions : Résistance à la censure (CR) et vivacité (Liveness) : Selon les critères de résistance à la censure et de vivacité, le classement actuel des solutions (du plus faible au plus fort) est le suivant : séquenceur unique → POA → séquenceur PoS sans permission → séquenceur partagé → Rollup basé sur la séquence de la couche 1. À noter que, par rapport à un séquenceur centralisé avec transaction forcée activée, un POA avec autorisations limitées et sans support de transaction forcée pourrait présenter une résistance à la censure moindre.
En ce qui concerne la vivacité, un autre indicateur clé est la panne du proposant (proposer failure), c’est-à-dire l’échec lorsque le proposant est hors ligne. Dans ce cas, il faut garantir que les utilisateurs puissent toujours retirer leurs fonds.
- Même si le séquenceur procède à la censure ou refuse de fonctionner, certains Rollups permettent aux utilisateurs de soumettre directement leurs transactions à la couche 1, soit une sortie d’urgence (la vivacité de la transaction forcée dépend de la mise en œuvre). Le problème est que cette approche peut être trop coûteuse pour les utilisateurs aux ressources limitées, qui souhaiteraient néanmoins disposer en permanence de CR et de vivacité.
- Certaines solutions Rollup, comme Arbitrum et Fuel, permettent à toute personne de devenir proposant après un certain délai, appelé auto-proposition.
- Consultez les indicateurs spécifiques à chaque Rollup.
-
Pour plus de détails sur d'autres solutions, voir mon précédent post.
Protection contre le MEV :
-
Différentes solutions de confidentialité aident à protéger les utilisateurs contre les attaques de front-running ou sandwich, car les informations des transactions sont masquées (ce qui contribue aussi à renforcer la CR). Parmi les méthodes de masquage : FCFS avec mempool privé (solution actuellement mise en œuvre par Arbitrum et Optimism), solution TEE de SUAVE, chiffrement seuil (technologie étudiée par Shutter Network), etc. Plus la solution est complexe, plus le calcul des transactions est simplifié.
-
Il convient de noter que notre objectif est de protéger contre le MEV, pas de l’éliminer complètement. La recherche de @tarunchitra résume deux grandes directions pour réduire le MEV : limiter la flexibilité du mineur à réordonner les transactions via des règles de tri imposées, ou introduire un marché concurrentiel pour le réordonnancement, l’ajout et/ou la censure des transactions. Toutefois, l’étude conclut qu’aucun mécanisme de tri équitable ou économique ne peut efficacement réduire le MEV pour toutes les fonctions de paiement. Dans certains cas, le MEV ne peut jamais être entièrement éliminé.
Lorsque cela est économiquement opportun, le séquenceur exécute, regroupe les transactions et publie la racine d’état sur la couche de disponibilité des données (DA) ; état sécurisé
-
Hypothèse de confiance : Le producteur de blocs publie l'intégralité du bloc sur la couche DA, accessible au téléchargement et à la vérification.
-
Problèmes de sécurité : Si une partie des données est indisponible, le bloc pourrait contenir des transactions malveillantes cachées par le producteur. Même si les transactions ne sont pas malveillantes, les cacher nuit à la sécurité du système. Le séquenceur doit avoir accès aux données des transactions, car le Rollup a besoin de connaître l’état du réseau et les soldes des comptes.
-
Solutions :
Actuellement, publier les données sur Ethereum est la solution la plus sûre mais aussi la plus coûteuse (après protodanksharding, cela coûtera 90 % de moins, mais même avec un débit 10 fois supérieur, cela reste insuffisant pour les Rollups). Tous les nœuds Ethereum peuvent télécharger et diffuser les transactions du Rollup. Comme Ethereum dispose d’un grand nombre de nœuds répliquant et validant les données, celles-ci sont difficiles à perdre ou à rendre totalement indisponibles.
- Après danksharding, les nœuds Ethereum ne téléchargeront pas toutes les données, mais utiliseront DAS et KZG pour n’en télécharger qu’une partie (similaire à la solution Avail décrite ci-dessous).
- Selon le concept modulaire, publier les données des transactions du Rollup sur une couche DA dédiée uniquement à la disponibilité des données serait plus efficace (la performance théorique d’Ethereum pourrait être légèrement inférieure, car en plus de la disponibilité des données, Ethereum conserve l’exécution de niveau 1, voir comparaison EigenDA/Ethereum ci-dessous).
Les solutions modulaires actuelles de disponibilité des données exigent un compromis entre sécurité et performance. Il est difficile d’évaluer la sécurité de la disponibilité des données selon une seule dimension :
- Avail et Celestia utilisent DAS pour garantir la disponibilité des données ; tant qu’un échantillonnage suffisant est effectué, les données sont sécurisées. Comme l’indisponibilité des données peut facilement être détectée et récupérée par une très petite fraction de clients légers, ceux-ci peuvent réaliser des sondages et assurer largement la disponibilité des données. Sans DAS, cela n’est pas possible. Le degré de 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 la répartition des intérêts. EigenDA n’utilise pas DAS, mais un mécanisme de preuve de garde pour empêcher les re-stakers de se relâcher. Autrement dit, l’opérateur DA doit régulièrement calculer une fonction, seulement réalisable après avoir téléchargé toutes les données nécessaires. S’il ne prouve pas correctement le blob, il est puni (mais n’a plus besoin de stocker après la preuve).
- Garantir l’exactitude du processus de réplication des données (code d’effacement). EigenDA, Ethereum post-EIP-4844 et Avail utilisent des engagements KZG pour assurer l’exactitude, mais cela nécessite beaucoup de calcul. Celestia adopte une conception basée sur des preuves de fraude (fraud-proof). Les nœuds légers doivent attendre un certain temps avant de confirmer qu’un bloc a été correctement encodé, achevant ainsi leur confirmation finale. (*Si les preuves d’efficacité sont un meilleur compromis, Celestia pourrait passer à ce modèle)
- Sécurité économique de la couche DA (risque de réorganisation et collusion) : dépend de la valeur stakée dans la couche DA, soit 2/3 de la valeur stakée dans Avail et Celestia.
- Transmettre la preuve de disponibilité des données de la couche DA à Ethereum. Si les données sont publiées sur une autre couche DA, mais que le contrat de règlement reste sur Ethereum, un pont contractuel est nécessaire pour vérifier que les données sont disponibles sur la couche DA afin de finaliser le règlement.
-- Blobstream de Celestia valide les signatures sur la preuve de disponibilité des données provenant de Celestia. Cette preuve est la racine Merkle des données de niveau 2 signées par les validateurs Celestia, attestant que les données sont disponibles sur Celestia. Cette fonctionnalité est déjà disponible sur le testnet.
-- Avail utilise une méthode optimiste pour valider la preuve de disponibilité des données. Une fois cette preuve publiée sur le contrat de pont d’Ethereum, une période d’attente commence, durant laquelle la preuve est considérée comme valide sauf contestation.
-- Succinct collabore avec Avail et Celestia pour développer un pont de preuve de données basé sur zk-SNARK, rendant le processus de vérification plus sûr et moins coûteux grâce à la validation de preuves zk.
-- Pour EigenDA, le disperser divise la tâche et la publie sur les nœuds EigenDA, puis agrège les signatures et transmet les données à Ethereum.
Règlement final : état définitivement confirmé
-
Hypothèse de confiance 1 :
Une fois le premier bloc Rollup valide publié sur la chaîne principale, les nœuds complets du Rollup (capables de calculer entièrement l’état sans dépendre d’autres preuves) peuvent le finaliser à leur hauteur, car ils disposent des données et des ressources nécessaires pour rapidement valider la validité du bloc. Cependant, ce n’est pas le cas pour d’autres tiers comme les clients légers. Ils doivent dépendre de preuves de validité, de preuves de fraude ou de protocoles de résolution de litige pour valider l’état sans confiance, sans exécuter indépendamment une copie complète de la chaîne.
-
Problème de sécurité 1 :
Pour les ZK Rollups, la couche 1 valide la preuve à connaissance nulle et n’accepte que la racine d’état correcte. La difficulté réside principalement dans le coût et le processus de génération de la preuve zk. En revanche, les Rollups optimistes reposent sur l’hypothèse qu’au moins une partie honnête soumettra rapidement une preuve de fraude pour contester toute transaction malveillante. Toutefois, la plupart des systèmes de preuve de fraude actuels ne sont pas sans permission, et seuls quelques validateurs soumettent ces preuves.
-
Solution 1 :
Preuve de fraude sans permission fournie par le protocole BOLD d’Arbitrum. La raison principale pour laquelle les preuves de fraude sont actuellement permises est de prévenir les attaques par retard :
- Pendant la phase de défi, tout staker autre que le proposant peut lancer un défi. Le proposant doit alors se défendre individuellement contre chaque challenger. À la fin de chaque tour de défi, la mise du perdant est confisquée.
- Dans une attaque par retard, une partie malveillante (ou un groupe) peut bloquer ou retarder la confirmation finale sur la chaîne de niveau 1 en lançant un défi et en perdant intentionnellement le litige et sa mise.
- Pour résoudre ce problème, le protocole de défi BOLD garantit qu’un seul acteur honnête peut vaincre un nombre quelconque de prétendants malveillants, assurant ainsi que le temps de confirmation des Rollups optimistes ne dépasse jamais une limite supérieure fixée.
Witness Chain peut servir de surveillant pour les nouveaux Rollups optimistes, garantissant qu’au moins un acteur honnête contesterait un état invalide :
- Des Rollups matures comme Arbitrum et Optimism ont suffisamment d’incitations internes pour inciter des fournisseurs tiers (navigateurs, services de type Infura, fondations) à surveiller l’état de la chaîne et à soumettre des preuves de fraude si nécessaire. Toutefois, de nouveaux Rollups ou chaînes d’applications peuvent ne pas bénéficier de ce niveau de sécurité.
- Witness Chain adopte un mécanisme d’incitation unique, la « preuve de diligence » (Proof of Diligence), garantissant que les surveillants (validateurs) ont toujours intérêt à surveiller et valider les transactions, assurant ainsi que l’état publié sur la chaîne principale est correct. Ce mécanisme garantit que chaque validateur fait son devoir, car la récompense qu’il obtient est spécifique et indépendante pour chaque nœud. Autrement dit, si un validateur découvre une prime, il ne peut pas la partager avec d’autres validateurs, assurant ainsi une validation indépendante de chaque nœud. De plus, Witness Chain permet aux Rollups de définir des exigences personnalisées (comme le nombre de validateurs et leur répartition géographique, soutenue par un « proof of location » via leurs services indépendants), offrant davantage de flexibilité pour équilibrer sécurité et efficacité.
* Le réseau Watchtower devient également une nouvelle couche dans la pile Rollup, offrant une sécurité complète pour l'exécution d'autres applications connexes (sécurité Rollup elle-même, protocoles d'interopérabilité, services de notification, réseaux keeper, etc.). Davantage de détails seront publiés prochainement.
-
Hypothèse de confiance 2 :
Tout le processus de règlement des Rollups basés sur contrats intelligents est codé dans un contrat intelligent de niveau 1. On suppose que la logique du contrat intelligent sur la couche de disponibilité des données est exacte, sans faille, et sans mise à jour malveillante.
-
Problème de sécurité 2 :
Le pont et les mises à jour des Rollups basés sur contrats intelligents sont contrôlés par un portefeuille multisignature. Le pont peut voler arbitrairement les fonds des utilisateurs via une mise à jour malveillante.
-
Solution 2 :
Actuellement, la solution la plus courante consiste à ajouter un délai temporel, permettant aux utilisateurs de sortir s'ils désapprouvent la mise à jour prévue. Toutefois, cette solution oblige les utilisateurs à surveiller constamment toutes les chaînes où se trouvent leurs jetons, au cas où ils devraient sortir.
La couche Beacon d’Altlayer peut servir de couche sociale pour tous les Rollups, leur fournissant un service de mise à jour. Que le contrat de pont sur Ethereum soit mis à jour ou non, le séquenceur du Rollup exécuté avec les validateurs de la couche Beacon peut provoquer un fork social du Rollup.
À long terme : les Rollups intégrés (Enshrined Rollup) restent depuis des années l’objectif ultime de la feuille de route d’Ethereum. En plus d’intégrer le pont / le vérificateur de preuve de fraude dans la couche 1, le contrat de règlement y est également intégré.
- L’équipe PSE d’Ethereum travaille dans cette direction.
Concernant les Rollups souverains, la différence principale est que l’état de la chaîne est réglé par les nœuds complets du Rollup, et non par un contrat intelligent dans la couche 1. Pour une comparaison plus détaillée, voir https://www.cryptofrens.info/p/settlement-layers-ethereum-rollups
Il convient de noter que l’amélioration de la sécurité n’implique pas nécessairement une amélioration des performances. Généralement, l’ajout de mesures de sécurité implique un compromis avec l’évolutivité. Ainsi, équilibrer ces deux aspects est crucial. En résumé, les Rollups offrent de la flexibilité, permettant de choisir différents niveaux d’hypothèses de sécurité selon les préférences individuelles. Cette adaptabilité est une caractéristique marquante du monde modulaire, permettant des solutions sur mesure pour des besoins spécifiques tout en préservant l’intégrité du système.
Équilibrer personnalisation et interopérabilité
Dans le monde modulaire, un adage bien connu veut que « modularisme plutôt que maximalisme ». Si les Rollups ne peuvent pas interagir de manière sécurisée et efficace, alors le modularisme devient fragmentation, pas maximalisme. C’est pourquoi il est impératif de résoudre l’interopérabilité entre différents Rollups.
Commençons par rappeler comment les chaînes monolithiques réalisent l’interopérabilité. En bref, cela passe par la vérification du consensus ou de l’état d’une autre chaîne pour exécuter des opérations inter-chaînes. Actuellement, diverses approches existent, variant selon qui est responsable de la vérification (entité officielle, mécanisme multisignature, réseau décentralisé, etc.) et selon la manière dont la vérification est garantie (via une tierce partie, garantie économique, mécanisme optimiste, preuve à connaissance nulle, etc.). Pour approfondir ce sujet, consultez mon article préféré sur les ponts : Thoughts on Interoperability.
Avec l’avènement du modularisme, le problème d’interopérabilité devient plus complexe :
Problème de fragmentation :
-
On s’attend à ce que le nombre de Rollups dépasse largement celui des chaînes de niveau 1, car déployer sur la couche 2 est nettement plus simple que sur la couche 1. Cela conduira-t-il à une forte fragmentation du réseau ?
-
Bien que les blockchains monolithiques offrent un consensus et un état cohérents permettant une vérification simple, comment le processus de vérification se déroulera-t-il si les blockchains modulaires comprennent trois (voire quatre) composants distincts (disponibilité des données, exécution, règlement et séquencement) ?
La couche de disponibilité des données et la couche de règlement deviennent les principales sources de données. Étant donné que le Rollup lui-même fournit une preuve d’exécution, la vérification d’exécution est déjà disponible. Le séquencement a lieu avant la publication sur la couche DA.
Problème d’évolutivité :
-
Avec l’introduction de nouveaux Rollups, une question surgit : pouvons-nous fournir rapidement des services de pont pour accueillir de nouveaux Rollups ? Même si la création de Rollups est sans permission, vous pourriez encore passer 10 semaines à convaincre d’autres acteurs d’ajouter un nouveau Rollup. Les services de pont actuels ciblent principalement les Rollups et jetons dominants. Avec l’afflux futur de nombreux Rollups, on craint que ces services puissent évaluer efficacement et déployer des solutions adaptées sans compromettre la sécurité ni les fonctionnalités.
Problème d’expérience utilisateur :
-
Le règlement final d’un Rollup optimiste prend sept jours, bien plus longtemps que sur d’autres chaînes de niveau 1. Le défi actuel est de résoudre l’attente de sept jours imposée par le pont officiel des Rollups optimistes. La soumission de preuves zk connaît également des retards, car les Rollups attendent généralement d’accumuler un grand lot de transactions avant de soumettre la preuve, afin de réduire les coûts de vérification. Des Rollups populaires comme StarkEx publient une preuve à la couche 1 toutes les quelques heures.
-
Pour réduire les coûts, les données de transaction des Rollups envoyées à la couche DA / règlement présentent un délai (comme mentionné, 1-3 minutes pour les Rollups optimistes, plusieurs heures pour les zk Rollups). Pour les utilisateurs ayant besoin de résultats finaux plus rapides et plus sécurisés, cela doit être abstrait.
La bonne nouvelle est que de nouvelles solutions émergent face à ces défis :
Problème de fragmentation :
-
Bien que le nombre de Rollups dans l’écosystème continue d’augmenter, il est important de noter que la majorité des Rollups basés sur contrats intelligents partagent actuellement une couche de règlement commune : Ethereum. Les principales différences entre eux concernent leur couche d’exécution et leur couche de séquencement. Pour assurer l’interopérabilité, ces Rollups n’ont
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@SevenXVentures
