O que são danksharding e amostragem de disponibilidade de dados?

Porque é que o Ethereum não pode simplesmente "tornar os blocos maiores"

A proposta do danksharding só faz sentido se compreenderes primeiro a limitação que pretende resolver. Cada nó numa blockchain tem de descarregar, verificar e armazenar todos os blocos. Se simplesmente aumentares o tamanho dos blocos de, por exemplo, algumas centenas de quilobytes para vários megabytes, não obténs mais capacidade de processamento. Obténs um requisito mínimo de hardware mais elevado, porque até o portátil de consumo mais barato continua a ter de acompanhar a rede.

Esta é a tensão por detrás do famoso trilema da blockchain: uma rede quer ser descentralizada, com muitos nós independentes, segura, sem uma forma fácil de falsificar o histórico, e escalável, com muitas transações baratas. Aumentar o tamanho dos blocos melhora uma propriedade à custa das outras, porque os requisitos dos nós aumentam e o número de operadores diminui.

O roteiro do Ethereum centrado nos rollups é uma resposta parcial. Em vez de fazer tudo na camada 1, permite-se que os rollups da camada 2 executem milhares de transações e depois publiquem um resumo comprimido no Ethereum. O Ethereum torna-se uma camada de liquidação e de dados, não um computador mundial. Isto funciona, mas tem um estrangulamento: os rollups precisam de um local barato e verificável para publicar os seus dados, e esse local é atualmente o calldata do Ethereum, que é caro e compete com todas as outras utilizações do espaço dos blocos.

Danksharding é o plano para eliminar esse estrangulamento, dando aos rollups um canal de dados dedicado e abundante, sem obrigar todos os nós a descarregá-lo por completo.

EIP-4844: o primeiro passo que já viste

Antes de o danksharding poder existir, o Ethereum lançou o proto-danksharding, formalizado como EIP-4844, em março de 2024. Esta é a parte que talvez já conheças pelo nome blobs.

Um blob é um fragmento de dados anexado a uma transação que funciona num mercado de taxas separado, muitas vezes chamado mercado de blob gas, e que é automaticamente eliminado da cadeia após cerca de 18 dias. Os nós não têm de executar o conteúdo dos blobs. Só têm de os armazenar temporariamente e provar que foram publicados. Rollups como Arbitrum, Optimism e Base passaram de publicar dados comprimidos como calldata para os publicar como blobs, o que tornou imediatamente as transações dos rollups várias vezes mais baratas.

O EIP-4844 é um compromisso de engenharia. Não altera a forma como o Ethereum verifica a disponibilidade de dados. Continua a exigir que todos os nós descarreguem cada blob na íntegra para confirmar que o bloco é válido. Isto funciona com alguns blobs por bloco, mas não escala para os volumes previstos pelo danksharding.

Por isso, pensa no proto-danksharding como a via de entrada. Introduz o formato das transações com blobs, o mercado de taxas separado e as regras de consenso que o danksharding futuro reutilizará. O danksharding completo acontece quando o Ethereum deixa de obrigar todos os nós a descarregar todos os blobs e começa a fazer amostragem.

O que "disponibilidade de dados" significa realmente

A expressão "os dados estão disponíveis" parece óbvia, mas tem um significado preciso na investigação sobre consenso. Um bloco tem disponibilidade de dados se todos os nós honestos conseguem mesmo obter os dados subjacentes, e não apenas o cabeçalho ou um compromisso com eles. Sem essa garantia, um produtor de blocos malicioso poderia publicar um cabeçalho de bloco que parece válido, mas reter os dados por trás dele, e os nós completos não teriam forma de detetar fraude ou reconstruir a cadeia.

Este é o problema da disponibilidade de dados, e é um dos problemas mais difíceis na escalabilidade de blockchains. É por isso que os clientes leves no Bitcoin não conseguem verificar totalmente a cadeia. Descarregam os cabeçalhos dos blocos, mas confiam que outra entidade está a armazenar os corpos. Se um minerador retiver alguma vez as transações de um bloco, um cliente leve não o consegue saber.

Ethereum quer dar aos clientes leves verificação real em vez de confiança. Isso exige um primitivo em que um nó possa confirmar que um grande conjunto de dados foi publicado sem descarregar esse conjunto de dados. A amostragem de disponibilidade de dados é esse primitivo, e o danksharding é o desenho específico do Ethereum que o implementa ao nível do consenso.

Codificação de apagamento. a matemática que permite que amostras impliquem o todo

O DAS só funciona por causa da codificação de apagamento, uma técnica emprestada da teoria do armazenamento e das comunicações. O modelo mental mais simples é imaginar escrever um ficheiro de 1 MB numa folha de cálculo e depois acrescentar 1 MB de linhas redundantes que são combinações lineares das células originais. Agora tem 2 MB, mas pode reconstruir os 1 MB originais a partir de qualquer 1 MB dos 2 MB.

No danksharding, os produtores de blocos fazem algo semelhante com os dados dos blobs. Expandem os dados subjacentes de cada blob com blocos de paridade extra, calculados com um código do estilo Reed-Solomon, duplicando o tamanho on-chain em troca de uma garantia poderosa. Se os dados estiverem sequer parcialmente disponíveis, um nó honesto pode reconstruí-los todos.

Porque é que isto importa para a amostragem? Suponha que um produtor de blocos tenta reter um quarto dos dados estendidos para que ninguém os consiga reconstruir. Isso é estatisticamente impossível de esconder, porque as amostras são escolhidas uniformemente ao acaso em todo o conjunto de dados estendido. Um nó leve que descarregue com sucesso, por exemplo, 30 blocos aleatórios e confirme que todos coincidem pode ter a certeza matemática, com uma probabilidade ajustável, de que o conjunto de dados completo é reconstruível por alguém.

A ideia-chave é que a codificação de apagamento transforma um problema de descarregar tudo num problema de verificação aleatória pontual. Sem isso, a amostragem seria inútil, porque um produtor malicioso poderia reter um único byte alvo e nenhuma verificação pontual o apanharia.

Como a amostragem de disponibilidade de dados corre realmente num nó

No desenho do danksharding, os dados da cadeia estão conceptualmente organizados numa grelha bidimensional. Cada linha corresponde aos dados de blob de um slot, e cada coluna é uma faixa de blocos estendidos. Um produtor de blocos compromete-se com toda a grelha usando compromissos polinomiais, no plano atual compromissos KZG, que funcionam como uma impressão digital criptográfica suficientemente pequena para caber num cabeçalho de bloco.

Os nós leves fazem então o seguinte para cada slot:

• Recebem o cabeçalho do bloco e os compromissos KZG para os dados estendidos.
• Descarregam alguns blocos aleatórios da grelha, pedindo posições diferentes a pares diferentes.
• Verificam cada bloco descarregado contra o respetivo compromisso. Um bloco incorreto falha a verificação de imediato.
• Aumentam a sua confiança, a cada amostra bem-sucedida, de que a grelha completa está disponível.

Depois de amostras bem-sucedidas suficientes, o nó leve trata os dados como disponíveis. Se o produtor de blocos tentasse reter mesmo uma pequena fração da grelha, a probabilidade de todas as amostras aleatórias caírem na parte honesta diminui exponencialmente. Com algumas dezenas de amostras, a probabilidade de falha torna-se negligenciável.

Esta é a parte que muda a história do hardware. Um nó leve já não precisa de ser um servidor robusto com um SSD rápido. Precisa de descarregar algo na ordem de alguns kilobytes por slot e depois espalhar essas amostras pela rede. Isso mantém os validadores individuais e os validadores domésticos competitivos, o que preserva a descentralização.

Os riscos de que ninguém fala com honestidade

O danksharding é tecnicamente elegante, mas traz modos reais de falha. Uma cobertura honesta exige falar deles.

O primeiro risco é o ataque de ocultação da disponibilidade de dados. Um produtor de blocos ainda pode tentar publicar um cabeçalho e depois reter blocos suficientes para que os nós leves honestos falhem a amostragem. Se a rede não tiver nós leves suficientes a fazer amostragem de forma redundante, um atacante pode explorar a aleatoriedade até que clientes leves suficientes falhem os dados disponíveis e rejeitem o bloco, causando uma falha de liveness, a cadeia fica parada. As mitigações de investigação incluem ter vários produtores de blocos por slot e obrigar os nós leves a esperar até que a rede tenha tido tempo para espalhar as amostras, mas ambos acrescentam latência.

O segundo risco é o modo de falha da própria codificação de apagamento. Se um bug ou erro de implementação tornar a codificação inconsistente entre clientes, nós leves honestos poderiam rejeitar blocos válidos ou aceitar blocos indisponíveis. Em parte por isso, o desenho depende de compromissos KZG, que podem provar que células individuais são consistentes com o cabeçalho, e por isso também são executados testnets extensivos, devnets como o da-dedi inspirado na Celestia e o trabalho EIP-7591, antes da implementação na mainnet.

O terceiro risco é a centralização em torno da infraestrutura. Mesmo que os requisitos no papel para um nó leve sejam mínimos, os requisitos reais para um validador completo, os que realmente propõem e atestam blocos, continuam a aumentar. Se os validadores individuais desistirem porque as tarefas de atestação exigem hardware sofisticado, a rede torna-se mais centralizada, independentemente de quão baratos sejam os clientes leves.

Por fim, existe o risco social de exagerar a promessa. A expressão "escalabilidade ilimitada" é frequentemente associada ao DAS, e isso está errado. A codificação de apagamento duplica aproximadamente a pegada de dados, por isso existe um custo real. A amostragem apenas verifica a disponibilidade. Não permite magicamente que a rede processe mais execução. Os rollups continuam a pagar pela execução noutro lugar, e os limites de throughput mantêm-se, só que num nível muito mais alto do que hoje.

Porque é que Celestia, EigenDA e Avail parecem semelhantes

Ethereum não é a única equipa a apostar na amostragem da disponibilidade de dados. A Celestia foi lançada no final de 2023 como uma blockchain autónoma cuja única função é ser uma camada de disponibilidade de dados. Usa a mesma receita de DAS e codificação por apagamento. Os dados são codificados numa grelha 2D, nós leves amostram células aleatórias e um compromisso do tipo KZG ancora a grelha inteira.

A proposta é que os rollups e as app-chains não tenham de viver na Ethereum de todo. Podem publicar os seus dados na Celestia, pagar taxas à Celestia e usar a Ethereum, ou qualquer outra camada de settlement, apenas para provas de fraude ou de validade. A Celestia posiciona-se como uma peça modular de blockchain, e não como uma plataforma de contratos inteligentes.

O EigenDA tem uma forma diferente. É um serviço de disponibilidade de dados construído em cima da EigenLayer, que permite aos stakers de ETH optarem por assegurar serviços adicionais ao voltarem a fazer staking do seu colateral. A afirmação do EigenDA é que herda a segurança económica da Ethereum, porque os operadores que executam a sua rede de armazenamento também são validadores da Ethereum com exposição real a slashing.

A Avail, originalmente criada a partir da Polygon, segue um terceiro caminho. Posiciona-se como uma camada de disponibilidade de dados que pode servir muitas cadeias, incluindo as que não são da Ethereum, e usa um esquema diferente de compromisso polinomial. Os compromissos Kate podem ser substituídos ou complementados por outros modelos, para manter a flexibilidade. A própria Polygon lançou uma chain Polygon POS que historicamente usava uma abordagem diferente, enquanto os novos rollups "Polygon CDK" podem escolher livremente qualquer camada de DA.

Porque é que a Ethereum se dá ao trabalho de construir a sua própria? Por duas razões. Primeiro, a comunidade Ethereum quer que a segurança da DA seja suportada por stakers de ETH, e não por um token separado, o que mantém as premissas de confiança de um rollup da Ethereum dentro do ecossistema da Ethereum. Segundo, a concorrência é saudável. Saber que a Celestia existe obriga os investigadores da Ethereum a lançar o que desenvolvem, e vice-versa.

O que isto significa para si como utilizador ou programador

Se estiver apenas a fazer transações na Ethereum ou num rollup, o danksharding surge sobretudo como taxas mais baixas. Quando os blobs forem abundantes e baratos, os rollups podem publicar lotes maiores e comprimir ainda mais o gas. Os números exatos dependem da dinâmica do mercado de taxas de blobs e das melhorias na compressão dos rollups, mas o impacto direcional é real. As transações em rollups que já custam alguns cêntimos podem descer para frações de cêntimo com grandes volumes de blobs.

Se for um programador a escolher uma stack de rollup, a nova decisão é qual a camada de DA a usar. As opções incluem agora a Ethereum nativa, depois do danksharding completo, a Celestia, o EigenDA e a Avail, cada uma com diferentes pressupostos de custo, segurança e pontes. Um rollup na Celestia não está tão fortemente ligado aos stakers de ETH, mas pode ser mais barato e flexível. Um rollup no EigenDA herda a segurança de ETH re-staked, mas só é tão descentralizado quanto o conjunto de operadores da EigenLayer. Não existe almoço grátis.

Se for um staker ou um validador doméstico, a mensagem prática é mais tranquilizadora do que alarmante. Os requisitos para clientes leves mantêm-se baixos, por isso o patamar de hardware do dia a dia não sobe como aconteceria com aumentos ingénuos do tamanho dos blocos. Os requisitos de atestação podem ainda aumentar, mas a um ritmo mais controlado, e melhorias como a separação enshrined entre proponente e construtor pretendem reduzir a carga operacional.

O que não deve fazer é assumir que o danksharding está "concluído". No início de 2026, continua em testnets, com a EIP-7591 (PeerDAS, um passo intermédio) a ser a implementação de curto prazo e o danksharding completo mais tarde. Tratar qualquer calendário como garantido é uma receita para desilusão.

Fique à frente do roteiro de escalabilidade da Ethereum

Danksharding, DAS, taxas de blobs e camadas concorrentes de disponibilidade de dados evoluem rapidamente, e a cobertura credível está espalhada por fóruns de investigação, rascunhos de EIP e chamadas dos programadores principais. O Zippfeed agrega os títulos sobre escalabilidade da Ethereum com pontuação de sentimento, bullish, neutral, ou bearish, e uma classificação de importância, para que possa perceber quais os marcos do protocolo que realmente fazem mexer a agulha e quais são apenas republicações.