Les raisons pour lesquelles les Rollups natifs étaient souvent évités et le changement de stratégie de Vitalik

Ce qui est devenu évident dans la dernière publication de Vitalik Buterin, c’est qu’il a considérablement changé de position concernant les Rollups natifs. Auparavant, sa prudence était principalement due à des questions de maturité technologique. Au cœur de cette évolution se trouve l’ensemble de l’écosystème, notamment l’accélération du développement des technologies ZK et leur mise en œuvre.

Maturation des technologies ZK et nouvelles options pour la sécurité des L2

La principale raison pour laquelle les Rollups natifs étaient auparavant évités est que les solutions de précompilation imposaient un choix binaire. Les L2 devaient soit « permettre des retraits rapides tout en assumant un risque de preuve », soit « dépendre de la sécurité d’Ethereum en acceptant un délai de retrait de 2 à 7 jours », ce qui obligeait souvent à opter pour la seconde option. Cette contrainte favorisait la diffusion d’alternatives comme les ponts multisignatures, ce qui réduisait la composabilité (interopérabilité) de l’ensemble du système.

Cependant, la situation technologique évolue rapidement. La feuille de route d’Ethereum pour une adoption sérieuse de ZK au niveau L1, ainsi que la mise en œuvre progressive des précompilations pour les Rollups natifs, commencent à s’aligner. Ces avancées laissent entrevoir la résolution progressive des obstacles majeurs qui existaient auparavant.

L’importance de la synchronisation de la composabilité et les nouvelles orientations pour la conception des précompilations

Selon Vitalik, la communauté commence à reconnaître la « synchronisation de la composabilité » comme une proposition de valeur essentielle pour les L2. La combinaison de solutions basées sur Rollup et de mécanismes de précompilation à faible latence accélère les efforts pour dépasser les limitations traditionnelles.

Dans la mise en œuvre concrète des précompilations pour les Rollups natifs, Vitalik insiste sur le fait qu’il ne faut pas adopter une conception précipitée. La spécification idéale qu’il propose consiste à permettre aux développeurs de construire des Rollups « avec des extensions limitées de fonctionnalités à l’EVM », en réutilisant directement la partie EVM des précompilations pour Rollup natif, tout en introduisant un système de preuve personnalisé uniquement pour les nouvelles fonctionnalités. Cela permettrait de connecter ces deux éléments de manière standardisée.

Ce fondement repose sur un équilibre entre compatibilité et flexibilité. Il s’agit d’une tentative de résoudre progressivement la complexité que rencontrent souvent les Rollups natifs. Avec la maturation de ZK-EVM et l’évolution des technologies de précompilation, une nouvelle étape de l’écosystème L2 est en train de se dessiner.