Os debates sobre soluções de escalabilidade de blockchains geralmente giram em torno de desempenho, finalidade, taxas de transação e segurança (parte do trilema da blockchain). Mas há uma questão mais profunda subjacente às tentativas de escalabilidade de blockchains: a disponibilidade de dados.
Disponibilidade de dados em blockchains é uma garantia de que os dados dos blocos recém-propostos estejam acessíveis a todos os participantes da rede. A disponibilidade de dados é fundamental para operações seguras e sustentáveis: se os nós líderes (ou seja, produtores de blocos) avançarem o estado da blockchain sem publicar dados de transações, os outros nós não poderão verificar a validade das transações nem a correção das transições de estado.
A disponibilidade de dados também é importante para a vivacidade (liveness; comportamento contínuo e ininterrupto de um sistema): a retenção de dados de transações impede que outras pessoas interpretem o estado da blockchain (por exemplo, verificar saldos de contas) ou interajam com ela (por exemplo, adicionar novos blocos). Nesse cenário, os usuários não podem interagir com a cadeia - anulando a propriedade de vivacidade.
As soluções para resolver o problema de disponibilidade de dados incluem forçar os nós a publicar dados de transações na rede ao propor blocos e armazenar dados de transações de forma redundante em vários nós sem comprometer a largura de banda.
O primeiro garante a segurança, pois elimina a possibilidade de ocultar transações mal-intencionadas em blocos, enquanto o segundo garante a vivacidade: os dados necessários para reconstruir o estado da cadeia têm a garantia de estar disponíveis em vários pares da rede (peers). Mas o armazenamento de dados da blockchain dessa forma limita a escalabilidade devido à largura de banda. Como todos os nós devem processar os mesmos dados de transação, o tempo necessário para processar cada transação aumenta linearmente em proporção ao número de nós da blockchain.
A escalabilidade de blockchains, portanto, exige o gerenciamento eficiente da disponibilidade de dados sem comprometer a escalabilidade e a segurança. A otimização de qualquer solução de escalabilidade depende em grande parte de sua abordagem em relação à disponibilidade de dados. Os comitês de disponibilidade de dados (DACs) são uma solução para o problema da disponibilidade de dados, que está sendo adotada pelos desenvolvedores de protocolos.
O Infura já faz parte desses comitês e se uniu ao DAC StarkEx em junho de 2020 e mais recentemente, ao DAC Arbitrum Nova este ano (2022). O Infura é acompanhado por organizações líderes da Web2 e Web3, incluindo Offchain Labs, Reddit, Google Cloud, FTX, P2P e QuickNode no DAC Arbitrum Nova. A seleção do Infura para esses DACs demonstra nosso papel de longa data como um provedor líder e confiável de infraestrutura de alta disponibilidade e acesso confiável a dados de blockchain.
Neste artigo, vamos nos aprofundar na dinâmica dos DACs, em por que eles são soluções de escalabilidade importantes e em o que o futuro dos DACs pode nos reservar.
O que é Comitê de Disponibilidade de Dados (DAC)?
Um comitê de disponibilidade de dados (DAC) é um conjunto de nós encarregados de armazenar cópias de dados off-chain e disponibilizá-los conforme solicitado. Os DACs aparecem em soluções de escalabilidade que aumentam o rendimento em uma blockchain ao processar transações em uma camada separada (ou seja, escalabilidade off-chain).
Embora as soluções de escalabilidade off-chain sejam mais fáceis de implementar, elas precisam enfrentar o problema da disponibilidade de dados. Sem acesso às transações processadas off-chain, a cadeia principal não pode garantir a segurança e a vivacidade do protocolo de escalabilidade.
Algumas soluções de escalabilidade ("layer 2s") contornam esse problema publicando dados de transações na camada de base, embora em formato compactado, para evitar a reintrodução dos problemas de escalabilidade descritos anteriormente. No entanto, essa abordagem reduz os ganhos de escalabilidade, pois a taxa de transferência na cadeia de camada 2 (L2) é limitada pela capacidade de processamento de dados da cadeia de camada 1 (L1).
Um comitê de disponibilidade de dados (DAC) é uma alternativa para o armazenamento de dados on-chain. Em vez de publicar dados de transações na camada de base, os produtores de blocos enviam blocos ao DAC para armazenamento off-chain. Isso reduz os dados postados na blockchain subjacente - aumentando a escalabilidade - e descentraliza o armazenamento de dados para melhorar as garantias de disponibilidade de dados.
As soluções de escalabilidade abordam a disponibilidade de dados de várias maneiras. (fonte)
Como funcionam os comitês de disponibilidade de dados
Os comitês de disponibilidade de dados são confiáveis ou de necessidade mínima de confiança (trustless). Em um esquema de DAC confiável, os gerentes de disponibilidade de dados são conhecidos de antemão e nomeados para suas funções. Esses DACs são compostos por entidades com reputação no mundo real e, portanto, os membros do comitê podem ser responsabilizados pela comunidade por suas ações.
Um DAC de necessidade mínima de confiança é não permissionado - os nós podem aderir ao protocolo e participar do armazenamento de dados off-chain sem precisar da aprovação de uma autoridade. As identidades dos nós no mundo real são ocultas (pseudonimato), de modo que a responsabilidade social não pode ser usada para impor um comportamento honesto.
Os DACs de necessidade mínima de confiança, no entanto, utilizam outros mecanismos para garantir a segurança, ou seja, incentivos criptoeconômicos. Aqui, os gerenciadores de disponibilidade de dados são obrigados a fornecer um título como garantia de comportamento honesto, que pode ser cortado (destruído) como punição por comportamento mal-intencionado.
Um DAC de necessidade mínima de confiança é considerado a solução ideal de disponibilidade de dados na comunidade de blockchains. Mas os DACs descentralizados têm um problema fundamental que ainda não foi resolvido: o Problema do Pescador (The Fisherman’s Problem). Na literatura sobre disponibilidade de dados, o Problema do Pescador é usado para ilustrar problemas que aparecem nas interações entre clientes que solicitam dados e nós que armazenam dados em um protocolo DAC de necessidade mínima de confiança.
Abaixo está uma breve descrição do Problema do Pescador:
Imagine que um cliente que solicita dados de um nó descobre que partes de um bloco não estão disponíveis e alerta outros pares na rede. O nó, no entanto, libera os dados posteriormente para que outros nós descubram que os dados do bloco estão disponíveis mediante inspeção. Isso cria um dilema: o nó estava deliberadamente retendo dados ou o cliente estava dando um alarme falso?
A indisponibilidade de dados não é exclusivamente uma falha atribuível. (fonte)
O Problema do Pescador tem implicações para a segurança de qualquer protocolo DAC em diferentes cenários:
Um cliente (ou seja, o pescador de recompensas) recebe uma recompensa por detectar um nó que está retendo dados, mesmo que este último libere os dados imediatamente para outros nós: Isso poderia levar a um conluio entre nós e clientes para ganhar dinheiro com falsas penalizações (minando a segurança econômica do DAC no processo).
Um cliente não recebe nenhuma recompensa pela detecção de blocos indisponíveis: Isso pode levar a ataques de negação de serviço (DoS) de baixo custo, em que os nós são forçados a fazer download de blocos para verificar se uma reclamação de indisponibilidade de dados é confirmada. Esse é especialmente o caso dos clientes que não incorrem em nenhum custo para iniciar desafios relacionados à disponibilidade de um bloco.
Um cliente incorre em um custo (ou "recompensa negativa") por contestar blocos indisponíveis: Isso desestimularia os clientes a detectar a indisponibilidade de dados, dando aos nós mal-intencionados a liberdade de realizar ataques de retenção de dados.
O Problema do Pescador é um dos motivos pelos quais a criação de uma camada de disponibilidade de dados descentralizada segura e eficiente ainda é um problema de pesquisa em aberto (que está sendo trabalhado por projetos como EigenLayr, Celestia e Polygon Avail). Em contrapartida, há vários exemplos de protocolos DAC permissionados já em uso atualmente.
Como se comparam os DACs permissionados e não permissionados?
DACs Permissionados
Um DAC permissionado opera com um conjunto fixo de participantes confiáveis, o que o torna menor em tamanho e mais fácil de coordenar. Esse tipo de DAC também é mais simples de projetar e implementar e incorre em custos operacionais mais baixos.
Entretanto, o uso de um DAC confiável força os usuários a confiar na honestidade dos membros do DAC (embora o grau de suposição de honestidade possa variar). Quando o DAC é corrompido, ele pode realizar ataques de retenção de dados por conta própria ou agir em conluio com produtores de blocos. Isso leva a problemas de segurança e de vivacidade, conforme explorado nos seguintes cenários hipotéticos:
Problemas de segurança: Um sequenciador de rollup optimistic executa uma transação para roubar fundos e suborna o DAC para ignorar as solicitações de dados de transação dos usuários. Sem acesso aos dados para reconstruir de forma independente o estado da cadeia de camada 2, os usuários não podem criar provas de fraude e contestar atualizações de estado inválidas.
Problemas de vivacidade: Um DAC mal-intencionado retém dados para criar provas de Merkle (necessárias para comprovar a propriedade dos fundos) dos usuários de uma cadeia validium, congelando assim as retiradas. Os usuários são forçados a pagar um resgate antes de retirar os fundos de volta para a cadeia principal.
Mesmo que os membros de um DAC sejam honestos, a vivacidade ainda pode estar em risco. Como os DACs permissionados armazenam dados com um conjunto limitado de nós, a capacidade de tolerar falhas (por exemplo, nós que não podem fornecer dados devido a falhas no sistema) é baixa. Assim, há sempre a possibilidade de os usuários nunca terem acesso a dados de estado críticos.
DACs Não Permissionados
À primeira vista, os DACs não permissionados resolvem a maioria dos problemas descritos acima. Em um DAC não permissionado, os participantes possuem mais incentivos para agir honestamente, pois os stakes (participações) podem ser reduzidos se eles tentarem subverter o protocolo retendo dados. Os dados off-chain também são replicados em um conjunto maior de nós, reduzindo a probabilidade de indisponibilidade de dados, mesmo que alguns nós estejam com falhas de propósito ou por acidente.
Mas a natureza descentralizada de um DAC não permissionado - um de seus principais benefícios - também pode ser desvantajosa.
Com os participantes livres para entrar e sair quando quiserem, a coordenação da comunicação entre os nós incorre em um custo operacional significativo. Isso se deve ainda mais ao fato de que os DACs não permissionados não são como os DACs permissionados que operam com um conjunto fixo de participantes aprovados (em que as partes sabem como chegar umas às outras). Os nós em um DAC não permissionado geralmente são desconhecidos uns dos outros (e não são confiáveis), o que complica a participação individual no armazenamento e na recuperação de dados.
Além disso, os DACs não permissionados geralmente exigem mecanismos complexos para garantir a segurança, pois os participantes adversários não podem ser distinguidos de forma confiável das partes honestas (como visto no Problema do Pescador). Isso pode aumentar significativamente os custos do uso dessas soluções de disponibilidade de dados - um custo que provavelmente será repassado aos usuários de aplicativos.
Por que os comitês de disponibilidade de dados são importantes para a escalabilidade da blockchain?
Modelo mais seguro
A existência de comitês de disponibilidade de dados possibilita a criação de soluções de escalabilidade que armazenam dados off-chain sem reduzir muito as garantias de segurança. Por exemplo, validiums e cadeias optimistic são duas soluções off-chain que usam DACs para gerenciar a disponibilidade de dados.
As cadeias Optmistic são semelhantes aos rollups Optmistic. Por exemplo, uma cadeia Optimistic pressupõe que as transações são válidas até que sejam contestadas (por meio de provas de fraude) e tem pressupostos de honestidade 1 de N (ou seja, há sempre um nó honesto disponível para contestar transações e avançar o estado do rollup). Mas as cadeias Optimistic armazenam dados off-chain, ao contrário dos rollups Optmistic que publicam dados de transações na cadeia de camada 1.
Validiums são similares aos rollups zero-knowledge (rollups de conhecimento zero) . Por exemplo, provas de validade são geradas para blocos e verificadas na camada de base, garantindo a exatidão da computação off-chain. No entanto, os produtores de blocos em uma cadeia validium armazenam dados off-chain em vez de publicá-los na cadeia principal, como fazem os rollups ZK.
O armazenamento de dados de transações off-chain significa que os validiums e as cadeias optimistic não herdam a segurança da blockchain subjacente. No entanto, confiar em comitês de disponibilidade de dados - como a maioria dos validiums e cadeias Optimistic fazem hoje - oferece melhores garantias de segurança do que outras soluções de escalabilidade (por exemplo, sidechains e cadeias de plasma).
Redução das taxas
Os rollups pagam pela publicação de dados de transações de camada 1 e esse custo geralmente é suportado pelos usuários de aplicativos executados em cadeias de camada 2. O armazenamento de dados com um DAC, em vez de colocá-los na camada de base, minimiza a pegada on-chain e reduz os custos para os usuários de aplicativos.
É por isso que as blockchains criadas com aplicativos de alto volume em mente consideram atraentes os comitês de disponibilidade de dados. Como esses aplicativos precisam processar uma quantidade considerável de transações, os custos de publicação de CALLDATA seriam mais altos. O armazenamento de dados off-chain por um DAC resolve esse problema, permitindo que os usuários se beneficiem de taxas mais baixas.
Um exemplo da vida real é o Arbitrum Nova, uma cadeia Optimistic projetada para aplicativos sociais e de jogos. Como esses aplicativos exigem o envio de muitas transações, seria inviável usá-los na Ethereum devido às altas taxas de gas.
Os sequenciadores da Arbitrum Nova enviam lotes de transações para um DAC off-chain e publicam um atestado dos membros do DAC (incluindo assinaturas de um quorum) confirmando a disponibilidade dos dados. O custo de publicação e verificação de atestados de DA na camada 1 é baixo e fixo, em comparação com o custo variável e, às vezes, caro de postar dados de rollup na camada 1.
Maior taxa de transferência
Embora os rollups tenham melhores propriedades de escalabilidade, sua taxa de transferência é limitada pela largura de banda da blockchain da camada de base. Como as transações compactadas de um rollup precisam competir com outras transações de camada 1 pelo espaço de blocos, o limite de tamanho de bloco impõe um limite superior efetivo de quantas transações um rollup pode processar por segundo.
As construções do tipo rollup com armazenamento de dados off-chain, como validiums e cadeias Optimistic, não são limitadas pelo desempenho da camada 1. Assim, elas podem se dar ao luxo de aumentar o tamanho dos blocos e aumentar a taxa de transferência.
Quais são alguns exemplos de comitês de disponibilidade de dados?
DAC Arbitrum Nova
O Arbitrum Nova, que mencionamos anteriormente, é uma sidechain (cadeia Optimistic) da Ethereum criada para reduzir as taxas de gas e proporcionar transações mais rápidas. O Arbitrum Nova é diferente do Arbitrum One (um rollup optimistic), pois os sequenciadores armazenam blocos com um comitê de disponibilidade de dados em vez de publicá-los na Ethereum como CALLDATA.
O DAC Arbitrum Nova inclui organizações reputáveis, como o Infura, FTX, Google Cloud e Reddit. O Nova é baseado na tecnologia AnyTrust, da Arbitrum, que requer um quorum de DAC para assinar um certificado de disponibilidade de dados (DA) publicado na Ethereum junto com a raiz Merkle do lote de transação.
Se o DAC não estiver disponível ou não quiser assinar o atestado de DA, a cadeia Nova entrará no modo rollup, em que novos lotes de transações serão aceitos pelo contrato de camada 1 somente se os dados da transação estiverem disponíveis na camada 1. (Isso garante que um DAC mal-intencionado não possa congelar arbitrariamente a cadeia à vontade, recusando-se a cooperar).
DAC StarkEx da Starkware
O StarkEx é um Validium operado pela Starkware (que também opera com rollup ZK StarkNet). Após processar as transações e gerar uma prova de validade, o operador do StarkEx envia os dados da transação para um DAC autorizado e obtém um atestado dos membros do comitê prometendo disponibilizar os dados. Esse atestado funciona como uma prova de disponibilidade de dados e é verificado juntamente com a prova de conhecimento-zero na Ethereum. Observe que o StarkEx pode operar como Validium ou como Rollup-Zk (como faz para o dYdX). E também pode operar como Volition, o que permite que os usuários decidam o método de disponibilidade de dados que desejam para cada transação.
Como um validium, o StarkEx não enfrenta o risco de um sequenciador mal-intencionado roubar os fundos do usuário (as provas de validade garantem a exatidão das transições de estado). Mas os usuários ainda precisam ter acesso aos dados da transação ao criar provas de Merkle para provar a titularidade dos fundos. Isso é particularmente importante quando o sequenciador se torna desonesto e os usuários precisam usar o mecanismo escape-hatch (saída de emergência)
Celestia e Polygon Avail
A Celestia e o Polygon Avail são "modular blockchains" (blockchains modulares) que se concentram exclusivamente no fornecimento de disponibilidade de dados para outras blockchains (por exemplo, rollups). As transações são enviadas de produtores de blocos externos, como sequenciadores de rollup, para os nós completos da Celestia e do Polygon Avail para armazenamento. Os nós leves em ambas as cadeias não armazenam blocos, mas podem verificar de forma confiável se os blocos estão disponíveis por meio de amostragem de disponibilidade de dados.
A Celestia e o Polygon Avail são essencialmente DACs não permissionados. Qualquer pessoa pode executar um nó completo e armazenar dados de outras cadeias, mas deve primeiro fornecer um stake . Esse stake pode ser reduzido se eles agirem de forma maliciosa (por exemplo, armazenando blocos indisponíveis), fornecendo garantias criptoeconômicas de honestidade.
A Celestia e o Polygon Avail existem como camadas de disponibilidade de dados de uso geral para várias blockchains. Isso os torna diferentes dos DACs permissionados, que geralmente são projetados para atender a um único protocolo.
O futuro dos comitês de disponibilidade de dados
Como vimos, os comitês de disponibilidade de dados podem fazer a ponte entre segurança e escalabilidade ao projetar novas soluções de escalabilidade. Mas o benefício futuro mais interessante dos DACs é que eles permitem mais flexibilidade na criação de novas blockchains.
Por exemplo, a Celestia apresenta os Celestiums— são rollups que usam a Celestia para disponibilidade de dados e a Ethereum para arbitragem de disputas. Em vez de publicar CALLDATA na camada 1, o rollup envia um atestado de disponibilidade de dados (a raiz Merkle do lote de transações da camada 2 assinado por um quorum de validadores Celestia) para um contrato de ponte na camada 1.
Quando uma nova raiz de estado da camada 2 é publicada na camada 1, o contrato de rollup confirma que os dados estão disponíveis verificando o atestado de DA armazenado no contrato de ponte (bridge). No caso de uma transação contestada, os usuários de rollup podem solicitar dados dos nós da Celestia para executar provas de fraude na Mainnet (Rede principal). Isso significa que os rollups no estilo Celestia ainda podem herdar alguma segurança da camada 1, reduzindo ainda mais os custos e melhorando a escalabilidade.
Fluxo de trabalho proposto para rollups usando a Celestia como uma camada DA. (fonte)
No entanto, os comitês de disponibilidade de dados - especialmente os tipos não permissionados - enfrentam obstáculos para a adoção. Projetar mecanismos de segurança criptoeconômica para DACs é uma tarefa não trivial e a amostragem de disponibilidade de dados em sua forma atual enfrenta desafios.
O modo como esses problemas são resolvidos acabará determinando o lugar dos DACs na corrida para escalonar blockchains públicas e preparar a Web3 para adoção em massa. O Infura está pronto para participar dessa jornada e continuar a fazer do fornecimento de disponibilidade de dados um objetivo central de nosso serviço.
Esse artigo foi escrito por Emmanuel Awosika e Clarissa Watson e traduzido por Fátima Lima. O original pode ser lido aqui.
Top comments (0)