Auteur: krane, lamby (Asula), sylve, lancelot (Hyle) Source: bedlam research Traduction: Shanooba, Golden Finance

Introduction

Au cours de la semaine dernière, nous avons vu plusieurs propositions concernant la feuille de route de la couche de consensus d'ETH. La plus remarquable est celle de Justin Drake lors de son discours à Devcon 2024, où il expose sa vision de l'ère ZK d'ETH. Elle est appelée beam chaîne ou beam fork, et apporte de nombreuses améliorations majeures à ETH, notamment la réduction du temps de slot, l'accélération de la finalité et la « snarkification » du consensus ETH. Les réactions à cette proposition et aux délais de ces changements sont mitigées. Cependant, compte tenu de l'ampleur économique d'ETH, nous devons également reconnaître l'importance de la prudence envers ETH. Malgré cette reconnaissance, il est utile de réfléchir à l'avenir ambitieux de la couche de base d'un écosystème centré sur Rollup. Dans l'esprit de « ne pas être entravé par le passé, mais seulement pour l'avenir », cet article présente une vision future basée sur les progrès de la recherche en ZK et en consensus.

Nous commencerons par examiner les principes fondamentaux de la couche de base, puis nous explorerons les concepts clés de la recherche sur le consensus. Enfin, nous examinerons en détail comment appliquer ces recherches à la conception de la prochaine génération de la couche de base, en particulier dans le cadre du mécanisme ZK.

Couche de base

De nos jours, la plupart des Rollup utilisent un ordonnanceur centralisé pour trier et exécuter les transactions. Une fois que l'ordonnanceur génère un bloc, il est également responsable de générer une preuve d'exécution pour que d'autres puissent la vérifier. Pour rendre l'exécution vérifiable, des tiers ont besoin des données d'état du Rollup ainsi que de la preuve d'exécution. Les données d'état et les preuves sont généralement publiées sur la couche de disponibilité des données (DA), et la transition d'état est vérifiée par la couche de validation (généralement appelée à tort couche de règlement).

Au début, Ethereum a élaboré une feuille de route centrée sur rollup et est devenu la couche de base initiale, tout en exécutant DA et vérification. L'état unique d'Ethereum (c'est-à-dire la grande quantité d'actifs de valeur émis sur Ethereum) en fait une couche de vérification naturelle pour rollup ou Règlement. En utilisant Ethereum comme base, rollup peut non seulement hériter de sa sécurité, mais aussi de sa Liquidité. Quoi qu'il en soit, il n'y avait pas d'options spécifiques de Règlement ou de DA sur le marché à l'époque.

Même dans le monde d'aujourd'hui avec de nombreux couches spécialisées, posséder le plus grand ensemble de validateurs PoS et le support blob sur Ethereum est également un choix très sûr en tant que couche DA. De plus, le nombre d'actifs familiaux sur Ethereum et la capitalisation boursière ont toujours été en hausse. Comme le 'Règlement' est spécifique à l'actif, la validation des rollups autorisant les retraits forcés doit se faire off-chain pour les actifs émis. Si un rollup souhaite autoriser les retraits forcés des actifs émis sur Ethereum, il doit les valider sur Ethereum.

Aujourd'hui, l'Éther semble être comme ceci :

Cependant, les couches spécialisées DA et Règlement sont également en concurrence directe avec Ethereum pour exécuter ces opérations. Par exemple, Celestia et EigenDA offrent déjà des débits DA nettement plus élevés (bien que les modèles de sécurité soient différents). De même, Initia étend le concept de validation ou de centre de règlement en offrant une expérience plus fluide aux utilisateurs de l'écosystème grâce à l'Oracle Machine, une expérience Portefeuille unifiée et une interopérabilité intégrée (ce qui est également un point important de la feuille de route d'Ethereum au cours des derniers mois).

Tous ces systèmes utilisent la même forme que Ethereum, la couche de base est décomposée en disponibilité des données et en validation, chaque couche servant de pivot spécialisé pour ses propres opérations :

La clé de la nouvelle conception réside dans la nécessité d'optimiser la séparation entre la couche DA et la couche de validation. Le rôle initial de la blockchain est de permettre une Décentralisation de confiance entre deux parties qui ne se font pas mutuellement confiance. Dans un système centré sur le rollup, le rôle de la couche de base est d'agir en tant que tierce partie de confiance pour la Décentralisation entre les rollups, afin de permettre leur interopérabilité. Une fois que la couche de base a validé l'état du rollup, tous les autres rollups peuvent implicitement lui faire confiance. Une autre caractéristique clé de la conception centrée sur le rollup est qu'elle permet aux applications d'offrir aux utilisateurs un accès rapide et bon marché à la confirmation des transactions dans des conditions moyennes (via un ordonnanceur centralisé dans une certaine mesure), sans compromettre l'audit final dans le pire des cas (par le biais d'une sortie forcée de la couche de base).

Étant donné notre compréhension de la séparation entre la disponibilité des données et la validation, ainsi que du rôle central de la couche de base dans la fourniture de la résistance finale, de l'interopérabilité entre les Rollups et de l'émission d'actifs, nous pouvons déduire comment construire une meilleure couche de base. Actuellement, les Rollups publient les données d'état sur la couche de base toutes les quelques heures, ce qui signifie que les préconfirmations fournies par le séquenceur Rollup ne sont finalisées sur la base que pendant cette période. Une couche de base avec un débit de données plus élevé que la couche L1 de l'ETH peut permettre aux Rollups de publier les données plus fréquemment, réduisant ainsi le temps entre la préconfirmation Rollup et la confirmation de la couche de base, renforçant ainsi la sécurité des Rollups. De même, une validation plus rapide entre les Rollups peut permettre une interopérabilité plus rapide entre eux, sans avoir besoin de ponts de liquidité ni de teneurs de marché. Nous pouvons utiliser des idées spécifiques sur la forme de la charge de travail que la couche de base doit gérer pour construire une couche de base avec un débit plus élevé et une communication plus rapide entre les Rollups.

L'intégration du Bloc a une zone de "état chaud", comme les pools DEX souvent attaqués. Cela rend l'ordre relatif des transactions de tous les participants très important. D'autre part, le rollup fonctionne généralement dans un espace d'état largement indépendant, la plupart des transactions n'affectant que l'état de son propre rollup. Bien que des interactions entre rollups se produisent (par exemple, lorsqu'un utilisateur transfère des actifs entre rollups ou combine des rollups), ces interactions sont explicites, clairement définies et prévisibles. Étant donné que la plupart des transactions dans chaque rollup fonctionnent de manière désynchronisée et que les transactions entre rollups sont gérées par des mécanismes d'interopérabilité spécifiques, la nécessité d'un strict ordonnancement global de toutes les données du rollup au niveau de la couche de base est moindre. Au contraire, l'ordonnancement peut être sélectivement appliqué uniquement lorsque les rollups interagissent explicitement.

Deux Rollup publient une liste de différences d'état vers la couche de base et leur preuve ZK de transition d'état.

Attention : Nous supposons que Rollup publie ici une liste de différences d'état ainsi que sa preuve ZK de transition d'état Rollup.

Les idées centrales ici tournent autour des relations de cause à effet entre les transactions, et soutiennent le travail considérable réalisé autour du modèle de consensus du Graphe acyclique orienté (DAG). En général, l'algorithme du DAG tente de mettre en évidence les dépendances afin que les calculs/traitements puissent être effectués en parallèle. En s'inspirant de ces idées, nous prévoyons l'émergence d'une couche de base rollup, où le consensus est largement assoupli pour soutenir un débit plus élevé et une latence plus faible.

La division naturelle de l'état de Rollup suggère que forcer toutes les transactions Rollup à suivre un ordre total peut être une dépense inutile. Des systèmes tels que delta et Hylé tirent parti de cette observation en permettant aux Rollup d'être indépendants et de ne coordonner que les transferts d'actifs entre domaines. Cependant, cela ne supprime pas complètement le consensus ; au contraire, c'est une amélioration là où le consensus est vraiment nécessaire. L'innovation réside dans la reconnaissance que cet ordre peut être limité aux endroits où il est réellement nécessaire, plutôt que d'être globalement imposé dans toutes les transactions.

L'impact majeur de cette partition est la création d'une solution Rollup élégante pour augmenter le débit de l'environnement d'exécution spécialisé sans compromettre la combinaison avec d'autres Rollups.

Tri causal et tri complet

Avant d'approfondir la discussion, revenons d'abord sur le classement. En termes généraux, le Consensus est le consensus des nœuds du réseau sur le classement des transactions valides:

• Les chaînes de blocs linéaires doivent parvenir à un consensus sur l'ordre total des transactions, c'est-à-dire l'ordre linéaire complet des événements tel qu'il apparaît à tous les nœuds participants. Les transactions non liées les unes aux autres sont toujours placées dans l'ordre global.
• D'autre part, l'ordre causal n'est qu'un ordre des transactions, c'est-à-dire que les transactions qui se produisent en premier sont classées avant les transactions qui dépendent de leurs sorties. Les transactions sans relation de cause à effet n'ont pas besoin d'être classées les unes par rapport aux autres. Cela s'appelle également une préférence partielle. DAG est simplement une structure de données qui met en œuvre une préférence partielle parmi un ensemble de transactions. La préférence partielle ouvre également la voie à l'exécution de transactions parallèles entre les parties non intersectantes du DAG. Ici, il n'y a pas d'ordre unique et global des transactions accepté par tous les nœuds.

La totalité peut être établie sur un DAG. Il nécessite un Mécanisme de consensus supplémentaire pour parvenir à un consensus sur l'ordre des événements concurrents. L'évolution la plus récente de Narwhal And Tuskprotocole ou Mysticeti de Sui en est un exemple.

Les transactions dans le DAG peuvent être confirmées indépendamment des autres transactions non apparentées. Une fois qu'une transaction est approuvée par la majorité des validateurs, elle est considérée comme valide. Permettre la confirmation individuelle des transactions plutôt que la confirmation des transactions dans un bloc peut considérablement augmenter le débit des transactions, car de nombreuses transactions peuvent être proposées et confirmées en parallèle. Cela peut être considéré comme une généralisation du consensus d'un leader unique, où n'importe quel validateur peut proposer de nouvelles transactions (Remarque : cela peut également être considéré comme la proposition d'un bloc contenant une seule transaction).

Résumons le fonctionnement de la vérification des transactions dans le DAG :

• L'utilisateur donne un sous-ensemble de Diffusion des transactions au validateur Nœud. Lorsque Nœud reçoit une transaction, il vérifie d'abord en fonction de sa vue locale du graphique si la transaction entre en conflit avec toute transaction qu'il connaît actuellement.
• En cas de conflit, par exemple si vous essayez de dépenser les mêmes fonds, la transaction sera refusée.
• Si aucune collision n'est détectée, le nœud accepteur interagit avec les autres nœuds du réseau pour parvenir à un consensus sur la validité de la transaction. Une méthode consiste à effectuer un sous-échantillonnage, où le nœud échantillonne un sous-ensemble d'autres nœuds et leur demande s'ils considèrent la transaction comme valide selon leur propre point de vue local. Si le seuil de réponse affirmative parmi les nœuds échantillonnés est atteint, le round de requête est considéré comme réussi, représentant un consensus atteint par un nombre suffisant de participants. Ce processus de sous-échantillonnage est répété jusqu'à ce que le nœud ait suffisamment confiance dans la validité de la transaction. Ce processus permet aux nœuds d'atteindre rapidement un consensus probabiliste sur la validité de la transaction, sans nécessiter de consensus global. La répétition de l'échantillonnage contribue à garantir un consensus global dans l'ensemble du réseau, rendant ainsi très improbable l'acceptation simultanée de transactions en conflit.

Sous-échantillonnage de vérification de transaction

Il convient de souligner que tout Nœud peut exécuter ce processus interactif à tout moment pour atteindre un consensus légal, permettant ainsi plusieurs chemins pour parvenir à un consensus. En un sens, chaque validateur ou réplique exécute sa propre blockchain et se synchronise régulièrement avec d'autres nœuds. L'idée de faire avancer plusieurs blockchains différentes avant de coordonner est également explorée dans les conceptions non DAG, comme Autobahn (toujours dépendant de la séparation de la diffusion et du tri des données). Dans Autobahn, chaque validateur maintient son propre canal de transactions, puis se coordonne lors du processus de synchronisation. Bien que cet article ne les appelle pas explicitement des blockchains, nous considérons que les canaux sont très proches des blockchains et que le processus de synchronisation est similaire à la fusion de plusieurs blockchains.

Relations de cause à effet dans la couche de base

Maintenant que nous comprenons le concept de causalité, nous pouvons essayer de relier ce concept à la couche de base. Comme mentionné précédemment, le rollup publie généralement des données d'état ou des listes de différences d'état correspondant aux mises à jour d'état de ses propres partitions persistantes. Les données publiées par deux rollups ne produiront pas de conflits pour certains "états chauds", car les données ne se chevauchent pas du tout. Cela assouplit le besoin de la couche de base pour un tri global. De plus, pour vérifier le nouvel état du rollup, il suffit de vérifier l'état du rollup précédemment publié. Ainsi, la couche de base peut librement trier ces transactions rollup, leur permettant de se dérouler de manière indépendante les unes des autres sans attendre de tri global :

Plus généralement, le rollup devrait pouvoir publier librement des données et des preuves sur la couche de base sans se soucier des frais. Lorsque les données se propagent dans le réseau, les validateurs de la couche de base valident les preuves publiées par le rollup. Si un certain nombre de validateurs valident la preuve, la transaction est considérée comme confirmée. Un tel système permettrait au rollup de confirmer les données à la vitesse de propagation de la couche de base. En théorie, cela devrait également raccourcir le délai entre la pré-confirmation du séquenceur et la confirmation de la couche de base.

Le système ci-dessus dépend de l'exécution basée sur ZK Sharding, et non de l'exécution de la réplication en tant qu'application vérifiable de l'avenir.

Les transactions inter-fragmentaires de transfert de données entre deux rollup nécessitent une mise en ordre, mais cela se fait par étapes. Par exemple, le transfert de l'actif X de rollup A à rollup B nécessite que les transactions de retrait de rollup A atteignent un nombre légal, puis que rollup B puisse inclure les transactions de dépôt. Une confirmation rapide de la couche de base fournira une garantie fiable pour l'interopérabilité entre les rollups au sein du même écosystème, créant ainsi un effet de réseau pour la couche de base. Une interopérabilité rapide combinée à une grande quantité d'actifs de valeur pourrait rendre la couche de base attrayante pour les rollups potentiels. En résumé, cette conception spécifique permettra:

• Le temps de confirmation des transactions Rollup est rapide.
• Interopérabilité rapide entre les Rollups (sans passerelle Liquidité ou teneur de marché).
• Débit d'air DA dédié à Rollup.
• Outil de vérification dédié pour Rollup (plus de systèmes de preuve).

Brève explication : accumulation de valeur des actifs de base

La discussion ci-dessus fournit une base bon marché, rapide et sûre pour le rollup. Cependant, la majeure partie de la discussion actuelle sur la feuille de route centrée sur le rollup tourne autour de l'accumulation de valeur d'ETH et d'Ethereum. Les L2 avec des relations utilisateur (comme Base) peuvent facturer une prime sur leur espace Bloc et ne rembourser qu'une petite partie de leurs revenus à Ethereum sous forme de frais DA.

En permettant aux rollups de publier plus fréquemment des données d'état pour une interopérabilité rapide, la couche de base peut gagner certains revenus qui auraient été perdus pour les fournisseurs de liquidité et les ponts de Liquidité. Bien que la valeur d'un système d'interopérabilité amélioré pour la couche de base dépend entièrement du nombre de rollups qui ont besoin de communiquer entre eux. Dans les configurations où les rollups ne répondent pas aux besoins de plusieurs applications, la valeur de la couche de base devient plus claire. Les applications n'ont qu'à interagir avec la couche de base pour réaliser la modularité. Les applications peuvent bénéficier d'une haute capacité de traitement et d'un contrôle sur leur espace sans sacrifier la modularité.

Certains arguments soutiennent que la valeur accumulée des Jetons natifs peut être améliorée en améliorant l'exécution de la couche de base. Cela permet en réalité à la couche de base de concurrencer rollup, ce qui va à l'encontre du principe de conception centré sur rollup. Une autre approche (peut-être notre préférée) consiste à construire un rollup consacré, où les actifs de la couche de base sont protégés en réaffectant les enjeux au classeur rollup. Si nécessaire, l'ensemble des validateurs de la couche de base peut même servir d'ensemble de classeurs pour rollup (bien que l'ensemble des validateurs n'ait pas besoin d'être identique). En fait, après le discours de Martin Köppelmann lors de Devcon 2024, le sujet du rollup consacré ou natif a commencé à gagner en popularité. Pour des écosystèmes comme Ethereum, cela permettrait à ETH de récupérer une partie de la valeur perdue, tout en permettant aux développeurs d'expérimenter plus librement sur rollup, car les enjeux du rollup pourraient être beaucoup plus faibles que ceux de la couche de base d'Ethereum.

Conclusion

Dans l'ensemble, nous pensons que l'ère de ZK représente un avenir véritablement passionnant et novateur pour Ethereum et l'ensemble de la blockchain. Dans cet article, nous exposons comment la combinaison de ZK avec un consensus de pointe représente une nouvelle direction potentielle pour la couche de base d'un système axé sur rollup. En combinant les preuves de connaissance nulle avec l'idée empruntée au mécanisme de consensus basé sur DAG, nous pouvons repenser la couche de base optimisée pour rollup. Le consensus est uniquement appliqué là où il y a un partage réel de l'état, et non comme une exigence uniforme pour toutes les opérations. À mesure que l'écosystème continue de se développer vers une conception modulaire, nous prévoyons que cette approche de consensus plus fine deviendra la norme pour les blockchains modulaires.

En général, nous pensons que compte tenu de plusieurs nouvelles technologies de support qui viennent d'être mises en production, la couche de base doit adopter cette technologie pour rester compétitive.

Nous ne devons pas avoir peur d'avoir des rêves plus grands.