Como o PeerDAS vai melhorar a disponibilidade de dados do Ethereum?
Para garantir a gestão eficiente dos dados e a verificação segura, Ethereum evoluiu de DA para DAS, culminando na introdução do PeerDAS.
Para garantir uma gestão eficiente dos dados e validação segura, o Ethereum evoluiu de DA para DAS, culminando na introdução do PeerDAS.
Escrito por: 0XNATALIE
Na recente reunião de desenvolvedores do Ethereum, foi discutida a proposta de dividir o hard fork Pectra do Ethereum em duas partes. Essa proposta já havia sido rejeitada anteriormente, pois havia preocupações de que atrasaria a atualização das árvores Verkle. No entanto, nesta reunião, os desenvolvedores voltaram a sugerir essa ideia porque desejam incluir mais propostas de melhoria (EIP) no fork Pectra. A proposta é dividir o hard fork em duas partes: a primeira incluiria todos os EIPs atualmente presentes no Pectra Devnet 3, enquanto a segunda parte incluiria EOF (EVM Object Format) e PeerDAS, entre outros. Para entender melhor o PeerDAS, começaremos pelo conceito fundamental de disponibilidade de dados.
DA: Garantindo que os nós obtenham dados on-chain
Disponibilidade de dados (Data Availability, DA) refere-se à garantia de que os blocos propostos e todos os dados de transação contidos nesses blocos estejam acessíveis e recuperáveis de forma eficaz por outros participantes da rede. A disponibilidade de dados é um fator crucial para a segurança do blockchain, pois, se os dados não estiverem disponíveis, mesmo que o bloco seja válido, outros nós não poderão verificar seu conteúdo, o que pode causar problemas de consenso e ataques à rede. Por exemplo, um atacante pode publicar apenas parte dos dados do bloco, impedindo que outros nós realizem a validação.
Quando um novo bloco é transmitido, todos os nós participantes baixam e validam os dados do bloco. Esse modelo funciona bem quando a rede é pequena, mas à medida que o blockchain cresce, o volume de dados se torna enorme, aumentando constantemente o armazenamento necessário em cada nó e exigindo hardware mais potente. Para permitir que nós leves (como dispositivos móveis ou computadores pessoais) também participem da validação dos blocos, o blockchain introduziu a tecnologia de sharding.
Sharding é a técnica de dividir toda a rede blockchain em várias pequenas "shards". Cada shard processa apenas seus próprios dados, sem precisar lidar com todos os dados do blockchain. Assim, um nó individual só precisa processar os dados do seu shard. No entanto, como cada shard lida apenas com uma parte dos dados, os nós de outros shards não têm acesso direto aos dados completos. Como garantir, então, que os dados dentro de um shard estejam disponíveis e que outros nós possam validar a validade desses dados? Por exemplo, um nó de um shard pode publicar um bloco recém-gerado, mas pode divulgar apenas parte dos dados. Se outros nós não conseguirem acessar todos os dados do bloco, não poderão verificar se o bloco é realmente válido.
DAS: Validando a disponibilidade de dados por meio de amostragem parcial
Para lidar com o problema de disponibilidade de dados nos shards, foi proposta a técnica de Data Availability Sampling (DAS), cuja ideia central é validar a disponibilidade dos dados do bloco por meio de amostragem, sem exigir que cada nó armazene ou baixe todos os dados do bloco.
A amostragem de disponibilidade de dados permite que os nós obtenham aleatoriamente apenas uma parte dos dados do bloco para validar sua disponibilidade. Se o nó conseguir acessar e validar esses fragmentos de dados aleatórios, pode-se inferir que os dados do bloco inteiro estão disponíveis.
Para suportar essa validação por amostragem, os dados do bloco geralmente utilizam codificação RS. Esse tipo de codificação permite que, mesmo com a perda de parte dos dados, seja possível recuperar o conjunto completo. Assim, mesmo que um nó baixe apenas parte dos dados do bloco, ainda pode inferir e confirmar a validade de todo o bloco. O DAS reduz a quantidade de dados que cada nó precisa processar por meio da validação por amostragem, permitindo que nós leves também participem da validação dos blocos.
O layer DA, como o da Celestia, é implementado por meio dessas tecnologias. Envolve principalmente RS encoding + validity proof + DAS.
- RS Encoding (Codificação Reed-Solomon): Esse método de codificação permite que nós que recebem apenas parte dos fragmentos de dados possam reconstruir todo o bloco de dados. É semelhante a um código de correção de erros, com certa tolerância a falhas, ou seja, mesmo que parte dos dados seja perdida, o restante é suficiente para reconstruir o conjunto completo.
- Validity Proof (Prova de Validade): Utiliza provas de conhecimento zero para garantir que não haja erros durante a codificação e transmissão dos dados. Se a validação for bem-sucedida, é possível decodificar corretamente todos os dados.
- DAS (Data Availability Sampling): Nós leves fazem amostragens aleatórias de fragmentos RS codificados dentro do bloco, validando a disponibilidade desses fragmentos e inferindo que todo o bloco de dados está disponível.
PeerDAS: Validação colaborativa de dados entre nós
PeerDAS é uma implementação específica do DAS, utilizando uma rede peer-to-peer para realizar a amostragem de disponibilidade de dados. Uma rede peer-to-peer é composta por vários nós que se comunicam diretamente entre si. No DAS, cada nó realiza a validação dos dados de forma independente, enquanto o PeerDAS otimiza esse processo, permitindo que os nós colaborem, compartilhem e validem os dados dos blocos, aumentando ainda mais a eficiência da validação. Os nós não estão isolados, podendo compartilhar tarefas e resultados de validação de dados, além de confiar nos dados já validados por outros nós. Assim, um nó não precisa realizar sozinho todo o trabalho de validação, mas pode dividir a tarefa com outros, reduzindo ainda mais sua carga. Além disso, a validação colaborativa dificulta a adulteração dos dados, pois um atacante precisaria comprometer vários nós de validação ao mesmo tempo para conseguir alterar os dados com sucesso.
Atualmente, de acordo com a última reunião do Ethereum sobre PeerDAS, a equipe do cliente Lighthouse já integrou o branch do DAS ao branch principal e está testando para garantir a compatibilidade com o PeerDAS. Um branch geralmente é uma versão independente do código usada para desenvolver e testar novas funcionalidades ou melhorias; ao ser integrado ao branch principal, significa que a funcionalidade ou melhoria já foi desenvolvida, está estável e pode ser incorporada ao código principal.
Aviso Legal: o conteúdo deste artigo reflete exclusivamente a opinião do autor e não representa a plataforma. Este artigo não deve servir como referência para a tomada de decisões de investimento.
Talvez também goste
Uniswap considera queimar tokens do protocolo enquanto sua arrecadação de taxas em 2025 se aproxima de US$ 1 bilhão
Desde o início do segundo trimestre, as taxas mensais geradas pela Uniswap cresceram em média 17%. O trecho a seguir foi extraído do boletim Data and Insights do The Block.

Ethereum Foundation revela o trabalho mais recente na 'Interop Layer' para fazer o ecossistema L2 'parecer uma única blockchain'
A equipe de Account Abstraction da Ethereum Foundation publicou um post no blog nesta terça-feira destacando os objetivos para a próxima Ethereum Interop Layer, que agora está aberta para testes.

Block está posicionada para aproveitar a crescente demanda por liquidez sob demanda em aplicativos fintech, dizem analistas
Resumo rápido: O negócio Square da Block está mostrando sinais iniciais de recuperação, à medida que novos modelos de empréstimos e uma distribuição mais ampla ajudam a reduzir a diferença entre o volume de pagamentos e o lucro. As crescentes capacidades cripto do Cash App, incluindo pagamentos via Lightning e stablecoins, conectam ainda mais seus ecossistemas de consumidores e comerciantes.

O OCC afirma que bancos podem manter certas criptomoedas para pagar taxas de gás em sua orientação mais recente
Resumo rápido: Os bancos podem ter que pagar taxas de rede como parte de suas operações e manter criptomoedas em seus balanços para pagar essas taxas, informou o órgão em sua Carta Interpretativa 1186 nesta terça-feira. O OCC mencionou o Ethereum como exemplo, dizendo que a rede Ethereum exige que as transações sejam denominadas em ETH.

