TL;DR

1. Notre recherche se penche sur le marché émergent des blobs EIP-4844, qui fonctionne de manière similaire à la tarification du gaz EIP-1559 mais qui ne dispose pas d'un mécanisme de pourboire direct pour l'inclusion des blobs dans le bloc, ce qui pourrait entraîner une expérience de transaction blob peu fiable et des défis d'inclusion.
2. Nous notons que bien que les transactions de blob soient volumineuses (~125 kB) et moins chères que les calldata équivalents, elles ajoutent une taille significative aux blocs Ethereum mais apportent un pouvoir d'enchère incrémentiel pour un bloc.
3. Nous démontrons que la capacité de ce nouveau marché absorbe les besoins actuels en données de rollup et réduit les coûts de gaz de l'espace de bloc standard de 15 à 20 %, débloquant des opportunités mev à moindre coût.
4. Nous observons que les transactions de blob risquent de ralentir la propagation des blocs de centaines de millisecondes en période d'activité réseau accrue, ce qui peut amener les constructeurs de blocs à censurer les blobs pour maintenir une surenchère compétitive dans le mev-boost.
5. Nous évaluons qu'une "offre de préconf" peut atténuer ces défis et que les préconfs de blob peuvent améliorer les capacités de l'EIP-4844, offrant des expériences de transaction améliorées pour les utilisateurs L2 et une expérience d'inclusion stable pour les rollups.
6. Nous allons expérimenter sur le testnet Holesky, collecter des données de construction de blocs, et mettre en place des relais en tant que fournisseurs de blob preconf en utilisant mev-commit, et nous invitons les acteurs de PBS à participer.

Introduction

EIP-4844 étend les capacités de disponibilité des données d'Ethereum avec l'introduction d'un marché de blob. Ce marché naissant utilise un mécanisme de prix du gaz similaire à l'EIP-1559 pour fixer le prix et brûler les frais de gaz de base du blob. Cependant, contrairement aux transactions de type2, il n'y a pas de moyen direct d'enchérir pour un pourboire du constructeur pour inclusion sur le marché du blob. Le manque de frais de priorité rend difficile la fixation précise du prix de l'inclusion du blob. De plus, les blocs contenant des blobs sont censés se propager plus lentement à travers le réseau en raison de la taille des blobs, qui sont parmi les plus grandes transactions d'Ethereum. Si les constructeurs acceptent de nombreux blobs dans un bloc, ils font actuellement face à un risque accru de réorganisation de bloc, et un constructeur économiquement rationnel pourrait choisir de censurer parfois les blobs pour maintenir la latence de construction du bloc bas, ce qui pourrait être corrélé à des pics de MEV.

Nous avons mis en avant un effort de construction de blocs liés aux blobs et de collecte de données de renforcement de mev, ainsi qu'une expérience de fournisseur de préconfirmation de blobs utilisant mev-commit, et inviter la communauté des rollups, relais, constructeurs de blocs et proposants à participer. Nos connaissances sur le comportement lié aux blobs dans l'EIP-4844 suggèrent que les pré-confirmations de blobs L1 peuvent améliorer les capacités du marché des blobs à offrir une meilleure expérience de transaction pour les utilisateurs de L2, une inclusion fiable pour les rollups dans les conditions émergentes de MEV, et un avenir plus stable centré sur les rollups pour Ethereum.

Comprendre le marché de Blob

Transactions de Blob

EIP-4844introduit un type de transaction de type3 (tx) appelé une tx de blob. Une tx transportant un blob est comme une transaction régulière, mais améliorée avec des données de blob, des engagements KZG et des preuves. Les blobs sont extrêmement volumineux (~125 ko) par rapport aux tx Ethereum standard, et sont beaucoup moins chers qu'une quantité équivalente de calldata. Alors que le calldata est tarifé à 16 gaz par octet non nul et peut avoir une taille variable, les données de blob sont tarifées à 1,04 gaz par octet et ont une taille fixe de 131,072 gas.

Mécanique du gaz de Blob

Tarification du gaz de base Bloba un mécanisme de frais de congestion similaire à l'EIP-1559. La principale différence est que le blob gas est un nombre cible de blobs, tandis que l'EIP-1559 est basé sur l'utilisation cible du gaz. Le nombre cible de blobs est de 3 (0,375 Mo), et le maximum est de 6 (0,75 Mo) par bloc. Le gaz de base blob minimum est fixé à 1 wei.

Lorsqu'une transaction blob est soumise, l'expéditeur soumettra un max_fee_per_blob_gas comme prix le plus élevé qu'il est prêt à payer pour les frais de base de gaz blob, le tout étant brûlé. Le max_fee_per_blob_gas est similaire au max_fee_per_gas dans les transactions de type0 et type2. Si l'utilisateur souhaite soumettre des frais supplémentaires pour inciter à l'inclusion, il soumettrait également un max_priority_fee. Cependant, le max_priority_fee ne couvre que la partie de la transaction qui ne concerne pas le gaz blob. Cela ne laisse aucun moyen direct de soumettre un pourboire d'inclusion au constructeur.

Capacité du marché Blob

Dans cette section, nous effectuer un backtestsur l'activité de rollup historique de janvier 2023 à janvier 2024 pour démontrer la capacité du marché blob. Nous nous concentrons sur les txs des rollups les plus actifs sur Ethereum et utilisons les données historiques pour simuler un marché blob en direct. Bien que ce marché soit en croissance active et n'est pas encore sur le mainnet,nous utilisons des données historiquesde toute l'année 2023 pour simuler son potentiel.

Basé sur l'activité historique des données d'appel rollup utilisées sur l'espace de bloc de type3 tx, nous constatons que le prix du marché des blobs peut absorber confortablement toute la capacité rollup sans déplacer le prix du marché des blobs au-delà du gaz de base minimum des blobs.

base blob gaz par bloc

Bien que les rollups envoient plus de données à Ethereum, la majorité des blocs sont encore en dessous de la cible, ce qui garantit que le prix du gaz blob reste bas.

La couleur plus claire indique un nombre plus élevé de fois qu'un bloc serait construit avec un certain nombre de blobs inclus.

💡 Les implications sont que non seulement le coût des données d'appel sera inférieur sur le marché blob (facteur de 16), mais le prix du gaz sera également beaucoup moins cher (wei vs gwei), ce qui se traduit par deux niveaux d'économies de coûts supplémentaires pour les rollups.

Non seulement le marché blob peut absorber confortablement les besoins actuels en matière de disponibilité des données de rollup, mais il libère également de l'espace de bloc sur le marché non-blob, réduisant ainsi les coûts de gaz de 15 à 20 %. La réduction des coûts de gaz augmente proportionnellement les capacités d'enchères pour les utilisateurs/chercheurs, les constructeurs et les validateurs, et ouvre de nouvelles opportunités de mev qui étaient exclues avant l'EIP 4844.

Effet de l'EIP 4844 sur l'espace de bloc standard en utilisant les données de 2023.

Les Rollups demandent plus de disponibilité des données

Les rollups ont une influence majeure sur la quantité de gaz utilisée dans les blocs, et ils sont la plus grande catégorie d'utilisateurs de gaz de l'espace de bloc Ethereum aujourd'hui. En 2023, les rollups ont stocké des quantités record de données de transaction sur Ethereum, comme nous le décrivons ci-dessous :

Les données d'appel enregistrées sur Ethereum sont à des niveaux record.

Les graphiques moyens quotidiens ci-dessous montrent que les rollups commencent à prendre plus de 15 % de chaque bloc dans lequel ils se trouvent, affectant directement le prix pour les autres utilisateurs.

Cela peut être encore exacerbé dans les situations de demande de cygne noir. Récemment en décembre 2023, le spam d'inscription a mis hors ligne le séquenceur Arbitrumpendant environ une heure en raison du nombre écrasant de transactions. Lorsque le séquenceur Arbitrum a repris ses opérations et a commencé à publier le backlog des états sauvegardés, le séquenceur a monopolisé l'espace de bloc, causant les prix du gaz vont grimper au-dessus de 140 gwei et consommer plus de 90% du gazdans des blocs entiers, rendant le réseau inutilisable pour la majorité des utilisateurs pendant plusieurs heures.

Dans la section suivante, nous expliquons comment les jeux de timing et la censure sont susceptibles d'affecter ce marché même en l'absence de pics de demande.

Défis du marché des BLOB : censure

Propagation de Blob

EIP-4844 augmente les besoins en bande passante par bloc de phare d'un maximum d'environ 0,75 Mo, 42m de gaz pour accueillir jusqu'à 6 blobs supplémentaires dans chaque bloc de phare. Contrairement aux calldata, qui sont stockés pour toujours, les blobs sont persistés dans les nœuds de phare pendant une courte période (18 jours à partir de février 2024) afin de maintenir la croissance de l'état d'archive du réseau gérable.

De plus, les transactions de blob ont deux représentations réseau - pour le constructeur de blocs en tant que tx de blob et pour le validateur en tant que sidecar de blob. Le sidecar de blob existe pour compatibilité avantfinalités.

Les blobs doivent d'abord se propager à travers la couche d'exécution avant de passer à travers la couche de consensus. Cela signifie que ce sont les constructeurs, et non les validateurs, qui ont le dernier mot sur inclusion de blobLes proposants ne peuvent exclure que les transactions de blob basées sur l'engagement ou la preuve d'invalidité dans le cadre de la dynamique de renforcement de l'mev.

La vérification de l'exécution est effectuée par les constructeurs. La vérification du consensus est effectuée par les validateurs.

La Perspective du Constructeur de Blocs

Recherche récente sur les jeux de synchronisation des validateurs souligne que l’optimisation de la latence peut bénéficier stratégiquement aux opérateurs de nœuds pour maximiser les profits en retardant les propositions de blocs. Les auteurs expliquent que cela est préjudiciable à la santé de la chaîne. Les transactions d’objets blob compliquent davantage les jeux de synchronisation en ajoutant une quantité variable de latence lorsque l’objet blob sidecar propage.

Les transactions Blob sont équivalentes aux tailles de transaction les plus importantes possibles. En conséquence, les blocs contenant ces transactions peuvent se propager plus lentement, ce qui rend les constructeurs de blocs moins compétitif pour remporter des offres de mev-boostEn conséquence, cela incite les constructeurs de blocs à censurer temporairement ou même indéfiniment des blobs afin de pouvoir soumettre des offres de MEV avec fréquence plus élevée.

Le ethpandal'équipe a effectué des tests de latence réels sur les réseaux de test en utilisant @ethpandaops/xatu-overview">Xatu. Les sentinelles sont placées dans les régions de NYC, FRA, BLR et SYD pour représenter les mesures de latence réelle en utilisant les clients de consensus Prysm, Nimbus, Lodestar et Lighthouse. Un instantané de données avec des données de blob Holesky le 20 février 2024 indique qu'une quantité non négligeable de latence est encourue tout au long du pipeline mev.

Après que le constructeur de blocs remporte l'enchère mev-boost, le proposant doit attendre que les sidecars de blob se propagent avant de pouvoir vérifier les blobs inclus dans le bloc. Le tableau ci-dessous montre que le temps minimum pour qu'un seul sidecar de blob se propage est d'environ 400 ms sur un échantillon de ~800 sidecars de blob.

Table 1. Propagation du blob par rapport au nombre de blobs pour la fente

Une petite taille de données contribue à certaines des observations contre-intuitives illustrées dans cet ensemble de données

La prochaine table montre les écarts de latence en attendant que plus de sidecars blob arrivent. Le 50e percentile (p50) indique que l'écart de latence entre un bloc de 2 blobs et un bloc de 6 blobs est d'environ 225 ms.

Table 2. Différence de temps entre le premier et le dernier sidecar de blob regroupé par le nombre total de sidecars de blob dans le bloc

Cette latence de propagation de blob ajoute un risque supplémentaire de réorganisation de bloc pour les constructeurs de blocs lorsqu'ils remplissent leurs blocs de blobs, pour peu de gain économique. Le constructeur pourrait choisir d'exclure/censurer la transaction de blob pour éviter une réorganisation potentielle. Si un bloc contient beaucoup de MEV, les constructeurs économiquement rationnels devraient être compensés de manière appropriée par les rollups pour ce risque.

Sur l'enchère d'inclusion de marché Blob UX

Le jeux de synchronisation de la recherche des validateurssouligne que des offres plus importantes sont corrélées à des blocs de plus grande taille plus tard dans le processus d'enchères mev-boost. À mesure que les offres et le prix du gaz augmentent, une plus grande part d'ETH est brûlée dans les créneaux ultérieurs. Si la commission de base augmente alors que l'extraction de mev reste constante, les constructeurs ont moins à offrir pour le revenu futur d'un proposant.

Dans le marché blob attendu où la capacité dépasse la demande actuelle, la taxe de base blob qui est brûlée restera très faible, dans les dizaines ou centaines de wei. Il devient essentiel pour les rollups de reconnaître que leurs transactions blob pourraient ne pas être incluses malgré le paiement de la taxe de base suffisante. Le marché blob à faible frais de base implique que les blobs devront offrir de nombreux multiples plus élevés pour inciter les constructeurs à inclure les transactions. Dans de tels cas, la transaction blob devra être soumise à nouveau avec des frais augmentés, ce qui entraîne une mauvaise UX.

De plus, comme le marché initial du blob sous l'EIP-4844 n'aura pas de mécanisme d'inclusion (par exemple, des frais de gaz de priorité de blob), cela aggrave encore le problème de l'expérience utilisateur car le rollup ne peut pas enchérir directement sur la transaction de blob.

Nous examinons un exemple de transaction et calculons le coût équivalent en blob en supposant un coût de gaz de base blob de 10 wei. Notez que cet exemple suppose qu'il existe un mécanisme d'enchères d'inclusion efficace pour pouvoir enchérir sur l'espace de blob en premier lieu.

💡Voici un exemple de transaction:

Données d'appel - 129 998 octets (129 429 octets non nuls) ~ 2 094 140 gaz utilisés à 10,56 gwei (prix de base de 10,55 gwei + Frais de priorité de 0,01 gwei) = 0,022 ETH

Blob - 128,000 octets ~ 131,072 gaz utilisés à 1 gwei (prix de base de 10 wei + frais de priorité de 0,99999999 gwei) = 0,000131072 ETH

Le calcul conclut que si les rollups utilisent le marché des blobs, ils peuvent soumettre une offre potentiellement 100 fois plus importante en raison du tarif de base inférieur des blobs tout en économisant plus de 150 fois le coût. Le tarif de base inférieur des blobs permettra aux rollups de proposer des offres d'inclusion plus compétitives tout en réalisant des économies. Les frais d'inclusion devront être aussi compétitifs que les opportunités MEV existantes dans le bloc pour compenser le risque potentiel de réorganisation du constructeur, et donc même une offre 100 fois plus élevée pourrait ne pas suffire. Autrement dit, en l'absence de préconfirmations de blobs.

Blob Préconfirmations avec mev-commit

Dans de tels jeux de synchronisation, le rôle principal d'une préconfirmation de blob est de dresser une liste de blobs que le fournisseur a préconfirmés disponibles dans le pipeline MEV. Lors de la validation MEV, chaque fournisseur de préconf émet ses propres engagements aux txs. Le fournisseur peut ensuite donner accès à ces données à d'autres (par exemple, constructeurs de blocs, relais, séquenceurs). La disponibilité des données de la liste de préconf pour d'autres acteurs à travers le pipeline MEV permet à la charge utile d'exécution correspondante d'être envoyée en parallèle par un constructeur de blocs. Cette notion peut être exploitée pour créer des listes d'inclusion de blob préconf, ou pour que l'espace de bloc de type3 soit construit de manière collaborative par un relais.

Avec la connaissance avancée des blobs préconfirmés, les constructeurs de blocs peuvent commencer à construire des blocs futurs avec des blobs avant le début de leur créneau. Cela crée une base de tarification et jette les bases d'un marché à terme robuste qui offre aux rollups une inclusion plus fiable et une stabilité des prix de l'espace de blocs. De plus, les offres préconf mev-commit donnent aux rollups un mécanisme de découverte de prix plus fiable car les rollups peuvent mettre à jour leurs offres préconf en temps réel sans soumettre à nouveau l'intégralité de la tx de blob.

Enfin, regrouper des blobs et utiliser une enchère préconf permet aux rollups de construire des alliances. Les enchères préconf peuvent être appliquées à des ensembles de transactions de blobs ou à des blobs agrégés, permettant aux rollups de partager leur puissance d'enchère et leur inclusion avec d'autres rollups, aidant à stabiliser et à développer le marché des blobs Ethereum.

Conclusion

Dans l'ensemble, nous montrons que l'économie des rollups s'améliore, alors qu'un nouveau marché émerge avec des considérations supplémentaires allant des jeux de timing à l'absence d'un mécanisme de basculement. Bien qu'il soit trop tôt pour passer à la phase de résolution des problèmes que nous mettons en évidence, nous pouvons facilement expérimenter cela avec les acteurs PBS étant donné que mev-commit est actif sur le testnet Holesky. Primev collectera des données sur les effets de blob sur la construction de blocs et la latence des proposants, et espère mettre en lumière des informations sur les éventuels schémas comportementaux.

Alors que l'économie et l'expérience utilisateur sont les principaux moteurs des transactions de type2 préconf, il semble que l'inclusion, la fiabilité et la stabilité du rollup et de l'écosystème centré sur le rollup deviendront des raisons importantes pour les blobs préconf sous l'EIP-4844. Nous expérimenterons également avec un relais de préconf de blobs qui pourra tirer parti des préconfs de blobs et de la coordination des constructeurs de blocs pour améliorer la propagation de la latence du sidecar de blob sur le testnet Holesky. Nous invitons la communauté à nous contacter et à participer à cette expérience car elle fournira une solution potentielle pour l'ensemble de la communauté.

Avertissement：

1. Cet article est repris de [Gatemiroir], Transmettre le titre original'Censure, Latence et Préconfirmations sur le marché du Blob', Tous les droits d'auteur appartiennent à l'auteur original [Primev]. En cas d'objections à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.

2. Clause de non-responsabilité: 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 effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.