Cliente ligeiro Ethereum Helios: acesso a dados na cadeia sem confiança

No dia 8 de novembro, uma conhecida instituição de capital de risco lançou o cliente ligeiro Helios para Ethereum. Este cliente, desenvolvido em linguagem Rust, tem como objetivo fornecer acesso ao Ethereum totalmente sem necessidade de confiança.

Uma das grandes vantagens da tecnologia blockchain é a ausência de necessidade de confiar em terceiros. Através da blockchain, os usuários podem controlar autonomamente sua riqueza e dados. Blockchains como Ethereum realmente cumpriram essa promessa na maioria dos casos: nossos ativos realmente pertencem a nós.

No entanto, para buscar conveniência, também fizemos alguns compromissos. Um deles é o uso de servidores RPC (chamada remota) centralizados. Os usuários geralmente acessam o Ethereum através de provedores centralizados. Essas empresas executam nós de alto desempenho em servidores na nuvem, ajudando os usuários a obter facilmente dados na cadeia. Quando uma carteira consulta o saldo de tokens ou verifica se uma transação pendente foi empacotada, quase sempre utiliza os serviços desses provedores centralizados.

O problema atual do sistema é que os usuários precisam confiar nesses provedores, sem poder verificar a precisão dos resultados das consultas.

Helios é um cliente ligeiro de Ethereum baseado em Rust, capaz de fornecer acesso ao Ethereum totalmente sem necessidade de confiança. Ele utiliza o protocolo de cliente ligeiro implementado após a transição do Ethereum para PoS, que pode converter dados de fornecedores de RPC centralizados não confiáveis em RPC local seguro e verificável. Combinando RPC centralizado, Helios pode verificar a autenticidade dos dados sem precisar executar um nó completo.

É um ponto de dor comum a dificuldade de equilibrar conveniência e descentralização. Este novo cliente (aberto ao público para desenvolvimento contínuo) pode completar a sincronização em cerca de dois segundos e não requer espaço de armazenamento, permitindo que os usuários acessem dados na cadeia de forma segura através de qualquer dispositivo (incluindo smartphones e extensões de navegador). Então, quais são os riscos potenciais de depender de infraestruturas centralizadas? Este artigo irá explorar detalhadamente esses riscos, apresentar o design do Helios e fornecer algumas sugestões para ajudar os desenvolvedores a contribuir para a base de código.

Riscos potenciais de infraestrutura centralizada: ameaças teóricas no ecossistema Ethereum

Dentro do ecossistema Ethereum, existe uma ameaça teórica que se esconde. Não está à procura de alvos na pool de memória de transações (Mempool), mas sim armando armadilhas ao imitar a infraestrutura centralizada da qual dependemos. Os usuários que caem nessa armadilha não fizeram nada de errado: eles simplesmente acessaram o DEX familiar como de costume, definiram um desvio razoável e realizaram transações de tokens... As suas operações não têm problema algum, mas podem enfrentar um novo tipo de ataque de sanduíche, que é uma armadilha cuidadosamente montada na entrada do ecossistema Ethereum - o provedor RPC.

Antes de entrar em detalhes, vamos primeiro ver como o DEX lida com as transações. Quando os usuários realizam a troca de tokens, eles fornecem alguns parâmetros para o contrato inteligente: o token a ser trocado, o valor da troca e, o mais crítico, a quantidade mínima de tokens que o usuário está disposto a aceitar. Este último parâmetro determina o "mínimo de saída" que a troca deve atingir, caso contrário, a transação será cancelada. Isso é normalmente conhecido como "slippage", pois efetivamente limita a variação de preço máxima que pode ocorrer entre o envio da transação para o pool de memórias e a inclusão no bloco. Se o slippage for definido muito baixo, o usuário pode acabar obtendo menos tokens. Essa situação também pode levar a ataques de sanduíche, onde um atacante pode colocar a transação do usuário entre duas transações maliciosas. Essas transações elevam o preço à vista, forçando o usuário a negociar a um preço desfavorável. Em seguida, o atacante venderá imediatamente os tokens, obtendo um pequeno lucro.

Desde que o parâmetro mínimo de saída esteja definido dentro de uma faixa razoável, os usuários não serão afetados por ataques de sanduíche. Mas e se o provedor RPC não fornecer a cotação exata do contrato inteligente DEX? Nessa situação, os usuários podem ser enganados a assinar transações de troca com parâmetros mínimos de saída baixos. Pior ainda, os usuários podem enviar a transação diretamente para um provedor RPC malicioso. O provedor pode optar por não transmitir essa transação para o pool de memória pública (onde há muitos bots competindo para realizar ataques de sanduíche), mas sim manter em privado e enviar o pacote de transações atacadas diretamente para uma plataforma específica, para lucrar com isso.

A raiz desse ataque está na confiança em outros para ajudar a obter o estado da blockchain. Para resolver esse problema, usuários experientes geralmente optam por executar seu próprio nó Ethereum. Isso requer um grande investimento de tempo e recursos, sendo necessário pelo menos um dispositivo constantemente online, centenas de GB de espaço de armazenamento, e cerca de um dia para sincronizar a partir do zero. Embora esse processo tenha sido simplificado em comparação com antes, algumas equipes têm trabalhado para ajudar os usuários a executar nós com hardware de baixo custo (como um Raspberry Pi com disco rígido externo). Mas mesmo com a exigência de uma redução significativa, para a maioria dos usuários, especialmente aqueles que usam dispositivos móveis, executar um nó ainda é uma tarefa árdua.

É importante notar que, embora os ataques de fornecedores de RPC centralizados sejam totalmente possíveis, atualmente são apenas um risco teórico e, na prática, ainda não ocorreram. Embora o histórico dos principais fornecedores seja confiável, ainda é aconselhável realizar uma pesquisa completa antes de adicionar fornecedores de RPC desconhecidos à carteira.

Introdução ao Helios: Acesso ao Ethereum totalmente sem confiança

O protocolo de cliente ligeiro lançado pelo Ethereum abriu possibilidades emocionantes para interações rápidas na cadeia e validação de pontos finais RPC com os requisitos mínimos de hardware. Um mês após a fusão, vários clientes ligeiros independentes surgiram um após o outro, adotando abordagens diferentes, mas todos com o mesmo objetivo: acesso eficiente sem necessidade de confiança e sem a necessidade de usar nós completos.

Helios é um cliente ligeiro de Ethereum, capaz de completar a sincronização em cerca de dois segundos, sem necessidade de espaço de armazenamento, e fornece acesso ao Ethereum totalmente sem confiança. Como todos os clientes de Ethereum, o Helios é composto por uma camada de execução e uma camada de consenso. Mas, ao contrário da maioria dos outros clientes, o Helios combina essas duas camadas de forma estreita, permitindo que os usuários instalem e executem um único software.

O seu funcionamento é o seguinte: a camada de consenso Helios utiliza um hash de bloco da cadeia de sinalização conhecido e conecta-se a um RPC não confiável, para sincronizar de forma verificável com o bloco atual. A camada de execução Helios combina esses blocos da cadeia de sinalização verificados com RPC de execução não confiáveis, para validar várias informações sobre o estado na cadeia, como saldos de contas, armazenamento de contratos, recibos de transações e resultados de chamadas de contratos inteligentes. Esses componentes trabalham em conjunto, proporcionando aos usuários um RPC completamente sem necessidade de confiança, sem a necessidade de executar um nó completo.

camada de consenso

O cliente ligeiro da camada de consenso segue as normas do cliente ligeiro da cadeia de sinalização e utiliza o comitê de sincronização da cadeia de sinalização (introduzido no hard fork Altair antes da fusão). O comitê de sincronização é um subconjunto de 512 validadores selecionados aleatoriamente, com um ciclo de serviço de aproximadamente 27 horas.

Após os validadores entrarem no comitê de sincronização, eles assinarão todos os cabeçalhos de bloco da cadeia de beacon que virem. Se mais de dois terços dos membros do comitê assinarem um cabeçalho de bloco, então esse bloco é muito provável que esteja na cadeia de beacon conforme o padrão. Se o Helios entender a composição atual do comitê de sincronização, ele pode rastrear a cabeça da cadeia com alta certeza consultando assinaturas recentes do comitê de sincronização através de RPC não confiável.

Graças à agregação de assinaturas BLS, é possível validar o cabeçalho de um novo bloco com uma única consulta. Desde que a assinatura seja válida e mais de dois terços dos membros do comitê tenham assinado, é garantido que o bloco foi incluído na cadeia (claro que ele também pode ser reorganizado fora da cadeia, e o rastreamento da finalização do bloco pode fornecer uma garantia mais forte).

Mas falta claramente um elemento nesta estratégia: como encontrar o atual comitê de sincronização. Primeiro, é necessário obter uma raiz de confiança chamada ponto de verificação de subjetividade fraca. Este é apenas um hash de bloco antigo que pode garantir que foi incluído na cadeia em algum momento no passado. Existe uma interessante análise matemática sobre o tempo exato de existência do ponto de verificação: a análise do pior cenário mostra cerca de duas semanas, enquanto estimativas mais práticas indicam que pode durar vários meses.

Se o ponto de verificação for muito antigo, teoricamente existe um ataque que pode enganar os nós a seguir uma cadeia errada. Neste caso, obter um ponto de verificação de subjetividade fraca ultrapassa a capacidade do protocolo. A solução da Helios é fornecer um ponto de verificação inicial, codificado diretamente no repositório de código (fácil de ser sobrescrito), que irá armazenar localmente o hash do último bloco final, para ser usado como ponto de verificação durante a sincronização dos nós.

Através de operações de hash, os blocos da cadeia de beacon podem gerar facilmente um hash único de bloco de beacon. Assim, é possível consultar facilmente o bloco completo de beacon para os nós e, em seguida, provar a validade do conteúdo do bloco realizando operações de hash e comparando com hashes de blocos conhecidos. O Helios utiliza essa característica para obter e validar certos campos dentro dos blocos de pontos de verificação de subjetividade fraca, incluindo dois campos cruciais: o comitê de sincronização atual e o próximo comitê de sincronização. O mais importante é que o cliente ligeiro pode usar esse mecanismo para verificar rapidamente a história da cadeia de blocos.

Com o ponto de verificação de subjetividade fraca, podemos obter e verificar o comitê de sincronização atual e o próximo. Se o cabeçalho atual da cadeia e o ponto de verificação estiverem dentro do mesmo ciclo de comitê de sincronização, podemos começar imediatamente a usar o cabeçalho do comitê de sincronização assinado para validar novos blocos. Se o nosso ponto de verificação estiver atrasado em relação a vários comitês de sincronização, então podemos:

1. Utilize o próximo comitê de sincronização após o ponto de verificação para obter e verificar um bloco que irá gerar um comitê de sincronização no futuro.

2. Utilize este novo bloco para obter o próximo comitê de sincronização.

3. Se o ponto de verificação ainda estiver atrás, volte ao passo 1.

Através deste processo, conseguimos verificar rapidamente a história da blockchain em unidades de 27 horas, começando a partir de qualquer hash de bloco passado e sincronizando até o hash de bloco atual.

camada de execução

O objetivo do cliente ligeiro da camada de execução é combinar o cabeçalho do bloco de beacon validado pela camada de consenso com o RPC da camada de execução não confiável, fornecendo dados da camada de execução verificados. Esses dados podem ser acessados através de um servidor RPC hospedado localmente pelo Helios.

Vamos usar o exemplo de obter o saldo da conta para introduzir de forma simples como o Ethereum armazena estados. Cada conta contém vários campos, como o hash do código do contrato, um número aleatório, o hash de armazenamento e o saldo. Essas contas são armazenadas em uma grande árvore Merkle-Patricia modificada, chamada árvore de estados. Assim que se conhece a raiz da árvore de estados, é possível verificar a prova Merkle para demonstrar se existe alguma conta na árvore. Esta prova não pode ser falsificada.

Helios obteve a raiz de estado verificada da camada de consenso. Ao aplicar esta raiz de estado e o pedido de prova Merkle ao RPC da camada de execução não confiável, Helios pode verificar localmente todos os dados armazenados na Ethereum.

Utilizamos diferentes tecnologias para validar os vários dados utilizados pela camada de execução. Desta forma, podemos validar todos os dados provenientes de RPCs não confiáveis. RPCs não confiáveis podem recusar-se a fornecer acesso aos dados, mas não podem fornecer resultados incorretos.

Usando Helios em ambientes complexos

É um problema comum ter dificuldade em equilibrar a conveniência e a descentralização. Com o Helios leve, os usuários podem acessar dados na cadeia de forma segura a partir de qualquer dispositivo (incluindo telemóveis e extensões de navegador). Isso permitirá que mais pessoas acessem os dados do Ethereum sem precisar confiar, sem limitações de hardware. Os usuários podem configurar o Helios como fornecedor RPC em algumas carteiras, permitindo o acesso a várias DApps sem confiança, todo o processo sem quaisquer outras alterações.

Além disso, o suporte do Rust para WebAssembly permite que os desenvolvedores de aplicações integrem facilmente o Helios em aplicações JavaScript (como carteiras e DApps). Essas integrações aumentarão a segurança do Ethereum e reduzirão nossa dependência de infraestrutura centralizada.

A reação da comunidade a isso é empolgante. Existem várias maneiras de contribuir para o Helios, além de adicionar ao repositório de código, também é possível construir software que integre o Helios para aproveitar suas vantagens. Aqui estão algumas ideias empolgantes:

• Suporta a obtenção de dados do cliente ligeiro diretamente da rede P2P (em vez de RPC)
• Implementar alguns métodos RPC ainda não suportados
• Desenvolver uma versão do Helios que possa ser compilada para WebAssembly
• Integrar o Helios diretamente no software de carteira
• Construir um painel de rede para ver o saldo de tokens, incorporando o Helios em sites que utilizam WebAssembly para obter dados.
• Implementar a API do motor, conectando a camada de consenso Helios ao nó completo da camada de execução existente.