À mesure que l'utilisation de Rollups augmente et héberge les applications de l'écosystème, les coûts de migration pour les utilisateurs augmenteront et les commandes centralisées acquerront une influence monopolistique sur les prix. Les contrôleurs des commandes centralisées sont justifiés de maximiser l'extraction de valeur (MEV) des utilisateurs à la fois directement (par exemple par le biais de frais) et indirectement (par exemple par le biais de transactions en amont, d'attaques en sandwich, etc.). - Expresso
Comme l'a mentionné l'équipe d'Espresso, les rollups centralisés seront éventuellement confrontés à des prix de monopole et à des problèmes de MEV. De plus, les rollups centralisés rompent intrinsèquement la composabilité, ce qui entraîne des rollups fragmentés. **
Cependant, presque tous les rollups actuels sont encore centralisés, car la création d'un rollup décentralisé, sans autorisation et évolutif est extrêmement difficile. Une autre raison est que le lancement de Rollups centralisés en premier peut aider à incuber l'écosystème et à gagner des parts de marché.
Et lorsque nous discutons des Rollups décentralisés, en particulier des zkRollups, il existe deux niveaux de décentralisation. La première est la décentralisation du démonstrateur, et la seconde est la décentralisation de l'ordonnateur. Pour parvenir à une décentralisation complète, il est également nécessaire de résoudre le problème de coordination entre le donneur d'ordre et le démonstrateur.
Dans le cadre de la tendance à la modularisation, il existe actuellement trois principaux types de participants au Rollup décentralisé. La première catégorie vise à réaliser des Rollups entièrement décentralisés et propose une solution complète. La deuxième catégorie est celle des protocoles conçus pour résoudre les réseaux de preuves. Enfin, il existe plusieurs solutions qui fonctionnent pour décentraliser le trieur.
Rollups décentralisés
Dans zkRollups, Polygon et Starknet ont trouvé des solutions pour décentraliser leurs Rollups.
Polygone
Avant l'introduction du POE (Proof of Efficiency), Polygon zkEVM a adopté le POD (Proof of Donation), permettant au trieur d'enchérir pour avoir l'opportunité de créer le prochain lot de transactions. Cependant, cela crée le problème qu'une seule partie malveillante peut contrôler l'ensemble du réseau en offrant le plus élevé.
Après avoir adopté POE, le donneur d'ordre et le prouveur participeront au réseau sans autorisation le plus efficacement possible dans leurs propres conditions matérielles. N'importe qui peut rejoindre le Polygon zkEVM tant que cela a un sens économique.
Dans Polygon zkEVM, le trieur nécessite 16 Go de RAM et un processeur à 4 cœurs, tandis que le prouveur nécessite 1 To de RAM et un processeur à 128 cœurs. De plus, il existe un rôle appelé agrégateur, qui est chargé de collecter les données L1, de les envoyer au prouveur, de recevoir la preuve et de la soumettre à L1. On peut considérer l'agrégateur et le prouveur comme le même sujet, car la relation entre l'agrégateur et le prouveur est très simple, et l'agrégateur paie le prouveur pour produire la preuve.
Cette architecture est très simple : n'importe quel ordonnateur peut empaqueter des transactions basées sur l'état précédent sur L1 sans autorisation, et mettre à jour l'état correspondant. Dans le même temps, tout agrégateur peut soumettre une preuve pour vérifier l'état mis à jour.
Dans POE, l'efficacité se réfère non seulement à l'efficacité du réseau des participants en concurrence les uns avec les autres, mais aussi à l'efficacité économique du séquenceur et du prouveur eux-mêmes. Dans L2, le donneur d'ordre et le prouveur partagent les frais de transaction, et le donneur d'ordre paie le batchFee à l'agrégateur pour générer la preuve. Cela garantit que les participants sont économiquement motivés pour contribuer à l'efficacité du réseau, ce qui se traduit par un écosystème plus robuste et durable.
trieur
Revenu : frais de transaction L2
Coût : batchFee (calculé en $MATIC) + frais de transaction L1 (méthode call sequenceBatches)
Agrégateur (Prover)
Revenu : batchFee (calculé en $MATIC)
Coût : coût de la preuve + frais de transaction L1 (appelez la méthode verifyBatchesTrustedAggregator)
Coordinateur : batchFee
paramètres initiaux
batchFee= 1 $MATIC
veryBatchTimeTarget = 30 minutes. Il s'agit de l'heure cible pour le lot de validation. Le protocole mettra à jour la variable batchFee pour atteindre ce temps cible.
multiplicateurBatchFee = 1002. Il s'agit du multiplicateur de frais de lot, allant de 1000 à 1024, avec 3 décimales.
Régulateur
diffBatches : le nombre de lots agrégés > 30 minutes moins le nombre de lots <= 30 minutes. La valeur maximale est 12.
Processus de coordination
Augmenter la récompense d'agrégation pour inciter les agrégateurs lorsque diffBatches> 0.
Lorsque diffBatches < 0, réduisez la récompense d'agrégation pour supprimer l'agrégateur et ralentir le processus d'agrégation.
Starknet
Starknet vise également à créer un Rollup sans autorisation et évolutif à confirmation rapide. Alors que la spécification finale de la solution décentralisée n'a pas encore été atteinte, ils ont publié quelques brouillons sur le forum il y a quelques mois.
Comparé au mécanisme simple de Polygon zkEVM, le schéma de Starknet est plus compliqué car il inclut le consensus L2 et la preuve enchaînée d'un protocole dans le réseau de preuve.
trieur
Au lieu d'ajouter simplement une couche de consensus au sein de la couche de commande, Starknet propose un protocole de consensus à double registre. Dans ce protocole, L2 fournit une réponse rapide en tant que protocole en direct, tandis que les points de contrôle L1 fournissent une confirmation finale en tant que protocole sûr.
Pour le protocole en direct de L2, divers mécanismes de consensus peuvent être adoptés, tels que des systèmes PoS résistants à Sybil tels que Tendermint ou DAG. D'autre part, le protocole sécurisé de L1 implique plusieurs contrats qui gèrent respectivement la gestion des enjeux, la vérification des preuves et la mise à jour du statut.
Le flux de travail typique du protocole de consensus à double registre est le suivant :
Tout d'abord, utilisez la sortie du registre dynamique L2 comme entrée du registre sécurisé L1 pour générer un registre dynamique vérifié.
Ensuite, prenez le registre en direct vérifié comme entrée et saisissez-le à nouveau dans le protocole de consensus pur de L2 pour vous assurer que le registre en direct vérifié est toujours le préfixe du registre en direct.
Répétez le processus ci-dessus.
Lors de la création d'un protocole de consensus à double registre, il existe un compromis entre le coût et la latence. La solution idéale vise à obtenir à la fois un faible coût et une approbation finale rapide.
Afin de réduire les coûts de gaz sur L2, Starknet divise les points de contrôle en "niveau minute" et "niveau heure". Pour les points de contrôle "au niveau minute", seul l'état lui-même est engagé dans la chaîne, tandis que le reste des données (preuves de validité, disponibilité des données, etc.) est envoyé sur le réseau StarkNet L2. Ces données sont stockées et vérifiées par les nœuds complets de StarkNet. En revanche, les points de contrôle "horaires" sont validés publiquement en L1. Les deux types de points de contrôle fournissent la même confirmation finale. Pour les points de contrôle "au niveau minute", la preuve de validité est vérifiée par les nœuds complets StarkNet et peut être émise par n'importe quel nœud sur L1 pour donner la finalité L1 aux points de contrôle "au niveau minute". Par conséquent, le prouveur doit générer de petites preuves à diffuser largement dans le réseau L2.
Pour réduire davantage la latence, Starknet propose un protocole d'élection du leader pour déterminer le leader à l'avance. La logique de base est la suivante : le leader de l'époque actuelle i est prédéterminé en fonction de la quantité de L1 jalonnée et d'un certain caractère aléatoire. Plus précisément, à l'époque i-2, la méthode leader_election place les trieurs en mosaïque lexicographiquement en fonction du nombre de promesses à l'époque i-3. Ensuite, envoyez une transaction pour mettre à jour le nonce et choisissez un point au hasard. Le trieur correspondant à la position où tombe le point sera le leader de l'époque i.
Certificateur
Dans le cadre du module POE, il y a une compétition ouverte entre les participants, ce qui peut conduire à une situation où le gagnant remporte tout. Starknet essaie de parvenir à un mécanisme de concurrence sans risque de centralisation. Voici quelques options:
Rotation : cela peut résoudre en partie le problème de la centralisation, mais peut ne pas fournir d'incitations pour trouver la meilleure personne pour prouver le travail.
Basé sur la mise : le trieur détermine la probabilité d'être élu comme prouveur en fonction du montant qu'il mise.
Schéma Commit-Reveal : le premier committer doit mettre en gage des jetons pour obtenir une courte opportunité de monopole, puis générer des preuves dans ce laps de temps. Afin d'éviter les attaques DDoS, si les premiers ne peuvent pas générer de preuves à temps, les jetons de garantie requis par les seconds augmenteront de façon exponentielle. Bien que sous ce mécanisme, le réseau peut perdre la machine avec les meilleures performances, mais plus de prouveurs peuvent être cultivés.
En plus de la concurrence entre les prouveurs, la barrière à l'entrée devrait être abaissée afin que davantage de prouveurs puissent participer au réseau. Starknet propose un protocole complexe utilisant des preuves récursives appelées preuves de protocole chaîné.
Dans les protocoles de preuve de chaîne, la blockchain elle-même est divisée en plusieurs fourches différentes. De cette façon, les preuves peuvent non seulement être récursives, mais la génération de preuves peut également être simultanée. Par exemple, dans un cadre à 3 branches, 12 blocs noirs sont divisés en 3 rangées, chaque rangée représentant une branche. Nous pouvons considérer chaque branche comme une sous-chaîne où chaque bloc doit attester du bloc précédent. Du point de vue de l'ensemble de la chaîne, le slot n doit prouver le slot n-3. L'intervalle de 3 blocs laisse suffisamment de temps au donneur d'ordre pour calculer et acheter des épreuves à l'avance. Ceci est quelque peu similaire au sharding, où un attaquant n'a besoin de contrôler qu'une seule branche pour contrôler l'ensemble du réseau de prouveurs.
Afin de tisser ces branches ensemble, Starknet propose une technologie de tissage qui peut fusionner plusieurs nœuds pour vérifier conjointement la légitimité des transactions et assurer la cohérence et la fiabilité des enregistrements de transaction.
Une solution consiste à exiger que chaque slot soit fusionné avec plusieurs branches en même temps. Une autre solution consiste à essayer alternativement chaque branche de fusionner avec d'autres branches, réduisant ainsi la charge de travail de la preuve. Bien sûr, c'est aussi un problème ouvert, et il peut y avoir de meilleures solutions à l'avenir.
coordination
Afin de s'assurer activement que le prouveur peut disposer d'un espace de profit suffisant, Starknet propose une méthode de référence au schéma EIP1559 : définissez les frais de base comme la limite inférieure du prix des ressources du prouveur, effectuez activement la découverte des prix et le trieur peut utiliser des conseils. pour motiver le démonstrateur. De cette façon, le prouveur sera toujours surpayé, et seuls les cas extrêmes affecteront le processus de preuve. Sinon, si l'étalon est payé près du prix du marché, une légère fluctuation pourrait déclencher un verrouillage de l'étalon.
Décentralisation du Certificateur
Du point de vue des Rollups, le prouveur est plus facile à décentraliser que le trieur. De plus, l'étalon actuel est un goulot d'étranglement en termes de performances et doit suivre la vitesse de traitement par lots de la trieuse. Lorsque la décentralisation du trieur n'est pas résolue, le prouveur décentralisé peut également fournir des services au trieur centralisé.
En fait, non seulement Rollups, zkBridge et zkOracle ont également besoin d'un réseau de preuves. Ils nécessitent tous un solide réseau distribué de prouveurs.
À long terme, un réseau de prouveurs pouvant accueillir différentes puissances de calcul est plus durable, sinon les machines les plus performantes monopoliseront le marché.
Marché de la preuve
Certains protocoles ne coordonnent pas la relation entre le séquenceur et le prouveur, mais abstrait directement la coordination dans un marché de preuve. Sur ce marché, les preuves sont des marchandises, les démonstrateurs sont des producteurs de preuves et les protocoles sont des consommateurs de preuves. L'équilibre du marché est le plus efficace sous l'influence de la "main invisible".
Exploiter
Mina a établi un marché de preuves appelé Snarketplace où les preuves Snark sont échangées. La plus petite unité ici est la preuve Snark d'une seule transaction. Mina utilise une preuve récursive d'arbre d'état appelée Scan State.
Scan State est une forêt d'arbres binaires où chaque transaction est un nœud. Une seule preuve est générée en haut de l'arborescence qui peut prouver toutes les transactions de l'arborescence. Le prouveur a deux tâches : la première est de générer des preuves, et la seconde est de fusionner des preuves.
Une fois que le prouveur a terminé le travail et soumis l'offre, le producteur de blocs du protocole Mina sélectionnera le soumissionnaire avec le prix le plus bas. C'est également le prix d'équilibre, car les soumissionnaires soumettront des offres supérieures au coût des épreuves, et les producteurs de blocs n'achèteront pas d'épreuves qui ne valent pas l'argent.
=Nul ; Fondation
Le marché de preuve de Mina est conçu pour son propre protocole, tandis que =nil; Foundation propose un marché de preuve général pour servir l'ensemble du marché.
Le service de marché se compose de trois composants : DROP DATABASE, zkLLVM et Proof Market.
DROP DATABASE : Il s'agit d'un protocole de système de gestion de base de données, qui peut être considéré comme une couche DA.
Proof Market : est une application qui s'exécute sur DROP DATABASE, similaire à ce que certains appellent un "échange décentralisé" à l'épreuve des zk.
zkLLVM : est un compilateur qui convertit les langages de programmation de haut niveau en entrées pour des protocoles informatiques prouvables.
Chaque preuve se compose de ses différentes entrées et circuits, de sorte que chaque preuve est unique. Un circuit définit un type de preuve, similaire à la façon dont une "paire de transaction" est définie en termes financiers. De plus, différents systèmes de preuve introduisent plus de circuits.
Le flux de travail est le suivant : le côté demande de la preuve peut écrire du code dans un langage de programmation de haut niveau, puis le transmettre à =nil;zkLLVM via la chaîne d'outils, générant un circuit unique qui deviendra une paire commerciale unique sur le marché.
Du côté de la demande de preuve, ils peuvent faire un compromis entre le coût et le temps. Les prouveurs prendront également en compte leur puissance de calcul et leurs revenus. Par conséquent, sur le marché, il y aura différentes puissances de calcul, une puissance de calcul élevée générera des preuves plus rapidement, mais à un coût plus élevé, tandis qu'une faible puissance de calcul générera des preuves plus lentement, mais moins chères.
ENGAGEMENT EN DEUX ÉTAPES
Récemment, Opside a proposé un schéma de validation en deux étapes pour décentraliser le réseau de preuves. Le schéma divise la soumission de la preuve en deux phases pour éviter la situation où le prouveur le plus rapide gagne toujours.
Étape 1 : Soumettez le hachage de la preuve de connaissance nulle du T-ème bloc
À partir du bloc T+11, les nouveaux prouveurs ne sont plus autorisés à soumettre des hachages.
* Étape 2 : soumettre une preuve de connaissance nulle
Après le bloc T + 11, tout prouveur peut soumettre une preuve sans connaissance. Si au moins une preuve de connaissance zéro réussit la vérification, elle sera utilisée pour vérifier tous les hachages soumis, et le prouveur vérifié recevra les récompenses PoW correspondantes proportionnellement au montant de l'hypothèque.
Si aucune preuve de connaissance zéro n'est vérifiée avant le bloc T + 20, tous les prouveurs qui ont soumis des hachages seront pénalisés. Puis rouvrez le trieur, vous pouvez soumettre un nouveau hash, revenez à l'étape 1.
Cette méthode peut s'adapter à différentes puissances de calcul. Cependant, la garantie requise introduit toujours un niveau de centralisation.
Décentralisation du trieur
La décentralisation des donneurs d'ordre est plus complexe que celle des valideurs. En effet, le trieur a le pouvoir de regrouper et d'organiser les transactions, et des questions telles que le MEV et la répartition des revenus doivent être prises en compte.
Étant donné qu'Ethereum privilégiera la vivacité à la réactivité, les solutions L2 devraient compléter ce compromis en privilégiant la réactivité à la vivacité. Cependant, par rapport aux trieurs centralisés, les trieurs décentralisés sacrifient intrinsèquement en termes de réactivité. Par conséquent, diverses optimisations doivent être mises en œuvre pour résoudre ce dilemme.
Actuellement, il existe trois propositions différentes de trieurs décentralisés. La première solution est réalisée en optimisant le mécanisme de consensus. Le deuxième schéma implique un réseau de séquenceurs partagés. Le troisième schéma est basé sur les validateurs L1.
consensus
Le protocole de consensus est principalement chargé d'ordonner les transactions et d'assurer leur disponibilité, pas de les exécuter. Cependant, ajouter directement une autre couche de consensus, comme mentionné précédemment, n'est pas une solution facile.
Pour améliorer la réactivité, une approche courante consiste à s'appuyer sur un ensemble plus restreint de validateurs. Par exemple, Algorand et Polkadot utilisent des comités plus petits échantillonnés au hasard pour regrouper les transactions. Tous les nœuds utilisent des balises aléatoires et une fonction aléatoire vérifiable (VRF), avec une probabilité d'être inclus dans un comité dans une période donnée proportionnelle à leur montant misé.
Pour réduire le trafic réseau, des comités de disponibilité des données (DA) plus petits peuvent être utilisés. Ou utilisez VID (Dispersion d'informations vérifiables). VID distribue le code d'effacement des données à tous les nœuds participant au consensus, de sorte que tout sous-ensemble de nœuds détenant un taux de promesse suffisamment élevé puisse coopérer pour restaurer les données. Le compromis de cette approche est de réduire la complexité de la diffusion, mais d'augmenter la complexité de la récupération des données.
Arbitrum a sélectionné des entités réputées pour former l'ensemble de validateurs, telles que ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, IFF's Distributed Ledger Research Center (DLRC) et Unit 410 pour rejoindre le Sorter Committee. Le compromis de cette approche est de compenser le manque de quantité en améliorant la qualité de la décentralisation.
Réseau de séquenceur partagé
Les trieurs jouent un rôle essentiel dans les blockchains modulaires, en particulier dans les Rollups. Chaque Rollup construit généralement son propre réseau de trieurs. Cependant, cette approche crée non seulement des problèmes de redondance, mais entrave également la composabilité. Pour résoudre ce problème, certains protocoles proposent de construire un réseau partagé de trieur Rollup. Cette approche réduit la complexité de la réalisation de l'atomicité, de la composabilité et de l'interopérabilité, des fonctionnalités dont les utilisateurs et les développeurs ont désespérément besoin dans les blockchains ouvertes et sans autorisation. De plus, cela élimine également le besoin d'un client léger séparé pour le réseau du donneur d'ordre.
Autriche
Astria développe une blockchain middleware pour l'écosystème Rollup de Celestia, qui comprend sa propre collection de commandes distribuées. Cet ensemble de trieurs est chargé d'accepter les transactions de plusieurs Rollups et de les écrire dans la couche de base sans les exécuter.
Le rôle d'Astria est principalement axé sur la commande de transactions et fonctionne indépendamment de la couche de base et du Rollup. Les données de transaction sont stockées sur la couche de base (par exemple, Celestia), tandis que les nœuds complets Rollup maintiennent l'état et exécutent les opérations. Cela garantit qu'Astria est dissociée de Rollup.
Pour la finalité, Astria propose deux niveaux d'engagement :
"Engagement souple": permet à Rollup de fournir des confirmations de blocage rapides à ses utilisateurs finaux.
« Engagement ferme » : la vitesse est la même que celle de la couche de base, garantissant une sécurité et une finalité supérieures.
Expresso
Espresso a apporté une contribution significative dans le domaine de la technologie sans connaissance. Leur dernier développement est une solution complète pour les trieurs décentralisés qui peut être appliquée aux Optimistic Rollups et zkRollups.
Le réseau de commande décentralisé se compose de :
Consensus HotShot : privilégiez le débit élevé et la finalité rapide à la disponibilité dynamique.
Espresso DA : combinaison d'une solution DA basée sur un comité et d'un VID, où les nœuds à large bande passante transmettent les données à tous les autres nœuds. La disponibilité de chaque bloc individuel est également soutenue par un petit comité élu au hasard. Les VID fournissent une sauvegarde fiable mais plus lente, garantissant la disponibilité tant qu'un pourcentage suffisamment élevé du poids jalonné de tous les nœuds n'est pas compromis.
API Rollup REST : Ethereum compatible avec JSON-RPC.
Contrat de séquenceur : vérifiez le consensus HotShot (c'est-à-dire, agissez en tant que client léger) et enregistrez les points de contrôle (c'est-à-dire, faites un engagement cryptographique à la transaction), et gérez la table de gage de HotShot.
Réseau P2P : protocole Gossip.
Par rapport à Astria, Espresso propose DA. Par conséquent, le flux de travail sera légèrement différent, comme suit :
L'utilisateur crée et soumet une transaction à Rollup.
La transaction est propagée à travers le réseau du donneur d'ordre et conservée dans le mempool.
Désignez un leader via le mécanisme de promesse HotShot, proposez un bloc et propagez-le aux exécuteurs et aux prouveurs de Rollup.
Le leader envoie la transaction au comité de disponibilité des données et reçoit un certificat DA en retour.
Le leader envoie également un engagement pour le bloc au contrat de trieur de couche 1, ainsi que le certificat que le contrat utilise pour valider le bloc.
Espresso introduit le protocole Gossip pour les preuves afin de fournir une expérience utilisateur plus flexible. Il offre trois options pour la finalité de la transaction :
Rapide : les utilisateurs peuvent faire confiance au serveur Rollup qui a exécuté la transaction et généré la preuve, ou ils peuvent profiter de la faible latence de HotShot pour exécuter la transaction.
Modéré : L'utilisateur peut attendre un moment que la preuve soit générée, puis la vérifier.
Lent : les utilisateurs peuvent attendre les mises à jour de l'état vérifié L1 pour obtenir l'état mis à jour sans aucune hypothèse ou calcul de confiance.
En plus des optimisations ci-dessus, Espresso prévoit également de faire participer l'ensemble du validateur Ethereum lui-même à l'exécution du protocole de commande Espresso. L'utilisation du même ensemble de validateurs fournira une sécurité similaire, et le partage de valeur avec les validateurs L1 sera plus sécurisé. En outre, Espresso peut également tirer parti de la solution de réimplantation ETH fournie par EigenLayer.
Rayon
Radius construit une couche de commande partagée sans confiance basée sur des preuves à connaissance nulle, en se concentrant sur la résolution du problème MEV en L2, car les revenus de L2 proviennent principalement de l'espace de bloc. Le compromis à considérer est l'équilibre entre les revenus MEV et L2. L'objectif de Radius est d'éliminer le MEV, néfaste pour les utilisateurs, et propose un service à deux niveaux.
La couche supérieure cible les transactions régulières des utilisateurs et fournit une protection cryptographique contre les MEV indésirables grâce à l'utilisation de puzzles timelock. Plus précisément, il utilise la technologie PVDE (Practical Verifiable Delayed Encryption), qui générera en 5 secondes des preuves à connaissance nulle pour les puzzles de verrouillage temporel basés sur RSA. Cette méthode fournit une solution pratique pour protéger les utilisateurs contre les MEV nocifs. En bref, le contenu de la transaction ne peut être connu tant que le séquenceur n'a pas déterminé l'ordre des transactions.
La couche sous-jacente est conçue pour les constructeurs de blocs et leur permet de participer à des activités génératrices de revenus tout en atténuant l'impact négatif du MEV.
Rollups basés sur
Based Rollup est un concept récemment proposé par Justin Drake, où les proposants de bloc L1 coopèrent avec les chercheurs et les constructeurs L1 pour inclure des blocs de cumul dans le prochain bloc L1 sans autorisation. Il peut être vu comme un réseau de séquenceurs partagés sur L1. Les avantages et les inconvénients de Based Rollup sont évidents.
Du côté positif, Based Rollup tire parti de la vivacité et de la décentralisation fournies par L1, et sa mise en œuvre est simple et efficace. Le cumul basé est également économiquement cohérent avec L1. Cependant, cela ne signifie pas que Based Rollup compromet sa souveraineté. Bien que MEV soit transféré à L1, Based Rollup peut toujours posséder des jetons de gouvernance et facturer des frais de base. Sur la base de l'hypothèse, Based Rollup peut tirer parti de ces avantages, atteindre une position dominante et, en fin de compte, maximiser les rendements.
en conclusion
Au vu des propositions proposées, on constate que la décentralisation de Rollup a encore un long chemin à parcourir. Certaines de ces propositions sont encore à l'état de projet et nécessitent des discussions plus approfondies, tandis que d'autres n'ont complété que des spécifications préliminaires. Tous ces scénarios doivent être mis en œuvre et rigoureusement testés.
Bien que certains Rollups ne proposent pas explicitement une solution décentralisée correspondante, ils incluent souvent des mécanismes d'échappement pour traiter les points de défaillance uniques dus aux commandes centralisées. Par exemple, zkSync fournit une méthode FullExit qui permet aux utilisateurs de retirer leurs fonds directement de L1. Lorsque le système entre en mode exode et ne peut pas traiter de nouveaux blocs, l'utilisateur peut initier une opération de retrait.
Pour obtenir une résistance à la censure, ces Rollups permettent souvent aux utilisateurs de soumettre des transactions directement sur L1. Par exemple, zkSync utilise une file d'attente prioritaire pour de telles transactions envoyées sur L1. De même, Polygon zkEVM inclut une méthode de lot forcé dans le contrat L1. Lorsqu'aucune agrégation ne se produit dans une semaine, l'utilisateur peut appeler cette méthode sur L1 et fournir le tableau d'octets et bathFee de la transaction au prouveur.
Ce qui est certain, c'est que dans un avenir prévisible, la décentralisation de Rollup sera une solution combinée, qui pourra inclure les solutions importantes susmentionnées ou d'autres variantes innovantes.
Voir l'original
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.
Comprendre les cumuls décentralisés dans un article
Titre original : "Decentralized Rollups"
À mesure que l'utilisation de Rollups augmente et héberge les applications de l'écosystème, les coûts de migration pour les utilisateurs augmenteront et les commandes centralisées acquerront une influence monopolistique sur les prix. Les contrôleurs des commandes centralisées sont justifiés de maximiser l'extraction de valeur (MEV) des utilisateurs à la fois directement (par exemple par le biais de frais) et indirectement (par exemple par le biais de transactions en amont, d'attaques en sandwich, etc.). - Expresso
Comme l'a mentionné l'équipe d'Espresso, les rollups centralisés seront éventuellement confrontés à des prix de monopole et à des problèmes de MEV. De plus, les rollups centralisés rompent intrinsèquement la composabilité, ce qui entraîne des rollups fragmentés. **
Cependant, presque tous les rollups actuels sont encore centralisés, car la création d'un rollup décentralisé, sans autorisation et évolutif est extrêmement difficile. Une autre raison est que le lancement de Rollups centralisés en premier peut aider à incuber l'écosystème et à gagner des parts de marché.
Et lorsque nous discutons des Rollups décentralisés, en particulier des zkRollups, il existe deux niveaux de décentralisation. La première est la décentralisation du démonstrateur, et la seconde est la décentralisation de l'ordonnateur. Pour parvenir à une décentralisation complète, il est également nécessaire de résoudre le problème de coordination entre le donneur d'ordre et le démonstrateur.
Dans le cadre de la tendance à la modularisation, il existe actuellement trois principaux types de participants au Rollup décentralisé. La première catégorie vise à réaliser des Rollups entièrement décentralisés et propose une solution complète. La deuxième catégorie est celle des protocoles conçus pour résoudre les réseaux de preuves. Enfin, il existe plusieurs solutions qui fonctionnent pour décentraliser le trieur.
Rollups décentralisés
Dans zkRollups, Polygon et Starknet ont trouvé des solutions pour décentraliser leurs Rollups.
Polygone
Avant l'introduction du POE (Proof of Efficiency), Polygon zkEVM a adopté le POD (Proof of Donation), permettant au trieur d'enchérir pour avoir l'opportunité de créer le prochain lot de transactions. Cependant, cela crée le problème qu'une seule partie malveillante peut contrôler l'ensemble du réseau en offrant le plus élevé.
Après avoir adopté POE, le donneur d'ordre et le prouveur participeront au réseau sans autorisation le plus efficacement possible dans leurs propres conditions matérielles. N'importe qui peut rejoindre le Polygon zkEVM tant que cela a un sens économique.
Dans Polygon zkEVM, le trieur nécessite 16 Go de RAM et un processeur à 4 cœurs, tandis que le prouveur nécessite 1 To de RAM et un processeur à 128 cœurs. De plus, il existe un rôle appelé agrégateur, qui est chargé de collecter les données L1, de les envoyer au prouveur, de recevoir la preuve et de la soumettre à L1. On peut considérer l'agrégateur et le prouveur comme le même sujet, car la relation entre l'agrégateur et le prouveur est très simple, et l'agrégateur paie le prouveur pour produire la preuve.
Cette architecture est très simple : n'importe quel ordonnateur peut empaqueter des transactions basées sur l'état précédent sur L1 sans autorisation, et mettre à jour l'état correspondant. Dans le même temps, tout agrégateur peut soumettre une preuve pour vérifier l'état mis à jour.
Dans POE, l'efficacité se réfère non seulement à l'efficacité du réseau des participants en concurrence les uns avec les autres, mais aussi à l'efficacité économique du séquenceur et du prouveur eux-mêmes. Dans L2, le donneur d'ordre et le prouveur partagent les frais de transaction, et le donneur d'ordre paie le batchFee à l'agrégateur pour générer la preuve. Cela garantit que les participants sont économiquement motivés pour contribuer à l'efficacité du réseau, ce qui se traduit par un écosystème plus robuste et durable.
trieur
Agrégateur (Prover)
Coordinateur : batchFee
Starknet
Starknet vise également à créer un Rollup sans autorisation et évolutif à confirmation rapide. Alors que la spécification finale de la solution décentralisée n'a pas encore été atteinte, ils ont publié quelques brouillons sur le forum il y a quelques mois.
Comparé au mécanisme simple de Polygon zkEVM, le schéma de Starknet est plus compliqué car il inclut le consensus L2 et la preuve enchaînée d'un protocole dans le réseau de preuve.
trieur
Au lieu d'ajouter simplement une couche de consensus au sein de la couche de commande, Starknet propose un protocole de consensus à double registre. Dans ce protocole, L2 fournit une réponse rapide en tant que protocole en direct, tandis que les points de contrôle L1 fournissent une confirmation finale en tant que protocole sûr.
Pour le protocole en direct de L2, divers mécanismes de consensus peuvent être adoptés, tels que des systèmes PoS résistants à Sybil tels que Tendermint ou DAG. D'autre part, le protocole sécurisé de L1 implique plusieurs contrats qui gèrent respectivement la gestion des enjeux, la vérification des preuves et la mise à jour du statut.
Le flux de travail typique du protocole de consensus à double registre est le suivant :
Tout d'abord, utilisez la sortie du registre dynamique L2 comme entrée du registre sécurisé L1 pour générer un registre dynamique vérifié.
Ensuite, prenez le registre en direct vérifié comme entrée et saisissez-le à nouveau dans le protocole de consensus pur de L2 pour vous assurer que le registre en direct vérifié est toujours le préfixe du registre en direct.
Répétez le processus ci-dessus.
Lors de la création d'un protocole de consensus à double registre, il existe un compromis entre le coût et la latence. La solution idéale vise à obtenir à la fois un faible coût et une approbation finale rapide.
Afin de réduire les coûts de gaz sur L2, Starknet divise les points de contrôle en "niveau minute" et "niveau heure". Pour les points de contrôle "au niveau minute", seul l'état lui-même est engagé dans la chaîne, tandis que le reste des données (preuves de validité, disponibilité des données, etc.) est envoyé sur le réseau StarkNet L2. Ces données sont stockées et vérifiées par les nœuds complets de StarkNet. En revanche, les points de contrôle "horaires" sont validés publiquement en L1. Les deux types de points de contrôle fournissent la même confirmation finale. Pour les points de contrôle "au niveau minute", la preuve de validité est vérifiée par les nœuds complets StarkNet et peut être émise par n'importe quel nœud sur L1 pour donner la finalité L1 aux points de contrôle "au niveau minute". Par conséquent, le prouveur doit générer de petites preuves à diffuser largement dans le réseau L2.
Pour réduire davantage la latence, Starknet propose un protocole d'élection du leader pour déterminer le leader à l'avance. La logique de base est la suivante : le leader de l'époque actuelle i est prédéterminé en fonction de la quantité de L1 jalonnée et d'un certain caractère aléatoire. Plus précisément, à l'époque i-2, la méthode leader_election place les trieurs en mosaïque lexicographiquement en fonction du nombre de promesses à l'époque i-3. Ensuite, envoyez une transaction pour mettre à jour le nonce et choisissez un point au hasard. Le trieur correspondant à la position où tombe le point sera le leader de l'époque i.
Certificateur
Dans le cadre du module POE, il y a une compétition ouverte entre les participants, ce qui peut conduire à une situation où le gagnant remporte tout. Starknet essaie de parvenir à un mécanisme de concurrence sans risque de centralisation. Voici quelques options:
En plus de la concurrence entre les prouveurs, la barrière à l'entrée devrait être abaissée afin que davantage de prouveurs puissent participer au réseau. Starknet propose un protocole complexe utilisant des preuves récursives appelées preuves de protocole chaîné.
Dans les protocoles de preuve de chaîne, la blockchain elle-même est divisée en plusieurs fourches différentes. De cette façon, les preuves peuvent non seulement être récursives, mais la génération de preuves peut également être simultanée. Par exemple, dans un cadre à 3 branches, 12 blocs noirs sont divisés en 3 rangées, chaque rangée représentant une branche. Nous pouvons considérer chaque branche comme une sous-chaîne où chaque bloc doit attester du bloc précédent. Du point de vue de l'ensemble de la chaîne, le slot n doit prouver le slot n-3. L'intervalle de 3 blocs laisse suffisamment de temps au donneur d'ordre pour calculer et acheter des épreuves à l'avance. Ceci est quelque peu similaire au sharding, où un attaquant n'a besoin de contrôler qu'une seule branche pour contrôler l'ensemble du réseau de prouveurs.
Afin de tisser ces branches ensemble, Starknet propose une technologie de tissage qui peut fusionner plusieurs nœuds pour vérifier conjointement la légitimité des transactions et assurer la cohérence et la fiabilité des enregistrements de transaction.
Une solution consiste à exiger que chaque slot soit fusionné avec plusieurs branches en même temps. Une autre solution consiste à essayer alternativement chaque branche de fusionner avec d'autres branches, réduisant ainsi la charge de travail de la preuve. Bien sûr, c'est aussi un problème ouvert, et il peut y avoir de meilleures solutions à l'avenir.
coordination
Afin de s'assurer activement que le prouveur peut disposer d'un espace de profit suffisant, Starknet propose une méthode de référence au schéma EIP1559 : définissez les frais de base comme la limite inférieure du prix des ressources du prouveur, effectuez activement la découverte des prix et le trieur peut utiliser des conseils. pour motiver le démonstrateur. De cette façon, le prouveur sera toujours surpayé, et seuls les cas extrêmes affecteront le processus de preuve. Sinon, si l'étalon est payé près du prix du marché, une légère fluctuation pourrait déclencher un verrouillage de l'étalon.
Décentralisation du Certificateur
Du point de vue des Rollups, le prouveur est plus facile à décentraliser que le trieur. De plus, l'étalon actuel est un goulot d'étranglement en termes de performances et doit suivre la vitesse de traitement par lots de la trieuse. Lorsque la décentralisation du trieur n'est pas résolue, le prouveur décentralisé peut également fournir des services au trieur centralisé.
En fait, non seulement Rollups, zkBridge et zkOracle ont également besoin d'un réseau de preuves. Ils nécessitent tous un solide réseau distribué de prouveurs.
À long terme, un réseau de prouveurs pouvant accueillir différentes puissances de calcul est plus durable, sinon les machines les plus performantes monopoliseront le marché.
Marché de la preuve
Certains protocoles ne coordonnent pas la relation entre le séquenceur et le prouveur, mais abstrait directement la coordination dans un marché de preuve. Sur ce marché, les preuves sont des marchandises, les démonstrateurs sont des producteurs de preuves et les protocoles sont des consommateurs de preuves. L'équilibre du marché est le plus efficace sous l'influence de la "main invisible".
Exploiter
Mina a établi un marché de preuves appelé Snarketplace où les preuves Snark sont échangées. La plus petite unité ici est la preuve Snark d'une seule transaction. Mina utilise une preuve récursive d'arbre d'état appelée Scan State.
Scan State est une forêt d'arbres binaires où chaque transaction est un nœud. Une seule preuve est générée en haut de l'arborescence qui peut prouver toutes les transactions de l'arborescence. Le prouveur a deux tâches : la première est de générer des preuves, et la seconde est de fusionner des preuves.
Une fois que le prouveur a terminé le travail et soumis l'offre, le producteur de blocs du protocole Mina sélectionnera le soumissionnaire avec le prix le plus bas. C'est également le prix d'équilibre, car les soumissionnaires soumettront des offres supérieures au coût des épreuves, et les producteurs de blocs n'achèteront pas d'épreuves qui ne valent pas l'argent.
=Nul ; Fondation
Le marché de preuve de Mina est conçu pour son propre protocole, tandis que =nil; Foundation propose un marché de preuve général pour servir l'ensemble du marché.
Le service de marché se compose de trois composants : DROP DATABASE, zkLLVM et Proof Market.
Chaque preuve se compose de ses différentes entrées et circuits, de sorte que chaque preuve est unique. Un circuit définit un type de preuve, similaire à la façon dont une "paire de transaction" est définie en termes financiers. De plus, différents systèmes de preuve introduisent plus de circuits.
Le flux de travail est le suivant : le côté demande de la preuve peut écrire du code dans un langage de programmation de haut niveau, puis le transmettre à =nil;zkLLVM via la chaîne d'outils, générant un circuit unique qui deviendra une paire commerciale unique sur le marché.
Du côté de la demande de preuve, ils peuvent faire un compromis entre le coût et le temps. Les prouveurs prendront également en compte leur puissance de calcul et leurs revenus. Par conséquent, sur le marché, il y aura différentes puissances de calcul, une puissance de calcul élevée générera des preuves plus rapidement, mais à un coût plus élevé, tandis qu'une faible puissance de calcul générera des preuves plus lentement, mais moins chères.
ENGAGEMENT EN DEUX ÉTAPES
Récemment, Opside a proposé un schéma de validation en deux étapes pour décentraliser le réseau de preuves. Le schéma divise la soumission de la preuve en deux phases pour éviter la situation où le prouveur le plus rapide gagne toujours.
* Étape 2 : soumettre une preuve de connaissance nulle
Cette méthode peut s'adapter à différentes puissances de calcul. Cependant, la garantie requise introduit toujours un niveau de centralisation.
Décentralisation du trieur
La décentralisation des donneurs d'ordre est plus complexe que celle des valideurs. En effet, le trieur a le pouvoir de regrouper et d'organiser les transactions, et des questions telles que le MEV et la répartition des revenus doivent être prises en compte.
Étant donné qu'Ethereum privilégiera la vivacité à la réactivité, les solutions L2 devraient compléter ce compromis en privilégiant la réactivité à la vivacité. Cependant, par rapport aux trieurs centralisés, les trieurs décentralisés sacrifient intrinsèquement en termes de réactivité. Par conséquent, diverses optimisations doivent être mises en œuvre pour résoudre ce dilemme.
Actuellement, il existe trois propositions différentes de trieurs décentralisés. La première solution est réalisée en optimisant le mécanisme de consensus. Le deuxième schéma implique un réseau de séquenceurs partagés. Le troisième schéma est basé sur les validateurs L1.
consensus
Le protocole de consensus est principalement chargé d'ordonner les transactions et d'assurer leur disponibilité, pas de les exécuter. Cependant, ajouter directement une autre couche de consensus, comme mentionné précédemment, n'est pas une solution facile.
Pour améliorer la réactivité, une approche courante consiste à s'appuyer sur un ensemble plus restreint de validateurs. Par exemple, Algorand et Polkadot utilisent des comités plus petits échantillonnés au hasard pour regrouper les transactions. Tous les nœuds utilisent des balises aléatoires et une fonction aléatoire vérifiable (VRF), avec une probabilité d'être inclus dans un comité dans une période donnée proportionnelle à leur montant misé.
Pour réduire le trafic réseau, des comités de disponibilité des données (DA) plus petits peuvent être utilisés. Ou utilisez VID (Dispersion d'informations vérifiables). VID distribue le code d'effacement des données à tous les nœuds participant au consensus, de sorte que tout sous-ensemble de nœuds détenant un taux de promesse suffisamment élevé puisse coopérer pour restaurer les données. Le compromis de cette approche est de réduire la complexité de la diffusion, mais d'augmenter la complexité de la récupération des données.
Arbitrum a sélectionné des entités réputées pour former l'ensemble de validateurs, telles que ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, IFF's Distributed Ledger Research Center (DLRC) et Unit 410 pour rejoindre le Sorter Committee. Le compromis de cette approche est de compenser le manque de quantité en améliorant la qualité de la décentralisation.
Réseau de séquenceur partagé
Les trieurs jouent un rôle essentiel dans les blockchains modulaires, en particulier dans les Rollups. Chaque Rollup construit généralement son propre réseau de trieurs. Cependant, cette approche crée non seulement des problèmes de redondance, mais entrave également la composabilité. Pour résoudre ce problème, certains protocoles proposent de construire un réseau partagé de trieur Rollup. Cette approche réduit la complexité de la réalisation de l'atomicité, de la composabilité et de l'interopérabilité, des fonctionnalités dont les utilisateurs et les développeurs ont désespérément besoin dans les blockchains ouvertes et sans autorisation. De plus, cela élimine également le besoin d'un client léger séparé pour le réseau du donneur d'ordre.
Autriche
Astria développe une blockchain middleware pour l'écosystème Rollup de Celestia, qui comprend sa propre collection de commandes distribuées. Cet ensemble de trieurs est chargé d'accepter les transactions de plusieurs Rollups et de les écrire dans la couche de base sans les exécuter.
Le rôle d'Astria est principalement axé sur la commande de transactions et fonctionne indépendamment de la couche de base et du Rollup. Les données de transaction sont stockées sur la couche de base (par exemple, Celestia), tandis que les nœuds complets Rollup maintiennent l'état et exécutent les opérations. Cela garantit qu'Astria est dissociée de Rollup.
Pour la finalité, Astria propose deux niveaux d'engagement :
Expresso
Espresso a apporté une contribution significative dans le domaine de la technologie sans connaissance. Leur dernier développement est une solution complète pour les trieurs décentralisés qui peut être appliquée aux Optimistic Rollups et zkRollups.
Le réseau de commande décentralisé se compose de :
Par rapport à Astria, Espresso propose DA. Par conséquent, le flux de travail sera légèrement différent, comme suit :
L'utilisateur crée et soumet une transaction à Rollup.
La transaction est propagée à travers le réseau du donneur d'ordre et conservée dans le mempool.
Désignez un leader via le mécanisme de promesse HotShot, proposez un bloc et propagez-le aux exécuteurs et aux prouveurs de Rollup.
Le leader envoie la transaction au comité de disponibilité des données et reçoit un certificat DA en retour.
Le leader envoie également un engagement pour le bloc au contrat de trieur de couche 1, ainsi que le certificat que le contrat utilise pour valider le bloc.
Espresso introduit le protocole Gossip pour les preuves afin de fournir une expérience utilisateur plus flexible. Il offre trois options pour la finalité de la transaction :
En plus des optimisations ci-dessus, Espresso prévoit également de faire participer l'ensemble du validateur Ethereum lui-même à l'exécution du protocole de commande Espresso. L'utilisation du même ensemble de validateurs fournira une sécurité similaire, et le partage de valeur avec les validateurs L1 sera plus sécurisé. En outre, Espresso peut également tirer parti de la solution de réimplantation ETH fournie par EigenLayer.
Rayon
Radius construit une couche de commande partagée sans confiance basée sur des preuves à connaissance nulle, en se concentrant sur la résolution du problème MEV en L2, car les revenus de L2 proviennent principalement de l'espace de bloc. Le compromis à considérer est l'équilibre entre les revenus MEV et L2. L'objectif de Radius est d'éliminer le MEV, néfaste pour les utilisateurs, et propose un service à deux niveaux.
La couche supérieure cible les transactions régulières des utilisateurs et fournit une protection cryptographique contre les MEV indésirables grâce à l'utilisation de puzzles timelock. Plus précisément, il utilise la technologie PVDE (Practical Verifiable Delayed Encryption), qui générera en 5 secondes des preuves à connaissance nulle pour les puzzles de verrouillage temporel basés sur RSA. Cette méthode fournit une solution pratique pour protéger les utilisateurs contre les MEV nocifs. En bref, le contenu de la transaction ne peut être connu tant que le séquenceur n'a pas déterminé l'ordre des transactions.
La couche sous-jacente est conçue pour les constructeurs de blocs et leur permet de participer à des activités génératrices de revenus tout en atténuant l'impact négatif du MEV.
Rollups basés sur
Based Rollup est un concept récemment proposé par Justin Drake, où les proposants de bloc L1 coopèrent avec les chercheurs et les constructeurs L1 pour inclure des blocs de cumul dans le prochain bloc L1 sans autorisation. Il peut être vu comme un réseau de séquenceurs partagés sur L1. Les avantages et les inconvénients de Based Rollup sont évidents.
Du côté positif, Based Rollup tire parti de la vivacité et de la décentralisation fournies par L1, et sa mise en œuvre est simple et efficace. Le cumul basé est également économiquement cohérent avec L1. Cependant, cela ne signifie pas que Based Rollup compromet sa souveraineté. Bien que MEV soit transféré à L1, Based Rollup peut toujours posséder des jetons de gouvernance et facturer des frais de base. Sur la base de l'hypothèse, Based Rollup peut tirer parti de ces avantages, atteindre une position dominante et, en fin de compte, maximiser les rendements.
en conclusion
Au vu des propositions proposées, on constate que la décentralisation de Rollup a encore un long chemin à parcourir. Certaines de ces propositions sont encore à l'état de projet et nécessitent des discussions plus approfondies, tandis que d'autres n'ont complété que des spécifications préliminaires. Tous ces scénarios doivent être mis en œuvre et rigoureusement testés.
Bien que certains Rollups ne proposent pas explicitement une solution décentralisée correspondante, ils incluent souvent des mécanismes d'échappement pour traiter les points de défaillance uniques dus aux commandes centralisées. Par exemple, zkSync fournit une méthode FullExit qui permet aux utilisateurs de retirer leurs fonds directement de L1. Lorsque le système entre en mode exode et ne peut pas traiter de nouveaux blocs, l'utilisateur peut initier une opération de retrait.
Pour obtenir une résistance à la censure, ces Rollups permettent souvent aux utilisateurs de soumettre des transactions directement sur L1. Par exemple, zkSync utilise une file d'attente prioritaire pour de telles transactions envoyées sur L1. De même, Polygon zkEVM inclut une méthode de lot forcé dans le contrat L1. Lorsqu'aucune agrégation ne se produit dans une semaine, l'utilisateur peut appeler cette méthode sur L1 et fournir le tableau d'octets et bathFee de la transaction au prouveur.
Ce qui est certain, c'est que dans un avenir prévisible, la décentralisation de Rollup sera une solution combinée, qui pourra inclure les solutions importantes susmentionnées ou d'autres variantes innovantes.