Le 30 juin, Vitalik a publié un nouvel article discutant des problèmes d'Ethereum avec la vitesse de confirmation des transactions. Vitalik a mentionné qu'Ethereum a été grandement amélioré par rapport à il y a cinq ans. Grâce à l'EIP-1559 (ajustement dynamique des frais de transaction) et au temps de génération de bloc stable après la fusion, les transactions envoyées par les utilisateurs sur L1 sont généralement confirmées dans les 20. secondes. Cependant, ce temps peut être encore amélioré, et pour certaines applications qui nécessitent explicitement une latence de quelques centaines de millisecondes, voire moins, une réduction supplémentaire du temps d'accusé de réception est tout à fait logique. Pour atteindre cet objectif, la communauté Ethereum et les chercheurs ont proposé des solutions pratiques, dont les préconfirmations.
Les préconfirmations (preconf) sont un état de pré-confirmation d'une transaction avant qu'elle ne soit officiellement confirmée. Plus précisément, il s'agit d'une confirmation temporaire par le nœud avant que la transaction ne soit incluse dans le bloc par le mineur et officiellement mise sur la chaîne. Cette confirmation temporaire signifie que plusieurs nœuds vérifient la validité de la transaction et la stockent temporairement dans la mémoire. piscine. Cela permet aux utilisateurs de recevoir un signal indiquant que la transaction a été acceptée dans un court laps de temps, obtenant ainsi un retour immédiat pour réduire le temps d'attente et améliorer l'expérience utilisateur. Cette pré-confirmation n'est pas la confirmation définitive et peut encore être révoquée (comme dans le cas d'une réorganisation de bloc), mais cette situation est relativement rare.
Normalement, dans le mécanisme de pré-confirmation, le proposant joue le rôle de fournir des services de pré-confirmation. Moyennant des frais supplémentaires, les utilisateurs peuvent obtenir un engagement de signature indiquant que leurs transactions seront incluses dans le bloc suivant. Si les proposants ne respectent pas leurs engagements, ils s’exposent à des sanctions financières.
Le chercheur de la Fondation Ethereum, Justin Drake, a fait la promotion d'une méthode de mécanisme de pré-confirmation d'Ethereum : les préconfirmations basées, qui fournissent une confirmation rapide des transactions grâce à des mécanismes d'incitation et de pénalité spécifiques.
Afin de réduire le risque que les transactions ne parviennent pas à être regroupées en blocs pour diverses raisons dans le mécanisme des préconfs basés, des pénalités supplémentaires pour le proposant et une inclusion forcée sont requises :
Slashing du proposant : proposition L1 Les candidats doivent choisir d'ajouter des les conditions de pénalité deviennent des préconférations. Ceci peut être réalisé grâce à des mécanismes liés au jalonnement important.
Inclusions forcées des proposants : les proposants L1 doivent être capables de forcer l'inclusion des transactions dans la chaîne, même lorsque les conditions économiques sont faibles ou que les autres proposants ne sont pas coopératifs. Ceci peut être réalisé grâce à des listes d’inclusion.
Le proposant L1 devient un pré-confirmateur en acceptant les deux conditions de pénalité de pré-confirmation suivantes. Les pré-validateurs émettent des engagements de pré-confirmation signés aux utilisateurs, promettant d'inclure les transactions dans des blocs dans une période de temps spécifiée, et reçoivent des conseils des utilisateurs pour remplir leurs engagements.
Réduction de la vivacité : les pré-confirmateurs s'exposeront à des pénalités s'ils n'incluent pas les transactions pré-confirmées dans le délai spécifié.
Slashing de sécurité : les pré-confirmateurs s'exposeront à des pénalités si leurs engagements ne sont pas cohérents avec les transactions réellement incluses.
De plus, les pré-confirmateurs seront priorisés en fonction de leur position dans l'anticipation du proposant afin d'exécuter les transactions de pré-confirmation plus rapidement. Le mécanisme d'anticipation des proposants est un mécanisme utilisé pour déterminer quels proposants auront la possibilité de regrouper des blocs à l'avenir. Chaque futur proposant se verra attribuer un numéro de position, qui représente sa position dans l'ordre des futures propositions de blocs. Les pré-confirmateurs sont triés en fonction de leur position dans l'anticipation du proposant. Plus le numéro de position est petit, plus la priorité du pré-confirmateur est élevée. Supposons qu'une transaction soit validée par le pré-confirmateur B, alors le proposant avec un numéro de position plus petit avant B (pré-confirmateur A) peut immédiatement emballer la transaction, réduisant ainsi le temps d'attente de l'utilisateur et n'ayant pas à attendre le tour de B à ce moment-là. période en tant que proposant. Si le proposant précédent de B ne parvient pas à regrouper les transactions à temps, le pré-confirmateur B doit s'assurer que ces transactions sont incluses dans sa période de temps, sinon il s'exposera à des pénalités.
Avec les conditions et paramètres ci-dessus, les préconfs basés peuvent fournir à L1 une confirmation de transaction plus rapide. Si le cumul est basé (l'ordre de L2 est laissé à L1), c'est-à-dire que tous les blocs L2 sont logiquement considérés comme des transactions L1, alors le même mécanisme peut être utilisé pour fournir une pré-confirmation pour L2.
Justin Drake a proposé des préconfirmations basées, ce qui a attiré l'attention de la communauté sur le mécanisme de préconfirmation. Ensuite, la communauté a lancé une riche discussion sur le thème de la pré-confirmation. Parmi les plus remarquables figurent : Jonah B, membre de Blockchain Capital, a proposé de permettre aux utilisateurs de personnaliser les mesures punitives dans le mécanisme de pré-confirmation ; Matthew a proposé d'utiliser le mécanisme de pré-confirmation en chaîne (chaînage préconf) pour protéger le proposant d'être puni par des situations externes inattendues telles que des pannes de courant, des interruptions de réseau, etc. (le chercheur de Primev, Christian Matt, a introduit deux modes de pré-confirmation) ; : l'un est effectué par un leader désigné (basé sur un leader) et fournit une pré-confirmation, et l'autre consiste à fournir une pré-confirmation par plusieurs concurrents (sans leader) en l'absence d'un leader. L'avantage du mode leader est qu'il peut fournir une garantie de confirmation de près de 100 %. Dans un environnement concurrentiel sans leader, il permet de découvrir efficacement les prix pré-confirmés et d'optimiser les revenus du vérificateur. Christian Matt a également proposé plusieurs solutions combinant la pré-confirmation avec et sans leader ; Potuz, membre de la Fondation Ethereum, a discuté de divers défis et solutions pour l'introduction d'un mécanisme de pré-confirmation dans le cadre ePBS.
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!