Otimização da taxa de gás do Ethereum: como o proto-Danksharding remodelou os custos de transação da camada 2

A grande mudança para os usuários de camada 2 não foi um corte universal nas taxas de gás do Ethereum. Foi uma via de dados temporária e mais barata para rollups. A atualização Dencun do Ethereum ativou o proto-danksharding por meio do EIP-4844 em 13 de março de 2024. Os rollups passaram a poder publicar lotes usando blobs — contêineres de dados temporários com um mercado de taxas separado — em vez de depender apenas de dados de chamada armazenados permanentemente. Essa mudança reduziu um custo importante para os servidores de camada 2 que adotaram blobs, mas não tornou todas as transações de camada 2 baratas o tempo todo.

O contexto atual é importante. A atualização Fusaka do Ethereum, lançada posteriormente, trouxe o PeerDAS para a rede principal em dezembro de 2025, avançando o mesmo roteiro de disponibilidade de dados ao possibilitar o escalonamento da taxa de transferência de blobs de forma mais eficiente. Para os usuários de hoje, a lição prática é que as taxas da camada 2 dependem de mais do que um único "preço do gás": uma camada 2 precisa pagar por sua própria execução e pela publicação de dados ou provas no Ethereum, enquanto a demanda por espaço para blobs e a política de taxas de cada camada 2 podem alterar o preço final.

O que mudou com o proto-danksharding?

Antes da EIP-4844, era comum que os rollups enviassem dados de transação para o Ethereum como calldata. Os calldata fazem parte da entrada de transações do Ethereum e permanecem disponíveis como parte do histórico da blockchain. Essa permanência é valiosa, mas torna o uso desses dados em larga escala muito caro para os rollups.

A EIP-4844 adicionou um novo tipo de transação, frequentemente chamada de transação de blob. Um blob armazena dados que são disponibilizados à rede por um período limitado, em vez de serem executados pela Máquina Virtual Ethereum ou armazenados permanentemente da mesma forma que os dados de chamada. O Ethereum.org afirma que os dados em blob ficam disponíveis por cerca de 18 dias (4096 épocas) antes de serem removidos. Esse período foi projetado para atender às necessidades de disponibilidade de dados de rollups, e não para armazenamento permanente de arquivos de uso geral.

O resultado é um caminho econômico diferente para os dados de rollup. O rollup ainda se consolida ou se ancora no Ethereum, mas pode usar um recurso de disponibilidade de dados criado especificamente para esse fim, em vez de competir apenas pela capacidade de execução L1 e de dados de chamada comuns. Leia as perguntas frequentes do Dencun do Ethereum para obter uma visão geral oficial da atualização e a especificação EIP-4844 para o design de transações e taxas.

O mecanismo principal: as taxas de blob são separadas do gás normal.

O termo "gás" é frequentemente usado como se fosse um único número. Após a EIP-4844, essa abreviação pode obscurecer o que um rollup está pagando. Transações Blob têm campos de taxa de execução normais do Ethereum, além de uma taxa máxima separada para o gás do blob. O protocolo mantém uma taxa base independente para blobs que responde ao uso de blobs, em vez de precificar blobs apenas por meio do mercado de gás L1 normal.

A EIP-4844 mantém deliberadamente a precificação de blobs separada. Sua especificação descreve o gás para blobs como independente do gás normal, com sua própria meta e regra de ajuste. É por isso que uma notícia sobre baixo gás de camada 1 não informa automaticamente quanto custará uma transação de camada 2, e um pico na demanda por blobs pode afetar os rollups mesmo quando a atividade normal de camada 1 parece baixa.

Como isso mudou as transações de nível 2 na prática?

Os rollups podem publicar dados de forma mais econômica.

Os rollups executam muitas transações de usuários fora da rede principal do Ethereum e, em seguida, publicam informações suficientes no Ethereum para que o estado do rollup possa ser verificado ou contestado, de acordo com seu projeto. Antes dos blobs, os dados de chamada permanentes eram uma parte significativa desse processo. Os blobs oferecem ao rollup um local de menor custo para publicar dados que devem estar disponíveis por tempo suficiente para o processo de segurança do sistema, mas que não precisam permanecer no histórico de execução permanente de cada nó.

Para uma camada 2 que suporte blobs, a economia pode ser repassada aos usuários, retida em um modelo de taxas ou parcialmente compensada por outros custos. O momento e a magnitude de qualquer redução são, portanto, específicos da implementação. O Ethereum.org observa explicitamente que os provedores de rollup fazem a escolha entre calldata e blobs, geralmente com base na demanda por espaço de blobs, e que os prazos de suporte e o comportamento das taxas podem variar.

As taxas tornaram-se mais sensíveis ao processamento em lote e à eficiência dos dados.

Em geral, um rollup agrupa várias ações do usuário em um lote antes de enviá-las para a camada 1 (L1). Distribuir o custo de dados da L1 por mais transações pode reduzir a parcela por usuário, enquanto ações com grande volume de dados podem consumir uma parcela maior. Os detalhes variam de acordo com a arquitetura do rollup, o método de compressão e a política do sequenciador. Uma simples transferência de token, uma chamada de contrato com um volume substancial de dados e a criação de um NFT podem, portanto, gerar taxas muito diferentes na mesma camada 2 (L2).

O proto-danksharding não elimina essa compensação. Ele reduz o custo da camada de disponibilidade de dados quando blobs são usados; porém, não elimina a computação da camada 2, a complexidade dos contratos inteligentes ou o custo de um recurso de dados escasso durante períodos de congestionamento.

O que o proto-danksharding não mudou

• Isso não tornou diretamente todas as transações na Mainnet mais baratas. O FAQ da Dencun afirma que o EIP-4844 visa principalmente as taxas da camada 2. Qualquer efeito nas taxas da Mainnet é indireto e depende da adoção e da demanda.
• Isso não tornou o espaço de blobs ilimitado. A capacidade de blobs é limitada e os rollups podem usar calldata quando o espaço de blobs estiver em demanda ou indisponível a um custo aceitável.
• Isso não obrigou todos os servidores de camada 2 a usar blobs da mesma maneira. O operador de sequenciamento ou de agregação geralmente gerencia as opções de publicação e agrupamento de dados.
• Isso não transformou os blobs em armazenamento permanente. O conteúdo dos blobs é temporário; aplicativos que precisam de dados duráveis ​​devem usar um design de armazenamento apropriado.
• Não foram removidas as taxas de ponte, troca, protocolo ou carteira. O total exibido pode incluir várias camadas de custo além da taxa básica de transação de camada 2.

Por que o roteiro pós-Dencun ainda é importante: PeerDAS

O proto-danksharding foi intencionalmente concebido como uma ponte para uma disponibilidade de dados mais escalável, e não como a forma final de sharding. A EIP-4844 introduziu o formato de transação blob e um mercado de taxas separado, mantendo uma capacidade inicial conservadora. Em dezembro de 2025, Fusaka apresentou o PeerDAS (EIP-7594), um projeto de amostragem de disponibilidade de dados que permite aos nós verificar a disponibilidade por meio da amostragem de dados, em vez de cada nó baixar todos os dados blob.

Isso é importante porque uma maior capacidade de processamento de blobs permite suportar mais dados de rollup sem exigir que cada nó carregue toda a carga. Isso não altera a regra básica para o usuário: a taxa da camada 2 continua sendo dinâmica. A melhoria técnica pode aumentar a capacidade e reduzir a pressão, mas não é uma promessa de preço fixo. Consulte o anúncio da rede principal Fusaka da Ethereum Foundation e a visão geral oficial do PeerDAS para obter detalhes confirmados sobre o escopo dessa atualização.

Um fluxo de trabalho prático para otimização de taxas para usuários de nível 2.

Não é possível selecionar um lote diretamente em uma transação típica de carteira; o processo de rollup decide como os lotes serão enviados. No entanto, você pode reduzir custos desnecessários e escolher uma rota adequada para a transação.

1. Identifique a rede real. Confirme se o aplicativo está usando a Mainnet do Ethereum, um rollup específico ou outra blockchain. "Compatível com Ethereum" não significa que ele se beneficia do espaço de armazenamento do Ethereum.
2. Leia atentamente a discriminação das taxas antes de confirmar. Distinga a taxa de rede L2 de quaisquer taxas de aplicação, ponte, troca ou protocolo.
3. Compare a mesma ação em diferentes servidores de camada 2 (L2) compatíveis. Use apenas a rede oficial do aplicativo e a cotação atual da carteira. Uma taxa menor só é útil se o destino, a liquidez, as garantias de segurança e o método de saque forem adequados ao seu caso de uso.
4. Evite chamadas desnecessárias que gerem grande volume de dados. Aprovações múltiplas, tentativas repetidas e interações complexas com contratos podem custar mais do que uma simples transferência. Consolide ações somente quando isso não representar um risco maior para a segurança ou a execução do serviço.
5. Não tente novamente sem antes verificar o status da transação. Uma transação de substituição ou duplicada pode gerar outra cobrança ou uma segunda ação não intencional.
6. Mantenha uma pequena reserva de gás nativo no cache de camada 2 (L2). Ficar sem gás após uma ponte ou troca de pacotes pode forçar uma transferência extra e atrasar a transação.
7. Utilize exploradores e documentação oficiais. Verifique os endereços dos contratos, as etapas de ponte e as configurações de rede antes de assinar. Uma transação "barata" enviada para a rede errada não é uma otimização.

Quando uma taxa exibida mais baixa não é a melhor opção

A otimização de taxas é condicional. Uma camada 2 de baixo custo pode ser uma boa opção para uma ação frequente e com suporte, como uma interação com um aplicativo que permanece dentro desse ecossistema. Pode ser uma má escolha se você precisar reconectar imediatamente, se o aplicativo não for compatível com a rede de destino ou se os mecanismos de liquidez e saque adicionarem mais custos e riscos do que a economia inicial na taxa.

Por exemplo, transferir ativos para um servidor de camada 2 (L2) com taxas baixas para uma pequena troca pode ser ineficiente se a ponte, as aprovações e a transferência de retorno custarem mais do que transacionar onde os ativos já estão. Por outro lado, um usuário que realiza muitas transações suportadas dentro de um único ecossistema de camada 2 pode se beneficiar mais de baixos custos recorrentes de execução e dados. Compare o caminho completo, não apenas a primeira cotação de gás.

Como os desenvolvedores devem interpretar a mudança

Para equipes de rollup, os blobs alteram o objetivo de otimização de "minimizar dados de chamadas permanentes a todo custo" para "usar a disponibilidade de dados de forma eficiente, gerenciando um mercado de taxas de blob separado". Isso inclui compressão, formação de lotes, comportamento alternativo quando as taxas de blob aumentam e contabilização transparente das taxas para os usuários. Os aplicativos devem evitar alegar uma redução permanente de taxas com base apenas no EIP-4844, pois a demanda, a implementação do rollup e as futuras atualizações do protocolo continuam sendo variáveis.

Para desenvolvedores de aplicações em uma camada 2 (L2), o design de transações ainda é importante. Reduzir gravações desnecessárias no armazenamento, chamadas de dados (calldata), chamadas de contrato e falhas de execução pode diminuir a parcela de custo de execução para o usuário. Essas são otimizações complementares: o proto-danksharding reduz principalmente o componente de envio de dados da camada 1 (L1) do rollup, enquanto contratos eficientes abordam o trabalho realizado na própria camada 2.

Resumindo

O proto-danksharding alterou a economia da camada 2 ao fornecer aos rollups uma via de dados temporária com preço separado. É por isso que muitos rollups com suporte a blobs puderam reduzir significativamente os custos de liquidação após o Dencun. A chegada posterior do PeerDAS fortaleceu o lado da capacidade do mesmo roteiro, mas nenhuma das atualizações torna as taxas fixas ou garante que toda camada 2 seja mais barata que a Mainnet para todas as tarefas.

Para os usuários, a melhor otimização é escolher a rede correta para todo o caminho da transação, ler a cotação real da taxa, evitar chamadas de contrato redundantes e manter gás nativo suficiente para a rede que está sendo usada. Para os desenvolvedores, a lição duradoura é tratar a disponibilidade de blobs, as taxas de blobs, o processamento em lote e a execução de camada 2 como partes relacionadas, mas distintas, do modelo de custo.