Trieur partagé détaillé 4D : principe de fonctionnement, théorie de l'agrégation et intégration verticale

Cet article analyse les technologies clés des séquenceurs partagés : hautement résistantes à la censure, faciles à déployer, interopérables, rapides à déterminer et instantanées. La théorie de l'agrégation lui offre une nouvelle perspective et l'intégration verticale guide son développement ultérieur.

Titre original : "The Shared Sequencer"

Écrit par : MAVEN11

Compilation : Kxp, BlockBeats

Imaginez ce que ce serait si Rollup "prêt à l'emploi" pouvait atteindre un degré élevé de résistance à la censure, de facilité de déploiement, d'interopérabilité, de finalité rapide, de vivacité et de démocratisation du MEV. Cela peut sembler être un grand objectif, mais avec l'avènement du séquenceur partagé, cela pourrait bientôt devenir une réalité. Cependant, tous les Rollups ne sont pas identiques, nous devons donc réfléchir à la manière de distribuer les récompenses et le MEV sur le réseau de séquenceur partagé. Dans cet article, nous explorons comment les réseaux de classement partagés sont mis en œuvre et les propriétés qui peuvent être obtenues.

Les réseaux de séquenceurs partagés ont été principalement introduits par Alex Beckett, plus tard par Evan Forbes (et Radius) des équipes de Celestia et Espresso, et un nouvel article de Jon Charbonneau qui couvre le sujet plus en profondeur. Josh, Jordan et leur équipe Astria construisent le premier réseau de séquenceurs partagés prêt pour la production. Le Shared Orderer Network d'Astria est une blockchain modulaire qui agrège et ordonne les transactions de Rollup sans les exécuter.

Dans la configuration d'Astria, le trieur envoie des blocs ordonnés à la couche DA ainsi qu'aux nœuds Rollup. Les cumuls obtiennent des garanties de finalité souples de la part de l'ordonnateur et des garanties de finalité fermes de la couche DA (une fois les blocs finalisés), puis ils exécuteront des transactions valides.

Le réseau de séquenceurs partagés est essentiellement un groupe de séquenceurs compatibles Rollup, comme son nom l'indique, il peut fournir des services pour différents Rollups. Cela a divers compromis et propriétés, que nous détaillerons plus tard. Premièrement, nous devons décrire les propriétés les plus importantes d'un trieur (ou d'un ensemble de trieurs). Dans Rollup, la principale exigence pour un séquenceur ou un groupe de séquenceurs est la résistance à la censure ou la vivacité (dont certaines proviennent de la couche de base, ainsi que la sécurité). Cela signifie qu'une transaction valide soumise au donneur d'ordre doit être incluse dans la chaîne dans un laps de temps fini (paramètre timeout). Le groupe de commande partagé doit uniquement s'assurer que les transactions sont incluses dans des blocs (c'est-à-dire des crLists).

Satisfaire la résistance à la censure et l'immédiateté en même temps est assez difficile, comme nous l'avons souligné dans la partie II du MEV modulaire. Dans un algorithme de consensus tel que Tendermint, vous pouvez assurer la récupération après une attaque. Cependant, en cas d'attaque, vous perdez l'immédiateté. Fondamentalement, exiger que tous les autres assembleurs signent un bloc, plutôt que d'élire un masternode personnalisé, n'est probablement pas optimal. Bien que cela améliore la résistance à la censure, cela se fait au prix de la "centralisation" et de l'extraction MEV vers un seul masternode. Un autre mécanisme de tri disponible peut être comparé à la multiplicité de Duality, qui est leur petit outil permettant aux non-masternodes (ou trieurs) d'inclure d'autres transactions dans des blocs. Dans l'ensemble, la résistance à la censure et l'immédiateté après une attaque sont difficiles à obtenir dans la plupart des protocoles de consensus.

Un autre algorithme de consensus qui peut être utilisé est HotStuff 2, qui assure l'immédiateté en cas d'attaque.

Ce qu'il permet, c'est d'éviter d'attendre un délai réseau maximum (timeout) en cas de censure ou de non signé pour élire un nouveau masternode. La raison pour laquelle il pourrait s'agir d'un algorithme de consensus intéressant pour un ensemble décentralisé de commandes est qu'il résout le problème d'immédiateté dans le consensus sans ajouter d'étape supplémentaire. Si le masternode connaît le verrou le plus élevé (le plus grand nombre de participants s'accordant sur une sortie particulière) et peut convaincre les parties honnêtes, le problème est résolu. Sinon, un masternode honnête après un certain point peut prendre en charge le push, en assistant le prochain masternode. Par exemple, un nœud Hotstuff n'a pas besoin d'accuser réception d'un message de basculement avant de notifier un nouveau maître, mais peut directement passer à une nouvelle vue et notifier le nouveau maître.

La différence avec Tendermint est que, bien que les deux soient en deux phases (Hotstuff1 en a trois, Hotstuff2 en a deux), Tendermint a une communication linéaire mais n'est pas réactif, tandis que Hotstuff2 est réactif. S'il existe une chaîne de masternodes honnêtes, le protocole répond positivement, puisque toutes les étapes sauf la proposition du premier masternode dépendent de l'obtention de la quantité d'informations de l'étape précédente. Dans un cadre de commande partagé, cela permet au protocole d'obtenir une meilleure immédiateté sans retomber sur la couche inférieure, sans annuler cette possibilité.

Construction de groupes de tri partagés

Un ensemble de donneurs d'ordre est autorisé à soumettre des transactions à la couche de règlement (la couche où réside Rollup). Vous pouvez rejoindre ce groupe d'assembleurs, à condition que certaines conditions soient remplies et que le nombre requis de producteurs de blocs n'ait pas été atteint. Cela optimise la latence, le débit, etc. Ces exigences sont similaires à celles requises pour devenir validateur d'une blockchain. Par exemple, vous devez répondre à certaines exigences matérielles, ainsi qu'à un dépôt initial, surtout si vous souhaitez offrir une certitude avec des conditions financières.

Un groupe de commande partagé (ou tout groupe de commande décentralisé) se compose de plusieurs composants qui fonctionnent ensemble pour assurer le traitement correct des transactions, notamment :

1. Fournissez JSON-RPC pour chaque Rollup pour la soumission de transaction (pour les opérateurs de nœud non complet) au nœud en tant que pool de mémoire, puis créez et triez. Dans le mempool, un mécanisme est nécessaire pour déterminer la file d'attente, ainsi que le processus de sélection des transactions, afin d'assurer la construction efficace des blocs.

2. Algorithme de construction de blocs/lots, responsable du traitement des transactions dans la file d'attente et de leur conversion en blocs ou en lots. Cette étape peut également inclure une compression pour réduire la taille de bloc résultante (appelée compression de données). Comme mentionné, cela devrait être distinct du proposant, essentiellement PBS. Les données peuvent être compressées de différentes manières, par exemple :

• Pas d'encodage RLP - cependant, cela peut nécessiter un ensemble décentralisé d'assembleurs pour aider à normaliser le transfert de données entre les nœuds, économisant ainsi de l'espace.
• Omettre le nonce (numéro unique validant les données dans un bloc particulier) - il peut être recalculé au moment de l'exécution en regardant l'état précédent de la chaîne.
• Simplification du prix du gaz - définir le gaz sur la base d'une fourchette de prix fixe.
• Simplification du gaz - Outre le prix du gaz, il existe également un système de numérotation du gaz.
• Remplacer l'adresse par l'index - Rollup peut stocker un index d'une adresse mappée au lieu de stocker l'adresse complète.
• Valeurs exprimées en notation scientifique - les champs de valeur dans les transactions Ethereum sont libellés en wei, donc les valeurs sont grandes. Vous ne pouvez pas omettre des champs numériques ou les réduire à un ensemble fixe de valeurs. Cependant, vous pouvez l'écrire en notation scientifique pour optimiser le stockage des données :

• Omission de champs de données : les champs de données ne sont pas requis pour les transferts simples, mais sont requis pour les transactions plus complexes.

• Remplacer les signatures individuelles par des signatures agrégées BLS : les signatures sont le composant le plus important des transactions Ethereum. Au lieu de stocker chaque signature, vous pouvez stocker des signatures agrégées BLS pour un nombre spécifique de transactions. Vous pouvez également vérifier la signature agrégée BLS par rapport à l'ensemble de messages et à l'ensemble d'expéditeurs pour vous assurer de sa validité.

• Utiliser le champ De comme index : comme le champ À, vous pouvez utiliser le champ De comme index pour le mappage.

• Un concept intéressant de conception "modulaire" est que vous pouvez faire des ajustements et des compromis au besoin pour le faire fonctionner pour votre Rollup.

3. La couche peer-to-peer permettra aux ordonnateurs de recevoir des transactions d'autres ordonnateurs et de propager des blocs après la construction. Cette étape est essentielle pour garantir que le séquenceur partagé fonctionne efficacement sur plusieurs cumuls.

4. Algorithme de rotation des maîtres pour les ensembles de commandes partagés (aucun consensus requis en cas d'élection d'un maître unique). Vous pouvez choisir de définir uniquement l'algorithme de rotation du nœud maître ou d'emprunter la route du producteur de blocs multi-concurrents proposée par Duality.

5. Les algorithmes de consensus, tels que Tendermint ou Hotstuff2 susmentionnés, peuvent garantir que les nœuds Rollup sont en accord avec la séquence proposée par le grand livre.

6. Client RPC pour soumettre des blocs/lots à la couche de consensus DA+ sous-jacente afin que les blocs/lots puissent être ajoutés en toute sécurité à la couche DA, garantissant la finalité "finale" et rendant toutes les données de transaction disponibles sur la chaîne.

7. Séparez les rôles des constructeurs et des producteurs de blocs pour assurer l'équité et la cohérence, et éviter le vol de MEV. Supprime également le tri effectué, ce qui est important pour optimiser l'efficacité, réduire le PGA et augmenter le CR.

• Les nœuds de cumul reçoivent des blocs ordonnés du trieur pour une soumission souple et reçoivent des blocs de couche DA ordonnés pour une soumission dure. *

Les données d'appel sont d'abord publiées sur le réseau de base, où un consensus est exécuté pour garantir les transactions utilisateur et Rollup. Ensuite, le nœud Rollup exécute la transaction et soumet une fonction de transition d'état à la chaîne canonique Rollup. Un réseau de commandes partagées offre à Rollup l'immédiateté et la résistance à la censure. Les cumuls conservent leur souveraineté car toutes les données de transaction sont stockées dans la couche de base, ce qui leur permet de bifurquer à tout moment à partir de l'ordre partagé. La racine d'état de la fonction de transition d'état Rollup (STF) est calculée à partir des racines de transaction (entrées) envoyées par l'ordonnanceur partagé à la couche DA. Dans Celestia, les racines d'état sont générées lorsque des données sont ajoutées à la chaîne et qu'un consensus est atteint. Puisque vous avez déjà la racine de la transaction (et toutes les données disponibles), Celestia peut fournir aux clients légers (nœuds Rollup fonctionnant sur Celestia) une petite preuve d'inclusion.

Afin de fournir l'expérience utilisateur que les utilisateurs attendent, les nœuds Rollup reçoivent des blocs ordonnés (qui sont également envoyés à la couche DA). Cela peut fournir à Rollup des garanties déterministes souples - des garanties que les blocs seront finalement ordonnés dans l'ordre sur la couche DA, à quel point les nœuds Rollup exécutent des transactions et fournissent de nouvelles racines d'état.

Création de bloc et emplacement

Afin de déterminer l'heure de création du bloc, le séquenceur doit définir le créneau. Le séquenceur doit soumettre des lots à intervalles fixes (généralement X secondes), où X est le créneau horaire. Cela garantit que les transactions sont traitées rapidement et efficacement, car sinon le masternode d'un créneau particulier expirerait et perdrait la récompense de signature (et la récompense d'exécution). Par exemple, le temps de blocage de Celestia (selon les spécifications de GitHub) est d'environ 15 secondes. Puisque cela est connu, nous pouvons faire des hypothèses sur le nombre de "slots/blocs" que nous pourrions avoir de l'ensemble partagé de coorteurs à la couche DA et les nœuds Rollup sont chargés dans des blocs finalisés. À cet égard, nous pouvons nous référer à Tendermint optimisé ou Hotstuff2.

Dans le même créneau, nous pouvons soumettre plusieurs lots de transactions, à condition que la conception comprenne des mécanismes permettant aux nœuds complets de cumul de les traiter efficacement en un seul bloc (dans ce délai et les paramètres de délai d'attente). Cela permet d'optimiser davantage la création de blocs et garantit que les transactions sont traitées rapidement. De plus, des créneaux peuvent également être utilisés pour faciliter l'élection de nœuds maîtres de tri. Par exemple, vous pouvez sélectionner au hasard un nœud maître d'emplacement dans le pool de jalonnement en fonction du poids de jalonnement. Faire cela d'une manière qui préserve la confidentialité et utilise quelque chose comme l'élection secrète du chef pour minimiser la censure est la meilleure option ; ou même une configuration de technologie de validation distribuée telle que des solutions comme Obol/SSV. La latence et le temps de créneau ont un impact important sur les soumissions de blocs et les versions du protocole. Nous devons donc examiner comment cela affecte le système. Bloxroute a d'excellentes recherches et points de données sur Ethereum en particulier. Dans MEV-Boost, les producteurs de blocs participants (validateurs ou séquenceurs dans le cas de Rollup) demandent GetHeader au relais. Cela leur donne la valeur de l'offre de bloc, qui est la valeur d'un bloc particulier. Il peut s'agir du bloc de valeur la plus élevée reçu à chaque fois. Pour chaque créneau, les validateurs demandent généralement GetHeader environ 400 ms après le démarrage du créneau - en raison du grand nombre de validateurs, les relais doivent souvent soumettre de nombreuses demandes. C'est également ce qui peut arriver avec de grands groupes de trieurs partagés. Cela signifie que vous avez besoin de l'infrastructure en place pour faciliter ce processus.

Les relais aident également à faciliter la séparation des constructeurs et des producteurs de blocs, tout en vérifiant que les constructeurs ont construit les bons blocs. Ils vérifient également que les frais sont payés correctement et agissent comme une protection DoS. En outre, ils sont essentiellement les gardiens des blocs et gèrent l'enregistrement des validateurs. Ceci est particulièrement important dans l'architecture d'un séquenceur illimité, car vous devez savoir qui a participé et qui n'a pas participé (par exemple, la couche de synchronisation évoquée précédemment).

En ce qui concerne les temps de bloc (c'est-à-dire les blocs soumis par les créateurs), ils se produisent généralement autour de 200 millisecondes. Ils commencent généralement à s'exécuter avant/après environ 200 ms, bien que, comme GetHeader, il existe des variations considérables. Si le constructeur envoie le bloc à plusieurs relais, cela entraînera un retard considérable. Bloxroute a également examiné ce qui se passe lorsque des blocs sont envoyés à plusieurs relais. Comme vous pouvez vous y attendre, le délai de propagation des blocs vers davantage de relais sera plus long. En moyenne, il a fallu au deuxième relais 99 millisecondes pour passer le bloc, au troisième 122 millisecondes et au quatrième 342 millisecondes.

Ce que nous avons probablement appris au cours des derniers mois, c'est que RPC est très important pour les blockchains. C'est un énorme fardeau sans l'infrastructure appropriée en place, et il est également essentiel d'avoir une option RPC appropriée. Dans ce cas, RPC est important pour les investisseurs de détail qui envoient leurs transactions à RPC (et au mempool public). Bloxroute a effectué un petit test de 20 transactions envoyées à divers RPC et a mesuré le temps nécessaire pour que chaque transaction soit incluse dans un bloc.

Source : Laboratoires Bloxroute

Fait intéressant, certains RPC n'incluent les transactions que plusieurs blocs plus tard, selon le constructeur qui gagne dans le bloc suivant. Si le RPC envoie la transaction à plusieurs constructeurs, la probabilité d'une inclusion rapide est plus élevée. Bien qu'il soit possible pour les initiateurs de transactions de tirer parti de leur position unique dans le flux d'ordres pour cibler des constructeurs spécifiques ou même créer leurs propres blocs.

Leurs performances sont également intéressantes dans les statistiques de performances des relais d'Ethereum. Cela nous aide à mieux comprendre le fonctionnement de PBS dans un monde à plusieurs validateurs/constructeurs/relais, ce que nous espérons réaliser avec la mise à niveau Rollup. Metrika a d'excellentes statistiques à ce sujet et tous les points de données leur sont dus.

Il est important de noter que les enchères manquées se produisent lorsqu'un relayeur est censé enchérir, mais n'enchérit pas. Les attentes cibles proviennent des validateurs enregistrés auprès d'un relais particulier pour un créneau donné. Ce n'est pas un défaut de relais en soi, et il n'est pas non plus géré de cette façon au niveau du protocole.

Source : app.metrika.co

Si un défaut survient (tel qu'un relais desservant un bloc invalide) et qu'il en est responsable, il sera compté comme un défaut. Ceux-ci sont généralement peu fréquents et sont principalement des échecs de préférence d'enregistrement (c'est-à-dire des limites de gaz ou des frais qui ne correspondent pas aux enregistrements pour un validateur particulier). Encore plus rares sont les défaillances de la couche consensus, qui sont incompatibles avec les règles de la couche consensus Ethereum, telles que des emplacements incorrects ou des hachages parents non alignés avec le bloc précédent, etc.

En termes de latence (comme le temps qu'il faut à un validateur pour recevoir un en-tête de bloc construit par un constructeur), les données sont très cohérentes. Bien qu'il existe certaines valeurs aberrantes, telles que le relais demandé se trouvant dans un emplacement géographique différent de celui du validateur choisi.

Source : app.metrika.co

En ce qui concerne les constructeurs, le nombre total de constructeurs sur MEV-boost est d'environ 84, les trois premiers constructeurs construisant environ 65 % des blocs construits. Bien que cela puisse être quelque peu trompeur car ce sont aussi les constructeurs les plus anciens. Les résultats sont similaires si le délai est réduit. Le nombre de constructeurs actifs réels est beaucoup plus faible, 35 au cours des 30 derniers jours et 24 au cours de la semaine dernière. La concurrence est féroce, et généralement le constructeur le plus fort gagne. Un flux de commandes exclusif peut déjà exister, ce qui ne fera qu'aggraver la situation. Nous nous attendons à ce que la répartition des constructeurs reste relativement centralisée (puisqu'il s'agit d'une course pour un flux de commandes optimal et une optimisation du matériel) à moins que nous n'apportions des modifications majeures à la configuration. Bien qu'il ne s'agisse pas d'un problème fondamental, il s'agit toujours d'une force centralisatrice dans la pile et nous aimerions entendre des idées sur la façon de défier le statu quo ici. Si vous souhaitez approfondir ce problème (sérieux), nous vous recommandons vivement de lire les articles de Quintus sur le flux de commandes, les enchères et la centralisation.

Pour le rôle Builder dans la future pile de modularité, nous sommes presque sûrs (au moins dans la configuration du SDK Cosmos) que nous verrons une configuration Skip/Mekatek-like Builder Modules. Une autre solution est une configuration de type SUAVE, telle qu'une chaîne de constructeurs mondiale spécifique fournissant des services de création de blocs et de préférences d'enchères à un nombre quelconque de chaînes pour assurer le PBS. Nous explorerons cette solution plus en profondeur ultérieurement et apporterons des réponses aux questions non abordées ici.

En ce qui concerne les relais, nous vous recommandons vivement de lire un article d'Ankit Chiplunkar de Frontier Research et de Mike Neuder de la Fondation Ethereum intitulé Optimistic relays and where to find them. Cet article détaille le fonctionnement des relais dans MEV-boost, leurs compromis et coûts d'exploitation actuels, ainsi que certains changements susceptibles d'augmenter l'efficacité. Fait intéressant, faire fonctionner un relais dans MEV-Boost coûte actuellement environ 100 000 $/an selon les estimations de Flashbot.

Déterministe

Avant de parler du déterminisme des blockchains modulaires (telles qu'elles se présentent actuellement), jetons un coup d'œil à notre précédent article "Modular MEV". Notez qu'il ne s'agit pas d'une vue "officielle" ni complète de la finalité, mais nous pensons qu'elle représente le plus fidèlement les nuances de la finalité du cumul pour faciliter la compréhension.

En attente_On_L2 : le trieur Rollup représente un engagement souple selon lequel la transaction d'un utilisateur sera finalement validée et finalisée sur la couche de base de sa sécurité.

Finality_On_L2 : le séquenceur s'est engagé dans la fonction de transition d'état du Rollup et le bloc a été ajouté à la chaîne canonique du Rollup.

En attente_On_L1 : la fonction de transition d'entrée ou de sortie/d'état de la transaction a été publiée sur L1, mais la preuve de validité n'a pas encore été émise, ou la période d'arbitrage n'est pas encore terminée - cela nécessite Ethereum pour deux époques consécutives. C'est le point auquel la plupart des cumuls optimistes disent qu'ils ont atteint la finalité, mais il y a encore une période de défi arbitraire de 7 jours à ce stade selon la spécification du pont inter-chaînes.

Finalité_Sur_L1 : pour un cumul optimiste, la période d'arbitrage est terminée, ou une preuve de validité publiée et vérifiée a été confirmée par une majorité qualifiée dans deux époques consécutives.

Maintenant, dans un Sovereign Shared Sort Rollup, cela semble légèrement différent, essayons de l'expliquer avec un diagramme :

Dans ce cas, on peut théoriquement obtenir un déterminisme sur L1 avant L2, etc. ? Oui, dans ce cas, L2 est souverain après tout. Cela suppose qu'il n'y a pas de preuves de fraude et de périodes de contestation, ou que vous utilisez une preuve de validité.

Alors, comment atteignons-nous ces niveaux de finalité ? La finalité du bloc est atteinte lorsqu'un bloc est ajouté à la chaîne canonique, qui ne peut pas être retiré. Cependant, il y a quelques nuances ici, selon les nœuds pleins ou légers. Dans le cas d'un bloc ordonné, il est déterministe une fois qu'il est inclus dans un bloc de couche DA. Les blocs (avec des racines d'état) sont appliqués par des nœuds/validateurs complets de cumul, ce qui leur donne la garantie d'une racine d'état valide dérivée des blocs ordonnés de la couche de base. Pour le déterminisme au-delà des nœuds complets (comme pour les clients légers ou les ponts inter-chaînes), vous devez être sûr de la validité de cette racine d'état. Ici, vous pouvez utiliser l'une des méthodes décrites ci-dessous. En outre, une autre approche consiste à rendre les validateurs responsables de la preuve correcte de la racine d'état (la voie Optimiste), via une caution et une preuve de fraude ultérieure. De plus, vous pouvez fournir une preuve de validité (ZK).

Différentes façons d'atteindre la finalité du bloc :

1. Par Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) et d'autres méthodes probabilistes.

2. Une méthode démontrable au moyen d'un nombre suffisant de membres du comité signant des blocs. (par exemple Tendermint 2/3, Hotshot2 ou autres types de PBFT)

3. Dépend de l'ordre des transactions/blocs sur la couche DA et de ses règles, à savoir les règles de sélection canonique de la chaîne et du fork.

Nous pouvons atteindre différents types de finalité par différents mécanismes.

Un type de finalité est la «finalité douce» (comme en attente), qui peut être obtenue par l'élection d'un seul chef. Dans ce cas, chaque slot n'aura qu'un ou zéro bloc (validé ou non), et la couche de synchronisation peut assumer en toute sécurité la séquence des transactions dans ces blocs.

Un autre type de finalité est la "finalité prouvable", qui offre des garanties plus fortes (essentiellement définitives) que la finalité souple. Pour obtenir une finalité prouvable, la majorité des donneurs d'ordre doivent signer un bloc, exprimant ainsi leur accord sur le fait que le bloc est canonique. Bien que cette approche soit agréable, elle peut ne pas être nécessaire si une élection à un seul chef a été mise en œuvre, car elle garantit essentiellement l'ordre des blocs. Évidemment, cela dépend de l'algorithme d'élection du chef particulier mis en œuvre. Par exemple, s'agit-il d'une mise en œuvre à 51 %, d'une mise en œuvre à 66 % ou d'un leader unique (de préférence aléatoire (VRF) et élection secrète). Si vous souhaitez en savoir plus sur le déterminisme dans Ethereum, lisez cet article que nous vous recommandons vivement, et l'article que nous recommanderons plus tard pour les ensembles de trieurs illimités.

sous licence, semi-licence ou non-permis

Pour prévenir d'éventuelles attaques DoS, des barrières économiques doivent être définies afin de rejoindre le groupe de commande et de soumettre des transactions à la couche de commande. Dans les groupes bornés (nombre fini de trieurs) et non bornés (nombre illimité de trieurs), des barrières économiques doivent être mises en place pour soumettre les lots à la couche DA afin d'empêcher la couche synchronisation (propagation de blocs entre trieurs) d'être ralentie ou sous attaque DDoS . Cependant, la couche DA elle-même offre également une certaine protection, car la soumission de données à celle-ci nécessite un coût (da_fee). Le dépôt de garantie requis pour rejoindre le groupe illimité doit couvrir tous les coûts supplémentaires nécessaires pour empêcher la couche de synchronisation d'être spammée. En revanche, la marge nécessaire pour rejoindre un groupe délimité dépendra de la demande (équilibrée d'un point de vue coûts/revenus).

Pour un ensemble illimité de trieurs, nous ne pouvons pas obtenir une finalité prouvable au niveau du trieur (puisque nous ne savons jamais exactement combien de votants/signataires actifs il y a). D'un autre côté, dans un groupe limité de coortiers, la finalité prouvable peut être atteinte par une majorité de coortiers signant des blocs. Cela nécessite que la couche de synchronisation soit consciente de la couche séquenceur et du nombre de séquenceurs actifs à un moment donné, ce qui représente une surcharge supplémentaire. Dans un ensemble limité de trieurs (par exemple jusqu'à 100), vous pouvez également optimiser le nombre de trieurs pour améliorer les "performances", bien qu'au détriment de la décentralisation et de la résistance à la censure. L'importance des groupes délimités et des garanties économiques pour fournir une certitude démontrable "rapide" est également déterministe.

Les types de trieur illimité et de trieur borné sont également reflétés dans les blockchains traditionnelles.Par exemple, le PoS (Casper+LMD-GHOST) dans Ethereum adopte le type non borné, tandis que la chaîne basée sur Cosmos SDK/Tendermint adopte le type borné. Une réflexion intéressante est la suivante : nous attendons-nous à voir une économie et des options de type preuve de participation de la part de la communauté autour des commandes partagées ? À cet égard, nous avons constaté un mouvement vers la centralisation de certaines entités (donc sans limite n'a pas vraiment d'importance si vous avez déjà de grands fournisseurs/pools de preuve de participation). Même s'ils "cachent" la centralisation, après tout, vous pouvez toujours exploiter si vous le souhaitez. D'un point de vue idéologique, les choix devraient presque toujours être illimités - mais rappelez-vous que les principes économiques les rendent de toute façon très similaires. Quels que soient les participants, l'économie de ce que vous payez devrait toujours être la même, comme le coût de la DA et le coût du matériel (bien que cela puisse être réduit par le nombre de preuves de participation que vous allouez et que vous expérimentez, et efficace exploitation de l'infrastructure). Même dans le monde limité du PoS, nous avons vu un groupe de fournisseurs d'infrastructure devenir les validateurs les plus importants et les plus courants sur presque toutes les chaînes. Sur la plupart des chaînes Cosmos, les dépendances entre validateurs sont déjà très importantes, ce qui constitue certainement un danger pour la décentralisation et la résistance à la censure desdites chaînes. Pourtant, un fait très différent est que tout investisseur de détail peut miser n'importe quel montant avec n'importe quel validateur de son choix. Malheureusement, cela est généralement attribué en haut de la liste et la vie continue. Nous demandons à nouveau : attendons-nous un modèle économique similaire dans un monde modulaire ? On souhaite que ce ne soit pas le cas, mais avec la spécialisation, vous avez souvent besoin du meilleur ajustement - et ils ont tendance à être des fournisseurs professionnels de preuve de participation. Nous aborderons également ces questions économiques dans un chapitre séparé plus tard.

Cependant, une chose importante à retenir dans tous ces problèmes est que la chose la plus importante est l'authentification de l'utilisateur final, qui est accessible à tous, où qu'ils se trouvent (même à Gizeh) via les clients légers et la pyramide DAS).

Source : @JosephALChami

Voici les compromis et les avantages des trieurs bornés et non bornés :

Ensemble de tri illimité :

*Toute personne disposant de suffisamment d'obligations/de jalonnement peut devenir un trieur = haut degré de décentralisation

• Il n'est pas possible d'avoir une seule élection de chef, car le trieur est essentiellement infini.
• L'élection d'un leader non unique via VRF est possible, mais il est difficile de déterminer les paramètres VRF car on ne sait pas combien de commandes il y aura. Cela devrait également être une élection secrète du chef si possible pour éviter les attaques DoS.
• Pas d'élection de leader = gaspillage de ressources Problème : La construction de blocs est essentiellement une compétition gratuite, celui qui soumet le premier bloc/lot valide gagne, et tous les autres perdent. · · · Pas de certitude démontrable au niveau du donneur d'ordre, uniquement probabiliste : par exemple LMD Ghost+Casper
• La finalité n'est atteinte qu'après l'écriture des lots sur la couche DA (limitée uniquement par le temps de bloc sous-jacent, 15 secondes dans le cas de Celestia).
• Les ensembles non bornés sont "meilleurs" résistants à la censure que les ensembles bornés.

Ensemble borné de trieurs :

C'est l'une des solutions d'Ethereum pour le déterminisme à créneau unique et le fait d'avoir un comité super "majoritaire".

• Il y a une limite au nombre de séquenceurs autorisés à un moment donné.
• Les ensembles bornés sont plus complexes que les ensembles non bornés.
• Une élection de chef unique peut être mise en œuvre, offrant une garantie déterministe forte pour la couche de tri.
• La couche de synchronisation doit comprendre l'ensemble des classeurs pour déterminer quels blocs sont valides.
• L'écriture d'ensembles de trieurs (ou de modifications d'ensembles) dans des blocs de couche de règlement (tels que des règles de sélection de fourche), qui sont écrites dans la couche DA, permet à la couche de synchronisation de déterminer indépendamment l'ensemble de trieurs. Par exemple, c'est ce que fait le Rollup de Sovereign Labs, les changements de collection sont écrits dans une preuve de validité publiée sur la couche DA.
• Les fortes garanties de finalité de la couche de commande peuvent ne pas être nécessaires si la couche DA est suffisamment rapide (cependant, la plupart des configurations de couche de règlement non optimisées actuelles ont au moins 10+ secondes de temps de bloc).

Il y a une marge de conception considérable pour la façon dont ces ensembles de trieurs sont surveillés et de nouveaux membres sont ajoutés ou supprimés. Par exemple, cela sera-t-il réalisé grâce à la gouvernance des détenteurs de jetons (que diriez-vous de nombreux jetons et cumuls différents utilisant des collections alors ?). Cela signifie que la signalisation des changements hors chaîne peut être possible grâce à un consensus social (par exemple, prenez Ethereum comme exemple). Cependant, rappelez-vous que le consensus réel sur la chaîne est clairement établi et que des sanctions pour violation des règles de consensus existent déjà.

Mécanisme économique pour les trieurs partagés

L'économie du partage d'un réseau de séquenceurs permet des options intéressantes. Comme nous l'avons vu précédemment, les validateurs d'un réseau de commande partagé ne sont pas très différents des validateurs L1 typiques. Le réseau auquel il participe est simplement plus optimisé pour effectuer une tâche, qui est de recevoir des intentions (anciennement PBS), et donc de proposer et de commander des transactions. Tout comme les validateurs "réguliers", il existe des composants de revenus et de coûts. Des deux côtés de l'équation, il y a beaucoup de flexibilité dans les réseaux auxquels les validateurs participent, comme pour la L1 régulière.

Les revenus proviennent des utilisateurs ou des Rollups avec lesquels ils souhaitent finalement interagir en payant une certaine redevance pour l'utilisation du séquenceur partagé. Ces frais peuvent être un pourcentage du MEV retiré (la saisie de nombres peut être difficile à approximer), des transferts de valeur inter-chaînes, du gaz ou des frais fixes par interaction. La solution de revenus la plus appropriée pourrait être de payer moins de valeur au donneur d'ordre partagé que la valeur supplémentaire obtenue grâce au donneur d'ordre partagé Rollup, ainsi que les avantages de la sécurité et de la liquidité partagées. Mais l'inconvénient est qu'il est difficile de quantifier les avantages de la décentralisation d'une autre partie de la pile. Cependant, à mesure que le réseau de commande partagé se développe dans son propre écosystème, sa capacité à extraire des frais peut augmenter. Cela est dû en grande partie à leur capacité inhérente à s'agréger facilement, avec certaines économies d'échelle. Au fur et à mesure que de plus en plus de Rollups et d'applications rejoindront le réseau, de plus en plus de MEV interdomaines pourront extraire.

En termes de coût, les réseaux de commande partagés ont également des options concurrentes. Ils peuvent facilement financer leur utilisation du réseau en finançant le coût de la publication sur la couche DA, ou même le coût de l'interaction avec les applications sur Rollup. Ceci est similaire à la stratégie utilisée par les entreprises Web 2.0, où vous prenez la perte initiale sur l'acquisition d'utilisateurs (ou rollup), en espérant que leurs revenus à long terme l'emporteront sur les frais. Une autre méthode plus nouvelle ou crypto-native consiste à permettre à Rollup de payer les frais DA avec son jeton natif. Ici, la couche de tri partagée supporte le risque de tarification entre le jeton requis pour publier des données sur la couche DA et le jeton natif de Rollup. En substance, il s'agit toujours d'un coût initial de trieur partagé, mais il crée une cohérence d'écosystème en obtenant le jeton du "fournisseur" (c'est-à-dire Rollup). Ceci est quelque peu similaire à la construction d'entrepôt que nous avons expliquée dans le document AppChain, et différentes formes de DA peuvent être utilisées pour réduire les coûts. Différents niveaux DA offriront des prix différents en raison de l'utilisation, de la capacité des utilisateurs à vérifier facilement via un client léger ou simplement à faire des choix de taille de bloc différents. Enfin, le trieur partagé peut également regrouper les transactions avant de les publier sur la couche DA. Dans le cas de ZKR, cela peut réduire les coûts de transaction grâce à un certain nombre de soldes de transactions, et en termes d'ORU, vous pouvez effectuer diverses optimisations de gaz de traitement par lots, que nous pouvons actuellement voir sur divers Rollups. Cela réduira la quantité de données devant être publiées sur la couche DA, réduisant ainsi le coût du réseau de séquenceur partagé et augmentant la rentabilité de l'ensemble du réseau. Cela se fera au prix d'une limitation de l'interopérabilité et de la modification des temps de finalité des blocs (déterminisme sur L1 comme mentionné précédemment).

Dans l'ensemble, l'économie du partage d'un réseau de séquenceurs permet des stratégies d'expérimentation et d'amorçage intéressantes. Nous estimons que la principale différence sera la taille de l'écosystème, de sorte que le nombre de MEV interdomaines est supérieur à l'aspect coût. Nous vous recommandons également fortement de consulter le blog de l'équipe Espresso sur les commandes partagées, ils couvrent également les compromis économiques (et positifs) de ces types de réseaux. Pour montrer pourquoi Rollup est motivé à tirer parti des trieurs partagés (en plus de l'économie), nous pouvons le considérer du point de vue de la théorie de l'agrégation.

Théorie de l'agrégation et trieurs partagés

Une autre façon de décrire les propriétés apportées par les trieurs partagés est à travers le prisme de la théorie de l'agrégation. La théorie de l'agrégation fait référence au concept selon lequel une plate-forme ou un agrégateur intègre d'autres plates-formes et leurs utilisateurs de manière systématique pour attirer l'attention des utilisateurs. Vous déplacez essentiellement le jeu de l'allocation d'une ressource rare (par exemple, l'espace de bloc) à la nécessité de contrôler une ressource abondante (encore une fois, l'espace de bloc a du sens dans cet exemple). La théorie de l'agrégation regroupe en fait les fournisseurs et les produits (c'est-à-dire Rollup et Blockspace) dans une expérience de super utilisateur pour servir la base d'utilisateurs agrégée. Au fur et à mesure que l'effet réseau de ces agrégateurs grandit, cette relation devient de plus en plus exclusive. Lorsque cela se produit, l'expérience utilisateur devient un différenciateur clé entre des configurations similaires. S'il existe des incitations à attirer de nouveaux utilisateurs (comme une bonne expérience utilisateur et une meilleure interopérabilité), il est peu probable que Rollup passe à son propre réseau ou à une configuration différente, car les effets de réseau entraînent de nouveaux fournisseurs et de nouveaux utilisateurs. Cela crée un effet de volant, non seulement du point de vue du fournisseur et de l'utilisateur, mais également d'un point de vue agrégé résistant à la censure.

Source : Théorie de l'agrégation 2015, Ben Thompson

Dans le domaine des trieurs partagés, la théorie de l'agrégation peut être considérée comme des "combinaisons" et des fédérations de divers rollups, tous utilisant des verticales similaires de la pile - se responsabilisant ainsi que les autres tout en permettant aux utilisateurs d'obtenir la même expérience.

Les fournisseurs (tels que les cumuls) ne sont théoriquement pas exclusifs à l'ensemble de coorteurs partagé, mais en pratique, l'ensemble de coorteurs partagé, ses cumuls et les utilisateurs bénéficient d'une série de boucles d'effets de réseau qui conduisent à une utilisation accrue de ces cumuls. Ces avantages facilitent l'intégration des Rollups et des utilisateurs dans une pile partagée, car ils ont plus à perdre s'ils ne participent pas. Bien que ces avantages puissent être difficiles à voir lorsque vous n'avez que deux Rollups partageant un seul ensemble de séquenceurs, ils deviennent plus clairs à mesure que vous ajoutez de plus en plus de Rollups et d'utilisateurs dans l'équation. Les ensembles de tri partagés ont une relation directe avec les utilisateurs, car ils commandent leurs transactions, même si les utilisateurs eux-mêmes ne savent pas qu'ils interagissent avec eux, car de leur point de vue, ils utilisent simplement des cumuls avec lesquels ils ont une raison d'interagir ( Cela signifie que les commandes/trieurs deviennent exclusifs). Le seul coût de ces trieurs est vraiment le coût matériel pour les faire fonctionner, tant que l'espace de bloc et les jetons qui le sécurisent sont précieux pour l'utilisateur final. Les frais de transaction sont numérisés, payés sur les portefeuilles des utilisateurs, et peut-être même à l'avenir, peuvent même être abstraits grâce à des avancées telles que les hôtes de paiement dans l'abstraction de compte (cependant, quelqu'un devra supporter le coût de l'AD, de la commande et de l'exécution).

Cela a plus de sens si l'on considère l'ancienne société de Josh et Jordan à Astria - Google. Depuis sa création, les produits Google se sont inspirés de l'idée d'AT, notamment dans Google Search, qui est créé en modularisant des pages et des articles individuels, les rendant directement accessibles via la fenêtre de recherche globale.

Dans le cas d'un ensemble partagé de trieurs, les utilisateurs qui utilisent des Rollups (ceux qui partagent un ensemble de trieurs) ont des coûts d'acquisition de plus en plus faibles, car à mesure que le nombre de fournisseurs (Rollup) augmente, ils sont susceptibles d'être attirés par l'ensemble . Cela signifie que, dans la plupart des cas, un agrégateur (ou multi-agrégateur) a un effet gagnant-gagnant possible, car la valeur d'un agrégateur augmente avec le nombre de fournisseurs (tant que l'expérience utilisateur est bonne, bien sûr). En revanche, sur un seul réseau série, l'acquisition de clients est limitée à un seul réseau et à ses applications. Si les utilisateurs souhaitent utiliser l'application Rollup sur un autre Rollup, ils devront (dans les limites actuelles) se déconnecter complètement du réseau. Cela signifie que l'adhérence et la valeur de l'utilisateur ne sont pas très élevées, et cela signifie également qu'à tout moment, si un autre écosystème Rollup est très apprécié (ou a plus d'incitations), du capital peut être perdu.

Résumé des attributs et des compromis

Les attributs

Un ensemble de tri partagé est un réseau de cumul qui regroupe et trie les transactions pour plusieurs cumuls. Ces Rollups partagent le même trieur. Cette mise en commun des ressources signifie que les Rollups gagnent en sécurité économique et en capacités anti-censure, ce qui peut fournir des garanties déterministes souples rapides et des transactions croisées conditionnelles.

À l'heure actuelle, il y a beaucoup de bruit sur l'atomicité parmi les Rollups qui partagent le même ensemble de trieurs, principalement pour savoir si c'est atomique par défaut - ce qui n'est pas le cas. Cependant, si les cumuls en question implémentent les fonctions de transition d'état (STF) les uns des autres en tant que dépendances entre eux, impliquant des transactions conditionnelles, ils peuvent en effet atteindre l'atomicité entre eux - tant que leur alignement slot/blocktime (comme avec les ensembles de trieurs partagés). Dans ce cas, pour obtenir l'interopérabilité atomique, il vous suffit d'exécuter un client léger de la chaîne B sur la chaîne A et vice versa (similaire au fonctionnement d'IBC). Pour renforcer davantage l'interopérabilité des mesures de sécurité (au-delà de faire confiance à un seul nœud complet en tant que nœud léger), vous pouvez implémenter ZKP (preuve d'état) pour résoudre le "problème oracle" d'assurer l'exactitude de l'état. Cela permettra de voir plus clairement si une transaction conditionnelle ou quelque chose comme ça a atteint un pont canonique entre les chaînes. Les preuves de fraude sont également une possibilité, mais laisseraient évidemment une période de contestation (c'est-à-dire qu'un tiers interviendrait pour couvrir le coût de ce risque). De plus, dans le cas de clients légers (plutôt que de nœuds complets), il y aura au moins un bloc de retard en raison de l'attente de l'en-tête de signature + de la fenêtre anti-fraude (le cas échéant).

Nous pensons que le problème du "pont inter-chaînes" est plus susceptible d'être résolu avec des clients légers et des preuves à connaissance nulle. Le défi avec l'utilisation d'un client léger (plutôt qu'un contrat intelligent) dans ce cas est que les hard forks (mises à niveau, etc.) du côté du nœud Rollup doivent se coordonner pour que leur pont fonctionne (tout comme IBC doit activer le même module d'état). Si vous souhaitez approfondir ce sujet particulier (et comment l'aborder), nous vous recommandons vivement de consulter cette présentation.

La raison pour laquelle les commandes partagées évoluent si bien est qu'elles n'exécutent et ne stockent aucun état (comme le font les commandes centralisées aujourd'hui). Il en va de même pour les nœuds Rollup eux-mêmes (sauf s'ils veulent l'atomicité entre eux - par exemple client léger/preuve d'état). Ces nœuds n'exécutent que les transactions valides pour leur cumul et toutes les transactions interdomaines conditionnelles valides pour eux. Si un nœud Rollup doit exécuter et stocker l'état de plusieurs Rollups, cela entrave l'évolutivité et réduit la décentralisation (et donc la résistance à la censure). Cela renforce également le concept de séparation producteur-constructeur de blocs (PBS). Bien que nous ayons encore besoin de séparer complètement les constructeurs et les producteurs de blocs. Dans la configuration actuelle, les ordonnateurs sont essentiellement un constructeur et un producteur de blocs (bien qu'ils n'exécutent pas de transactions). Une configuration idéale pourrait être celle où le donneur d'ordre n'existe que pour signer aveuglément des blocs à partir d'une configuration de constructeur hautement optimisée et s'assurer que les blocs sont correctement mis en œuvre (tout en offrant un degré élevé de certitude économique et de résistance à la censure à cette certification). De cette façon, ils peuvent fournir un degré élevé de sécurité et d'engagement pour garantir une finalité souple aux nœuds Rollup.

Pour les transactions conditionnelles de cumul croisé, elles existent également pour permettre aux nœuds de cumul (exécuteurs) de fournir des racines d'état intermédiaires, permettant l'atomicité entre les cumuls.

troquer

Le paramètre de délai d'attente susmentionné a des effets intéressants sur le MEV et l'inclusion des transactions, en fonction du mécanisme de masternode/consensus de l'ensemble de commandes. Par exemple, si le paramètre de délai d'attente est décrit comme relativement court dans notre article sur la chaîne spécifique à l'application, il est essentiel que les producteurs de blocs d'un ensemble décentralisé de commandes publient les données aussi rapidement que possible. Dans un tel monde, vous pouvez voir la concurrence entre les "validateurs" qui se font concurrence pour être des nœuds maîtres et enchérir sur la couche DA pour l'espace de bloc jusqu'à ce qu'elle ne soit plus rentable.

Comme Evan l'a expliqué dans son article original sur le paresseux sur les forums Celestia, attendre que les transactions soient publiées sur la couche de base (Celestia dans ce cas) avant de les exécuter est très inefficace. Depuis maintenant, vous êtes limité par le temps de blocage de la couche de base - qui est trop long pour attendre l'expérience utilisateur. Pour une meilleure expérience utilisateur, le trieur partagé fournit aux Rollups des engagements déterministes souples (comme décrit précédemment), qui offrent aux utilisateurs l'expérience utilisateur à laquelle ils sont habitués dans les Rollups centralisés existants (tout en maintenant la décentralisation et une résistance élevée à la censure). Les engagements souples sont essentiellement de simples engagements à l'ordre final des transactions, mais soutenus par de lourdes garanties économiques et une finalisation rapide une fois libérés. Ceci est également couvert par les preuves de fraude (comme mentionné dans l'introduction). La finalité matérielle réelle est atteinte une fois que toutes les données de transaction ont été publiées sur la couche de base (ce qui signifie que L1 atteint en fait une finalité plus rapide). Cela dépend si Rollup utilise des preuves de fraude ou des preuves à connaissance nulle pour sa vérification de preuve de souveraineté - ce qui se produit sur Rollup. La raison de vouloir cette séparation est de supprimer l'énorme goulot d'étranglement des transitions d'état du trieur. Au lieu de cela, les nœuds Rollup ne traitent que les nœuds qui sont valides pour eux (ce qui signifie que nous devons ajouter des transactions conditionnelles, une preuve d'état ou une validation de nœud léger pour une bonne interopérabilité). Le déterminisme dur dépend toujours de la couche de base (mais celle-ci peut atteindre 15 secondes sur Celestia, et est également déterministe sous Tendermint), ce qui nous donne des garanties de déterminisme dur relativement rapides sur Rollup.

Utilisez des preuves à connaissance nulle à l'intérieur du réseau pour optimiser la validation, la taille des transactions (par exemple, ne publiez que les différences d'état - mais cela ajoute un niveau de confiance plus élevé jusqu'à ce que le ZKP soit publié). Comme mentionné précédemment, ces preuves d'état peuvent être utilisées pour permettre aux chaînes/rollups connectés d'avoir une interopérabilité plus facile et plus rapide (sans attendre les fenêtres de défi).

Un inconvénient de ces transactions conditionnelles est qu'elles sont susceptibles d'être plus coûteuses, nécessitant des coûts de vérification et d'émission plus élevés (tels que le coût de la vérification de l'en-tête de bloc Tendermint, qui est subventionnée sur la chaîne Cosmos), et ajoutant une certaine latence au système ( mais toujours plus rapides que les cumuls isolés sont beaucoup plus rapides). L'atomicité obtenue par l'intégration partagée verticalement peut compenser ces problèmes.

Au cours de la phase d'amorçage d'un nouveau cumul, l'utilisation d'un ensemble partagé d'assembleurs a beaucoup de sens, et les avantages dont vous bénéficiez en tant que fournisseur l'emporteront probablement sur certains des compromis que vous pourriez être "obligés" de faire au niveau du fossé. Cependant, pour un Rollup déjà mature, où il y a beaucoup de transactions et d'activité économique, cela n'a probablement aucun sens de renoncer à une partie du fossé.

Cela soulève la question de savoir si nous avons besoin d'une redistribution économique/transactionnelle similaire (par Rollup) du MEV extrait pour inciter les Rollups déjà matures à rejoindre l'ensemble partagé - ou même empêcher les Rollups extrêmement matures de générer leur propre réseau. Tout cela est assez théorique, mais c'est sans aucun doute un processus de réflexion intéressant en ce qui concerne la façon dont les MEV dans les mondes verticaux partagés seront représentés entre de nombreux Rollups avec différents niveaux d'activité. Par exemple, si un Rollup unique qui génère de la valeur partage certains de ces bénéfices avec d'autres (n'apportant probablement pas beaucoup de "valeur") via le Sequencer Set, alors il doit y avoir plus de raisons pour qu'ils se déplacent dans leur propre système cloisonné. Sreeram par EigenLayr a également quelques réflexions à ce sujet, que nous vous recommandons également de lire.

Cela devient de plus en plus important si l'on considère qu'il y a un coût technique considérable pour les chercheurs pour développer de nouvelles chaînes, donc standardiser et fournir une certaine souveraineté sur "leurs" VEM peut être un bon point de départ. En pratique, dans MEV, l'interface (ou le logiciel) dominante peut l'emporter, mais la monétisation réelle de ce logiciel en exécutant des parties critiques de l'infrastructure est très difficile (conduisant à la centralisation). Au niveau du marché, ce qu'un ordonnateur partagé fournit est essentiellement un mempool commun pour plusieurs fournisseurs, avec une enchère centralisée, ce qui pourrait conduire à une concurrence plus saine.

Une préoccupation ici est que si deux Rollups exécutent des trieurs dans l'ensemble partagé, alors un Rollup avec une valeur "moins économique" (A) peut être sélectionné pour proposer un rollup avec un montant élevé de MEV + frais de Rollup (B). . Du point de vue de Rollup B, ils manquent essentiellement une valeur que, dans l'approche isolée, ils garderaient pour eux-mêmes.

Traiter les compromis d'interopérabilité

Une autre note sur les compromis présentés par l'interopérabilité et une autre façon de résoudre certains des problèmes suit :

Le but du réseau de commande partagé est de fournir une garantie canonique pour plusieurs chaînes, ce qui est évidemment un gros avantage dans ce cas. Ceci peut être combiné avec un mécanisme pour garantir des transitions d'état efficaces entre les Rollups. Il peut s'agir d'une approche basée sur un comité (par exemple PoS), de preuves sécurisées (l'approche Optimiste) ou de notre préférée - un ZKP soutenu par des signatures de comité. Étant donné que les trieurs partagés sont "paresseux", ils ne créent que des super blocs pour trier les transactions de plusieurs Rollups, et l'exécution de la transaction spécifique est laissée à un Rollup spécifique. Les preuves d'état (c'est-à-dire Lagrange, Axiom ou Herodotus, etc.) sont toutes des solutions possibles pour potentiellement obtenir des preuves de finalité à travers des cumuls souverains. Vous pouvez même ajouter des preuves de finalité économiquement garantie grâce à des éléments tels que des pools de jalonnement, EigenLayr, etc. L'idée de base est qu'un trieur partagé apporte une garantie économique d'ordre, et les preuves de validité générées à partir de ce tri sont déterministes. L'idée de base est que les Rollups peuvent exécuter des transactions de manière synchrone les unes avec les autres. Par exemple, un réseau de deux nœuds Rollup peut conditionnellement savoir que les deux historiques Rollup sont valides, via ZKP et les données disponibles (données publiées sur une couche DA efficace). En publiant un seul préfixe de bloc Rollup à partir des réseaux A et B, un nœud Rollup peut régler deux Rollups simultanément. Une chose à souligner est que les transactions de cumul croisé conditionnel consomment des ressources de deux systèmes distincts via une exécution partagée, de sorte que les transactions atomiques (ou synchrones) de cumul croisé sont susceptibles d'être plus coûteuses que les intra-transactions à cumul unique.

Succinct a également couvert les transactions "atomiques" inter-chaînes entre les Rollups avec des ordonnateurs partagés (et des preuves de fraude partagées) au sein de l'écosystème de l'hyperchaîne Optimism, qui peut être consulté ici. De plus, comme le dit Bo Du de Polymer : "Les transactions atomiques inter-chaînes sont comme l'acquisition de verrous entre les fragments de base de données lors de l'écriture".

L'avenir de l'intégration verticale

Le fonctionnement interne possible des chaînes SUAVE a déjà été exploré en profondeur par Jon Charbonneau et al, nous n'entrerons donc pas trop dans les détails. Si vous souhaitez une description plus détaillée, vous pouvez consulter son article. Néanmoins, nous pensons que l'intégration verticale mérite une introduction distincte, à la fois pour souligner à quel point nous pouvons être modulaires (et pourquoi) et pour présenter certains des problèmes et préoccupations associés à l'intégration verticale.

Alors que le système actuel de commande partagée d'Astria, Espresso et Radius est très modulaire, les commandes agissent toujours en tant que constructeurs et producteurs de blocs (bien que dans le cas d'Astria, ils n'exécutent pas de transactions). Astria a également activement intégré PBS dans son architecture depuis le début.

Si le PBS n'est pas intégré au protocole, il existe plusieurs façons de mettre en œuvre le PBS (bien qu'avec des degrés de décentralisation variables). Des produits comme SUAVE utilisent des modèles hors ligne comme MEV-Boost ou implémentent des modules de création tels que les modules Cosmos SDK construits par Mekatek et Skip.

Il convient de noter qu'aucune de ces méthodes ne s'exclut mutuellement. Vous avez la possibilité d'utiliser plusieurs méthodes différentes et de laisser chacun exprimer sa préférence. De cette façon, vous pouvez avoir des exécuteurs en compétition pour combler ces postes vacants. Ajouter plus d'options est toujours bon (et conforme à notre croyance en la modularité). Pourtant, différentes implémentations auront des compromis différents. Par exemple, dans un cas comme SUAVE, vous pouvez ajouter une protection de la vie privée via la technologie SGX ou Crypto, et ajouter la sécurité économique Crypto à la vérité, au lieu de compter sur un constructeur PBS centralisé entièrement fiable. (Merci à Jon Charbonneau pour ses commentaires ici).

L'intégration verticale dans la chaîne de création garantit l'équité sans prendre de raccourcis, ajouter de la latence et dégrader les performances. Par conséquent, la chaîne de construction doit être hautement optimisée et peut nécessiter un matériel coûteux et puissant (conduisant à la centralisation). Cela signifie que pour obtenir la validation de l'utilisateur final, nous aurions probablement besoin d'une sorte de nœuds légers (bien qu'ils devraient faire confiance aux nœuds complets), ou utiliser une configuration de type preuve d'état pour garantir que la chaîne et les utilisateurs ont la preuve que les préférences d'enchère sont remplis et les blocs sont corrects Construire.

Une chaîne comme celle-ci peut être très lourde pour l'état (nous voulons éviter cela), bien que ces transactions lourdes pour l'état soient priorisées via des contrats intelligents. Dans le cas d'une enchère prioritaire, soit elle est satisfaite, soit elle ne l'est pas (pendant une courte période), car les offres ne sont généralement valables que pendant une courte période, selon la préférence. Cela signifie que nous pourrons peut-être mettre en œuvre une expiration d'état très efficace (et précoce) pour les offres, ce qui nous permettra d'élaguer les données et de garder la chaîne "propre". Cette date d'expiration doit être suffisamment longue pour permettre aux offres d'être remplies en premier, mais la réduire trop rendrait presque impossible l'obtention de contrats à terme sur l'espace de blocs. Nous n'avons pas besoin de mettre à jour et de récupérer les contrats d'appel d'offres expirés car ils n'ont pas besoin d'exister pour toujours (contrairement aux applications) - cela peut être fait soit en fournissant des preuves d'état/de stockage lorsque les offres sont remplies, soit par des solutions de stockage DAS (telles que celles proposées par la solution Joachim Neu) pour la rendre plus "sûre" et digne de confiance.

Comme mentionné précédemment, la nécessité de vérifier "l'authenticité" de SUAVE peut être limitée aux "jusha" (utilisateurs avancés) de la plate-forme, car la plupart des utilisateurs et clients de SUAVE peuvent en tirer des avantages économiques élevés. Cela pourrait nous pousser à ne laisser les gens exécuter des nœuds complets que s'ils veulent valider - bien que cela exclut la grande majorité des gens (on pourrait dire qu'ils n'ont pas besoin de valider). C'est (à notre avis) l'opposé de Crypto, où nous préférerions implémenter une vérification SUAVE "sans confiance" via des preuves d'état ou des implémentations conviviales pour les clients légers.

La raison pour laquelle cela est nécessaire est que vous souhaitez vérifier que votre priorité d'enchère a été remplie correctement et que le bloc a été rempli avec les informations correctes lors du paiement (pour éviter les regroupements et autres bogues). Il s'agit essentiellement d'un problème d'oracle - en fait, il peut être résolu avec une preuve d'état (comme c'est le cas avec tous les SUAVE). Cependant, ces preuves d'état soulèvent un autre problème lors du croisement des chaînes, comment relayer ces informations à travers les chaînes d'une manière qu'elles n'aient pas été falsifiées ou dissimulées ? Cela peut nécessiter de passer par une finalité économique forte (telle que celle proposée par Lagrangien), auquel cas vous pouvez utiliser les validateurs de reprise d'EigenLayr pour prouver la finalité et l'authenticité de la chaîne, et avoir des contraintes économiques très fortes. Cela soulève alors un autre problème (par exemple, le contrat d'appel d'offres stipule que la "machine oracle" - dans ce cas, le re-gageur - a désigné le jeton mis en gage et fourni une liaison économique - mais comment pouvons-nous faire un consensus entre le slashing externe ? Alors que vous pouvez écrire des critères de slashing, ce n'est pas un consensus, ce qui signifie que le slashing social sera exploité via des contrats intelligents (ce qui n'est presque jamais "équitable" et peut causer des problèmes). C'est actuellement le cas chez EigenLayr. .

Alors, où cela nous mène-t-il ? Peut-être, jusqu'à ce que nous obtenions une réduction "sans confiance" sur la chaîne au-delà du consensus, des chaînes comme SUAVE peuvent avoir besoin de leurs propres algorithmes de consensus et de la sécurité cryptoéconomique pour prouver les préférences d'enchères et construire la certitude des blocs - Cependant, cela signifie ajouter plus de vecteurs d'attaque cryptoéconomiques, surtout si le Rollup valeur de ses blocs de construction est bien supérieure à sa propre sécurité crypto-économique.

De plus, il reste encore beaucoup d'espace de conception dans les chaînes de type SUAVE et les MEV inter-domaines.Voici quelques pistes de recherche possibles :

• Correspondance d'intention et systèmes basés sur l'intention
• Optimisation convexe dans le trading multi-actifs
• ADSL
• Réaffectation MEV
• Guerre retardée
• Problème de mise à l'échelle avec un seul ensemble d'acteurs, mais doit être construit pour plusieurs machines d'état Rollup
• Expression de préférence

Concernant l'expression de préférence, pour interagir avec un contrat intelligent dans l'EVM, il est nécessaire d'envoyer un appel de contrat (message) à une fonction spécifique à l'adresse du code déployé contenant l'instruction d'exécution. Bien que les utilisateurs fournissent une entrée, ils peuvent ne pas avoir le contrôle sur la sortie en raison d'un statut possible.

En revanche, les systèmes de conception d'expression de préférence (tels que SUAVE et Anoma) exigent uniquement que les utilisateurs signent les préférences avec une caution, qui est versée aux constructeurs et aux producteurs de blocs si les préférences du chercheur sont satisfaites. Pour une logique combinatoire complexe, telle que des séquences de transactions pour les chercheurs et constructeurs MEV, différents langages et machines virtuelles peuvent devoir être implémentés. Il s'agit d'un nouvel espace de conception qui a reçu beaucoup d'attention ces derniers temps, en particulier l'architecture Anoma. De plus, nous vous recommandons vivement ce court article.