Explicação sobre Amostragem de Disponibilidade de Dados: como o DAS escala blockchains

Porque é que as blockchains esbarram num limite ao escalar

Todas as blockchains têm um estrangulamento oculto que nada tem a ver com transações por segundo. Antes que um bloco possa ser considerado fiável, cada nó que se preocupa com a segurança tem de ter a certeza de que os dados no seu interior existem de facto e podem ser transferidos. Se um produtor de blocos publicar apenas o cabeçalho do bloco e esconder as transações subjacentes, ninguém consegue verificar a cadeia, e um proponente malicioso poderia, em teoria, roubar fundos ou reescrever a história.

Durante a maior parte da história das criptomoedas, a regra era simples: para verificar a cadeia, transferia-se a cadeia. Os utilizadores do Bitcoin e da Ethereum inicial corriam nós completos que processavam cada byte. Funcionava a pequena escala, mas à medida que os tamanhos dos blocos cresciam para acomodar mais utilizadores, o custo de manter um nó subiu para centenas de gigabytes e, por fim, para terabytes de disco e largura de banda. A descentralização foi-se erodindo silenciosamente, porque só operadores bem apetrechados conseguiam acompanhar.

O problema da disponibilidade de dados é o nome formal para esta tensão. Uma blockchain precisa de publicar dados suficientes para que qualquer pessoa a possa verificar, mas publicar dados a mais afasta os utilizadores comuns da verificação. Soluções de escalabilidade como os rollups agravam o problema, em vez de o resolverem, porque publicam dados de transações comprimidos de volta na cadeia-mãe. Mais rollups, mais dados, e de repente a cadeia-mãe está a asfixiar com o próprio sucesso.

É esse o muro que a DAS foi concebida para derrubar. O objetivo não é fazer com que cada nó transfira menos dados no sentido trivial de comprimir transações. O objetivo é tornar a verificação barata o suficiente para que clientes leves, o nível carteira-num-portátil, possam confirmar blocos grandes com confiança, permitindo ao mesmo tempo que a rede no seu conjunto escale para dezenas de milhares de transações por segundo.

O que os clientes leves podiam e não podiam fazer antes da DAS

Antes de a amostragem existir, os clientes leves levavam uma vida precária. Um cliente leve é qualquer nó que não transfere a cadeia completa, mas que, em vez disso, verifica os cabeçalhos dos blocos e pede provas sobre transações específicas a nós completos. As carteiras móveis, as extensões de navegador e os dispositivos embebidos comportam-se, na prática, como clientes leves.

O problema é que um cliente leve pode ser enganado. Um pequeno conjunto de nós completos pode fornecer a um cliente leve um cabeçalho que parece válido e provas que parecem corretas, enquanto os dados subjacentes do bloco estão, na verdade, a ser retidos ao resto da rede. O cliente leve não tem forma de saber, porque nunca pediu para ver os dados completos. Este é o clássico ataque de disponibilidade de dados, e é a razão pela qual, durante anos, os clientes leves foram tratados como cidadãos de segunda classe, úteis para pagamentos, mas não para decisões críticas de segurança.

Para resolver isto, os programadores precisavam de uma forma de um cliente leve exigir prova de que os dados por trás de um cabeçalho existem de facto algures na rede, sem ter de transferir os dados em si. Pedir a nós completos não basta, porque os nós completos podem conluiar-se. Pedir a todos os nós completos é simplesmente transferir os dados. Tinha de ser inventada uma abordagem estatística.

A ideia central: amostragem aleatória como garantia probabilística

A amostragem de disponibilidade de dados assenta numa intuição única que parece quase demasiado simples para funcionar. Se um bloco for dividido em muitas pequenas partes e um cliente leve verificar aleatoriamente algumas dessas partes, a probabilidade de um atacante estar a esconder sequer uma parte torna-se insignificante à medida que mais clientes leves fazem amostragens.

Imagine um bloco que foi dividido em 1.000 partes. Um cliente leve escolhe 10 partes aleatórias e pede-as à rede. Se as 10 voltarem, o cliente ainda não terminou. Apenas sabe que essas 10 partes existem. Mas multiplique isso por milhões de clientes leves, cada um a escolher as suas próprias partes aleatórias, e a hipótese de que alguma parte escondida sobreviva a todos esses pedidos colapsa para zero. Após amostras independentes suficientes, a rede pode tratar o bloco como disponível com quase certeza matemática, mesmo que nenhum nó individual tenha descarregado a coisa toda.

Esta é a garantia probabilística no centro do DAS. Não é uma promessa de que cada nó viu cada byte. É uma promessa de que os dados existem, distribuídos pela rede, e de que qualquer tentativa de esconder uma parte exigiria mentir a tantas amostras aleatórias que a probabilidade de escapar impune é, para efeitos práticos, zero.

Codificação de apagamento: o truque que faz a amostragem funcionar

A amostragem aleatória por si só não seria suficiente. Se um bloco for simplesmente fatiado em 1.000 partes brutas, um atacante só precisa de esconder uma delas para partir a cadeia, e a hipótese de um único cliente leve acertar na parte escondida é pequena. Para fazer as contas funcionar, as blockchains adicionam redundância de propósito, usando uma técnica chamada codificação de apagamento.

O esquema mais comum é a codificação Reed-Solomon, um método de correção de erros com décadas de existência, originalmente concebido para CDs e comunicações no espaço profundo. A ideia é pegar nos dados originais do bloco, tratá-los como um polinómio e estender esse polinómio para que a mesma informação fique codificada em mais pontos de dados do que os originais. Com um código Reed-Solumon configurado para duplicar os dados, um bloco original de 1.000 partes torna-se um bloco estendido de 2.000 partes, em que qualquer conjunto de 1.000 dessas partes é suficiente para reconstruir a coisa toda.

Porque é que isto importa: agora um atacante que queira reter dados tem de reter pelo menos metade do bloco estendido, não apenas uma parte. Os clientes leves, entretanto, continuam a fazer amostragens aleatórias do conjunto estendido. A probabilidade de falhar uma parte escondida diminui drasticamente, porque o atacante tem de esconder uma parte muito maior. A combinação de codificação de apagamento com amostragem aleatória é o que transforma uma garantia fraca numa garantia forte, e é o coração técnico de cada design de DAS em produção ou em testes sérios.

PeerDAS: a evolução ponto-a-ponto do DAS na Ethereum

A abordagem atual da Ethereum ao DAS chama-se PeerDAS, e o nome sugere a mudança arquitetónica. Num design de DAS ingénuo, cada nó completo continua a armazenar o bloco estendido inteiro. A amostragem é apenas para clientes leves, e os nós completos carregam o fardo do armazenamento. O PeerDAS inverte isso. No PeerDAS, os dados estendidos também são fragmentados pela rede ponto-a-ponto, de modo que cada nó completo armazena apenas um subconjunto do espaço total de blobs, e os dados são reconstruídos sob demanda, pedindo as fatias aos pares.

Para a Ethereum, os dados relevantes são o que ela chama de blobs, os blocos de dados temporários que os rollups publicam a baixo custo. O PeerDAS permite que os validadores armazenem apenas algumas das colunas de uma matriz de blobs com codificação de apagamento e continuem a poder servir qualquer amostra aleatória à rede. A garantia matemática é a mesma do DAS clássico, mas o custo de recursos é distribuído, para que a rede possa aumentar a capacidade total de blobs sem aumentar os requisitos por nó ao mesmo ritmo.

Outros ecossistemas usam a mesma ideia com nomes diferentes. A Celestia, frequentemente referenciada pelo seu ticker TIA, foi a primeira rede em produção desenhada de raiz à volta do DAS, apresentando-se como uma camada modular de disponibilidade de dados para a qual os rollups podem pagar para publicar. A NEAR explorou designs de estilo DAS como parte do seu roteiro de fragmentação. Em todos eles, aparece o mesmo padrão: codificar os dados com apagamento, amostrar aleatoriamente e deixar a probabilidade fazer o trabalho de segurança que antes exigia replicação total.

O que isto significa na prática: dezenas de milhares de TPS

Assim que a disponibilidade de dados é barata e comprovável, o resto da história de escalabilidade desbloqueia. Os rollups, o padrão de escalabilidade dominante na Ethereum e cada vez mais noutras cadeias, estão estrangulados pela quantidade de dados que conseguem publicar na sua cadeia-mãe. Quando a camada de dados da cadeia-mãe pode crescer porque o DAS torna a verificação barata, os rollups podem publicar mais transações comprimidas por bloco, e a capacidade efetiva sobe.

Os números citados pelos investigadores da Ethereum, frequentemente na ordem das dezenas de milhares de transações por segundo em L2, dependem deste tipo de escalabilidade de dados. A mesma dinâmica aplica-se à Celestia e a qualquer cadeia que adote uma arquitetura modular, em que a execução e a disponibilidade de dados são separadas e otimizadas de forma independente. Sem DAS, essas afirmações de capacidade exigiriam centralizar os nós completos ou confiar num pequeno comité de disponibilidade de dados, duas hipóteses que são más trocas.

Há também um efeito de segunda ordem, mais discreto. À medida que os clientes leves se tornam fiáveis, o universo de dispositivos que podem verificar a cadeia expande-se. Telemóveis, navegadores e até hardware embutido podem participar na segurança. Isso é bom para a descentralização a longo prazo, porque reduz a alavancagem dos grandes operadores de nós e torna a rede mais difícil de censurar ou capturar.

As desvantagens honestas que deve conhecer

A DAS é poderosa, mas não é magia, e compreender os seus limites importa mais do que memorizar os seus benefícios. A garantia probabilística é real, mas continua a ser uma probabilidade. Um light client que executou apenas algumas amostras não está totalmente protegido. As implementações dos clientes têm de escolher cuidadosamente o número de amostras, e a rede tem de assumir que existem, em qualquer momento, light clients independentes suficientes online para que a matemática se mantenha.

A PeerDAS, em particular, introduz novas premissas ponto a ponto. O sistema só funciona se uma fração suficientemente grande de nodos estiver online para servir os seus slices atribuídos. Partições de rede prolongadas, ataques de negação de serviço direcionados contra pares ou, simplesmente, uma descoberta de pares fraca podem degradar a garantia. Existem mitigações, incluindo pontuação de pares, provas de custódia de dados e modos de contingência, mas são áreas de investigação ativas e não problemas resolvidos.

Há também considerações económicas. À medida que a capacidade de dados cresce, a questão de quem paga pelo armazenamento e pela largura de banda torna-se mais premente. A Ethereum responde a isto com taxas de blob que são queimadas ao longo do tempo, e a Celestia utiliza um modelo semelhante. Nenhum destes mecanismos é perfeito, e estão a evoluir a par do design técnico. Qualquer pessoa que avalie uma cadeia que utilize DAS deve dar tanta atenção ao seu mercado de taxas e estrutura de incentivos quanto às suas alegações criptográficas.

Como acompanhar o data availability sampling de forma inteligente

O data availability sampling está a passar dos artigos de investigação para redes ativas, e as notícias sobre o tema mudam todas as semanas. As testnets da PeerDAS da Ethereum, as atualizações da Celestia e designs concorrentes da NEAR e de outros projetos geram um fluxo constante de anúncios, muitos deles envoltos em hype. Distinguir que mudanças são reais e quais são marketing exige mais do que uma passagem rápida pelo Twitter. A Zippfeed destaca manchetes sobre data availability e escalabilidade com classificação de sentimento (bullish, neutral ou bearish) e uma pontuação de importância, para que possa distinguir os marcos técnicos do ruído sem ter de ler todas as threads.