DA=Disponibilidade de dados≠Recuperação de dados históricos

• Título original enviado: Mal-entendido sobre a disponibilidade de dados: DA = libertação de dados ≠ recuperação de dados históricos

Introdução:

O que é exatamente a disponibilidade de dados? Para a maioria das pessoas, a primeira impressão pode ser "aceder a dados históricos de um determinado momento", mas isso é, na verdade, um grande mal-entendido do conceito de DA. Recentemente, os co-fundadores da L2BEAT e proponentes do Danksharding, juntamente com o fundador da Celestia, esclareceram este equívoco. Salientaram que a Disponibilidade de Dados (DA) deveria, de facto, referir-se à "publicação de dados", mas a maioria das pessoas interpretou a DA como "capacidade de recuperação 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 último estado da L2 para construir uma prova de Merkle, enquanto a Plasma só precisa dos dados de 7 dias antes (isto está relacionado com os seus métodos de determinar uma raiz de Estado legítima).

Com isto, Dankrad salientou claramente que a Validium exige que a DA garanta a segurança dos fundos dos utilizadores, mas a Plasma não. Neste caso, o caso de utilização da Dankrad aponta a diferença entre a DA e a recuperação de dados históricos, que é o facto de a DA envolver frequentemente apenas dados recentemente divulgados.

No L2BEAT, a distinção entre disponibilidade de dados (DA) e armazenamento de dados (DS) foi ainda mais enfatizada. Bartek, do L2BEAT, tem repetidamente sublinhado que a DA e o armazenamento de dados/recuperação de dados históricos são duas coisas diferentes e que os utilizadores só podem aceder aos dados L2 de que necessitam porque os nós que fornecem os dados são "suficientemente simpáticos para si". Além disso, o L2BEAT planeia utilizar "se existem nós de armazenamento de dados com permissão disponíveis" como uma nova métrica para avaliar os Rollups, para além da DA.

As declarações dos membros da comunidade Ethereum/Fundação Ethereum mostram a sua intenção de clarificar e aperfeiçoar os conceitos relacionados com a camada 2 no futuro, bem como de fornecer uma definição mais pormenorizada da própria camada 2. Isto deve-se ao facto de muitos termos relacionados com o Rollup e o L2 não terem sido claramente explicados, como por exemplo, até que ponto os dados anteriores são considerados "históricos" - alguns acreditam que, uma vez que 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 AD e o armazenamento de dados, desde a origem da AD, a amostragem da disponibilidade de dados, até aos métodos de implementação da AD em Rollups, explicando o que significa verdadeiramente a disponibilidade de dados - publicação de dados.

A origem do conceito de AD

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

Mustafa também salienta que os Ethereum Rollups simplesmente publicam os dados do bloco L2 na cadeia Ethereum e confiam na ETH para garantir a disponibilidade dos dados. No sítio Web oficial do Ethereum, o problema da disponibilidade dos dados é resumido na pergunta: "Como é que verificamos se os dados de um novo bloco estão disponíveis?" Para os clientes ligeiros, a questão da disponibilidade dos dados refere-se à verificação da disponibilidade de um bloco sem necessidade de descarregar o bloco inteiro.

O sítio Web oficial do Ethereum também distingue claramente entre disponibilidade de dados e capacidade de recuperação de dados: a disponibilidade de dados refere-se à capacidade de os nós descarregarem dados de blocos quando estes são propostos, por outras palavras, está relacionada com o tempo que decorre antes de um bloco chegar a consenso. A capacidade de recuperação de dados refere-se à capacidade de os nós recuperarem informações históricas da cadeia de blocos. Embora o arquivamento possa exigir dados históricos da cadeia de blocos, os nós não precisam de utilizar dados históricos para verificar blocos e processar transacções.

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

Para o Dr. Qi Zhou, fundador da EthStorage, a definição de disponibilidade de dados (DA) é que ninguém pode reter os dados de transação enviados pelos utilizadores para a rede. O modelo de confiança correspondente é que só precisamos de confiar no protocolo da Camada 1 (L1) em si, sem necessidade de introduzir outros pressupostos de confiança.

Qi Zhou salienta que a atual implementação do DA no Ethereum é essencialmente uma transmissão P2P (usando o protocolo de fofocas), em que cada nó completo descarrega, propaga novos blocos e armazena dados Rollup. No entanto, os full nodes do Ethereum não armazenarão blocos históricos para sempre. Após a implementação do EIP-4844, poderão apagar automaticamente os dados de um determinado período de tempo (aparentemente 18 dias). Não existem muitos nós de arquivo que armazenem todos os dados históricos a nível mundial. A EthStorage planeia preencher esta lacuna no ecossistema Ethereum e ajudar a Layer 2 a estabelecer os seus nós dedicados à permanência de dados.

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. Nessa altura, acreditava que, para garantir a escalabilidade e a eficiência da cadeia de blocos, era necessário aumentar a configuração de hardware dos nós completos (os nós completos são os que descarregam o bloco completo e verificam a sua validade, e os validadores, que participam no consenso, são um subconjunto dos nós completos). No entanto, o aumento dos requisitos de hardware para nós completos também aumentaria os custos operacionais, levando à centralização da cadeia de blocos.

Sobre esta questão, Vitalik sugeriu a conceção de um esquema para lidar com os riscos de segurança provocados pela tendência de centralização dos nós completos de elevado desempenho. Planeou introduzir códigos de apagamento e amostragem aleatória de dados para conceber um protocolo que permita aos nós leves com capacidades de hardware inferiores verificar que um bloco não tem problemas sem conhecer o bloco completo.

A sua ideia inicial estava, na verdade, relacionada com uma ideia mencionada no whitepaper da Bitcoin, que afirma que os nós leves não precisam de receber o bloco completo, mas serão alertados por nós completos honestos se houver um problema com o bloco. Este conceito pode ser alargado a provas de fraude posteriores, mas não garante que os nós completos honestos possam sempre obter dados suficientes, nem pode julgar, após o facto, 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 salientou que este problema poderia ser resolvido através da Amostragem de Disponibilidade de Dados (DAS), que obviamente envolve questões de publicação de dados.

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

Amostragem da disponibilidade dos dados

No entanto, o conceito de DA não é assim tão fácil de explicar, como demonstra o facto de o documento de Vitalik no GitHub ter sofrido 18 correcções, tendo a última correção sido apresentada em 25 de setembro de 2018. No dia anterior, em 24 de setembro de 2018, o fundador da Celestia, Mustafa e Vitalik, foram co-autores do famoso artigo "Fraud and Data Availability Proofs: Maximizando a segurança do cliente leve e escalando blockchains com maiorias desonestas".

Curiosamente, Mustafa é o primeiro autor do artigo e não Vitalik (outro autor é atualmente investigador na cadeia de blocos pública Sui). O documento menciona o conceito de provas de fraude e explica o princípio da amostragem da disponibilidade de dados (DAS), concebendo, grosso modo, um protocolo misto de DAS + codificação de apagamento bidimensional + provas de fraude. O documento refere especificamente que o sistema de prova DA é um complemento necessário às provas de fraude.

Na perspetiva de Vitalik, o protocolo funciona da seguinte forma:

Suponha que uma cadeia de blocos pública tem N nós de consenso (validadores) com hardware de elevada capacidade, o que permite um elevado débito de dados e eficiência. Embora uma cadeia de blocos deste tipo possa ter um TPS (Transacções por segundo) elevado, o número de nós de consenso, N, é relativamente pequeno, o que a torna mais centralizada, com uma maior probabilidade de conluio entre nós.

No entanto, assume-se que pelo menos um dos N nós de consenso é honesto. Desde que pelo menos 1/N dos validadores sejam honestos, capazes de detetar e transmitir provas de fraude quando um bloco é inválido, os clientes ligeiros ou os validadores honestos podem tomar consciência dos problemas de segurança na rede e utilizar mecanismos como o corte de nós maliciosos e bifurcações de consenso social para recuperar a normalidade da rede.

Como Vitalik já referiu, se um nó completo e honesto receber um bloco e achar que lhe faltam algumas partes e publicar uma prova de fraude, é difícil determinar se o proponente do bloco não publicou essa parte, se foi retida por outros nós durante a transmissão ou se se trata de uma falsa bandeira do nó que publica a prova de fraude. Além disso, se a maioria dos nós conspirar, o validador 1/N honesto pode ficar isolado, incapaz de receber novos blocos, o que constitui um cenário de ataque de retenção de dados. Nesses casos, o nó honesto não pode determinar se isso se deve a más condições 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 avaliar se uma maioria conspirou na retenção de dados.

Por conseguinte, tem de haver uma forma de garantir, com uma probabilidade muito elevada, que os validadores honestos possam obter os dados necessários para validar os blocos; e de identificar quem está por detrás de um ataque de retenção de dados - quer seja o proponente do bloco que não publicou dados suficientes, quer estes tenham sido retidos por outros nós, quer se trate de uma conspiração maioritária. É evidente que este modelo de segurança oferece muito mais proteção do que o "pressuposto da maioria honesta", comum nas cadeias de pontos de venda típicas, e a amostragem da disponibilidade de dados (DAS) é o método de implementação específico.

Supondo que existem muitos nós de luz na rede, possivelmente 10 vezes N, cada um ligado a vários validadores (para simplificar, suponha que cada nó de luz está ligado a todos os N validadores). Estes nós luminosos efectuariam várias amostragens de dados dos validadores, solicitando de cada vez, aleatoriamente, uma pequena porção de dados (suponha que é apenas 1% de um bloco). Em seguida, espalharão os fragmentos adquiridos aos validadores que não dispõem desses dados. Desde que existam nós de luz suficientes e a frequência de amostragem de dados seja suficientemente elevada, mesmo que alguns pedidos sejam recusados, desde que a maioria seja respondida, pode garantir-se que todos os validadores podem eventualmente adquirir a quantidade de dados necessária para validar um bloco. Isto 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 dos pedidos dos nós de luz, seria fácil para as pessoas perceberem que há um problema com a cadeia (porque mesmo que algumas pessoas tenham uma internet fraca, isso não resultaria na negação da maioria dos pedidos de nós de luz). Assim, o esquema acima mencionado pode muito provavelmente determinar o comportamento da conspiração da maioria, embora tais situações sejam raras. Com esta abordagem, podem ser resolvidas as incertezas de outras fontes que não o proponente do bloco. Se o proponente do bloco retiver dados, por exemplo, não publicando dados suficientes no bloco para o validar (após a introdução da codificação de apagamento bidimensional, um bloco contém 2k2k fragmentos, e o restabelecimento dos dados originais do bloco requer, pelo menos, cerca de kk fragmentos, ou 1/4. Para impedir que outros restaurem os dados originais, o proponente teria de reter pelo menos k+1*k+1 fragmentos), acabarão por ser detectados por Validadores honestos, que transmitirão provas de fraude para avisar os outros.

De acordo com Vitalik e Mustafa, o que fizeram foi essencialmente combinar ideias que já tinham sido propostas por outros e acrescentar as suas próprias inovações. Quando se analisa o conceito e o método de implementação como um todo, é evidente que a "disponibilidade de dados" se refere ao facto de os dados necessários para verificar o último bloco terem sido publicados pelo proponente do bloco e de poderem ser recebidos pelos verificadores. O que está em causa é o facto de os dados estarem "integralmente publicados" e não o facto de os "dados históricos poderem ser recuperados".

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

Com a afirmação acima, vejamos como a Disponibilidade de Dados (DA) é implementada nos Rollups do Ethereum, o que se torna bastante claro: o proponente do bloco num Rollup é conhecido como o Sequenciador, que publica os dados necessários para verificar as transições de estado da Camada 2 no Ethereum em intervalos. Especificamente, inicia uma transação para um contrato designado, colocando os dados relacionados com a DA nos parâmetros de entrada personalizados, que são depois registados num bloco Ethereum. Dado o elevado grau de descentralização do Ethereum, pode ter a certeza de que os dados submetidos pelo sequenciador serão recebidos sem problemas pelos "verificadores". No entanto, as entidades que desempenham o papel de "verificadores" diferem consoante as várias redes Rollup.

Por exemplo, no caso do Arbitrum, o sequenciador lança lotes de transacções para um determinado contrato no Ethereum. O contrato em si não verifica estes dados, mas emite um evento para os nós completos do L2 ouvirem, informando-os de que o sequenciador publicou um lote de transacções. Especificamente, os ZK Rollups utilizam um contrato Verifier no Ethereum como "verificador". Um ZK Rollup só precisa de publicar uma Difusão de Estado + Prova de Validade, ou seja, informação sobre alterações de estado mais uma prova de validade. O contrato do verificador verifica a prova de validade para ver se corresponde à oficial do Estado. Se a validação for aprovada, o bloco/lote L2 publicado pelo sequenciador é considerado válido.

(Fonte: Antigo Livro Branco do Polygon Hermez)

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

Em comparação com os rollups ZK, o custo de DA (disponibilidade de dados) dos rollups optimistas é mais elevado, porque os rollups ZK só precisam de divulgar as alterações do estado final após a execução de um lote de transacções, acompanhadas de uma prova de validade, tirando partido da sucinta funcionalidade do ZK SNARK/STARK; enquanto os rollups optimistas só podem utilizar o método mais complicado, exigindo que todas as transacções sejam reexecutadas por outros nós L2 completos.

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

Quanto à Validium e à Plasma/Optimium, estas utilizam efetivamente a camada DA fora da cadeia do Ethereum para obter a DA. Por exemplo, a ImmutableX, que adoptou um sistema de prova de validade, criou um conjunto de nós DAC (Data Availability Committee) especificamente para publicar dados relacionados com DA; a Metis publica dados DA no Memlabs, e a Rooch e a Manta utilizam o Celestia. Atualmente, devido à existência de DAS (Data Availability Solutions) e de sistemas de prova de fraude, o Celestia é um dos projectos de camada DA mais fiáveis fora do Ethereum.

Declaração de exoneraçã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 [ Fausto, Geek web3]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.