Como o PeerDAS melhorará a disponibilidade de dados do Ethereum?

Para garantir uma gestão eficiente dos dados e uma validação segura, o Ethereum evoluiu de DA para DAS, culminando na introdução do PeerDAS.

Autor: 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 devido à preocupação de atrasar a atualização das árvores Verkle. No entanto, nesta reunião, os desenvolvedores voltaram a sugerir essa ideia, pois desejam incluir mais propostas de melhoria (EIP) no fork Pectra. A proposta é dividir o hard fork em duas partes: a primeira incluirá todos os EIPs atualmente presentes no Pectra Devnet 3, enquanto a segunda parte do fork incluirá 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ções contidos nesses blocos estejam acessíveis e disponíveis para outros participantes da rede. A disponibilidade de dados é um fator crucial para a segurança da 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 verificação.

Quando um novo bloco é transmitido, todos os nós participantes baixam e verificam os dados do bloco. Esse modelo funciona quando a rede é pequena, mas, à medida que a blockchain cresce, o volume de dados se torna enorme, aumentando continuamente o armazenamento necessário em cada nó e, consequentemente, os requisitos de hardware. Para permitir que nós leves (como dispositivos móveis ou computadores pessoais) também participem da validação dos blocos, a blockchain introduziu a tecnologia de sharding.

O sharding divide toda a rede blockchain em várias pequenas “shards”. Cada shard processa apenas seus próprios dados, sem precisar lidar com os dados de toda a blockchain. Assim, um nó individual só precisa processar os dados do seu shard. No entanto, como cada shard processa apenas 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 estão disponíveis e que outros nós podem verificar a validade desses dados? Por exemplo, um nó de um shard pode publicar um novo bloco, 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: Verificando a disponibilidade de dados por amostragem parcial

Para lidar com o problema de disponibilidade de dados nos shards, foi proposta a técnica de amostragem de disponibilidade de dados (Data Availability Sampling, DAS), cujo conceito central é verificar 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 verificar sua disponibilidade. Se o nó conseguir obter e verificar com sucesso esses fragmentos de dados aleatórios, pode-se inferir que todos os dados do bloco estão disponíveis.

Para suportar essa verificação por amostragem, os dados do bloco geralmente utilizam a codificação RS. Esse tipo de codificação permite que, mesmo com a perda de parte dos dados, seja possível reconstruir o dado completo. Assim, mesmo que o nó baixe apenas parte dos dados do bloco, 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 verificação por amostragem, permitindo que nós leves também participem da validação dos blocos.

O layer DA, como o da Celestia, utiliza essas tecnologias. Envolve principalmente RS encoding + validity proof + DAS.

• RS encoding (Reed-Solomon Encoding): Este 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; mesmo que parte dos dados seja perdida, o restante é suficiente para reconstruir o dado 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 verificação for bem-sucedida, é possível decodificar todo o dado sem erros.
• DAS (Data Availability Sampling): Nós leves realizam amostragem aleatória de fragmentos RS codificados dentro do bloco, verificando a disponibilidade desses fragmentos e, assim, 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, que realiza a amostragem de disponibilidade de dados por meio de uma rede peer-to-peer, composta por vários nós que se comunicam diretamente. No DAS, cada nó realiza a verificação de amostragem de dados de forma independente, enquanto o PeerDAS otimiza esse processo, permitindo que os nós colaborem para compartilhar e validar os dados do bloco, aumentando ainda mais a eficiência da validação. Os nós não sã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, os nós não precisam assumir sozinhos todo o trabalho de validação, mas sim dividir a tarefa por meio da cooperação, reduzindo ainda mais a carga de cada nó. 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 simultaneamente para conseguir alterar os dados.

Atualmente, de acordo com a mais recente reunião do Ethereum sobre PeerDAS, a equipe do cliente Lighthouse do Ethereum já integrou o branch do DAS ao branch principal e está testando para garantir a compatibilidade com o PeerDAS. Um branch normalmente é uma versão independente do código usada para desenvolver e testar novas funcionalidades ou melhorias; integrá-lo ao branch principal significa que a funcionalidade ou melhoria já foi desenvolvida, considerada estável e pode ser incorporada ao código principal.