Lorsque nous examinons la vision et la feuille de route de diverses solutions de déploiement, nous constatons que presque tous les déploiements ont un objectif ultime. Si cet objectif est condensé en une phrase : construire une pile technologique, la fournir à la communauté, résoudre l'expansion du blockchain, et finalement la décentralisation de la pile technologique des opérations et de la gouvernance. Cela conduit au terme de cumul décentralisé.
Alors, qu'est-ce que la décentralisation exactement ? Quelle est la répartition des tâches entre les différentes parties du système Rollup ? La décentralisation signifie-t-elle maximiser les participants à l'exploitation du système ? Quel impact aura un trieur centralisé ? Comment concevoir l'ordonnanceur partagé et le consensus local L2 ? Quelle est la fonction du prouveur unique dans ZK-Rollup ? À quoi ressemblerait un réseau de preuves décentralisé ouvert ? Pourquoi avons-nous besoin de l'accélération matérielle zk ? Quelle est la solution au problème de disponibilité des données ? ....
Il y a des discussions sans fin autour du Rollup décentralisé dans la communauté, donc ECN a organisé une série d'entretiens en podcast sur le thème du "Rollup décentralisé", et a invité des fondateurs et des chercheurs exceptionnels dans ce domaine à parler de leur compréhension du Rollup décentralisé.
Alors que de plus en plus de liquidités affluent dans la plate-forme de couche 2, de plus en plus de fournisseurs de services de rollup apparaissent, non seulement des solutions de rollup à usage général, des chaînes de rollup spécifiques aux applications, mais également des plates-formes de rollup en tant que service. Par conséquent, de plus en plus de personnes craignent qu'un rôle très critique "séquenceur" dans presque tous les rollups soit encore centralisé. Quels sont les risques d'un trieur centralisé ? Un trieur décentralisé est-il un travail urgent ?
**Dans le deuxième épisode, nous avons invité Yaoqi Jia, fondateur d'AltLayer Network, Toghrul Maharramov, chercheur de Scroll, et Abdelhamid Bakhta, Starknet Exploration Lead, à mener une table ronde sur le thème des trieurs décentralisés, afin que le public et les lecteurs peut comprendre le courant Certains progrès et dilemmes des trieurs décentralisés. **
Invités dans ce numéro :
Yaoqi Jia, fondateur du réseau AltLayer, twitter @jiayaoqi
Chercheur de défilement Toghrul Maharramov, twitter @toghrulmaharram
Abdelhamid Bakhta, responsable de l'exploration de Starknet, twitter @dimahledba
Passé
Question 1 : Comment décentraliser Rollup ?
Patrick McCorry, chercheur à Arbitrum
Aperçu
Problème 3 : Réseau du prouveur et accélération matérielle zk
Ye Zhang, co-fondateur de Scroll
Léo Fan, co-fondateur de Cysic
Problème 4 : Disponibilité des données et stockage décentralisé
Qi Zhou, fondateur d'EthStorage
Écouter
Cliquez pour vous abonner au podcast pour en savoir plus :
Youtube:
Microcosme:
horodatage
00:49 Yaoqi se présente
01:37 Abdelhamid se présente
02:50 Toghrul se présente
04:03 Le rôle du trieur dans le rollup
08:37 Commande décentralisée : amélioration de l'expérience utilisateur et résolution des problèmes de vivacité et de censure
19:43 Comment Starknet va décentraliser le trieur
22:59 Comment Scroll va décentraliser le trieur
26:34 La différence entre le consensus L2 dans le contexte du cumul optimiste et du zkRollup
32:28 zkRollup décentralise le trieur et doit également tenir compte du prouveur
36:01 Qu'est-ce qu'un rollup basé ?
40:53 Inconvénients du séquenceur partagé et du rollup basé, et leurs scénarios d'application
49:02 Quel impact un commandeur décentralisé aura-t-il sur MEV ?
Présentation de l'invité
Yaoqi
Je suis le fondateur d'AltLayer. AltLayer construit une plate-forme "Rollup as a Service" où les développeurs cliquent simplement sur certains boutons et configurent les paramètres. À l'aide de notre tableau de bord ou de notre panneau de configuration, ils peuvent lancer rapidement des cumuls spécifiques à l'application en quelques minutes. C'est donc ce que nous essayons de faire maintenant, pour fournir aux développeurs un environnement d'exécution et des fonctionnalités communs. Nous fournissons également plusieurs séquenceurs, plusieurs systèmes de machines virtuelles et divers systèmes de preuve parmi lesquels les développeurs peuvent choisir.
Abdelhamid
Je travaille chez Starkware et je suis le chef de l'équipe d'exploration. L'objectif de ce groupe est essentiellement de lancer des projets open source de type recherche mais axés sur l'ingénierie. Notre objectif est de travailler sur des projets open source en étroite collaboration avec la communauté et avec des personnes d'autres écosystèmes. L'un de ces projets est Madara, qui est en fait un trieur Starknet. Ce n'est pas seulement un candidat pour le réseau public Starknet, mais aussi un séquenceur pour la chaîne d'application Starknet et Layer3. Ceci est également lié à ce que l'invité précédent a dit, nous envisageons également de fournir une fonction de déploiement en tant que service, les gens peuvent déployer leur chaîne d'applications Starknet et choisir différentes solutions de disponibilité des données de manière quelque peu modulaire. Avant cela, j'ai travaillé en tant que développeur principal d'Ethereum pendant quatre ans, principalement responsable des travaux de l'EIP-1559.
Choix
Je suis chercheur chez Scroll, et mes principales responsabilités chez Scroll sont la conception de protocoles, la conception de ponts, la décentralisation, les incitations, ce genre de choses. Donc, quand je ne tweete pas, la plupart du temps, je travaille juste sur la façon de décentraliser le protocole ou les ordonnateurs, les prouveurs, des trucs comme ça. Comme Starkware, l'une des choses sur lesquelles nous travaillons est un SDK de déploiement. Ainsi, vous pouvez émettre un cumul basé sur le défilement et utiliser de manière modulaire différentes options de disponibilité des données, etc. Nous envisageons toujours une option selon laquelle les rollups basés sur le SDK Scroll peuvent utiliser le trieur de Scroll pour les aider à réaliser la décentralisation sans exiger que chaque rollup gère la décentralisation par lui-même. Bien sûr, le plan n'a pas encore été finalisé. Cependant, c'est aussi la direction dans laquelle nous travaillons.
Rubrique entretien
sujet un
Expliquer le trieur de rollup ?
Abdelhamid
Le trieur est un composant très important dans l'architecture de la couche 2, ce composant reçoit les transactions des utilisateurs, puis les regroupe et les regroupe en blocs, exécute les transactions, etc. C'est très critique car c'est le composant responsable de la création des blocs, puisque la couche 2 est aussi une blockchain avec des blocs de transaction. Les ordonnateurs créent ces blocs et les démonstrateurs attestent de ces blocs.
Yaoqi
Comme Abdel l'a mentionné, l'ordonnateur est une combinaison de nombreuses fonctions dans la blockchain. Il se peut donc que nous donnions actuellement trop de responsabilités au donneur d'ordre par rapport à une blockchain publique typique. Il doit d'abord regrouper toutes les transactions des utilisateurs, puis trier ces transactions, soit en fonction du prix du gaz, soit selon le principe du premier arrivé, premier servi. Ensuite, le séquenceur doit exécuter ces transactions. Comme maintenant, certains Layer2 utilisent EVM (Starware a une machine virtuelle différente), mais fondamentalement, le séquenceur doit utiliser une machine virtuelle dédiée pour exécuter les transactions et générer l'état. Ensuite, la transaction atteint une étape de pré-confirmation, ce qui signifie que si vous voyez un temps de confirmation d'une ou deux secondes, voire de sous-secondes, il s'agit essentiellement d'un état de pré-confirmation complété par le séquenceur. Ensuite, pour la plupart des trieurs, ils doivent également télécharger ou publier des points de contrôle ou des hachages d'état sur L1. Il s'agit d'une confirmation au niveau L1, que nous appelons la disponibilité des données. Ainsi, le trieur a en fait de nombreux rôles dans le système de cumul. Mais en général, je pense que c'est le composant le plus critique du système de cumul.
** Sujet 2 **
Pourquoi un trieur décentralisé est-il important ? Si nous utilisons un trieur centralisé, quels sont les dangers cachés pour les utilisateurs et le système ?
Choix
Tout d'abord, nous devons savoir qu'à l'exception de Fuel V1 au stade actuel, il n'y a pas de véritable cumul, car les autres cumuls ont encore des roues d'entraînement.
Cependant, nous pouvons dire qu'une fois qu'il est classé comme cumul, cela signifie que le multi-sig est supprimé et ainsi de suite. Ensuite, le problème de la décentralisation du trieur devient un problème d'expérience utilisateur, et non un problème de sécurité. Donc, quand les gens parlent, disons, de décentraliser la L1, le problème est complètement différent. Parce que L1 doit fournir des garanties pour la commande et les clients légers. Ainsi, si un client léger veut vérifier que l'état est correct, il doit faire confiance aux validateurs L1. Pour le cumul, ce n'est pas le cas. Car le trieur ne fournit qu'un tri temporaire, qui est ensuite finalisé par L1. Et, comme les rollups sont également garantis résistants à la censure, nous n'avons pas besoin de décentralisation pour que cela se produise.
Il y a donc plusieurs raisons pour lesquelles vous avez besoin d'un trieur décentralisé. Premièrement, si la finalisation de la L1 est lente (soit parce que vos preuves de validité soumises sont trop lentes, soit en raison du mécanisme de période de défi des preuves de fraude cumulées optimistes), vous devez compter sur quelque chose pour obtenir une confirmation de transaction rapide. A ce stade de confirmation rapide, bien que vous puissiez avoir confiance que Starkware ou Scroll ne vous tromperont pas, ils indiquent qu'après la confirmation d'un blocage, il n'y aura pas de réorganisation. C'est une hypothèse de confiance. Et la décentralisation peut ajouter des garanties économiques, etc.
Mais sur cette base, le rollup n'a pas non plus de garantie de finalité en temps réel. Essentiellement, vous pouvez forcer l'empaquetage des transactions via L1, mais cela prend des heures pour empaqueter cette transaction. Ainsi, par exemple, s'il existe un oracle responsable de la mise à jour et que l'heure fluctue, alors, en gros, si l'oracle est mis à jour pendant une heure ou plus, les applications du cumul ne seront pas disponibles. Essentiellement, la décentralisation nous permet de fournir des garanties plus solides de résistance à la censure en temps réel, car alors un adversaire devrait compromettre non seulement une entité ou une poignée d'entités, mais l'ensemble du réseau de donneurs d'ordre.
Donc pour nous, la décentralisation est plus une solution pour améliorer l'expérience utilisateur ou régler le cas particulier des mises à jour oracle, etc. Au lieu de fournir des garanties de sécurité de base, c'est ce que fait L1.
Abdelhamid
Oui, la question sur le trieur décentralisé que vous avez mentionné n'est pas exactement la même que la L1 décentralisée, ce qui, à mon avis, est très important. Parce que quand on voit certains N1 critiquer les trieurs centralisés, ils ne regardent pas correctement les compromis que font les trieurs centralisés.
Sur cette base, je voudrais ajouter quelque chose lié à l'expérience utilisateur, lié à l'activité. Parce que lorsque vous n'avez qu'un seul trieur, vous courez un plus grand risque que le trieur tombe en panne. Par conséquent, un ordonnanceur décentralisé augmente également la résilience et la vivacité sur le réseau. Mais même dans un contexte centralisé, nous avons une bonne sécurité en matière de sécurité. Parce que lorsque vous pouvez forcer les transactions de package via L1, la différence entre les deux n'est que la chronologie. Et avoir un trieur décentralisé vous permet d'avoir des garanties rapides de résistance à la censure, comme l'a mentionné Toghrul. Donc, je veux juste ajouter qu'il est également important pour la vivacité d'avoir un réseau décentralisé de donneurs d'ordre.
Yaoqi
Je voudrais ajouter quelque chose. L'activité est probablement la chose la plus importante que nous devons considérer à ce stade. Les cas les plus récents de parachutages sur les L2 les plus populaires, tels que Optimism et Arbitrum, ont connu une période d'indisponibilité. Par conséquent, je pense que ce que nous devons résoudre, c'est comment gérer des milliers de demandes de transaction par seconde lorsque nous n'avons qu'un seul trieur. Même en théorie, si vous n'avez qu'un seul nœud, il ne peut pas vraiment gérer autant de requêtes en même temps. Donc, en ce qui concerne la vivacité, nous avons certainement besoin de plusieurs trieurs. Le point de défaillance unique est un véritable obstacle, pas seulement pour Web3, même Web2 est un gros problème.
Au-delà de cela, il y a la question de la censure. Si nous n'avons qu'un seul coordinateur, même si nous voyons qu'il peut être géré par l'équipe, vous devez toujours prouver que l'équipe n'examinera pas réellement les transactions. Parfois, il est possible et capable pour des parties malveillantes de mettre certaines transactions sur liste noire. C'est un système de commande décentralisé, ils peuvent également essayer d'envoyer des transactions via d'autres commandes. C'est pourquoi nous avons reçu beaucoup de critiques concernant les trieurs individuels ces derniers temps.
Au-delà de cela, il y a d'autres problèmes comme le MEV et les premières courses. Dans un système avec des trieurs centralisés, en particulier pour les protocoles DeFi, ils pourraient être en mesure de vérifier facilement le mempool. Probablement pas sous la forme d'un favori, mais ils ont une meilleure chance de suivre le commerce et de l'arbitrer.
Beaucoup de ces problèmes, pour diverses raisons, même si nous voyons que L2 est très différent de L1. Mais en fin de compte, nous devons encore le rendre aussi décentralisé que possible. Nous devons donc faire face à certains des problèmes similaires que nous rencontrons avec les blockchains publiques ou L1.
Abdelhamid
Oui, je suis d'accord qu'un trieur décentralisé est important. Mais je tiens également à dire que, comme nous le savons tous, ce n'est pas une question facile.
De plus, **puisque les rollups ont une architecture très spécifique, avec plusieurs entités. Nous parlons d'un seul ordonnateur, mais il y a aussi un prouveur, et nous devons décentraliser les deux. ** Il y aura des compromis et des difficultés dans la tarification des transactions car différents facteurs sont nécessaires pour faire fonctionner le réseau. Alors, comment fixez-vous le prix de la transaction ? Le trieur et l'étalon ont des exigences matérielles différentes, l'étalon a besoin d'une machine super puissante et ainsi de suite. Par conséquent, la tarification des transactions dans un monde décentralisé est également un problème très difficile, c'est pourquoi nous avons besoin de temps pour avancer lentement.
Nous allons donc tous faire face à un tel compromis. Si nous voulons décentraliser rapidement, nous devrons peut-être prendre quelques roues d'entraînement et décentraliser progressivement, car si nous voulons directement une architecture parfaite, cela prendra plusieurs années. Je pense donc que nous allons adopter une approche pragmatique et essayer de décentraliser progressivement. Du moins, c'est notre plan actuel, comme peut-être commencer par un simple mécanisme de consensus BFT, puis ajouter un autre mécanisme de consensus à court terme ou quelque chose comme ça. Je veux juste dire que ce n'est pas une question facile. Parce qu'il y a évidemment un compromis entre la vitesse de développement et l'applicabilité de l'architecture à un environnement décentralisé.
Sujet 3
Comment décentraliser le trieur ?
Abdelhamid
Il existe de nombreuses fonctionnalités que nous souhaitons décentraliser, et toutes ont des compromis différents.
Par exemple, lors de la décentralisation, vous souhaitez introduire une sorte de mécanisme de consensus. Dans le mécanisme de consensus, cependant, il y a plusieurs parties. Le premier est l'élection du leader, c'est-à-dire comment choisir qui créera des blocs, qui sera l'ordonnateur chargé de créer des blocs dans un créneau donné ou dans un délai donné. ** Ce que l'équipe Starknet prévoit de faire, c'est d'utiliser autant que possible la couche 1. C'est-à-dire que dans notre algorithme d'élection de leader, nous voulons miser sur la couche1. Par exemple, nous avons des jetons, et le gage aura lieu sur le contrat intelligent de la couche 1 Ethereum, qui est utilisé pour déterminer le mécanisme d'élection du leader. ** Cela signifie que nous devons avoir une interaction où le donneur d'ordre L2 interrogera le contrat intelligent Ethereum pour savoir qui sera le prochain leader ou quelque chose du genre. Donc, évidemment, une sorte de hasard et d'autres choses sont nécessaires. Ce n'est donc pas une question simple. Mais c'est la première partie. Ensuite, vous devez disposer d'un mécanisme pour le consensus lui-même. Il existe plusieurs options : soit le mécanisme à chaîne la plus longue ou BFT, soit un hybride des deux. Comme Ethereum, il a LMG Ghost et Casper FFG pour finalité.
Nous pourrions donc adopter une approche pragmatique et commencer par BFT en premier. pourquoi ? Lorsque la couche 2 considère la décentralisation, notre objectif n'est pas d'avoir une échelle de tri aussi grande que la couche 1. Par exemple, sur Ethereum, l'objectif est de faire participer des millions de validateurs. Dans ce cas, vous ne pouvez pas simplement utiliser le mécanisme BFT, car son efficacité sera très mauvaise et cela causera de très gros problèmes. Par exemple, s'il y a un problème sur le réseau Bitcoin, s'il s'agit d'un mécanisme BFT, la chaîne s'arrêtera complètement. Mais ce n'est pas le cas, le réseau Bitcoin continue de créer des blocs, seul le mécanisme de finalité est attaqué.
Mais dans la couche 2, si la cible est de quelques centaines à 1000 trieurs, il peut être bon de commencer par un mécanisme BFT. Donc, nous avons le mécanisme d'élection du chef, puis le consensus, et puis il y a deux autres parties, mais je laisserai aux autres invités le soin de continuer à ajouter. Mais les deux autres parties sont les mises à jour d'état et la génération de preuves.
Choix
Premièrement, en L2, la décentralisation est un problème à multiples facettes, tel que décrit par Abdel. Surtout dans zkRollup, parce qu'il y a des prouveurs et des ordonnateurs, il faut se coordonner entre eux, il faut décentraliser les deux. Ce problème est complètement différent de L1.
Une autre différence est qu'en L2, toute votre conception consiste à convaincre le pont sous-jacent que le consensus est correct, et non à convaincre un certain nombre d'autres nœuds. Vous devriez évidemment faire la même chose, mais votre objectif principal devrait être le pont lui-même.
Actuellement, nous travaillons dans deux directions différentes. Premièrement, je pense que, comme tout le monde, nous travaillons sur un protocole BFT. Ce n'est pas très efficace et il y a quelques problèmes qui doivent être résolus. Nous avons trouvé une solution approximative, mais ce n'est toujours pas optimal. Par exemple, l'une des questions est de savoir comment équilibrer les incitations entre les trieurs et les étalonneurs ? Étant donné que le donneur d'ordre contrôle le MEV et que le prouveur n'a pas accès au MEV, les gens sont incités à exécuter le donneur d'ordre au lieu du prouveur. Mais en réalité, nous avons besoin de plus de prouveurs que de commanditaires, alors comment équilibrer les incitations entre les deux ? C'est l'un de ces problèmes.
La deuxième solution sur laquelle nous travaillons est une autre direction. N'oubliez pas que les choses peuvent changer. De nouvelles propositions sortent chaque jour. Par exemple, il y a eu beaucoup de discussions ces derniers temps sur le cumul basé et sur la façon dont vous pouvez complètement externaliser le tri vers L1. La deuxième direction consiste à abandonner complètement le trieur et à utiliser un constructeur externe. Par exemple, les constructeurs Ethereum ou Flashbots SUAVE, etc. proposent des blocs ordonnés, puis exécutent un consensus à l'intérieur du prouveur. L'avantage ici est que vous n'avez pas à vous soucier des incitations car, en gros, vous pouvez utiliser PBS dans le protocole et cela crée un protocole plus simple. Mais l'inconvénient est que puisque nous avons besoin d'un grand nombre de prouveurs (car nous pouvons prouver en parallèle), il est assez difficile de faire tourner un protocole BFT classique avec eux. La question est donc de savoir comment optimiser un protocole BFT existant pour qu'il fonctionne avec des centaines, voire des milliers de prouveurs ? Et ce n'est pas une question facile à répondre.
L'introduction du consensus L2 est-elle nécessaire pour un ordonnateur décentralisé ?
Yaoqi
Je peux répondre grossièrement à cette question parce que nous venons tout juste de déployer quelque chose comme ça.
L'introduction d'un consensus ne dépend donc pas du fait que nous le voulions ou non. Une fois que vous avez de nombreux donneurs d'ordre ou même seulement des nœuds, vous devez les mettre d'accord. Cela dépend vraiment de vos hypothèses. S'il s'agit d'une hypothèse byzantine, nous pouvons utiliser BFT ou tout protocole de consensus byzantin existant. S'il s'agit d'une configuration non byzantine, par exemple, si nous supposons simplement qu'un nœud ne peut être qu'en ligne et hors ligne, et qu'il ne peut pas agir de manière malveillante, nous pouvons utiliser le protocole Raft ou un autre protocole de consensus plus rapide. Mais de toute façon, si nous avons un groupe d'ordonnateurs ou de prouveurs, si nous voulons les organiser ensemble pour produire des blocs sur une période de temps, alors vous devez avoir un protocole de consensus autour d'eux.
Ainsi, comme Toghrul et Abdel viennent de le mentionner, je pense qu'il existe de nombreuses propositions et sujets de recherche sur la manière dont nous pouvons mettre en œuvre un système de commande ou de preuve décentralisé. Donc, parce que nous venons de lancer un testnet pour un système de cumul multi-trieurs (ne prend actuellement en charge que les preuves de fraude pour les cumuls optimistes), sur la base de notre expérience de conception et de mise en œuvre, il y a certaines choses que je peux partager sur les difficultés. Comme Toghrul l'a mentionné tout à l'heure, la difficulté ne réside pas dans le protocole de consensus lui-même, la vraie difficulté réside dans d'autres choses que cela, comme la partie preuve. Parce que s'il s'agit d'un seul trieur, vous n'avez pas besoin de plusieurs nœuds. Nous pouvons le considérer comme un EVM, une machine virtuelle. Donc, récupérez simplement les transactions et exécutez-les, faites des transitions d'état. Le prouveur est chargé de générer des preuves pour la transition d'état de l'ensemble de transactions précédent. Cependant, si nous exécutons le protocole de consensus pour l'assembleur et le prouveur lors du cumul, nous devons y introduire une logique de consensus supplémentaire. En plus de cela, vous avez également besoin d'un système de preuve pour le protocole de consensus. Par conséquent, cela introduira beaucoup de travail pour le système de preuve à générer. Ensuite, une fois que vous avez généré la preuve, vous pouvez facilement la vérifier sur L1 Ethereum.
C'est pourquoi, d'une certaine manière, lorsque nous avons lancé le premier testnet multi-commande, le cumul optimiste présentait certains avantages à cet égard. En général, vous pouvez simplifier beaucoup de choses, comme ne pas considérer la partie preuve de validité. Comme nous, nous comparons essentiellement tout à WASM. Donc au final c'est une instruction WASM. Ainsi, en vérifiant ces instructions WASM, il est relativement facile de vérifier à l'aide du code Solidity. Si nous réimplémentions simplement toutes les interprétations d'instructions WASM sur Ethereum.
Mais en général, le problème n'est pas singulier. Si nous avons une solution au problème, en conséquence, il y aura d'autres travaux de suivi qui devront être résolus en même temps. Bien sûr, il y aura des problèmes de MEV, comme comment distribuer équitablement le MEV. Vous pouvez affecter tous les ordonnateurs et démonstrateurs selon qu'ils ont produit un bloc ou validé un bloc. Mais en fin de compte, c'est vraiment une combinaison de nombreux problèmes, pas seulement techniques, mais aussi des incitations économiques.
Et nous devons nous rappeler que L2 est proposé parce que nous voulons réduire considérablement le coût du gaz. Nous ne pouvons donc pas avoir autant de nœuds. Même en générant des preuves, L2 peut être plus cher que L1. Nous devons donc vraiment trouver une approche équilibrée à ce genre de problème.
Abdelhamid
Je voudrais ajouter un point supplémentaire. Premièrement, il n'existe actuellement aucune preuve réelle de fraude sans autorisation pour les cumuls optimistes. Et je continue à le souligner à chaque fois que j'en ai l'occasion, car il est important d'être honnête à ce sujet lorsque l'on compare. Ils ne sont donc pas du tout en L2. C'est la première chose.
Ensuite, j'aimerais ajouter quelque chose à propos de l'asynchronicité entre le tri et les preuves, car c'est très important. Comme vous l'avez dit, nous souhaitons optimiser le tri, car il s'agit actuellement d'un goulot d'étranglement pour toutes les solutions. Mais c'est bien dans le cadre d'un tri centralisé, car nous savons que le trieur ne produira que des transitions de valeur et nous pourrons les vérifier. Mais ce sera plus difficile dans le cadre d'un tri décentralisé, car peut-être que votre trieur pourra produire quelque chose qui ne peut pas être vérifié. Ensuite, vous devrez vous en occuper plus tard.
Dans le cadre d'un tri centralisé, pour optimiser le tri, puisqu'on n'a pas à générer de preuves lors du tri, on peut essayer de le faire à vitesse locale, c'est ce qu'on veut faire. Traduisez Cairo dans un langage machine de bas niveau comme LLVM et exécutez-le très rapidement sur le trieur. Ensuite, vous pouvez prouver de manière asynchrone. Et la chose la plus cool avec les preuves, c'est que vous pouvez les faire en parallèle. La parallélisabilité massive est obtenue en prouvant que la récursivité est possible. C'est pourquoi nous pourrons rattraper la vitesse du trieur. Mais c'est difficile lorsqu'il est décentralisé, car nous devons nous assurer que l'ordonnanceur ne produit que des transitions d'état valides.
Choix
J'ajouterai que je ne suis pas sûr de ce que fait Starknet ici. Mais pour nous, je suppose que c'est une hypothèse générale de chaque zkRollup que si vous décentralisez le trieur, votre système de preuve doit être capable de gérer les lots invalides. Donc, fondamentalement, si, par exemple, vous soumettez un lot avec une signature invalide, vous devez être en mesure de prouver que l'état résultant est équivalent à l'état de départ. Il y aura donc des frais généraux de toute façon. Il s'agit de minimiser la probabilité que cela se produise.
Abdelhamid
Oui c'est vrai. C'est pourquoi nous avons introduit Sierra dans Cairo 1 pour que tout soit vérifiable. Cette représentation intermédiaire garantira que chaque programme Cairo 1 est vérifiable afin que nous puissions inclure une transaction de retour.
Qu'est-ce que le cumul basé ?
Yaoqi
Le rollup basé provient à l'origine d'un article de blog de Justin Drake sur les forums Ethereum. L'une de ses idées est que nous pouvons réutiliser certains vérificateurs Ethereum pour vérifier les transactions de cumul, de sorte que nous n'avons pas besoin d'un groupe distinct de nœuds pour vérifier différentes transactions de cumul. En particulier, nous aurons de nombreux cumuls à l'avenir, y compris des cumuls à usage général et de nombreux cumuls spécifiques à une application. Donc, dans ce cas, ce serait formidable si nous pouvions trouver un lieu commun comme le pool de validateurs Ethereum pour valider ces transactions.
Bien sûr, ce n'est qu'une idée, car cela introduit également de nombreuses difficultés techniques. Par exemple, en théorie, nous pourrions exiger que les validateurs Ethereum vérifient les transactions de cumul, mais il est très difficile d'obtenir la logique de vérification des cumuls regroupée ou intégrée dans le protocole Ethereum lui-même. Nous appelons cela la vérification dans le protocole, qui nécessite un hard fork de nœuds Ethereum. Bien sûr, dans ce cas, nous pouvons vérifier certaines transactions de cumul. Mais si nous le faisons, vous verrez des problèmes. C'est un peu comme si nous voulions que le cumul de L2 partage la pression d'Ethereum, mais au final, nous demandons toujours aux validateurs d'Ethereum de prendre en charge une partie du travail transféré à L2. Donc, beaucoup de gens parlent de la façon dont nous pouvons faire cela.
Ensuite, nous avons parlé à Barnabe, un chercheur de la Fondation Ethereum qui travaille actuellement sur PBS. Il s'agit d'une proposition d'Ethereum, qui consiste à diviser la tâche des validateurs en plusieurs rôles, constructeurs et proposants. Maintenant, nous avons des Flashbots pour jouer le rôle de constructeurs dans PBS, ils composent tous les blocs et les envoient aux proposants Ethereum. Ainsi, une fois ces blocs intégrés au réseau Ethereum, les constructeurs recevront également des récompenses. Alors dans ce cas, comment récompenser ces validateurs du réseau Ethereum ? Ils sont également responsables de la validation du cumul.
L'une des solutions est le "reprise", que vous avez peut-être beaucoup entendu parler d'EigenLayer ou d'autres protocoles. Les utilisateurs peuvent réimplanter l'ETH sur d'autres réseaux de tri. Ou récompensez les validateurs Ethereum pour avoir réellement exécuté le logiciel pour effectuer le travail de validation pour le cumul. Dans ce cas, ils peuvent être récompensés à la fois à partir de L2 et via le protocole de re-staking. Il y a eu de nombreuses propositions à ce sujet jusqu'à présent, mais en général, c'est une idée de la façon de pouvoir réutiliser les validateurs Ethereum existants. Comment pouvons-nous réutiliser l'ETH existant pour aider à inaugurer une nouvelle ère de systèmes cumulatifs ou L2 ? Donc, il s'agit essentiellement de simplifier beaucoup de choses pour le projet de déploiement. Si un rollup veut un nouveau trieur, s'il veut une nouvelle source de garantie, il peut réutiliser l'infrastructure existante ou la garantie existante. C'est pourquoi il est construit au-dessus d'Ethereum, puis une infrastructure et un jalonnement supplémentaires peuvent également être réutilisés pour le cumul et L2.
Inconvénients du séquenceur partagé et du rollup basé, et leurs scénarios d'application.
Choix
Je veux me plaindre de cette proposition, je ne suis pas convaincu par la proposition liée au séquenceur partagé. Bien sûr, ils en sont encore à leurs balbutiements, et si ces conceptions s'améliorent à l'avenir, il est tout à fait possible que je les soutienne. C'est juste que la forme actuelle ne me convainc pas. Il y a plusieurs raisons.
Premièrement, pour moi, la principale proposition de valeur d'un trieur partagé est de permettre aux utilisateurs d'acquérir une composabilité atomique entre des cumuls à usage général comme Scroll ou Starknet. Mais le problème est que si vous avez une composabilité atomique, votre cumul est aussi final que le cumul le plus lent avec lequel vous combinez. Ainsi, en supposant que Scroll soit combiné avec Optimistic Rollup, la finalité de Scroll sera de sept jours. Alors que la principale proposition de valeur de ZKRollup est d'atteindre une finalité relativement rapide, les utilisateurs peuvent se retirer en L1 en quelques minutes. Et dans ce cas, renoncez essentiellement à cela.
Un autre inconvénient est que si vous voulez une finalité hors chaîne, vous devez exécuter un nœud L2, et tant que les données soumises à la chaîne sont finalisées par L1, vous obtenez la finalité localement dans L2. Si chaque L2 combiné n'exécute pas un nœud complet, il est pratiquement impossible d'obtenir une finalisation locale. Cela signifie que l'exécution de ce système peut être plus coûteuse que l'exécution d'un système comme Solana, car plusieurs nœuds complets s'exécutent en même temps, avec leur propre surcharge, etc.
Donc, pour ces raisons, je ne pense tout simplement pas que cela ait du sens pour L2. C'est un peu différent pour L3, car si quelqu'un veut construire une chaîne spécifique à une application et ne veut pas gérer la décentralisation. Disons que je construis un jeu et que je veux juste m'occuper de la construction du jeu, alors je peux externaliser le travail décentralisé. Mais je ne pense pas que cela ait de sens pour la L2 pour le moment.
En ce qui concerne le cumul basé, j'ai aussi mes préoccupations. Par exemple, comment partagez-vous les bénéfices du MEV avec les étalonneurs ? Parce que si le problème d'allocation n'est pas pris en compte, fondamentalement L1 peut obtenir tous les bénéfices du MEV. Une autre petite chose est que son temps de confirmation est égal au temps de confirmation de L1, qui est de 12 minutes, ce qui ne peut pas être plus rapide. Un autre problème est que, comme il est sans autorisation, plusieurs demandeurs peuvent soumettre des lots de transactions en même temps, ce qui signifie qu'il peut se retrouver avec des résultats centralisés. Parce que les constructeurs sont incités à inclure leurs transactions si un chercheur se connecte plus facilement que les autres. Par conséquent, cela peut aboutir à ce qu'un seul Seeker propose des lots pour L2 à la fin, ce qui n'est pas une très bonne solution, car si cela se produit, nous revenons essentiellement à la case départ.
Yaoqi
Fait intéressant, je viens d'avoir un appel avec Ben, le fondateur d'Espresso, en fait la semaine dernière. Nous en parlons beaucoup dans le sujet des trieurs partagés. Comme Toghrul l'a mentionné, je pense qu'il existe une certaine incertitude quant aux scénarios d'utilisation d'un système de commande partagé. C'est principalement parce que pour un L2 à usage général, nous n'avons généralement pas un grand nombre de trieurs en raison de l'efficacité, de la complexité et de l'économie. Et je pense toujours que, que ce soit pour un séquenceur partagé, un rollup basé ou une reprise, le meilleur cas d'utilisation est principalement pour RAS (Rollup as a Service) ou de telles plates-formes où nous pouvons déployer beaucoup de rollups. Nous n'avons pas vraiment besoin d'un grand réseau de tri pour être honnête s'il n'y a pas beaucoup de rollups. Ces rollups ont déjà leurs propres systèmes de tri, et ont déjà leurs propres communautés ou partenaires, alors qu'il n'y a que quelques L2 génériques. Ils n'ont pas vraiment besoin d'avoir un réseau séparé et tiers. De plus, c'est un fardeau pour le réseau tiers, car vous devez personnaliser pour chaque L2, et chaque L2 a une pile de test différente. Cela nécessite de nombreux changements dans votre propre réseau.
Mais en même temps, comme Toghrul l'a mentionné, pour certains cas d'utilisation particuliers. Par exemple, si nous voulons avoir une certaine interopérabilité au niveau du trieur, les trieurs partagés peuvent être une solution potentielle. Par exemple, le même trieur est utilisé pour plusieurs cumuls. Dans ce cas, ce trieur peut essentiellement gérer certaines transactions de cumul croisé pour assurer l'atomicité inter-chaînes entre le cumul A, B et C.
Mais vous pouvez également voir le problème ici lorsque je décris la situation. Si nous avions vraiment beaucoup de ces séquenceurs partagés, ils redeviendraient un goulot d'étranglement et un nouveau point de défaillance unique. Nous donnons trop de pouvoir à ces soi-disant ordonnateurs partagés. Ils ressemblent davantage à un réseau, contrôlant de nombreux rollups. Enfin, nous devons à nouveau trouver un moyen de décentraliser ce trieur partagé.
Quoi qu'il en soit, je pense que c'est une bonne chose que les gens découvrent progressivement de plus en plus de problèmes et proposent de plus en plus de solutions. Dans l'ensemble, c'est excitant de voir ce qu'il y a de nouveau dans ce domaine chaque jour. Avec toutes ces nouvelles solutions, au moins on est sur la bonne voie pour vraiment décentraliser tout l'espace rollup.
Abdel
Oui, je suis d'accord avec vous deux. Je pense que cela a plus de sens pour Layer3 et Lisk car ils ne veulent plus assumer la responsabilité d'encourager un réseau décentralisé et doivent trouver des partenaires pour démarrer des choses comme des trieurs. Je pense donc que pour Lisk, cela a du sens. Mais comme Toghrul, je ne pense pas que cela ait encore beaucoup de sens pour Layer2.
Sujet 4
Quel impact un donneur d'ordre décentralisé aura-t-il sur MEV ?
Abdel
Pour Starknet, dans le cadre de la centralisation, nous ne faisons aucun type de MEV, et nous adoptons un modèle premier arrivé, premier servi. C'est-à-dire que dans le cadre de la décentralisation, bien sûr, plus de MEV seront amenés plus tard. Mais il est trop tôt pour dire quel ratio, car cela dépend aussi de la conception du mécanisme de consensus et d'autres aspects.
Choix
Mais le fait est que même si vous ne faites pas de MEV, il se peut qu'il y ait encore des MEV qui se produisent à Starknet. Eh bien, la décentralisation en elle-même ne diminue pas vraiment le MEV ou n'augmente pas le MEV. Bien sûr, si vous appliquez une sorte de protocole de commande équitable ou de cryptage de seuil, par exemple, alors oui, vous minimisez MEV. Mais vous ne pouvez pas l'éliminer complètement. Ma philosophie est la suivante : MEV ne peut pas être éliminé. Mais disons que vous créez simplement un consensus BFT, ou que vous construisez quelque chose au-dessus d'un consensus BFT. Cela n'affecte en fait pas du tout le MEV. Le MEV existe toujours, cela devrait être une question de savoir comment le chercheur travaille avec le trieur pour extraire ce MEV.
Yaoqi
Le problème est que même le modèle du premier arrivé, premier servi comporte des parties délicates. Une fois que nous avons exposé le mempool à certains chercheurs, ils ont toujours l'avantage de jouer davantage. Par exemple, pour les séquenceurs, cela équivaut à attendre à la porte de votre bureau. Donc, dans ce cas, une fois qu'ils voient une sorte d'opportunité d'arbitrage, pas seulement une attaque frontale ou une attaque sandwich, dès qu'un utilisateur envoie une transaction, ils peuvent immédiatement la voir dans le mempool. Ainsi, ils peuvent rapidement placer leurs métiers avant les autres. Ainsi, ils ont un avantage sur les autres chercheurs.
Mais pour en revenir à la décentralisation, je pense qu'il s'agit surtout de résistance à la censure, comme nous en avons discuté au début. Les séquenceurs sont gérés par l'équipe. L'équipe peut dire qu'elle est juste envers tout le monde. Mais cela n'est pas interdit dans le code. Donc, si nous pouvions avoir un réseau P2P, ce serait formidable si nous avions l'impression que ces nœuds vérifiaient mes transactions et que nous pouvions ensuite les envoyer à d'autres nœuds. Donc, il s'agit vraiment de l'équité du traitement des transactions à L2.
En ce qui concerne les MEV, car récemment, en plus des MEV générés dans un seul cumul, il y a des MEV générés à travers les ponts. Dans ce réseau de tri relativement décentralisé, vous aurez plus de possibilités d'extraire le MEV. En supposant que nous ayons un réseau de commande partagé, si vous pouvez d'une manière ou d'une autre influencer le commandeur partagé pour réorganiser les transactions, vous avez en gros un gros avantage sur tout le monde.
Un réseau de séquenceurs partagés présente des avantages et des inconvénients. Du côté positif, nous pouvons décentraliser davantage le système de classement. Mais d'un autre côté, tout le monde a la possibilité d'être un trieur. Donc, ils peuvent faire ce qu'ils veulent, et c'est à nouveau une forêt sombre. Nous avons donc introduit la décentralisation, puis nous avons dû faire face à des problèmes similaires à ceux auxquels nous étions confrontés dans Ethereum. C'est pourquoi Flashbots et les gens de la Fondation Ethereum veulent aller de l'avant avec PBS, séparer les proposants et les constructeurs, puis essayer d'avoir une solution unique du côté des constructeurs.
Ainsi, lorsque nous examinons le problème, ce n'est pas qu'un seul problème. Ce n'est plus un problème individuel, mais individuel, et plus encore.
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.
Dialogue avec les équipes AltLayer, Scroll, Starknet : Séquenceur partagé et Consensus L2
Introduction
Lorsque nous examinons la vision et la feuille de route de diverses solutions de déploiement, nous constatons que presque tous les déploiements ont un objectif ultime. Si cet objectif est condensé en une phrase : construire une pile technologique, la fournir à la communauté, résoudre l'expansion du blockchain, et finalement la décentralisation de la pile technologique des opérations et de la gouvernance. Cela conduit au terme de cumul décentralisé.
Alors, qu'est-ce que la décentralisation exactement ? Quelle est la répartition des tâches entre les différentes parties du système Rollup ? La décentralisation signifie-t-elle maximiser les participants à l'exploitation du système ? Quel impact aura un trieur centralisé ? Comment concevoir l'ordonnanceur partagé et le consensus local L2 ? Quelle est la fonction du prouveur unique dans ZK-Rollup ? À quoi ressemblerait un réseau de preuves décentralisé ouvert ? Pourquoi avons-nous besoin de l'accélération matérielle zk ? Quelle est la solution au problème de disponibilité des données ? ....
Il y a des discussions sans fin autour du Rollup décentralisé dans la communauté, donc ECN a organisé une série d'entretiens en podcast sur le thème du "Rollup décentralisé", et a invité des fondateurs et des chercheurs exceptionnels dans ce domaine à parler de leur compréhension du Rollup décentralisé.
Alors que de plus en plus de liquidités affluent dans la plate-forme de couche 2, de plus en plus de fournisseurs de services de rollup apparaissent, non seulement des solutions de rollup à usage général, des chaînes de rollup spécifiques aux applications, mais également des plates-formes de rollup en tant que service. Par conséquent, de plus en plus de personnes craignent qu'un rôle très critique "séquenceur" dans presque tous les rollups soit encore centralisé. Quels sont les risques d'un trieur centralisé ? Un trieur décentralisé est-il un travail urgent ?
**Dans le deuxième épisode, nous avons invité Yaoqi Jia, fondateur d'AltLayer Network, Toghrul Maharramov, chercheur de Scroll, et Abdelhamid Bakhta, Starknet Exploration Lead, à mener une table ronde sur le thème des trieurs décentralisés, afin que le public et les lecteurs peut comprendre le courant Certains progrès et dilemmes des trieurs décentralisés. **
Invités dans ce numéro :
Passé
Question 1 : Comment décentraliser Rollup ?
Aperçu
Problème 3 : Réseau du prouveur et accélération matérielle zk
Problème 4 : Disponibilité des données et stockage décentralisé
Écouter
Cliquez pour vous abonner au podcast pour en savoir plus :
Youtube:
Microcosme:
horodatage
00:49 Yaoqi se présente
01:37 Abdelhamid se présente
02:50 Toghrul se présente
04:03 Le rôle du trieur dans le rollup
08:37 Commande décentralisée : amélioration de l'expérience utilisateur et résolution des problèmes de vivacité et de censure
19:43 Comment Starknet va décentraliser le trieur
22:59 Comment Scroll va décentraliser le trieur
26:34 La différence entre le consensus L2 dans le contexte du cumul optimiste et du zkRollup
32:28 zkRollup décentralise le trieur et doit également tenir compte du prouveur
36:01 Qu'est-ce qu'un rollup basé ?
40:53 Inconvénients du séquenceur partagé et du rollup basé, et leurs scénarios d'application
49:02 Quel impact un commandeur décentralisé aura-t-il sur MEV ?
Présentation de l'invité
Yaoqi
Je suis le fondateur d'AltLayer. AltLayer construit une plate-forme "Rollup as a Service" où les développeurs cliquent simplement sur certains boutons et configurent les paramètres. À l'aide de notre tableau de bord ou de notre panneau de configuration, ils peuvent lancer rapidement des cumuls spécifiques à l'application en quelques minutes. C'est donc ce que nous essayons de faire maintenant, pour fournir aux développeurs un environnement d'exécution et des fonctionnalités communs. Nous fournissons également plusieurs séquenceurs, plusieurs systèmes de machines virtuelles et divers systèmes de preuve parmi lesquels les développeurs peuvent choisir.
Abdelhamid
Je travaille chez Starkware et je suis le chef de l'équipe d'exploration. L'objectif de ce groupe est essentiellement de lancer des projets open source de type recherche mais axés sur l'ingénierie. Notre objectif est de travailler sur des projets open source en étroite collaboration avec la communauté et avec des personnes d'autres écosystèmes. L'un de ces projets est Madara, qui est en fait un trieur Starknet. Ce n'est pas seulement un candidat pour le réseau public Starknet, mais aussi un séquenceur pour la chaîne d'application Starknet et Layer3. Ceci est également lié à ce que l'invité précédent a dit, nous envisageons également de fournir une fonction de déploiement en tant que service, les gens peuvent déployer leur chaîne d'applications Starknet et choisir différentes solutions de disponibilité des données de manière quelque peu modulaire. Avant cela, j'ai travaillé en tant que développeur principal d'Ethereum pendant quatre ans, principalement responsable des travaux de l'EIP-1559.
Choix
Je suis chercheur chez Scroll, et mes principales responsabilités chez Scroll sont la conception de protocoles, la conception de ponts, la décentralisation, les incitations, ce genre de choses. Donc, quand je ne tweete pas, la plupart du temps, je travaille juste sur la façon de décentraliser le protocole ou les ordonnateurs, les prouveurs, des trucs comme ça. Comme Starkware, l'une des choses sur lesquelles nous travaillons est un SDK de déploiement. Ainsi, vous pouvez émettre un cumul basé sur le défilement et utiliser de manière modulaire différentes options de disponibilité des données, etc. Nous envisageons toujours une option selon laquelle les rollups basés sur le SDK Scroll peuvent utiliser le trieur de Scroll pour les aider à réaliser la décentralisation sans exiger que chaque rollup gère la décentralisation par lui-même. Bien sûr, le plan n'a pas encore été finalisé. Cependant, c'est aussi la direction dans laquelle nous travaillons.
Rubrique entretien
sujet un
Expliquer le trieur de rollup ?
Abdelhamid
Le trieur est un composant très important dans l'architecture de la couche 2, ce composant reçoit les transactions des utilisateurs, puis les regroupe et les regroupe en blocs, exécute les transactions, etc. C'est très critique car c'est le composant responsable de la création des blocs, puisque la couche 2 est aussi une blockchain avec des blocs de transaction. Les ordonnateurs créent ces blocs et les démonstrateurs attestent de ces blocs.
Yaoqi
Comme Abdel l'a mentionné, l'ordonnateur est une combinaison de nombreuses fonctions dans la blockchain. Il se peut donc que nous donnions actuellement trop de responsabilités au donneur d'ordre par rapport à une blockchain publique typique. Il doit d'abord regrouper toutes les transactions des utilisateurs, puis trier ces transactions, soit en fonction du prix du gaz, soit selon le principe du premier arrivé, premier servi. Ensuite, le séquenceur doit exécuter ces transactions. Comme maintenant, certains Layer2 utilisent EVM (Starware a une machine virtuelle différente), mais fondamentalement, le séquenceur doit utiliser une machine virtuelle dédiée pour exécuter les transactions et générer l'état. Ensuite, la transaction atteint une étape de pré-confirmation, ce qui signifie que si vous voyez un temps de confirmation d'une ou deux secondes, voire de sous-secondes, il s'agit essentiellement d'un état de pré-confirmation complété par le séquenceur. Ensuite, pour la plupart des trieurs, ils doivent également télécharger ou publier des points de contrôle ou des hachages d'état sur L1. Il s'agit d'une confirmation au niveau L1, que nous appelons la disponibilité des données. Ainsi, le trieur a en fait de nombreux rôles dans le système de cumul. Mais en général, je pense que c'est le composant le plus critique du système de cumul.
** Sujet 2 **
Pourquoi un trieur décentralisé est-il important ? Si nous utilisons un trieur centralisé, quels sont les dangers cachés pour les utilisateurs et le système ?
Choix
Tout d'abord, nous devons savoir qu'à l'exception de Fuel V1 au stade actuel, il n'y a pas de véritable cumul, car les autres cumuls ont encore des roues d'entraînement.
Cependant, nous pouvons dire qu'une fois qu'il est classé comme cumul, cela signifie que le multi-sig est supprimé et ainsi de suite. Ensuite, le problème de la décentralisation du trieur devient un problème d'expérience utilisateur, et non un problème de sécurité. Donc, quand les gens parlent, disons, de décentraliser la L1, le problème est complètement différent. Parce que L1 doit fournir des garanties pour la commande et les clients légers. Ainsi, si un client léger veut vérifier que l'état est correct, il doit faire confiance aux validateurs L1. Pour le cumul, ce n'est pas le cas. Car le trieur ne fournit qu'un tri temporaire, qui est ensuite finalisé par L1. Et, comme les rollups sont également garantis résistants à la censure, nous n'avons pas besoin de décentralisation pour que cela se produise.
Il y a donc plusieurs raisons pour lesquelles vous avez besoin d'un trieur décentralisé. Premièrement, si la finalisation de la L1 est lente (soit parce que vos preuves de validité soumises sont trop lentes, soit en raison du mécanisme de période de défi des preuves de fraude cumulées optimistes), vous devez compter sur quelque chose pour obtenir une confirmation de transaction rapide. A ce stade de confirmation rapide, bien que vous puissiez avoir confiance que Starkware ou Scroll ne vous tromperont pas, ils indiquent qu'après la confirmation d'un blocage, il n'y aura pas de réorganisation. C'est une hypothèse de confiance. Et la décentralisation peut ajouter des garanties économiques, etc.
Mais sur cette base, le rollup n'a pas non plus de garantie de finalité en temps réel. Essentiellement, vous pouvez forcer l'empaquetage des transactions via L1, mais cela prend des heures pour empaqueter cette transaction. Ainsi, par exemple, s'il existe un oracle responsable de la mise à jour et que l'heure fluctue, alors, en gros, si l'oracle est mis à jour pendant une heure ou plus, les applications du cumul ne seront pas disponibles. Essentiellement, la décentralisation nous permet de fournir des garanties plus solides de résistance à la censure en temps réel, car alors un adversaire devrait compromettre non seulement une entité ou une poignée d'entités, mais l'ensemble du réseau de donneurs d'ordre.
Donc pour nous, la décentralisation est plus une solution pour améliorer l'expérience utilisateur ou régler le cas particulier des mises à jour oracle, etc. Au lieu de fournir des garanties de sécurité de base, c'est ce que fait L1.
Abdelhamid
Oui, la question sur le trieur décentralisé que vous avez mentionné n'est pas exactement la même que la L1 décentralisée, ce qui, à mon avis, est très important. Parce que quand on voit certains N1 critiquer les trieurs centralisés, ils ne regardent pas correctement les compromis que font les trieurs centralisés.
Sur cette base, je voudrais ajouter quelque chose lié à l'expérience utilisateur, lié à l'activité. Parce que lorsque vous n'avez qu'un seul trieur, vous courez un plus grand risque que le trieur tombe en panne. Par conséquent, un ordonnanceur décentralisé augmente également la résilience et la vivacité sur le réseau. Mais même dans un contexte centralisé, nous avons une bonne sécurité en matière de sécurité. Parce que lorsque vous pouvez forcer les transactions de package via L1, la différence entre les deux n'est que la chronologie. Et avoir un trieur décentralisé vous permet d'avoir des garanties rapides de résistance à la censure, comme l'a mentionné Toghrul. Donc, je veux juste ajouter qu'il est également important pour la vivacité d'avoir un réseau décentralisé de donneurs d'ordre.
Yaoqi
Je voudrais ajouter quelque chose. L'activité est probablement la chose la plus importante que nous devons considérer à ce stade. Les cas les plus récents de parachutages sur les L2 les plus populaires, tels que Optimism et Arbitrum, ont connu une période d'indisponibilité. Par conséquent, je pense que ce que nous devons résoudre, c'est comment gérer des milliers de demandes de transaction par seconde lorsque nous n'avons qu'un seul trieur. Même en théorie, si vous n'avez qu'un seul nœud, il ne peut pas vraiment gérer autant de requêtes en même temps. Donc, en ce qui concerne la vivacité, nous avons certainement besoin de plusieurs trieurs. Le point de défaillance unique est un véritable obstacle, pas seulement pour Web3, même Web2 est un gros problème.
Au-delà de cela, il y a la question de la censure. Si nous n'avons qu'un seul coordinateur, même si nous voyons qu'il peut être géré par l'équipe, vous devez toujours prouver que l'équipe n'examinera pas réellement les transactions. Parfois, il est possible et capable pour des parties malveillantes de mettre certaines transactions sur liste noire. C'est un système de commande décentralisé, ils peuvent également essayer d'envoyer des transactions via d'autres commandes. C'est pourquoi nous avons reçu beaucoup de critiques concernant les trieurs individuels ces derniers temps.
Au-delà de cela, il y a d'autres problèmes comme le MEV et les premières courses. Dans un système avec des trieurs centralisés, en particulier pour les protocoles DeFi, ils pourraient être en mesure de vérifier facilement le mempool. Probablement pas sous la forme d'un favori, mais ils ont une meilleure chance de suivre le commerce et de l'arbitrer.
Beaucoup de ces problèmes, pour diverses raisons, même si nous voyons que L2 est très différent de L1. Mais en fin de compte, nous devons encore le rendre aussi décentralisé que possible. Nous devons donc faire face à certains des problèmes similaires que nous rencontrons avec les blockchains publiques ou L1.
Abdelhamid
Oui, je suis d'accord qu'un trieur décentralisé est important. Mais je tiens également à dire que, comme nous le savons tous, ce n'est pas une question facile.
De plus, **puisque les rollups ont une architecture très spécifique, avec plusieurs entités. Nous parlons d'un seul ordonnateur, mais il y a aussi un prouveur, et nous devons décentraliser les deux. ** Il y aura des compromis et des difficultés dans la tarification des transactions car différents facteurs sont nécessaires pour faire fonctionner le réseau. Alors, comment fixez-vous le prix de la transaction ? Le trieur et l'étalon ont des exigences matérielles différentes, l'étalon a besoin d'une machine super puissante et ainsi de suite. Par conséquent, la tarification des transactions dans un monde décentralisé est également un problème très difficile, c'est pourquoi nous avons besoin de temps pour avancer lentement.
Nous allons donc tous faire face à un tel compromis. Si nous voulons décentraliser rapidement, nous devrons peut-être prendre quelques roues d'entraînement et décentraliser progressivement, car si nous voulons directement une architecture parfaite, cela prendra plusieurs années. Je pense donc que nous allons adopter une approche pragmatique et essayer de décentraliser progressivement. Du moins, c'est notre plan actuel, comme peut-être commencer par un simple mécanisme de consensus BFT, puis ajouter un autre mécanisme de consensus à court terme ou quelque chose comme ça. Je veux juste dire que ce n'est pas une question facile. Parce qu'il y a évidemment un compromis entre la vitesse de développement et l'applicabilité de l'architecture à un environnement décentralisé.
Sujet 3
Comment décentraliser le trieur ?
Abdelhamid
Il existe de nombreuses fonctionnalités que nous souhaitons décentraliser, et toutes ont des compromis différents.
Par exemple, lors de la décentralisation, vous souhaitez introduire une sorte de mécanisme de consensus. Dans le mécanisme de consensus, cependant, il y a plusieurs parties. Le premier est l'élection du leader, c'est-à-dire comment choisir qui créera des blocs, qui sera l'ordonnateur chargé de créer des blocs dans un créneau donné ou dans un délai donné. ** Ce que l'équipe Starknet prévoit de faire, c'est d'utiliser autant que possible la couche 1. C'est-à-dire que dans notre algorithme d'élection de leader, nous voulons miser sur la couche1. Par exemple, nous avons des jetons, et le gage aura lieu sur le contrat intelligent de la couche 1 Ethereum, qui est utilisé pour déterminer le mécanisme d'élection du leader. ** Cela signifie que nous devons avoir une interaction où le donneur d'ordre L2 interrogera le contrat intelligent Ethereum pour savoir qui sera le prochain leader ou quelque chose du genre. Donc, évidemment, une sorte de hasard et d'autres choses sont nécessaires. Ce n'est donc pas une question simple. Mais c'est la première partie. Ensuite, vous devez disposer d'un mécanisme pour le consensus lui-même. Il existe plusieurs options : soit le mécanisme à chaîne la plus longue ou BFT, soit un hybride des deux. Comme Ethereum, il a LMG Ghost et Casper FFG pour finalité.
Nous pourrions donc adopter une approche pragmatique et commencer par BFT en premier. pourquoi ? Lorsque la couche 2 considère la décentralisation, notre objectif n'est pas d'avoir une échelle de tri aussi grande que la couche 1. Par exemple, sur Ethereum, l'objectif est de faire participer des millions de validateurs. Dans ce cas, vous ne pouvez pas simplement utiliser le mécanisme BFT, car son efficacité sera très mauvaise et cela causera de très gros problèmes. Par exemple, s'il y a un problème sur le réseau Bitcoin, s'il s'agit d'un mécanisme BFT, la chaîne s'arrêtera complètement. Mais ce n'est pas le cas, le réseau Bitcoin continue de créer des blocs, seul le mécanisme de finalité est attaqué.
Mais dans la couche 2, si la cible est de quelques centaines à 1000 trieurs, il peut être bon de commencer par un mécanisme BFT. Donc, nous avons le mécanisme d'élection du chef, puis le consensus, et puis il y a deux autres parties, mais je laisserai aux autres invités le soin de continuer à ajouter. Mais les deux autres parties sont les mises à jour d'état et la génération de preuves.
Choix
Premièrement, en L2, la décentralisation est un problème à multiples facettes, tel que décrit par Abdel. Surtout dans zkRollup, parce qu'il y a des prouveurs et des ordonnateurs, il faut se coordonner entre eux, il faut décentraliser les deux. Ce problème est complètement différent de L1.
Une autre différence est qu'en L2, toute votre conception consiste à convaincre le pont sous-jacent que le consensus est correct, et non à convaincre un certain nombre d'autres nœuds. Vous devriez évidemment faire la même chose, mais votre objectif principal devrait être le pont lui-même.
Actuellement, nous travaillons dans deux directions différentes. Premièrement, je pense que, comme tout le monde, nous travaillons sur un protocole BFT. Ce n'est pas très efficace et il y a quelques problèmes qui doivent être résolus. Nous avons trouvé une solution approximative, mais ce n'est toujours pas optimal. Par exemple, l'une des questions est de savoir comment équilibrer les incitations entre les trieurs et les étalonneurs ? Étant donné que le donneur d'ordre contrôle le MEV et que le prouveur n'a pas accès au MEV, les gens sont incités à exécuter le donneur d'ordre au lieu du prouveur. Mais en réalité, nous avons besoin de plus de prouveurs que de commanditaires, alors comment équilibrer les incitations entre les deux ? C'est l'un de ces problèmes.
La deuxième solution sur laquelle nous travaillons est une autre direction. N'oubliez pas que les choses peuvent changer. De nouvelles propositions sortent chaque jour. Par exemple, il y a eu beaucoup de discussions ces derniers temps sur le cumul basé et sur la façon dont vous pouvez complètement externaliser le tri vers L1. La deuxième direction consiste à abandonner complètement le trieur et à utiliser un constructeur externe. Par exemple, les constructeurs Ethereum ou Flashbots SUAVE, etc. proposent des blocs ordonnés, puis exécutent un consensus à l'intérieur du prouveur. L'avantage ici est que vous n'avez pas à vous soucier des incitations car, en gros, vous pouvez utiliser PBS dans le protocole et cela crée un protocole plus simple. Mais l'inconvénient est que puisque nous avons besoin d'un grand nombre de prouveurs (car nous pouvons prouver en parallèle), il est assez difficile de faire tourner un protocole BFT classique avec eux. La question est donc de savoir comment optimiser un protocole BFT existant pour qu'il fonctionne avec des centaines, voire des milliers de prouveurs ? Et ce n'est pas une question facile à répondre.
L'introduction du consensus L2 est-elle nécessaire pour un ordonnateur décentralisé ?
Yaoqi
Je peux répondre grossièrement à cette question parce que nous venons tout juste de déployer quelque chose comme ça.
L'introduction d'un consensus ne dépend donc pas du fait que nous le voulions ou non. Une fois que vous avez de nombreux donneurs d'ordre ou même seulement des nœuds, vous devez les mettre d'accord. Cela dépend vraiment de vos hypothèses. S'il s'agit d'une hypothèse byzantine, nous pouvons utiliser BFT ou tout protocole de consensus byzantin existant. S'il s'agit d'une configuration non byzantine, par exemple, si nous supposons simplement qu'un nœud ne peut être qu'en ligne et hors ligne, et qu'il ne peut pas agir de manière malveillante, nous pouvons utiliser le protocole Raft ou un autre protocole de consensus plus rapide. Mais de toute façon, si nous avons un groupe d'ordonnateurs ou de prouveurs, si nous voulons les organiser ensemble pour produire des blocs sur une période de temps, alors vous devez avoir un protocole de consensus autour d'eux.
Ainsi, comme Toghrul et Abdel viennent de le mentionner, je pense qu'il existe de nombreuses propositions et sujets de recherche sur la manière dont nous pouvons mettre en œuvre un système de commande ou de preuve décentralisé. Donc, parce que nous venons de lancer un testnet pour un système de cumul multi-trieurs (ne prend actuellement en charge que les preuves de fraude pour les cumuls optimistes), sur la base de notre expérience de conception et de mise en œuvre, il y a certaines choses que je peux partager sur les difficultés. Comme Toghrul l'a mentionné tout à l'heure, la difficulté ne réside pas dans le protocole de consensus lui-même, la vraie difficulté réside dans d'autres choses que cela, comme la partie preuve. Parce que s'il s'agit d'un seul trieur, vous n'avez pas besoin de plusieurs nœuds. Nous pouvons le considérer comme un EVM, une machine virtuelle. Donc, récupérez simplement les transactions et exécutez-les, faites des transitions d'état. Le prouveur est chargé de générer des preuves pour la transition d'état de l'ensemble de transactions précédent. Cependant, si nous exécutons le protocole de consensus pour l'assembleur et le prouveur lors du cumul, nous devons y introduire une logique de consensus supplémentaire. En plus de cela, vous avez également besoin d'un système de preuve pour le protocole de consensus. Par conséquent, cela introduira beaucoup de travail pour le système de preuve à générer. Ensuite, une fois que vous avez généré la preuve, vous pouvez facilement la vérifier sur L1 Ethereum.
C'est pourquoi, d'une certaine manière, lorsque nous avons lancé le premier testnet multi-commande, le cumul optimiste présentait certains avantages à cet égard. En général, vous pouvez simplifier beaucoup de choses, comme ne pas considérer la partie preuve de validité. Comme nous, nous comparons essentiellement tout à WASM. Donc au final c'est une instruction WASM. Ainsi, en vérifiant ces instructions WASM, il est relativement facile de vérifier à l'aide du code Solidity. Si nous réimplémentions simplement toutes les interprétations d'instructions WASM sur Ethereum.
Mais en général, le problème n'est pas singulier. Si nous avons une solution au problème, en conséquence, il y aura d'autres travaux de suivi qui devront être résolus en même temps. Bien sûr, il y aura des problèmes de MEV, comme comment distribuer équitablement le MEV. Vous pouvez affecter tous les ordonnateurs et démonstrateurs selon qu'ils ont produit un bloc ou validé un bloc. Mais en fin de compte, c'est vraiment une combinaison de nombreux problèmes, pas seulement techniques, mais aussi des incitations économiques.
Et nous devons nous rappeler que L2 est proposé parce que nous voulons réduire considérablement le coût du gaz. Nous ne pouvons donc pas avoir autant de nœuds. Même en générant des preuves, L2 peut être plus cher que L1. Nous devons donc vraiment trouver une approche équilibrée à ce genre de problème.
Abdelhamid
Je voudrais ajouter un point supplémentaire. Premièrement, il n'existe actuellement aucune preuve réelle de fraude sans autorisation pour les cumuls optimistes. Et je continue à le souligner à chaque fois que j'en ai l'occasion, car il est important d'être honnête à ce sujet lorsque l'on compare. Ils ne sont donc pas du tout en L2. C'est la première chose.
Ensuite, j'aimerais ajouter quelque chose à propos de l'asynchronicité entre le tri et les preuves, car c'est très important. Comme vous l'avez dit, nous souhaitons optimiser le tri, car il s'agit actuellement d'un goulot d'étranglement pour toutes les solutions. Mais c'est bien dans le cadre d'un tri centralisé, car nous savons que le trieur ne produira que des transitions de valeur et nous pourrons les vérifier. Mais ce sera plus difficile dans le cadre d'un tri décentralisé, car peut-être que votre trieur pourra produire quelque chose qui ne peut pas être vérifié. Ensuite, vous devrez vous en occuper plus tard.
Dans le cadre d'un tri centralisé, pour optimiser le tri, puisqu'on n'a pas à générer de preuves lors du tri, on peut essayer de le faire à vitesse locale, c'est ce qu'on veut faire. Traduisez Cairo dans un langage machine de bas niveau comme LLVM et exécutez-le très rapidement sur le trieur. Ensuite, vous pouvez prouver de manière asynchrone. Et la chose la plus cool avec les preuves, c'est que vous pouvez les faire en parallèle. La parallélisabilité massive est obtenue en prouvant que la récursivité est possible. C'est pourquoi nous pourrons rattraper la vitesse du trieur. Mais c'est difficile lorsqu'il est décentralisé, car nous devons nous assurer que l'ordonnanceur ne produit que des transitions d'état valides.
Choix
J'ajouterai que je ne suis pas sûr de ce que fait Starknet ici. Mais pour nous, je suppose que c'est une hypothèse générale de chaque zkRollup que si vous décentralisez le trieur, votre système de preuve doit être capable de gérer les lots invalides. Donc, fondamentalement, si, par exemple, vous soumettez un lot avec une signature invalide, vous devez être en mesure de prouver que l'état résultant est équivalent à l'état de départ. Il y aura donc des frais généraux de toute façon. Il s'agit de minimiser la probabilité que cela se produise.
Abdelhamid
Oui c'est vrai. C'est pourquoi nous avons introduit Sierra dans Cairo 1 pour que tout soit vérifiable. Cette représentation intermédiaire garantira que chaque programme Cairo 1 est vérifiable afin que nous puissions inclure une transaction de retour.
Qu'est-ce que le cumul basé ?
Yaoqi
Le rollup basé provient à l'origine d'un article de blog de Justin Drake sur les forums Ethereum. L'une de ses idées est que nous pouvons réutiliser certains vérificateurs Ethereum pour vérifier les transactions de cumul, de sorte que nous n'avons pas besoin d'un groupe distinct de nœuds pour vérifier différentes transactions de cumul. En particulier, nous aurons de nombreux cumuls à l'avenir, y compris des cumuls à usage général et de nombreux cumuls spécifiques à une application. Donc, dans ce cas, ce serait formidable si nous pouvions trouver un lieu commun comme le pool de validateurs Ethereum pour valider ces transactions.
Bien sûr, ce n'est qu'une idée, car cela introduit également de nombreuses difficultés techniques. Par exemple, en théorie, nous pourrions exiger que les validateurs Ethereum vérifient les transactions de cumul, mais il est très difficile d'obtenir la logique de vérification des cumuls regroupée ou intégrée dans le protocole Ethereum lui-même. Nous appelons cela la vérification dans le protocole, qui nécessite un hard fork de nœuds Ethereum. Bien sûr, dans ce cas, nous pouvons vérifier certaines transactions de cumul. Mais si nous le faisons, vous verrez des problèmes. C'est un peu comme si nous voulions que le cumul de L2 partage la pression d'Ethereum, mais au final, nous demandons toujours aux validateurs d'Ethereum de prendre en charge une partie du travail transféré à L2. Donc, beaucoup de gens parlent de la façon dont nous pouvons faire cela.
Ensuite, nous avons parlé à Barnabe, un chercheur de la Fondation Ethereum qui travaille actuellement sur PBS. Il s'agit d'une proposition d'Ethereum, qui consiste à diviser la tâche des validateurs en plusieurs rôles, constructeurs et proposants. Maintenant, nous avons des Flashbots pour jouer le rôle de constructeurs dans PBS, ils composent tous les blocs et les envoient aux proposants Ethereum. Ainsi, une fois ces blocs intégrés au réseau Ethereum, les constructeurs recevront également des récompenses. Alors dans ce cas, comment récompenser ces validateurs du réseau Ethereum ? Ils sont également responsables de la validation du cumul.
L'une des solutions est le "reprise", que vous avez peut-être beaucoup entendu parler d'EigenLayer ou d'autres protocoles. Les utilisateurs peuvent réimplanter l'ETH sur d'autres réseaux de tri. Ou récompensez les validateurs Ethereum pour avoir réellement exécuté le logiciel pour effectuer le travail de validation pour le cumul. Dans ce cas, ils peuvent être récompensés à la fois à partir de L2 et via le protocole de re-staking. Il y a eu de nombreuses propositions à ce sujet jusqu'à présent, mais en général, c'est une idée de la façon de pouvoir réutiliser les validateurs Ethereum existants. Comment pouvons-nous réutiliser l'ETH existant pour aider à inaugurer une nouvelle ère de systèmes cumulatifs ou L2 ? Donc, il s'agit essentiellement de simplifier beaucoup de choses pour le projet de déploiement. Si un rollup veut un nouveau trieur, s'il veut une nouvelle source de garantie, il peut réutiliser l'infrastructure existante ou la garantie existante. C'est pourquoi il est construit au-dessus d'Ethereum, puis une infrastructure et un jalonnement supplémentaires peuvent également être réutilisés pour le cumul et L2.
Inconvénients du séquenceur partagé et du rollup basé, et leurs scénarios d'application.
Choix
Je veux me plaindre de cette proposition, je ne suis pas convaincu par la proposition liée au séquenceur partagé. Bien sûr, ils en sont encore à leurs balbutiements, et si ces conceptions s'améliorent à l'avenir, il est tout à fait possible que je les soutienne. C'est juste que la forme actuelle ne me convainc pas. Il y a plusieurs raisons.
Premièrement, pour moi, la principale proposition de valeur d'un trieur partagé est de permettre aux utilisateurs d'acquérir une composabilité atomique entre des cumuls à usage général comme Scroll ou Starknet. Mais le problème est que si vous avez une composabilité atomique, votre cumul est aussi final que le cumul le plus lent avec lequel vous combinez. Ainsi, en supposant que Scroll soit combiné avec Optimistic Rollup, la finalité de Scroll sera de sept jours. Alors que la principale proposition de valeur de ZKRollup est d'atteindre une finalité relativement rapide, les utilisateurs peuvent se retirer en L1 en quelques minutes. Et dans ce cas, renoncez essentiellement à cela.
Un autre inconvénient est que si vous voulez une finalité hors chaîne, vous devez exécuter un nœud L2, et tant que les données soumises à la chaîne sont finalisées par L1, vous obtenez la finalité localement dans L2. Si chaque L2 combiné n'exécute pas un nœud complet, il est pratiquement impossible d'obtenir une finalisation locale. Cela signifie que l'exécution de ce système peut être plus coûteuse que l'exécution d'un système comme Solana, car plusieurs nœuds complets s'exécutent en même temps, avec leur propre surcharge, etc.
Donc, pour ces raisons, je ne pense tout simplement pas que cela ait du sens pour L2. C'est un peu différent pour L3, car si quelqu'un veut construire une chaîne spécifique à une application et ne veut pas gérer la décentralisation. Disons que je construis un jeu et que je veux juste m'occuper de la construction du jeu, alors je peux externaliser le travail décentralisé. Mais je ne pense pas que cela ait de sens pour la L2 pour le moment.
En ce qui concerne le cumul basé, j'ai aussi mes préoccupations. Par exemple, comment partagez-vous les bénéfices du MEV avec les étalonneurs ? Parce que si le problème d'allocation n'est pas pris en compte, fondamentalement L1 peut obtenir tous les bénéfices du MEV. Une autre petite chose est que son temps de confirmation est égal au temps de confirmation de L1, qui est de 12 minutes, ce qui ne peut pas être plus rapide. Un autre problème est que, comme il est sans autorisation, plusieurs demandeurs peuvent soumettre des lots de transactions en même temps, ce qui signifie qu'il peut se retrouver avec des résultats centralisés. Parce que les constructeurs sont incités à inclure leurs transactions si un chercheur se connecte plus facilement que les autres. Par conséquent, cela peut aboutir à ce qu'un seul Seeker propose des lots pour L2 à la fin, ce qui n'est pas une très bonne solution, car si cela se produit, nous revenons essentiellement à la case départ.
Yaoqi
Fait intéressant, je viens d'avoir un appel avec Ben, le fondateur d'Espresso, en fait la semaine dernière. Nous en parlons beaucoup dans le sujet des trieurs partagés. Comme Toghrul l'a mentionné, je pense qu'il existe une certaine incertitude quant aux scénarios d'utilisation d'un système de commande partagé. C'est principalement parce que pour un L2 à usage général, nous n'avons généralement pas un grand nombre de trieurs en raison de l'efficacité, de la complexité et de l'économie. Et je pense toujours que, que ce soit pour un séquenceur partagé, un rollup basé ou une reprise, le meilleur cas d'utilisation est principalement pour RAS (Rollup as a Service) ou de telles plates-formes où nous pouvons déployer beaucoup de rollups. Nous n'avons pas vraiment besoin d'un grand réseau de tri pour être honnête s'il n'y a pas beaucoup de rollups. Ces rollups ont déjà leurs propres systèmes de tri, et ont déjà leurs propres communautés ou partenaires, alors qu'il n'y a que quelques L2 génériques. Ils n'ont pas vraiment besoin d'avoir un réseau séparé et tiers. De plus, c'est un fardeau pour le réseau tiers, car vous devez personnaliser pour chaque L2, et chaque L2 a une pile de test différente. Cela nécessite de nombreux changements dans votre propre réseau.
Mais en même temps, comme Toghrul l'a mentionné, pour certains cas d'utilisation particuliers. Par exemple, si nous voulons avoir une certaine interopérabilité au niveau du trieur, les trieurs partagés peuvent être une solution potentielle. Par exemple, le même trieur est utilisé pour plusieurs cumuls. Dans ce cas, ce trieur peut essentiellement gérer certaines transactions de cumul croisé pour assurer l'atomicité inter-chaînes entre le cumul A, B et C.
Mais vous pouvez également voir le problème ici lorsque je décris la situation. Si nous avions vraiment beaucoup de ces séquenceurs partagés, ils redeviendraient un goulot d'étranglement et un nouveau point de défaillance unique. Nous donnons trop de pouvoir à ces soi-disant ordonnateurs partagés. Ils ressemblent davantage à un réseau, contrôlant de nombreux rollups. Enfin, nous devons à nouveau trouver un moyen de décentraliser ce trieur partagé.
Quoi qu'il en soit, je pense que c'est une bonne chose que les gens découvrent progressivement de plus en plus de problèmes et proposent de plus en plus de solutions. Dans l'ensemble, c'est excitant de voir ce qu'il y a de nouveau dans ce domaine chaque jour. Avec toutes ces nouvelles solutions, au moins on est sur la bonne voie pour vraiment décentraliser tout l'espace rollup.
Abdel
Oui, je suis d'accord avec vous deux. Je pense que cela a plus de sens pour Layer3 et Lisk car ils ne veulent plus assumer la responsabilité d'encourager un réseau décentralisé et doivent trouver des partenaires pour démarrer des choses comme des trieurs. Je pense donc que pour Lisk, cela a du sens. Mais comme Toghrul, je ne pense pas que cela ait encore beaucoup de sens pour Layer2.
Sujet 4
Quel impact un donneur d'ordre décentralisé aura-t-il sur MEV ?
Abdel
Pour Starknet, dans le cadre de la centralisation, nous ne faisons aucun type de MEV, et nous adoptons un modèle premier arrivé, premier servi. C'est-à-dire que dans le cadre de la décentralisation, bien sûr, plus de MEV seront amenés plus tard. Mais il est trop tôt pour dire quel ratio, car cela dépend aussi de la conception du mécanisme de consensus et d'autres aspects.
Choix
Mais le fait est que même si vous ne faites pas de MEV, il se peut qu'il y ait encore des MEV qui se produisent à Starknet. Eh bien, la décentralisation en elle-même ne diminue pas vraiment le MEV ou n'augmente pas le MEV. Bien sûr, si vous appliquez une sorte de protocole de commande équitable ou de cryptage de seuil, par exemple, alors oui, vous minimisez MEV. Mais vous ne pouvez pas l'éliminer complètement. Ma philosophie est la suivante : MEV ne peut pas être éliminé. Mais disons que vous créez simplement un consensus BFT, ou que vous construisez quelque chose au-dessus d'un consensus BFT. Cela n'affecte en fait pas du tout le MEV. Le MEV existe toujours, cela devrait être une question de savoir comment le chercheur travaille avec le trieur pour extraire ce MEV.
Yaoqi
Le problème est que même le modèle du premier arrivé, premier servi comporte des parties délicates. Une fois que nous avons exposé le mempool à certains chercheurs, ils ont toujours l'avantage de jouer davantage. Par exemple, pour les séquenceurs, cela équivaut à attendre à la porte de votre bureau. Donc, dans ce cas, une fois qu'ils voient une sorte d'opportunité d'arbitrage, pas seulement une attaque frontale ou une attaque sandwich, dès qu'un utilisateur envoie une transaction, ils peuvent immédiatement la voir dans le mempool. Ainsi, ils peuvent rapidement placer leurs métiers avant les autres. Ainsi, ils ont un avantage sur les autres chercheurs.
Mais pour en revenir à la décentralisation, je pense qu'il s'agit surtout de résistance à la censure, comme nous en avons discuté au début. Les séquenceurs sont gérés par l'équipe. L'équipe peut dire qu'elle est juste envers tout le monde. Mais cela n'est pas interdit dans le code. Donc, si nous pouvions avoir un réseau P2P, ce serait formidable si nous avions l'impression que ces nœuds vérifiaient mes transactions et que nous pouvions ensuite les envoyer à d'autres nœuds. Donc, il s'agit vraiment de l'équité du traitement des transactions à L2.
En ce qui concerne les MEV, car récemment, en plus des MEV générés dans un seul cumul, il y a des MEV générés à travers les ponts. Dans ce réseau de tri relativement décentralisé, vous aurez plus de possibilités d'extraire le MEV. En supposant que nous ayons un réseau de commande partagé, si vous pouvez d'une manière ou d'une autre influencer le commandeur partagé pour réorganiser les transactions, vous avez en gros un gros avantage sur tout le monde.
Un réseau de séquenceurs partagés présente des avantages et des inconvénients. Du côté positif, nous pouvons décentraliser davantage le système de classement. Mais d'un autre côté, tout le monde a la possibilité d'être un trieur. Donc, ils peuvent faire ce qu'ils veulent, et c'est à nouveau une forêt sombre. Nous avons donc introduit la décentralisation, puis nous avons dû faire face à des problèmes similaires à ceux auxquels nous étions confrontés dans Ethereum. C'est pourquoi Flashbots et les gens de la Fondation Ethereum veulent aller de l'avant avec PBS, séparer les proposants et les constructeurs, puis essayer d'avoir une solution unique du côté des constructeurs.
Ainsi, lorsque nous examinons le problème, ce n'est pas qu'un seul problème. Ce n'est plus un problème individuel, mais individuel, et plus encore.