Ir para o conteúdo
Financial Context Wiki

Clientes leves

Guia sensível a forks sobre bootstrap de clientes leves de consenso, comitês de sincronização, checkpoints de subjetividade fraca, cabeçalhos otimistas e finalizados, provas de estado de execução, provedores RPC, disponibilidade de dados e privacidade.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Um cliente leve é um software de verificação que acompanha uma blockchain com menos execução, estado e histórico locais do que um nó completo. Um nó leve é um dispositivo ou processo que executa esse software. Na Ethereum com prova de participação, um cliente leve de consenso parte de um checkpoint finalizado recente e confiável e verifica atualizações de comitês de sincronização com conhecimento dos forks para manter cabeçalhos otimistas e finalizados. Ele não reexecuta todas as transações da EVM.

Essa visão de consenso verificada é apenas a primeira âncora de confiança. Para verificar o valor de uma conta ou do armazenamento de um contrato, o cliente precisa vincular o cabeçalho beacon autenticado ao cabeçalho do payload de execução, selecionar seu stateRoot e verificar uma prova de conta ou armazenamento contra essa raiz. Uma resposta RPC comum sem a prova necessária continua sendo uma afirmação do provedor. Assinaturas de consenso não provam automaticamente o histórico de transações, recibos, traces, disponibilidade de dados, comportamento de aplicações nem recuperação de longo prazo.

Como funciona

  1. Fixe a rede e as raízes de confiança: identidade da cadeia, raiz e horário dos validadores de gênese, calendário de forks e presets, relógio atual, versão do cliente e um checkpoint de subjetividade fraca finalizado, recente e confiável. Confira o checkpoint em fontes autenticadas independentes; o consenso entre pares não corrige uma raiz inicial maliciosa.
  2. Obtenha um LightClientBootstrap para a raiz do bloco confiável. Verifique o cabeçalho de bootstrap, o comitê de sincronização atual e seu ramo de Merkle e, então, inicialize o LightClientStore. Rejeite cadeia, resumo de fork, índice generalizado ou esquema de serialização que não corresponda ao fork configurado.
  3. Processe objetos LightClientUpdate por período do comitê de sincronização. Antes de alternar os comitês, verifique slots, bits de participação, assinatura BLS agregada e domínio, ramos dos comitês atual e seguinte, ramo de finalidade e monotonicidade. Atualizações de fork podem alterar campos dos objetos e índices generalizados; as constantes de Altair não são valores universais permanentes.
  4. Mantenha políticas separadas para optimistic_header e finalized_header. Uma atualização otimista pode fornecer informação mais recente, mas com maior exposição a reorganização ou retenção; uma atualização finalizada possui status de consenso mais forte, porém pode estar defasada. A aplicação deve selecionar explicitamente o cabeçalho adequado, em vez de renomear a resposta mais recente como final.
  5. Ancore os dados de execução. Verifique o cabeçalho do payload de execução e o ramo contido no cabeçalho autenticado do cliente leve; depois vincule cada consulta de conta ou armazenamento ao stateRoot, ao hash do bloco e ao status de finalidade dessa execução. Na Ethereum, eth_getProof pode retornar uma prova de conta e as provas de armazenamento solicitadas; verifique localmente nós, caminhos, valores e inexistência.
  6. Inventarie toda superfície não verificada. Uma prova de saldo não autentica recibo de transação, consulta de logs, trace, simulação de chamada, mempool, rótulo de token, oráculo, blob, intervalo histórico nem a alegação do provedor de que nenhum resultado foi omitido. Para cada objeto necessário, defina uma prova, reconstrução independente, alternativa com nó completo ou premissa explícita de confiança.
  7. Opere fechando em caso de falha. Registre checkpoint, fork, raízes otimista e finalizada, bloco e raiz de estado de execução, nós da prova, provedor e horários. Imponha um limite de defasagem, diversifique provedores e rotas de rede, proteja a privacidade das consultas, teste a recuperação contra eclipse e indisponibilidade e use um nó completo ou outro sistema de verificação quando a superfície de provas do cliente leve for insuficiente.

Exemplos detalhados

  • Limite inteiro do comitê de sincronização. Para um comitê de 512 membros, o teste de supermaioria da especificação é participants * 3 >= 512 * 2. Com 341 participantes, 341 / 512 = 66.6015625% e 1,023 < 1,024; portanto, o teste falha. Com 342, 342 / 512 = 66.796875% e 1,026 >= 1,024; portanto, ele passa. Isso verifica a regra configurada para a atualização; não prova que todo membro do comitê ou toda implementação seja honesto.
  • Relógios dos cabeçalhos. Um checkpoint didático está no slot 10,000, um cabeçalho atestado está em 10,064 e seu cabeçalho finalizado está em 10,032. A 12 seconds/slot, o cabeçalho atestado fica 64 * 12 = 768 seconds = 12 minutes 48 seconds após o checkpoint, enquanto a finalidade fica 32 * 12 = 384 seconds = 6 minutes 24 seconds atrás do cabeçalho atestado. O tempo dos slots não garante entrega pela rede nem finalidade segundo um SLA fixo de relógio.
  • Ramo compacto, afirmação estreita. Em uma árvore balanceada ideal com 2^20 folhas, o ramo de uma única folha contém 20 hashes irmãos. A 32 bytes/hash, isso equivale a 640 bytes; comparado a um objeto de 8 MiB = 8,388,608 bytes, o ramo representa 0.00762939453125% do tamanho, uma redução de 99.99237060546875%. O ramo prova apenas a relação entre a folha e a raiz, não a disponibilidade dos demais bytes.
  • Prova versus RPC sem prova. Em um stateRoot de execução finalizado, uma prova de conta verificada retorna 3.25 ETH, enquanto uma resposta RPC sem prova informa 3.30 ETH. A diferença é 0.05 ETH, e a resposta sem prova é 0.05 / 3.30 = 1.5151515152% maior. Aceite o valor provado sob a raiz selecionada, mas não deduza dessa prova um saldo posterior, recibo, resultado histórico ou identidade do token.

Riscos

  • Configurar a cadeia, a raiz dos validadores de gênese, o horário de gênese ou o preset incorretos.
  • Inicializar a partir de um checkpoint malicioso, desatualizado ou não finalizado.
  • Usar uma única fonte não autenticada de checkpoint ou aceitar um fork de longo alcance.
  • Desvio do relógio local provocar decisões erradas sobre slots, períodos, domínios ou defasagem.
  • Executar calendário de forks, esquema de objetos ou índice generalizado obsoleto.
  • Não validar participação do comitê de sincronização, assinaturas BLS ou domínios.
  • Perder a rotação do comitê ou aceitar um comitê atual ou seguinte inválido.
  • Tratar o cabeçalho otimista como cabeçalho finalizado.
  • Vincular cabeçalho beacon, payload de execução ou hash de bloco de execução incorretos.
  • Verificar uma prova de conta ou armazenamento contra o stateRoot errado.
  • Aceitar nós de trie, caminhos, codificações ou provas de inexistência malformados.
  • Tratar como verificado um método RPC incompatível ou sem prova.
  • Receber respostas defasadas, censuradas, incompletas ou fabricadas pelo provedor.
  • Falha de eclipse, Sybil ou controle comum entre provedores aparentemente distintos.
  • Perder disponibilidade quando nós completos que fornecem provas podam dados ou param de servi-los.
  • Confundir validade de consenso com reexecução ou correção da aplicação.
  • Confundir uma prova válida com disponibilidade de dados ou recuperação permanente.
  • Não dispor de recibos, logs, traces, corpos ou histórico exigidos pela aplicação.
  • Falha de implementação, dependência, binário ou atualização de fork do cliente.
  • Vazamento de consultas, IP, contas e transações para provedores ou pares.

Equívocos comuns

  • Um cliente leve é apenas um nó completo menor ou um endpoint RPC remoto renomeado.
  • Um cabeçalho verificado pelo comitê de sincronização torna confiável toda resposta RPC.
  • O cabeçalho otimista mais recente equivale a um cabeçalho finalizado.
  • Uma prova de Merkle ou assinatura de consenso prova disponibilidade de dados e histórico completo.
  • Usar um cliente leve fornece automaticamente a privacidade, disponibilidade e resistência à censura de um nó completo.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...