Buterin : Trois solutions pour accélérer le temps de confirmation des transactions ! Quel est l’avenir de Layer2 ?

Optimisation du temps de confirmation des transactions Ethereum

Le co-fondateur d'Ethereum, Vitalik Buterin, a proposé des méthodes pour optimiser le temps de confirmation des transactions, notamment :

1. La finalité d'un emplacement unique (SSF)

• Le mécanisme de consensus Gasper de remplacement détermine. bloque plus rapidement.
• Tous les joueurs doivent envoyer deux messages toutes les 12 secondes.
• Amélioration du débit, rendant la finalisation plus rapide.

2. Pré-confirmation de cumul

• transactions d'emballage de la chaîne latérale pour réduire la charge de la chaîne principale.
• Pré-confirmez les transactions de la chaîne latérale pour raccourcir le temps de confirmation des transactions de la chaîne principale.
• Améliorez l'évolutivité et prenez en charge davantage de transactions.

3. Basé sur un mécanisme de pré-confirmation

• Basé sur le mécanisme de consensus, les transactions sont pré-confirmées sur la chaîne principale.
• Semblable à la pré-confirmation Rollup, mais sans sidechains.
• Améliorez l'efficacité de la confirmation des transactions et réduisez la pression sur la chaîne principale.

architecture des slots et des époques

• slot : Une période de temps toutes les 12 secondes, généralement un bloc est généré.
• époque : Composé de 32 emplacements, toutes les 6 minutes et 24 secondes, et effectue des vérifications de statut et des récompenses et punitions du validateur.
• Ces structures garantissent une confirmation rapide des transactions.

  

  Dessin de conception de la proposition SSF
  Pré-confirmation rollup et pré-confirmation basée
  En outre, Buterin a également discuté des mécanismes de pré-confirmation rollup et de pré-confirmation basée. Ethereum a toujours suivi une voie de développement centrée sur le Rollup, en concevant L1 pour prendre en charge la disponibilité des données et d'autres fonctions, tandis que L2 fournit aux utilisateurs des services à plus grande échelle. Cependant, cela sera confronté à un problème inévitable : L2 doit être confirmé pour les utilisateurs. servi à des vitesses supérieures à 5 à 20 secondes.
  De plus, il est injuste d'exiger que tous les L2 mettent en œuvre un réseau de commande décentralisé, ce qui les oblige à effectuer l'essentiel du travail de la nouvelle L1.
  Pour résoudre ce problème, Justin Drake a lancé un mécanisme de pré-confirmation partagé basé sur la pré-confirmation basée sur Ethereum, le rendant accessible à tous les L2 et L1.
  L'approche de pré-confirmation basée sur l'hypothèse que les proposants d'Ethereum seront des participants très sophistiqués pour des raisons liées au MEV (Maximum Extractable Value). Les approches basées sur la pré-confirmation exploitent cette complexité en incitant ces proposants expérimentés à fournir des services de pré-confirmation. L'idée de base est de créer un protocole standardisé grâce auquel les utilisateurs peuvent payer une prime en échange d'une garantie immédiate que la transaction sera incluse dans le bloc suivant, et éventuellement d'une réclamation sur les résultats de l'exécution de la transaction. Si un proposant ne respecte pas l'une de ses promesses envers les utilisateurs, il sera réduit.
  En résumé, la préconfirmation basée offre une garantie pour les transactions L1. Si le cumul est "Basé", alors tous les blocs L2 sont des transactions L1, donc le même mécanisme peut être utilisé pour fournir une pré-confirmation pour n'importe quelle L2.
  3 Orientations de développement de L2
  Enfin, Buterin a proposé trois stratégies de développement raisonnables pour L2 :
  1 Les niveaux techniques et spirituels sont basés sur Ethereum : ces L2 sont optimisés pour les attributs techniques et la valeur de la couche de base d'Ethereum (forte décentralisation, anti-. censure, etc.). En termes simples, ces cumuls peuvent être considérés comme des « fragments de marque » et permettent une expérimentation approfondie avec de nouvelles conceptions de VM et d'autres améliorations techniques.
  2. Architecture blockchain basée sur serveur : ces L2 commencent par des serveurs, puis ajoutent la preuve de la validité de STARK, les droits des utilisateurs de retirer ou de forcer des transactions et la liberté de choix collectif (comme coordonner les retraits massifs ou modifier les capacités des donneurs d'ordre), tout en maintenir l’efficacité du serveur tout en bénéficiant des avantages des opérations massives en chaîne.
  3. Compromis : en utilisant une chaîne rapide à cent nœuds, Ethereum offre une interopérabilité et une sécurité supplémentaires, ce qui constitue la véritable feuille de route de nombreux projets L2.
  Chacune de ces trois stratégies a une architecture de slot et d'époque différente :
  Architecture native d'Ethereum
  Pré-confirmation du serveur
  Pré-confirmation du comité
  La question clé que pose Buterin est de savoir combien pouvons-nous faire de bien dans la première catégorie ? Si la première catégorie devient très bonne, l’importance de la troisième catégorie peut diminuer. La deuxième catégorie existera toujours, car toute solution « basée sur Ethereum » n'est pas adaptée aux données hors chaîne L2 telles que les plasmas et les validiums.
  Buterin a conclu que nous avons besoin de plus d'options pour simplifier le travail des développeurs L2 et améliorer l'expérience utilisateur.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!