Na véspera da atualização do Ethereum Cancun, obtenha uma visão abrangente do mercado Blob

Artigo: 0xEvan, Primev

Traduzido por: Franci, Espaço de Pesquisa ETHconomics

Revisão: Jason, ETHconomics Research Space

Introdução do Tradutor

Os artigos anteriores que publicamos foram todos relacionados à transação de blob em si e ao mecanismo de taxas 4844. Neste artigo, o autor usou backtesting de dados no ano passado para simular o potencial do mercado de blob - quantos dados ele pode acomodar? Ele pode atender aos requisitos de disponibilidade de dados do rollup?

Além do impacto da curva de oferta e demanda do espaço blob no mercado de blob, os jogos de cronometragem dos validadores e a revisão dos construtores também terão alguns efeitos negativos neste mercado. Este artigo realiza análise de dados sobre o possível atraso na transmissão de transações de blob, demonstra seu impacto na experiência do usuário e na sobrecarga de disponibilidade de dados de rollup e também propõe uma solução possível: pré-confirmar transações de blob.

Em geral, este artigo é uma análise relativamente abrangente do mercado de blobs. Os leitores podem explorar o cenário futuro do espaço de blobs através do contexto do artigo.

texto:

🙏Agradecimentos especiais a @terencechain pela revisão, @BertKellerman pelos insights e @ethpandaops pelos dados holesky testnet.

###TL;DR

Nossa pesquisa se aprofunda no mercado emergente de blob EIP-4844, que opera de forma semelhante ao preço do gás EIP-1559. A diferença é que ele não possui um mecanismo de gorjeta diretamente para os construtores de blocos para incentivá-los a empacotar transações de blob, o que pode levar a uma experiência de transação de blob instável e a certos desafios para que sejam empacotadas em blocos.
Observamos que, embora as transações de blob sejam grandes (~125 kB) e mais baratas que calldata do mesmo tamanho, elas aumentam significativamente o tamanho do bloco Ethereum. Isso também significa que as transações de blob trazem poder de lance incremental aos blocos.
Demonstramos que a capacidade deste novo mercado pode absorver as atuais necessidades de dados acumulados e reduzir o custo do gás do espaço de bloco padrão em 15-20%, abrindo assim oportunidades de mev de baixo custo.
Observamos que durante períodos de maior atividade de rede, as transações de blob podem desacelerar as transmissões de bloco na ordem de centenas de milissegundos, o que pode levar à censura dos construtores de bloco, a fim de manter lances competitivos no blob mev-boost.
Avaliamos que os "lances pré-confirmados" podem aliviar esses desafios, e a pré-confirmação do blob pode aprimorar os recursos do EIP-4844, fornecer uma melhor experiência de transação para usuários L2 e fornecer uma experiência estável de empacotamento de transações para rollups.
Conduziremos experimentos na rede de teste Holesky, coletaremos dados do construtor de blocos e configuraremos a retransmissão por meio de mev-commit. Como provedor de pré-confirmação de blob, convidamos participantes relevantes da PBS para conduzir experimentos juntos.

Introdução

EIP-4844 introduz um mercado de blob, ampliando a disponibilidade de dados do Ethereum. Este mercado emergente utiliza um mecanismo de precificação de gás semelhante ao EIP-1559 para precificar e destruir a taxa básica de gás dos blobs. No entanto, ao contrário das transações do tipo 2, não existe uma maneira direta de os usuários no mercado de blob fazerem ofertas aos construtores como uma dica para empacotar seus blobs. A falta de um design de taxa prioritária torna difícil definir com precisão o preço das taxas de embalagem blob. Além disso, espera-se que os blocos que transportam blobs sejam transmitidos mais lentamente pela rede porque os blobs são os maiores tipos de transação do Ethereum. Se um construtor aceitar muitos blobs em um bloco, ele enfrentará um risco maior de reorganização do bloco, portanto, supondo que o construtor seja uma pessoa economicamente racional, ele poderá optar por revisar os blobs durante os períodos de pico de mev para manter baixa latência para a construção do bloco.

Propomos um esforço de construção de bloco relacionado a blob e coleta de dados mev-boost, bem como um experimento de provedor de pré-confirmação de blob usando mev-commit, e convidamos rollups, retransmissores, construtores de bloco e proponentes da comunidade para participar. Nossos insights sobre o comportamento relacionado ao blob no EIP-4844 indicam que a pré-confirmação do blob L1 pode aprimorar a utilidade trazida pelo mercado de blob, fornecer uma melhor experiência de transação para usuários L2, fornecer uma experiência de empacotamento confiável para rollup na presença de condições mev e fornecer um futuro mais estável para o roteiro Ethereum centrado em rollup.

Compreendendo o mercado de blobs

Transação de blob

EIP-4844 introduz uma transação type3 (também conhecida como transação blob). As transações que transportam blobs são semelhantes às transações regulares, mas com a adição de dados de blob, compromissos KZG e provas. Os blobs são extremamente grandes (~125 kB) em comparação com as transações padrão do Ethereum e muito mais baratos do que a quantidade equivalente de calldata. Calldata custa 16 gas por byte diferente de zero e pode variar em tamanho; os dados de blob custam 1,04 gas por byte e são limitados a 131.072 gas por blob.

Mecanismo de Gás Blob

O preço base do gás blob tem um mecanismo de taxas para precificar o congestionamento da rede, semelhante ao EIP-1559. A principal diferença é que o preço do gás base do blob é baseado na mudança no uso do blob, enquanto o EIP-1559 é baseado na mudança na utilização do gás do bloco anterior (a quantidade de gás usada em relação à quantidade de gás alvo). O número de Target Blobs é 3 (0,375 MB) e o número máximo de cada bloco é 6 (0,75 MB). O preço base mínimo do gás Blob é definido como 1 wei.

Ao enviar uma transação de blob, o remetente enviará max_fee_per_blob_gas como o preço máximo que está disposto a pagar pela taxa base de gás do blob, e todos serão queimados. max_fee_per_blob_gas é semelhante a max_fee_per_gas em transações type0 e type2. Se os usuários quiserem enviar taxas adicionais para incentivar o empacotamento de suas transações, eles também enviarão max_priority_fee. No entanto, max_priority_fee cobre apenas a parte não-blob gas da transação. Em outras palavras, sob esse mecanismo de taxa de blob gas, os usuários não podem enviar dicas de empacotamento de blob diretamente ao construtor.

(Nota do tradutor: Em relação à análise do princípio do mecanismo de taxas 4844, nossa comunidade escreveu um artigo mais detalhado, veja aqui)

Capacidade do mercado de blobs

Nesta seção, testamos a atividade histórica de interação na rede rollup de janeiro de 2023 a janeiro de 2024 para demonstrar a capacidade do mercado de blob. Nós nos concentramos nas transações de rollup mais ativas no Ethereum e usamos dados históricos para simular um mercado blob em tempo real. É claro que este mercado está crescendo ativamente e os blobs ainda não estão online na rede principal. Este artigo usa dados históricos ao longo de 2023 para simular seu potencial.

Com base na atividade histórica de dados de chamada de rollup e simulando seu uso no espaço de bloco de transações do tipo 3, podemos ver que o preço de mercado do blob pode facilmente absorver toda a capacidade do rollup sem fazer com que o preço de mercado do blob exceda o mínimo do gás base do blob valor (Isso é 1 wei).

Figura: gás blob base por bloquear

Embora o rollup publique mais dados para Ethereum, a maioria dos blocos ainda está abaixo do número alvo do blob, o que garante que os preços do gás do blob permaneçam baixos.

Foto: O mais clara a cor, representa a embalagem Quanto mais vezes um bloco de um número específico de blobs é construído

💡 Isso significa que a sobrecarga de calldata do mercado de blob será menor (calldata consome 16 gas por byte, enquanto blob consome 1 gas por byte), e o preço do gas também será menor (o preço do gas de calldata é do nível gwei, enquanto blob O preço do gás está no nível wei), economizando assim duas camadas adicionais de custos para rollup.

O mercado de blob não só pode absorver facilmente as necessidades de disponibilidade de dados do rollup atual, como também pode permitir que o mercado não-blob libere mais espaço de bloco e reduza a sobrecarga de gás em mais de 15-20%. A redução nas despesas gerais de gás, por sua vez, aumenta o poder de licitação dos usuários/pesquisadores, construtores e validadores, e desbloqueia novas oportunidades de mev que anteriormente estavam fora do preço do EIP-4844.

Figura: EIP-4844 versus blocos padrão Impacto espacial (com base em dados de 2023)

O rollup requer mais disponibilidade de dados

Rollup afeta muito o uso de gás no bloco. Eles são atualmente o maior tipo de usuário de gás no espaço do bloco Ethereum. Em 2023, o rollup armazenou uma quantidade recorde de dados de transações no Ethereum, conforme mostrado na figura abaixo:

Imagem: calldata salvo no Ethereum recorde

O gráfico de média diária abaixo mostra que os rollups estão começando a ocupar mais de 15% de cada bloco em que estão, afetando diretamente o preço de uso dos demais usuários.

Isto pode piorar no caso de um cisne negro e de um aumento da procura. Ainda em dezembro de 2023, a mania das inscrições causou um volume excessivo de transações, fazendo com que o sequenciador do Arbitrum ficasse offline por cerca de uma hora. Quando o sequenciador Arbitrum retomou as operações e começou a publicar o backlog de dados de estado salvos, o sequenciador imediatamente monopolizou todo o espaço do bloco, fazendo com que o preço do gás subisse para mais de 140 gwei, consumindo até 90% do gás em todos os blocos, tornando A rede ficou indisponível para a maioria dos usuários por várias horas.

**Na próxima seção, discutiremos como os jogos de cronometragem e a censura podem impactar esse mercado mesmo na ausência desse aumento na demanda. **

Desafios enfrentados pelo mercado de Blob: revisão

Transmissão de transação de blob

O EIP-4844 aumenta os requisitos de largura de banda por bloco de beacon em até ~0,75 MB, 42m de gás, para acomodar até 6 blobs adicionais por bloco de beacon. Ao contrário dos calldata, que são armazenados permanentemente, os blobs persistem em nós beacon por um curto período de tempo (18 dias a partir de fevereiro de 2024) para manter o crescimento do estado arquivado da rede sob controle.

Além disso, as transações de blob têm duas representações de rede: uma transação de blob para construtores de blocos e um arquivo secundário de blob para validadores. Os sidecars de blob são projetados para compatibilidade futura.

O blob deve primeiro ser transmitido através da camada de execução e depois para a camada de consenso. **Isso significa que o construtor (não o validador) tem a palavra final sobre o empacotamento do blob. **Os proponentes só podem excluir transações de blob sob dinâmica mev-boost com base em promessas/provas inválidas.

Figura: A verificação de execução é realizada pelo construtor, a verificação do consenso é realizada por validadores

Perspectiva do Block Builder

Pesquisas recentes sobre “jogos de tempo” de validadores destacam como a otimização da latência pode permitir estrategicamente que os operadores de nós maximizem os lucros atrasando propostas de blocos. Os autores explicam que isso é prejudicial à saúde da cadeia. As transações de blob complicam ainda mais esse jogo, adicionando quantidades variadas de latência quando o sidecar do blob é transmitido.

As transações de blob são equivalentes ao maior tipo de tamanho de transação possível. Por esse motivo, os blocos que transportam essas transações se propagam mais lentamente, tornando os construtores de blocos menos competitivos na vitória de lances de aumento de mev. Como resultado, isso incentiva os construtores de blocos a revisar os blobs temporariamente ou mesmo indefinidamente para que possam enviar lances mev com maior frequência.

A equipe ethpanda tem usado o Xatu para testar a latência do mundo real na testnet. Eles configuraram observadores em vários locais ao redor do mundo (NYC, FRA, BLR, SYD), usando diferentes clientes de consenso Ethereum (Prysm, Nimbus, Lodestar e Lighthouse) para medir a latência do mundo real. O instantâneo de dados do Holesky Blob de 20 de fevereiro de 2024 mostra que uma grande quantidade de latência é gerada em todo o pipeline mev.

Depois que um construtor de bloco vence um leilão de lance mev-boost, o proponente deve aguardar a transmissão do sidecar do blob antes de validar o blob empacotado no bloco. A tabela abaixo mostra que, com um tamanho de amostra de 800 sidecars de blob, o tempo mínimo para uma transmissão de sidecar de blob único é de aproximadamente 400 milissegundos

Gráfico 1. Tempo de transmissão do blob versus número de blobs contidos em um único slot

Figura: A pequena quantidade de dados resultam em dados de custo Uma razão para algumas das observações contra-intuitivas descritas no conjunto

A tabela abaixo mostra a diferença na latência ao aguardar a chegada de mais sidecars de blob. O 50º percentil (p50) na tabela mostra que a diferença na latência entre um bloco que transporta 2 blobs e um bloco que transporta 6 blobs é de cerca de 225 milissegundos.

Gráfico 2. Diferença de tempo entre o primeiro sidecar de blob que chega e o último que chega em relação ao número total de sidecars de blob com base no agrupamento de blocos

Esse tipo de atraso na transmissão do blob dará aos construtores de bloco um risco adicional de reorganização de bloco quando preencherem seus próprios blocos com blobs com pouco ganho financeiro. Os construtores podem optar por excluir/censurar transações de blob para evitar possíveis reorganizações. Se um bloco contém um grande número de mevs, os construtores economicamente racionais precisam compensar adequadamente esse risco através da rede rollup.

Sobre a experiência do usuário em lances de pacotes no mercado Blob

Neste artigo sobre o estudo do jogo do tempo do validador, aponta-se que posteriormente no processo de licitação mev-boost, lances maiores estão associados a blocos maiores. À medida que a oferta e o preço do gás aumentam, uma parcela maior da ETH será destruída nos slots subsequentes. Se a taxa base aumentar, mas o valor do saque mev permanecer o mesmo, o construtor terá menos espaço para fazer lances sobre a receita futura do proponente.

Nota do tradutor:

(Entrada de valor: MEV + taxa de movimentação

Saída de valor: ETH destruído + PriorityFee do proponente + gorjeta do construtor ao proponente + renda própria do construtor)

Em outras palavras, se mais for destruído, menos será dado ao proponente.

No mercado blob esperado, a capacidade excede a procura actual. A taxa base do blob destruído permanecerá em uma ordem de magnitude muito pequena, ou seja, dezenas ou centenas de wei. É fundamental que os rollups compreendam que as suas transações blob podem não ser roladas mesmo que sejam pagas taxas base suficientes. A baixa taxa básica do mercado de blob significa que as transações de blob exigem lances muitas vezes mais altos para incentivar os construtores a empacotar tais transações. Nesse caso, a transação do blob terá que ser reenviada por uma taxa mais alta, resultando em uma experiência ruim para o usuário.

Além disso, como o mercado inicial de blobs sob EIP-4844 não possui um mecanismo de gorjeta de pacote (como uma taxa de gás prioritária de blob), isso agrava ainda mais o problema da experiência do usuário porque o rollup não pode licitar diretamente para competir por espaço em transações de blob empacotadas.

Vejamos um exemplo de transação, assumindo que a taxa básica de gás do blob é de 10 wei, e calculemos a sobrecarga do blob para a mesma quantidade de dados. Deve-se notar que este exemplo pressupõe que existe um mecanismo eficaz de licitação de pacotes que pode licitar por espaço de blob.

💡Veja o exemplo de transação:

Calldata - 129.998 bytes (129.429 bytes diferentes de zero) ~ 2.094.140 gás usado a 10,56 gwei (preço base de 10,55 gwei + taxa de prioridade de 0,01 gwei) = 0,022 ETH

Blob-128.000 bytes ~ 131.072 gás usado em 1gwei (10weibase price + 0,99999999gweipriorityfee) = 0,000131072ETH

**Os cálculos concluíram que, se os rollups usassem o mercado de blob, poderiam potencialmente enviar 100 vezes mais propostas devido à taxa base de blob mais baixa, ao mesmo tempo que economizavam mais de 150 vezes o custo. **Uma taxa base de blob mais baixa permitirá que o rollup forneça lances mais competitivos e, ao mesmo tempo, economize despesas gerais. As taxas de embalagem têm de ser tão competitivas quanto as oportunidades de mev existentes no bloco para compensar os construtores por potenciais riscos de reestruturação, pelo que mesmo uma proposta 100 vezes superior pode não ser suficiente. Isso ocorre sem pré-validação de blob.

Implementar pré-confirmação de blob por meio de mev-commit

Neste jogo de tempo, a principal função da pré-confirmação de blob é disponibilizar alguns blobs pré-confirmados no pipeline mev. Com o mev-commit, cada provedor de pré-confirmação assume seu próprio compromisso com a transação. Os provedores podem então delegar esses dados a outros atores (por exemplo, construtores de blocos, retransmissores, sequenciadores). Os dados de pré-confirmação disponíveis para outros participantes no pipeline MEV permitem que os construtores de blocos enviem cargas de execução correspondentes em paralelo. Este conceito pode ser explorado para criar listas de empacotamento de blob pré-confirmadas ou para que relés colaborem na construção de espaços de bloco tipo 3.

Como os blobs pré-confirmados são conhecidos antecipadamente, os construtores de blocos podem construir blocos futuros carregando blobs antes do início de seus slots. Esta prática fornece a base para a precificação e estabelece as bases para a construção de um mercado futuro forte. O mercado fornecerá aos rollups uma experiência de empacotamento de transações mais confiável e tornará os preços dos espaços em bloco mais estáveis. Além disso, os lances pré-confirmados do mev-commit fornecem um mecanismo de descoberta de preços mais confiável para rollups, já que os rollups podem atualizar seus lances pré-confirmados em tempo real sem reenviar toda a transação do blob.

Por fim, agrupar blobs e usar lances de pré-confirmação permite que os rollups construam alianças. Os lances de pré-confirmação podem ser aplicados a transações de blobs agrupados ou blobs agregados, permitindo que os rollups compartilhem recursos de lances e espaço de empacotamento, ajudando a promover a estabilidade e o desenvolvimento contínuo do mercado de blobs Ethereum.

para concluir

Globalmente, a nossa investigação mostra que a economia do rollup está a melhorar, enquanto o surgimento de novos mercados exige que sejam considerados mais factores, incluindo o impacto dos jogos de tempo e a falta de um mecanismo de inclinação. É muito cedo para entrar na fase de solução dos problemas que destacamos, mas como o mev-commit já está ativado na testnet Holesky, podemos facilmente realizar experimentos com entidades comportamentais do PBS. Primev coletará dados sobre o impacto dos blobs na construção de blocos e na latência do proponente, e espera compreender os padrões comportamentais subjacentes.

Embora a economia e a experiência do usuário sejam os principais impulsionadores para transações pré-confirmadas do Tipo 2, sob EIP-4844, os rollups e a experiência de empacotamento de transações centradas em rollup, a confiabilidade e a estabilidade do ecossistema Ethereum se tornarão os principais impulsionadores para blobs pré-confirmados. motivo importante. Também experimentaremos um relé de pré-confirmação de blob, que pode aproveitar a pré-confirmação de blob e a coordenação do construtor de blocos para melhorar os problemas de latência de transmissão do sidecar de blob na rede de teste Holesky. Convidamos a comunidade a participar nesta experiência, pois irá fornecer soluções potenciais para toda a comunidade.