Transférer le titre original : Déballage de la prochaine génération des solutions de couche 2 d'Ethereum (III) : Rollups natifs

Au cours des deux dernières années, Ethereum s'est pleinement engagé dans une feuille de route axée sur les rollups. Cette stratégie consiste à verrouiller l'ETH dans des contrats de pont, à exécuter des transactions hors chaîne et à utiliser des preuves - soit des preuves de fraude, soit des preuves de connaissance nulle (ZKPs) - pour vérifier l'état de la couche 2 (L2) et gérer les retraits.

Cependant, il y a un défi significatif : Ethereum ne valide pas nativement l'exécution de l'EVM, obligeant les rollups à implémenter indépendamment leurs propres systèmes de preuve on-chain pour valider les transitions d'état.

Ethereum subit fréquemment des hard forks qui peuvent modifier l'EVM, ce qui signifie que les équipes de rollups doivent prendre la responsabilité de maintenir et de mettre à jour leurs implémentations personnalisées. Cela nécessite souvent la formation d'un conseil de sécurité ou l'adoption d'un système de gouvernance par vote basé sur les 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 exploré les rollups basés et les booster rollups. Maintenant, nous nous concentrons pour approfondir le concept de rollups natifs.

Basé, Booster, Natif... Quelle est la différence ?

Il peut y avoir beaucoup de confusion entre les définitions de based rollups, booster rollups et native rollups. Dans la série précédente, nous avons déjà abordé les based rollups et les booster rollups, il est donc recommandé de les consulter avant de lire cet article. Cependant, nous vous rappellerons rapidement ces trois types.

Les Rollups basés utilisent l'ensemble des validateurs L1 pour le séquençage des transactions, favorisant la décentralisation mais pouvant potentiellement affecter le débit en raison des temps de blocs L1 relativement longs, tels que 12 secondes. Cependant, des efforts sont déployés pour améliorer cette expérience avec des techniques de pré-confirmation, permettant aux utilisateurs de bénéficier d'une finalité des transactions beaucoup plus rapide alors que la communauté continue d'innover.

Les Booster Rollups augmentent l'exécution et le stockage en imitant le traitement L1 sur L2, permettant aux applications de croître sans re-déploiement. Bien que cette approche offre une évolutivité, elle introduit une complexité supplémentaire par rapport aux rollups traditionnels, nécessitant des efforts d'ingénierie plus sophistiqués pour le développement et la maintenance.

Les Rollups natifs exploitent la propre fonction de transition d'état (STF) de la couche d'application de L1 en tant que vérificateur des transitions d'état. Cependant, bien qu'Optimism, Arbitrum et d'autres rollups fonctionnent dans des environnements équivalents à l'EVM, ils incluent souvent des modifications personnalisées qui peuvent être complexes, voire impossibles, à implémenter directement sur Ethereum.

Les rollups natifs, autrefois appelés rollups consacrés, ont été largement discutés dans divers écrits. De plus, le terme « rollup canonique » a été brièvement employé par @apolynyaCependant, «enraciné» a finalement été remplacé par «natif» pour indiquer que les rollups équivalents à l'EVM existants pourraient éventuellement passer à ce modèle. Le terme «natif» a été proposé par @danrobinsonet un contributeur anonyme de Lido.

Comment fonctionnent les rollups natifs ?

La proposition native de rollup introduit le précompilé EXECUTE, conçu pour agir en tant que vérificateur des transitions d'état de rollup. Ce précompilé permettrait aux équipes de rollup de l'utiliser dans leurs contrats de vérification, fournissant une base pour les systèmes de preuve et permettant aux rollups d'hériter de la validation native d'Ethereum.

Étant donné que ce nouveau précompilé est quelque peu similaire au concept de "EVM dans EVM", il sera mis à jour via le 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 aux rollups d'hériter de la validation d'Ethereum et de soulager les équipes de rollup des responsabilités de gouvernance telles que les conseils de sécurité ou les multisigs, rendant finalement les rollups intrinsèquement plus sécurisés pour les utilisateurs.

La fonction de précompilation EXECUTE agit comme un vérificateur pour les transitions d'état de l'EVM, permettant aux rollups d'utiliser l'infrastructure native d'Ethereum au niveau de l'application. Elle valide les transitions en utilisant des entrées telles que pre_state_root, post_state_root, trace et gas_used, en s'appuyant sur un mécanisme de tarification du gaz similaire à l'EIP-1559.

Les validateurs peuvent assurer la correction des transitions d'état rollup par réexécution ou preuves SNARK, en fonction des besoins de l'évolutivité rollup. De plus, un délai d'un slot est incorporé pour atténuer les risques de centralisation, tels que la concurrence de preuves basées sur le MEV.

Le précompilé simplifie le développement de rollups en permettant des "rollups sans confiance" en termes de systèmes de preuve. S'il est combiné à une conception de rollup basée, où à la fois le séquençage et les systèmes de preuve sont gérés par Ethereum, cette structure pourrait atteindre une pleine absence de confiance, souvent appelée "rollup à ultrasons." Il améliore la composabilité avec la possibilité d'un règlement en temps réel, encourageant ainsi des conceptions de rollup plus composables et sécurisées.

La précompilation proposée se comporte de manière similaire à l'EVM, réexécutant les transactions de rollup pour vérifier leur exactitude. Cela contredit l'avantage principal des rollups, qui est l'exécution hors chaîne avec uniquement des preuves de validité soumises à Ethereum. Au lieu de cela, la précompilation reflète essentiellement ce que fait déjà Ethereum, n'ajoutant aucune valeur en termes de déchargement du fardeau computationnel de la L1.

Le choix d'un vérificateur similaire à l'EVM plutôt que des vérificateurs zk découle de l'immaturité actuelle de la technologie ZK. Même les zkVM largement utilisés ont montré des vulnérabilités, et l'évolution rapide des ZKPs rend risqué et inflexible le codage en dur de vérificateurs zk spécifiques on-chain. Ethereum privilégie plutôt la diversité et la neutralité, permettant l'expérimentation avec divers clients zk sans se verrouiller sur un seul vérificateur.

Cependant, cela ne signifie pas que le précompilé échoue à contribuer à la scalabilité d'Ethereum. Alors qu'Ethereum garantit sa sécurité en gardant les vérificateurs de preuves zk hors chaîne, il exploite ce précompilé pour valider les preuves zk soumises par les rollups. Cela permet aux validateurs d'Ethereum d'éviter de simuler entièrement toutes les transactions des rollups du début à la fin. Au lieu de cela, en se basant sur les preuves zk hors chaîne, le réseau maintient ses garanties de sécurité tout en cherchant à atteindre la scalabilité en termes d'exécution.

Quels sont les principaux avantages des rollups natifs ?

Avec les rollups natifs, une grande partie du travail complexe peut être gérée par une précompilation, rendant des choses comme les preuves de fraude ou les vérifications SNARK beaucoup plus simples. Cela signifie moins de code à écrire et à maintenir, et pas besoin de systèmes supplémentaires comme les réseaux de preuves ou les conseils de sécurité.

La vérification SNARK sur la chaîne est coûteuse, c'est pourquoi de nombreux zk-rollups règlent les transactions moins fréquemment pour économiser les coûts. Le précompilateur EXECUTE pourrait aider à réduire ces coûts en regroupant plusieurs preuves ensemble à l'aide de la récursion SNARK. Cette approche permet aux rollups de valider les transactions de manière plus efficace, rendant la vérification hors chaîne plus abordable.

Assurer un fonctionnement sans bug dans les rollups traditionnels est difficile et nécessite souvent des vérifications approfondies. De nombreuses équipes atténuent les risques en utilisant un séquençage centralisé pour empêcher la création de blocs malveillants. Cependant, l'exécution native via une précompilation pourrait permettre un mécanisme de séquençage plus sécurisé et sans permission. Cette approche peut permettre aux rollups d'hériter non seulement de la sécurité mais aussi de la fongibilité des actifs de L1, car les transactions sont validées directement dans l'environnement de confiance d'Ethereum.

Il existe de nombreux rollups compatibles avec l'EVM, mais peu d'entre eux sont véritablement équivalents à l'EVM : suivre les changements sur la blockchain principale nécessite souvent un système de groupe ou de vote pour mettre à jour les rollups, ce qui peut être risqué. Les rollups natifs peuvent se mettre à jour automatiquement avec la blockchain principale, maintenant ainsi tout en synchronisation sans avoir besoin de règles supplémentaires ou de votants.

Pour les zk-rollups, atteindre des temps de preuve ultra-bas, tels que 100ms, est une tâche d'ingénierie très difficile. Les rollups natifs, en comparaison, pourraient permettre un calendrier de preuve plus "relaxé", en le prolongeant sur un slot complet. Cette approche réduit la pression pour générer des preuves instantanément, améliorant potentiellement la fiabilité et l'intégration avec L1.

Chaque rollup sera-t-il natif ?

Toutes les piles de rollup actuelles, telles que la pile OP et la pile Arbitrum Orbit, ont le potentiel de se transformer en «rollups natifs», héritant directement des fonctionnalités de sécurité d'Ethereum. Cette mise à niveau rendrait les utilisateurs plus heureux en raison d'une sécurité renforcée et les équipes de rollup plus satisfaites en éliminant le besoin de conseils de sécurité. Pendant ce temps, les équipes de rollup peuvent continuer à concourir en offrant une couche de séquençage partagée efficace, en capturant toujours les frais de séquenceur et en maximisant le MEV.

Cependant, tous les rollups ne passeront pas en mode natif. Certaines fonctionnalités L2 sont intrinsèquement incompatibles avec les rollups natifs, notamment les types de transactions uniques, les méthodes de comptabilisation distinctes du gaz, et les précompilations non présentes sur la blockchain principale L1. La variété des machines virtuelles parmi les rollups L2, partageant chacune une base de sécurité commune, est l'une des forces de l'écosystème L2 actuel, comme @EclipseFNDétant un rollup SVM, @movementlabsxyzétant un rollup MoveVM, ou @Starknetétant un rollup CairoVM.

Comme indiqué par @doganeth_en, les futurs rollups tomberont dans 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, la séquenciation et la possession de leurs rollups, parfait pour les entreprises souhaitant avoir un contrôle similaire à web2 sur l'ordre des transactions, l'exécution et les applications.

Les rollups axés sur la performance utiliseront le règlement d'Ethereum mais compteront sur une disponibilité de données alternative pour des performances optimales, comme@megaeth_labsutiliser@eigen_dapour la disponibilité des données. Moins décentralisés, ces rollups renforcent $ETHutilitaire mais compromis sur certaines fonctionnalités Ethereum.

Les rollups natifs seront entièrement intégrés à l'infrastructure d'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 aux effets de réseau d'Ethereum, partageant potentiellement les revenus, mais la durabilité dépend des incitations économiques naturelles.

Conclusion

Les rollups natifs représentent une avancée majeure dans la feuille de route centrée sur les rollups d'Ethereum, offrant une approche plus alignée avec l'infrastructure d'Ethereum. En introduisant le pré-compilé EXECUTE, les rollups natifs simplifient la gouvernance, en supprimant la dépendance aux multisigs, aux conseils de sécurité ou aux systèmes de vote basés sur les jetons. Cette approche améliore non seulement la sécurité, mais permet également aux rollups de se développer de manière plus efficace en utilisant des preuves zk hors chaîne, garantissant à la fois la minimisation de la confiance et la scalabilité.

Bien que la proposition soit pleine de promesses, elle n'est pas sans défis. La plupart des rollups existants, bien qu'étiquetés comme équivalents à l'EVM, incluent souvent de légères modifications à l'EVM. Par conséquent, passer à un modèle de rollup natif pourrait introduire des frais de développement supplémentaires pour les rollups avec des implémentations personnalisées de l'EVM.

Néanmoins, les rollups natifs offrent une voie convaincante pour intégrer la sécurité et la flexibilité d'Ethereum avec la conception de rollup. En favorisant l'alignement avec L1, ils encouragent l'innovation tout en réduisant la fragmentation, rendant l'écosystème d'Ethereum plus cohésif et résilient pour l'avenir.

Si vous ne l'avez pas déjà fait, assurez-vous de vérifierpartie I etpartie IIde notre série Rollups 2.0 qui se concentre respectivement sur les rollups basés et les rollups booster. Dans notre prochain article, nous approfondirons le concept des rollups gigagas et explorerons comment cette approche innovante de conception de rollup pourrait repousser les limites de la scalabilité d'Ethereum et améliorer davantage l'écosystème du rollup.

Avertissement :

1. Cet article est repris de[2077 Recherche]. Transférer le titre original : Décryptage de la prochaine génération de solutions de couche 2 d'Ethereum (III) : Rollups natifs. Tous les droits d'auteur appartiennent à l'auteur original [2077 Recherche]. S'il y a des objections à cette reproduction, veuillez contacter le Portail Apprendrel'é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 de gate Learn. Il est interdit de copier, distribuer ou plagier les articles traduits sauf mention contraire.