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
Andrew Kang critica Tom Lee: 5 razões para alta do ETH que são de fazer rir e chorar

A jornada de 7 anos da Wemade no blockchain culmina em uma iniciativa global de stablecoin em KRW
A jornada de sete anos da Wemade no blockchain culmina em uma ambiciosa plataforma de stablecoin em KRW, voltada para pagamentos globais relacionados à K-culture e transações no setor de turismo.

A alocação de 3% do TGE da Meteora para stakers de JUP é uma jogada inteligente de liquidez?
A proposta de TGE da Meteora visa recompensar os stakers de JUP com NFTs de LP em vez de tokens, impulsionando a liquidez, mas gerando debates sobre a justiça dessa medida.

Atualização da Celestia e Prova de Governança: Um Ponto de Virada para TIA?
A atualização Matcha da Celestia e a proposta PoG podem transformar o TIA em um ativo deflacionário. No entanto, a execução e a adoção serão determinantes para saber se o ativo irá se destacar.

Populares
MaisPreços de criptomoedas
Mais








