RECHERCHE ETHEREUM: Rollups native – Super-puissances de l’exécution de L1

Auteur: Le chercheur Ethereum Justin Drake, Ethresearch;

Le crédit pour cet article est dû à la communauté plus large de R&D Ethereum.Les contributions clés découlent de 2017, avec des déverrouillages incrémentiels importants dans la conception au fil des ans.Des percées récentes dans l’ingénierie ZKVM ont déclenché une exploration approfondie de l’espace de conception.Cet article fait de son mieux pour reconstituer un design cohérent pour une grande idée qui pourrait enfin arriver.

résumé

Nous proposons une précompilation d’exécution élégante et puissante qui expose le moteur d’exécution EVM L1 natif vers la couche d’application.Le résumé de l’exécution native (« Résumé natif ») est un résumé des transitions d’état EVM à l’aide d’exécuter pour vérifier les transactions utilisateur par lots.Le résumé natif peut être considéré comme des «fragments d’exécution programmables» et précompilés dans des fonctions dérivées pour gérer la logique système en dehors de l’EVM, telles que le tri, le pontage, l’inclusion forcée, la gouvernance.

Étant donné que l’exécution de précompilation est effectuée directement par le validateur, il jouit de la diversité du client (ZK) EL et fournit des équivalents EVM qui sont sans erreur de manière constructive et sont mises à niveau vers EVM via la compatibilité précédente de L1 Fork Hard Fork.Pour un résumé équivalent EVM qui souhaite hériter pleinement de la sécurité Ethereum, les formulaires d’introspection EVM comme l’exécution de la précompilation sont nécessaires.Nous appelons le résumé de la sécurité d’Ethereum pleinement héritée un « résumé sans confiance ».

Exécuter la précompilation simplifie considérablement le développement d’un résumé équivalent EVM car la simulation et la maintenance EVM sont effectuées sans infrastructures complexes telles que les jeux de prévention de la fraude, les circuits de snark, les panneaux de sécurité.Avec EXECUTE, quelques lignes de code de solidité peuvent être utilisées pour déployer un minimum de résumés natifs et basés sur des rouleaux en utilisant des fonctions dérivées simples, éliminant le besoin d’un traitement spécial du tri, de l’inclusion forcée ou de la gouvernance.

Plus important encore,L’agrégation indigène peut profiter de règlement en temps réel sans se soucier de la preuve en temps réel, simplifiant considérablement la composabilité synchrone.

Cet article est divisé en deux parties, introduisant d’abord la précompilation proposée et discutant enfin du résumé natif.

Partie 1 – Exécuter précompilé

structure

Exécuter la précompilation accepte les entrées pre_state_root, post_state_root, trace et gas_used.Il renvoie vrai si et seulement si les conditions suivantes sont remplies:

Trace est un suivi d’exécution bien formé (par exemple, la liste des transactions L2 et la preuve d’accès à l’état correspondant)
L’exécution sans état de la trace commence par pre_state_root et se termine par post_state_root
L’exécution sans état de Trace consomme simplement du gaz_équé

Il existe un mécanisme de style EIP-1559 pour mesurer et tarifier le gaz accumulé consommé par tous les appels d’exécution dans le bloc L1.Plus précisément, il existe une limite de gaz accumulée execure_cumulative_gas_limit et une cible de gaz accumulée execute_cumulative_gas_target.(Lorsque L1 EVM peut être exécuté sans état par le vérificateur, les limites et cibles cumulatives peuvent être fusionnés avec le mécanisme L1 EIP-1559.)

L’appel de précompilation nécessite un nombre fixe de gaz L1, EXECUTE_GAS_COST, plus GAS_USUD * GAS_PRICE, où GAS_PRICE (prix en eth / gaz) est fixé par le mécanisme de style EIP-1559.Le prépaiement complet sera retiré même si la précompilation revient fausse.

Le suivi doit indiquer les données Ethereum disponibles à partir des données d’appel, du blob, de l’état ou de la mémoire.

Réexécuter

Si execure_cumulative_gas_limit est suffisamment petit, le validateur peut simplement réexécuter la trace pour appliquer l’exactitude de l’appel d’exécution.Le déploiement initial basé sur la précompilation de réexécution peut servir de tremplin, similaire à la simple refonte du naufrage d’origine du naufrage complet.Notez que la simple réexécution n’apporte pas la croissance de l’état ou les frais généraux de bande passante au validateur, et toute surcharge d’exécution peut être parallélisée entre les noyaux CPU.

Le validateur doit contenir une copie explicite de la trace pour la réexécution, empêchant ainsi l’utilisation de pointeurs pour bloquer les données échantillonnées (plutôt que téléchargées) via DAS.Notez que les résumés natifs optimistes peuvent encore publier des données agrégées sous forme de blobs, se retournant aux données d’appel uniquement dans les jeux de fraude.Il est également important de noter que l’agrégation native optimiste peut avoir des limites de gaz qui dépassent de loin l’exécution_cumulative_gas_limit, car l’exécution de la précompilation ne nécessite qu’un seul appel sur un petit segment EVM pour résoudre le défi à l’épreuve de la fraude.

En tant que dossier historique, en 2017, Vitalik a proposé une précompilation «EVM EVM» similaire appelée exected.

Exécuter via Snark

Pour déverrouiller le plus grand EXECUTE_CUMULATIVE_GAS_LIMIT, il permettra naturellement au vérificateur de vérifier sélectivement la preuve de snark.À partir de maintenant, nous supposons qu’un créneau horaire retarde l’exécution, où un bloc non valide (ou une transaction non valide) est considéré comme une opération sans opération.(Pour plus d’informations sur l’exécution retardée, consultez ce post d’ethresearch, cette EIP, et cette conception pour Francesco.) Une exécution retardée de l’emplacement entraîne des secondes (l’ensemble de l’emplacement) pour la preuve.Ils évitent également d’inciter les compétitions de preuve motivée par le MEV, qui introduiront des vecteurs centralisés.

Notez que même si l’exécution est appliquée par Snark, il n’y a aucune preuve claire que le système ou le circuit est incorporé dans le consensus.(Notez que l’exécution de la précompilation ne prend aucune preuve explicite en entrée.) Au lieu de cela, chaque opérateur de striage est libre de choisir son client de validateur ZKEL préféré, similaire à la façon dont l’approche d’aujourd’hui pour sélectionner un client EL subjectivement.La section suivante «preuve hors chaîne» expliquera les avantages de cette décision de conception.

À partir de maintenant, nous supposons que le proposant d’exécution est mature dans le contexte de la séparation de prouvants (APS) avec des emplacements d’exécution et de consensus alternatifs.Pour motiver les proposeurs d’exécution rationnels pour générer des preuves en temps opportun (dans un creux de temps), nous exigeons que les preuves prouvent le bloc d’exécution n + 1 uniquement lorsque le bloc d’exécution de la preuve d’exécution est disponible.(Nous recommandons de regrouper le bloc N + 1 avec l’exécution de la preuve du bloc N au niveau de la couche P2P.) Les proposeurs d’exécution qui ignorent les preuves peuvent manquer leurs emplacements, ce qui entraîne des frais manqués et des MEV.Nous imposons en outre une pénalité fixe aux créneaux d’exécution manqués, le définissant suffisamment haut (par exemple 1 ETH) pour toujours dépasser le coût de la preuve.

Notez que dans le contexte de l’APS, la génération de blocs consensus n’est pas bloquée par des emplacements d’exécution manqués.Cependant, la génération de preuves en temps opportun est importante pour les clients légers afin qu’ils puissent lire facilement l’état du côté de la chaîne sans réexécution sans état.Pour garantir la génération de preuves en temps opportun pour les clients légers, nous nous appuyons sur l’hypothèse altruiste de la preuve des minorités même dans le cas spécial où le prochain proposant d’exécution manque son créneau horaire.Un seul prover altruiste est suffisant pour générer une preuve dans 1 créneau horaire.Pour éviter les preuves redondantes inutiles, la plupart des preuves altruistes ne peuvent attendre en attente et ne déclencher que lorsque aucune preuve n’arrive dans 1 emplacement, agissant ainsi comme une mesure de sécurité pour les retards allant jusqu’à 2 emplacements.

Notez que EXECUTE_CUMULATIVE_GAS_LIMIT doit être réglé suffisamment bas pour rendre les hypothèses altruistes de la minorité digne de confiance (et pour rendre la proposition d’exécution de manière irréaliste en compliqué).Une stratégie conservatrice pourrait être de définir EXECUTE_CUMULATIVE_GAS_LIMIT afin que les ordinateurs portables tels que MacBook Pro haut de gamme puissent accéder à des épreuves à emplacement unique.Une politique plus pragmatique et positive peut être de cibler un petit pourcentage de GPU, et une fois qu’ils sont entièrement marchandisés, il peut éventuellement cibler la preuve ASIC SNARK.

Preuve hors chaîne

Pour réitérer, nous vous recommandons de ne pas mettre la preuve d’exécution de Zkel sur la chaîne, mais de la partager hors de la chaîne.Ne pas épargner est une bonne idée, d’abord proposé par Vitalik, et il présente plusieurs avantages:

Diversité:Les vérificateurs sont libres de sélectionner des validateurs de preuve (y compris des systèmes et des circuits de preuve) de l’équipe de développement en laquelle ils ont confiance, similaire à la façon dont les validateurs choisissent les clients EL en qui ils ont confiance.Cela fournit une robustesse grâce à la diversité.Le client de validateur ZKEL (et certains des ZKVMs sous-jacents des clients) sont des logiciels de chiffrement complexes.Les erreurs dans l’un ou l’autre client ne doivent pas provoquer un plan d’Ethereum.
Neutralité:Le fait d’avoir le marché client de Validator Zkel permet à la couche consensus de ne pas sélectionner le gagnant de la technologie.Par exemple, le marché ZKVM est très compétitif et le choix d’un fournisseur gagnant (comme RISC0, succinct ou de nombreux autres fournisseurs) peut ne pas être considéré comme neutre.
Simplicité:La couche de consensus n’a pas besoin d’inclure un validateur de snark spécifique, ce qui simplifie considérablement la spécification de la couche consensus.Incluez simplement le format de la preuve d’accès de l’État, et non les détails de l’implémentation du validateur de preuve spécifique.
flexibilité:Si des erreurs ou des optimisations sont trouvées, les validateurs affectés peuvent mettre à jour leurs clients sans fourchettes difficiles.

Avoir une preuve hors chaîne entraîne des complexités contrôlables:

Prouver la charge et la fragmentation P2P:Puisqu’il n’y a pas de preuve de spécification unique, plusieurs preuves doivent être générées (au moins un par client ZKEL).Chaque personnalisation du client ZKEL (par exemple, échanger un RISC-V ZKVM pour une autre) nécessite une preuve différente.De même, chaque mise à niveau de la version ZKEL nécessite une preuve différente.Cela entraînera une charge de preuve accrue.Si chaque type de preuve a un canal de potins séparé, il fragmentera davantage le réseau P2P.
Quelques zkels:Il est difficile de motiver quelques zkels à générer des preuves.Les proposeurs d’exécution rationnels ne peuvent générer que suffisamment de preuves pour atteindre la grande majorité des preuves sans manquer leur période de temps.Pour résoudre ce problème, les opérateurs marqués peuvent être encouragés par la société à gérer plusieurs clients ZKEL en parallèle, similaire aux opérateurs de garantie d’aujourd’hui.L’exécution de la configuration K-Of-N a également l’avantage supplémentaire d’améliorer la sécurité, en particulier la prévention des vulnérabilités sanitaires qui permettent aux attaquants de créer des preuves pour les appels d’exécution arbitraires (ce cas n’est pas pour les clients EL traditionnels. Common).

La preuve hors chaîne réduira également l’efficacité du règlement en temps réel L2:

Pas de substitut da:Étant donné que l’entrée de suivi de l’exécution doit être fournie au validateur L1, le L2 qui se règle en temps réel (le L2 qui met à jour son statut de spécification racine immédiatement) doit consommer L1 DA, c’est-à-dire le résumé.Notez qu’il n’y a pas une telle limite à la L2 optimiste du règlement retardé du jeu par fraude, c’est-à-dire que cela peut être une valeur valable.
Averrage d’accès à l’état:Étant donné que la trace doit être sans état, elle doit inclure des feuilles de trie d’État qui sont lues ou écrites, qui introduit une petite quantité de frais généraux DA qu’un bloc L2 typique.Notez que le L2 optimiste n’a pas cette limitation car les feuilles de trie d’État ne sont nécessaires que dans les défis de la fraude, et le challenger peut recalculer les feuilles de tri.
Aucune différence d’état:Étant donné que la preuve doit être sans autorisation, la différence de statut de résumé ne peut pas être effectuée en raison d’un suivi donné.Cependant, si la preuve spécialisée correspondante est incorporée dans le consensus, la preuve d’accès sans état ou la signature de transaction EVM peut être compressée.

Exécution native RISC-V

Compte tenu de la convergence de facto d’aujourd’hui en RISC-V ZKVM, il peut y avoir une opportunité d’exposer localement les transitions d’État RISC-V vers les EVM (similaires aux wasmes dans des environnements de stylet arbitrum) et de maintenir le snark-friendly.

Partie 2 – Rollup natif

nom

Discutons d’abord de la dénomination des rouleaux indigènes pour résoudre plusieurs problèmes déroutants:

Nom alternatif:Le résumé natif était auparavant connu sous le nom de résumé consacré.(Le terme «résumé canonique» a également été brièvement utilisé dans Polynya 12.) Le terme «consacré» a ensuite été abandonné et remplacé par «natif» pour indiquer que le résumé équivalent EVM existant peut être éventuellement amélioré vers le natif.Le nom «natif» a été proposé indépendamment par Dan Robinson et un contributeur de Lido qui voulait rester anonyme en novembre 2022.
Basé sur le résumé:Basé sur le résumé et les résumés natifs sont toujours des concepts orthogonaux: « basé » est lié au tri L1, tandis que « natif » est lié à l’exécution de L1.Dans le même temps, sur la base et le résumé natif est fantaisiste appelé « SUPERON RÉSUMÉ ».
Exécuter le fragment:Le rupture d’exécution (c’est-à-dire la copie inscrite de la chaîne EVM L1) est un concept différent mais connexe lié aux résumés natifs, plusieurs années avant les résumés natifs.(L’exécution de Sharding a été avant la «phase 2» de la feuille de route Ethereum 2.0.) Contrairement au rollup natif, le fragment n’est pas programmable, c’est-à-dire qu’il n’y a pas d’options telles que la gouvernance personnalisée, le tri personnalisé et les jetons à gaz personnalisés.Les fragments d’exécution sont également généralement instanciés dans un nombre fixe (par exemple 64 ou 1 024 éclats).Malheureusement, Martin Köppelmann a utilisé le terme «natif L2» 7 dans son discours de Devcon en 2024 sur l’exécution de Shards.

avantage

Les rouleaux natifs ont plusieurs avantages, que nous couvrirons en détail ci-dessous:

Simplicité:La majeure partie de la complexité d’une machine virtuelle de rouleau native peut être encapsulée par précompilation.Aujourd’hui, l’optimisme et ZK-Rollup, comparables à l’EVM, ont des milliers de lignes de code pour leurs jeux de fraude ou leurs validateurs de sark qui peuvent être compressés en une seule ligne de code.Les Rollups natifs ne nécessitent pas non plus d’infrastructures auxiliaires telles que les réseaux de preuve, les tours de guette et les comités de sécurité.
Sécurité:La construction d’un jeu de fraude EVM sans erreur ou d’un validateur Snark est une tâche d’ingénierie très difficile qui peut nécessiter une validation de formulaire approfondie.Aujourd’hui, chaque ROLUP OPTIMISME et ZK EVM est susceptible d’avoir une vulnérabilité grave dans sa fonction de transition de l’état EVM.Pour éviter les vulnérabilités, le tri centralisé est souvent utilisé comme une béquille pour contrôler la production de blocs contradictoires.L’exécution native de précompilation permet un déploiement sécurisé du tri sans autorisation.Les rouleaux sans confiance qui héritent pleinement de la sécurité L1 héritent également entièrement l’interchangeabilité des actifs L1.
Équivalence EVM:Aujourd’hui, le seul moyen de synchroniser les règles L1 EVM est que la gouvernance (généralement les comités de sécurité et / ou les jetons de gouvernance) reflète les mises à niveau L1 EVM.(Les mises à jour EVM sont toujours régulièrement effectuées avec des fourches dures environ une fois par an.) La gouvernance n’est pas seulement un vecteur d’attaque, il s’écarte strictement de L1 EVM et empêche tout rollup d’atteindre une véritable équivalence EVM à long terme.D’un autre côté, le rouleau indigène peut être amélioré de manière synchrone avec L1 sans gouvernance.
Coût de gaz sark:La vérification de Snark sur chain coûte cher.Par conséquent, de nombreux rollups ZK se régalent rarement pour minimiser les coûts.Étant donné que Snark n’est pas validé sur la chaîne, l’exécution de précompilation peut être utilisée pour réduire les coûts de vérification.Si vous utilisez Snark pour par lots récursivement des preuves d’exécution pour plusieurs appels dans un bloc, EXECUTE_GAS_COST peut être défini relativement bas.
Composabilité synchrone:Aujourd’hui, la composabilité synchrone avec L1 nécessite une preuve en temps réel du même emplacement.La mise en œuvre des preuves de latence ultra-bas (par exemple environ 100 millisecondes) est une tâche d’ingénierie particulièrement difficile pour les rouleaux ZK.En utilisant une racine d’état de retard de fente unique, vous pouvez détendre le retard de preuve du natif effectué précompilé sur une fente complète.