O que é a camada de disponibilidade de dados?

As tarefas principais das blockchains modulares e monolíticas incluem executar transações, alcançar consenso sobre a ordenação das transações e garantir a disponibilidade dos dados transacionais. A última parte—disponibilidade de dados—é crítica para blockchains e representa o foco deste artigo.

Disponibilidade de dados refere-se à ideia de que todos os dados relacionados a transações estão disponíveis para os nós da rede blockchain. A disponibilidade de dados é importante porque permite que os nós verifiquem transações de forma independente e computem o estado da blockchain sem a necessidade de confiar uns nos outros.

Este guia explicará em detalhes o que significa disponibilidade de dados e por que resolver o "problema de disponibilidade de dados" importa. Você também aprenderá o papel que as camadas de disponibilidade de dados desempenham no escalonamento de blockchains e as diferentes soluções propostas para resolver o problema de disponibilidade de dados.

O que significa disponibilidade de dados?

Disponibilidade de dados em blockchains refere-se à capacidade dos nós de baixar os dados contidos em todos os blocos propagados através de uma rede peer-to-peer. Entender disponibilidade de dados requer compreender os processos atuais de verificação de blocos em blockchains.

Como funciona a verificação de blocos?

Primeiro, o produtor de blocos vai:

1. Pegar transações do mempool‍
2. Produzir um novo bloco com essas transações
3. Transmitir o novo bloco para a rede P2P para ser adicionado à chain

Um produtor de blocos é chamado de "miner" em uma rede Proof-of-Work e "validator" em uma rede Proof-of-Stake.

Em seguida, os nós validadores (também conhecidos como full nodes) vão:

1. Baixar as transações do bloco recém-proposto
2. Reexecutar as transações para confirmar a conformidade com as regras de consenso
3. Adicionar o bloco ao topo da chain assim que a rede considerar o bloco válido

A ilustração a seguir usa Bitcoin como exemplo de verificação de blocos:

Mas e se um proposer de blocos se recusasse a publicar os dados das transações e transmitisse apenas os cabeçalhos dos blocos, que contêm metadados sobre as transações, mas não as transações em si?

Nesse cenário, os full nodes seriam incapazes de verificar a integridade dos blocos propostos. Além disso, os light nodes que baixam apenas os cabeçalhos dos blocos poderiam ser facilmente enganados a aceitar blocos inválidos.

Para evitar esse problema, as blockchains—especialmente as chains monolíticas—exigem que os block proposers disponibilizem os dados dos blocos para o restante da rede.

Além de possibilitar a segurança, as regras de disponibilidade de dados incentivam o "trustlessness": os peers podem verificar transações e blocos de forma independente, em vez de confiar em outros na rede.

Quais são os desafios da disponibilidade de dados?

Os desafios apresentados pela necessidade de disponibilidade de dados são: exigir que os nós baixem e verifiquem dados reduz o throughput, e usar armazenamento on-chain para uma quantidade cada vez maior de informação limita o número de entidades que podem operar infraestrutura de nó.

As blockchains monolíticas garantem disponibilidade de dados armazenando dados de estado de forma redundante em múltiplos nós, de modo que um peer que precise desses dados só precisa solicitá-los a outro peer. Mas essa implementação ingênua de disponibilidade de dados tem um problema.

Forçar um grande número de nós da rede a baixar, verificar e armazenar os mesmos dados reduz drasticamente o throughput das blockchains. É por isso que o Ethereum consegue processar apenas 15-20 transações por segundo e a velocidade de processamento do Bitcoin fica em torno de 5-7 transações por segundo.

O armazenamento de dados on-chain também leva a aumentos exponenciais no tamanho da blockchain, o que aumenta ainda mais os requisitos de hardware para full nodes que precisam armazenar quantidades sempre crescentes de estado.

O aumento dos custos de hardware de alta especificação tende a reduzir o número de indivíduos dispostos a operar nós, o que aumenta diretamente o risco de centralização.

Disponibilidade de dados e escalonamento de blockchains

A disponibilidade de dados também é relevante no contexto da escalabilidade de blockchains. As chains modulares são frequentemente projetadas para escalar throughput separando a disponibilidade de dados do consenso e da execução. Sob esse arranjo, os nós não precisam armazenar dados da blockchain, removendo algumas das restrições descritas na seção anterior.

No entanto, a rede ainda precisa garantir que todos os dados dos blocos estejam disponíveis para as partes interessadas. Isso forma a base do problema de disponibilidade de dados: "Como podemos saber que os dados por trás de cada bloco foram publicados sem ter acesso ao bloco inteiro?"

Discutiremos soluções para o problema de disponibilidade de dados em uma seção posterior. Por enquanto, vamos explorar o conceito de "camada de disponibilidade de dados" e suas implicações para blockchains.

O que é a camada de disponibilidade de dados?

Em blockchains, uma camada de disponibilidade de dados é um sistema que armazena e fornece consenso sobre a disponibilidade dos dados da blockchain. A "camada de disponibilidade de dados" refere-se ao local onde os dados de transação são armazenados.

Existem dois tipos de camadas de disponibilidade de dados:

1. Camada de disponibilidade de dados on-chain‍

Essa é a abordagem padrão entre muitas blockchains, na qual os dados são armazenados on-chain pelos nós que executam as transações. Embora isso garanta alta disponibilidade de dados, limita a descentralização e a escalabilidade.

2. Camada de disponibilidade de dados off-chain‍

Essa abordagem requer o armazenamento dos dados de transação fora da rede blockchain original. Uma camada de disponibilidade de dados off-chain pode ser outra blockchain ou qualquer sistema de armazenamento de dados escolhido pelos desenvolvedores. Nesse caso, a camada de disponibilidade de dados foca no armazenamento de dados, não na execução.

Como a camada de disponibilidade de dados ajuda o Ethereum a escalar?

Sharding é uma abordagem de escalonamento de blockchain que envolve dividir uma rede em várias sub-chains operando em paralelo. Os nós em cada sub-chain lidam com tarefas diferentes com o objetivo de alcançar um uso eficiente dos recursos computacionais.

O roteiro de escalonamento atual do Ethereum inclui planos para implementar data sharding—um sistema no qual vários clusters de nós armazenam pedaços distintos de dados. Haverá 64 shard chains operando de forma independente, com os nós baixando apenas os dados postados no shard a que foram designados. Isso significa que os full nodes não precisarão mais armazenar os mesmos dados, como acontece atualmente.

Com o sharding, o Ethereum empregará múltiplas camadas de disponibilidade de dados em vez de armazenar dados de estado em um único local. Os blocos não precisarão se propagar por toda a rede, e apenas um conjunto limitado de nós será necessário para verificar os dados de cada bloco. Isso se traduz diretamente em escalabilidade, pois a rede será capaz de processar transações mais rapidamente.

Além disso, armazenar dados entre múltiplas camadas descentraliza ainda mais o Ethereum.

Os full nodes atualmente armazenam a blockchain inteira, que tem aproximadamente 1TB de dados, de acordo com estatísticas recentes, mas precisarão armazenar apenas 1/64 dos dados da chain com 64 shards em operação. Isso poderia potencialmente reduzir os requisitos de armazenamento para full nodes e aumentar o número de validators no Ethereum.

Como a camada de disponibilidade de dados funciona com rollups?

Rollups escalam o Ethereum movendo a computação e o armazenamento de estado para fora do ambiente de execução do Ethereum: a Ethereum Virtual Machine. A EVM aceita apenas os resultados da computação off-chain e os aplica ao seu estado sem precisar reexecutar as transações, melhorando assim as velocidades de processamento e reduzindo custos.

O que torna os Rollups mais seguros que outras soluções de escalonamento do Ethereum, incluindo sidechains ou Plasma, é a dependência deles do Ethereum para disponibilidade de dados. Além de publicar os resultados das transações no Ethereum, optimistic rollups e zero-knowledge rollups também publicam dados de transação na Layer 1 como CALLDATA.

Os dados de blocos postados de um rollup para o Ethereum ficam publicamente disponíveis, permitindo que qualquer pessoa execute transações e valide a rollup chain.

Isso também promove a resistência à censura, pois os dados postados podem ser usados por potenciais produtores de blocos para reconstruir o estado da chain e começar a produzir novos blocos. Devido a essa medida, nenhum único operador de Layer 2 pode congelar arbitrariamente a chain e censurar usuários no rollup.

Com a camada de disponibilidade de dados fornecendo segurança, os rollups podem otimizar para escalabilidade. Por exemplo, um rollup pode optar por blocos grandes e tempos de bloco mais rápidos para acelerar as velocidades de processamento.

Embora isso aumente os requisitos de hardware para os nós (a maioria dos rollups tem alguns "supernodes" executando transações), a disponibilidade dos dados de estado permite que qualquer pessoa conteste transições de estado inválidas ou produza blocos para prevenir censura.

Como as camadas de disponibilidade de dados funcionam com blockchains modulares?

Uma blockchain modular é uma blockchain que lida com uma função específica, como execução, consenso ou disponibilidade de dados, e depende de outras blockchains e sistemas off-chain para realizar as demais tarefas. O stack de blockchain modular compreende diferentes chains modulares que trabalham juntas de várias formas para alcançar objetivos definidos.

A camada de disponibilidade de dados em um stack de blockchain modular é geralmente responsável por armazenar dados de transação, embora também possa fornecer consenso sobre a ordenação das transações. Por exemplo, blockchains modulares focadas em execução (por exemplo, rollups e validiums) dependem de camadas de disponibilidade de dados off-chain para armazenar os dados por trás das atualizações de estado.

Uma camada de disponibilidade de dados em si é uma chain modular, já que se concentra em armazenar dados e terceiriza a execução para outras chains. Diferente de blockchains regulares, uma camada de disponibilidade de dados pura não verifica a validade dos dados publicados pelos produtores de blocos. Os nós só precisam chegar a um consenso sobre a ordenação das transações e confirmar que as taxas corretas foram pagas.

O que as camadas de disponibilidade de dados significam para desenvolvedores Web3?

A existência de uma camada de disponibilidade de dados separada traz benefícios importantes para desenvolvedores de blockchain, incluindo ciclos de desenvolvimento mais rápidos e taxas de usuário mais baratas.

1. Ciclos de desenvolvimento mais rápidos

Desenvolvedores lançando novas blockchains ou chains específicas de aplicação podem alcançar propriedades de segurança relevantes desde o início ao usar uma camada de disponibilidade de dados. A segurança de uma blockchain geralmente é medida pela distribuição dos nós validadores, mas alcançar uma distribuição ideal de validators nos estágios iniciais não é realista.

Em vez disso, essas novas blockchains podem focar em execução e settlement enquanto dependem de redes de disponibilidade de dados existentes para segurança. Assim, mesmo que um pequeno número de nós esteja executando a chain, sua capacidade de agir de forma maliciosa publicando transações inválidas e censurando usuários é limitada.

Isso ocorre porque os dados de estado necessários para computar fraud proofs e validity proofs para verificar a execução têm sua disponibilidade garantida. A disponibilidade de dados também facilita a sincronização com o estado da blockchain, o que é um requisito para produzir novos blocos.

2. Taxas de usuário mais baratas

A competição por blockspace limitado no Ethereum tem elevado as taxas de transação, o que não é ideal para aplicações descentralizadas que precisam postar uma grande quantidade de dados on-chain. Em vez de publicar dados no Ethereum, uma dApp pode armazenar dados de forma mais barata em uma camada otimizada para disponibilidade de dados.

As taxas para usar camadas de disponibilidade de dados são mais baixas por dois motivos: os nós precisam cobrar taxas menores para recuperar as despesas com hardware, e as redes de disponibilidade de dados podem aumentar o tamanho dos blocos, o que significa que mais transações podem ser incluídas nos blocos.

1. Os nós precisam de hardware menos caro

Os nós se preocupam apenas com o armazenamento de dados e não precisam investir na largura de banda ou no hardware necessários para executar transações. Assim, os nós não sofrem pressão para cobrar taxas altas para recuperar o investimento em hardware.

2. Redes de disponibilidade de dados podem aumentar o tamanho dos blocos

Redes de disponibilidade de dados podem aumentar o tamanho dos blocos sem prejudicar a descentralização e a segurança graças à amostragem de disponibilidade de dados.

A amostragem de disponibilidade de dados permite que os nós amostrem aleatoriamente um bloco para confirmar sua disponibilidade sem baixar todos os dados. Uma competição menor por blockspace significa que armazenar dados em uma blockchain de disponibilidade de dados é, em média, mais barato.

Quais são os diferentes tipos de soluções de disponibilidade de dados?

As soluções para o problema de disponibilidade de dados geralmente seguem duas abordagens: modificar o armazenamento de dados on-chain ou armazenar dados off-chain. Exploramos as duas classes de soluções de disponibilidade de dados abaixo.

1. Armazenamento on-chain modificado

O armazenamento on-chain modificado requer alterar a forma como os dados são armazenados on-chain para alcançar eficiência e segurança. Uma forma de armazenamento on-chain modificado refere-se ao processo de data sharding discutido anteriormente.

Em blockchains com sharding, os nós baixam e armazenam apenas os dados postados em um shard específico. Em outras palavras, os validators operam um full node para um shard e atuam como light-client para os demais shards.

A pergunta óbvia aqui é: "Como os nós podem ter certeza de que os dados dos outros shards estão disponíveis sem baixar esses blocos?"

É aqui que entra a amostragem de disponibilidade de dados.

O que é amostragem de disponibilidade de dados (das)?

A amostragem de disponibilidade de dados é um mecanismo para verificar a disponibilidade de um bloco sem precisar baixá-lo por completo. Os nós aplicam a amostragem de disponibilidade de dados baixando partes aleatórias de um bloco para ver se estão disponíveis.

Com muitos nós amostrando aleatoriamente um bloco, a probabilidade de esconder dados do bloco diminui. Se um nó descobrir que um pedaço do bloco está indisponível, ele pode levantar um alarme e alertar outros nós.

Embora a amostragem de disponibilidade de dados possa dar aos nós alta certeza estatística de que os dados de um bloco estão disponíveis, ela não consegue descartar completamente ataques de retenção de dados. Um ataque de retenção de dados acontece quando produtores de blocos propõem novos blocos, mas não publicam todos os dados de transação.

Mesmo que um produtor de blocos publique a maior parte do bloco, esconder uma pequena fração dos dados ainda tem implicações de segurança. E se um operador de rollup realizar uma transação inválida transferindo uma grande quantidade de tokens de usuários para si mesmo e retiver os dados necessários para contestações?

Para ter garantias de segurança maiores contra a retenção de dados, combinamos amostragem de disponibilidade de dados com erasure coding.

O que é erasure coding?

Erasure coding é uma primitiva criptográfica para aumentar a integridade e a disponibilidade de dados que envolve duplicar um conjunto de dados adicionando peças redundantes (chamadas de erasure codes), de modo que qualquer combinação das peças redundantes possa ajudar a recuperar os dados originais.

As shard chains no Ethereum publicam dados de transação usando "blobs" (binary large objects), que são semelhantes a blocos. Antes de publicar um blob, o produtor de blocos precisa estender os dados originais via erasure coding. Dessa forma, qualquer pessoa pode reconstruir o bloco inteiro com acesso a alguns dos erasure codes.

O erasure coding torna mais difícil realizar ataques de retenção de dados. Com blocos com erasure coding, os nós precisam apenas de uma pequena fração para recuperar os dados originais. Assim, um produtor de blocos precisaria esconder uma grande parte do conjunto total de dados—mais de 50%—para conseguir esconder dados com sucesso.

2. Armazenamento de dados off-chain

O armazenamento de dados off-chain envolve armazenar dados em outro lugar para evitar sobrecarregar os nós. As soluções de armazenamento de dados off-chain têm duas vertentes: comitês de disponibilidade de dados (DAC) e redes de disponibilidade de dados.

1. Comitês de disponibilidade de dados (DACs)

Um comitê de disponibilidade de dados (DAC) é uma coleção de entidades com permissão encarregadas de manter cópias dos dados da blockchain off-line. O DAC costuma ser composto por entidades confiáveis designadas para essa função.

Os produtores de blocos são obrigados a enviar dados de transação aos membros do DAC ao realizar transições de estado. Isso reduz o risco de centralização porque o DAC pode disponibilizar os dados aos usuários—especialmente se o produtor de blocos começar a agir de forma maliciosa.

Os Validiums, que são uma solução de escalonamento do Ethereum semelhante aos ZK-rollups, usam DACs para garantir disponibilidade de dados. Além de computar provas de conhecimento zero para verificar lotes de transações, os block proposers precisam obter atestações (assinaturas) dos membros do DAC. Essa "prova de disponibilidade" é verificada junto com a validity proof no Ethereum antes que novos lotes de transações sejam aceitos.

Exemplos de projetos que usam DACs incluem DiversiFi e ImmutableX.

Embora os comitês de disponibilidade de dados ajudem a resolver o problema de disponibilidade de dados até certo ponto, eles têm certas desvantagens. O DAC costuma ser pequeno, o que facilita para atores maliciosos comprometerem o grupo. E como os membros do DAC são entidades "confiáveis", não há um sistema em vigor para punir má conduta.

2. Redes de disponibilidade de dados

As redes de disponibilidade de dados visam descentralizar o processo de armazenamento de dados da blockchain e eliminar pressupostos de confiança. As redes de disponibilidade de dados são semelhantes aos comitês de disponibilidade de dados, exceto por três diferenças fundamentais: arquitetura sem permissão, trustlessness e tolerância a falhas.

Arquitetura sem permissão

A rede de disponibilidade de dados costuma ser uma blockchain com o único propósito de ordenar transações e armazenar dados.

Redes de disponibilidade de dados, como Celestia e Polygon Avail, usam um sistema Proof-of-Stake que permite que qualquer pessoa se torne um gerenciador de disponibilidade de dados. Para isso, os usuários só precisam depositar o stake necessário para começar a participar da blockchain.

Trustlessness

Redes de disponibilidade de dados Proof-of-Stake usam incentivos cripto-econômicos para garantir que os nós ajam honestamente. Todo nó encarregado de armazenar dados precisa fazer stake de fundos em um smart contract, que pode ser slashed caso não forneça os dados quando solicitado. Esse recurso elimina os pressupostos de confiança que existem em comitês de disponibilidade de dados.

Tolerância a falhas

Redes de disponibilidade de dados Proof-of-Stake costumam ter conjuntos de participação maiores do que comitês de disponibilidade de dados. Isso dificulta que atores maliciosos comprometam o grupo e realizem ataques de retenção de dados.

Conclusão

A disponibilidade de dados desempenha um papel fundamental na capacidade das blockchains de permanecerem funcionais e seguras. Especialmente no contexto de blockchains modulares, as camadas de disponibilidade de dados permitem descentralização e segurança relevantes.

Os planos futuros de escalabilidade do Ethereum também dependem da sua capacidade de armazenamento de dados. Os rollups são limitados pelo throughput de dados na chain principal, daí a introdução do data sharding e outras atualizações para melhorar o desempenho do Ethereum como camada de disponibilidade de dados para soluções de Layer 2.