Como podem os pares numa rede blockchain ter a certeza de que todos os dados de um bloco recém-proposto estão disponíveis? E por que é importante?

Neste post, mergulhamos nos detalhes do problema de disponibilidade de dados e como pode afetar a escalabilidade no Ethereum.

Qual é o problema da Disponibilidade de Dados?

O problema de Disponibilidade de Dados (DA): Como é que os pares numa rede de blockchain podem ter a certeza de que todos os dados de um bloco recém-proposto estão realmente disponíveis? Se os dados não estiverem disponíveis, o bloco pode conter transações maliciosas que estão a ser ocultadas pelo produtor do bloco. Mesmo que o bloco contenha transações não maliciosas, ocultá-las pode comprometer a segurança do sistema.

Para dar um exemplo, suponha que Alice seja uma operadora de um ZK-Rollup (ZKR). Ela submete uma Prova-ZK no Ethereum que é verificada. Se ela não submeter todos os dados transacionais no Ethereum, embora a sua prova prove que todas as transições de estado tomadas no rollup são válidas, ainda assim os utilizadores do rollup podem ficar no escuro sobre os seus saldos de conta atuais. A prova submetida não lança luz sobre os estados atuais devido à sua natureza de Zero-Knowledge.

Existe um exemplo análogo em Rollup Otimista (OPR)configuração, onde Alice envia uma afirmação no Ethereum, mas nenhum dos participantes do OPR pode desafiá-la porque os dados transacionais não estão disponíveis e, portanto, não conseguem recalcular ou desafiar a afirmação.

Para combater os cenários acima, tanto os designs OPR quanto ZKR exigem que os operadores submetam todos os detalhes transacionais em Ethereumcomo 'calldata'. Embora isso os faça contornar o problema de DA a curto prazo, à medida que o número de transações cresce dentro dos rollups, a quantidade de dados que precisa ser submetida também cresceria, limitando a quantidade de escalabilidade que esses rollups podem oferecer.

Para piorar as coisas, a indisponibilidade de dados não é uma falha unicamente atribuível. Isso significa que os participantes não conseguem provar a outros pares que um determinado pedaço de dados está em falta. Isto acontece porque Bob pode transmitir que o bloco submetido por Alice tem dados em falta, mas quando Charlie questiona Alice, ela pode fornecer-lhe os dados.

Como é que isto afeta uma blockchain hoje?

Para responder a esta pergunta, vamos primeiro revisitar a estrutura geral do bloco de uma blockchain semelhante 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 do bloco contém o resumo e metadados relacionados às transações incluídas no bloco.
• Corpo do bloco: Este contém todos os dados transacionais e constitui a maioria do tamanho do bloco.

Nos protocolos blockchain convencionais, todos os nós são considerados nós completos que sincronizam o bloco inteiro e verificam todas as transições de estado. Eles precisam gastar uma quantidade considerável de recursos para verificar a validade das transações e armazenar os blocos. Por outro lado, esses nós não podem ser feitos para aceitar qualquer transação inválida.

Pode haver outra classe de nós que não têm (ou não querem gastar) recursos para verificar todas as transações. Em vez disso, estão principalmente interessados em saber o estado atual da blockchain e se algumas transações, que são relevantes para eles, estão incluídas na cadeia ou não. Idealmente, esses clientes leves também devem estar protegidos de seguir uma cadeia que contenha transações inválidas. Isso é realmente possível usando chamados provas de fraude. Estas são mensagens sucintas que mostram que um determinado corpo de bloco inclui uma transação que é inválida. Qualquer nó completo pode produzir tal prova de fraude, e o cliente leve, assim, não precisa confiar que um determinado nó completo é honesto. Eles apenas têm que garantir que estão bem conectados a uma rede de fofocas que garanta que, se houver prova de fraude disponível para um cabeçalho de bloco, 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, pois na sua perspetiva, nem sequer é um bloco se não vier com o corpo do bloco. Os clientes leves, no entanto, podem ser apresentados com a cadeia de cabeçalhos e não têm forma de perceber que os dados estão em falta. Ao mesmo tempo, os nós completos não podem produzir provas de fraude, porque estarão em falta os dados necessários para criar provas de fraude.

Para combater isso, precisamos de um mecanismo para que clientes leves verifiquem a disponibilidade de dados. Isso garantiria que um produtor de bloco que esconde dados não possa convencer um cliente leve do contrário. Também forçaria o produtor de bloco a revelar partes dos dados, fazendo com que toda a rede tenha acesso ao bloco inteiro de forma colaborativa.

Vamos aprofundar um pouco mais o problema com a ajuda de um exemplo. Suponha que a produtora de blocos Alice construa um bloco B com transações tx1, tx2, …, txn. Vamos supor que tx1 seja uma transação maliciosa. Se tx1 for transmitida, qualquer nó completo pode verificar que é maliciosa e enviar isso para um cliente leve como prova de fraude, que imediatamente saberia que o bloco é inaceitável. No entanto, se Alice quiser esconder tx1, ela revela o cabeçalho e todos os dados transacionais, exceto tx1. Os nós completos não podem verificar a correção de tx1.

Pode-se pensar que uma solução simples é se todos os clientes leves simplesmente amostrarem as transações aleatoriamente e, se encontrarem suas amostras disponíveis, podem ter a certeza de que o bloco está disponível. Deixe os nós leves consultarem uma transação, uniformemente ao acaso. A probabilidade de o cliente leve consultar tx1 é 1/n. Assim, com uma probabilidade esmagadora, Alice consegue enganar os clientes leves a aceitar uma transação maliciosa. Em outras palavras, a maioria dos clientes leves será enganada. Devido à natureza não atribuível, os nós completos não podem provar de forma alguma que tx1 não está disponível. Infelizmente, aumentar o número de amostras não melhora muito isso.

Então, o que fazemos sobre isto?

A solução para este problema reside em introduzir redundância num bloco. Existe um vasto conjunto de literatura sobre teoria de codificação em geral e codificação de apagamento em particular, que nos pode ajudar com este problema.

Numa palavra, a codificação de apagamento permite-nos estender qualquer n pedaços de dados em 2n pedaços de dados de tal forma que qualquer n em 2n são suficientes para reconstruir o pedaço original de dados (os parâmetros são ajustáveis, mas aqui consideramos isto para simplicidade).

Se obrigarmos o produtor de blocos a codificar por apagamento as transações tx1, tx2, …, txn, então, para esconder uma única transação, seria necessário esconder n+1 fragmentos de dados, já que qualquer n é suficiente para construir o conjunto inteiro de transações. Neste caso, um número constante de consultas dá ao cliente leve uma confiança muito alta de que os dados subjacentes estão realmente disponíveis.

Uau, então é isso?

Embora este truque simples torne o trabalho de ocultação mais difícil, ainda é possível que o produtor de bloco simplesmente execute intencionalmente a codificação de apagamento de forma errada. No entanto, um nó completo pode verificar se esta codificação de apagamento foi feita corretamente e, caso contrário, pode prová-lo a um cliente leve. Este é outro tipo de prova de fraude, tal como no caso de transações maliciosas acima. Curiosamente, precisa de existir um único vizinho honesto de nó completo de um cliente leve para ter a certeza de que, se o bloco for malicioso, receberá uma prova de fraude. Isto garante que o cliente leve tenha acesso a uma cadeia sem transações maliciosas com uma probabilidade muito alta.

Mas há uma ressalva. Se feito de forma ingênua, o tamanho de algumas provas de fraude pode ser da ordem do tamanho do bloco em si. A suposição de recursos que tínhamos sobre o cliente leve nos impede de usar um design desses. Houve melhorias nesse sentido ao usar técnicas de codificação de apagamento multidimensional que reduzem o tamanho das provas de fraude com o custo do tamanho do compromisso. Por uma questão de concisão, não abordamos esses aspetos, mas este papeltem uma análise detalhada disso.

O problema com soluções baseadas em prova de fraude é que os clientes leves nunca têm certeza completa sobre qualquer bloco para o qual ainda não receberam uma prova de fraude. Além disso, confiam continuamente que os seus pares de nós completos são honestos. Os nós honestos também precisam de incentivos para continuar a auditar os blocos.

Focámo-nos aqui em sistemas que garantam que, se a codificação do bloco for inválida, os nós completos possam detetá-la e fornecer prova aos clientes leves que os convença do erro. No entanto, na próxima secção, iremos analisar as codificações de bloco que garantem que apenas as codificações válidas podem ser comprometidas na cadeia. Isto elimina a necessidade de provas de fraude que comprovem erros de codificação. Estas soluções baseadas em provas de validade permitem que as aplicações utilizem o sistema sem terem de esperar por este tipo de provas de fraude dos nós completos.

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

Recentemente, os compromissos polinomiais têm suscitado um interesse renovado no espaço da blockchain. Estes compromissos polinomiais, especialmente os compromissos de tamanho constante KZG/Kate para polinómios, pode ser usado para projetar um esquema DA arrumado sem a necessidade de provas de fraude. Em suma, os compromissos KZG nos permitem nos comprometer com um polinômio usando um único elemento de grupo de curva elíptica. Além disso, o esquema nos apoia para provar que em algum ponto i o polinômio φ avalia para φ(i) usando uma testemunha de tamanho constante. O esquema de compromisso é computacionalmente vinculativo e também é homomórfico, nos permitindo evitar fraudes de maneira arrumada.

Forçamos o produtor de blocos a pegar os dados transacionais originais e organizá-los em uma matriz 2D de tamanho n x m. Utiliza interpolação polinomial para estender cada coluna de tamanho n em colunas de tamanho 2n. Cada linha desta 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.

Os clientes leves consultam qualquer célula desta matriz estendida para obter a testemunha que permite verificar imediatamente contra o cabeçalho do bloco. As provas de adesão de tamanho constante tornam a amostragem extremamente eficiente. A natureza homomórfica do compromisso garante que a prova verifique apenas se o bloco for construído corretamente e a interpolação polinomial garante que um número constante de amostras bem-sucedidas signifique que os dados estão disponíveis com uma probabilidade muito alta.

Uma representação esquemática do bloco

Os detalhes mais finos do esquema juntamente com otimizações adicionais e estimativas de custo estão além do âmbito deste artigo. No entanto, gostaríamos de salientar que embora discutamos um esquema 2D aqui, garantias semelhantes podem ser fornecidas com um esquema 1D também, que tem um tamanho de cabeçalho menor ao custo de menos paralelismo e eficiência de amostragem de cliente leve. Vamos aprofundar isso em artigos de acompanhamento.

Quais são as outras alternativas e o que se segue?

O código de apagamento de dimensão superior e os compromissos KZG não são as únicas maneiras de abordar o problema DA. Há outras maneiras que nós ignoramos aqui, como Árvores Merkle Codificadas, Árvore de Interlaçamento Codificado, FRI, e abordagens baseadas em STARK, mas cada uma tem seus méritos e deméritos.

Na Avail, temos estado a trabalhar numa solução de Disponibilidade de Dados usando compromissos KZG. Em publicações posteriores, iremos abordar os detalhes de implementação, como pode utilizá-lo hoje e como pretendemos transformar o espaço do problema DA. Para mais informações sobre Avail, siga-nos em Twittere junte-se a nósServidor do Discord.

Aviso legal：

1. Este artigo é reimpresso de [GateEquipe Avail]. Todos os direitos de autor pertencem ao autor original [Equipe Avail]. Se houver objeções a este reenvio, entre em contato com o [GateGate Learn] equipa e eles vão tratar disso prontamente.

2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.

3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.