• Título original encaminhado: Equívoco sobre a disponibilidade de dados: DA = liberação de dados ≠ recuperação de dados históricos

Introdução:

O que exatamente é disponibilidade de dados? Para a maioria das pessoas, a primeira impressão pode ser "acessar dados históricos de um determinado momento", mas isso é, na verdade, um grande mal-entendido do conceito de DA. Recentemente, os cofundadores da L2BEAT e defensores do Danksharding, juntamente com o fundador da Celestia, esclareceram esse equívoco. Eles apontaram que a disponibilidade de dados (DA) deveria, na verdade, se referir à "publicação de dados", mas a maioria das pessoas interpretou DA como "recuperabilidade de dados históricos", o que, na verdade, envolve questões de armazenamento de dados.

Por exemplo, há algum tempo, Dankrad mencionou o mecanismo de retirada obrigatória/escape hatch da Camada 2, observando que a retirada obrigatória da Validium exige a obtenção do estado L2 mais recente para construir uma prova de Merkle, enquanto a Plasma precisa apenas dos dados de 7 dias antes (isso está relacionado aos seus métodos de determinar uma raiz de estado legítima).

Com isso, Dankrad apontou claramente que a Validium exige que a DA garanta a segurança dos fundos dos usuários, mas a Plasma não. Aqui, o caso de uso da Dankrad aponta a diferença entre a DA e a recuperação de dados históricos, que é o fato de a DA geralmente envolver apenas dados recém-lançados.

No L2BEAT, a distinção entre disponibilidade de dados (DA) e armazenamento de dados (DS) foi enfatizada ainda mais. Bartek, do L2BEAT, enfatizou várias vezes que DA e armazenamento de dados/recuperação de dados históricos são duas coisas diferentes e que os usuários podem acessar os dados L2 de que precisam somente porque os nós que fornecem dados são "gentis o suficiente com o senhor". Além disso, o L2BEAT planeja usar "se há nós de armazenamento de dados com permissão disponíveis" como uma nova métrica para avaliar os rollups, além do DA.

As declarações dos membros da comunidade Ethereum/Fundação Ethereum mostram sua intenção de esclarecer e refinar os conceitos relacionados à Camada 2 no futuro, bem como de fornecer uma definição mais detalhada da própria Camada 2. Isso ocorre porque muitos termos relacionados ao Rollup e ao L2 não foram claramente explicados, como, por exemplo, o quanto os dados anteriores são considerados "históricos" - alguns acreditam que, como os contratos inteligentes só podem chamar dados dos últimos 256 blocos, os dados anteriores a 256 blocos (50 minutos) são considerados "históricos".

No entanto, o "Rollup" mencionado pela Celestia e pela Fundação Ethereum refere-se estritamente a duas coisas diferentes. Este artigo tem como objetivo esclarecer a diferença entre o conceito de DA e o armazenamento de dados, desde a origem do DA, a amostragem de disponibilidade de dados, até os métodos de implementação do DA em Rollups, explicando o que realmente significa disponibilidade de dados - publicação de dados.

A origem do conceito de DA

O conceito de DA tem origem na questão da "disponibilidade de dados", que o fundador da Celestia, Mustafa, explica da seguinte forma: DA é sobre como garantir que todos os dados em um bloco sejam publicados na rede quando um produtor de blocos propõe um novo bloco. Se o produtor do bloco não liberar todos os dados do bloco, será impossível verificar se o bloco contém transações errôneas.

Mustafa também ressalta que os Rollups da Ethereum simplesmente publicam os dados do bloco L2 na cadeia da Ethereum e contam com a ETH para garantir a disponibilidade dos dados. No site oficial da Ethereum, o problema da disponibilidade de dados é resumido como a pergunta: "Como verificamos se os dados de um novo bloco estão disponíveis?" Para clientes leves, a questão da disponibilidade de dados refere-se à verificação da disponibilidade de um bloco sem a necessidade de fazer o download do bloco inteiro.

O site oficial da Ethereum também faz uma distinção clara entre disponibilidade de dados e capacidade de recuperação de dados: a disponibilidade de dados refere-se à capacidade dos nós de fazer o download dos dados do bloco quando eles são propostos, em outras palavras, está relacionada ao tempo até que um bloco chegue a um consenso. A capacidade de recuperação de dados refere-se à capacidade dos nós de recuperar informações históricas do blockchain. Embora o arquivamento possa exigir dados históricos do blockchain, os nós não precisam usar dados históricos para verificar blocos e processar transações.

Na opinião do colaborador chinês da Celestia e parceiro do W3Hitchhiker, Ren Hongyi, a camada 2 pressupõe de antemão que a Ethereum é suficientemente segura e descentralizada. Os classificadores podem enviar dados DA com confiança para a Ethereum, e esses dados serão propagados sem obstruções para todos os nós completos da Ethereum. Como os próprios nós completos L2 executam o cliente Geth, eles são considerados um subconjunto de nós completos Ethereum e, portanto, podem receber dados DA da Camada 2.

Na visão do Dr. Qi Zhou, fundador da EthStorage, a definição de disponibilidade de dados (DA) é que ninguém pode reter os dados de transações enviados pelos usuários à rede. O modelo de confiança correspondente é que só precisamos confiar no protocolo da Camada 1 (L1) em si, sem a necessidade de introduzir outras suposições de confiança.

Qi Zhou ressalta que a implementação atual do DA na Ethereum é essencialmente uma transmissão P2P (usando o protocolo gossip), em que cada nó completo faz o download, propaga novos blocos e armazena dados do Rollup. No entanto, os full nodes da Ethereum não armazenarão blocos históricos para sempre. Após a implementação do EIP-4844, eles poderão excluir automaticamente os dados de um determinado período (aparentemente 18 dias). Não há muitos nós de arquivo que armazenem todos os dados históricos em todo o mundo. O EthStorage planeja preencher essa lacuna no ecossistema Ethereum e ajudar a Layer 2 a estabelecer seus nós de permanência de dados dedicados.

As primeiras discussões sobre a disponibilidade de dados pela Fundação Ethereum podem ser vistas nos tweets de Vitalik Buterin e nos documentos do GitHub em 2017. Naquela época, ele acreditava que, para garantir a escalabilidade e a eficiência do blockchain, era necessário aumentar a configuração de hardware dos full nodes (full nodes são aqueles que baixam o bloco completo e verificam sua validade, e os validadores, que participam do consenso, são um subconjunto dos full nodes). No entanto, o aumento dos requisitos de hardware para nós completos também aumentaria os custos operacionais, levando à centralização do blockchain.

Sobre esse assunto, Vitalik sugeriu a criação de um esquema para lidar com os riscos de segurança causados pela tendência de centralização de nós completos de alto desempenho. Ele planejou introduzir códigos de apagamento e amostragem aleatória de dados para projetar um protocolo que permita que nós leves com recursos de hardware inferiores verifiquem se um bloco está livre de problemas sem conhecer o bloco completo.

Sua ideia inicial estava, na verdade, relacionada a uma ideia mencionada no whitepaper do Bitcoin, que afirma que os nós leves não precisam receber o bloco completo, mas serão alertados por nós completos honestos se houver algum problema com o bloco. Esse conceito poderia ser estendido para provas de fraude posteriores, mas não garante que nós completos honestos possam sempre obter dados suficientes, nem pode julgar, após o fato, se o proponente do bloco reteve alguns dados para não serem publicados.

Por exemplo, um nó A poderia publicar uma prova de fraude alegando que recebeu um bloco incompleto do nó B. No entanto, é impossível determinar se o bloco incompleto foi fabricado por A ou enviado por B. Vitalik apontou que esse problema poderia ser resolvido pela amostragem de disponibilidade de dados (DAS), que obviamente envolve questões de publicação de dados.

Vitalik discutiu brevemente esses problemas e suas soluções em seu artigo "A note on data availability and erasure coding". Ele ressaltou que as provas de DA (Data Availability) são essencialmente um "complemento" das provas de fraude.

Amostragem de disponibilidade de dados

No entanto, o conceito de DA não é tão fácil de explicar, como evidenciado pelo documento de Vitalik no GitHub que passou por 18 correções, com a última correção enviada em 25 de setembro de 2018. No dia anterior, em 24 de setembro de 2018, o fundador da Celestia, Mustafa, e Vitalik foram coautores do famoso artigo "Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities" (Maximizando a segurança do cliente leve e dimensionando blockchains com maiorias desonestas).

É interessante notar que Mustafa está listado como o primeiro autor do artigo, e não Vitalik (outro autor é agora um pesquisador da blockchain pública Sui). O documento menciona o conceito de provas de fraude e explica o princípio da amostragem de disponibilidade de dados (DAS), projetando aproximadamente um protocolo misto de DAS + codificação de apagamento bidimensional + provas de fraude. O documento menciona especificamente que o sistema de prova DA é um complemento necessário às provas de fraude.

Do ponto de vista de Vitalik, o protocolo funciona da seguinte forma:

Suponha que uma blockchain pública tenha N nós de consenso (validadores) com hardware de alta capacidade, o que permite um alto rendimento e eficiência de dados. Embora essa blockchain possa ter um TPS (Transactions Per Second, transações por segundo) alto, o número de nós de consenso, N, é relativamente pequeno, o que a torna mais centralizada, com maior probabilidade de conluio entre os nós.

No entanto, supõe-se que pelo menos um dos N nós de consenso seja honesto. Desde que pelo menos 1/N dos validadores sejam honestos, capazes de detectar e transmitir provas de fraude quando um bloco é inválido, os clientes leves ou os validadores honestos podem tomar conhecimento dos problemas de segurança na rede e usar mecanismos como a eliminação de nós mal-intencionados e bifurcações de consenso social para recuperar a rede ao normal.

Como Vitalik mencionou anteriormente, se um nó completo e honesto receber um bloco e achar que ele não tem algumas partes e publicar uma prova de fraude, será difícil determinar se o proponente do bloco não publicou essa parte, se ela foi retida por outros nós durante a transmissão ou se é um sinalizador falso do nó que publicou a prova de fraude. Além disso, se a maioria dos nós conspirar, o Validador 1/N honesto poderá ficar isolado, sem poder receber novos blocos, o que é um cenário de ataque de retenção de dados. Nesses casos, o nó honesto não pode determinar se isso se deve às condições ruins da rede ou a uma conspiração deliberada de retenção de dados por parte de outros, nem pode saber se outros nós também estão isolados, o que torna difícil julgar se a maioria conspirou na retenção de dados.

Portanto, é preciso haver uma maneira de garantir, com uma probabilidade muito alta, que os validadores honestos possam obter os dados necessários para validar os blocos; e identificar quem está por trás de um ataque de retenção de dados - seja o proponente do bloco que não publicou dados suficientes, que os dados foram retidos por outros nós ou que se trata de uma conspiração majoritária. Claramente, esse modelo de segurança oferece muito mais proteção do que a "suposição de maioria honesta" comum nas cadeias de PoS típicas, e a amostragem de disponibilidade de dados (DAS) é o método de implementação específico.

Supondo que haja muitos nós de luz na rede, possivelmente 10 vezes N, cada um conectado a vários validadores (para simplificar, suponha que cada nó de luz esteja conectado a todos os N validadores). Esses nós leves realizariam várias amostragens de dados dos validadores, cada vez solicitando aleatoriamente uma pequena parte dos dados (suponha que seja apenas 1% de um bloco). Em seguida, eles espalhariam os fragmentos adquiridos para os validadores que não tivessem esses dados. Desde que haja nós de luz suficientes e a frequência da amostragem de dados seja alta o suficiente, mesmo que algumas solicitações sejam negadas, desde que a maioria seja respondida, é possível garantir que todos os validadores consigam adquirir a quantidade necessária de dados para validar um bloco. Isso pode anular o impacto da retenção de dados por outros nós que não o proponente do bloco.

(Fonte da imagem: W3 Hitchhiker)

Se a maioria dos validadores conspirar e se recusar a responder à maioria das solicitações de nós leves, será fácil para as pessoas perceberem que há um problema com a cadeia (porque mesmo que algumas pessoas tenham uma internet ruim, isso não resultaria na negação da maioria das solicitações de nós leves). Portanto, é muito provável que o esquema mencionado acima possa determinar o comportamento da conspiração da maioria, embora essas situações sejam raras. Com essa abordagem, as incertezas de outras fontes que não o proponente do bloco podem ser resolvidas. Se o proponente do bloco retiver dados, como não publicar dados suficientes no bloco para validá-lo (após a introdução da codificação de apagamento bidimensional, um bloco contém 2k2k fragmentos, e a restauração dos dados originais do bloco exige pelo menos cerca de kk fragmentos, ou 1/4. Para evitar que outras pessoas restaurem os dados originais, o proponente precisaria reter pelo menos k+1*k+1 fragmentos), eles acabarão sendo detectados por validadores honestos, que transmitirão provas de fraude para alertar outras pessoas.

De acordo com Vitalik e Mustafa, o que eles fizeram foi essencialmente combinar ideias que já haviam sido propostas por outros e acrescentar suas próprias inovações. Ao analisar o conceito e o método de implementação como um todo, fica claro que a "disponibilidade de dados" se refere ao fato de os dados necessários para verificar o último bloco terem sido publicados pelo proponente do bloco e poderem ser recebidos pelos verificadores. Trata-se de saber se os dados estão "totalmente publicados" e não se "os dados históricos podem ser recuperados".

Como a disponibilidade de dados (DA) do Ethereum Rollup é implementada

Com a afirmação acima, vejamos como a Disponibilidade de Dados (DA) é implementada nos Rollups da Ethereum, o que se torna bastante claro: o proponente do bloco em um Rollup é conhecido como Sequencer, que publica os dados necessários para verificar as transições de estado da Camada 2 na Ethereum em intervalos. Especificamente, ele inicia uma transação para um contrato designado, inserindo os dados relacionados ao DA nos parâmetros de entrada personalizados, que são então registrados em um bloco Ethereum. Dado o alto grau de descentralização da Ethereum, é possível garantir que os dados enviados pelo sequenciador serão recebidos sem problemas pelos "verificadores". No entanto, as entidades que desempenham o papel de "verificadores" diferem entre as várias redes Rollup.

Por exemplo, no caso da Arbitrum, o sequenciador publica lotes de transações em um determinado contrato na Ethereum. O contrato em si não verifica esses dados, mas emite um evento para os nós completos do L2 ouvirem, informando-os de que o sequenciador publicou um lote de transações. Especificamente, os ZK Rollups usam um contrato Verifier na Ethereum como o "verificador". Um ZK Rollup só precisa publicar um State Diff + Validity Proof, ou seja, informações sobre mudanças de estado mais uma prova de validade. O contrato Verifier verifica o comprovante de validade para ver se ele corresponde ao State Diff. Se a validação for aprovada, o bloco/lote L2 publicado pelo sequenciador será considerado válido.

(Fonte: Antigo documento técnico da Polygon Hermez)

Os Rollups otimistas exigem a publicação de mais dados no Ethereum porque dependem exclusivamente de nós completos L2 para baixar dados e verificar a validade dos blocos. Isso significa que, no mínimo, as assinaturas digitais de cada transação L2 (agora comumente usando assinaturas agregadas) devem ser divulgadas. Se forem feitas chamadas de contrato, os parâmetros de entrada também deverão ser divulgados, além dos endereços de transferência de transações, os valores de nonce para evitar ataques de repetição, etc. No entanto, em comparação com os dados completos da transação, ainda há algum corte.

Em comparação com os ZK Rollups, o custo de DA (Data Availability, disponibilidade de dados) dos Optimistic Rollups é mais alto porque os ZK Rollups só precisam divulgar as alterações do estado final após a execução de um lote de transações, acompanhadas de uma prova de validade, aproveitando a sucinta característica do ZK SNARK/STARK; enquanto os Optimistic Rollups só podem usar o método mais complicado, exigindo que todas as transações sejam reexecutadas por outros nós completos L2.

Anteriormente, W3hitchhiker estimou que, sem considerar os desenvolvimentos futuros do EIP-4844 e dos blobs, o efeito de escala do ZKR (Zero-Knowledge Rollups) poderia chegar a várias vezes o do OPR (Optimistic Rollups). Se considerarmos as carteiras inteligentes relacionadas à EIP-4337 (que usam impressões digitais, dados de íris em vez de assinaturas de chave privada), a vantagem da ZKR seria ainda mais evidente, porque ela não precisa publicar os dados binários de impressões digitais, íris na Ethereum, enquanto os Optimistic Rollups precisam.

Quanto à Validium e à Plasma/Optimium, elas realmente usam a camada DA fora da cadeia da Ethereum para obter a DA. Por exemplo, a ImmutableX, que adotou um sistema de prova de validade, criou um conjunto de nós DAC (Data Availability Committee, Comitê de Disponibilidade de Dados) especificamente para publicar dados relacionados a DA; a Metis publica dados de DA no Memlabs, e a Rooch e a Manta usam o Celestia. Atualmente, devido à existência de DAS (Data Availability Solutions) e sistemas de prova de fraude, a Celestia é um dos projetos de camada DA mais confiáveis fora da Ethereum.

Isenção de responsabilidade：

1. Este artigo foi reproduzido de[Geek Web3]. Encaminhar o título original：Misunderstandings about data availability: DA = Data Publishing ≠ Historical Data Retrieva, Todos os direitos autorais pertencem ao autor original [ Faust, Geek web3]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.