Qual é o problema com a disponibilidade de dados?

! [Qual é o problema com a disponibilidade de dados?] (https://piccdn.0daily.com/202310/25080444/tnfnxd82p4sv8fpe.jpg!webp)

Em uma rede blockchain, como os nós garantem que todos os dados para um bloco recém-proposto estejam disponíveis?

Neste post, vamos dar um mergulho profundo nos problemas de disponibilidade de dados e como eles afetam a escalabilidade do Ethereum.

Qual é o problema da disponibilidade de dados?

Problemas de disponibilidade de dados (DA): Como os nós em uma rede blockchain podem garantir que todos os dados em um bloco recém-proposto estejam realmente disponíveis e, se os dados não estiverem disponíveis, o bloco pode conter transações maliciosas ocultas pelo produtor do bloco. Mesmo que os blocos contenham transações não maliciosas, ocultá-los pode ameaçar a segurança do sistema.

Por exemplo, digamos que Alice é uma operadora de um ZK-Rollup. Ela enviou um ZK-Proof no Ethereum e foi verificada. Se ela não tivesse enviado todos os dados de transação no Ethereum, os usuários do rollup ainda poderiam não ter ideia sobre o saldo de sua conta atual, apesar de sua prova confirmar que todas as transições de estado feitas no rollup eram válidas. Devido à natureza de conhecimento zero, a prova apresentada não pode revelar informações sobre o estado atual.

No caso do Optimistic Rollup, há um exemplo semelhante em que Alice envia uma afirmação sobre o Ethereum, mas os participantes do OPR não podem recalcular ou contestar a reivindicação porque os dados da transação não estão disponíveis.

Em resposta ao acima, tanto o OPR quanto o ZKR são projetados para exigir que os operadores enviem todos os detalhes da transação para o Ethereum como “calldata”. Embora isso permita que eles evitem problemas de DA no curto prazo, à medida que o número de transações dentro de um pacote cumulativo aumenta, aumenta também a quantidade de dados que precisam ser enviados, limitando a quantidade de dimensionamento que esses pacotes cumulativos podem fornecer.

Para piorar a situação, a indisponibilidade de dados é um erro que não pode ser atribuído exclusivamente. Isso significa que os participantes não podem provar a outros nós que um determinado bloco de dados está faltando. Isso ocorre porque Bob pode transmitir que o bloco enviado por Alice está faltando dados, mas Charlie pode fornecer dados para Alice quando ela o consulta.

Como os problemas de disponibilidade de dados afetam os blockchains atuais?

Para responder a essa pergunta, vamos primeiro analisar a estrutura geral de blocos de blockchains semelhantes ao Ethereum e os tipos de clientes que existem em qualquer rede blockchain.

Um bloco pode ser dividido em duas partes principais:

• Cabeçalho do bloco: Um pequeno cabeçalho de bloco contém um resumo e metadados relacionados às transações contidas no bloco.
• Corpo do bloco: Contém todos os dados da transação e forma a parte principal do bloco.

Nos protocolos de blockchain tradicionais, todos os nós são considerados nós completos, e eles sincronizam todo o bloco e verificam todas as transições de estado. Eles exigem muitos recursos para verificar a validade das transações e armazenar blocos. A vantagem é que esses nós não aceitarão transações inválidas.

Pode haver outro tipo de nó que não tenha (ou não queira gastar) os recursos para validar cada transação. Em vez disso, eles estão principalmente interessados em entender o estado atual do blockchain e se algumas transações relacionadas a eles estão incluídas na cadeia. Idealmente, esses clientes leves também devem ser protegidos de serem falsificados por cadeias contendo transações inválidas. Na verdade, isto pode ser conseguido utilizando o que é conhecido como à prova de fraude. Essas mensagens sucintas mostram que um determinado bloco contém transações inválidas. Qualquer nó completo pode produzir essa prova de fraude, para que clientes leves não precisem confiar em um nó completo específico para serem honestos. Eles só precisam se certificar de que estão bem conectados a uma rede de fofocas que garante que, se houver uma prova de fraude do cabeçalho do bloco disponível, eles a receberão.

No entanto, há um problema com este sistema: e se um produtor de blocos não revelar todos os dados por trás de um bloco? Neste caso, os nós completos obviamente rejeitarão o bloco porque, em sua opinião, se um bloco não vem com um corpo de bloco, então ele nem é um bloco. No entanto, clientes leves podem ser expostos ao cabeçalho do bloco e não notar que os dados estão faltando. Ao mesmo tempo, nós completos não podem produzir provas de fraude porque não têm os dados necessários para criar provas de fraude.

Para combater isso, precisamos de um mecanismo para clientes leves verificarem a disponibilidade de dados. Isso garantirá que o produtor do bloco que oculta os dados não possa ser evitado convencendo o cliente leve. Isso também forçará os produtores de blocos a revelar alguns dos dados, permitindo que toda a rede acesse os dados de todo o bloco de forma colaborativa.

Vamos dar uma olhada mais profunda nesta questão com um exemplo. Digamos que a produtora de blocos Alice construa um bloco B contendo transações tx 1, tx 2 、…、 txn. Digamos que tx 1 é uma transação maliciosa. Se tx 1 for transmitido, qualquer nó completo pode verificar se é malicioso e enviar essas informações como uma prova de fraude para o cliente light, que saberá imediatamente que o bloqueio é inaceitável. No entanto, se Alice quiser ocultar tx 1, ela só revela o cabeçalho e todos os dados de transação, exceto tx 1. Um nó completo não pode verificar a exatidão de tx 1.

Pode-se pensar que uma solução simples seria ter todos os clientes leves amostras aleatórias de transações, e se eles descobrirem que sua amostra está disponível, eles podem ter certeza de que o bloco está disponível. No entanto, se o nó light for solicitado a consultar qualquer transação aleatoriamente, a probabilidade de o cliente light consultar tx 1 é de 1/n. Como resultado, Alice quase sempre será capaz de enganar um cliente leve para aceitar uma transação maliciosa. Em outras palavras, a maioria dos clientes leves são falsificados. Devido à natureza não atribuível, um nó completo não pode provar de forma alguma que tx 1 está indisponível. Infelizmente, aumentar o tamanho da amostra não torna as coisas melhores.

Então, como resolver este problema?

A solução para este problema reside na introdução de redundância nos blocos. Há um rico conjunto de literatura que pode nos ajudar a resolver esse problema quando se trata de teoria da codificação, especialmente codificação de apagamento.

Em suma, a codificação de apagamento nos permite expandir quaisquer n blocos de dados em 2 n blocos para que n de qualquer 2 n seja suficiente para reconstruir os dados originais (os parâmetros são ajustáveis, mas aqui consideramos este caso por uma questão de simplificação).

Se forçarmos o produtor do bloco a apagar as transações tx 1, tx 2 、…、 txn, então para ocultar uma única transação, ele precisa ocultar n+ 1 partes, porque quaisquer n partes são suficientes para construir todo o conjunto de transações. Neste caso, um pequeno número de consultas pode dar ao cliente leve um alto grau de confiança de que os dados subjacentes estão realmente disponíveis.

Woah, então é isso?

Não. Embora este truque simples torne mais difícil ocultar dados, ainda é possível que o produtor do bloco tenha deliberadamente apagado a codificação da maneira errada. No entanto, um nó completo pode verificar se essa codificação de eliminação está sendo feita corretamente e, se não, pode prová-lo para o cliente leve. Este é outro tipo de prova de fraude, assim como as transações maliciosas mencionadas acima. Curiosamente, tudo o que é preciso é um nó completo honesto para agir como um vizinho de um cliente leve, garantindo que, se um bloco for malicioso, ele receberá uma prova de fraude. Isso garante que clientes leves sejam capazes de acessar uma cadeia com uma probabilidade muito alta de estar livre de transações maliciosas.

Mas há um porém. Se feito de forma muito simples, algumas provas de fraude podem ser tão grandes quanto o tamanho do próprio bloco. Nossas suposições de recursos para clientes leves nos proíbem de usar tal design. Foram introduzidas melhorias através da utilização de técnicas de codificação de eliminação multidimensional que reduziram o tamanho das provas de fraude, mas ao custo de aumentar o tamanho da promessa. Por uma questão de brevidade, não entraremos em detalhes sobre eles aqui, mas este artigo fornece uma análise detalhada deles.

O problema com uma solução de prova de fraude é que um cliente leve nunca pode ter certeza completa de qualquer bloco para o qual ainda não recebeu uma prova de fraude. Ao mesmo tempo, eles continuam a confiar que seus nós completos são honestos. Os nós honestos também precisam ser incentivados a revisar blocos de forma consistente.

O que estamos vendo aqui são os sistemas que garantem que, se a codificação de bloco for inválida, nós completos podem detetar e fornecer provas aos clientes leves para convencê-los de má conduta. No entanto, na próxima seção, vamos nos concentrar em códigos de bloco que garantem que apenas códigos válidos podem ser enviados para a cadeia. Isso elimina a necessidade de provas de fraude que precisam provar erros de codificação. As soluções de prova de validade permitem que os aplicativos usem o sistema sem ter que esperar por nós completos para fornecer esse tipo de prova de fraude.

Então, como funcionam essas soluções?

Recentemente, promessas polinomiais despertaram um interesse renovado no espaço blockchain. Esses compromissos polinomiais, especialmente o compromisso KZG/Kate de tamanho constante com polinômios, podem ser usados para projetar um esquema de disponibilidade de dados limpos (DA) que não exija provas de fraude. Em poucas palavras, a promessa KZG nos permite nos comprometer com um polinômio usando um único elemento de grupo de curva elíptica. Além disso, o esquema nos permite provar que, em um determinado ponto i, o valor do φ polinomial é φ(i), usando uma testemunha de tamanho constante. Este esquema de compromisso é computacionalmente vinculativo e homomórfico, permitindo-nos contornar inteligentemente as provas de fraude.

Forçamos os produtores de blocos a organizar os dados brutos da transação em uma matriz bidimensional de tamanho n x m. Ele usa interpolação polinomial para expandir o tamanho n de cada coluna para uma coluna de tamanho 2 n. Cada linha dessa matriz estendida gera um compromisso polinomial e envia esses compromissos como parte do cabeçalho do bloco. Uma representação esquemática do bloco é dada abaixo.

O cliente light consulta qualquer célula dessa matriz estendida para obter prova, o que permite que ela seja verificada em relação ao cabeçalho do bloco instantaneamente. A identificação de membros de tamanho constante torna a amostragem extremamente eficiente. O homomorfismo comprometido garante que as provas só possam ser verificadas se o bloco for construído corretamente, enquanto a interpolação polinomial garante um número constante de amostras bem-sucedidas, o que significa que a probabilidade de disponibilidade de dados é muito alta.

! [Qual é o problema com a disponibilidade de dados?] (https://piccdn.0daily.com/202311/17064433/5gjxe19ptk6oa203.png!webp)

Uma representação esquemática de um bloco

As partes mais detalhadas desse cenário, bem como a otimização adicional e as estimativas de custo, estão além do escopo deste artigo. No entanto, gostaríamos de salientar que, embora estejamos falando de um esquema 2D aqui, garantias semelhantes também podem ser fornecidas através de um esquema 1D com um tamanho de cabeçalho de bloco menor, mas ao custo de paralelismo reduzido e eficiência de amostragem leve do cliente. Vamos explorar isso com mais profundidade em um artigo de acompanhamento.

Quais são as outras alternativas? Quais são as próximas etapas?

A codificação de eliminação de alta dimensão e o compromisso KZG não são a única maneira de resolver problemas de disponibilidade de dados. Nós pulamos algumas outras abordagens aqui, como a codificação de árvores Merkle, codificação de árvores intercaladas, FRI, e métodos baseados em STARK, mas cada um tem suas vantagens e desvantagens.

Na Avail, temos usado o compromisso KZG para desenvolver soluções de disponibilidade de dados. Em um artigo subsequente, abordaremos os detalhes da implementação, como usá-la e como planejamos alterar o espaço do problema de disponibilidade de dados. Para saber mais sobre a Avail, siga-nos no Twitter

Twitter é uma plataforma de serviços de rede social originária dos Estados Unidos. Em 27 de outubro de 2022, Musk concluiu sua aquisição do Twitter e o fundiu com a recém-formada empresa “X”. De acordo com a mensagem anterior de Musk no Twitter, ele criará um aplicativo com tudo incluído, e mencionou que comprar o Twitter pode acelerar esse desejo.

e junte-se ao nosso servidor Discord.

Twitter:

Discórdia:

Siga a Modular 101 no Twitter em @Modular 101