transmettre le titre original 'nous construisons tous la même chose'

introduction

ce post analyse ce qui suit

• exécution asynchrone - pourquoi des blockchains intégrées à haute performance (par exemple, SolanaetMonad) permettra de dissocier l'exécution du consensus sur l'ordonnancement (séquençage).
• séquençage paresseux - comment ils vont refléter la conception d'un séquenceur paresseux (par exemple, @astriaorg/hj6ccpp9t">astria).
• préconfirmations - préconfs sur Ethereum L1 et rollups basés.
• basé vs non basé - comparaison des rollups basés + preconfs vs des rollups non basés + fallback de couche de base.
• composabilité synchrone universelle - via inclusion atomique (à partir de séquenceurs partagés) + sécurité cryptographique (par exemple, )AggLayeret/ou une preuve en temps réel).
• Les rollups basés sur la rapidité - les rollups basés devraient simplement avoir une couche de base rapide.
• jeux de timing - Le temps, c'est de l'argent, et comment cela sous-tend les divergences de fin de partie entre solana et ethereum.
• Décentralisation pour la résistance à la censure - commentséparation attester-proposerviaenchères d'exécutionpeut préserver des validateurs décentralisés qui peuvent garantir la résistance à la censure aveclistes d'inclusion.

enfin, et surtout, nous verrons pourquoinous construisons tous putain la même chosealors peut-être nous devrions simplement...

optimisation de la réplication de la machine d'état (smr)

nous partirons des bases pour comprendre que l'objectif final des blockchains à haute performance (par exemple, Solana, Monade, @patrickogrady/rys8mdl5p#mitigation-strategy-enable-profit-maximizing-builders-to-minimize-invalidtps">hypersdk) approche celle d'un séquenceur paresseux (par exemple, @astriaorg/hj6ccpp9t">astria). nous reviendrons plus tard pour les comparer aux rollups basés sur Ethereum + preconfs.

Séquençage vs exécution

les blockchains sont machines à états répliquéesLes nœuds décentralisés détiennent et mettent à jour leur propre copie de l'état du système. Pour faire avancer la chaîne, les nœuds exécutent la fonction de transition d'état (STF) sur l'état actuel + les nouvelles entrées (par exemple, de nouvelles transactions). Cela produit le nouvel état.

nous utiliserons les termes suivants tout au long de cette section :

• syntaxe valide - la transaction est bien formée avec une structure de transaction et une signature appropriées.
• sémantiquement valide - la transaction effectue une transition d'état valide (par exemple, paie les frais requis).
• séquence - détermine l'ordre et l'inclusion des données.
• exécuter - interpréter et agir sur les données conformément au stf.
• construire - créer un bloc (ou un morceau de bloc partiel / fragmenté) à partir des transactions stockées localement.
• vérifier - effectuer la vérification syntaxique et/ou sémantique requise d'un bloc (ou d'un morceau/partie partielle de bloc/déchiqueté).
• replication - diffuser un bloc (ou une partie de bloc/fragment) à d'autres validateurs.

zoomons sur le séquençage et l'exécution, car ce sont les sous-tâches principales nécessaires pour calculer l'état de la chaîne :

De plus, les nœuds vérifient et répliquent les données à travers le réseau. Les nœuds parviennent à un consensus pour maintenir une vue cohérente de la chaîne.

Cependant, les architectures de chaînes différentes divergent de manière significative quant à qui est responsable de ces tâches et à quel moment elles le font (par exemple, la construction et la vérification des blocs peuvent ou non inclure l'exécution). Le temps de bout en bout du processus completréplication de machine à états (smr)la boucle dicte les limites inférieures de la latence système. différentes constructions peuvent donner des temps très variables, donc un processus smr qui est efficace Pipelines) ces tâches sont nécessaires pour des performances à faible latence et à haut débit.

dans les sections suivantes, nous verrons qu'une idée centrale de la mise en pipeline efficace consiste à se concentrer sur la réalisation d'un consensus sur les entrées d'exécution plutôt que sur les résultats d'exécution. cela nécessite de relâcher certaines contraintes sur les transactions pouvant être incluses. nous devrons ensuite réintroduire certaines contraintes plus faibles pour garantir que le système reste utile et résistant aux attaques (par exemple, éviter les vecteurs DOS à partir de transactions qui ne paient pas de frais).

SMR traditionnel

La SMR traditionnelle (par exemple, Ethereum) couple étroitement le séquençage et l'exécution. Les nœuds complets séquencent et exécutent en continu toutes les transactions de la couche de base - les deux sont des prérequis pour que les nœuds parviennent à un consensus. En plus de vérifier que toutes les données de bloc sont disponibles (et séquencées), les nœuds doivent également exécuter le bloc pour vérifier que :

• toutes les transactions sont syntaxiquement et sémantiquement valides
• le nouvel état calculé correspond à celui fourni par le chef

Les validateurs ne voteront pour un bloc et ne construiront dessus que s'ils ont vérifié indépendamment son état. Cela signifie que l'exécution se produit au moins deux fois avant que le consensus ne puisse être atteint (c'est-à-dire que le producteur de blocs exécute pendant la construction + les validateurs receveurs exécutent à nouveau pour vérifier).

Dans ce modèle traditionnel, la construction et la vérification comprennent toutes deux l'exécution.

source: @patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: fortifying decoupled state machine replication

streaming smr

Le streaming SMR (par exemple, Solana) est une forme efficace de pipelineLes producteurs de blocs diffusent continuellement des morceaux de blocs (appelé lambeauxou morceaux) au fur et à mesure qu'ils sont construits. Les autres nœuds reçoivent et vérifient (y compris l'exécution) ces fragments en continu, même pendant que le reste du bloc est encore en construction. Cela permet au prochain leader de commencer à construire leur bloc plus tôt.

source: @patrickogrady/rys8mdl5p#making-the-case-for-decoupled-state-machine-replication-dsmr">vryx: renforcer la réplication déconnectée de la machine à états

Dans ce modèle de streaming, la construction et la vérification incluent toujours le séquençage et l'exécution. Cela augmente l'efficacité de SMR par rapport au SMR traditionnel sans relâcher aucune contrainte selon laquelle toutes les transactions incluses sont à la fois sémantiquement et syntaxiquement valides.

exécution asynchrone

approche intégrée

maintenant, pouvons-nous obtenir une meilleure performance si nous relâchons ces contraintes?

l'exécution asynchrone élimine l'exécution du chemin chaud du consensus - les nœuds parviennent simplement à un consensus sur l'ordre des données sans exécuter d'abord ces données. C'est plus efficace, c'est pourquoi SolanaetMonadles deux prévoient de mettre en œuvre une exécution asynchrone.

le leader construirait et répliquerait un bloc (ou des fragments) sans avoir besoin de l'exécuter. ensuite, d'autres validateurs voteraient dessus sans l'exécuter non plus. les nœuds ne parviennent à un consensus que sur l'ordre et la disponibilité des transactions. cela est suffisant car étant donné un stf déterministe, tout le monde finira par calculer le même état. l'exécution n'a pas besoin de retarder le consensus - elle peut s'exécuter de manière asynchrone. cela peut ouvrir le budget d'exécution des nœuds (leur donner plus de temps à consacrer à l'exécution) tout en réduisant les étapes requises (et donc le temps) pour parvenir à un consensus.

la commande détermine la vérité. l'exécution la révèle simplement. n'importe qui peut exécuter les données pour révéler la vérité une fois que sa commande est finalisée.

c'est probablement pourquoi Keone croit que finalement chaque blockchain utilisera une exécution asynchrone, et c'est un élément clé de La vision finale de Toly pour Solana:

L'exécution synchrone nécessite que tous les nœuds qui votent et créent des blocs soient surapprovisionnés pour le temps d'exécution du pire des cas dans n'importe quel bloc... les nœuds de consensus peuvent effectuer moins de travail avant de voter. Le travail peut être aggreGate.iod et regroupé, ce qui permet une exécution efficace sans aucun cache manquant. Il peut même être exécuté sur une machine différente de celle des nœuds de consensus ou des leaders. Les utilisateurs qui désirent une exécution synchrone peuvent allouer suffisamment de ressources matérielles pour exécuter chaque transition d'état en temps réel sans attendre le reste du réseau.

actuellement, les validateurs rejouent toutes les transactions aussi rapidement que possible sur chaque bloc et ne votent qu'une fois que la transition complète de l'état du bloc est calculée. L'objectif de cette proposition est de séparer la décision de voter pour une fourchette de la computation de la transition complète de l'état pour le bloc.

il est à noter que nous voulons également nous assurer que la vérité est facilement révélée aux utilisateurs, et cela signifie un support robuste pour les clients légers. Certains de ces designs qui retardent considérablement l'exécution rendraient cela difficile (par exemple, Solana envisage de ne le demander qu'une seule fois par époque) par rapport à d'autres qui fournissent une racine d'état avec un délai plus court (par exemple, comme dans le hypersdk).

approche modulaire

la dissociation de la séquence et de l'exécution peut sembler très familière car il s'agit également de l'approche « modulaire » ! combiner et associer différentes couches spécialisées dans des tâches différentes. la dissociation de la séquence et de l'exécution est le principe de conception clé des séquenceurs paresseux (par exemple, astria) :

• Séquençage - les nœuds séquenceurs ne parviennent à un consensus que sur l'ordre et la disponibilité des données de rollup (c'est-à-dire qu'ils séquencent mais n'exécutent pas).
• exécution - les nœuds de rollup exécutent leurs données respectives après que le séquenceur s'y soit engagé.

La différence principale ici réside dans le fait que les nœuds de chaîne intégrée s'exécutent après le séquençage, tandis que les séquenceurs paresseux le transmettent à un ensemble d'acteurs totalement différent et diversifié. Les séquenceurs paresseux ignorent complètement les machines d'état des rollups. Ils n'exécutent jamais ces transactions. Les rollups gèrent l'exécution asynchrone.

L'approche intégrée offre une interopérabilité plus fluide entre les utilisateurs de l'environnement d'exécution, mais réduit la flexibilité pour les développeurs d'applications (par exemple, les machines virtuelles personnalisées, les différents intervalles horaires).règles de tarification et d'ordonnancement d'applications spécifiques renforcées par consensus, etc.). L'approche modulaire offre plus de flexibilité et de souveraineté aux développeurs pour posséder des domaines personnalisés, mais il est plus difficile d'unifier l'expérience à travers eux.

dans les deux cas, un tuyau vraiment gros et rapide pour commander les données est le primitive dont nous avons besoin:

Cependant, vous devez noter que vous pouvez techniquement utiliser à peu près n'importe quelle chaîne comme un séquenceur paresseux. Après tout, c'est simplement un gros tuyau de données à la fin de la journée. Un rollup peut naïvement jeter ses données arbitraires sur sa couche de base de choix (que ce soit Ethereum, Bitcoin, Monad, etc.) pour l'utiliser implicitement comme leur séquenceur. Les nœuds rollup peuvent ensuite exécuter de manière asynchrone les données après coup.

La différence en pratique est que les chaînes que nous appelons réellement des « séquenceurs paresseux » sont spécialisées pour cette tâche, ce qui est beaucoup plus facile à dire qu'à faire (par exemple, prendre en charge les types de transactions nécessaires, exposer des interfaces faciles, mettre en œuvre une infrastructure de MEV, des temps de créneau rapides, une inclusion de transaction fiable, une bande passante élevée, etc.). En conséquence, les nœuds des chaînes intégrées finissent par exécuter la plupart des données qu'ils incluent, tandis que les séquenceurs paresseux laissent cela principalement aux rollups.

c'est pourquoi ce n'est pas aussi simple que "pourquoi n'utilisons-nous pas simplement solana (ou n'importe quelle autre chaîne quand ce n'a jamais été l'objectif de conception) en tant que séquenceur rollup ?" :

• manquant de l'infrastructure mev nécessaire conçue spécifiquement pour les rollups (par exemple, l'infrastructure pbs requise, les mécanismes d'interopérabilité entre chaînes, le compositeur pour abstraire les paiements de frais pour les utilisateurs de rollup dans le jeton de gaz de la couche de base, etc.)
• manque de types de transaction natifs conçus pour la publication de données de rollups.
• en concurrence avec l’environnement d’exécution natif (par exemple, il est conçu explicitement pour consommer la totalité ou la plus grande partie possible des données fournies, ce qui laisse moins de place et une inclusion fiable des transactions, etc.).
• compétition pour le soutien général des développeurs et la priorisation des mises à niveau. Vous êtes probablement plus enclin à vous tourner vers le protocole et l'équipe spécialisés dans l'aide au lancement de rollups et la conception de leur protocole spécifiquement pour vous, plutôt que vers celui où la plupart de la communauté pense que les rollups sont un peu stupides.

renforcement de SMR découplé

Maintenant, pouvons-nous aborder ces problèmes causés par la relaxation de ces contraintes? En bref, oui, les implémentations naïves introduisent en effet des problèmes tels que la possibilité d'autoriser des transactions invalides qui ne peuvent pas payer de frais (ce qui serait un vecteur d'attaque DOS s'il était implémenté naïvement), mais ils sont gérables de manière à ce qu'ils ne posent pas de problèmes sérieux.

nous ne nous attarderons pas trop sur les détails ici, mais vous pouvez vous référer àPatrick o’grady'stravail incroyable sur@patrickogrady/rys8mdl5p#renforcer-la-réplication-d'état-machine-découpée-dsmr">vryx pour renforcer smr découplé, toly’s fin de l'exécution asynchrone, et Implémentation par Monad des coûts de transportsur la manière de résoudre ces problèmes. encore une fois, les solutions à ces problèmes semblent étonnamment presque les mêmes à la fois du côté modulaire et du côté intégré.

le tldr est que vous pouvez réintroduire certaines contraintes beaucoup plus faibles (par rapport à une exécution synchrone avec une vérification complète) qui conservent la plupart des avantages de performance sans ouvrir un tas d'attaques.

acteurs en protocole vs acteurs hors protocole

Il est important de réaliser que les processus susmentionnés ne prennent naïvement en compte que les acteurs in-protocol. En réalité, les acteurs out-of-protocol jouent un rôle énorme dans ces chaînes d'approvisionnement de transaction. C'est ce que nous avons vu précédemment pour les validateurs (in-protocol) dans le SMR traditionnel :

source :@patrickogrady/rys8mdl5p# Faire valoir la réplication de machine d'état découplée (DSMR)">vryx: fortifier la réplication de machine d'état découplée

en pratique cependant,presque tous les validateurs Ethereum externalisent la construction de blocs via mev-boost Les trois principaux constructeurs (Beaver, Titan et Rsync) ont construit presque tous ces blocs. Notez que Beaver et rsync censurent les transactions OFAC alors que Titan ne le fait pas.

source: mevboost.pics

les relais se chargent de répliquer ces blocs au reste du réseau. ils sont également relativement lourds, avec les quatre principaux opérateurs (ultra sound, bloxroute, agnostic et flashbots) relayant la grande majorité des blocs. bloxroute et flashbots censurent les transactions de l'OFAC, tandis qu'agnostic et ultra sound ne le font pas.

source :mevboost.pics

Il n’est pas non plus surprenant que nous observions des tendances très similaires dans les optimisations de latence, comme nous l’avons vu précédemment. La tendance est à la relais optimistesqui ne vérifient plus les blocs avant la réplication car c'est simplement plus rapide. Les séquenceurs paresseux peuvent être considérés comme des réseaux de relais incitatifs.

Ces exemples mettent en évidence la façon dont MEV fausse les incitations au profit dans ces systèmes. Les validateurs externalisent la production de blocs parce que les constructeurs sophistiqués peuvent capturer plus de valeur que les blocs séquencés naïvement.

Même sous une exécution asynchrone, il y aura souvent des producteurs de blocs hors protocole exécutant des transactions pendant la construction pour maximiser la valeur. Par exemple, il est très probable que les séquenceurs paresseux auront des constructeurs de profit maximisant sous une forme de PBS. Le fait qu'un producteur de bloc externe est toujours incité à exécuter pleinement et à optimiser la valeur d'un bloc peut en fait être utile dans des paramètres où nous relâchons les contraintes dans l'exécution asynchrone. Cependant, d'autres validateurs n'auraient pas besoin de ré-exécuter avant de voter.

composabilité synchrone universelle

définitions

Maintenant, pouvons-nous obtenir la souveraineté et la flexibilité qu’offrent les chaînes modulaires, mais les réunir pour qu’elles se sentent comme une chaîne intégrée ? Pouvons-nous avoir le beurre et l’argent du beurre, ou finissons-nous simplement par construire Solana avec des étapes supplémentaires ?

quand on écoute les gens parler de la résolution de la fragmentation de Rollup, vous avez probablement entendu les grands mots clés autour deComposabilité synchrone universelle (usc). Cependant, cela a probablement été votre réaction :

ces termes sont tous utilisés avec des significations différentes, et certains termes sont souvent utilisés de manière incorrecte de manière interchangeable. nous devons établir des définitions concrètes. nous définissons les termes nécessaires ci-dessous dans le contexte de la composabilité inter-chaîne.

Notez que nous discuterons des "rollups" tout au long du reste de ce rapport, mais bon nombre de ces concepts s'appliquent également à d'autres types de "l2s" tels que les validiums.Je ne veux simplement pas me battre pour savoir ce qu'est à nouveau un l2..

dans les exemples suivants:

• r_un= rollup a
• r_b = cumul b
• t_A1 = transaction 1 sur r_un
• t_b1 = transaction 1 sur r_b
• b_a1 = bloc 1 sur r_une
• b_b1 = bloc 1 sur r_b
  

Notez que nous définissons "le temps" comme "la hauteur de la fente" ici. Le temps est purement relatif à l'observateur. La seule notion objective du temps que nous avons est un ordre relatif par un observateur partagé, c'est-à-dire un consensus partagé (où ce "consensus" peut être un seul acteur ou un mécanisme décentralisé).

si les deux rollups ont chacun un mécanisme de consensus qui fournit un ordre, nous pouvons affirmer:

• b_a1 est avant b_a2
• b_{B1 (en anglais seulement)} est avant b_b2

Cependant, le seul moyen de faire valoir :

• b_A1 est en même temps à b_{B1 (en anglais seulement)}, et donc
• t_a1 et l_b1se produire de manière synchrone, c'est si
• ils partagent un ordre fourni par un consensus partagé pour cette fente donnée.

Par conséquent, la composabilité synchrone inter-chaînes nécessite par définition un certain type de séquenceur partagé pour cette hauteur d’emplacement. Les chaînes qui n’en ont pas ne peuvent avoir qu’une composabilité asynchrone.

Cependant, notez que nous pouvons avoir une composabilité atomique asynchrone. Malheureusement, je remarque souvent que les gens utilisent les termes « atomique » et « synchrone » de manière interchangeable, mais ce sont en effet des termes différents.

Maintenant que cela est réglé, voyons si nous pouvons réintroduire la composabilité synchrone dans les chaînes modulaires. Si nous le pouvons, cela pourrait sembler diminuer la valeur des chaînes intégrées. Voici le résumé que nous allons explorer :

• La séquence partagée peut assurer elle-même l'inclusion atomique synchrone (ce qui est beaucoup plus faible que la composabilité).
• L’association d’un séquenceur partagé avec un mécanisme de sécurité cryptographique (par exemple, Agglayer) peut renforcer cette garantie d’inclusion dans la composabilité réelle.
• Les garanties de sécurité fournies par l'agglayer pour la sécurité inter-chaînes peuvent également être utilisées sans un séquenceur partagé (c'est-à-dire dans le cadre asynchrone).
• nous verrons comment nous pouvons également simuler les effets de la composabilité synchrone, bien que de manière moins efficace en capital, en utilisant la cryptéconomie (la garantie directe des transactions inter-chaînes).

inclusion atomique - séquençage partagé

Le séquençage partagé signifie que pour une hauteur de créneau donnée, une seule entité (le « séquenceur » ou le « proposant ») a les droits de monopole pour séquencer (c'est-à-dire proposer des blocs pour) plusieurs chaînes. Pour réitérer, ces séquenceurs partagés dont nous parlons généralement sont Séquenceurs paresseux. ils parviennent à un consensus sur l'ordre et la disponibilité des données de rollup, mais ils ne l'exécutent pas. ils sont complètement ignorants des machines d'état des rollups.

Comme je l'ai écrit précédemmentCela signifie que les séquenceurs partagés paresseux peuvent fournir un engagement crédible pour inclure des paquets inter-chaînes (c'est-à-dire un ensemble de transactions) :

• atomiquement - soit toutes les transactions seront incluses, soit aucune ne le sera, et
• synchroniquement - en même temps (hauteur de la fente)

Cela permet une extraction plus efficace du MEV en super constructeurs(c'est-à-dire, les constructeurs de chaîne croisée) lorsqu'ils effectuent des actions de chaîne croisée, car ils n'ont plus à évaluer le risque qu'une jambe du paquet de chaînes croisées puisse échouer. La synchronicité ici est capable de leur fournir implicitement l'atomicité.

démantèlement inter-chaînes

maintenant, comment faisons-nous exactement cela sans faire entièrement confiance au constructeur et / ou au proposant actif pour le séquenceur partagé? si nous envoyons simplement deux transactions signées de manière indépendante (t₁ et t₂) pour chaque rollup, le séquenceur partagé pourrait toujours décider d'inclure l'un ou l'autre.

par exemple, il n'existe actuellement aucune notion de format de bundle natif dans l'EVM, c'est pourquoi les chercheurs font entièrement confiance aux constructeurs/relais pour ne pas les dénouer. Toute personne qui voit un ensemble de transactions signées de manière indépendante avant qu'elles ne soient validées par le leader actuel peut les dénouer. En général, c'est bien, car les constructeurs et les relais sont incités à maintenir leur réputation et à protéger les ensembles de recherche, mais lorsque cette confiance est rompue (ou qu'ils sont trompés par des participants malhonnêtes pour révéler les transactions), Le désintégration peut être incroyablement rentable.

Nous avons besoin d'une garantie de sécurité beaucoup plus solide ici si nous voulons une véritable interopérabilité entre chaînes. Nous ne parlons pas seulement de prendre de l'argent à un chercheur. Si les contrats cross-chain defi étaient conçus en supposant que les bundles cross-chain seront respectés, mais que cette confiance est rompue, les résultats seraient catastrophiques pour ces protocoles (par exemple, dans un bundle de pont cross-chain de type burn-and-mint, vous pourriez omettre la destruction mais créer des fonds de l'autre côté).

Nous avons besoin de garanties de sécurité inébranlables pour mettre en œuvre l'interopérabilité entre chaînes. Cela signifie que nous devons définir un format de transaction qui garantit que plusieurs transactions dans un bundle cross-chain sont incluses ensemble. Si l'une est incluse sans l'autre, nous avons besoin d'une garantie de sécurité que celle qui est incluse est invalide.

Cela signifie que nous devons créer une nouvelle structure de transaction pour les faisceaux de chaînes croisées qui ne peuvent pas être dégroupé. la solution naive est de « créer simplement un nouveau type de transaction pour ces rollups », mais ce n'est pas si facile. cela demanderait des changements de vm pour ces rollups, perdant la compatibilité descendante. vous seriez également étroitement coupler les rollups en modifiant leurs machines étatiques de sorte que chaque transaction ne soit valide qu'avec l'autre incluse.

Cependant, il existe une manière plus propre de faire cela. Vous pouvez faire en sorte que chaque transaction de l’ensemble signe également le hachage de l’ensemble, puis ajouter le résumé de hachage à un champ de transaction libre (par exemple, calldata dans l’EVM). Le correctif cumulatif doit modifier son pipeline de dérivation pour les vérifier, mais la machine virtuelle peut rester inchangée. Une fois cela en place, les utilisateurs de cumul pourraient soumettre des offres groupées inter-chaînes dont ils sont certains qu’elles ne peuvent pas être dissociées. Tenter de le faire les invaliderait.

source: Ben fisch

garanties d'inclusion vs garanties de l'État

avec ce qui précède en place, nous avons maintenant établi comment un séquenceur partagé paresseux :

• peut fournir un engagement crédible d'inclusion synchrone atomique pour les paquets inter-chaînes (c'est-à-dire que toutes les transactions seront incluses, ou aucune ne le sera)
• ne peut pas fournir un engagement crédible autour de l'état résultant de l'inclusion de telles transactions (par exemple, il est possible que les deux transactions soient incluses, mais qu'une autre transaction se place devant elles et les fait revenir en arrière)

Malheureusement, l'inclusion atomique à elle seule est une garantie beaucoup plus faible. Cet engagement envers l'inclusion atomique est suffisant pour que le constructeur ait une grande confiance que le bloc de cross-rollup qu'il construit créera l'état résultant qu'il souhaite s'il est confirmé. Le constructeur sait nécessairement l'état résultant du bloc, car il l'a exécuté pour le construire.

nous avons toujours un problème cependant - comment tout le monde sait-il avec certitude quelle sera la situation?

considérez un exemple :

• nous avons deux rollups (ra et rb) partageant le même séquenceur paresseux
• Je veux utiliser un pont de combustion-et-frappe entre ra → rb qui brûle simultanément sur ra et frappe sur rb
• Le contrat de pontage de frappe sur rb a besoin d'une garantie de la transition d'état sur ra (brûler) pour frapper sur rb, mais le contrat ne peut pas savoir si le jeton a réellement été brûlé sur ra au moment de l'exécution car il n'a pas accès à l'état de ra.

si nous avons soumis un ensemble approprié, alors le séquenceur paresseux peut garantir que la transaction de destruction a été incluse dans le flux de transactions pour ra, mais vous ne savez pas, par exemple, si une autre transaction s'est placée devant elle et l'a invalidée (ce qui signifie que les jetons n'ont pas été réellement brûlés).

Le simple partage d'un séquenceur paresseux est insuffisant pour permettre aux chaînes d'accéder aux états mutuels pendant l'exécution du bundle. La composabilité synchrone nécessite la capacité de la machine à états de chaque chaîne à accéder à l'état de l'autre chaîne (par exemple, le contrat de pont lui-même sur rb doit connaître l'état de ra) au moment de l'exécution. Cette capacité est exactement ce qui permet une composabilité complète au sein d'une seule chaîne intégrée.

Le constructeur ne peut pas se contenter de dire aux contrats « Fais-moi confiance, mon frère, ça va marcher. » Nous voyons que l’inclusion atomique est un bon outil pour les chercheurs qui font confiance aux constructeurs pour exécuter correctement leurs bundles, mais c’est insuffisant pour faire abstraction de l’interopérabilité inter-chaînes.

Pour résoudre ce problème, nous devons ajouter un autre mécanisme en plus du séquençage partagé :

comme nous l'avons mentionné, le constructeur sait personnellement quel sera l'état résultant si le bundle est inclus atomiquement. Comment peuvent-ils fournir un engagement crédible pour convaincre tout le monde de l'état résultant si leurs transactions sont incluses ?

ils ont globalement deux options:

• cryptéconomique - le constructeur peut miser une grande quantité de capital pour garantir intégralement ses actions de chaîne croisée.Ceci est souvent inefficace et vraisemblablement une composabilité simulée, mais il s’agit d’un exemple utile pour démontrer la fonctionnalité.
• cryptographique - nous pouvons avoir un mécanisme qui fournit des garanties cryptographiques que les transactions produiront l’état souhaité.

sécurité cryptoéconomique - obligations des constructeurs

prenons un exemple pour voir comment la crypto-économie pourrait simuler les effets de la composabilité synchrone. l'exemple classique utilisé est celui d'un Flashloan inter-chaînes. Je veux prendre un prêt flash sur ra, l'utiliser pour une opération d'arbitrage sur rb et le rembourser sur ra, le tout dans le même créneau horaire. C'est possible si ces protocoles DeFi déploient ici une fonctionnalité personnalisée de cross-chain avec ce que nous appellerons des "contrats bancaires" des deux côtés :

Maintenant, pour ce problème de sécurité, le contrat sur Ra et RB a besoin de connaître les états de la chaîne de l’autre pour le faire en toute sécurité, mais nous n’avons rien fait pour y remédier. Eh bien, la « solution » crypto-économique ici est en fait plutôt la force brute - vous avez le super constructeur qui agit comme un fournisseur de liquidité et met en place la valeur totale du prêt flash. Si les transactions devaient échouer, le protocole de prêt conserverait de toute façon sa mise. Vous pouvez voir pourquoi ce n’est pas la « solution » la plus satisfaisante.

sécurité cryptographique - agglayer

Qu’est-ce que c’est ?

le AggLayer est un protocole décentralisé qui offre trois avantages majeurs:

1. sécurité pour une compossibilité inter-chaînes rapide - elle produit des preuves zk qui offrent à aggchains une sécurité cryptographique pour une interopérabilité inter-chaînes atomique à faible latence (c'est-à-dire plus rapide que les blocs Ethereum) lorsqu'elle fonctionne de manière asynchrone ou synchrone. La conception isole de manière unique les erreurs de chaîne afin de pouvoir prendre en charge n'importe quel environnement d'exécution et prouveur.
2. Fongibilité des actifs inter-chaînes - elle dispose d'un pont partagé pour assurer la fongibilité des actifs sur l'ensemble des aggchains (c'est-à-dire les chaînes qui l'utilisent) afin que les utilisateurs n'aient pas une multitude d'actifs enveloppés. Le contrat de pont se trouve sur Ethereum qui est la couche de règlement. (notez que différentes chaînes peuvent toujours avoir des hypothèses de sécurité différentes en raison de la mise en œuvre, ce qui est expliqué plus en détail ci-dessous.)
3. optimisation du gaz - il aggreGate.ios des preuves pour les aggchains afin d'amortir les coûts fixes à travers de nombreuses chaînes. Le contrat de dépôt partagé optimise également les coûts de gaz en permettant des transferts directs de L2 à L2 sans toucher le L1.

source: Brendan fermier, Blockchains agrégées

Pour clarifier deux idées fausses courantes sur ce que l’agglayer n’est pas :

• L'agglayer n'est pas seulement un service pour les preuves aggreGate.io- c'est confus parce que cela regroupe effectivement les preuves de Gate.io, et ils mettent "agrégation" dans le nom de la chose. cependant, le but d'agglayer est d'agréger des chaînes. La distinction importante pour les besoins de ce message est que l'agrégation des preuves seule ne suffit pas à garantir la sécurité dont nous avons besoin ici.
• Les agglayer et les séquenceurs partagés ne sont pas des conceptions opposées- bien qu'ils n'aient pas besoin d'être utilisés ensemble, ils sont en fait des compléments parfaits qui offrent des garanties différentes. L’agglayer est complètement agnostique à la façon dont les aggchains sont séquencées. Il ne gère aucun des messages entre les chaînes, de sorte qu’il s’appuie explicitement sur une infrastructure de coordination du marché libre (par exemple, des relais, des constructeurs, des séquenceurs isolés, des séquenceurs partagés, etc.) pour composer les chaînes.

maintenant, passons en revue comment cela fonctionne.

le pontage est nul

Faire le pont entre les rollups aujourd’hui, c’est nul. Supposons que vous vouliez faire le pont entre deux cumuls optimistes Ethereum ORU_unet oru_b:

• Via Native Bridge - vous paierez des frais de gaz Ethereum L1 élevés (c’est-à-dire un pont à partir d’ORU_un → ethereum + ethereum → oru_b), et le voyage aller-retour prendra plus d'une semaine (en raison de la fenêtre de preuve de défaillance).
• Cumul direct → cumul - l’ETH enveloppé que vous recevez sur ORU_bne serait pas réellement fongible avec l'eth native pour notre_un. la dépendance du chemin emprunté par le biais de différents ponts rompt la fongibilité. par exemple, si l'oru_unSi le pont a été vidé, alors l'eth enveloppé que vous avez transféré vers Orub ne serait plus couvert, tandis que l'eth natif sur Oru le serait._bwould be fine. la fragmentation de la liquidité est nulle, donc ce n'est pas quelque chose que les utilisateurs veulent. en pratique, les utilisateurs font directement le pont via les fournisseurs de liquidité. quelqu'un vous avancera l'eth sur oru_bet gardez vos fonds sur oru_uneIls peuvent retirer via le pont natif et attendre, mais ils factureront des frais élevés pour le risque et le coût élevé du capital qu'ils supportent.

Vous pouvez penser que les rollups zk résolvent cela d'emblée, mais ce n'est pas le cas. Les implémentations naïves nécessitent toujours que vous soumettiez des transactions l1, ce qui est à nouveau coûteux et généralement assez lent (par exemple, en raison des temps de finalité ethereum, des temps de génération de preuves, de la fréquence à laquelle les preuves sont publiées en pratique, etc.).

les utilisateurs ne veulent pas gérer cela. Ils veulent simplement avoir des fonds et utiliser des applications. Le pontage devrait être complètement abstrait - les actifs devraient être fongibles et se déplacer rapidement, à moindre coût et en toute sécurité.

C'est là que le partage d'un contrat de pont intervient. Un contrat de pont partagé ouvre la porte aux chaînes qui l'utilisent pour se relier directement les unes aux autres sans passer par le L1.

les jetons peuvent également être fongibles entre les aggchains en conséquence. en passant par eth depuis r_un → r_bou r_c → r_bbrûle et frappe le même jeton. ce n'est pas un actif emballé lock-and-mint. c'est de l'eth native. c'est possible car tous les actifs sont mis en garantie ensemble et réglés via le pont unifié. c'est un point de douleur majeur pour les l2s aujourd'hui qui doit être résolu.

Cependant, notez qu'un utilisateur détenant de l'eth sur r_unvs. r_bpourrait avoir un profil de risque différent si les différentes chaînes utilisent des vérificateurs différents (par exemple, peut-être que vous êtes passé d'une chaîne sûre à une chaîne avec un bug de circuit). les profils de risque ne changent pas parmi les chaînes utilisant des normes communes ici (ce qui est pratiquement la norme aujourd'hui). des normes plus uniformes et une vérification formelle ne feront qu'améliorer cela avec le temps même si des domaines hétérogènes sont ajoutés.

Preuves pessimistes

Les aggchains soumettent leurs mises à jour d’état et leurs preuves aux nœuds jalonnés d’agglayer qui les organisent, génèrent des engagements pour tous les messages et créent des preuves récursives. l’agglayer génère alors une seule preuve aggreGate.iod zk (qu’ils appellent un "preuve pessimiste”) pour régler sur ethereum pour tous les aggchains. parce que l'agrégation de la preuve amortit les coûts à travers un nombre arbitraire de chaînes, il est pratique d'un point de vue coût de les poster sur ethereum pour un règlement rapide dès que possible. le programme de preuve pessimiste est écrit en code rust régulier, en utilisantLe zkvm sp1 succinct de Succinctpour faciliter le développement et garantir des performances élevées.

ces preuves pessimistes renforcent:

• comptabilité inter-chaînes - prouve que toutes les invariants du pont sont respectés (c'est-à-dire, aucune chaîne ne peut retirer plus de jetons qu'elle n'en a déposé).
• La validité des chaînes agg - prouve que chaque chaîne a mis à jour son état de manière véridique, sans équivoque de chaîne ou blocs invalides.
• Sécurité inter-chaînes - prouve que les mises à jour d'état résultant de transactions inter-chaînes à une latence inférieure à celle d'Ethereum sont cohérentes et peuvent être réglées en toute sécurité sur Ethereum L1. Cela inclut l'exécution atomique réussie de faisceaux inter-chaînes à la fois de manière synchrone et asynchrone.

Avec cela, l’agglayer s’assure que le règlement se produit sur Ethereum si et seulement si les conditions ci-dessus sont remplies. S’ils ne sont pas remplis, les chaînes respectives ne peuvent pas s’établir. En tant que tel, l’agglayer peut permettre à un coordinateur (par exemple, un séquenceur ou un constructeur partagé) de transmettre des messages entre les chaînes à faible latence sans qu’ils ne fassent confiance à ce coordinateur pour la sécurité.

interopérabilité inter-chaîne rapide et sûr

Les aggchains peuvent utiliser les garanties fournies ici dans les paramètres d'interopérabilité asynchrone et synchrone pour exprimer des contraintes sur la validité des blocs par rapport à d'autres rollups.

Cela permettrait aux utilisateurs de soumettre des ensembles inter-chaînes qui doivent être exécutés avec succès de manière atomique des deux côtés. Pas seulement une inclusion atomique. Vous appliquez en fait que l'état résultant d'entre eux doit être réussi. C'est parfait pour compléter exactement ce que nous avons décrit comme manquant dans les garanties d'inclusion atomique d'un séquenceur partagé seul.

source: Brendan agriculteur, Chaînes de blocs agrégées

prenons notre exemple précédent:

• Nous avons deux cumuls (r_unet r_bpartageant le même séquenceur paresseux et l'agglayer
• Je soumets un ensemble de chaînes croisées pour brûler simultanément de l'eth sur r_unet mint eth sur r_b
• Un Super Builder construit un bloc pour les deux chaînes en faisant cela, ce que le séquenceur partagé s’engage à faire
• le contrat de pontage de frappe sur r_bpeut créer de manière optimiste l'eth en fonction de l'état de r_une (dans ce cas, exécution réussie de la gravure eth)
• Ces blocs et preuves sont soumis à l’agglayer, qui prouve que les deux chaînes ont agi de manière valide (à la fois indépendamment et l’une par rapport à l’autre) et que le pont partagé a été utilisé en toute sécurité

Pour que cela soit réglé avec succès sur Ethereum, les deux jambes du bundle doivent avoir été exécutées correctement. Si l'une ou l'autre des parties échoue, alors les blocs seraient invalides et ne pourraient pas être réglés. Cela signifie que si, par exemple, le séquenceur partagé a signé un bloc où l'ETH n'a pas été brûlé sur r_unemais a frappé de l'eth sur r_b, alors ce bloc serait réorganisé. cela garantit la sécurité de toutes les chaînes et empêche les actions malhonnêtes entre chaînes d'être réglées.

Il y a deux points à garder à l'esprit concernant ces reorgs :

• ils seraient incroyablement courts car ils seraient détectés et prouvés immédiatement.
• ils ne peuvent se produire que si le coordinateur (par exemple, le séquenceur et/ou le constructeur) de la chaîne à laquelle vous êtes connecté est activement malveillant.

Ces réorganisations devraient être extrêmement rares et minimales en raison des points ci-dessus, mais à cause de cela, AGGchains aura un contrôle total sur les chaînes avec lesquelles ils veulent composer atomiquement et sous quelles hypothèses de confiance. Par exemple, r_unpeut accepter un état de chaîne de r_bcomposer avec en fonction du consensus de leur séquenceur, mais pour r_cil peut également demander une preuve soumise, et pour r_d Peut-être veulent-ils qu’ils sécurisent crypto-économiquement toutes les dépendances atomiques inter-chaînes. Chaque chaîne peut faire ses propres compromis personnalisables ici pour une faible latence et une vivacité. Agglayer fournit simplement la base la plus flexible et la plus minimaliste possible pour que les chaînes aient des interactions inter-chaînes sûres.

vous pouvez également voir ici pourquoi un tel design est en pratique incompatible avec un design à l'épreuve des fautes. en théorie, ils pourraient le faire, mais dans ce cas, il serait possible de faire l'expérience de réorganisations incroyablement profondes. prouver et régler rapidement toutes les chaînes limite le pire des cas à être très court, ce qui agit également comme un moyen de dissuasion naturel contre toute tentative malveillante.

Isolation des défauts pour les étalons hétérogènes

Plus important encore, l'agglayer permet de manière unique des chaînes complètement hétérogènes. Vous pouvez avoir une aggchain avec n'importe quelle vm personnalisée, prover, couches da, etc. tout en partageant en toute sécurité un pont avec tout le monde.

Mais comment est-ce possible ? La raison pour laquelle cela n’est normalement pas acceptable est qu’un seul participant défectueux (par exemple, avec un bogue de circuit) pourrait normalement simplement tromper un pont et le vider de tous les fonds. Eh bien, c’est là qu’intervient la preuve comptable interchain mentionnée ci-dessus. Ces preuves garantissent que les invariants du pont sont tous respectés, de sorte que même dans le cas d’un prouveur malsain, seuls les fonds déposés dans la chaîne affectée pourraient être drainés. Le défaut est complètement isolé.

Neutralité crédible

ce type d'infrastructure bénéficie grandement de la neutralité crédible, c'est pourquoi le Le code entièrement open-source ifor agglayer est un territoire neutre. Dans le même esprit, l’agglayer utilisera l’ETH comme seul jeton de gaz pour payer les frais d’agrégation de preuves.

Ce n’est certainement pas parfait. Surtout au début, il ne sera pas tout à fait neutre de manière crédible. Il est probable qu’il y aura une mise à niveau des contrats sur la voie de l’immuabilité et de la consécration en tant que bien public.

Cela étant dit, cela n'a pas besoin d'être parfaitement neutre de manière crédible, rien ne l'est. (nous verrons cela à nouveau ci-dessous avec les rollups basés.) En pratique, cela offre probablement la vision compétitive technique la plus convaincante, et adopte une attitude délibérément minimaliste envers l'enfermement et l'extraction de loyers. L'objectif est de permettre aux aggchains de maintenir autant de souveraineté que possible, tout en étant capable d'abstraire une interopérabilité entre chaînes de confiance minimisée.

Les aggchains n'ont pas besoin de VM spécifique, d'environnement d'exécution, de séquenceur, de couche DA, de jeton de mise en jeu, de jeton de gaz ou de gouvernance commune. Les chaînes peuvent partir quand elles le souhaitent. Il n'y a pas d'exigences de partage des revenus. Vous n'avez pas besoin de déployer en tant que L3 sur la chaîne de quelqu'un d'autre.

Les raisons de lancer L3s sur le dessus des L2s généraux ont principalement été, à mon avis, des solutions temporaires alors que des architectures similaires à l'AggLayer sont en cours de construction. Pour être clair, c'est une raison tout à fait valable de les lancer aujourd'hui. L'AggLayer v1 est simplement un contrat de pont partagé simple. Le v2 avec l'agrégation de preuves et la capacité d'obtenir une interopérabilité sûre à faible latence n'est même pas en direct. Vous ne pouvez pas vous attendre à ce que les gens attendent des années lorsqu'ils ont l'urgence de livrer quelque chose aujourd'hui qui leur donnera la distribution la plus rapide.

Preuve en temps réel

bien que plusieurs années soient nécessaires avant que cela ne soit pratique dans des paramètres à faible latence, nous devrions noter que la preuve en temps réel pourrait également potentiellement être utilisée aux côtés du séquençage partagé pour la sécurité entre chaînes. C'est aussi tout simplement cool, donc nous en parlerons brièvement. Plus précisément, la preuve en temps réel fait référence à des temps de preuve plus courts que les temps de fente de la chaîne en question. Reprenons l'exemple du pont de création et de destruction entre chaînes :

• nous avons deux rollups (r_une et r_b) partageant le même séquenceur paresseux
• Je veux utiliser un pont de brûlure et de création entre ra → rb qui brûle simultanément sur ra et crée sur rb
• le super constructeur crée un bloc inter-chaînes qui comprend un ensemble de ces transactions inter-chaînes. À l'intérieur des blocs, le constructeur inclut une preuve de la transition d'état qui est incluse sur l'autre rollup.

Nous avions déjà la garantie du séquenceur partagé d’inclusion d’un faisceau atomique synchrone, et maintenant chaque contrat peut vérifier une preuve de l’état de l’autre chaîne pour savoir qu’il s’exécutera avec succès.

Pour la preuve en temps réel, nous voulons idéalement que le temps de preuve ne représente qu’une petite fraction du temps total de l’intervalle de temps, maximisant ainsi la « fenêtre de synchronisation ». Il s’agit de la partie du temps de créneau dans laquelle vous êtes en mesure de traiter des transactions qui fonctionneraient de manière synchrone entre les chaînes, car vous devez prévoir suffisamment de temps dans l’emplacement pour créer la preuve et la placer dans le bloc.

source: Justin drake, preuve en temps réel

Notez que nous finirions implicitement par fusionner ou colocaliser les constructeurs et les prouveurs ici. Il y a une incitation claire pour les constructeurs à optimiser les vitesses d’essai afin qu’ils puissent construire jusqu’à la dernière seconde et tenir autant que possible dans leur bloc.

source: Justin drake, preuve en temps réel

si cette incitation élevée à la démonstration en temps réel se concrétise dans les années à venir, nous devons également noter que cela n'est évidemment pas du tout favorable à la décentralisation de la démonstration. Les prouveurs devraient être relativement centralisés car ils fusionnent ou se colloquent avec les constructeurs.

résumé

La composabilité synchrone universelle est vraiment cool, mais il n’est pas très clair à quel point elle est précieuse. Internet est entièrement asynchrone et vous ne le saurez jamais. C’est parce que c’est rapide et que la complexité est abstraite. C’est tout ce que les utilisateurs veulent.

Je m'attends à ce que la majeure partie de la valeur de l'utilisation de quelque chose comme agglayer ne se situe pas seulement dans le cadre synchrone. Au contraire, c'est le fait qu'il peut agir comme une forme d'abstraction de chaîne cross-rollup. Rendre plusieurs chaînes plus semblables à une seule avec les aspects orientés utilisateur qui importent (par exemple, des actifs natifs plus fongibles, une fonctionnalité d'application nativement cross-chaîne, une interopérabilité rapide, etc.).

La composabilité synchrone est clairement financièrement précieuse (par exemple, permettant des liquidations, une arbitrage plus efficace, un refinancement plus efficace à l'aide de prêts flash). Cependant, de la même manière que l'Internet est asynchrone et fonctionne très bien, le tradfi est bien sûr asynchrone. Il est raisonnable de vouloir être encore meilleur que le tradfi, mais nous devons être clairs que la synchronicité universelle n'est pas une exigence pour une bonne exécution. Il y a aussi un coût réel pour la construction et la fourniture d'une infrastructure synchrone.

Je pense personnellement que le meilleur argument en faveur de la nécessité de l'USC est que, en pratique, cela conduit à une meilleure UX et DevEx. Il est impossible de nier l'énorme avantage que cela a été pour des écosystèmes tels que Solana. Cependant, cela devrait être plus un problème actuel qu'un problème permanent.

le simple fait est que c'est aussi un peu difficile pour quiconque de raisonner à ce stade. ce n'est pas un choix binaire entre 'tout dans la crypto est synchrone' ou 'tout est asynchrone'. je pense que nous devrons fondamentalement résoudre et tendre vers cette dernière, mais les deux peuvent coexister de manière ad hoc.

rollups basés sur Ethereum

D’accord, nous devrions maintenant avoir une bonne idée de l’espace de solution pour résoudre la fragmentation dans les cumuls. La question suivante est de savoir comment impliquer la couche de base dans tout cela. Quel est le rôle d’Ethereum ici ?

nous utiliserons les abréviations suivantes tout au long :

• bl - couche de base
• br - Rollup basé sur BR
• preconfs - préconfirmations

sauf indication contraire, le bl en question dont nous allons discuter est ethereum, et les br sont des br ethereum. Cependant, les concepts de base s'appliquent largement car vous pouvez lancer des br n'importe où.

rollups basés sur la vanille

les implémentations initiales de rollup il y a plusieurs années étaient en faitprévu d'être brs, mais étaient abandonné au profit des séquenceurs centralisés pour une latence réduite et une efficacité accrue. Ce que nous appelons aujourd’hui le séquençage basé, Vitalik l’a appelé «anarchie totale"à l'époque. c'était relativement impraticable et inefficace avant l'évolution de l'infrastructure pbs d'ethereum (avec des constructeurs sophistiqués).

Les BRS ont ensuite été ramenés sous les feux de la rampe en mars 2023,où ils ont été définis comme suit:

"un rollup est dit être basé, ou séquencé en l1, lorsque son séquençage est entraîné par le l1 de base. plus concrètement, un rollup basé est un rollup où le prochain proposant l1 peut, en collaboration avec les chercheurs et les constructeurs l1, inclure de manière permissionless le prochain bloc rollup comme partie du prochain bloc l1."

ils devraient offrir les avantages suivants:

"le séquençage de ces rollups - le séquençage basé - est maximale simple et hérite de la vivacité l1 et de la décentralisation. De plus, les rollups basés sont particulièrement alignés économiquement avec leur base l1."

Plus précisément, vous bénéficiez de la sécurité en temps réel d'Ethereum:

"vous héritez de la résistance à la censure et de la vivacité d'Ethereum. Donc, non seulement vous avez les garanties de règlement d'Ethereum, mais vous avez aussi la résistance à la censure, la résistance à la censure en temps réel, pas celle retardée que vous connaissez avec l'issue de secours, mais celle en temps réel."

Être un rollup basé est la conception logique une fois que vous avez choisi une couche de base:

« Ethereum vise à maximiser ces deux propriétés, la sécurité et la neutralité crédible, c'est presque la définition d'un rollup... un rollup est celui qui a déjà adopté l'hypothèse de sécurité d'Ethereum. Vous n'ajoutez pas une nouvelle hypothèse de sécurité. Vous ne tombez pas dans le maillon le plus faible. Vous réutilisez simplement l'hypothèse de sécurité existante. Et deuxièmement, vous avez déjà accepté Ethereum comme une plateforme neutre de manière crédible, sinon vous auriez choisi une autre chaîne. Et maintenant, vous pouvez vous demander pourquoi tout le monde n'utilise pas simplement la séquence de couche un ? »

Dans leur forme la plus simple, les brs peuvent certainement atteindre les objectifs de conception ci-dessus. Si le rollup n'implémente pas son propre séquenceur, alors implicitement, le proposeur actuel d'Ethereum décide de ce qui sera inclus toutes les 12 secondes (temps de slot d'Ethereum).

Cependant, le séquençage basé sur des compromis comporte toujours des inconvénients, ce qui est exactementPourquoi les rollups implémentent-ils généralement leur propre séquenceur ?:

• Les utilisateurs de Rollup ne veulent pas attendre plus de 12 secondes pour les blocs Ethereum.
• Préconfs sécurisées - Parfois, les blocs Ethereum subissent une réorganisation, ce qui oblige les utilisateurs à attendre encore plus longtemps pour être en sécurité, ce que les utilisateurs n'aiment pas. Les séquenceurs peuvent donner des préconfs qui ne dépendent pas des blocs Ethereum non finalisés et n'ont donc pas besoin de se réorganiser même si Ethereum lui-même subit une courte réorganisation.
• Publication en lot efficace - les séquenceurs peuvent regrouper de nombreuses données, les compresser et les publier périodiquement sur le BL de manière optimisée en termes de coûts (par exemple, en garantissant une utilisation complète des blobs).

rollups basés + preconfs

Alors, pouvons-nous avoir notre gâteau et le manger aussi? entrez préconférences basées.

Nous expliquerons ici relativement brièvement l'intuition derrière les préconfs basées sur brs, afin de pouvoir les comparer aux rollups traditionnels. Plus tard, nous reviendrons pour analyser plus en détail les préconfs de manière plus générale (c'est-à-dire à la fois les préconfs de br et de bl sur les transactions Ethereum L1).

L'idée centrale est que les préconfs br doivent provenir des bl proposants. Pour fournir des préconfs, ces proposants doivent fournir une certaine garantie (par exemple, le restaking) et accepter des conditions de réduction supplémentaires (c'est-à-dire que les préconfs qu'ils fournissent seront effectivement intégrées à la chaîne comme promis). Tout proposant qui le souhaite peut agir en tant que séquenceur br et fournir des préconfs.

Nous devons noter que les proposants (c'est-à-dire les validateurs) sont en fait censés déléguer ce rôle de fourniture de préconfs à des entités plus spécialisées appelées « Gate.ioways ». La fourniture de préconfs nécessitera une entité relativement sophistiquée, et Ethereum souhaite que les proposants restent peu sophistiqués.

Cependant, il est prévu que les relais existants vont également prendre en charge ce rôle. Le Gate.ioway ne ferait qu'interfacer entre l'utilisateur et le relais, donc ajouter une autre entité indépendante ne ferait qu'ajouter de la complexité et de la latence (bien que la latence pourrait également être résolue avec la co-localisation). Le relais est déjà approuvé par les constructeurs et les proposants, donc nous ajouterions ici une autre exigence de confiance de la part des utilisateurs.

notez que bien que les validateurs servent actuellement de proposants de blocs Ethereum, il est envisagé une mise à niveau par laquelle le protocole lui-même vendrait directement les droits de proposition viaenchères d'exécution. cela permettrait aux entités sophistiquées d'acheter directement les droits de proposition, évitant ainsi aux validateurs (les proposants actuels) de les déléguer à Gate.io comme prévu ici.

Dans tous les cas, le point important est que toute préconfiguration plus rapide que le consensus Ethereum (12s) nécessite une tierce partie de confiance (TTP). Que votre TTP soit un validateur restaké, enjeu ou non, ...enchère d'exécution winner, deleGate.iod Gate.ioway, ou quoi que ce soit d’autre - il ne peut fondamentalement pas fournir de sécurité Ethereum en temps réel. Que Coinbase vous donne une « préconf basée » en tant que proposant Ethereum ou une « préconf traditionnelle » en tant que séquenceur de cumul, vous faites confiance à Coinbase. De même, ils peuvent mettre en place un lien d’un certain ETH, mais dans les deux cas, cela est indépendant de la sécurité du consensus d’Ethereum.

nous devrions alors remarquer que tout design préconf basé détériore nécessairement les objectifs déclarés de brs avec lesquels nous avons commencé (simplicité et sécurité bl).Les préconfs basées sont de plus en plus complexes, et ils ne peuvent pas fournir les garanties de sécurité en temps réel d'Ethereum.

cependant, vous devriez conserver la capacité de forcer une transaction directement via une transaction bl si ces préconférences sont hors ligne ou commencent à censurer. ces garanties d'ethereum devraient devenir encore plus fortes lorsque listes d'inclusionsont mis en œuvre.

Pour les BRS - TTPS, fournissent des pré-confs rapides, et la BL assure la sécurité éventuelle.

rollups sans base + fallback basé

maintenant, considérons un rollup traditionnel (c'est-à-dire non basé). son propre séquenceur (qu'il soit centralisé ou décentralisé) donne des préconfs rapides. plus tard, leurs utilisateurs bénéficient d'une sécurité complète d'Ethereum avec un décalage. cela inclut la vivacité (croissance du registre + résistance à la censure) qui provient d'un certain type de inclusion forcéeouBL fallbackmécanisme.

comme je l'ai noté dansLes rollups héritent-ils de la sécurité ?:

Les cumuls ont la possibilité d’exposer des règles de confirmation avec des propriétés de sécurité équivalentes à celles de leur chaîne hôte. Ils peuvent recevoir ces propriétés au mieux à la vitesse du consensus de leur chaîne hôte (et en pratique, c’est souvent un peu plus lent en fonction de la fréquence à laquelle le cumul publie sur la chaîne hôte).

Les rollups peuvent également rendre disponible une règle de confirmation plus souple "happy path" (c'est-à-dire des séquenceurs) pour une meilleure expérience utilisateur, mais ils conservent la solution de secours en cas de défaillance. Si votre séquenceur s'arrête, vous pouvez continuer à avancer.

Notez que le temps pour la sécurité finaleest la variable clé à optimiser ici:

L'hypothèse selon laquelle les utilisateurs de Rollup peuvent revenir à une vivacité équivalente à celle de la chaîne hôte suppose que vous pouvez obtenir une inclusion forcée à exactement la vitesse des blocs de la chaîne hôte (par exemple, si le séquenceur Rollup vous censure, que vous pouvez forcer l'inclusion de la transaction dans le prochain bloc Ethereum).

en pratique, il y a généralement un court délai. si vous autorisez une inclusion forcée immédiate, vous pourriez exposer censure rentable mevparmi d'autres complexités. cependant, il y a conceptions qui peuvent fournir des garanties de vivacité quasi temps réelde la chaîne hôte (par exemple, peut-être à la vitesse de quelques blocs de la chaîne hôte plutôt qu'un bloc).

dans cet esprit, Sovereign labs a un designqui fait ce qui suit:

• séquençage autorisé - les rollups utilisent un séquenceur autorisé dont les transactions sont traitées immédiatement dès leur inclusion dans le bloc car ils ont un verrou d'écriture sur l'état du rollup, ils peuvent fournir des préconfs fiables plus rapidement que le temps de bloc du bl.
• Séquençage basé - les utilisateurs peuvent également soumettre des transactions directement à leur bl, mais elles sont traitées avec un délai de n blocs (où n est suffisamment petit). Cela réduit considérablement le « temps de sécurité éventuelle », et en fait, ils appellent même la conception « séquençage basé avec des confirmations douces » à cause de cela! (Notez que cette définition de brs entrerait en conflit avec la définition que nous avons fournie précédemment, c'est-à-dire que le proposant bl doit avoir le droit de séquencer le br ou être délégué par eux.)

pour les non-BRS - ttps fournissent des preconfs rapides, et le bl assure la sécurité éventuelle.

pourquoi tho?

comme nous pouvons le voir, les deux chemins décrits ci-dessus produisent alors le même résultat efficace:

Ces brs sans préconfs ne fournissent plus la simplicité ou la sécurité en temps réel d'Ethereum. Alors, quel est l'intérêt de tout cela maintenant ? Pourquoi ne resserrons-nous pas simplement les fallbacks sur les rollups « traditionnels » ? Qu'est-ce qu'un « based rollup » à ce stade ?

cela revient en réalité à monPreuve de gouvernancepublication de l'année dernière où j'ai discuté des cas d'utilisation fondamentaux pour le restaking spécifique à Ethereum :

1) technique (engagements du proposeur) - il n'y a pas d'autre choix - si vous voulez un engagement crédible sur l'ordre d'un bloc Ethereum, il doit venir des validateurs Ethereum.MEV-Boost++est un exemple d'une application hypothétique qui pourrait entrer dans cette catégorie.

2) social - je considère l'alignement d'Ethereum comme le cas d'utilisation principal pour la plupart des applications de restaking aujourd'hui, pas le regroupement de la sécurité économique ou de la décentralisation. Cela revient à dire " regardez, nous sommes un projet Ethereum!” C'est en grande partie la même raison pour laquelle les chaînes continuent de s'appeler des couches 2 d'Ethereum.indépendamment de l'architecture.

Nous pouvons moderniser cela dans le contexte de la question de savoir quelle est la valeur d’un « BR + Preconfs » par rapport à un « rollup traditionnel + repli rapide » ?

1) technique (engagements du proposant) - Les BRS Ethereum avec des préconfirmations ont un avantage technique fondamental - ils peuvent obtenir un engagement crédible du proposant Ethereum actuel concernant l'inclusion et l'ordre des contenus d'un bloc Ethereum. Cela est potentiellement précieux pour les mêmes raisons pour lesquelles nous voulons potentiellement qu'un tas de Rollups partage un séquenceur. Si le proposant bl est également le proposant br (c'est-à-dire le séquenceur), alors il peut fournir les mêmes garanties d'inclusion atomique avec le bl que celles que vous pouvez obtenir entre n'importe quels Rollups partageant le séquenceur. Ils ont le monopole sur les deux chaînes. Maintenant, quelle est la valeur de cela? Nous y reviendrons dans un instant.

2) social (alignement / neutralité crédible) - que vous l'aimiez ou non,Alignement d'Ethereumest un argument de vente pour être un br. Je vais être honnête, je ne sais pas grand-chose sur taiko, à part qu'ils sont les gars du br, et je ne saurais probablement pas qui ils sont s'ils n'étaient pas les gars du br. Tout le monde veut une bonne co-commercialisation. Il y a une valeur à être les premiers ici, mais je soupçonne que ce n'est pas une proposition de valeur durable et ne se transpose pas à de nombreux futurs br potentiels. De même, nous avons tous entendu parler des premiers avss, mais pouvez-vous nommer tous les actuels ? Je ne peux pas.

à un niveau supérieur, vous n'obtiendrez pas tous les rollups ethereum pour opter pour le (hypothétique) « optimisme séquenceur partagé » ou le « séquenceur partagé arbitrum ». Cependant, vous avez plus de chances de les convaincre d'opter pour le « séquenceur partagé ethereum ». Pas de nouveau jeton, pas de nouvelle marque, pas de nouveau consensus. Si vous pensez qu'il est précieux que tous les L2 ethereum s'unissent sur la séquence, alors cette neutralité crédible est potentiellement le point de Schelling le plus fort pour atteindre cet objectif.

Cette neutralité crédible est probablement le plus précieux pour les développeurs de rollups qui cherchent à attirer des utilisateurs d'écosystèmes croisés (par exemple, des applications avec une infrastructure de base comme ens). Ils peuvent hésiter à utiliser le séquenceur Optimism s'ils alienent les utilisateurs d'Arbitrum, ou vice versa.

nous couvrirons chacun de ces éléments plus en détail ci-dessous.

neutralité crédible

Approfondissant ce point social, les brs sont souvent considérés comme l'option maximale “alignée sur Ethereum”. Mettant de côté le jugement de la valeur de ceci, le point important est que cela suppose un degré élevé de neutralité crédible pour tout design de br.

un br crédiblement neutre est facile à concevoir dans le cas vanille, mais comme nous l'avons noté, personne ne veut vraiment de cela. Les préconfs nécessitent alors nécessairement que le proposant opte pour des conditions de sanction supplémentaires. Ces conditions de sanction supplémentaires exigent que le proposant utilise un système supplémentaire (par exemple, un restaking potentiel de la couche propre).Symbiotique, ou une autre norme) pour prendre l’engagement. Un rollup peut être heureux d’opter pour le « séquenceur Ethereum » crédiblement neutre dans l’abstrait, mais la neutralité crédible est probablement perdue si vous utilisez des projets financés par des fonds privés, peut-être même avec leurs propres jetons.

Il y a plusieurs questions ouvertes concernant la garantie ici :

taille de la garantie

Les premières conceptions ont supposé que les proposants devraient personnellement fournir une quantité incroyablement élevée de garanties d'environ 1000 eth. Le problème est que fondamentalement, un proposant peut toujours revenir sur sa promesse de déléguer à Gate.io et construire un bloc par lui-même, en équivoquant sur les preconfs. Cela peut être incroyablement précieux, et 1000 eth est confortablement au-dessus des paiements les plus élevés jamais observés qui ont été effectués via mev-boost depuis sa création. L'inconvénient est que cela crée bien entendu une barrière à l'entrée élevée pour les petits proposants, tandis que les plus gros (par exemple, Coinbase) pourraient raisonnablement fournir 1000 eth tout en gagnant des récompenses sur tout leur poids de mise.>13% du total de l'eth misé) parce que les déclarants peuvent mettre en place une seule caution pour tous leurs validateurs. il y a d'autres idées pour permettre aux proposants avec des cautions beaucoup plus petites, bien sûr, cela comporte des compromis. L'espace de conception ici est tout simplement incertain.

il convient de noter que Ventes aux enchères d’exécutionCela apaiserait cette préoccupation, car nous pouvons supposer que tous les proposants seraient alors des acteurs sophistiqués facilement capables de cela.

source: Barnabé Monnot, de mev-boost à epbs à aps

Cependant, même les grands opérateurs hésitent à mettre en place de grandes quantités, en raison de problèmes potentiels de vivacité entraînant des coupures (une défaillance de la vivacité de la part d’un opérateur, donnant nos préconfs puis descendant avant qu’ils ne les incluent dans un bloc, est tout de même une défaillance de sécurité pour les utilisateurs, et doit être sévèrement pénalisée).

type de garantie

L’ETH vanille est probablement la seule garantie neutre crédible dans cette situation. Cependant, il y aura naturellement un désir d’utiliser des actifs plus efficaces sur le plan du capital (p. ex., Steth). Il existe quelques idées pour qu’un souscripteur s’occupe de cette conversion, comme décrit dans mteam ici.

plateforme

Ce ne serait pas très « neutre de manière crédible » si les « préconfigurations basées sur Ethereum » ressemblaient davantage aux « préconfs basées sur la couche d’eigenlayer » ou aux « préconfs symbiotiques ». Il y a des équipes qui envisagent d’aller dans cette direction, mais ce n’est pas une exigence stricte d’utiliser une telle plateforme. Il est possible de créer une norme générale et neutre pour que tout le monde puisse l’utiliser, et un tel système semblerait mieux placé pour une adoption générale en tant qu’option la plus basée.

L'adoption de normes de bien public sera nécessaire pour que les conceptions préconf basées soient vraisemblablement "crédiblement neutres".

Préconfirmations

inclusion vs. state preconfs

nous allons maintenant couvrir les preconfs en détail. Bien que nous ayons discuté plus tôt d'un type spécifique de preconf (les preconfs br sur l'état), nous devons noter qu'il s'agit d'un concept entièrement général. Vous pouvez offrir des preconfs sur les transactions bl en plus des brs, et vous pouvez offrir différentes forces de preconfs:

• inclusion preconfs - un engagement moins fort qu'une transaction sera éventuellement incluse onchain.
• preconfs d'état - l'engagement le plus fort selon lequel une transaction sera finalement incluse onchain et une garantie de l'état résultant.

ce dernier (state preconfs) est bien sûr ce que les utilisateurs veulent voir dans leurs portefeuilles :

j'ai échangé 1 eth contre 4000 usdc et j'ai payé 0,0001 eth de frais

pas d'inclusion preconfs:

ma transaction qui tente de faire un échange de 1 eth contre 4000 $ usdc et de payer jusqu'à 0,0001 eth de frais finira éventuellement sur la chaîne, mais peut-être qu'elle réussira, peut-être qu'elle échouera, nous verrons

Cependant, il convient de noter que les prépréconfigurations d’inclusion sont effectivement interchangeables avec les préconfs d’état dans le cas d’actions de l’utilisateur effectuées sur un état non litigieux (par exemple, des transferts simples où seul l’utilisateur lui-même pourrait invalider la transaction). Dans ce cas, une promesse selon laquelle, par exemple, « le transfert d’USDC d’Alice à Bob sera inclus dans les prochains blocs » est suffisante pour qu’un portefeuille affiche simplement à l’utilisateur « Vous avez envoyé vos USDC à Bob ».

Sans surprise, les engagements plus forts (préconfs d'État) sont plus difficiles à obtenir. Fondamentalement, ils nécessitent une engagement crédiblede l'entité qui détient actuellement un monopole sur la proposition de blocs (c'est-à-dire un verrou en écriture sur l'état de la chaîne). dans le cas des préconfs ethereum l1, il s'agit toujours du proposeur actuel d'ethereum l1. dans le cas des préconfs br, il s'agit probablement du prochain proposeur d'ethereum l1 dans le lookahead de br (ce qui en fait le proposeur actuel pour br), comme nous le verrons ci-dessous. les termes proposeur et séquenceur sont généralement interchangeables, le premier étant plus souvent utilisé dans le contexte l1 et le second dans le contexte l2.

tarification préconférences

une autre grande distinction que nous devons faire est quel type d'état touchent ces préconfigurations :

• État non litigieux - personne d’autre n’a besoin d’accéder à cet état (par exemple, Alice veut transférer des USDC à Bob)
• État litigieux - D’autres veulent avoir accès à cet état (par exemple, les swaps dans un pool AMM ETH/USDC)

Les préconfs sont des contraintes sur les blocs qui peuvent éventuellement être produits. Tout le reste étant égal, la limitation de l'espace de recherche pour les constructeurs ne peut qu'entraîner une réduction de la valeur potentielle qu'ils peuvent capturer en le commandant. Cela signifie que moins de valeur serait renvoyée au proposant. Pour le rendre incitatif, Gate.ioway doit facturer des frais de préconf ≥ la MEV potentielle perdue en limitant le résultat.

Cela est assez simple lorsque la perte de MEV est ~0 (par exemple, lors d'un transfert USDC). Dans ce scénario, facturer des frais fixes nominaux pourrait être raisonnable. Mais nous avons un gros problème - comment fixer le prix des préconfs sur les états litigieux ? Fixer les prix des préconfs à l'avance par rapport à la dernière minute semble moins rentable. Tout le reste étant égal, il est plus rentable pour un constructeur d'attendre jusqu'à la dernière seconde possible pour capturer et fixer précisément le prix du MEV.

Supposons cependant qu'il y ait une demande suffisante des utilisateurs pour des préconfs rapides sur un état controversé (en tenant compte à la fois des chercheurs sophistiqués et des utilisateurs normaux), de sorte qu'il y aura parfois un prix de compensation qui sera bénéfique pour tout le monde. Maintenant, comment fixez-vous exactement le prix d'un préconf pour une transaction sur un état controversé que vous pourriez inclure à n'importe quel moment au cours des 12 prochaines secondes, renonçant potentiellement à des opportunités plus rentables qui ne seraient plus possibles?

Les préconfs sur l'état contesté diffusé dans tout le bloc entreraient en conflit avec la façon dont les constructeurs créent des blocs. Le prix des préconfs de manière précise nécessite d'estimer en temps réel l'impact de la MEV de l'inclure maintenant plutôt que de le retarder, ce qui signifie exécuter et simuler les résultats possibles. Cela signifie que la Gate.ioway doit maintenant être un chercheur/bâtisseur hautement sophistiqué.

nous avons déjà supposé que le Gate.ioway et le relais fusionneraient. S’ils ont besoin de fixer continuellement le prix des préconfs, ils fusionneront également avec le constructeur. Nous avons également accepté que l’USC accélère la fusion du constructeur et du prouveur. Il semble aussi que enchères d'exécution vendra les droits des soumissionnaires directement à des acteurs sophistiqués (probablement des constructeurs) capables de les tarifer.

Cela met l'ensemble de la chaîne d'approvisionnement des transactions Ethereum L1 et BR dans une seule boîte qui a un verrou d'écriture monopolistique sur l'état de toutes les chaînes pour cette période.

Les politiques de commande du service de préconf ne sont pas claires (p. ex., exécutent-ils toujours des FCF ou les commandent-ils d’une autre manière). il est également potentiellement possible pour le Gate.ioway d’organiser une enchère sur toutes les préconfs (par exemple, permettant aux chercheurs d’enchérir sur les préconfs), bien qu’il ne soit pas clair à quoi ressemblerait une telle conception, et cela signifierait nécessairement une latence plus élevée.

Problème d’échange équitable

il y a un problème d’échange équitable avec les préconfs où le Gate.ioway n’est pas directement incité à publier la preconf.

considérez l'exemple suivant :

• la passerelle actuelle Gate.ioway a un monopole de 12s
• un utilisateur soumet une demande de transaction preconf dès le début de l'intervalle (t = 0)
• La Gate.ioway attend jusqu'à t = 11,5 pour libérer toutes les préconfs qu'ils ont faites pendant leur slot, en laissant une marge de 500 ms pour les obtenir toutes avec leur bloc. À ce moment-là, ils peuvent décider quelles préconfs inclure s'ils sont rentables et lesquelles exclure.

dans ce scénario, l'utilisateur peut finir par payer pour le preconf même s'ils ne le reçoivent effectivement qu'à la fin de la plage horaire. Le Gate.ioway pourrait également simplement le supprimer à la fin de la plage horaire s'ils décident que ce n'était pas rentable de l'inclure. Cette rétention par le Gate.ioway n'est pas une faute objectivement imputablemais cela pourrait être attribuable de manière intersubjective).

En fait, il y a en réalité une incitation pour les portails à retenir les préconfs jusqu'à la fin.Là où il y a une asymétrie de l'information, il y a de la MEV. garder les transactions privées permettrait à un constructeur d'avoir une vision plus à jour de l'état du monde, ce qui leur permettrait de mieux évaluer les risques et de saisir le MEV. il n'y a pas de consensus sur l'ensemble des préconférences données aux utilisateurs, donc la Gate.ioway ne peut être tenue pour responsable ici.

Il faudrait qu'il y ait des normes en placeet les attentes pour que le préconfirmeur publie immédiatement toutes les préconfs. cela donnerait aux utilisateurs ce qu'ils veulent immédiatement et permettrait aux autres de voir qu'une Gate.io offre les services attendus. s'ils ne le font pas à l'avenir, alors les utilisateurs ne leur feraient pas confiance et ne les paieraient pas pour les préconfs. la réputation de la Gate.io a de la valeur. cela dit, cela peut aussi êtreextrêmement précieuxêtre malhonnête ici et aller à l'encontre des préconfs.

l1 couche de base préconfs

Une fois les points de préconf généraux mis de côté, nous allons maintenant discuter des nuances des préconfs L1. Bien que nous ne les ayons pas mentionnés plus tôt, il y a des projets qui les construisent, et leur interaction avec les préconfs BR sera importante.

par exemple, Boulonest un tel protocole qui veut permettre aux proposants Ethereum de faire des engagements crédibles quant à leur contenu de blocs. Les proposants enregistrés peuvent exécuter le bolt sidecar pour recevoir des demandes préconf des utilisateurs, les confirmer, puis envoyer ces informations aux relais et aux constructeurs qui peuvent renvoyer des blocs qui respectent ces contraintes (c’est-à-dire qu’ils renvoient un bloc qui inclut les transactions pour lesquelles le proposant a donné des préconf).

Il est important de noter ici que Boulon v1décrit ici ne prend en charge que des préconfs d'inclusion de transaction simple pour un état non contentieux où seul l'utilisateur peut invalider la préconf. Comme nous l'avons discuté précédemment, ce sont les engagements les plus simples et les plus faibles à fournir.

Toutes ces équipes préconf ont des ambitions plus importantes (par exemple, des préconfs d'État, des enchères de blocs partiels, des enchères de créneaux ou de créneaux partiels), alors qu'est-ce qui les retient ?

• La responsabilité - les violations de l'engagement devraient être prouvables onchain pour un slashing objectif. Il est relativement facile de prouver l'inclusion de la transaction, mais il n'est pas aussi clair comment faire respecter d'autres engagements tels que les enchères de slot.
• exigences en capital - fournir des engagements arbitraires signifie que la valeur de la rupture d'un engagement pourrait être arbitrairement élevée. Gate.ioways finira probablement par devoir miser des sommes énormes (par exemple, des milliers d'eth) pour les fournir. ceux-ci pourraient très bien finir par être regroupés, au bénéfice des plus grandes entités (par exemple, les grandes firmes de trading ou coinbase) et en excluant les entités plus petites.
• tarification - il y a beaucoup de questions ouvertes sur la manière de fixer le prix d'une chose comme des préconfs d'état diffusé en continu, même si nous décidons que c'est faisable et précieux.
• la participation au réseau - c'est peut-être le point le plus important et fondamental. comme nous l'avons mentionné, seul le proposant actuel qui a un verrou en écriture sur l'état peut fournir des engagements comme des préconfs d'état. en théorie, 100% des proposants pourraient opter pour ce système et l'imiter. en pratique, cela n'arrivera pas.

mev-boost, un produit plus simple avec des années d'expérience qui est incroyablement rentable à exploiter, a >92% participationpour le contexte (probablement même un peu plus élevé car cela ne tient pas compte deenchère minimale. un nouveau service de preconf obtiendrait certainement un taux de participation nettement inférieur. mais même s'il pouvait atteindre environ 90 %, cela ne semble pas être un produit utile pour les utilisateurs normaux. vous ne pouvez pas dire aux utilisateurs 10 % du temps "oh désolé, pas de preconf disponible pour le moment, vérifiez à nouveau dans un instant."

au mieux, cela ressemble à des préconfs d'état qui ne seraient qu'un outil facultatif pour les chercheurs et les traders sophistiqués qui souhaitent obtenir un engagement plus tôt dans le bloc lorsque cette plage horaire a un proposant qui a opté. cela peut être précieux, mais il n'y a pas de fragmentation ou de déverrouillages ux ici.

preconfs basées sur l2 rollup

Les préconfs BR doivent provenir des proposants BL (c'est pourquoi ils sont «basés»). Cela nécessite qu'ils fournissent une garantie et optent pour des conditions de sanction supplémentaires (c'est-à-dire que les préconfs qu'ils fournissent arriveront effectivement sur la chaîne, comme promis). Tout proposant prêt à le faire peut agir en tant que séquenceur BR et fournir des préconfs.

Il est important de noter que ces préconfs BR sont des préconfs d’État et pas seulement des PECONF d’inclusion. c’est possible parce que les brs optent pour une conception où ils donnent un monopole de séquenceur rotatif aux proposants bl qui s’inscrivent pour être Gate.ioways.

Aujourd’hui, un validateur Ethereum sert de proposant pour chaque emplacement, et le calendrier du proposant est toujours connu pour l’époque actuelle et la suivante. Une époque est composée de 32 emplacements, nous connaissons donc toujours les 32 à 64 prochains proposants à un moment donné. La conception fonctionne en accordant au séquenceur actif suivant (c’est-à-dire au séquenceur suivant dans l’anticipation) des pouvoirs de monopole pour séquencer les transactions pour le BRS choisi dans ce système de préconf. Gate.ioways doit signer pour faire avancer l’état des chaînes br.

notez que chaque proposant (même ceux qui n'ont pas choisi d'être un Gate.ioway) a le droit mais pas l'obligation d'inclure des transactions qui ont été pré-confirmées par les séquenceurs (c'est-à-dire ceux qui ont choisi d'être un Gate.ioway). Ils peuvent agir en tant qu'incluant tant qu'ils ont la liste complète des transactions qui ont été pré-confirmées jusqu'à ce moment-là (le séquenceur peut créer un bl blob qui contient les transactions br et les faire circuler).

source: Séquençage d’Ethereum, Justin Drake

le flux de transaction fonctionne comme suit:

1. L'utilisateur soumet sa transaction au prochain séquenceur dans le lookahead (le proposant de la fente n+1 dans l'image ci-dessous)
2. le séquenceur fournit immédiatement une préconfirmation de l'état résultant (par exemple, l'utilisateur a échangé 1 eth contre 4000 $ usdc sur le br et a payé 0.0001 eth de frais)
3. à ce stade, tout inclus peut inclure la transaction séquencée (le proposant de la fente n le fait dans l'image ci-dessous)

source :Séquençage Ethereum, justin drake

si les autres inclus ne incluent pas les préconfigurations, alors le séquenceur qui les a donnés peut simplement les inclure sur la chaîne lors de son tour en tant que proposant de bloc. par exemple, dans l'image ci-dessus, supposons que l'inclus n du créneau décide de ne pas inclure les préconfigurations que le séquenceur du créneau n+1 a distribuées. alors le séquenceur du créneau n+1 serait responsable d'inclure toutes les préconfigurations qu'il a distribuées pendant les créneaux n et n+1 lorsqu'il soumet son bloc bl pour n+1. cela permet au séquenceur de donner en toute confiance des préconfigurations pour la période complète entre eux et le dernier séquenceur.

Pour simplifier les explications ci-dessus, nous avons simplement supposé que le proposant L1 remplirait ce rôle de préconféré. Comme décrit précédemment, cependant, il est peu probable que ce soit le cas. Il faudra une entité sophistiquée pour fixer le prix des préconfs, exécuter des nœuds complets pour tous les BR, disposer d’une protection DOS et d’une bande passante suffisante pour toutes les transactions BR, etc. Ethereum veut garder les validateurs très peu sophistiqués, de sorte que les proposants externaliseront probablement les préconfs à une autre entité de la même manière qu’ils externalisent la production complète de blocs L1 via MEV-Boost aujourd’hui.

Les proposants peuvent déléGuer.io à Gate.ioways via des mécanismes surchaîne ou hors chaîne, et cela peut être fait jusqu'au dernier moment avant leur créneau. Comme indiqué précédemment, ce rôle est susceptible d'être repris par les relais. Il est également possible qu'ils aient besoin de fusionner avec les constructeurs également.

source: Séquençage basé, justin drake

comme décrit précédemment, seule une entité peut être déléguée pour être la passerelle Gate.io à un moment donné. cela est nécessaire pour fournir des préconfs d'état fiables. les utilisateurs d'interfaces utilisateur (par exemple, des portefeuilles comme metamask) chercheraient qui est la prochaine passerelle Gate.io, et ils enverraient les transactions de l'utilisateur là-bas.

rollups Ethereum - à quel point seront-ils basés ?

Maintenant que suffisamment d’informations sont en place, les cumuls Ethereum devraient-ils être basés ? Il y a vraiment deux questions intégrées ici :

1. Devrait-il y avoir plusieurs rollups Ethereum partageant un séquenceur ?
2. si oui, devrait-il s'agir d'un séquenceur basé (c'est-à-dire impliquant les propositaires de bl ethereum et l'infrastructure mev environnante)?

Tout d'abord, il est important de noter que vous pouvez partager un séquenceur avec d'autres chaînes de manière ad hoc. Par exemple, le proposeur d'Ethereum peut séquencer un bloc pour vous s'ils font l'offre la plus élevée, puis un autre consensus bft pourrait séquencer votre prochain bloc s'ils font l'offre la plus élevée. Cependant, cela nécessite toujours qu'une chaîne adhère pleinement à cette vente aux enchères partagée uniforme qui peut fonctionner de manière synchrone avec ces autres chaînes, il existe donc toujours des compromis en matière de contrôle et de flexibilité (par exemple, des temps de bloc partagés). C'est juste que l'entité séquenceur gagnante peut changer.

Quoi qu'il en soit, supposons simplement que la condition 1 soit remplie. Je pense que nous disposons de preuves convaincantes à ce stade qu'il existe une demande suffisante pour utiliser un séquenceur partagé décentralisé. Même s'ils se soucient moins de l'aspect «partagé», je pense qu'il y a une valeur incroyable à pouvoir acheter un séquenceur décentralisé en tant que service prêt à l'emploi (en fait, je pense que c'est la plus grande valeur ici).

Maintenant, ce séquenceur partagé doit-il être basé sur Ethereum ?

engagements techniques (engagements du demandeur)

Je ne vois pas d'argument technique solide pour utiliser un séquenceur basé sur Ethereum. Toute interopérabilité entre BRS et l'Ethereum L1 serait extrêmement limitée en raison de l'incapacité à exécuter de manière fiable contre la L1 (c'est-à-dire sans avoir systématiquement un verrou en écriture sur l'état L1), de la longueur des blocs (12s) et du fait que les transactions BRS souhaitant interagir avec la L1 devraient ensuite se réorganiser avec elle. Il n'y a pas de repas gratuit ici. Cela ne débloque aucun produit utile orienté utilisateur par rapport à tout autre séquenceur partagé externe.

la principale valeur que je vois est que l'ajout de l'ethereum l1 à cette plus grande enchère combinatoire pourrait résulter en une création de valeur aggreGate.io plus élevée etpermettre à l1 de capturer plus de valeur. poussant cette logique à l'extrême, nous devrions probablement mettre tout dans le monde dans la même vente aux enchères. cette vente aux enchères universelle devrait également mettre en séquence les billets de concert de Taylor Swift. Je n'y suis pas encore.

Ceci vise simplement à souligner qu'il existe une réelle complexité technique et sociale à créer et à intégrer tout le monde dans cette enchère partagée, ce qui a un coût réel, qui, à mon avis, l'emporte probablement sur toute valeur supplémentaire théorique créée ici. Vous pouvez facilement concevoir un bien meilleur design technique pour exécuter cela à partir des premiers principes si nous n'essayons pas de l'ajouter au-dessus de l'éthereum l1 (par exemple, avoir un mécanisme de consensus simple et rapide construit à cet effet). Sans oublier le fait qu'une telle enchère combinatoire entraînerait une explosion exponentielle de la complexité.

En pratique, il existe un risque significatif pour moi que cela puisse effectivement être gravement contre-productif pour Ethereum, car cette architecture préconférencée semble potentiellement accélérationniste en ce qui concerne l'infrastructure MEV lorsque la chaîne d'approvisionnement d'Ethereum est déjà quelque peu fragile. Cela risque de compromettre la décentralisation et la résistance à la censure du réseau - les choses mêmes qui le rendent précieux dès le départ.

social (neutralité crédible)

Je vois effectivement un argument social valable pour un séquenceur basé sur Ethereum.

comme noté précédemment, il ne fait aucun doute que "l'alignement" est un argument de vente pour les premiers BRS. C'est bien, mais je ne pense pas que cela dure. C'est bien d'être le premier BRS, mais ce n'est pas cool d'être le huitième. Il doit y avoir une autre valeur ajoutée.

Je pense que la neutralité crédible d’un séquenceur basé sur Ethereum est potentiellement cette valeur. C’est probablement l’argument le plus fort en faveur d’une telle conception. Il y a beaucoup de chaînes qui veulent obtenir un séquenceur décentralisé sur étagère. Si nous pouvons éventuellement concevoir suffisamment d’infrastructure en plus de cette chose pour améliorer l’expérience utilisateur inter-chaînes, alors c’est encore mieux. Parmi les projets qui veulent une telle conception, j’imagine que beaucoup d’entre eux hésitent à « choisir leur camp » avec un protocole tiers. Comme indiqué précédemment, imaginez que vous êtes une chaîne d’applications avec une infrastructure générale de base comme ENS, et que vous souhaitez un cumul. Vous ne voulez pas choisir le séquenceur partagé (hypothétique) Arbitrum et désactiver la foule optimiste, ou vice versa.

La seule solution possible au problème de coordination sociale ici est d'avoir un séquenceur partagé crédiblement neutre, pour lequel Ethereum est clairement le candidat le plus fort. Notez que cela place encore plus l'accent sur les points que j'ai soulignés précédemment concernant la neutralité crédible - si c'est la principale valeur ajoutée d'un tel service, cela doit être un objectif de conception incroyablement important dans sa création. Cela ne fonctionnera pas s'il a l'apparence d'être le projet personnel d'un protocole tiers avec ses propres motifs de profit. Il doit réellement être le séquenceur partagé Ethereum.

Il convient de noter qu'il existe également des critiques raisonnables selon lesquelles le terme "neutre" ici est un code pour "Ethereum". Autrement dit, sa motivation principale est de bénéficier à Ethereum et à son infrastructure environnante d'origine. Et bien sûr, un tel système bénéficierait à ces parties. Cela signifierait une capture de valeur accrue pour l'ETH en tant qu'actif, et une rentabilité accrue pour les constructeurs, les relais et les chercheurs d'Ethereum.

Cumuls rapides

couches de base rapides

nous devrions maintenant comprendre que vous pouvez avoir des brs sur une bl lente comme ethereum, vous pouvez ajouter des préconfs de confiance pour une meilleure expérience utilisateur, et vous pouvez même garantir la sécurité lors des déplacements entre les chaînes via des garanties cryptographiques ou cryptographiques.

comme noté cependant, et si nous concevions simplement cette chose à partir de zéro. pas de gestion de la dette technologique et des décisions d'une chaîne existante. quelle est la façon évidente de construire la chose...

Plus tôt, nous avons discuté de la seule raison technique d'être un br avec des préconfs pour un bl donné (par exemple, ethereum) afin que son proposant puisse fournir des engagements crédibles à des moments concernant l'inclusion atomique synchrone avec le bl.

Cependant, nous n'avons pas sérieusement discuté de la capacité à être un BR sans préconfs. Nous avons essentiellement jeté cela par la fenêtre car Ethereum est lent et les utilisateurs sont impatients.

Alors pourquoi n'utilisons-nous pas un bl rapide pour les brs ?

cela résout pratiquement tous les cas limites et les préoccupations complexes que nous avions auparavant. Nous ne voulons pas de cas limites étranges où les chemins Gate.io ont des échecs de vivacité (qui ont le même résultat que les échecs de sécurité ici), nous ne voulons pas qu'ils se retirent des préconfs promis (c'est-à-dire des échecs de sécurité), et nous ne voulons pas de réorganisations Ethereum. C'est exactement pourquoi le consensus existe.

les couches de données sont mortes, vive les couches de séquençage!

la plupart des conversations concernant les séquenceurs paresseux les envisagent comme un séquenceur rollup qui déverse ensuite ses données sur une autre couche da. par exemple, les deux premiers rollups d'astria ( FormeetFlamme) utilisera celestia comme leur couche da. Le consensus d'astria séquencera ces rollups, puis il relaiera leurs données à celestia.

Cette combinaison est particulièrement agréable car elles se complètent évidemment - Astria fournit toute l'infrastructure de séquençage et Celestia fournit une vérification à minimisation de confiance viaéchantillonnage de disponibilité des données (das).

Cependant, Astria pourrait également être utilisée pour séquencer un rollup natif à Ethereum, Bitcoin, Solana, ou tout ce que vous voulez. Par exemple, elle pourrait même être configurée pour être utilisée comme pré-confer pour Ethereum "BRS avec pré-confer" (par exemple, au lieu d'un Gate.io centralisé, comme un séquenceur paresseux est essentiellement juste un relais incitatif et décentralisé).

Pour être clair cependant, chaque chaîne est une couche de données. Les nœuds complets peuvent toujours vérifier les données. C'est une partie des conditions de validité de n'importe quelle chaîne que les données soient disponibles, donc le consensus signe toujours que les données sont disponibles. Les nœuds légers vérifiant leur approbation font une hypothèse de majorité honnête. La seule différence est si la chaîne offre une autre option aux clients légers pour échantillonner directement les données plutôt que de demander au consensus.

cependant, comme je l'ai noté dans Les rollups héritent-ils de la sécurité?, des chaînes rapides comme astria pourraient techniquement ajouter un chemin lent pour das (pour améliorer la vérifiabilité), et des chaînes lentes comme celestia pourraient ajouter un chemin rapide pour le séquençage (avec une hypothèse de confiance majoritaire et sans das), appelé «blocs rapides carrés lents.”

La migration vers l'intégration verticale de couches spécialisées telles que le séquençage ou le DAS réduirait encore la distinction entre les blockchains modulaires et intégrées. Cela s'applique également à l'intégration verticale de lacouche de règlementvia ajoutantLes comptes de vérification ZK sur la couche de base de Celestia.

Cependant, il y a une valeur significative à garder ces services séparés plutôt que de les regrouper. C'est l'approche modulaire qui permet aux Rollups de choisir les fonctionnalités qu'ils veulent hors étagère (par exemple, je veux acheter une séquence décentralisée avec des blocs rapides, mais je ne veux pas payer pour les DAS, ou vice versa). Les chercheurs ont montré qu'ils voulaient des DAS, mais les utilisateurs ont jusqu'à présent montré qu'ils voulaient simplement des blocs rapides.

services de regroupement comme dans leblocs rapides carrés lents"serait très opinionné et intégré. cela ajouterait nécessairement de la complexité et des coûts. l'effet de la longueur de la fente sur jeux de timing(et donc potentiellement la décentralisation) qui sont maintenant omniprésents sur Ethereum est également à prendre en considération.

couche de base rapide vs. lente + préconf

mais vous pouvez également utiliser Astria comme BL pour les rollups. Les séquenceurs partagés peuvent être considérés comme des BLS optimisés pour les BRS de leur propre système.

Lorsque votre bl est rapide, votre br n'a pas besoin de préconfirmations car il obtient simplement des confirmations rapides dès le départ ! Ensuite, votre rollup bénéficie en réalité de la sécurité en temps réel de votre bl, contrairement aux brs + préconfirmations qui perdent nécessairement cela.

Les brs sans preconfs sont en fait la façon la plus logique de construire un rollup. C'est pourquoi tous les rollups d'aujourd'hui ont commencé là-bas :

Il est clair qu'un bl avec des blocs rapides corrige la plupart de nos problèmes dans les "rouleaux basés + preconfs." Les séquenceurs partagés sont naturellement construits davantage à partir d'une approche des premiers principes de "Hey, les développeurs d'applications veulent simplement lancer une chaîne rapide, fiable et décentralisée - comment puis-je leur donner cela?" Essayer d'ajouter des preconfs après coup à une couche de base plus lente comme Ethereum entraîne les complexités que nous avons décrites ci-dessus.

nous construisons tous la même chose

la modularité est inévitable

Ainsi, nous avons vu comment nous pouvions aggréger les chaînes modulaires de Gate.io ensemble, en fournissant une composition synchrone universelle (USC). Il y a bien sûr des compromis, mais ils réintroduisent un degré de cohésion significatif tout en préservant beaucoup plus de flexibilité que l'utilisation d'une seule machine d'état. Il y a également un argument très convaincant pour moi que la composition asynchrone est tout ce dont nous avons besoin pour la grande majorité des cas d'utilisation. Nous avons besoin de faible latence, de performances et d'une bonne expérience utilisateur. Internet est asynchrone et cela fonctionne très bien en abstrayant tout cela. La composition est une grande valeur ajoutée de la cryptographie, mais la composition ≠ synchronie.

Mis à part les avantages de la flexibilité et de la souveraineté, la plupart des gens conviendraient que nous aurons éventuellement besoin de nombreuses chaînes pour l'échelle de toute façon. Cela signifie que nous finirons par avoir de nombreux systèmes que nous devons unifier, donc la direction modulaire est inévitable ici.

ethereum + preconfs → solana?

maintenant, comparons les fins de partie ici. en particulier, nous comparerons la fin de partie de Solana à la fin de partie d'Ethereum s'il emprunte cette voie de maximisation de l'unité et de l'expérience utilisateur avec des rollups basés sur la confiance + des préconfigurations.

Dans cette vision, nous avons un tas de ces brs utilisant le séquenceur basé sur Ethereum. Les Gate.ioways diffusent en continu des préconfs promis par les proposants (c'est-à-dire sans poids de consensus) aux utilisateurs à faible latence, puis les proposants Ethereum les valident dans un bloc complet de temps en temps. Cela peut sembler familier car c'est à peu près ce que nous avons décrit pour Solana plus tôt avec Shred streaming !

Alors, est-ce juste une version plus compliquée de Solana ? La grande différence ici réside dans les temps de slot :

essayer d'ajouter cela à une chaîne lente présente clairement des problèmes au premier coup d'œil.

• Le consensus d'Ethereum est beaucoup trop lent pour les utilisateurs, donc la seule façon d'obtenir une expérience utilisateur rapide et crédiblement neutre est avec des préconfs promises par le proposant sur une base volontaire. Son principal goulot d'étranglement aujourd'hui est l'agrégation des signatures en raison de la taille énorme de son ensemble de validateurs.MaxEBet une agrégation de signature améliorée pourrait aider ici).
• Cela entraîne des monopoles de proposants beaucoup plus longs, offrant des incitations plus élevées et une plus grande liberté pour capturer plus de mev en agissant de manière malhonnête (par exemple, en retenant des préconfs).
• si Gate.ioways commence à retarder ou retenir les préconfs, alors le pire scénario pour les utilisateurs revient à dépendre des délais de slot ethereum. même si les producteurs de blocs solana arrêtaient la construction continue de blocs et la diffusion au sein de leurs monopoles allouéscomme il est probablement rationnel pour eux de le faire dans une certaine mesure pour la même raison exacte) , alors dans le pire des cas, il faut compter sur un consensus rapidement tournant. Le monopole à quatre emplacements est nécessaire aujourd'hui pour la fiabilité du réseau.
• En pratique, il est probable qu'il y ait très peu de Gate.ioways, du moins au début, ce qui entraînera un ensemble d'opérateurs plus centralisé par rapport à des chaînes comme solana.
• Exigences de garantie potentiellement incroyablement élevées pour les proposants (en notant que l'espace de conception est encore en cours de développement).
• préoccupations concernant les problèmes de vivacité qui sont incroyablement coûteux ici (car les problèmes de vivacité de l'opérateur entraînant des préconférences abandonnées constituent des défaillances de sécurité pour les utilisateurs, et doivent donc être lourdement sujettes à des sanctions).

tout cela est résolu avec un consensus rapide. tous ces systèmes sont littéralement la raison pour laquelle nous créons des systèmes bft en premier lieu. alors pourquoi Ethereum ne devrait-il pas simplement accélérer son consensus ? y a-t-il des compromis moins évidents avec des temps de blocage de la couche de base à latence extrêmement faible ?

Heureusement, je n'ai rien de mieux à faire que d'écrire un essai sur la question de savoir si des temps de blocs plus courts sont bons. La grande préoccupation concernant les temps de slot plus courts concerne la centralisation des validateurs et des opérateurs. Plus précisément, il y a des inquiétudes concernant l'interaction des temps de slot courts avec jeux de timing:

nous voyons déjà des jeux de timing progresser sur Ethereum. Les proposeurs proposent des blocs plus tard dans leurs créneaux, gagnant plus d'argent au détriment des autres. Les relais offrent égalementjeux de timing en tant que service"où ils retardent de même les blocs plus tard dans la plage :

source: Les données toujours

Les jeux de synchronisation ont été un sujet de discussion majeur sur le quelque peu infâme Podcast Justin vs. Toly Banklessdepuis quelques semaines :

par exemple, disons que vous êtes 100 ms plus rapide que tout le monde

si vous avez des créneaux de 1s, vous pouvez gagner 10% de plus que tout le monde

si vous avez des emplacements de 10s, vous pouvez gagner 1% de plus que tout le monde

— jon charbonneau (@jon_charb) 4 juin 2024

Justin a surtout soutenu que les jeux de timing poseront problème et que les récompenses progressives seront toujours pertinentes. Toly a surtout soutenu que les jeux de timing ne poseront pas problème et que les récompenses progressives obtenues grâce à une extraction MEV supplémentaire ne sont pas suffisantes pour s'en préoccuper.

Personnellement, je trouve difficile d'ignorer l'importance du timing des jeux ici :

• nous les voyons déjà en pratique sur Ethereum aujourd'hui.L'argument de Solanac'est que cela se produit uniquement parce que le MEV est devenu socialement normalisé sur Ethereum plus tôt, mais cela n'est pas convaincant lorsqu'il y avaitforte protestation publique contre les jeux de timing dès le début qui s'est depuis transformé en acceptationde cette nouvelle réalité à concevoir.
• Les récompenses MEV sont importantes - nous en parlons déjàdes milliards de dollars de paiements MEV ici, pas des sous sous sous le coussin du canapé. Même gagner « juste quelques pour cent de plus » sur cela est une énorme somme d’argent.
• Même si vous ne croyez pas que les stakers sont suffisamment sensibles au rendement sur la marge, les opérateurs réels dirigent des entrepriseset cela va directement à leur résultat net.
• Il est plus facile pour Solana de compter sur des grands acteurs altruistes(par exemple, la fondation et les gros investisseurs) plus tôt dans son cycle de vie, maisCe n'est pas durable car tout réseau se décentralise davantage..

Je pense clairement qu'il y a une énorme valeur dans la direction que prennent à la fois Solana et Ethereum. Sinon, nous verrons tout se dérouler en pratique. Stratégiquement, je pense aussi qu'il est logique pour Ethereum de s'appuyer sur ce qui le rend différent ici. Maximiser la décentralisation comme moyen d'atteindre la résistance à la censure dans des circonstances adverses. Ethereum a fait beaucoup de sacrifices pour maintenir un protocole incroyablement décentralisé parce que c'est une nécessité pour le long terme. Il possède une diversité de clients inégalée, une distribution de la propriété du réseau, des parties prenantes de l'écosystème, une décentralisation des opérateurs, et plus encore. Si (et probablement quand) Solana fait face à une pression sérieuse de la censure à l'avenir, il deviendra de plus en plus évident pourquoi Ethereum a pris les décisions qu'il a prises.

preconf.wtf vient de se passer à zuberlin la semaine dernière, et peut-être sans surprise tout le monde parlait de preconfs et de rollups basés. et c'était vraiment cool. mais personnellement, j'ai trouvéDiscours de Vitaliksurlistes d'inclusion d'un bit par attesteet la discussion de Barnabé surSurchargez plutôt le proposant d'exécution (de mev-boost à epbs à aps)être le plus important pour l'avenir d'Ethereum.

source: Barnabé monnot, De mev-boost à epbs à aps

les conversations préconf et basées sur rollup ont récemment commencé à prendre de l'ampleur, et je suis certainement encore du côté le plus prudent. Vitalik a célèbrement exposé ce qui suit Fin de partie:

Cependant, nous sommes déjà assez avancés dans la « production centralisée » sans avoir encore mis en place des protections anti-censure plus solides telles que des listes d'inclusion. Fondamentalement, Ethereum se situe à mi-chemin de la dernière rangée de cette image ci-dessous. (Je dis à mi-chemin car la censure n'est pas vraiment une question de tout ou rien, et Ethereum n'a qu'une « censure faible », c'est-à-dire que la plupart mais pas tous les blocs sont censurés, donc vous devrez peut-être attendre un peu, mais ensuite vous serez inclus):

source: Preuve de gouvernance

De manière empirique, la chaîne d'approvisionnement MEV de l'Ethereum L1 censure actuellement en temps réel plus de blocs que n'importe lequel de ces L2 avec des séquenceurs centralisés.

Les L2 peuvent déjà obtenir le CR éventuel de la L1 (ce qui est tout de même très bon) sans être basés. Les préconfs basées n’obtiennent pas la sécurité en temps réel du protocole Ethereum, elles bénéficient de la sécurité en temps réel de la petite poignée de fournisseurs d’infrastructure relativement centralisés qui l’entourent. Pour une meilleure CR en temps réel, la meilleure option est probablement d’externaliser le séquençage vers un type de séquenceur décentralisé exécutant un simple consensus BFT. Ce sera beaucoup plus robuste que de centraliser de nombreuses chaînes dans un goulot d’étranglement actuellement relativement centralisé. Cette situation pourrait s’améliorer avec des changements tels que les enchères d’exécution et les listes d’inclusion, mais ce n’est pas tout à fait pour demain.

En tenant compte de tout cela, il n'est pas clair pour moi que l'extension de la dépendance vis-à-vis de l'infrastructure MEV d'Ethereum L1 pour ensuite l'enraciner dans L2 soit une excellente idée à ce stade, alors qu'il y a une poignée de personnes qui construisent et relaient tous les blocs Ethereum, la plupart des blocs sans censure d'Ethereum aujourd'hui dépendent d'un seul constructeur (Titan), et aucun des outils CR n'a encore été implémenté dans le protocole. Cela semble être une accélération agressive à un moment fragile. Ethereum devrait certainement travailler à améliorer l'UX des L2, mais pas au détriment de toutes les propriétés sous-jacentes que nous voulions en premier lieu.

conclusion

nous construisons tous la même chose.

Eh bien, en quelque sorte. De toute évidence, ces choses ne sont pas toutes littéralement la même chose. Il y aura toujours des différences pratiques entre ces systèmes. Cependant, la tendance générale dans la crypto est claire : nous convergions tous vers des architectures de plus en plus similaires.

les différences techniques nuancées entre eux peuvent en pratique avoir des implications significatives sur l'endroit où ils finissent, et nous ne pouvons pas sous-estimer le rôle important que joue la dépendance au chemin dans ces systèmes même s'ils convergent vers des objectifs similaires.

De plus, il est sacrément impossible de raisonner sur certaines de ces choses.Comme Vitalik l'a dit:

« Une note de prudence que j'ai pour les APS est que je pense, d'un point de vue purement technique, que c'est assez léger et que nous sommes tout à fait capables de le faire avec très peu de risque d'erreur technique... mais d'un point de vue économique, il y a beaucoup plus d'opportunités pour les choses de mal tourner...

Comme pour l'eip-1559, nous avons pu comprendre grâce à la théorie. Nous avons assisté à quelques conférences d'économie intéressantes et appris les dangers des enchères au premier prix et pourquoi elles sont mauvaises. Nous avons compris que les enchères au deuxième prix ne sont pas crédibles, puis avons découvert qu'un mécanisme de prix fixe localisé dans chaque bloc pourrait être utilisé. Nous avons pu faire beaucoup grâce à la microéconomie.

mais aps n'est pas comme ça, n'est-ce pas? Et la question de savoir si aps va conduire Citadel ou Jane Street ou Justin Sun ou qui que ce soit à produire 1% de tous les blocs ethereum ou 99% est très très difficile, voire impossible à déterminer à partir des premiers principes.

et donc la chose que je veux voir à ce stade, c'est une expérimentation en direct... pour moi personnellement, l'écart entre aujourd'hui et le moment où je me sentirai vraiment à l'aise avec les aps, c'est essentiellement les aps qui fonctionnent avec succès sur une couche 2 Ethereum qui a une valeur moyenne, de l'activité, une communauté et de réels problèmes qui se produisent, et cela dure pendant un an, éventuellement plus longtemps pendant un an, et nous pouvons réellement voir des conséquences en direct.

Donc oui, je ne sais pas ce qui va se passer non plus. Nous devrons juste attendre et voir. Dans tous les cas, pendant que nous convergions tous vers ce que sera ce jeu final, nous avons beaucoup plus en commun que ce qui nous divise, alors assurons-nous de s'il vous plaît...

démenti:

1. Cet article est repris de [.dba]. transmettre le titre original 'nous construisons tous la même chose'. tous les droits d'auteur appartiennent à l'auteur original [jon charbonneau]. S'il y a des objections à cette reproduction, veuillez contacter leGate.io apprendre et ils s’en occuperont rapidement.
2. Clause de non-responsabilité : les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe d'apprentissage de Gate.io. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.