Catching the Fly: Practical Challenges in Making Blockchain FlyClient Real

1. Declaração do Problema

FlyClient é um protocolo teórico projetado para permitir a verificação ultraleve de blockchains de Prova de Trabalho (PoW). Ele permite que clientes (por exemplo, carteiras móveis, dispositivos IoT, contratos inteligentes) verifiquem a validade de uma blockchain com complexidade de dados logarítmica ($O(\log n)$), em vez de complexidade linear, utilizando amostragem probabilística de cabeçalhos de bloco e compromissos de Intervalo de Montanha de Merkle (MMR).

Apesar de sua promessa teórica, o FlyClient enfrenta barreiras significativas para implantação no mundo real:

• Falta de Implementação em Produção: Não havia implementações de provedor existentes para blockchains de produção principais (especificamente o Zcash, que suporta nativamente o FlyClient via hard fork).
• Modelos de Adversário Abstratos: O modelo de segurança original depende de um adversário $(c, L)$ (um atacante que não pode produzir uma bifurcação de comprimento $L$ com taxa de validade $c$). Este modelo é matematicamente conveniente, mas carece de uma interpretação econômica direta, dificultando que praticantes configurem verificadores com base em orçamentos de ataque do mundo real.
• Ineficiência no Tamanho da Prova: Os tamanhos atuais das provas são dominados por grandes componentes de cabeçalho de bloco (especificamente soluções Equihash no Zcash), tornando a verificação on-chain (por exemplo, em pontes entre cadeias) proibitivamente cara em termos de custos de gás.
• Lacunas de Desempenho: Havia uma falta de dados empíricos sobre a sobrecarga de recursos necessária para executar um provedor FlyClient e os requisitos reais de largura de banda/armazenamento sob diversas condições de rede.

2. Metodologia

Os autores fecharam a lacuna entre teoria e prática através de três pilares metodológicos principais:

A. Refinamento Teórico: O Modelo de Adversário $w_a$

• Os autores introduziram o modelo de adversário $w_a$, que substitui os parâmetros abstratos $(c, L)$ por um único parâmetro concreto: o orçamento de trabalho adversarial ($w_a$).
• Este modelo define a capacidade de um atacante com base no trabalho cumulativo máximo que ele pode produzir dado um orçamento monetário específico (por exemplo, custo de eletricidade e hardware).
• Eles derivaram um procedimento de otimização matemática para mapear esse orçamento econômico para os parâmetros ideais do protocolo ($n_{det}$ e $n_{prob}$), minimizando o número de cabeçalhos amostrados enquanto mantêm um nível de segurança alvo ($\lambda$).

B. Implementação: Provedor FlyClient do Zcash

• A equipe estendeu o Zebrad, a implementação oficial em Rust do nó completo do Zcash, para funcionar como um provedor FlyClient.
• Eles implementaram funções específicas de Chamada de Procedimento Remoto (RPC) para servir cabeçalhos de bloco, nós MMR e dados de trabalho total.
• Eles realizaram benchmarks de desempenho para medir o impacto da manutenção de um banco de dados de nós MMR nos tempos de sincronização do nó e nos requisitos de armazenamento.

C. Estratégias de Otimização

Os autores propuseram e avaliaram duas otimizações distintas para reduzir o tamanho da prova:

1. Provas Cumulativas: Uma otimização em nível de software onde o verificador baixa uma única prova MMR cobrindo todos os blocos amostrados simultaneamente, em vez de provas individuais para cada bloco. Isso elimina downloads redundantes de nós sem exigir mudanças de consenso.
2. Provas Destiladas: Uma otimização em nível de consenso que exige um hard fork. Isso envolve:
   • Substituir o algoritmo Equihash (que exige o armazenamento de soluções de 1344 bytes nos cabeçalhos) por um PoW mais eficiente em espaço (por exemplo, Ethash/RandomX) ou uma variante com soluções pequenas.
   • "Destilar" cabeçalhos de bloco para incluir apenas campos necessários para a verificação FlyClient (removendo dados de transação e raízes desnecessárias).
   • "Destilar" nós MMR para armazenar apenas campos essenciais e hashes do restante.

3. Contribuições Principais

1. Modelo de Adversário Econômico: A introdução do modelo de adversário $w_a$ permite uma configuração intuitiva, baseada em orçamento, de verificadores FlyClient. Foi provado que este modelo satisfaz as garantias de segurança do modelo original $(c, L)$, enquanto oferece reduções no tamanho da prova de até 37% através da seleção otimizada de parâmetros.
2. Primeiro Provedor de Nível de Produção: O artigo apresenta a primeira implementação funcional de provedor FlyClient para Zcash (integrada ao Zebrad). Demonstra que adicionar funcionalidade FlyClient tem um impacto negligenciável no tempo de sincronização (a atualização do banco de dados leva ~10 horas para uma cadeia de 3 milhões de blocos, enquanto a sincronização completa leva ~40 horas).
3. Otimizações no Tamanho da Prova:
   • Provas Cumulativas: Alcançou uma redução de 9,16% no tamanho da prova não interativa com zero mudanças de consenso.
   • Provas Destiladas: Alcançou uma redução massiva de 71,33% no tamanho da prova não interativa, reduzindo o tamanho de ~1,2 MiB para ~320 KiB para uma cadeia de 3 milhões de blocos.

4. Resultados Experimentais

• Tamanho da Prova e Custo:
  • Linha de Base: Uma prova FlyClient não interativa padrão para uma cadeia Zcash de 3 milhões de blocos é de ~1,2 MiB. Passar isso para um contrato inteligente (via EIP-7623) custa aproximadamente $13,21 USD.
  • Otimização Cumulativa: Reduz o custo para $12,00 USD (-9,16%).
  • Otimização Destilada: Reduz o custo para $3,44 USD (-71,33%), tornando pontes entre cadeias sem confiança economicamente viáveis para transações mais frequentes.
• Sobrecarga de Recursos:
  • A implementação do provedor FlyClient não degrada significativamente o desempenho do nó. O tempo para atualizar o banco de dados de um nó existente para armazenar nós MMR é linear e gerenciável.
  • A representação "binária compactada" (zipped binary) foi encontrada como a mais eficiente para transmissão de dados, reduzindo significativamente os tamanhos das provas em comparação com formatos JSON ou binários brutos.
• Análise de Segurança: O modelo de adversário $w_a$ confirmou que um atacante com um orçamento de ~$20.000 USD (suficiente para produzir ~50 blocos de trabalho) não pode atacar com sucesso um verificador configurado com os parâmetros otimizados, mesmo que o atacante tente criar uma bifurcação com uma taxa de validade mais baixa.

5. Significado

Este artigo é um passo crítico para a industrialização do FlyClient.

• Pontes Sem Confiança: Ao reduzir drasticamente o custo de gás da verificação de blockchains estrangeiras em contratos inteligentes, a otimização de prova destilada torna as pontes entre cadeias sem confiança (sem terceiros federados ou confiáveis) economicamente viáveis.
• Viabilidade para IoT e Móveis: Os resultados confirmam que clientes leves podem verificar blockchains massivas com largura de banda e armazenamento mínimos, permitindo transações seguras entre máquinas em ambientes com recursos limitados.
• Segurança Prática: A transição de modelos matemáticos abstratos para modelos de orçamento econômico fornece um quadro mais realista para a segurança de sistemas blockchain no mundo real.
• Roteiro Futuro: Os autores sugerem que combinar FlyClient com SNARKs (Argumentos Succintos Não Interativos de Conhecimento) poderia comprimir ainda mais as provas, embora isso permaneça como trabalho futuro.

Em conclusão, o artigo demonstra que o FlyClient não é mais apenas um conceito teórico, mas uma solução implantável, segura e otimizada para a infraestrutura de blockchain de próxima geração.