*Transmettre le titre original 'Époques et créneaux jusqu'au bout : des moyens de donner aux utilisateurs d'Ethereum des temps de confirmation de transaction plus rapides'

L'une des propriétés importantes d'une bonne expérience utilisateur de la blockchain est le temps de confirmation rapide des transactions. Aujourd'hui, Ethereum s'est déjà beaucoup amélioré par rapport à il y a cinq ans. Grâce à la combinaison de EIP-1559et des temps de blocs stables aprèsLa Fusion, les transactions envoyées par les utilisateurs sur L1 se confirment de manière fiable en 5 à 20 secondes. Cela est à peu près compétitif avec l'expérience de paiement par carte de crédit. Cependant, il y a une valeur à améliorer encore l'expérience utilisateur, et il y a certaines applications qui nécessitent carrément des latences de l'ordre de centaines de millisecondes ou même moins. Ce post examinera certaines des options pratiques qu'Ethereum a à sa disposition.

Aperçu des idées et techniques existantes

Finalité d'un seul créneau

Aujourd'hui, Ethereum’s GasperLe consensus utilise une architecture de slot et d'époque. Toutes les 12 secondes, un sous-ensemble de validateurs publie un vote sur la tête de la chaîne, et au cours de 32 slots (6,4 min), tous les validateurs ont une chance de voter une fois. Ces votes sont ensuite réinterprétés comme étant des messages dans un sens vague.de type PBFTalgorithme de consensus, qui après deux époques (12,8 min) donne une assurance économique très solide appelée finalité.

Au cours des dernières années, nous sommes de plus en plus mal à l'aise avec l'approche actuelle. Les raisons principales sont que (i) c'est compliqué et il y a de nombreux bugs d'interaction entre le mécanisme de vote slot-par-slot et le mécanisme de finalité epoch-par-epoch, et (ii) 12,8 minutes, c'est beaucoup trop long et personne ne veut attendre aussi longtemps.

La finalité en un seul slot remplace cette architecture par un mécanisme beaucoup plus similaire à Consensus Tendermint, dans lequel le bloc N est finalisé avant que le bloc N+1 ne soit créé. La principale différence par rapport à Tendermint est que nous conservons le "fuite d'inactivité« mécanisme, qui permet à la chaîne de continuer et de récupérer si plus d'un tiers des validateurs sont hors ligne. »

Un diagramme des principaux proposésconception de finalité à un seul emplacement_

Le principal défi avec SSF est que, naïvement, il semble impliquer que chaque validateur Ethereum devrait publier deux messages toutes les 12 secondes, ce qui représenterait une charge considérable pour la chaîne à gérer. Il y a idées intelligentespour savoir comment atténuer cela, y compris les plus récentsOrbit SSFproposition. Mais même ainsi, bien que cela améliore considérablement l'expérience utilisateur en accélérant la « finalité », cela ne change pas le fait que les utilisateurs doivent attendre 5 à 20 secondes.

Préconfirmations Rollup

Au cours des dernières années, Ethereum a suivi une feuille de route centrée sur Rollup, en concevant la couche de base Ethereum (le “L1”) autour du support dedisponibilité des donnéeset d'autres fonctionnalités qui peuvent ensuite être utilisées par des protocoles de niveau 2 commerollups (mais aussi validiumsetplasmas) qui peut offrir aux utilisateurs le même niveau de sécurité qu'Ethereum, mais à une échelle bien plus élevée.

Cela crée un séparation-des-concernsau sein de l'écosystème Ethereum : Ethereum L1 peut se concentrer sur la résistance à la censure, la fiabilité, la stabilité, la maintenance et l'amélioration d'un certain niveau de fonctionnalités de base, et les L2 peuvent se concentrer sur l'interaction plus directe avec les utilisateurs - à travers différents moyens.culturelet des compromis technologiques. Mais si vous empruntez cette voie, un problème inévitable se pose : les L2 veulent servir les utilisateurs qui souhaitent des confirmations beaucoup plus rapides que 5 à 20 secondes.

Jusqu'à présent, du moins dans la rhétorique, il a été de la responsabilité des L2 de créer leurs propres réseaux de "séquençage décentralisé". Un petit groupe de validateurs signerait des blocs, peut-être une fois tous les quelques centaines de millisecondes, et ils mettraient leur "mise" derrière ces blocs. Finalement, les en-têtes de ces blocs L2 sont publiés sur L1.

Les ensembles de validateurs L2 pourraient tricher : ils pourraient d'abord signer le bloc B1, puis signer plus tard un bloc conflictuel B2 et le valider sur la chaîne avant B1. Mais s'ils le font, ils se feraient prendre et perdraient leurs dépôts. En pratique, nous avons vu des versions centralisées de cela, mais les rollups ont été lents à développer des réseaux de séquençage décentralisés. Et l'on peut argumenter que demander à tous les L2 de faire un séquençage décentralisé est un marché injuste : nous demandons aux rollups de faire essentiellement la majeure partie du travail de création d'un nouveau L1. Pour cette raison et d'autres, Justin Drake a promu une manière de donner à tous les L2 (ainsi qu'au L1) un accès à un mécanisme de préconfirmation partagé à l'échelle d'Ethereum :preconfirmations basées.

Pre-confirmations basées

L'approche de préconfirmation basée sur l'hypothèse que les proposants d'Ethereum deviendront des acteurs très sophistiqués pour des raisons liées à l'EMV (voiricipour mon explication de MEV, et voir aussi lebillets d'exécutionligne de propositions). L'approche basée sur la préconfirmation tire parti de cette sophistication en incitant ces proposants sophistiqués à accepter la responsabilité d'offrir des préconfirmations en tant que service.

L'idée de base est de créer un protocole standardisé selon lequel un utilisateur peut offrir des frais supplémentaires en échange d'une garantie immédiate que la transaction sera incluse dans le bloc suivant, éventuellement accompagnée d'une déclaration sur les résultats de l'exécution de cette transaction. Si le proposeur viole une quelconque promesse faite à un utilisateur, il peut être pénalisé.

Comme décrit, les pré-confirmations basées fournissent des garanties aux transactions L1. Si les rollups sont"basé", puisque tous les blocs L2 sont des transactions L1, le même mécanisme peut être utilisé pour fournir des pré-confirmations pour n'importe quel L2.

Que regardons-nous réellement ici?

Supposons que nous mettions en œuvre une finalité à un seul créneau. Nous utilisons Orbit-like techniques to reduce the number of validators signing per slot, but not too much, so that we can also make progress on the key goal of reducing the 32 ETH staking minimum. As a result, perhaps the slot time creeps upward, to 16 sec. We then use either rollup preconfirmations, or based preconfirmations, to give users faster assurances. What do we have now? An epoch-and-slot architecture.

Le mème "ce sont les mêmes images" est de plus en plus utilisé à ce stade, donc je vais simplement mettre un vieux schéma que j'ai dessiné il y a des années pour décrire l'architecture de la fente et de l'époque de Gasper et un schéma des préconfirmations L2 côte à côte, et espérons que cela fera passer le message.

Il existe une raison philosophique profonde pour laquelle les architectures d'époque et de créneau semblent être si difficiles à éviter : il faut intrinsèquement moins de temps pour parvenir à un accord approximatif sur quelque chose, que pour parvenir à un accord de « finalité économique » maximal sur celui-ci.

Une raison simple est le nombre de nœuds. Alors que l'ancien linéaire...@VitalikButerin/paramétriser Casper: l'échange de décentralisation / temps de finalité / surcharge semble plus modéré maintenant grâce à l'agrégation BLS hyper-optimisée et dans un avenir proche ZK-STARKs, il est toujours fondamentalement vrai que:

1. « L'accord approximatif » ne nécessite que quelques nœuds tandis que la finalité économique nécessite une fraction significative de tous les nœuds.
2. Une fois que le nombre de nœuds dépasse une certaine taille, vous devez passer plus de temps à recueillir des signatures.

Aujourd'hui, dans Ethereum, une tranche de 12 secondes est divisée en trois sous-tranches, pour (i) la publication et la distribution de blocs, (ii) l'attestation et (iii) l'agrégation des attestations. Si le nombre d'attestants était beaucoup plus faible, nous pourrions passer à deux sous-tranches et avoir un délai de tranche de 8 secondes. Un autre facteur, et réaliste plus important, est la "qualité" des nœuds. Si nous pouvions également compter sur un sous-ensemble professionnalisé de nœuds pour parvenir à des accords approximatifs (et toujours utiliser l'ensemble complet des validateurs pour la finalité), nous pourrions vraisemblablement réduire cela à ~2 secondes.

Par conséquent, il me semble que (i) les architectures à emplacements et époques sont évidemment correctes, mais aussi (ii) que toutes les architectures à emplacements et époques ne sont pas créées égales, et qu'il y a une valeur à explorer plus pleinement l'espace de conception. En particulier, il vaut la peine d'explorer des options qui ne sont pas étroitement entrelacées comme Gasper, et où au lieu de cela, il y a une séparation plus forte des préoccupations entre les deux mécanismes.

Que devraient faire les L2s?

À mon avis, il existe trois stratégies raisonnables que les L2 peuvent adopter en ce moment :

1. Être "basé", à la fois technologiquement et spirituellement. C'est-à-dire, ils optimisent pour être des conduits de passage pour les propriétés techniques de la couche de base d'Ethereum et ses valeurs (décentralisation élevée, résistance à la censure, etc). Dans leur forme la plus simple, vous pourriez penser à ces rollups comme étant des "shards" de marque, mais ils peuvent aussi être beaucoup plus ambitieux que cela, et expérimenter assez lourdement avec de nouvelles conceptions de machines virtuelles et d'autres améliorations techniques.
2. Soyez fièrement un “serveur avec échafaudage blockchain”, et tirez-en le meilleur parti. Si vous commencez par un serveur, puis ajoutez (i) des preuves de validité STARK pour garantir que le serveur respecte les règles, (ii) des droits garantis pour l'utilisateur pour sortir ou forcer des transactions, et éventuellement (iii) la liberté de choix collectif, que ce soit par une sortie de masse coordonnée ou par la capacité de voter pour changer le séquenceur, alors vous avez déjà tiré beaucoup des avantages d'être onchain, tout en conservant la plupart des efficacités d'un serveur.
3. L'approche de compromis : une chaîne rapide de cent nœuds, avec Ethereum offrant une interopérabilité et une sécurité supplémentaires. C'est la feuille de route actuelle de facto de nombreux projets L2.

Pour certaines applications, (par exemple, ENS, keystores), certains paiements), un temps de bloc de 12 secondes suffit. Pour les applications qui ne le sont pas, la seule solution est une architecture de slot et d'époque. Dans les trois cas, les « époques » sont la SSF d'Ethereum (peut-être pouvons-nous réinterpréter cet acronyme pour qu'il signifie autre chose que « single slot », par exemple cela pourrait être « Secure Speedy Finality »). Mais les « slots » sont différents dans chacun des trois cas mentionnés ci-dessus :

1. Une architecture de slot et d'époque native d'Ethereum
2. Préconfirmations du serveur
3. Préconfirmations du comité

Une question clé est de savoir à quel point pouvons-nous rendre quelque chose de bonne qualité dans la catégorie (1) ? En particulier, s'il devient vraiment bon, alors on a l'impression que la catégorie (3) cesse d'avoir autant de sens. La catégorie (2) existera toujours, au moins parce que tout ce qui est "basé" ne fonctionne pas pour les L2 hors chaîne tels que les plasmas et les validiums. Mais si une architecture native d'Ethereum basée sur les créneaux et les époques peut descendre à des "créneaux" de 1 seconde (c'est-à-dire des temps de pré-confirmation), alors l'espace pour la catégorie (3) devient considérablement plus petit.

Aujourd’hui, nous sommes loin d’avoir des réponses définitives à ces questions. Une question clé - jusqu’à quel point les proposants de blocs vont-ils devenir sophistiqués - reste un domaine où il y a pas mal d’incertitude. Des conceptions telles que Orbit SSFsont très récents, ce qui suggère que l'espace de conception des conceptions de fente et d'époque où quelque chose comme Orbit SSF est l'époque est encore assez peu exploré. Plus nous avons d'options, mieux nous pouvons faire pour les utilisateurs à la fois sur L1 et sur L2s, et plus nous pouvons simplifier le travail des développeurs L2.

Avertissement：

1. Cet article est repris de [ vitalik]. Transmettre le titre original ‘Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times’. Tous les droits d'auteur appartiennent à l'auteur original [vitalik*]. S'il y a des objections à cette reproduction, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Responsabilité de non-fiabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux 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 Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.