TL;DR

1. Nossa pesquisa explora o emergente mercado de blob EIP-4844, que opera de forma semelhante à fixação de preços de gás EIP-1559, mas carece de um mecanismo direto de gorjeta para o construtor de blocos para a inclusão de blob, o que pode resultar em uma experiência de tx de blob não 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 os dados de chamada equivalentes, elas adicionam um tamanho significativo aos blocos do Ethereum, mas trazem um poder de licitação 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 no espaço de bloco em 15-20%, desbloqueando oportunidades de mev de custo mais baixo.
4. Observamos que as transações de blob arriscam atrasar a propagação do bloco por centenas de milissegundos em tempos de atividade de rede aumentada, o que pode levar os construtores de bloco a censurar os blobs para manter licitações competitivas em mev-boost.
5. Avaliamos que um "preconf bid" pode aliviar esses desafios e os preconfs de blob podem melhorar as capacidades do EIP-4844, oferecendo experiências de transação aprimoradas para os usuários da L2 e uma experiência de inclusão estável para os rollups.
6. Vamos experimentar na testnet Holesky, recolher dados do construtor de blocos e configurar relés como fornecedores de pré-configuração de blobs usando mev-commit, e convidamos atores da PBS para participar.

Introdução

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

Propusemos um esforço de construção de blocos relacionados com blobs e de recolha de dados de impulso de MEV, juntamente com uma experiência de fornecedor de pré-confirmação de blobs usando mev-commit, e convidar a comunidade de rollups, relays, construtores de blocos e proponentes para participar. As nossas perspetivas sobre o comportamento relacionado com blob em EIP-4844 sugerem que as pré-confirmações de blob L1 podem melhorar as capacidades do mercado de blob para proporcionar uma melhor experiência de transação para os utilizadores L2, inclusão fiável para rollups em condições mev emergentes e um futuro mais estável centrado em rollup para Ethereum.

Compreender o Mercado Blob

Transações de Blob

EIP-4844introduz um tipo de transação tipo3 (tx) chamada tx de blob. Uma tx que carrega um blob é como uma transação regular, mas melhorada com dados de blob, compromissos KZG e provas. Os blobs são extremamente grandes (~125 kB) em comparação com as txs Ethereum padrão e são muito mais baratos do que uma quantidade equivalente de calldata. Enquanto o calldata tem um preço de 16 gas por byte não-zero e pode ter um tamanho variável, os dados de blob têm um preço de 1,04 gas por byte e um tamanho fixo de 131,072 gas.

Mecânica de Gás de Blob

Preços base de gás Blobtem um mecanismo de taxa de congestionamento semelhante ao EIP-1559. A diferença principal é que o gas blob é um contagem de blobs de destino, enquanto o EIP-1559 é baseado na utilização de gas de destino. A contagem de blobs de destino é 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.

Quando uma transação de blob é submetida, o remetente irá submeter um max_fee_per_blob_gas como o preço mais alto que estão dispostos a pagar pela taxa base de gás de blob, tudo o que é queimado. O max_fee_per_blob_gas é semelhante ao max_fee_per_gas em transações tipo0 e tipo2. Se o usuário quisesse submeter uma taxa adicional para incentivar a inclusão, então eles também submeteriam um max_priority_fee. No entanto, o max_priority_fee apenas cobre a parte de gás não-blob da transação. Isso não deixa nenhuma maneira direta de submeter uma dica de inclusão para o construtor.

Capacidade de Mercado de Blob

Nesta seção, nós realizar um backtestna atividade de rollup histórica de janeiro de 2023 a janeiro de 2024 para demonstrar a capacidade do mercado de blob. Concentramo-nos em txs dos rollups mais ativos na Ethereum e usamos os dados históricos para simular um mercado de blob ao vivo. Embora este mercado esteja a crescer 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 calldata rollup usada no espaço de bloco tx tipo3, vemos que o preço do mercado blob pode absorver confortavelmente toda a capacidade de rollup sem mover o preço do mercado blob para além do gás base mínimo do blob.

base bloco gás por bloco

Embora os rollups estejam a publicar mais dados no 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 maior número de vezes que um bloco seria construído com um certo número de blobs 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 os rollups.

Não só o mercado de blob pode absorver confortavelmente as necessidades atuais de disponibilidade de dados rollup, também liberta 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 preço anteriormente ao EIP 4844.

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

Rollups Demand More Data Availability

Os rollups têm uma influência significativa na quantidade de gás utilizada nos blocos, e são a maior classe de utilizadores de gás do espaço de bloco Ethereum hoje. Em 2023, os rollups armazenaram quantidades recordes de dados de transações no Ethereum, como descrevemos abaixo:

Os dados da chamada guardados na 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 de cisne negro.Recentemente em dezembro de 2023, 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 publicar a fila de estados salvos, o sequenciador monopolizava o espaço do bloco, causando preços do gás a dispararem acima de 140 gwei e a consumirem mais de 90% do gásem blocos inteiros, tornando a rede inutilizável para a maioria dos utilizadores durante várias horas.

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

Desafios do Mercado do Blob: Censura

Propagação de Blob

EIP-4844 aumenta os requisitos de largura de banda por bloco beacon em no máximo ~0.75 MB, 42m de gás para acomodar até 6 blobs adicionais em cada bloco beacon. Ao contrário do calldata, que é armazenado para sempre, os blobs são persistidos nos nós beacon 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, as transações de blob têm duas representações na rede - para o construtor de blocos como uma tx de blob e para o validador como um sidecar de blob. O sidecar de blob existe para compatibilidade futurafins.

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

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

A Perspetiva do Construtor de Blocos

Investigações recentes em jogos de temporização do validadordestaca que a otimização da latência pode beneficiar estrategicamente os operadores de nós para maximizar os lucros, atrasando as propostas de bloco. Os autores explicam que isso é prejudicial para a saúde da cadeia. As transações de blob complicam ainda mais os jogos de temporização ao adicionar uma quantidade variável de latência quando o blobsidecar propaga.

As transações de blob são equivalentes aos tamanhos de transação possíveis. Como resultado, os blocos que contêm essas transações podem propagar-se mais lentamente, tornando os construtores de blocosmenos competitivo para ganhar lances de impulso de mev. Como resultado, isso incentiva os construtores de blocos a censurar temporariamente ou até indefinidamente os blobs para que possam submeter ofertas de MEV com frequência mais alta.

O ethpandaA equipa tem vindo a realizar testes de latência no 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. Uma captura 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.

Depois de o construtor de blocos vencer o leilão de licitação mev-boost, o proponente deve esperar que os sidecars de bloco blob se propaguem antes de poder verificar os blobs incluídos no bloco. A tabela abaixo mostra que o tempo mínimo para a propagação de um único sidecar de blob é 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 cerca de 225ms.

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

Esta latência de propagação de blob coloca um risco adicional de reorganização de blocos nos construtores de blocos à medida que preenchem os seus blocos com blobs, para 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 muitos mev, os construtores economicamente racionais precisariam ser compensados apropriadamente pelos rollups por este risco.

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

O pesquisa de jogos de temporização do validadoraponta que os lances maiores estão correlacionados com blocos de tamanho maior mais tarde no processo de licitação mev-boost. À medida que os lances e o preço do gás aumentam, uma parcela maior de ETH é queimada em slots subsequentes. Se a taxa base aumentar enquanto a extração de mev permanecer constante, os construtores têm menos para licitar 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 ordem das dezenas ou centenas de wei. Torna-se essencial para os rollups reconhecer que suas transações de blob podem não ser incluídas, apesar de pagar a taxa base suficiente. O mercado de blob com baixa taxa base implica que os blobs precisarão oferecer múltiplos mais altos para incentivar os construtores a incluir as transações. Em tais 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 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 o problema 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 do blob, assumindo um custo base de gás de blob de 10 wei. Note-se que este exemplo pressupõe que existe um mecanismo eficaz de licitação de inclusão em vigor para poder licitar no espaço de blobs em primeiro lugar.

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

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 gás usado a 1 gwei (preço base de 10 wei + taxa de prioridade de .99999999 gwei) = 0.000131072 ETH

O cálculo conclui que, se os rollups utilizarem o mercado de blob, podem submeter uma oferta potencialmente 100 vezes maior devido à taxa de base de blob mais baixa, enquanto ainda poupam mais de 150 vezes o custo. A taxa de base de blob mais baixa permitirá aos rollups oferecer lances de inclusão mais competitivos, ao mesmo tempo que economizam nos custos. A taxa de inclusão terá de ser tão competitiva quanto as oportunidades de MEV existentes no bloco para compensar o potencial risco de reorganização do construtor, e assim mesmo licitar 100 vezes mais alto pode não ser suficiente. Ou seja, na ausência de pré-confirmações de blob.

Blob Pré-confirmações 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 através do pipeline mev. No mev-commit, cada provedor de pré-conf apresenta seus próprios compromissos com txs. O provedor pode então dar acesso a esses dados a outros (por exemplo, construtores de blocos, retransmissões, sequenciadores). A disponibilidade de dados da lista pré-conf para outros atores ao longo do pipeline 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 ou ter o espaço de bloco tipo3 construído colaborativamente por um relé.

Com o conhecimento avançado dos bloco de informações pré-confirmadas, os construtores de blocos podem começar a construir blocos futuros com bloco de informações antes de seu intervalo começar. Isso cria uma base de preços e lança as bases para um mercado de futuros robusto que dá aos rollups uma inclusão mais confiável e estabilidade de preço de espaço de bloco. Além disso, as ofertas pré-confirmadas de compromisso de mev dão aos rollups um mecanismo de descoberta de preços mais confiável porque os rollups podem atualizar suas ofertas pré-confirmadas em tempo real sem reenviar toda a transação de bloco de informações.

Finalmente, agrupar blobs e usar um lance predefinido permite que os rollups construam alianças. Os lances predefinidos podem ser aplicados a conjuntos de transações de blobs ou blobs agregados, permitindo que os rollups compartilhem seu poder de licitação 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á a melhorar, enquanto um novo mercado surge com considerações adicionais que vão desde jogos de timing até à falta de um mecanismo de gorjeta. Embora seja demasiado cedo para avançar para a fase da solução dos problemas que destacamos, podemos facilmente experimentar com isso com atores do PBS, uma vez que o mev-commit está ativo na testnet de Holesky. Primev irá recolher dados sobre os efeitos de blob na construção de blocos e na latência do proponente, e espera obter insights sobre potenciais padrões comportamentais.

Embora a economia e a UX sejam os principais impulsionadores das transações de tipo2 pré-conf, 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 os blobs de pré-conf ao abrigo do EIP-4844. Também estaremos a experimentar com um relé de pré-conf de blobs que pode aproveitar os pré-confs de blobs e a coordenação de construção de blocos para melhorar a propagação de latência de sidecar de blobs na testnet Holesky. Convidamos a comunidade a entrar em contacto e participar nesta experiência, pois informará uma solução potencial para toda a comunidade.

Aviso legal:

1. Este artigo é reproduzido a partir de [Gateespelho], 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 Gate Learnequipa, e eles vão lidar com isso prontamente.

2. Responsabilidade de Isenção: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.

3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.