Les rollups natifs utilisent leurs propres STF L1 comme validateurs de la couche d'application pour la transition d'état.
Écrit par : Communauté de la chaîne d'inscription
Au cours des deux dernières années, Ethereum s'est pleinement engagé dans la feuille de route du 'centre de rollups'. Cette stratégie implique de verrouiller l'ETH dans les contrats de pont, d'exécuter les transactions hors chaîne, et d'utiliser des preuves - qu'il s'agisse de preuves de fraude ou de preuves de connaissance nulle (ZKP) - pour vérifier l'état de la couche 2 (L2) et traiter les retraits.
Cependant, un défi majeur subsiste : Ethereum ne vérifie pas nativement l'exécution de l'EVM, obligeant les rollups à mettre en place leur propre système de preuve sur la chaîne pour valider les transitions d'état.
Ethereum a souvent subi des forks durs, ce qui peut modifier l'EVM, ce qui signifie que les équipes de rollups doivent être responsables de la maintenance et de la mise à jour de leur implémentation personnalisée. Cela nécessite généralement la création d'un comité de sécurité ou l'adoption d'un système de gouvernance basé sur des jetons pour gérer les mises à jour de leurs contrats de pont et de leurs mécanismes de preuve.
Dans notre série précédente, nous avons discuté du rollup basé et du rollup Booster. Maintenant, nous allons nous tourner vers une exploration plus approfondie du concept de rollup natif.
Quelle est la différence entre Based, Booster et natif ?
Il peut y avoir beaucoup de confusion entre les définitions de Based rollup, Booster rollup et rollup natif. Dans les précédents articles de la série, nous avons déjà présenté Based rollup et Booster rollup, il est donc recommandé de consulter ces contenus avant de lire cet article. Cependant, nous passerons rapidement en revue ces trois types.
Les rollups basés sur l'Application Layer utilisent un ensemble de validateurs L1 pour ordonner les transactions, favorisant la décentralisation, mais en raison du temps de bloc L1 relativement long (par exemple 12 secondes), cela peut affecter le débit. Cependant, des efforts sont en cours pour améliorer cette expérience en utilisant la technologie de pré-confirmation, permettant aux utilisateurs de bénéficier d'une confirmation finale plus rapide des transactions tout en continuant à innover dans la communauté.
Les rollups de booster étendent l'exécution et le stockage en simulant le traitement L1 sur L2, permettant aux applications de croître sans nécessiter de redéploiement. Bien que cette approche offre une extensibilité, elle introduit une complexité supplémentaire par rapport aux rollups traditionnels, nécessitant des efforts d'ingénierie plus complexes pour le développement et la maintenance.
Les Rollups natifs utilisent la fonction de transfert d'état (STF) de la couche L1 comme validateur de la transition d'état de la couche d'application. Cependant, bien qu'Optimism, Arbitrum et d'autres rollups fonctionnent dans un environnement EVM équivalent, ils contiennent généralement des modifications personnalisées complexes ou irréalisables qui ne peuvent pas être directement mises en œuvre sur Ethereum.
Les rollups natifs ont été autrefois appelés rollups légaux et ont été largement discutés dans divers écrits. De plus, le terme "rollup spécifique" a été brièvement utilisé par @apolynya. Cependant, le terme "légal" a finalement été remplacé par "natif" pour indiquer que les rollups équivalents à l'EVM existants pourraient être mis à niveau vers ce modèle. Le terme "natif" a été proposé par @danrobinson et un contributeur anonyme de Lido.
Comment fonctionne le rollup natif ?
La proposition rollup native introduit la précompilation EXECUTE, destinée à servir de validateur pour la transition d'état rollup. Cette précompilation permettra aux équipes rollup de l'utiliser dans leurs contrats de validation, fournissant ainsi un système de preuves basé et permettant au rollup d'hériter de la validation native d'Ethereum.
Comme ce nouveau précompilé est en quelque sorte similaire au concept de "EVM dans EVM" , il sera mis à jour par le biais du processus de hard fork d'Ethereum sous son consensus social. Cela garantit que les modifications apportées à l'EVM se reflètent dans le précompilé, permettant ainsi au rollup d'hériter de la validation d'Ethereum et allégeant la responsabilité de gouvernance de l'équipe de rollup en matière de sécurité ou de multi-sig, rendant ainsi le rollup intrinsèquement plus sûr pour les utilisateurs.
EXÉCUTE Précompiler en tant que vérificateur de transition d'état EVM, permettant aux rollups d'utiliser les infrastructures natives d'Ethereum dans la couche d'application. Il vérifie la transition en utilisant des données d'entrée telles que pre_state_root, post_state_root, trace et gas_used, en utilisant un mécanisme de tarification du gaz similaire à l'EIP-1559. Selon les besoins en matière de scalabilité des rollups, les vérificateurs peuvent imposer la vérification de la transition d'état du rollup en le réexécutant ou en produisant une preuve SNARK. De plus, une latence de créneau est intégrée pour atténuer les risques de centralisation, tels que la compétition de preuve basée sur MEV.
Ce précompilation simplifie le développement rollup en prenant en charge un "rollup sans confiance" dans le système de preuve. Lorsqu'il est combiné avec la conception du rollup basée, où le tri et le système de preuve sont gérés par Ethereum, cette structure peut réaliser une confiance totale, généralement appelée "rollup ultra-sonique". Cela améliore la composabilité et a le potentiel de règlement en temps réel, encourageant ainsi des conceptions rollup plus compossibles et sécurisées.
Le comportement précompilé proposé est similaire à celui de l'EVM, re-exécutant les transactions de rollups pour vérifier leur validité. Cela va à l'encontre de l'avantage principal des rollups, car leur avantage réside dans l'exécution hors chaîne, ne soumettant à Ethereum que des preuves de validité. Au contraire, les précompilations reflètent essentiellement ce qu'Ethereum a déjà fait et n'ajoutent aucune valeur à l'allégement de la charge de calcul provenant de la couche L1.
Le choix de validateurs similaires à EVM plutôt que de validateurs zk est dû à l'immaturité actuelle de la technologie ZK. Le zkVM largement utilisé actuellement a montré des vulnérabilités, et l'évolution rapide de la ZKP rend risqué et peu flexible d'encoder en dur des validateurs zk spécifiques sur la chaîne. Ethereum privilégie au contraire la diversité et la neutralité, permettant d'expérimenter avec différents clients zk sans être verrouillé sur un seul validateur.
Cependant, cela ne signifie pas que la précompilation n'a pas contribué à la scalabilité d'Ethereum. Bien qu'Ethereum maintienne la sécurité en gardant les validateurs de preuves zk hors chaîne, il utilise cette précompilation pour vérifier les preuves zk soumises par les rollups. Cela permet aux validateurs Ethereum d'éviter de simuler entièrement toutes les transactions de rollup. Au contraire, en s'appuyant sur les preuves zk hors chaîne, le réseau maintient sa garantie de sécurité tout en travaillant à améliorer la scalabilité en termes d'exécution.
Quels sont les principaux avantages des rollups natifs ?
Grâce aux rollups natifs, de nombreux travaux complexes peuvent être prétraités, ce qui rend les preuves de fraude ou les vérifications SNARK plus simples. Cela signifie moins de code à écrire et à entretenir, et pas besoin de systèmes supplémentaires tels que des réseaux de preuves ou des comités de sécurité.
Le coût de vérification SNARK on-chain étant élevé, de nombreux rollups zk économisent des coûts en ne liquidant pas fréquemment les transactions. L'exécution du précompilateur peut aider à réduire ces coûts en regroupant plusieurs preuves en utilisant SNARK de manière récursive. Cette méthode permet une vérification plus efficace des transactions rollup, rendant ainsi la vérification off-chain plus rentable.
Dans les rollups traditionnels, garantir des opérations sans erreur est un défi, nécessitant généralement des vérifications approfondies. De nombreuses équipes réduisent les risques en adoptant un tri centralisé pour éviter la génération de blocs malveillants. Cependant, un mécanisme de tri plus sécurisé et sans autorisation pourrait être réalisé grâce à une exécution native précompilée. Cette approche permet aux rollups de non seulement hériter de la sécurité de la couche L1, mais aussi de la fongibilité des actifs, car les transactions sont directement validées dans l'environnement de confiance d'Ethereum.
Il y a beaucoup de rollups compatibles avec l'EVM, mais presque aucun n'est équivalent à l'EVM : maintenir la synchronisation avec la blockchain principale nécessite généralement une équipe ou un système de vote pour mettre à jour le rollup, ce qui peut comporter des risques. Les rollups natifs peuvent être mis à jour automatiquement avec la blockchain principale, maintenant ainsi tout synchronisé, sans nécessiter de règles ou de votants supplémentaires.
Pour les rollups zk, atteindre un temps de preuve ultra-bas, par exemple 100 millisecondes, est une tâche d'ingénierie extrêmement difficile. En revanche, les rollups natifs peuvent permettre un calendrier de preuves plus "souple", en le prolongeant à une fente complète. Cette approche réduit la pression pour générer immédiatement des preuves, ce qui pourrait améliorer la fiabilité et renforcer l'intégration avec L1.
Tous les rollups seront-ils natifs ?
Tous les stack rollups actuels, tels que OP Stack et Arbitrum Orbit Stack, ont le potentiel de devenir des "rollups natifs" et d'hériter directement des caractéristiques de sécurité d'Ethereum. Cette mise à niveau rendra les utilisateurs plus satisfaits car la sécurité sera renforcée, et les équipes de rollups se sentiront plus à l'aise car elles n'auront plus besoin de comités de sécurité. En même temps, les équipes de rollups peuvent toujours rester compétitives en fournissant une couche de tri partagée efficace et en capturant les frais de tri, maximisant ainsi le MEV.
Cependant, ce n'est pas le cas pour tous les rollups qui vont migrer vers une forme native. Certaines caractéristiques de la L2 sont intrinsèquement incompatibles avec les rollups natifs, notamment des types de transactions uniques, des méthodes de comptabilisation du gaz différentes et des précompilations introuvables sur la blockchain L1 principale. La diversité des machines virtuelles entre les rollups de la L2, partageant chacune une base de sécurité commune, est un grand avantage de l'écosystème L2 d'aujourd'hui, par exemple
@EclipseFND est SVM rollup
@movementlabsxyzMoveVM cumul
@Starknet est un rollup CairoVM
Comme le souligne @doganeth_en, l’avenir des rollups se divisera en trois catégories : les rollups d’entreprise, les rollups axés sur les performances et les rollups natifs « alignés ».
Les entreprises se concentreront sur la gestion, le tri et la possession de leurs rollups, ce qui convient parfaitement aux entreprises souhaitant bénéficier d'un contrôle similaire à celui du web2 sur l'ordre des transactions, l'exécution et les applications.
Les rollups axés sur les performances utiliseront le règlement d'Éthereum, mais dépendront de la disponibilité des données alternatives pour obtenir des performances optimales, par exemple @megaeth_labs utilise @eigen_da pour obtenir la disponibilité des données. Ces rollups ont un degré moindre de décentralisation, mais améliorent l'utilité de l'ETH, au détriment de certaines caractéristiques d'Etherum.
Les rollups natifs seront pleinement intégrés aux infrastructures basées sur Ethereum et offriront : une décentralisation de niveau Ethereum, une exécution partagée avec un accès direct à l'état, et une vérification de preuve ZK moins chère hors chaîne. Ces rollups contribuent à l'effet de réseau d'Ethereum, peuvent partager des revenus, mais leur durabilité dépend des incitations économiques naturelles.
Conclusion
Les rollups natifs représentent une avancée majeure dans la feuille de route des rollups Ethereum, offrant une méthode plus alignée avec l'infrastructure basée sur Ethereum. En introduisant la précompilation EXECUTE, les rollups natifs simplifient la gouvernance, éliminant la dépendance à l'égard des multi-signatures, des comités de sécurité ou des systèmes de vote basés sur des jetons. Cette approche renforce non seulement la sécurité, mais permet également aux rollups de s'étendre de manière plus efficace, en utilisant des preuves zk hors chaîne, garantissant ainsi la minimisation de la confiance et la scalabilité.
Bien que cette proposition ait un large potentiel, elle n'est pas sans défis. Bien que la plupart des rollups existants soient qualifiés d'équivalents EVM, ils apportent généralement des modifications mineures à l'EVM. Ainsi, la transition vers un modèle de rollup natif pourrait imposer un fardeau supplémentaire de développement aux rollups ayant des implémentations EVM personnalisées.
Malgré cela, les rollups natifs offrent un chemin prometteur pour combiner la sécurité et la flexibilité d'Ethereum avec la conception des rollups. En favorisant l'alignement avec la couche L1, ils encouragent l'innovation tout en réduisant la fragmentation, rendant l'écosystème d'Ethereum plus solide et résilient à l'avenir.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Décryptage de la prochaine génération d'ETH L2 : Rollups natifs
Les rollups natifs utilisent leurs propres STF L1 comme validateurs de la couche d'application pour la transition d'état.
Écrit par : Communauté de la chaîne d'inscription
Au cours des deux dernières années, Ethereum s'est pleinement engagé dans la feuille de route du 'centre de rollups'. Cette stratégie implique de verrouiller l'ETH dans les contrats de pont, d'exécuter les transactions hors chaîne, et d'utiliser des preuves - qu'il s'agisse de preuves de fraude ou de preuves de connaissance nulle (ZKP) - pour vérifier l'état de la couche 2 (L2) et traiter les retraits.
Cependant, un défi majeur subsiste : Ethereum ne vérifie pas nativement l'exécution de l'EVM, obligeant les rollups à mettre en place leur propre système de preuve sur la chaîne pour valider les transitions d'état.
Ethereum a souvent subi des forks durs, ce qui peut modifier l'EVM, ce qui signifie que les équipes de rollups doivent être responsables de la maintenance et de la mise à jour de leur implémentation personnalisée. Cela nécessite généralement la création d'un comité de sécurité ou l'adoption d'un système de gouvernance basé sur des jetons pour gérer les mises à jour de leurs contrats de pont et de leurs mécanismes de preuve.
Dans notre série précédente, nous avons discuté du rollup basé et du rollup Booster. Maintenant, nous allons nous tourner vers une exploration plus approfondie du concept de rollup natif.
Quelle est la différence entre Based, Booster et natif ?
Il peut y avoir beaucoup de confusion entre les définitions de Based rollup, Booster rollup et rollup natif. Dans les précédents articles de la série, nous avons déjà présenté Based rollup et Booster rollup, il est donc recommandé de consulter ces contenus avant de lire cet article. Cependant, nous passerons rapidement en revue ces trois types.
Les rollups basés sur l'Application Layer utilisent un ensemble de validateurs L1 pour ordonner les transactions, favorisant la décentralisation, mais en raison du temps de bloc L1 relativement long (par exemple 12 secondes), cela peut affecter le débit. Cependant, des efforts sont en cours pour améliorer cette expérience en utilisant la technologie de pré-confirmation, permettant aux utilisateurs de bénéficier d'une confirmation finale plus rapide des transactions tout en continuant à innover dans la communauté.
Les rollups de booster étendent l'exécution et le stockage en simulant le traitement L1 sur L2, permettant aux applications de croître sans nécessiter de redéploiement. Bien que cette approche offre une extensibilité, elle introduit une complexité supplémentaire par rapport aux rollups traditionnels, nécessitant des efforts d'ingénierie plus complexes pour le développement et la maintenance.
Les Rollups natifs utilisent la fonction de transfert d'état (STF) de la couche L1 comme validateur de la transition d'état de la couche d'application. Cependant, bien qu'Optimism, Arbitrum et d'autres rollups fonctionnent dans un environnement EVM équivalent, ils contiennent généralement des modifications personnalisées complexes ou irréalisables qui ne peuvent pas être directement mises en œuvre sur Ethereum.
Les rollups natifs ont été autrefois appelés rollups légaux et ont été largement discutés dans divers écrits. De plus, le terme "rollup spécifique" a été brièvement utilisé par @apolynya. Cependant, le terme "légal" a finalement été remplacé par "natif" pour indiquer que les rollups équivalents à l'EVM existants pourraient être mis à niveau vers ce modèle. Le terme "natif" a été proposé par @danrobinson et un contributeur anonyme de Lido.
Comment fonctionne le rollup natif ?
La proposition rollup native introduit la précompilation EXECUTE, destinée à servir de validateur pour la transition d'état rollup. Cette précompilation permettra aux équipes rollup de l'utiliser dans leurs contrats de validation, fournissant ainsi un système de preuves basé et permettant au rollup d'hériter de la validation native d'Ethereum.
Comme ce nouveau précompilé est en quelque sorte similaire au concept de "EVM dans EVM" , il sera mis à jour par le biais du processus de hard fork d'Ethereum sous son consensus social. Cela garantit que les modifications apportées à l'EVM se reflètent dans le précompilé, permettant ainsi au rollup d'hériter de la validation d'Ethereum et allégeant la responsabilité de gouvernance de l'équipe de rollup en matière de sécurité ou de multi-sig, rendant ainsi le rollup intrinsèquement plus sûr pour les utilisateurs.
EXÉCUTE Précompiler en tant que vérificateur de transition d'état EVM, permettant aux rollups d'utiliser les infrastructures natives d'Ethereum dans la couche d'application. Il vérifie la transition en utilisant des données d'entrée telles que pre_state_root, post_state_root, trace et gas_used, en utilisant un mécanisme de tarification du gaz similaire à l'EIP-1559. Selon les besoins en matière de scalabilité des rollups, les vérificateurs peuvent imposer la vérification de la transition d'état du rollup en le réexécutant ou en produisant une preuve SNARK. De plus, une latence de créneau est intégrée pour atténuer les risques de centralisation, tels que la compétition de preuve basée sur MEV.
Ce précompilation simplifie le développement rollup en prenant en charge un "rollup sans confiance" dans le système de preuve. Lorsqu'il est combiné avec la conception du rollup basée, où le tri et le système de preuve sont gérés par Ethereum, cette structure peut réaliser une confiance totale, généralement appelée "rollup ultra-sonique". Cela améliore la composabilité et a le potentiel de règlement en temps réel, encourageant ainsi des conceptions rollup plus compossibles et sécurisées.
Le comportement précompilé proposé est similaire à celui de l'EVM, re-exécutant les transactions de rollups pour vérifier leur validité. Cela va à l'encontre de l'avantage principal des rollups, car leur avantage réside dans l'exécution hors chaîne, ne soumettant à Ethereum que des preuves de validité. Au contraire, les précompilations reflètent essentiellement ce qu'Ethereum a déjà fait et n'ajoutent aucune valeur à l'allégement de la charge de calcul provenant de la couche L1.
Le choix de validateurs similaires à EVM plutôt que de validateurs zk est dû à l'immaturité actuelle de la technologie ZK. Le zkVM largement utilisé actuellement a montré des vulnérabilités, et l'évolution rapide de la ZKP rend risqué et peu flexible d'encoder en dur des validateurs zk spécifiques sur la chaîne. Ethereum privilégie au contraire la diversité et la neutralité, permettant d'expérimenter avec différents clients zk sans être verrouillé sur un seul validateur.
Cependant, cela ne signifie pas que la précompilation n'a pas contribué à la scalabilité d'Ethereum. Bien qu'Ethereum maintienne la sécurité en gardant les validateurs de preuves zk hors chaîne, il utilise cette précompilation pour vérifier les preuves zk soumises par les rollups. Cela permet aux validateurs Ethereum d'éviter de simuler entièrement toutes les transactions de rollup. Au contraire, en s'appuyant sur les preuves zk hors chaîne, le réseau maintient sa garantie de sécurité tout en travaillant à améliorer la scalabilité en termes d'exécution.
Quels sont les principaux avantages des rollups natifs ?
Grâce aux rollups natifs, de nombreux travaux complexes peuvent être prétraités, ce qui rend les preuves de fraude ou les vérifications SNARK plus simples. Cela signifie moins de code à écrire et à entretenir, et pas besoin de systèmes supplémentaires tels que des réseaux de preuves ou des comités de sécurité.
Le coût de vérification SNARK on-chain étant élevé, de nombreux rollups zk économisent des coûts en ne liquidant pas fréquemment les transactions. L'exécution du précompilateur peut aider à réduire ces coûts en regroupant plusieurs preuves en utilisant SNARK de manière récursive. Cette méthode permet une vérification plus efficace des transactions rollup, rendant ainsi la vérification off-chain plus rentable.
Dans les rollups traditionnels, garantir des opérations sans erreur est un défi, nécessitant généralement des vérifications approfondies. De nombreuses équipes réduisent les risques en adoptant un tri centralisé pour éviter la génération de blocs malveillants. Cependant, un mécanisme de tri plus sécurisé et sans autorisation pourrait être réalisé grâce à une exécution native précompilée. Cette approche permet aux rollups de non seulement hériter de la sécurité de la couche L1, mais aussi de la fongibilité des actifs, car les transactions sont directement validées dans l'environnement de confiance d'Ethereum.
Il y a beaucoup de rollups compatibles avec l'EVM, mais presque aucun n'est équivalent à l'EVM : maintenir la synchronisation avec la blockchain principale nécessite généralement une équipe ou un système de vote pour mettre à jour le rollup, ce qui peut comporter des risques. Les rollups natifs peuvent être mis à jour automatiquement avec la blockchain principale, maintenant ainsi tout synchronisé, sans nécessiter de règles ou de votants supplémentaires.
Pour les rollups zk, atteindre un temps de preuve ultra-bas, par exemple 100 millisecondes, est une tâche d'ingénierie extrêmement difficile. En revanche, les rollups natifs peuvent permettre un calendrier de preuves plus "souple", en le prolongeant à une fente complète. Cette approche réduit la pression pour générer immédiatement des preuves, ce qui pourrait améliorer la fiabilité et renforcer l'intégration avec L1.
Tous les rollups seront-ils natifs ?
Tous les stack rollups actuels, tels que OP Stack et Arbitrum Orbit Stack, ont le potentiel de devenir des "rollups natifs" et d'hériter directement des caractéristiques de sécurité d'Ethereum. Cette mise à niveau rendra les utilisateurs plus satisfaits car la sécurité sera renforcée, et les équipes de rollups se sentiront plus à l'aise car elles n'auront plus besoin de comités de sécurité. En même temps, les équipes de rollups peuvent toujours rester compétitives en fournissant une couche de tri partagée efficace et en capturant les frais de tri, maximisant ainsi le MEV.
Cependant, ce n'est pas le cas pour tous les rollups qui vont migrer vers une forme native. Certaines caractéristiques de la L2 sont intrinsèquement incompatibles avec les rollups natifs, notamment des types de transactions uniques, des méthodes de comptabilisation du gaz différentes et des précompilations introuvables sur la blockchain L1 principale. La diversité des machines virtuelles entre les rollups de la L2, partageant chacune une base de sécurité commune, est un grand avantage de l'écosystème L2 d'aujourd'hui, par exemple
Comme le souligne @doganeth_en, l’avenir des rollups se divisera en trois catégories : les rollups d’entreprise, les rollups axés sur les performances et les rollups natifs « alignés ».
Les entreprises se concentreront sur la gestion, le tri et la possession de leurs rollups, ce qui convient parfaitement aux entreprises souhaitant bénéficier d'un contrôle similaire à celui du web2 sur l'ordre des transactions, l'exécution et les applications.
Les rollups axés sur les performances utiliseront le règlement d'Éthereum, mais dépendront de la disponibilité des données alternatives pour obtenir des performances optimales, par exemple @megaeth_labs utilise @eigen_da pour obtenir la disponibilité des données. Ces rollups ont un degré moindre de décentralisation, mais améliorent l'utilité de l'ETH, au détriment de certaines caractéristiques d'Etherum.
Les rollups natifs seront pleinement intégrés aux infrastructures basées sur Ethereum et offriront : une décentralisation de niveau Ethereum, une exécution partagée avec un accès direct à l'état, et une vérification de preuve ZK moins chère hors chaîne. Ces rollups contribuent à l'effet de réseau d'Ethereum, peuvent partager des revenus, mais leur durabilité dépend des incitations économiques naturelles.
Conclusion
Les rollups natifs représentent une avancée majeure dans la feuille de route des rollups Ethereum, offrant une méthode plus alignée avec l'infrastructure basée sur Ethereum. En introduisant la précompilation EXECUTE, les rollups natifs simplifient la gouvernance, éliminant la dépendance à l'égard des multi-signatures, des comités de sécurité ou des systèmes de vote basés sur des jetons. Cette approche renforce non seulement la sécurité, mais permet également aux rollups de s'étendre de manière plus efficace, en utilisant des preuves zk hors chaîne, garantissant ainsi la minimisation de la confiance et la scalabilité.
Bien que cette proposition ait un large potentiel, elle n'est pas sans défis. Bien que la plupart des rollups existants soient qualifiés d'équivalents EVM, ils apportent généralement des modifications mineures à l'EVM. Ainsi, la transition vers un modèle de rollup natif pourrait imposer un fardeau supplémentaire de développement aux rollups ayant des implémentations EVM personnalisées.
Malgré cela, les rollups natifs offrent un chemin prometteur pour combiner la sécurité et la flexibilité d'Ethereum avec la conception des rollups. En favorisant l'alignement avec la couche L1, ils encouragent l'innovation tout en réduisant la fragmentation, rendant l'écosystème d'Ethereum plus solide et résilient à l'avenir.