À la veille de la mise à niveau d’Ethereum Cancun, obtenez un aperçu complet du marché Blob

Article : 0xEvan, Primev

Traduit par : Franci, ETHconomics Research Space

Relecture : Jason, ETHconomics Research Space

Introduction du traducteur

Les articles précédents que nous avons publiés concernaient tous la transaction blob elle-même et le mécanisme de frais 4844. Dans cet article, l'auteur a utilisé le backtesting des données au cours de l'année écoulée pour simuler le potentiel du marché blob : quelle quantité de données peut-il contenir ? Peut-il répondre aux exigences de disponibilité des données du cumul ?

Outre l'impact de la courbe d'offre et de demande d'espace blob sur le marché du blob, les jeux de timing des validateurs et l'examen des constructeurs auront également des effets négatifs sur ce marché. Cet article effectue une analyse des données sur l'éventuel délai de diffusion des transactions blob, démontre son impact sur l'expérience utilisateur et la surcharge de disponibilité des données de cumul, et propose également une solution possible : pré-confirmer les transactions blob.

En général, cet article est une analyse relativement complète du marché du blob.Les lecteurs peuvent explorer le paysage futur de l'espace blob à travers le contexte de l'article.

texte:

🙏Un merci spécial à @terencechain pour l'examen, @BertKellerman pour les informations et @ethpandaops pour les données Holesky Testnet.

TL;DR

• Notre recherche examine en profondeur le marché émergent du blob EIP-4844, qui fonctionne de manière similaire à la tarification du gaz de l'EIP-1559. La différence est qu'il ne dispose pas d'un mécanisme de basculement directement pour les constructeurs de blocs pour les encourager à regrouper les transactions blob, ce qui peut conduire à une expérience de transaction blob instable et à certains défis pour leur regroupement en blocs.
• Nous notons que bien que les transactions blob soient volumineuses (~ 125 Ko) et moins chères que les données d'appel de même taille, elles augmentent considérablement la taille du bloc Ethereum. Cela signifie également que les transactions blob apportent un pouvoir d’enchère supplémentaire aux blocs.
• Nous avons démontré que la capacité de ce nouveau marché peut absorber les besoins actuels en données cumulées et réduire le coût du gaz de l'espace de bloc standard de 15 à 20 %, ouvrant ainsi des opportunités de mev à moindre coût.
• Nous avons observé que pendant les périodes d'activité réseau accrue, les transactions blob peuvent ralentir les diffusions de blocs de l'ordre de centaines de millisecondes, ce qui peut conduire à la censure des constructeurs de blocs afin de maintenir des enchères compétitives dans le blob mev-boost.
• Nous estimons que les « offres pré-confirmées » peuvent atténuer ces défis, et que la pré-confirmation de blob peut améliorer les capacités de l'EIP-4844, offrir une meilleure expérience de transaction aux utilisateurs L2 et fournir une expérience de packaging de transactions stable pour les cumuls.
• Nous mènerons des expériences sur le testnet Holesky, collecterons les données du générateur de blocs et configurerons le relais via mev-commit. En tant que fournisseur de pré-confirmation de blob, nous invitons les participants concernés de PBS à mener des expériences ensemble.

Introduction

EIP-4844 introduit un marché blob, étendant la disponibilité des données d'Ethereum. Ce marché émergent utilise un mécanisme de tarification du gaz similaire à l’EIP-1559 pour fixer et détruire les frais de base du gaz des blobs. Cependant, contrairement aux transactions de type 2, il n'existe aucun moyen direct pour les utilisateurs du marché des blobs d'enchérir auprès des constructeurs en guise de pourboire pour conditionner leurs blobs. L’absence de conception de frais prioritaires rend difficile la tarification précise des frais d’emballage de blob. De plus, les blocs contenant des blobs devraient être diffusés plus lentement sur le réseau, car les blobs constituent le type de transaction le plus important d'Ethereum. Si un constructeur accepte de nombreux blobs dans un bloc, il est confronté à un risque plus élevé de réorganisation des blocs. Par conséquent, en supposant que le constructeur est une personne économiquement rationnelle, il peut choisir d'examiner les blobs pendant les périodes de pointe afin de maintenir une faible latence pour la construction de blocs.

Nous proposons un effort de création de blocs liés au blob et de collecte de données mev-boost, ainsi qu'une expérience de fournisseur de pré-confirmation de blob utilisant mev-commit, et invitons les rollups, les relais, les constructeurs de blocs et les proposants de la communauté à participer. Nos connaissances sur le comportement lié au blob dans EIP-4844 indiquent que la pré-confirmation du blob L1 peut améliorer l'utilité apportée par le marché du blob, offrir une meilleure expérience de transaction aux utilisateurs L2, fournir une expérience de packaging fiable pour le cumul en présence de conditions mev. , et Fournir un avenir plus stable pour la feuille de route Ethereum centrée sur le cumul.

Comprendre le marché des Blob

Transaction blob

EIP-4844 introduit une transaction de type 3 (également appelée transaction blob). Les transactions transportant des blobs sont similaires aux transactions normales, mais avec l'ajout de données blob, d'engagements KZG et de preuves. Les blobs sont extrêmement volumineux (~ 125 Ko) par rapport aux transactions Ethereum standard et beaucoup moins chers que la quantité équivalente de données d'appel. Les données d'appel sont facturées à 16 gaz par octet non nul et peuvent varier en taille ; les données de blob sont facturées à 1,04 gaz par octet et sont plafonnées à 131 072 gaz par blob.

Mécanisme de gaz Blob

La tarification du gaz de base Blob dispose d’un mécanisme de tarification pour la congestion du réseau, similaire à l’EIP-1559. La principale différence est que le prix du gaz de base blob est basé sur le changement dans l'utilisation du blob, tandis que l'EIP-1559 est basé sur le changement dans l'utilisation du gaz du bloc précédent (la quantité de gaz utilisée par rapport à la quantité de gaz cible). Le nombre de Blobs cibles est de 3 (0,375 Mo) et le nombre maximum de chaque bloc est de 6 (0,75 Mo). Le prix minimum du gaz de base Blob est fixé à 1 wei.

Lors de la soumission d'une transaction blob, l'expéditeur soumettra max_fee_per_blob_gas comme prix maximum qu'il est prêt à payer pour les frais de gaz de base du blob, qui seront tous brûlés. max_fee_per_blob_gas est similaire à max_fee_per_gas dans les transactions de type 0 et de type 2. Si les utilisateurs souhaitent soumettre des frais supplémentaires pour encourager le regroupement de leurs transactions, ils soumettent également max_priority_fee. Cependant, max_priority_fee ne couvre que la partie gaz non-blob de la transaction. En d’autres termes, dans le cadre de ce mécanisme de frais de gaz blob, les utilisateurs ne peuvent pas soumettre directement de conseils sur l’emballage des blob au constructeur.

(Note du traducteur : concernant l'analyse du principe du mécanisme de frais 4844, notre communauté a rédigé un article plus détaillé, voir ici)

Capacité du marché des objets blob

Dans cette section, nous testons l'activité d'interaction historique sur le réseau rollup de janvier 2023 à janvier 2024 pour démontrer la capacité du marché du blob. Nous nous concentrons sur les transactions cumulées les plus actives sur Ethereum et utilisons des données historiques pour simuler un marché blob en temps réel. Bien entendu, ce marché est en croissance active et les blobs ne sont pas encore en ligne sur le réseau principal. Cet article utilise des données historiques tout au long de 2023 pour simuler son potentiel.

Sur la base de l'activité historique des données d'appel du rollup et de la simulation de son utilisation dans l'espace de bloc des transactions de type 3, nous pouvons voir que le prix du marché du blob peut facilement absorber toute la capacité du rollup sans que le prix du marché du blob ne dépasse le minimum du gaz de base du blob. valeur (C'est 1 wei).

Figure : gaz de base par bloc

Bien que le rollup publie davantage de données sur Ethereum, la plupart des blocs sont toujours inférieurs au nombre de blob cible, ce qui garantit que les prix du gaz blob restent bas.

Photo : Le la couleur est plus claire, cela signifie un emballage Plus un bloc d'un nombre spécifique de blobs est construit plus de fois

💡 Cela signifie que la surcharge des données d'appel du marché du blob sera inférieure (les données d'appel consomment 16 gaz par octet, tandis que le blob consomme 1 gaz par octet), et le prix du gaz sera également inférieur (le prix du gaz des données d'appel est de niveau gwei, tandis que blob Le prix du gaz est au niveau wei), économisant ainsi deux couches supplémentaires de coûts pour le cumul.

Non seulement le marché du blob peut facilement absorber les besoins de disponibilité des données du cumul actuel, mais il peut également permettre au marché non-blob de libérer davantage d'espace de bloc et de réduire les frais généraux liés au gaz de plus de 15 à 20 %. La réduction des frais généraux de gaz augmente à son tour le pouvoir d'enchère des utilisateurs/chercheurs, des constructeurs et des validateurs, et débloque de nouvelles opportunités mev qui étaient auparavant exclues de l'EIP-4844.

Figure : EIP-4844 contre blocs standards Impact spatial (basé sur les données 2023)

Le cumul nécessite une plus grande disponibilité des données

Le rollup affecte grandement la consommation de gaz dans le bloc.Il s’agit actuellement du plus grand type d’utilisateur de gaz dans l’espace du bloc Ethereum. En 2023, le rollup a stocké une quantité record de données de transaction sur Ethereum, comme le montre la figure ci-dessous :

Image : données d'appel enregistrées sur Ethereum record

Le graphique moyen quotidien ci-dessous montre que les rollups commencent à occuper plus de 15 % de chaque bloc dans lequel ils se trouvent, affectant directement le prix d'utilisation pour les autres utilisateurs.

Cette situation pourrait s’aggraver en cas de cygne noir et d’augmentation de la demande. Pas plus tard qu'en décembre 2023, l'engouement pour les inscriptions a provoqué un volume de transactions excessif, provoquant la mise hors ligne du séquenceur d'Arbitrum pendant environ une heure. Lorsque le séquenceur Arbitrum a repris ses activités et a commencé à publier l'arriéré des données d'état enregistrées, le séquenceur a immédiatement monopolisé tout l'espace du bloc, provoquant une hausse du prix du gaz à plus de 140 gwei, consommant jusqu'à 90 % du gaz dans tous les blocs, ce qui a fait grimper le prix du gaz à plus de 140 gwei. Le réseau est resté indisponible pour la plupart des utilisateurs pendant plusieurs heures.

**Dans la section suivante, nous discuterons de l'impact que les jeux de timing et la censure peuvent avoir sur ce marché, même en l'absence de cette augmentation de la demande. **

Défis auxquels est confronté le marché du Blob : examen

Diffusion de transactions Blob

EIP-4844 augmente les besoins en bande passante par bloc de balise jusqu'à environ 0,75 Mo, 42 m de gaz, pour accueillir jusqu'à 6 blobs supplémentaires par bloc de balise. Contrairement aux données d'appel, qui sont stockées de manière permanente, les blobs persistent dans les nœuds balises pendant une courte période (18 jours à compter de février 2024) pour garder sous contrôle la croissance de l'état archivé du réseau.

De plus, les transactions blob ont deux représentations de réseau : une transaction blob pour les générateurs de blocs et un side-car blob pour les validateurs. Les side-cars Blob sont conçus pour une compatibilité ascendante.

Le blob doit d’abord être diffusé via la couche d’exécution, puis vers la couche de consensus. **Cela signifie que le constructeur (et non le validateur) a le dernier mot sur l'empaquetage des objets blob. **Les proposants ne peuvent exclure les transactions blob que sous la dynamique mev-boost en fonction de promesses/preuves non valides.

Figure : La vérification de l'exécution est effectuée par le constructeur, la vérification du consensus est effectuée par les validateurs

Point de vue du constructeur de blocs

Des recherches récentes sur les « jeux de timing » des validateurs mettent en évidence comment l’optimisation de la latence peut permettre stratégiquement aux opérateurs de nœuds de maximiser leurs profits en retardant les propositions de blocs. Les auteurs expliquent que cela est préjudiciable à la santé de la chaîne. Les transactions Blob compliquent encore davantage ce jeu en ajoutant des niveaux de latence variables lors de la diffusion du side-car Blob.

Les transactions Blob sont équivalentes au type de taille de transaction la plus grande possible. Pour cette raison, les blocs transportant ces transactions se propagent plus lentement, ce qui rend les constructeurs de blocs moins compétitifs pour remporter les offres mev-boost. En conséquence, cela incite les créateurs de blocs à examiner les blobs temporairement, voire indéfiniment, afin de pouvoir soumettre des offres mev plus fréquemment.

L'équipe Ethpanda utilise Xatu pour tester la latence réelle sur le testnet. Ils ont installé des observateurs dans plusieurs endroits à travers le monde (NYC, FRA, BLR, SYD), en utilisant différents clients de consensus Ethereum (Prysm, Nimbus, Lodestar et Lighthouse) pour mesurer la latence réelle. L'instantané des données Holesky Blob du 20 février 2024 montre qu'une grande quantité de latence est générée tout au long du pipeline mev.

Une fois qu'un constructeur de bloc a remporté une enchère mev-boost, le proposant doit attendre que le side-car blob soit diffusé avant de valider le blob emballé dans le bloc. Le tableau ci-dessous montre qu'avec un échantillon de 800 side-cars blob, la durée minimale d'une diffusion side-car d'un seul blob est d'environ 400 millisecondes.

Graphique 1. Durée de diffusion des blobs par rapport au nombre de blobs contenus dans un seul emplacement

Figure : La petite quantité de les données génèrent des données sur les coûts. Une des raisons pour lesquelles certaines des observations contre-intuitives décrites dans l'ensemble

Le tableau ci-dessous montre la différence de latence lors de l’attente de l’arrivée de nouveaux side-cars blob. Le 50e percentile (p50) du tableau montre que la différence de latence entre un bloc transportant 2 blobs et un bloc transportant 6 blobs est d'environ 225 millisecondes.

Graphique 2. Différence de temps entre le premier side-car blob arrivé et le dernier side-car blob arrivé sur le nombre total de side-cars blob en fonction du regroupement de blocs

Ce type de retard de diffusion du blob donnera aux constructeurs de blocs un risque supplémentaire de réorganisation des blocs lorsqu'ils rempliront leurs propres blocs de blobs pour un gain financier minime. Les constructeurs peuvent choisir d’exclure/censurer les transactions blob pour éviter d’éventuelles réorganisations. Si un bloc contient un grand nombre de mevs, les constructeurs économiquement rationnels doivent compenser de manière appropriée ce risque via le réseau cumulatif.

À propos de l'expérience utilisateur des enchères de packages sur le marché Blob

Dans cet article sur l'étude du jeu de temps du validateur, il est souligné que plus tard dans le processus d'enchères mev-boost, des offres plus importantes sont associées à des blocs plus grands. À mesure que l’offre et le prix du gaz augmentent, une plus grande part de l’ETH sera détruite dans les créneaux suivants. Si les frais de base augmentent, mais que le montant du retrait mev reste le même, le constructeur a moins de marge pour enchérir sur les revenus futurs du proposant.

Note du traducteur :

(Entrée de valeur : MEV + frais de traitement

Sortie de valeur : ETH détruit + PriorityFee du proposant + pourboire du constructeur au proposant + revenus propres du constructeur)

En d'autres termes, si davantage est détruit, moins sera donné au proposant.

Sur le marché attendu du blob, la capacité dépasse la demande actuelle. Les frais de base du blob détruit resteront d’un très petit ordre de grandeur, c’est-à-dire des dizaines ou des centaines de wei. Il est essentiel que les rollups comprennent que leurs transactions blob peuvent ne pas être reportées même si des frais de base suffisants sont payés. Les faibles frais de base du marché du blob signifient que les transactions blob nécessitent des offres plusieurs fois plus élevées pour inciter les constructeurs à regrouper de telles transactions. Dans ce cas, la transaction blob devra être soumise à nouveau moyennant des frais plus élevés, ce qui entraînera une mauvaise expérience utilisateur.

De plus, étant donné que le marché initial du blob sous EIP-4844 ne dispose pas d'un mécanisme de basculement des packages (tel que des frais de gaz prioritaires sur le blob), cela aggrave encore le problème de l'expérience utilisateur, car le rollup ne peut pas directement soumissionner pour concurrencer l'espace dans les transactions blob packagées.

Examinons un exemple de transaction, en supposant que les frais de gaz de base du blob sont de 10 wei, et calculons les frais généraux du blob pour la même quantité de données. Il convient de noter que cet exemple suppose qu’il existe un mécanisme d’enchères de package efficace qui peut enchérir sur l’espace blob.

💡Veuillez consulter l'exemple de transaction :

Calldata - 129 998 octets (129 429 octets différents de zéro) ~ 2 094 140 gaz utilisés à 10,56 gwei (prix de base de 10,55 gwei + frais prioritaires de 0,01 gwei) = 0,022 ETH

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

**Les calculs ont conclu que si les rollups utilisaient le marché du blob, ils pourraient potentiellement soumettre 100 fois plus d'offres en raison des frais de base du blob inférieurs, tout en économisant plus de 150 fois le coût. ** Des frais de base blob inférieurs permettront au cumul de fournir des offres plus compétitives tout en économisant des frais généraux. Les frais d'emballage doivent être aussi compétitifs que les opportunités mev existantes dans le bloc pour indemniser les constructeurs des risques potentiels de restructuration, de sorte que même une offre 100 fois plus élevée pourrait ne pas suffire. Ceci sans pré-validation blob.

Implémenter la pré-confirmation du blob via mev-commit

Dans ce jeu de temps, le rôle principal de la pré-confirmation des blobs est de rendre certains blobs pré-confirmés disponibles sur le pipeline mev. Avec mev-commit, chaque fournisseur de pré-confirmation prend son propre engagement dans la transaction. Les fournisseurs peuvent ensuite déléguer ces données à d'autres acteurs (par exemple des constructeurs de blocs, des relais, des séquenceurs). Les données de pré-confirmation disponibles pour les autres participants au pipeline MEV permettent aux générateurs de blocs d'envoyer des charges d'exécution correspondantes en parallèle. Ce concept peut être exploité pour créer des listes de colisage de blob pré-confirmées, ou pour que les relais collaborent à la construction d'espaces de blocs de type 3.

Étant donné que les blobs préconfirmés sont connus à l’avance, les constructeurs de blocs peuvent créer de futurs blocs contenant des blobs avant le début de leurs emplacements. Cette pratique constitue la base de la tarification et jette les bases de la construction d’un marché à terme solide. Le marché offrira aux rollups une expérience de packaging de transactions plus fiable et rendra les prix des blocs d’espace plus stables. De plus, les enchères pré-confirmées de mev-commit fournissent un mécanisme de découverte de prix plus fiable pour les rollups, car les rollups peuvent mettre à jour leurs offres pré-confirmées en temps réel sans soumettre à nouveau l'intégralité de la transaction blob.

Enfin, le regroupement de blobs et l’utilisation d’enchères de pré-confirmation permettent aux rollups de nouer des alliances. Les enchères de pré-confirmation peuvent être appliquées à des transactions blob groupées ou à des blobs agrégés, permettant aux rollups de partager les capacités d'enchères et l'espace de conditionnement, contribuant ainsi à promouvoir la stabilité et le développement continu du marché des blob Ethereum.

en conclusion

Dans l’ensemble, nos recherches montrent que les aspects économiques du rollup s’améliorent, tandis que l’émergence de nouveaux marchés nécessite la prise en compte de davantage de facteurs, notamment l’impact des jeux de temps et l’absence de mécanisme de basculement. Il est trop tôt pour entrer dans la phase de résolution des problèmes que nous avons soulignés, mais comme mev-commit est déjà activé sur le testnet Holesky, nous pouvons facilement mener des expériences avec des entités comportementales PBS. Primev collectera des données sur l'impact des blobs sur la construction de blocs et la latence des proposants, et espère comprendre les modèles comportementaux sous-jacents.

Alors que l’économie et l’expérience utilisateur sont les principaux moteurs des transactions pré-confirmées de type 2, selon EIP-4844, les rollups et l’expérience de packaging de transactions centrée sur le rollup, la fiabilité et la stabilité de l’écosystème Ethereum deviendront les principaux moteurs des blobs pré-confirmés. raison importante. Nous expérimenterons également un relais de pré-confirmation de blob, qui peut exploiter la pré-confirmation de blob et la coordination du générateur de blocs pour améliorer les problèmes de latence de diffusion du side-car de blob sur le testnet Holesky. Nous invitons la communauté à participer à cette expérience car elle apportera des solutions potentielles à l'ensemble de la communauté.

Les informations pertinentes

EIP-4844 Economics #1 : Mécanisme approfondi de frais EIP-4844

Le coût de la latence artificielle dans le contexte du PBS

Jeux de timing : implications et atténuations possibles

AVANTAGES STRUCTURELS POUR LES CONSTRUCTEURS INTÉGRÉS DANS MEV-BOOST

Poste de jeu de chronométrage du validateur EIP4844

Données historiques du réseau rollup de janvier 2023 à janvier 2024

_block_explorer/tree/master/panel

Qu'est-ce que mev-commit