Mal-entendido sobre a disponibilidade de dados: DA = liberação de dados ≠ recuperação de dados históricos

Introdução: O que exatamente é disponibilidade de dados? **Talvez a primeira impressão da maioria das pessoas seja que “dados históricos de um determinado momento podem ser obtidos”, mas este é na verdade o maior mal-entendido do conceito de AD. **Recentemente, L2BEAT Lianchuang, o proponente do Danksharding e o fundador da Celestia esclareceram esse mal-entendido. Eles apontaram que A disponibilidade de dados deveria na verdade se referir a "liberação de dados", mas a maioria das pessoas entende DA como "dados históricos podem ser recuperados", e este último envolve, na verdade, problemas de armazenamento de dados.

Por exemplo, Dankrad mencionou o mecanismo de retirada forçada/escape hatch da Camada 2 há algum tempo. Ele apontou que a retirada forçada do Validium precisa obter o estado L2 mais recente para construir a Prova Merkle, mas o Plasma só precisa do estado L2 mais recente de 7 dias atrás (este é diferente dos dois. Está relacionado ao método de determinação da Stateroot legal do usuário).

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

No L2BEAT, a diferença entre a disponibilidade de dados DA e o armazenamento de dados DS é ainda mais fortalecida. Bartek, da L2BEAT, enfatizou repetidamente que DA e armazenamento de dados/dados históricos são duas coisas diferentes, e os usuários podem obter os dados L2 de que precisam apenas porque os nós que fornecem os dados são “bons o suficiente para você”. Além disso, o L2BEAT também planeja usar “se há nós de armazenamento de dados com permissões abertas” como um novo indicador para avaliar o Rollup além do DA.

As observações acima feitas por membros da comunidade Ethereum/Fundação Ethereum indicam que eles padronizarão os conceitos relacionados à Camada 2 no futuro e fornecerão uma definição mais detalhada da própria Camada 2. Como muitos termos em torno de Rollup e L2 não são bem explicados, como há quanto tempo os dados são considerados "dados históricos" - algumas pessoas pensam que, como os contratos inteligentes só podem chamar dados de blocos anteriores dentro de 256 blocos, portanto, os dados 256 blocos ( 50 minutos) atrás são considerados "dados históricos".

A rigor, o “Rollup” mencionado pela Celestia e pela Fundação Ethereum são duas coisas diferentes. Este artigo tem como objetivo esclarecer a diferença entre o conceito de DA e armazenamento de dados. A partir da origem do DA, da amostragem de disponibilidade de dados e da implementação do DA do Rollup, explicaremos o que é disponibilidade de dados - liberação de dados. **

Fonte do conceito DA

Sobre a que se refere a questão da “disponibilidade de dados”, ** o fundador da Celestia, Mustafa, explicou o seguinte: ** DA é, quando o gerador de bloco propõe um novo bloco, como garantir que todos os dados do bloco sejam liberados para a rede? Se o gerador de bloco não liberar todos os dados do bloco, ele não poderá detectar se o bloco contém transações incorretas.

Mustafa também destacou que o Ethereum Rollup simplesmente publica dados do bloco L2 na cadeia Ethereum e depende da ETH para garantir a disponibilidade dos dados.

**No site oficial do Ethereum, há o seguinte resumo sobre DA: **O problema de disponibilidade de dados pode ser resumido como uma pergunta: "Como verificamos se os dados de um novo bloco estão disponíveis?"... Para luz clientes Em geral, o problema de disponibilidade de dados refere-se à verificação da disponibilidade de um bloco sem baixar o bloco inteiro.

**O site oficial da Ethereum também distingue claramente a diferença entre disponibilidade e recuperação de dados: **Disponibilidade de dados refere-se à capacidade do nó de baixar dados de bloco quando um bloco é proposto. Em outras palavras, a disponibilidade de dados é relevante quando um bloco ainda não atingiu o consenso... A recuperação de dados refere-se à capacidade de um nó de recuperar informações históricas do blockchain... embora o arquivamento possa exigir um blockchain Dados históricos, mas os nós podem validar blocos e processar transações sem usar dados históricos.

** Na opinião do contribuidor da Celestia China e parceiro do W3Hitchhiker Ren Hongyi, ** Layer2 assume antecipadamente que Ethereum é seguro e descentralizado o suficiente, e o sequenciador pode enviar dados DA com segurança e ousadia para Ethereum, e esses dados se espalharão sem obstáculos. Para todos os nós completos do Ethereum. O próprio nó completo L2 deve executar o cliente Geth, que é um subconjunto do nó completo Ethereum, para que possa receber dados DA da camada 2.

** Aos olhos do Dr. Qi Zhou, fundador da EthStorage, a definição de DA é que ninguém pode reter os dados de transação enviados pelos usuários à rede. O modelo de confiança correspondente é que só precisamos confiar no próprio protocolo L1 e não precisamos introduzir outras suposições de confiança.

Qi Zhou apontou que o método atual de implementação de DA do Ethereum é, na verdade, transmissão P2P (protocolo de fofoca).Cada nó completo baixará e propagará novos blocos e armazenará dados Rollup. É claro que os nós completos do Ethereum não armazenarão blocos históricos permanentemente e poderão excluir automaticamente os dados de um período de tempo (parece ser 18 dias) após 4.844 ficar online. **Não existem muitos nós de arquivo no mundo que armazenem todos os dados históricos. **EthStorage pretende preencher esta lacuna no sistema Ethereum e ajudar a Camada 2 a configurar seu próprio nó de persistência de dados exclusivo.

As primeiras discussões da Fundação Ethereum sobre a disponibilidade de dados podem ser encontradas nos tweets e documentos do GitHub de Vitalik em 2017. Naquela época, ele acreditava que se quisermos garantir a escalabilidade/alta eficiência do blockchain, precisamos melhorar a configuração de hardware do nó completo (um nó completo é um nó que baixa um bloco completo e verifica sua validade, e o Validador que faz o consenso é um subconjunto do nó completo). No entanto, se a configuração de hardware do nó completo for melhorada, o custo operacional aumentará, fazendo com que o blockchain se torne centralizado.

A este respeito,** Vitalik disse que uma solução pode ser projetada para resolver os riscos de segurança causados pela centralização de nós completos de alto desempenho. ** Ele planeja introduzir codificação de eliminação e amostragem aleatória de dados para projetar um protocolo para que nós leves com hardware de baixo custo possam saber que não há problema com o bloco, mesmo que não conheçam o bloco completo.

Seu pensamento inicial estava, na verdade, relacionado à ideia mencionada no white paper do Bitcoin. Essa ideia diz que os nós leves não precisam receber o bloco completo e, quando houver um problema com o bloco, o nó completo honesto emitirá um “alarme” para notificar o nó leve. Esta ideia pode ser estendida a provas de fraude subsequentes, mas não há garantia de que nós completos honestos possam sempre obter dados suficientes, nem pode ser avaliado posteriormente se o proponente do bloco reteve certos dados e não os divulgou.

Por exemplo, um determinado nó A pode emitir um certificado de fraude alegando ter recebido um bloco incompleto do nó B. Mas, neste momento, é impossível avaliar se este bloco incompleto foi forjado pelo próprio A ou enviado por B. Vitalik apontou que este problema pode ser resolvido com amostragem de disponibilidade de dados DAS (obviamente a disponibilidade de dados envolve essencialmente questões de divulgação de dados).

Vitalik fornece uma discussão superficial desses problemas e suas soluções em "Uma nota sobre disponibilidade de dados e codificação de eliminação". **Ele ressaltou que o certificado DA é essencialmente uma “conclusão” do certificado de fraude. **

Amostragem de disponibilidade de dados

Mas obviamente, o conceito de DA não é tão fácil de explicar, porque o documento do Vitalik no GitHub foi corrigido 18 vezes. Os registros mostram que a última correção foi enviada em 25 de setembro de 2018. No dia anterior, em 24 de setembro de 2018, Os fundadores da Celestia, Mustafa e Vitalik, publicaram em conjunto um artigo que se tornaria famoso no futuro——Provas de fraude e disponibilidade de dados: Maximizando a segurança do cliente leve e dimensionando blockchains com maiorias desonestas

Curiosamente, o primeiro autor deste artigo é Mustafa e não Vitalik (o outro autor é agora pesquisador da Sui Public Chain). O artigo mencionou o conceito de prova de fraude, explicou o princípio da amostragem de disponibilidade de dados DAS e projetou aproximadamente um protocolo de mashup de DAS + codificação de eliminação bidimensional + prova de fraude. **O documento menciona claramente que o sistema de prova de DA é essencialmente um complemento necessário à prova de fraude. **

Se partirmos da perspectiva de Vitalik, a função deste protocolo pode ser resumida da seguinte forma:

Suponha que uma cadeia pública tenha N validadores de nós de consenso com hardware de última geração, sua taxa de transferência de dados é grande e sua eficiência é muito alta. Embora tal blockchain tenha alto TPS, o número de nós de consenso N é relativamente pequeno, é relativamente centralizado e a probabilidade de conluio de nós é alta.

No entanto, pelo menos um dos N nós de consenso será honesto. **Desde que pelo menos 1/N Validadores sejam honestos, **verifiquem se o bloco é inválido e estejam dispostos a transmitir prova de fraude quando necessário, nós leves ou Validadores honestos podem saber que há um problema de segurança na rede , e pode usar nós maliciosos Slash e consenso social para Forks e outros métodos são usados para restaurar a rede ao normal.

No entanto, como Vitalik mencionou antes, se um nó completo honesto recebe um bloco e descobre que faltam certas partes e publica um certificado de fraude, é difícil determinar se o proponente do bloco não publicou esta parte dos dados ou foi bloqueado no meio do caminho. Outros nós o retiveram ou o nó que emitiu o certificado de fraude agiu por sua própria iniciativa.

Além disso, se a maioria dos nós conspirar, 1/N validadores honestos serão isolados e poderão não conseguir obter novos blocos, o que é considerado um cenário de ataque de retenção de dados. Deve-se notar que, neste momento, o nó honesto não sabe se a condição da rede é ruim ou se outras pessoas conspiraram para reter dados.Ele também não sabe se outros nós também estão isolados, e é difícil julgar se o a maioria das pessoas conspirou para reter dados.

Resumindo, deve haver uma maneira de garantir que o Validador honesto possa obter os dados necessários para verificar o bloco com uma probabilidade muito alta; ao mesmo tempo, deve ser possível determinar quem está envolvido em ataques de retenção de dados** - é o proponente do bloco que não publicou. Se houver dados suficientes, ainda se diz que eles foram retidos por outros nós ou que a maioria dos nós está em conluio. Obviamente, este modelo de segurança tem muito mais garantias do que a "suposição da maioria honesta" das cadeias POS comuns, e a amostragem de disponibilidade de dados DAS é o método de implementação específico.

Assumimos agora que existem muitos nós leves na rede, talvez 10 N, e cada nó leve está conectado a vários validadores ** (para conveniência da análise, assume-se que cada nó leve está conectado a todos os N validadores). Esses nós leves lançarão amostragem de dados para o Validador várias vezes, solicitando aleatoriamente uma pequena parte dos dados de cada vez (assumindo que representa apenas 1% de um bloco). Posteriormente, eles irão propagar os fragmentos extraídos para Validadores que não possuem esses dados. Desde que haja nós leves suficientes e o número de tempos de amostragem de dados seja suficientemente frequente, mesmo que algumas solicitações possam ser rejeitadas, desde que a maioria delas seja respondida, pode-se garantir que todos os Validadores acabarão por obter dados suficientes necessários para verificar o bloco. Isso pode compensar o impacto dos dados retidos por outros nós que não o proponente do bloco. **

(Fonte da imagem: W3 Hitchhiker)

E se a maioria dos Validadores conspirarem e se recusarem a responder às solicitações da maioria dos nós leves, as pessoas perceberão facilmente que há um problema com a cadeia (porque mesmo que a velocidade da rede de algumas pessoas não seja boa, não será tão ruim quanto as solicitações da maioria dos nós leves) foram rejeitados). Portanto, o esquema acima mencionado pode detectar a maioria dos comportamentos colusivos com uma probabilidade muito elevada, embora, claro, esta situação raramente ocorra.

Neste ponto, podemos resolver as incertezas vindas de fora do proponente do Bloco. **Se o proponente do bloco se envolver na retenção de dados, *por exemplo, ele não publicará dados suficientes necessários para verificar o bloco no bloco (após a introdução da codificação de eliminação bidimensional, um bloco contém 2k*2k fragmentos, e A recuperação dos dados originais do bloco requer pelo menos cerca de k*k fragmentos, representando 1/4. O proponente deseja que outros não consigam restaurar os dados originais, e pelo menos k+1*k+1 fragmentos precisam a ser retido), *Será eventualmente detectado por um validador honesto, que transmitirá prova de fraude para alertar outros *****ers. **

De acordo com vitalik e mustafa, eles realmente combinaram ideias que haviam sido propostas anteriormente e fizeram algumas inovações em cima delas. Do ponto de vista do ponto de partida e implementação de todo o conceito, é óbvio que a chamada "disponibilidade de dados" refere-se a se os dados necessários para verificar o último bloco foram divulgados pelo proponente do bloco e podem ser verificados pelo verificador.Nós recebemos. **Trata-se de "se os dados são totalmente divulgados" e não de "se os dados históricos podem ser recuperados".

Como implementar o DA do Ethereum Rollup

Com a conclusão anterior, vamos dar uma olhada na implementação DA do Ethereum Rollup. Na verdade, é relativamente claro: **O proponente do bloco no Rollup é o sequenciador, que emitirá verificações no Ethereum de vez em quando. Dados necessários para a transição de estado da camada 2 . **Para ser mais preciso, é iniciar uma transação para o contrato especificado, inserir os dados envolvidos no DA nos parâmetros de entrada personalizados e, finalmente, ser registrado no bloco Ethereum. Como o Ethereum é bastante descentralizado, você pode ter certeza de que os dados enviados pelo sequenciador serão recebidos com sucesso pelo “validador”. Mas o que desempenha o papel de “verificador” em diferentes redes Rollup é diferente.

*(O sequenciador Arbitrum publica lotes de transações em um contrato no Ethereum. O contrato em si não verifica esses dados, mas apenas lança um evento para o nó completo L2 ouvir, informando a este último que o sequenciador liberou o lote de transações ) *

Especificamente, ZK Rollup usa o contrato Verifier no Ethereum para atuar como um “verificador”. **ZKR só precisa publicar pelo menos a diferença de estado + prova de validade, **ou seja, mudanças de estado + prova de validade. O contrato do verificador detectará a prova de validade para determinar se ela pode corresponder à diferença de estado. Após passar na verificação, o Bloco/Lote L2 emitido pelo sequenciador é considerado válido.

(Fonte: Artigo anterior do Polygon Hermez)

O Rollup mais otimista liberará mais dados sobre Ethereum, porque só pode contar com nós completos L2 para baixar dados e verificar a validade do Bloco. **Neste caso, pelo menos a assinatura digital de cada transação L2 deve ser divulgada (assinaturas agregadas são geralmente usadas agora), e se um contrato for chamado, os parâmetros de entrada devem ser divulgados. Além disso, o endereço de transferência da transação e o O valor Nonce para evitar ataques de repetição deve ser divulgado. Mas em comparação com os dados completos da transação, ainda há alguns cortes.

**Comparado com o ZK Rollup, o custo DA do Rollup otimista é maior, **porque o ZK Rollup só precisa divulgar as mudanças de estado final após a execução de um lote de transações e vem com um certificado de validade, aproveitando a simplicidade do ZK SNARK/STARK; Optimistic Rollup só pode usar o método mais complicado, permitindo que todas as transações sejam reexecutadas em outros nós completos L2.

W3hitchhiker estimou anteriormente que, sem considerar o futuro 4844 e blobs, o efeito de expansão do ZKR pode atingir várias vezes o do OPR, e se considerar 4337 carteiras inteligentes relacionadas (substituindo assinaturas de chave privada por dados de impressão digital e íris), ZKR's as vantagens serão mais óbvias, porque não precisa postar os dados binários de impressões digitais e íris no Ethereum, enquanto o Optimistic Rollup faz).

Quanto ao Validium e ao Plasma/Optimium, eles realmente usam a camada DA sob a cadeia Ethereum para implementar o DA. Por exemplo, ImmutableX, que usa um sistema de prova de validade, construiu um conjunto de nós DAC (Comitê de Disponibilidade de Dados) para publicar dados relacionados ao DA; Metis publica dados de DA no Memlabs, e Rooch e Manta usam Celestia. Atualmente, parece que devido à existência de DAS e sistema à prova de fraude, **Celestia é um dos projetos de camada DA mais confiáveis fora do Ethereum. **

referências

5