jakiro
Auteur: Toni Wahrstätter Source: Traduction ethresear.CH: Shan Oppa, Vision de Bitchain
Bref aperçu:
-
Le constructeur peut ne pas avoir de motivation pour inclure le blob en raison d’une latence plus élevée causée par le blob.
-
Les utilisateurs non-BOOST incluent plus de blobs dans les blocs en moyenne que les constructeurs MEV-Boost.
-
Par rapport aux utilisateurs non-Boost, la probabilité que les utilisateurs de Boost MEV-Boost soient réorganisés est considérablement réduit (voir les sections MEV-Boost et de réorganisation pour plus de détails).
-
Les constructeurs RSYNC-Builder et Flashbots ont des taches moyennes plus faibles par bloc que les autres constructeurs.
Dans une analyse récente des grands blocs, des blobs et de la réorganisation, l’impact des blobs sur la probabilité de réorganisation peut être observé.
Dans ce qui suit, je voudrais inclure l’écosystème MEV-Boost en considération pour une discussion plus approfondie.
Les questions de base sont:- & gt; « MEV-Boost affecte-t-il la restructuration?Si oui, quelle est la taille de l’impact?«
Les blobs sont des « grands » objets et les grands objets provoquent une latence plus élevée.Ainsi, le constructeur peut ne pas inclure un blob dans son bloc dans les circonstances suivantes:
-
Le constructeur commet des blocs plus tard dans la fente pour minimiser les retards (voir le jeu chronométré).
-
Le constructeur veut capturer des opportunités MEV élevées et ne veut pas invalider ses blocs en raison de blobs indisponibles.
-
Les partisans ont une mauvaise connectivité (car la propagation commence plus tard).
ConstructeurLa compensation par des frais de priorité peut être nécessaire pour inclure des transactions susceptibles de provoquer la propagation de la latence plus élevée.Avant 4844, ces transactions étaient principalement des transactions contenant un grand nombre de CallData.Depuis 4844, les blobs sont devenus le principal moteur de la latence.
Comme le montre la figure ci-dessus, les conseils pour les transactions BLOB ne sont pas aussi bons que les transactions de type 2 régulières.
Sur la base de cela, Blobs ne donnera pas aux constructeurs d’avantages importants lorsqu’ils sont en compétition pour les mêmes créneaux temporels.Une autre explication pourrait être une transaction privée entre le constructeur et le Rollup pour garantir l’inclusion en temps opportun des transactions BLOB par les frais payés via le canal latéral.
Mev-boost et réorganisation
ML’écosystème EV-Boost se compose de participants, constructeurs et répéteurs complexes, ces participants sont bien connectés et sont spécialisés dans l’établissement de connexions à faible latence avec les pairs.Par conséquent, les proposants utilisant MEV-Boost devraient être réorganisés moins que les «constructeurs de vanille» (c’est-à-dire les utilisateurs qui n’utilisent pas MEV-Boost).
Cette attente est vraie lors de la visualisation de l’image ci-dessus.On peut voir,À mesure que le nombre de blobs augmente, la probabilité de recombinaison augmente.Cependant, la probabilité de réorganisation pour les utilisateurs de MEV-Boost est bien inférieure à celle des utilisateurs non-Boost (Builders Vanilla).
Dans ce cas, il est important de ne pas confondre la corrélation et la causalité:
– & gt; Les utilisateurs non-Boost sont sur des entités moins complexes, ce qui conduit également aux effets que nous avons observés dans la figure ci-dessus.
Dans ce cas, il est intéressant de comparer le nombre moyen de blobs par bloc pour les utilisateurs MEV-boost et les utilisateurs non-Boost.
Comme indiqué dans l’image ci-dessus, les proposants qui n’utilisent pas MEV-Boost incluent plus de blobs dans leurs blocs en moyenne, tandis que les utilisateurs Mev-Boost sont moins.Cela peut indiquer que les participants aux écosystèmes de Boost Mev (répéteurs et constructeurs) ont adopté une stratégie au-delà de «l’inclusion en l’espace».
Tout d’abord, examinons de plus près le constructeur.
Les constructeurs de vanille (proposition non-boost) ont le taux d’inclusion BLOB le plus élevé, suivi de BeaverBuild et Titan Builder.
RSync-Builder semble contenir beaucoup moins de blobs dans ses blocs.Il en va de même pour les constructeurs Flashbots, qui semblaient changer de comportement au début de mai, le nombre moyen de blobs par bloc approchant zéro.
« Est-il juste de dire » Builder XY Review Blobs « ? »
Injuste
Différents constructeurs adoptent différentes stratégies.Par exemple, les constructeurs comme RSYNC-Builder sont souvent compétitifs dans les plages horaires avec une faible latence et une importance de vitesse, et peuvent finir par gagner des blocs sans blobs (voir biais de sélection).
Ensuite, tournons notre attention aux répéteurs:
Comme indiqué ci-dessus, les constructeurs de vanille ont le taux d’inclusion BLOB moyen le plus élevé.Les répéteurs de la gnose échographique et agnostique sont classés respectivement deuxième et troisième, suivis des répéteurs de Bloxroute.Le répéteur Flashbots semble contenir le moins de blobs.
Surtout, les répéteurs s’appuient sur les constructeurs et, finalement, les constructeurs influencent le graphique ci-dessus.
Prochaine étape
Dans le contexte de Peerdas 10, le réseau devra s’appuyer sur des nœuds plus puissants que les autres nœuds et capables de gérer plus de 6 blobs par bloc.Par conséquent, il sera d’une grande valeur de voir plus de recherches sur le sujet.
Appel de reproduction: Ce serait formidable si quelqu’un pouvait vérifier mes résultats en reproduisant cette analyse.
Étudiez pourquoi certains constructeurs ont des taux d’inclusion BLOB nettement plus faibles que d’autres.
Réduire le taux de réorganisation des utilisateurs non-Boost: les répéteurs peuvent fournir leurs services de propagation de blocs aux utilisateurs non-Boost pour s’assurer que leurs blocs sont moins réorganisés.
Le marché des blobs est toujours en développement et les prix des Blob stables n’ont pas encore été découverts.À mesure que la demande d’espace blob augmente, les conseils des transactions BLOB peuvent rattraper les transactions régulières.
