Escrito por: imToken
No final de 2025, a comunidade Ethereum acolheu relativamente tranquilamente o encerramento da atualização Fusaka.
Ao olhar para o último ano, embora as discussões sobre atualizações técnicas de base tenham gradualmente saído do centro das atenções do mercado, acredita-se que muitos utilizadores na cadeia já tenham sentido uma mudança significativa: os custos de Gas na Ethereum L2 estão cada vez mais baratos.
Atualmente, as interações na cadeia, quer sejam transferências ou operações complexas de DeFi, muitas vezes requerem apenas alguns cêntimos de dólar ou até podem ser negligenciadas, e por trás disso, as atualizações Dencun e o mecanismo Blob tiveram um papel importante. Ao mesmo tempo, com a ativação oficial da característica central PeerDAS (Peer Data Availability Sampling, Amostragem de Disponibilidade de Dados Ponto a Ponto) na atualização Fusaka, a Ethereum está a despedir-se definitivamente da era da validação de dados por “download completo”.
Pode-se dizer que, o que realmente decide se a Ethereum pode suportar aplicações em grande escala de forma sustentável a longo prazo, não é apenas o Blob em si, mas sim o próximo passo representado pelo PeerDAS.
1. O que é o PeerDAS?
Para entender o significado revolucionário do PeerDAS, não podemos apenas falar de conceitos de forma abstrata; é necessário retroceder a um marco importante na escalabilidade da Ethereum, ou seja, a atualização Dencun de março de 2024.
Na altura, a EIP-4844 introduziu um modelo de transações que transportam Blob (incorporando uma grande quantidade de dados de transação em blobs), permitindo que as L2s deixem de depender do caro mecanismo de armazenamento calldata, passando a usar armazenamento temporário de Blob.
Esta mudança reduziu diretamente os custos do Rollup para uma décima parte do valor anterior, garantindo que as plataformas L2 possam oferecer transações mais baratas e rápidas, sem comprometer a segurança e o grau de descentralização da Ethereum, permitindo aos utilizadores experimentar os benefícios de uma “Era de Gas Baixo”.
No entanto, embora os blobs sejam úteis, o número de blobs que cada bloco na rede principal da Ethereum pode suportar tem um limite rígido (normalmente entre 3 a 6), devido a razões muito concretas: largura de banda física e espaço em disco são limitados.
Na validação tradicional, cada validador (Validator), seja um servidor operado por uma entidade profissional ou um computador comum em casa, ainda precisa descarregar e propagar os dados completos do Blob para confirmar sua validade.
Isto cria um dilema:
- Se aumentarmos o número de blobs (para expandir a capacidade): o volume de dados dispara, a largura de banda dos nós domésticos fica saturada, os discos ficam cheios, levando-os a desligar-se, o que rapidamente centraliza a rede, transformando-a numa cadeia dominada por grandes centros de dados;
- Se limitarmos o número de blobs (para promover a descentralização): a capacidade de throughput das L2s fica presa, incapaz de responder ao crescimento explosivo futuro.
Resumindo, o Blob foi apenas o primeiro passo, resolvendo a questão de “onde guardar os dados”. Quando há poucos dados, tudo funciona bem, mas se o número de Rollups continuar a aumentar, cada um submetendo dados em alta frequência, e a capacidade de blobs expandir-se continuamente, a largura de banda e a pressão de armazenamento dos nós tornar-se-ão novos riscos de centralização.
Se continuarmos a usar o método tradicional de download completo, a expansão da Ethereum será bloqueada pela parede da largura de banda física, levando a uma frustração constante. O PeerDAS é precisamente a chave para desbloquear esse impasse.
Resumindo em uma frase, o PeerDAS é uma arquitetura de validação de dados totalmente nova, que rompe com a regra de que a validação deve envolver o download completo, permitindo que a expansão de blobs ultrapasse o limite atual de throughput físico (por exemplo, de 6 blobs por bloco para 48 ou mais).
2. Blob resolve “onde guardar”, PeerDAS resolve “como guardar”
Como mencionado acima, o Blob deu o primeiro passo na expansão, resolvendo a questão de “onde guardar os dados” (passando de calldata caro para espaço temporário de Blob), e o PeerDAS deve resolver a questão de “como guardar de forma mais eficiente”.
O problema central que ele visa resolver é como, com o crescimento exponencial dos dados, não sobrecarregar a largura de banda física dos nós. A ideia é bastante direta: com base em probabilidade e colaboração distribuída, não é necessário que todos armazenem a totalidade dos dados, mas ainda assim possam confirmar com alta probabilidade que esses dados realmente existem.
Este conceito pode ser entendido a partir do nome completo do PeerDAS: “Amostragem de Disponibilidade de Dados Ponto a Ponto”.
Embora pareça um conceito complexo, podemos usar uma metáfora simples para entender essa mudança de paradigma: por exemplo, a validação completa anterior é como uma biblioteca que recebe uma enciclopédia de milhares de páginas (Blob de dados). Para evitar perdas, cada administrador (nó) tinha que fazer uma cópia completa do livro, como backup.
Isto significava que apenas quem tinha recursos (largura de banda / espaço em disco) suficiente poderia ser administrador, especialmente porque essa enciclopédia (Blob) continuava a crescer, tornando-se cada vez maior. Com o tempo, os indivíduos comuns seriam eliminados, e a descentralização desapareceria.
Agora, com a amostragem PeerDAS, introduzindo técnicas como o codificação de exclusão (Erasure Coding), é como rasgar o livro em inúmeros pedaços e codificá-los matematicamente. Cada administrador não precisa mais possuir o livro inteiro, apenas alguns pedaços aleatórios.
Mesmo na validação, não é necessário que alguém apresente o livro completo. Teoricamente, se a rede conseguir reunir qualquer 50% dos pedaços (independentemente de quem possui qual pedaço, seja a página 10 ou a página 100), podemos, por meio de algoritmos matemáticos, reconstruir o livro inteiro com certeza absoluta.
Essa é a magia do PeerDAS — descarregar a responsabilidade de baixar os dados de um único nó e dispersá-la por uma rede colaborativa composta por milhares de nós.
scale70Fonte: @Maaztwts
Apenas do ponto de vista de dados, antes da atualização Fusaka, o número de blobs estava rigidamente limitado a entre 3 a 6. Com a implementação do PeerDAS, esse limite foi rompido, permitindo que o número de blobs por bloco suba para 48 ou mais.
Quando um utilizador inicia uma transação na Arbitrum ou Optimism, e os dados são enviados de volta à rede principal, não é mais necessário transmitir o pacote completo para toda a rede. Isso faz com que a expansão da Ethereum deixe de aumentar linearmente o custo de nós.
De forma objetiva, Blob + PeerDAS constituem a solução completa de Disponibilidade de Dados (DA). Do ponto de vista do roteiro, essa é a transição crucial da Ethereum do Proto-Danksharding para o Danksharding completo.
3. A nova normalidade na cadeia após Fusaka
Como é de conhecimento geral, nos últimos anos, camadas modulares de DA de terceiros, como a Celestia, ganharam grande espaço de mercado devido ao alto custo de armazenamento nativo da Ethereum.
Com Blob e a mais recente implementação do PeerDAS, a Ethereum tornou-se não só mais barata, mas também extremamente segura: o custo de publicar dados das L2 na L1 foi reduzido pela metade, além de a Ethereum possuir o maior conjunto de validadores do mundo, garantindo uma segurança muito superior às cadeias de terceiros.
De forma objetiva, isso representa um golpe de redução de dimensão para soluções como a Celestia, marcando que a Ethereum está a retomar a soberania na disponibilidade de dados, comprimindo significativamente o espaço de atuação dessas soluções.
Você pode estar se perguntando: tudo isso parece muito técnico, qual a relação com usar a carteira, fazer transferências ou DeFi?
A relação é bastante direta. Se o PeerDAS for implementado com sucesso, isso significa que o custo de dados das L2s pode permanecer baixo a longo prazo, e as Rollups não precisarão aumentar suas taxas por causa do custo de DA. As aplicações na cadeia poderão ser projetadas para interações de alta frequência, e carteiras e DApps não precisarão ficar em um dilema constante entre “funcionalidade vs. custo”…
Em outras palavras, a razão pela qual podemos usar L2s baratos hoje é graças ao Blob, e se essa facilidade continuar, será graças à contribuição silenciosa do PeerDAS.
Por isso, embora discreto, o PeerDAS é considerado uma etapa indispensável na rota de expansão da Ethereum. Em essência, essa é a melhor forma de tecnologia aos meus olhos — “beneficia sem que se perceba, perde-se e é difícil de manter sem ela”, fazendo com que sua presença seja imperceptível.
No final, o PeerDAS prova que a blockchain pode, por meio de desenhos matemáticos sofisticados (como amostragem de dados), suportar volumes massivos de dados ao nível do Web2, sem sacrificar excessivamente a descentralização.
Assim, a autoestrada de dados da Ethereum está completamente pavimentada. Agora, a questão que o layer de aplicação deve responder é: que tipo de veículos irão rodar nela?
Vamos aguardar ansiosamente.
