4844

O que é o 4844?

O 4844 diz respeito à proposta EIP-4844 da Ethereum, conhecida também como Proto-Danksharding. Esta proposta foi ativada durante a atualização Dencun da mainnet, introduzindo um mecanismo de “publicação de dados” mais eficiente em termos de custos para redes Layer 2.

No universo Ethereum, as soluções Layer 2 (L2) funcionam como vias rápidas elevadas, desviando grandes volumes de tráfego. Os rollups são a implementação L2 mais predominante, agrupando múltiplas transações de utilizadores e publicando-as na mainnet Ethereum para garantir segurança. A EIP-4844 traz um novo canal de dados “Blob”, tornando o processo de publicação de dados mais económico e escalável.

Porque é que o 4844 reduz os custos das L2?

Anteriormente, os rollups armazenavam os seus dados de transação no “calldata” da Ethereum, competindo com a execução de smart contracts pelos mesmos recursos—o que resultava em custos elevados. A EIP-4844 transfere estes dados “de curta duração” para um mercado de taxas independente, o “Blob fee market”, tornando os custos mais estáveis e previsíveis.

Imagine o calldata como um “quadro de avisos permanente”, enquanto os Blobs funcionam como “quadros temporários que são regularmente limpos”. Como os rollups só precisam de garantir a disponibilidade dos dados durante um período limitado, os Blobs são suficientes e permitem custos mais reduzidos, aumentando a eficiência da rede.

O que é um Blob no 4844?

Um Blob é um grande bloco de dados associado a um tipo especial de transação, reservado para publicação e atestação. Os Blobs não podem ser lidos diretamente por smart contracts Ethereum (EVM); a sua integridade e disponibilidade são garantidas por mecanismos de compromisso e verificação.

Os dados dos Blobs são mantidos na rede apenas temporariamente antes de serem eliminados pelos nós, reduzindo as exigências de armazenamento permanente. Isto está de acordo com as necessidades dos rollups, que apenas precisam de acesso a dados históricos durante períodos de disputa ou de replay.

Como funciona o 4844 na Ethereum?

O 4844 introduz um novo tipo de transação que permite transportar dados Blob. Cada bloco tem um limite para o número de Blobs incluídos e o preço dos Blobs é definido por um mercado próprio que se ajusta dinamicamente à procura e oferta.

Quando utilizadores ou rollups submetem transações com Blobs, os validadores verificam os compromissos associados e recolhem as taxas correspondentes. Esta arquitetura separa os “custos de disponibilidade de dados” dos “custos de execução de contratos”, evitando a competição por recursos e estabilizando as despesas de publicação de dados das L2.

Importa salientar que a EVM não pode aceder diretamente ao conteúdo dos Blobs; as aplicações dependem de provas de compromisso para validar a publicação do Blob. Este modelo reduz a necessidade de armazenamento a longo prazo, mantendo uma janela de auditoria para recuperação e verificação de dados.

Que impacto tem o 4844 nos rollups?

O 4844 reduz substancialmente o custo de publicação de dados para os rollups, permitindo lotes maiores e maior flexibilidade—melhorando a experiência do utilizador com taxas mais baixas e confirmações mais rápidas. Desde a atualização Dencun em março de 2024, as taxas principais das L2 caíram significativamente e mantêm-se baixas (ver notas de atualização em Ethereum.org e painéis comunitários de taxas, desde março de 2024).

Para os operadores, taxas mais estáveis e maior largura de banda de dados permitem apoiar mais utilizadores e aplicações avançadas—como negociação de alta frequência, criação de NFT ou interações em jogos—com maior resiliência em períodos de maior procura.

Como pode poupar nas L2 com o 4844?

Para tirar partido dos custos mais baixos proporcionados pela EIP-4844, o essencial é realizar operações on-chain em L2 Ethereum com suporte a Blobs, prestando atenção aos métodos de depósito/levantamento e à gestão de risco.

Passo 1: Prepare a sua carteira. Utilize uma carteira reconhecida, atualizada para a versão mais recente, garantindo compatibilidade com redes L2 e formatos de assinatura. Os utilizadores iniciantes podem adicionar o endpoint RPC e o chain ID da L2 pretendida nas definições da carteira.

Passo 2: Deposite e levante via Gate. Transfira fundos da Gate para o endereço L2 pretendido, escolhendo o canal de rede L2 adequado na página de levantamento—normalmente com taxas inferiores. O mesmo se aplica aos depósitos; confirme sempre os detalhes da rede e do endereço, e faça um teste com um valor reduzido para evitar perdas por erro.

Passo 3: Interaja na L2. Realize transferências, operações em DEX ou criação de NFT na L2 selecionada—beneficiando normalmente de taxas mais baixas e confirmações mais rápidas. Em períodos de maior movimento, considere aumentar a gorjeta ou transacionar fora das horas de pico.

Passo 4: Acompanhe os painéis de taxas. Consulte painéis oficiais ou comunitários de taxas das L2, monitorizando eventuais picos temporários nos preços dos Blobs devido a congestionamento e planeando as suas transações para maior eficiência.

Passo 5: Conheça os tempos de espera das bridges. As bridges oficiais de diferentes L2 podem ter atrasos nos levantamentos; em casos urgentes, pode recorrer a bridges de terceiros reputadas, mas deve sempre avaliar o risco da contraparte e as taxas adicionais.

Aviso de risco: Todas as transferências e assinaturas on-chain envolvem risco irreversível. Confirme sempre redes, contratos e endereços—comece com valores reduzidos para limitar eventuais perdas.

Em que difere o 4844 do sharding e do calldata?

Ao contrário do calldata, os Blobs do 4844 têm um mercado de taxas próprio, são armazenados temporariamente e não são acessíveis diretamente pela EVM—tornando-os ideais para dados de rollup que só precisam de estar disponíveis a curto prazo e, normalmente, a um custo mais baixo.

O 4844 não é sharding completo, mas sim uma solução transitória (Proto-Danksharding). Não divide a Ethereum em shards de execução paralela, mas aumenta a largura de banda de dados na estrutura existente, introduzindo preços independentes—lançando as bases para o futuro Danksharding e sampling de disponibilidade de dados.

Quais são os riscos e limitações do 4844?

A EIP-4844 não reduz diretamente os custos de execução de smart contracts na Layer 1 da Ethereum; contratos complexos continuam dispendiosos na L1. Se a procura por Blobs aumentar rapidamente, os preços dos Blobs podem subir temporariamente—provocando alguma volatilidade nas taxas das L2.

Os dados dos Blobs só permanecem na rede por um tempo limitado antes de serem eliminados, obrigando rollups e operadores de nós a arquivar os dados necessários noutro local. Carteiras, browsers ou ferramentas podem demorar a atualizar-se para garantir compatibilidade; utilizadores iniciais poderão notar diferenças na apresentação ou nos pedidos de assinatura.

Além disso, o 4844 não altera o modelo de segurança dos rollups nem os tempos de levantamento das bridges. Os utilizadores devem estar atentos aos riscos associados a bridges cross-chain, atualizações de contratos e gestão de permissões.

O que se segue para o 4844?

A EIP-4844 é considerada um passo essencial rumo ao Danksharding completo. Os próximos desenvolvimentos incluem aumentar o limite de Blobs por bloco, otimizar os mecanismos de ajuste de taxas e avançar tecnologias como Data Availability Sampling (DAS) para ampliar a largura de banda e a participação dos nós.

Ao nível das aplicações, mais L2 irão otimizar estratégias de batching com base na disponibilidade de dados (DA) a baixo custo, tornando viáveis aplicações on-chain de alta frequência e em tempo real. Camadas alternativas de disponibilidade de dados continuarão a evoluir em paralelo com o roadmap da Ethereum—criando um ecossistema multi-camadas.

Principais conclusões do 4844

A EIP-4844 oferece um canal de armazenamento mais económico e de curta duração para publicação de dados de rollups, ao separar “custos de disponibilidade de dados” dos “custos de execução de contratos”. Isto melhora substancialmente as taxas e a capacidade das Layer 2, preparando o caminho para o Danksharding completo. Para os utilizadores: migrar operações para L2 com suporte a Blobs, escolher canais de depósito/levantamento adequados via Gate e seguir as melhores práticas de gestão de risco são essenciais para beneficiar de menores custos e melhor experiência.

FAQ

Os dados dos Blobs ficam armazenados permanentemente on-chain?

Não. Os dados dos Blobs permanecem on-chain cerca de 18 dias antes de serem automaticamente eliminados. Este modelo de armazenamento temporário responde às necessidades de disponibilidade de dados das L2, poupando espaço nos full nodes. Os projetos L2 podem arquivar os dados históricos necessários noutro local antes do fim do período dos Blobs para garantir rastreabilidade.

Porque são os Blobs muito mais baratos do que o calldata?

Os Blobs têm um mecanismo de definição de preço do gas dedicado, com preços inicialmente baixos e sem competir com a execução de contratos pelo espaço do gas. O calldata tem de ser armazenado e executado por todos os nós de forma permanente—tornando-o caro—enquanto os Blobs só precisam de ser guardados durante 18 dias num mercado de gas separado. Esta arquitetura permite que os custos das transações L2 diminuam mais de 90 %.

Se transacionar numa L2, irá notar taxas mais baixas devido ao 4844?

Sim. Se a L2 escolhida implementar publicação de dados baseada em Blobs, beneficiará diretamente de taxas de transação muito mais baixas. L2 líderes como Arbitrum e Optimism já suportam Blobs; novos utilizadores podem transferir ativos de plataformas como a Gate para estas L2 para transações económicas.

Porque tem cada Blob o tamanho fixo de 128 KB?

Este valor resulta do equilíbrio da Ethereum entre capacidade de processamento e requisitos dos nós. Um Blob de 128 KB reduz substancialmente os custos das L2 sem sobrecarregar a verificação ou o armazenamento dos nós. O tamanho poderá ser ajustado conforme as condições da rede, mas atualmente revela-se eficaz.

O 4844 afeta as transações na mainnet da Ethereum?

Quase nada. A EIP-4844 otimiza sobretudo as transações Layer 2—transações na mainnet não utilizam Blobs. Contudo, ao reduzir drasticamente os custos das L2, incentiva a migração de utilizadores da mainnet para as L2—aliviando a congestão da mainnet no contexto do roadmap de escalabilidade da Ethereum.