TL;DR

1. Nossa pesquisa investiga o emergente mercado de blobs EIP-4844, que opera de forma semelhante ao preço do gás EIP-1559, mas carece de um mecanismo direto de gorjeta para o construtor de blocos para a inclusão de blobs, o que pode resultar em uma experiência de tx de blobs pouco confiável e desafios de inclusão.
2. Observamos que, embora as transações de blob sejam grandes (~125 kB) e mais baratas do que o calldata equivalente, elas adicionam um tamanho significativo aos blocos do Ethereum, mas trazem poder de lance incremental para um bloco.
3. Demonstramos que a capacidade deste novo mercado absorve as necessidades atuais de dados de rollup e reduz os custos padrão de gás de espaço de bloco em 15-20%, desbloqueando oportunidades de mev de menor custo.
4. Observamos que transações de blob podem atrasar a propagação de blocos em centenas de milissegundos em momentos de aumento da atividade de rede, o que pode levar os construtores de blocos a censurar blobs para manter lances competitivos em mev-boost.
5. Avaliamos que um "lance pré-confirmação" pode aliviar esses desafios e pré-confirmações em bloco podem aprimorar as capacidades do EIP-4844, oferecendo experiências de transação aprimoradas para usuários de L2 e uma experiência de inclusão estável para rollups.
6. Vamos experimentar na testnet Holesky, coletar dados do construtor de blocos e configurar relés como provedores de pré-configuração de blob usando mev-commit, e convidamos atores da PBS para participar.

Introdução

EIP-4844 expande as capacidades de disponibilidade de dados do Ethereum com a introdução de um mercado de blob. Este mercado nascente utiliza um mecanismo de preço de gás EIP-1559 semelhante para precificar e queimar taxas de gás base de blob. No entanto, ao contrário das transações de tipo2, não há uma maneira direta de licitar por uma dica de construtor para inclusão no mercado de blob. A falta de uma taxa prioritária torna difícil precificar com precisão a inclusão de blob. Além disso, os blocos contendo blob são esperados para se propagar mais lentamente pela rede devido aos blobs sendo algumas das maiores transações do Ethereum em tamanho. Se os construtores aceitarem muitos blobs em um bloco, atualmente enfrentariam um risco aumentado de reorganização de blocos, e um construtor economicamente racional optaria por censurar blobs às vezes para manter a latência de construção de bloco baixa, provavelmente correlacionando com picos de mev.

Apresentamos um esforço de construção de bloco relacionado a blob e coleta de dados de impulso de mev, juntamente com um experimento de provedor de pré-confirmação de blob usandomev-commit, e convidar a comunidade de rollups, relays, construtores de blocos e proponentes para participar. Nossos insights sobre o comportamento relacionado a blob em EIP-4844 sugerem que as preconfirmações de blob da L1 podem aprimorar as capacidades do mercado de blob para fornecer uma melhor experiência de transação para usuários de L2, inclusão confiável para rollups sob condições emergentes de mev e um futuro mais estável centrado em rollup para o Ethereum.

Compreendendo o Mercado Blob

Transações de Blobs

EIP-4844introduz um tipo de transação tx chamado blob tx. Uma tx que carrega um blob é como uma transação regular, mas aprimorada com dados de blob, compromissos KZG e provas. Os blobs são extremamente grandes (~125 kB) em comparação com as txs padrão do Ethereum e são muito mais baratos do que uma quantidade equivalente de calldata. Enquanto a calldata é precificada a 16 gas por byte não zero e pode ter tamanho variável, os dados de blob são precificados a 1.04 gas por byte e possuem um tamanho fixo de 131,072 gás.

Mecânica de Gás Blob

Preços de gás baseados em Blobtem um mecanismo de taxa de congestionamento semelhante ao EIP-1559. A diferença principal é que o gas blob é uma contagem de blob alvo, enquanto o EIP-1559 é baseado na utilização alvo de gas. A contagem de blob alvo é 3 (0,375 MB), e o máximo é 6 (0,75 MB) por bloco. O gas base mínimo do blob é definido em 1 wei.

Ao enviar uma transação de blob, o remetente enviará um max_fee_per_blob_gas como o preço mais alto que estão dispostos a pagar pela taxa de gás básica do blob, que é totalmente queimada. O max_fee_per_blob_gas é semelhante ao max_fee_per_gas em transações do tipo0 e tipo2. Se o usuário desejar enviar uma taxa adicional para incentivar a inclusão, então também enviariam um max_priority_fee. No entanto, o max_priority_fee cobre apenas a parte da transação que não é de gás de blob. Isso não deixa uma maneira direta de enviar uma gorjeta de inclusão para o construtor.

Capacidade de Mercado de Blob

Nesta seção, nós realizar um backtestsobre a atividade histórica de rollup de janeiro de 2023 a janeiro de 2024 para demonstrar a capacidade do mercado de blob. Nós nos concentramos em txs dos rollups mais ativos na Ethereum e usamos os dados históricos para simular um mercado de blob ao vivo. Embora esse mercado esteja crescendo ativamente e ainda não esteja na mainnet, usamos dados históricosdo ano inteiro de 2023 para simular seu potencial.

Com base na atividade histórica de chamada de dados de rollup usada no espaço de bloco tx tipo3, vemos que o preço de mercado do blob pode absorver confortavelmente toda a capacidade de rollup sem mover o preço de mercado do blob além do mínimo de gás base do blob.

base blob gás por bloco

Embora os rollups estejam enviando mais dados para o Ethereum, a maioria dos blocos ainda está abaixo da meta, o que garante que o preço do gás blob permaneça baixo.

A cor mais clara indica um número maior de vezes que um bloco seria construído com um certo número de blocos incluídos.

💡 As implicações são que, além do custo dos dados de chamada ser menor no mercado de blob (fator de 16), o preço do gás também será muito mais barato (wei vs gwei), o que se traduz em duas camadas de economia de custos adicionais para rollups.

Não apenas o mercado de blob pode absorver confortavelmente as necessidades atuais de disponibilidade de dados de rollup, ele também libera espaço de bloco no mercado não blob, reduzindo os custos de gás em até 15-20%. A redução dos custos de gás aumenta proporcionalmente as capacidades de licitação para usuários/pesquisadores, construtores e validadores, e desbloqueia novas oportunidades de mev que estavam fora do alcance antes do EIP 4844.

Efeito do EIP 4844 no uso padrão do espaço de bloco usando dados de 2023.

Rollups Demand Mais Disponibilidade de Dados

Os rollups têm uma influência significativa na quantidade de gás usada em blocos, e são a maior classe de usuários de gás do espaço de bloco Ethereum hoje. Em 2023, os rollups armazenaram quantidades recordes de dados de transação no Ethereum, conforme mostramos abaixo:

Os dados salvos no Ethereum estão em máximos históricos.

Os gráficos médios diários abaixo mostram que os rollups estão começando a ocupar mais de 15% de cada bloco em que estão, afetando diretamente o preço para outros usuários.

Isso pode ser ainda mais exacerbado em situações de demanda cisne negro. Recentemente, em dezembro de 2023, o spam de inscrição tirou o sequenciador Arbitrum offlinepor cerca de uma hora devido à quantidade avassaladora de transações. À medida que o sequenciador Arbitrum retomava as operações e começava a postar o backlog dos estados salvos, o sequenciador monopolizava o espaço do bloco, causando preços do gás devem disparar acima de 140 gwei e consumir mais de 90% do gásem blocos inteiros, tornando a rede inutilizável para a maioria dos usuários por várias horas.

Na próxima seção, vamos explicar como os jogos de tempo e a censura provavelmente afetarão esse mercado mesmo na ausência de picos de demanda.

Desafios do Mercado Blob: Censura

Propagação de Blob

A EIP-4844 aumenta os requisitos de largura de banda por bloco de farol em um máximo de ~0,75 MB, 42m gas para acomodar até 6 blobs adicionais em cada bloco de farol. Ao contrário de calldata, que é armazenado para sempre, os blobs são persistidos em nós de farol por um curto período de tempo (18 dias a partir de fevereiro de 2024) para manter o crescimento do estado do arquivo de rede gerenciável.

Além disso, transações de blob têm duas representações de rede - para o construtor de bloco como uma tx de blob e para o validador como um sidecar de blob. O sidecar de blob existe para compatibilidade futurafins.

Os blobs primeiro devem se propagar através da camada de execução antes de passar pela camada de consenso. Isso significa que os construtores, não validadores, têm a palavra final sobreinclusão de blob. Os proponentes só podem excluir transações de blob com base no compromisso ou na invalidade da prova sob a dinâmica de impulso mev.

A verificação de execução é feita pelos construtores. A verificação de consenso é feita pelos validadores.

A Perspectiva do Construtor de Blocos

Pesquisa recente em jogos de cronometragem de validaçãodestaca que a otimização da latência pode beneficiar estrategicamente os operadores de nós para maximizar os lucros ao atrasar as propostas de bloco. Os autores explicam que isso é prejudicial à saúde da cadeia. As transações de blob complicam ainda mais os jogos de tempo ao adicionar uma quantidade variável de latência quando o blob sidecar propaga.

As transações do Blob são equivalentes aos tamanhos de transação possíveis. Como resultado, os blocos contendo essas transações podem se propagar mais lentamente, tornando os construtores de bloco menos competitivo em ganhar lances de impulso de mev. Como resultado, isso incentiva os construtores de blocos a censurar temporariamente ou até indefinidamente os blocos para que possam enviar lances de mev com frequência mais alta.

O EtpandaA equipe tem realizado testes de latência do mundo real nas testnets usando@ethpandaops/xatu-overview">Xatu. Sentinelas são colocadas nas regiões de NYC, FRA, BLR e SYD para representar medidas reais de latência usando os clientes de consenso Prysm, Nimbus, Lodestar e Lighthouse. Um instantâneo de dados com dados de blob Holesky em 20 de fevereiro de 2024 indica uma quantidade não trivial de latência incorrida ao longo do pipeline mev.

Após o construtor de blocos vencer o leilão de impulso mev, o proponente deve esperar que os sidecars do blob se propaguem antes de poder verificar os blobs incluídos no bloco. A tabela abaixo mostra que o tempo mínimo para um único sidecar de blob se propagar é de ~400ms em uma amostra de ~800 sidecars de blob.

Tabela 1. Propagação de blob versus número de blobs para slot

O tamanho pequeno dos dados contribui para algumas das observações contraintuitivas representadas neste conjunto de dados

A próxima tabela mostra as variações de latência ao esperar por mais sidecars de blob chegarem. O percentil 50 (p50) indica que a variação de latência entre um bloco de 2 blobs e um bloco de 6 blobs é de aproximadamente 225ms.

Tabela 2. Diferença de tempo entre o primeiro e o último sidecar do blob agrupado pelo número total de sidecars do blob no bloco

Essa latência de propagação de blob coloca um risco adicional de reorganização de bloco nos construtores de bloco, à medida que eles preenchem seus blocos com blobs, com pouco ganho econômico. O construtor pode optar por excluir/censurar a transação de blob para evitar uma reorganização potencial. Se um bloco contém muito mev, os construtores economicamente racionais precisariam ser compensados apropriadamente pelos rollups por esse risco.

Na Inclusão de Licitação de Mercado de Bolhas UX

O pesquisa de jogos de temporização do validadoraponta que lances maiores estão correlacionados com blocos de tamanhos maiores mais tarde no processo de lances de impulso de mev. À medida que os lances e o preço do gás aumentam, uma parcela maior de ETH é queimada nos slots subsequentes. Se a taxa base aumentar enquanto a extração de mev permanecer constante, os construtores terão menos para oferecer em direção à renda futura de um proponente.

No mercado de blob esperado, onde a capacidade excede a demanda atual, a taxa base de blob que é queimada permanecerá muito pequena, na faixa de dezenas ou centenas de wei. Torna-se essencial para os rollups reconhecerem que suas transações de blob podem não ser incluídas, apesar de pagar a taxa base suficiente. O mercado de blob de baixa taxa base implica que os blobs precisarão oferecer muitas vezes mais para incentivar os construtores a incluir as transações. Nesses casos, a transação de blob terá que ser reenviada com uma taxa aumentada, resultando em uma experiência do usuário ruim.

Além disso, uma vez que o mercado inicial de blob sob o EIP-4844 não terá um mecanismo de gorjeta de inclusão (por exemplo, uma taxa de gás de prioridade de blob), isso agrava ainda mais a questão de UX porque o rollup não pode licitar diretamente na transação de blob.

Vamos analisar um exemplo de transação e calcular o custo equivalente de blob assumindo um custo base de gás de blob de 10 wei. Observe que este exemplo pressupõe que existe um mecanismo eficaz de licitação de inclusão no local para poder licitar no espaço de blob em primeiro lugar.

💡Aqui está uma transação de amostra:

Calldata - 129,998 bytes (129429 bytes diferentes de zero) ~ 2,094,140 de gás usado a 10,56 gwei (preço base de 10,55 gwei + taxa de prioridade de .01 gwei) = .022 ETH

Blob - 128,000 bytes ~ 131,072 gas used at 1 gwei (10 wei base price + .99999999 gwei priority fee) = 0.000131072 ETH

O cálculo conclui que, se os rollups usarem o mercado de blob, eles podem enviar um lance potencialmente 100 vezes maior devido à taxa de base de blob mais baixa, enquanto ainda economizam mais de 150 vezes o custo. A taxa de base de blob mais baixa permitirá que os rollups ofereçam lances de inclusão mais competitivos, enquanto ainda economizam nos custos. A taxa de inclusão precisará ser tão competitiva quanto as oportunidades de mev existentes no bloco para compensar o risco potencial de reorganização do construtor, e assim, mesmo fazer um lance 100 vezes maior pode não ser suficiente. Ou seja, na ausência de pré-confirmações de blob.

Pré-confirmações de Blob com mev-commit

Sob tais jogos de temporização, o papel principal de uma pré-confirmação de blob torna-se fazer uma lista de blobs que um provedor pré-confirmou disponível em todo o pipeline de mev. No mev-commit, cada provedor pré-confirma emite seus próprios compromissos para txs. O provedor pode então dar acesso a esses dados a outros (por exemplo, construtores de blocos, relés, sequenciadores). A disponibilidade de dados da lista de pré-confirmação para outros atores em todo o pipeline de mev permite que a carga de execução correspondente seja enviada em paralelo por um construtor de blocos. Essa noção pode ser aproveitada para criar listas de inclusão de blobs pré-conf'd, ou ter o espaço de bloco do tipo3 construído colaborativamente por um relé.

Com o conhecimento avançado de blobs pré-confirmados, os construtores de blocos podem começar a construir blocos futuros com blobs antes do início de seu slot. Isso cria uma base de preços e lança as bases para um mercado futuro robusto que dá aos rollups uma inclusão mais confiável e estabilidade de preços de espaço de bloco. Além disso, os lances pré-conf de mev-commit dão aos rollups um mecanismo de descoberta de preços mais confiável porque os rollups podem atualizar seus lances pré-conf em tempo real sem precisar reenviar toda a transação de blob.

Finalmente, agrupar blobs e usar uma oferta predefinida permite que os rollups construam alianças. As ofertas predefinidas podem ser aplicadas a pacotes de transações de blobs ou blobs agregados, permitindo que os rollups compartilhem seu poder de oferta e inclusão com outros rollups, ajudando a estabilizar e expandir o mercado de blobs do Ethereum.

Conclusão

No geral, mostramos que a economia para rollups está melhorando, enquanto um novo mercado surge com considerações adicionais que variam de jogos de tempo à falta de um mecanismo de gorjeta. Embora seja muito cedo para passar para a fase de solução dos problemas que destacamos, podemos facilmente experimentar isso com os atores do PBS, uma vez que o mev-commit está ativo na testnet de Holesky. Primev estará coletando dados sobre os efeitos do blob na construção de blocos e na latência do proponente, e esperamos obter insights sobre possíveis padrões comportamentais.

Enquanto a economia e a UX são os principais impulsionadores para transações do tipo2 de preconf; parece que a inclusão, a confiabilidade e a estabilidade do rollup e do ecossistema centrado no rollup se tornarão razões importantes para blobs de preconf sob EIP-4844. Também estaremos experimentando com um relé de preconf de blob que pode alavancar preconfs de blob e coordenação de construção de bloco para melhorar a propagação de latência de sidecar de blob na testnet Holesky. Convidamos a comunidade a se aproximar e participar deste experimento, pois informará uma solução potencial para toda a comunidade.

Aviso Legal：

1. Este artigo foi reproduzido de [espelho], Encaminhe o Título Original 'Censura, Latência e Pré-confirmações no Mercado de Blob', Todos os direitos autorais pertencem ao autor original [Primev]. Se houver objeções a esta reimpressão, entre em contato com o Porta Aprenderequipe e eles vão lidar com isso prontamente.

2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.

3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.