Prova de validador: um esquema simples de credenciais anônimas para DHT da Ethereum

Introdução

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

No entanto, os DHTs 4 são suscetíveis a ataques Sybil: um invasor 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 de validadores de cadeia de beacon. Tal medida de segurança aumenta significativamente a barreira para os atacantes, uma vez que agora devem apostar a sua própria ETH para atacar o DHT.

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

Motivação: ataque de “ocultação de amostra” ao DAS

Nesta seção, motivamos ainda mais a prova do protocolo validador descrevendo um ataque Sybil contra 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 o particionamento de dados em amostras, e os participantes da rede buscam apenas amostras que pertençam aos seus interesses.

)

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

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

Prova de Validador

O ataque acima motiva a necessidade de um protocolo de prova de validação: se apenas os validadores puderem ingressar no DHT, então um invasor que queira lançar um ataque Sybil também deverá apostar uma grande quantidade de ETH.

Usando nosso protocolo de prova de validador, garantimos que apenas validadores de cadeia de beacon possam ingressar no DHT e que cada validador obtenha uma identidade DHT exclusiva.

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

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

• Exclusividade: Cada validador de cadeia de beacon deve ser capaz de derivar um único par de chaves. Esta propriedade não apenas 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, colocando na lista de bloqueio seu par de chaves derivado.
• Privacidade: os adversários não devem ser capazes de saber qual validador corresponde a uma determinada chave pública derivada
• Tempo de verificação: O processo de verificação do protocolo deve ser eficiente, demorando menos de 200 ms por nó, permitindo que cada nó aprenda pelo menos cinco novos nós por segundo

Tal protocolo de prova de validação seria usado por Bob durante o estabelecimento da conexão na camada DHT, para que Alice saiba que está falando com um validador.

Protocolo de prova de validador

Nosso protocolo de prova de validação é efetivamente um esquema simples de credenciais anônimas. Seu objetivo é permitir que Alice gere uma chave derivada única, denotada como D, se e somente se ela for uma validadora. Posteriormente, Alice usa essa chave derivada D na camada de rede.

Ao projetar este protocolo, nosso objetivo foi criar uma solução que fosse simples de implementar e analisar, garantindo que atendesse aos 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, demonstrando conhecimento de uma pré-imagem de hash secreta usando provas ZK. Alice então constrói um par de chaves exclusivo derivado dessa pré-imagem de hash secreta.

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 eficiência aceitável, elas apresentam compensações distintas. As árvores Merkle contam com funções hash compatíveis com SNARK, como Poseidon (que pode ser considerada experimental). Por outro lado, protocolos de pesquisa eficientes dependem de uma configuração confiável de poderes de tau de tamanho igual ao tamanho do conjunto de validadores (atualmente 700 mil validadores, mas em crescimento).

Agora vamos mergulhar nos protocolos:

Abordagem nº 1: Árvores Merkle

As árvores Merkle têm sido amplamente utilizadas para provas de adesão (por exemplo, veja Semáforo 3). Aqui está o espaço de compensação ao projetar uma prova de adesão usando árvores Merkle:

• Positivo: não há necessidade de configuração confiável
• Positivo: Simples de entender
• Negativo: depende de funções hash compatíveis com SNARK, como 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 sua identidade exclusiva de nó DHT.

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

Abordagem nº 2: pesquisas

Aqui está a compensação do uso de 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 confiável de tamanho grande (idealmente igual ao tamanho dos validadores)

Abaixo descrevemos uma prova concreta do protocolo validador:

Prova do protocolo validador usando pesquisas

Exatamente como na abordagem Merkle, cada validador i registra um novo valor pi no blockchain tal que:

Eficiência

Comparamos o tempo de execução do nosso protocolo de prova de adesão (link 6 ao código de benchmark 5) em termos de criação e verificação de prova. Observe que, embora a prova de adesão seja apenas uma parte do nosso protocolo de prova do validador, esperamos que ela domine o tempo geral de execução.

Abaixo, fornecemos resultados de benchmark para uma prova de associação de árvore merkle usando o sistema de prova Halo2 com IPA como 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 merkle.

Observamos que os tempos do provador e do verificador se alinham bem com nossos requisitos de eficiência. Por esse motivo, decidimos não fazer o benchmarking da abordagem baseada em Caulk, já que se espera que seu desempenho seja significativamente melhor em todas as categorias (especialmente no tempo de prova e no tamanho da prova).

Os benchmarks foram coletados em um laptop rodando em um Intel i7-8550U (CPU com cinco anos).

Discussão

Identidades rotativas

A propriedade de exclusividade do protocolo de prova do validador garante que cada participante da rede possua 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 em um determinado dia, Alice poderá bloqueá-la naquele dia. No entanto, no dia seguinte, Eve pode gerar uma nova chave derivada, que não está na lista de bloqueio. Se quiséssemos bloquear validadores permanentemente com base em sua identidade rotativa, precisaríamos de um esquema de credenciais anônimas mais avançado, como SNARKBlock 1.

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

Uma abordagem alternativa (talvez mais simples) seria construir um compromisso de todas as chaves de identidade do validador BLS12-381 e fazer uma prova de adesão a esse 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 essa 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 sua chave de identidade principal offline.

Direções de pesquisas futuras

• Podemos evitar totalmente os circuitos SNARK e realizar a prova de pertinência e a derivação da chave de maneira puramente algébrica?
• Relacionado: Podemos ter um protocolo de prova de associação eficiente sem uma configuração confiável e sem depender de funções hash compatíveis com SNARK?

Reconhecimentos

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

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [ethresear]. Todos os direitos autorais pertencem ao autor original [George Kadianakis, Mary Maller, Andrija Novakovic, Suphanat Chunhapanya]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: Th
   As opiniões e opiniões expressas neste artigo são de responsabilidade exclusiva do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.