Introdução

O roteiro do Ethereum incorpora uma tecnologia de escalonamento chamada Data Availability Sampling(DAS) 6. DAS apresenta o novo < a href= " https://notes.ethereum.org/@djrtwo/das-requisitos " > requisitos 4 para a pilha de redes da Ethereum, necessitando da implementação de protocolos de rede especializados 7. Um proeminente < a href= " https://notes.ethereum.org/@dankrad/s-Kademlia-das " > protocolo a proposta 4 utiliza uma Tabela de Hash Distribuída (DHT) baseada na Kademlia 2 para armazenar e recuperar as amostras dos dados.

No entanto, os DHTs 4 são suscetíveis a ataques Sybil: Um atacante que controla um grande número de nós DHT pode tornar as amostras DAS indisponíveis. Para neutralizar esta ameaça, pode ser estabelecida uma camada de rede de alta confiança, consistindo apenas em validadores de cadeia de beacon. Tal medida de segurança aumenta significativamente a barreira para os atacantes, uma vez que eles devem agora ter a sua própria ETH para atacar o DHT.

Neste post, apresentamos uma prova de protocolo validador, que permite aos participantes do DHT demonstrar, com conhecimento zero, que são um validador Ethereum.

Motivação: Ataque de “ocultação de amostras” no DAS

Nesta secção, motivamos ainda mais a prova do protocolo do validador descrevendo um ataque Sybil contra a amostragem de disponibilidade de dados.

O protocolo DAS gira em torno do construtor de blocos garantindo que os dados do bloco sejam disponibilizados para que os clientes possam buscá-los. As abordagens atuais envolvem a partição de dados em amostras, e os participantes da rede apenas buscam amostras que pertencem aos seus interesses.

)

Considere um cenário em que um invasor Sybil quer impedir que os participantes da rede busquem amostras de um nó da vítima, que é responsável por fornecer a amostra. Conforme ilustrado na figura acima, o invasor gera muitos IDs de nós que estão próximos do ID do nó da vítima. Ao cercar o nó da vítima com os seus próprios nós, o atacante impede os clientes de descobrirem o nó da vítima, uma vez que os nós malignos irão deliberadamente reter informações sobre a existência da vítima.

Para mais informações sobre esses ataques Sybil, consulte este recente artigo de investigação 2 sobre ataques DHT Eclipse. Além disso, < a href= " https://notes.ethereum.org/@dankrad/s-Kademlia-das #SKademlia -modificações " > Dankrad's A proposta de protocolo de rede DAS 8 descreve como o protocolo S/Kademlia DHT sofre de tais ataques e mostra a necessidade de uma prova do protocolo validador.

Prova de Validador

O ataque acima motiva a necessidade de uma prova de protocolo validador: Se apenas os validadores puderem aderir ao DHT, então um invasor que queira lançar um ataque Sybil também deve apostar uma grande quantidade de ETH.

Usando o nosso protocolo de prova de validador, garantimos que apenas os validadores da cadeia de beacon podem aderir ao DHT e que cada validador obtém uma identidade DHT única.

Além disso, para a resiliência do validador DoS, também pretendemos ocultar a identidade dos validadores na camada de rede. Ou seja, não queremos que os invasores possam dizer qual nó DHT corresponde a qual validador.

Para cumprir estes objetivos, o protocolo de prova do validador deve cumprir os seguintes requisitos:

• Exclusividade: Cada validador de cadeia de beacon deve ser capaz de derivar um único par de chaves único. Esta propriedade não só restringe o número de nós que um invasor Sybil pode gerar, mas também permite que os participantes da rede punam localmente os nós que se comportam mal, bloqueando o seu par de chaves derivado
• Privacidade: Os adversários devem ser incapazes de saber qual validador corresponde a uma chave pública derivada específica
• Tempo de verificação: O processo de verificação do protocolo deve ser eficiente, levando menos de 200ms por nó, permitindo que cada nó aprenda pelo menos cinco novos nós por segundo

Essa prova de protocolo validador seria usada por Bob durante o estabelecimento da conexão na camada DHT, para que Alice saiba que está a falar com um validador.

Prova do protocolo Validator

A nossa prova de protocolo validador é efetivamente um simples esquema de credenciais anónimas. O seu objetivo é permitir que Alice gere uma chave derivada única, denotada como D, se e só se ela for uma validadora. Posteriormente, Alice usa esta chave derivada D dentro da camada de rede.

Ao conceber este protocolo, o nosso objetivo era criar uma solução que fosse simples de implementar e analisar, garantindo que cumpre os requisitos descritos de forma eficiente.

Visão geral do protocolo

O protocolo emprega um subprotocolo de prova de adesão, em que Alice prova que é uma validadora ao demonstrar conhecimento de uma pré-imagem de hash secreta usando provas ZK. Alice constrói então um par de chaves único derivado dessa pré-imagem secreta de hash.

O subprotocolo de prova de adesão pode ser instanciado através de diferentes métodos. Neste post, mostramos um protocolo usando árvores Merkle e um segundo protocolo usando pesquisas.

Embora ambas as abordagens demonstrem uma eficiência aceitável, apresentam compensações distintas. As árvores Merkle dependem de funções hash amigáveis ao Snark como o Poseidon (que pode ser considerado experimental). Por outro lado, protocolos de pesquisa eficientes dependem de uma configuração fidedigna de potências de tau de tamanho igual ao tamanho do conjunto de validadores (atualmente 700k validadores mas em crescimento).

Agora vamos mergulhar nos protocolos:

Abordagem #1: Merkle Trees

As árvores de Merkle têm visto uma utilização generalizada para provas de adesão (ex. ver Semáforo 3). Aqui está o espaço de troca ao projetar uma prova de associação usando árvores Merkle:

• Positivo: Não há necessidade de configuração confiável
• Positivo: Simples de entender
• Negativo: Confia-se em funções hash amigáveis ao Snark, como o Poseidon
• Negativo: Criação de prova mais lenta

Abaixo descrevemos a prova do protocolo validador baseado em árvores Merkle:

Protocolo de prova de validador usando árvores Merkle

)

No final do protocolo, Alice pode usar D no DHT para assinar mensagens e derivar a sua identidade única de nó DHT.

Agora vamos olhar para uma solução um pouco mais complicada, mas muito mais eficiente, usando pesquisas.

Abordagem #2: Pesquisas

Aqui está o espaço de compensação de usar protocolos de pesquisa 2 como Caulk 2:

• Positivo: Criação de provas extremamente eficiente (usando uma fase de pré-processamento)
• Positivo: O protocolo pode ser adaptado para usar uma função hash regular em vez de Poseidon
• Negativo: Requer uma configuração fidedigna de tamanho grande (idealmente igual ao tamanho dos validadores)

Abaixo descrevemos uma prova concreta do protocolo do validador:

Prova do protocolo do validador usando pesquisas

Exatamente como na abordagem Merkle, cada validador i registra um novo valor pi na cadeia de blocos tal que:

Eficiência

Fizemos um benchmark do tempo de execução do nosso protocolo de prova de adesão (link 6 ao código de referência 5) em termos de criação e verificação de provas. Note que, embora a prova de adesão seja apenas uma parte do nosso protocolo de prova de validador, esperamos que domine o tempo de execução geral.

Abaixo, fornecemos resultados de referência para uma prova de adesão à merkle tree usando o sistema de prova Halo2 com IPA como o esquema de compromisso polinomial. O IPA é um esquema mais lento que o KZG mas não requer uma configuração confiável que maximize as vantagens da abordagem da árvore de merkle.

Observamos que tanto os tempos do provador como do verificador alinham-se bem com os nossos requisitos de eficiência. Por esta razão, decidimos não fazer o benchmarking da abordagem baseada em Caulk, uma vez que se espera que o seu desempenho seja significativamente melhor em todas as categorias (especialmente o tempo de prova e o tamanho da prova).

Os benchmarks foram recolhidos num computador portátil com um Intel i7-8550U (CPU de cinco anos).

Discussão

Identidades rotativas

A propriedade de exclusividade do protocolo de prova do validador garante que cada participante da rede possui um par de chaves derivado distinto. No entanto, para certos protocolos de rede, pode ser vantajoso permitir que os validadores tenham identidades rotativas, onde as suas chaves derivadas mudam periodicamente, talvez diariamente.

Nesse cenário, se Eva se comportar mal num determinado dia, a Alice pode bloqueá-la para esse dia. No entanto, no dia seguinte, Eve pode gerar uma nova chave derivada, que não está na lista de bloqueio. Se quiséssemos poder bloquear permanentemente validadores com base na sua identidade rotativa, precisaríamos de um esquema de credenciais anónimas mais avançado como o SmarkBlock 1.

Por que não usar a identidade BLS12-381 chave pública?

Uma abordagem alternativa (talvez mais simples) seria construir um compromisso com todas as chaves BLS12-381 da identidade do validador e fazer uma prova de adesão desse compromisso.

No entanto, esta abordagem exigiria que os validadores inserissem a sua chave privada de identidade no sistema de prova ZK para criar uma prova de adesão válida e calcular a chave derivada única.

Decidimos não adotar esta abordagem porque não é uma boa prática inserir chaves de identidade confidenciais em protocolos criptográficos complicados, e também tornaria mais difícil para os validadores manterem a sua chave de identidade principal offline.

Orientações de investigação futuras

• Podemos evitar completamente os circuitos SNARK e realizar a prova de adesão e derivação de chave de uma forma puramente algébrica?
• Relacionados: Podemos ter uma prova eficiente de protocolo de adesão sem uma configuração fidedigna e sem depender de funções hash amigáveis ao Snark?

Agradecimentos

Obrigado a Enrico Bottazzi, Cedoor, Vivian Plasencia e Wanseob pela ajuda na navegação na web de bases de código de prova de adesão.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [ethresear]. Todos os direitos de autor pertencem ao autor original [George Kadianakis, Mary Maller, Andrija Novakovic, Suphanat Chunhapanya]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As
   opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.