Pourquoi les rollups basés sont-ils le seul avenir d'Ethereum ? 6 ans après qu'Ethereum a dévoilé sa feuille de route centrée sur les rollups, la vision fonctionne en grande partie : les frais de transaction sont en baisse, le débit est plus élevé et le modèle de sécurité de base est resté solide. 1. Cependant, l'interopérabilité reste un défi non résolu. À mesure que de plus en plus de rollups sont lancés, davantage d'utilisateurs, d'applications et de liquidités sont répartis à travers des environnements isolés. Au lieu d'un grand réseau Ethereum, nous obtenons des dizaines de petites îles. Des ponts les relient, mais ils ajoutent de la latence, des risques et des frictions. Cette fragmentation est aggravée par le fait que chaque rollup aujourd'hui fonctionne avec son propre séquenceur centralisé, le système qui décide de l'ordre des transactions dans un bloc, qui entre en premier et qui capture également les profits du MEV. Comme chaque séquenceur fonctionne de manière indépendante, les rollups fonctionnent sur des chronologies différentes. Les applications sur des rollups séparés ne peuvent pas interagir de manière atomique, dans le même bloc au même moment, ce qui fracture la liquidité et affaiblit la composabilité. 2. Les séquenceurs centralisés avaient du sens au début. Ils ont permis aux équipes de se lancer rapidement en mettant en place un serveur, ont réduit le front-running grâce à un flux d'ordres privé, ont fourni des pré-confirmations quasi instantanées pour une expérience utilisateur fluide et ont offert une flexibilité opérationnelle. Mais ces avantages ont eu des inconvénients. • Les temps d'arrêt des séquenceurs ont mis hors ligne des rollups entiers pendant des heures. • Un séquenceur compromis pourrait réorganiser les transactions et siphonner des millions. • Ils ne peuvent pas évoluer de manière neutre et décentralisée, ce qui cause un problème de fragmentation. Quand on additionne tout cela, les séquenceurs centralisés étaient un bon point de départ, mais ils ne peuvent pas amener les rollups là où ils doivent aller. 3. La prochaine étape est les rollups basés. Au lieu de fonctionner avec son propre séquenceur, un rollup basé utilise les validateurs de la couche 1 (Ethereum, Celestia) pour le séquençage (l'ordre des transactions). C'est pourquoi on l'appelle "basé" : son séquençage est directement lié à la couche de base. Ce changement restaure la neutralité. Aucune équipe de rollup individuelle ne contrôle le flux des transactions. Tous les rollups qui sont "basés" partagent la même couche de séquençage à l'échelle d'Ethereum, ce qui signifie qu'ils peuvent interagir dans le même bloc au même moment. Le résultat est un réseau unifié : • La liquidité reste concentrée plutôt que fragmentée à travers des silos. • La composabilité est synchrone, donc les applications sur différents rollups peuvent interagir de manière atomique. • Le contrôle est neutre, sécurisé par les validateurs d'Ethereum plutôt que par un serveur centralisé. 4. Quels autres problèmes les rollups basés résolvent-ils ? • DeFi : La liquidité reste unifiée sous la couche de séquençage d'Ethereum. Les échanges, prêts et liquidations se produisent sur les L2 mais partagent le même ordre de base, maintenant les marchés profonds et concentrés plutôt que fragmentés ou perdus au profit de Solana. • Utilisateurs : Les frontières des rollups s'estompent. Avec des contrats de dépôt partagés et des transferts natifs L2 à L2, les actifs se déplacent sans effort à travers les rollups — pas besoin de revenir par L1 ou de s'inquiéter de "quelle chaîne" vous êtes. • Développeurs : La composabilité revient. Les applications sur différents rollups peuvent interagir de manière atomique dans le même bloc, permettant des prêts, échanges et stratégies complexes inter-rollups que les séquenceurs centralisés ne peuvent pas supporter. 5. Les séquenceurs partagés ne font-ils pas la même chose ? Ces 2 approches résolvent la fragmentation à des échelles très différentes. Les stacks de rollups comme Arbitrum Orbiy, Optimism Superchain et zkSync Elastic Chain expérimentent avec des séquenceurs partagés qui agissent comme des mini-hubs. Ainsi, la liquidité et les utilisateurs restent piégés à l'intérieur de ce cluster d'écosystème, plutôt que d'être partagés à travers Ethereum dans son ensemble. Les rollups basés vont plus loin. Au lieu de hubs au niveau de l'écosystème, ils utilisent Ethereum lui-même comme le séquenceur universel. Cela signifie que les pools de liquidité fusionnent à travers tous les rollups. Les séquenceurs partagés réduisent la fragmentation localement, tandis que les rollups basés la résolvent globalement à travers l'ensemble du réseau Ethereum. 6. Ethereum est essentiellement devenu un séquenceur, mais comment ? Pendant la majeure partie de son histoire, Ethereum ne pouvait séquencer que ses propres transactions. Les validateurs rassemblaient les transactions du mempool, les ordonnaient et construisaient des blocs. Si chaque rollup avait déversé ses transactions directement dans ce processus, le résultat aurait été le chaos : conflits, espace de bloc gaspillé et transactions échouées. La percée est venue avec la séparation des proposeurs et des constructeurs (PBS). Avant PBS : Les validateurs devaient tout faire, collecter les transactions, les ordonner et construire le bloc. Ajouter le trafic des rollups aurait été écrasant. Avec PBS : Le travail est divisé. • Les validateurs (proposeurs) signent simplement des blocs, tandis que des constructeurs spécialisés font le gros du travail. • Les constructeurs rassemblent les transactions (d'Ethereum et des rollups basés), les ordonnent et produisent des blocs complets. • Les validateurs signent uniquement l'en-tête du bloc le plus précieux, sans même avoir besoin de voir son contenu. Du point de vue du validateur, rien n'a changé, mais en pratique, Ethereum est devenu le séquenceur neutre pour chaque rollup basé. 7. Mais qui capture le MEV dans le "monde basé" ? Le MEV, le profit provenant de l'ordre des transactions, qui autrefois allait à un séquenceur centralisé, va maintenant dans le pipeline PBS d'Ethereum. Les constructeurs assemblent des blocs rentables, les validateurs les signent, et le MEV est capturé là, pas par l'équipe du rollup. Cependant, le MEV ne reste pas toujours avec les validateurs et les constructeurs. D'autres parties de la pile peuvent le capturer directement : • DEXs sensibles au MEV comme CoWSwap ou Uniswap v4 enchérissent sur des opportunités d'arbitrage et retournent des profits aux fournisseurs de liquidité. • Des outils comme MetaMask Protect ou Rabby acheminent les transactions de manière privée vers les constructeurs, protégeant les utilisateurs du front-running et redistribuant parfois une partie du MEV. Ces mécanismes réduisent l'arbitrage nuisible, mais le MEV ne disparaît pas, il change simplement de mains et de forme. 8. Avec un nouveau type de rollup, vient un nouveau type d'économie. Ce changement reformule l'économie des rollups. Beaucoup hésitent à passer au "basé" aujourd'hui car ils capturent des revenus MEV grâce à leurs séquenceurs centralisés, en front-running des échanges ou en arbitrant des prix à travers des plateformes. Mais à long terme, le flux de revenus le plus durable est constitué des frais d'exécution, le péage que les utilisateurs paient pour exécuter des transactions sur la machine virtuelle du rollup. Montrons un exemple hypothétique : Rollup avec son propre séquenceur (aujourd'hui) : • Frais d'exécution = 2M$/mois • MEV = 1M$/mois • Total = 3M$/mois Même rollup en tant que rollup basé (futur) : • MEV → validateurs Ethereum = 0$ • Frais d'exécution (des effets de réseau unifiés) = 10M$/mois • Total = 10M$/mois C'est le gambit MEV : sacrifier le pion (MEV du séquenceur) pour gagner le plus gros prix (des revenus d'exécution beaucoup plus élevés). Les rollups basés évitent de se battre pour le MEV et se concentrent plutôt sur l'évolutivité de leur couche d'exécution. 9. Ethereum peut-il gérer cette capacité ? La question évidente est : si chaque rollup se branche sur Ethereum comme son séquenceur, Ethereum L1 peut-il réellement le gérer ? En ce moment, Ethereum fonctionne sur des créneaux de 12 secondes. Le temps de créneau est la véritable contrainte. Avec des créneaux de 12 secondes, l'expérience utilisateur semble lente. Des recherches montrent qu'Ethereum pourrait probablement réduire cela à ~4 secondes sans sacrifier la décentralisation, les validateurs peuvent toujours fonctionner sur Internet domestique ou même des Raspberry Pis. Les pré-confirmations sans confiance sont essentielles pour qu'Ethereum puisse rivaliser avec les séquenceurs centralisés en termes de vitesse. Ce système utilise des proposeurs qui mettent en jeu des garanties et signent des garanties pour inclure des transactions, ce qui peut aboutir à des confirmations d'environ ~100 ms. C'est significativement plus rapide que les temps de bloc actuels et même plus rapide que certains setups de "superchain", offrant des vitesses similaires à la latence Internet. 10. Cependant, cette charge de travail est trop lourde pour les validateurs à domicile. L'APS (Attester Proposer Separation) divise le travail pour résoudre cela : les attesteurs vérifient et publient des transactions valides, tandis que les proposeurs/constructeurs construisent des blocs et gèrent les pré-confirmations. Au départ, cela se fait par le biais de passerelles, mais finalement, l'APS et le PBS inscrit permettront à Ethereum de fournir nativement des pré-confirmations rapides et sans confiance et un séquençage partagé. 11. Fabric : Construire les standards. Même avec l'APS et le PBS en place, il reste la question de la plomberie. Chaque équipe de rollup basé aujourd'hui doit réinventer les API pour les pré-confirmations, ajuster les pipelines PBS, mettre en place des registres et gérer le partage de blobs. Si cela n'est pas contrôlé, cela risque de se fragmenter en "mini standards" incompatibles. @fabric_ethereum est l'effort de coordination pour prévenir cela. Il ne lance pas de rollup ou de token. Au lieu de cela, il livre des composants open-source minimaux, y compris : • API des engagements pour les pré-confirmations • Contrat de registre universel pour la responsabilité des séquenceurs • Infrastructure de partage de blobs et de ponts Soutenu par des équipes comme @taikoxyz, @Scroll_ZKP, @Optimism, @arbitrum, @base, @Spire_Labs, et d'autres, Fabric émerge comme le point de convergence pour l'infrastructure des rollups basés — alignant les équipes sur des standards partagés afin que l'écosystème évolue ensemble, et non séparément.