Construindo Helios: Acesso totalmente confiável ao Ethereum

Uma das principais razões pelas quais usamos blockchains é a falta de confiança. Esta propriedade promete permitir-nos acesso auto-soberano à nossa riqueza e dados. Na maior parte, blockchains como o Ethereum cumpriram essa promessa – nossos ativos são verdadeiramente nossos. 

No entanto, há concessões que fizemos por uma questão de conveniência. Uma dessas áreas é o uso de servidores RPC (chamada de procedimento remoto) centralizados. Os usuários normalmente acessam o Ethereum por meio de provedores centralizados como o Alchemy. Essas empresas executam nós de alto desempenho em servidores em nuvem para que outras pessoas possam acessar facilmente os dados da cadeia. Quando uma carteira consulta seus saldos de tokens ou verifica se uma transação pendente foi incluída em um bloco, quase sempre o faz por meio de um desses provedores centralizados. 

O problema com o sistema existente é que os usuários precisam confiar nos provedores e não há como verificar a exatidão de suas consultas.

Entrar Helios, um cliente leve Ethereum baseado em Rust que desenvolvemos e que fornece acesso totalmente confiável ao Ethereum. Helios — que usa o protocolo light client da Ethereum, possibilitado pelo mudança recente para prova de participação — converte dados de um provedor de RPC centralizado não confiável em um RPC local comprovadamente seguro. O Helios trabalha em conjunto com RPCs centralizados para possibilitar a verificação de sua autenticidade sem executar um nó completo. 

A compensação entre portabilidade e descentralização é um problema comum, mas nosso cliente – que disponibilizamos ao público para desenvolvimento e muito mais – sincroniza em cerca de dois segundos, não requer armazenamento e permite que os usuários acessem dados de cadeia segura de qualquer dispositivo (incluindo telefones celulares e extensões de navegador). Mas o que são as possíveis armadilhas de depender de uma infraestrutura centralizada? Abordamos como eles podem funcionar nesta postagem, analisamos nossas decisões de design e também delineamos algumas ideias para que outras pessoas possam contribuir para o codebase.

As armadilhas da infraestrutura centralizada: criaturas teóricas na “floresta escura” de Ethereum

Uma criatura (teórica) se esconde no floresta Negra. Este não caça suas presas no mempool Ethereum, mas em vez disso arma suas armadilhas imitando a infraestrutura centralizada na qual confiamos. Os usuários que caem nessa armadilha não cometem erros: eles visitam sua bolsa descentralizada favorita, estabelecem uma tolerância razoável ao slippage e compram e vendem tokens como de costume... Eles fazem tudo certo, mas ainda assim são vítimas de um novo tipo de ataque sanduíche, uma armadilha meticulosamente montada bem na entrada da floresta escura de Ethereum: provedores de RPC.

Antes de elaborarmos, vamos ver como funcionam as negociações em bolsas descentralizadas. Quando os usuários enviam uma transação de swap, eles fornecem vários parâmetros ao contrato inteligente – quais tokens trocar, o valor da troca e, o mais importante, o número mínimo de tokens que um usuário deve receber para que a transação seja realizada. Este último parâmetro especifica que a troca deve satisfazer uma “saída mínima” ou reverter. Isso geralmente é conhecido como “tolerância ao slippage”, pois define efetivamente a alteração máxima de preço que pode ocorrer entre o momento em que a transação é enviada para o mempool e o momento em que é incluída em um bloco. Se este parâmetro for definido muito baixo, o usuário aceita a possibilidade de receber menos tokens. Esta situação também pode levar a um ataque sanduíche, onde um invasor efetivamente coloca a oferta entre duas trocas maliciosas. Os swaps aumentam o preço à vista e forçam a negociação do usuário a ser executada a um preço menos favorável. O invasor então vende imediatamente para obter um pequeno lucro.

Contanto que esse parâmetro de saída mínimo seja definido próximo ao valor justo, você estará protegido contra ataques sanduíche. Mas e se o seu provedor de RPC não fornecer uma cotação de preço precisa do contrato inteligente de troca descentralizada? Um usuário pode então ser induzido a assinar uma transação de swap com um parâmetro de saída mínimo mais baixo e, para piorar a situação, enviar a transação diretamente para o provedor RPC malicioso. Em vez de transmitir esta transação para o mempool público, onde dezenas de bots competem para realizar o ataque sanduíche, o provedor pode retê-la e enviar o pacote de transações de ataque diretamente para Flashbots, garantindo os lucros para si.

A causa raiz deste ataque é confiar em outra pessoa para obter o estado do blockchain. Usuários experientes tradicionalmente resolvem esse problema executando seus próprios nós Ethereum – um empreendimento que consome muito tempo e recursos e que, no mínimo, requer uma máquina constantemente on-line, centenas de gigabytes de armazenamento e cerca de um dia para sincronizar do zero. Este processo é certamente mais fácil do que costumava ser; grupos como Ethereum em ARM trabalharam incansavelmente para tornar possível a execução de nós em hardware de baixo custo (como um Raspberry Pi com um disco rígido externo conectado a ele). Mas mesmo com esses requisitos relativamente mínimos, executar um nó ainda é difícil para a maioria dos usuários, especialmente para aqueles que utilizam dispositivos móveis.

É importante observar que os ataques centralizados a provedores de RPC, embora totalmente plausíveis, geralmente são ataques de phishing simples – e o que descrevemos ainda não aconteceu. Mesmo que o histórico de provedores maiores como a Alchemy nos dê poucos motivos para duvidar deles, vale a pena fazer mais pesquisas antes de adicionar provedores de RPC desconhecidos à sua carteira.

Apresentando Helios: acesso totalmente confiável ao Ethereum

Ao introduzir seu protocolo de cliente leve (tornado possível pela recente mudança para Proof of Stake), Ethereum abriu novas possibilidades interessantes para interagir rapidamente com o blockchain e verificar endpoints RPC com requisitos mínimos de hardware. No mês desde A fusão, vimos uma nova safra de clientes leves emergir independentemente uns dos outros (Lodestar, nimboe o baseado em JavaScript Kevlar) que adotaram abordagens diferentes a serviço do mesmo objetivo: acesso eficiente e sem confiança, sem utilizar um nó completo.

Nossa solução, Helios, é um cliente Ethereum light que sincroniza em cerca de dois segundos, não requer armazenamento e fornece acesso totalmente confiável ao Ethereum. Como todos os clientes Ethereum, o Helios consiste em uma camada de execução e uma camada de consenso. Ao contrário da maioria dos outros clientes, o Helios une ambas as camadas de forma que os usuários só precisem instalar e executar um único software. (Erígon está se movendo nessa direção também, adicionando um cliente leve da camada de consenso construído diretamente em seu nó de arquivo). 

Então, como isso funciona? A camada de consenso do Helios usa um blockhash de cadeia de beacon previamente conhecido e uma conexão com um RPC não confiável para sincronizar de forma verificável com o bloco atual. A camada de execução Helios usa esses blocos de cadeia de beacon autenticados em conjunto com um RPC da camada de execução não confiável para provar informações arbitrárias sobre o estado da cadeia, como saldos de contas, armazenamento de contratos, recebimentos de transações e resultados de chamadas de contratos inteligentes. Esses componentes trabalham juntos para oferecer aos usuários um RPC totalmente confiável, sem a necessidade de executar um nó completo.

…Na camada de consenso

O cliente leve da camada de consenso está em conformidade com o cliente leve da cadeia de beacon especificação, e faz uso dos comitês de sincronização da cadeia de beacon (introduzidos antes do Merge no hard fork Altair). O comitê de sincronização é um subconjunto selecionado aleatoriamente de 512 validadores que atendem por períodos de aproximadamente 27 horas. 

Quando um validador está em um comitê de sincronização, ele assina todos os cabeçalhos de bloco da cadeia de beacon que vê. Se mais de dois terços do comitê assinar um determinado cabeçalho de bloco, é altamente provável que esse bloco esteja na cadeia de beacon canônica. Se o Helios souber a composição do comitê de sincronização atual, ele poderá rastrear com segurança o chefe da cadeia, solicitando a um RPC não confiável a assinatura mais recente do comitê de sincronização. 

Obrigado ao BLS assinatura agregação, apenas uma única verificação é necessária para validar o novo cabeçalho. Se a assinatura for válida e tiver sido assinada por mais de dois terços do comitê, é seguro assumir que o bloco foi incluído na cadeia (é claro que pode ser reorganizado fora da cadeia, mas a finalidade do bloco de rastreamento pode fornecer garantias mais rigorosas).

Porém, há uma peça óbvia que falta nesta estratégia: como encontrar o comitê de sincronização atual. Isso começa com a aquisição de uma raiz de confiança chamada ponto de verificação de subjetividade fraco. Não se deixe intimidar pelo nome – significa apenas um blockhash antigo que podemos garantir que foi incluído na cadeia em algum momento no passado. Há uma matemática interessante por trás da idade exata do ponto de verificação; a análise do pior caso sugere cerca de duas semanas, enquanto estimativas mais práticas sugerem muitos meses. 

Se o ponto de verificação for muito antigo, há ataques teóricos que pode enganar os nós para que sigam a cadeia errada. Adquirir um ponto de verificação de subjetividade fraco está fora do padrão do protocolo. Nossa abordagem com Helios fornece um ponto de verificação inicial codificado na base de código (que pode ser facilmente substituído); em seguida, ele salva o blockhash finalizado mais recente localmente para usar como ponto de verificação no futuro, sempre que o nó for sincronizado. 

Convenientemente, os blocos da cadeia de beacon podem ser hash para produzir um blockhash de beacon exclusivo. Isso significa que é fácil solicitar a um nó um bloco de beacon completo e, em seguida, provar que o conteúdo do bloco é válido fazendo hash e comparando com um blockhash conhecido. Helios usa essa propriedade para buscar e provar certos campos dentro do bloco de ponto de verificação de subjetividade fraca, incluindo dois campos muito importantes: o comitê de sincronização atual e o próximo comitê de sincronização. Criticamente, esse mecanismo permite que os clientes leves avancem rapidamente no histórico do blockchain.

Agora que temos um ponto de verificação de subjetividade fraco, podemos buscar e verificar os comitês de sincronização atuais e os próximos. Se o chefe da cadeia atual estiver dentro do mesmo período do comitê de sincronização que o ponto de verificação, começaremos imediatamente a verificar novos blocos com os cabeçalhos do comitê de sincronização assinados. Se nosso ponto de verificação estiver com vários comitês de sincronização atrás, podemos:

1. Use o próximo comitê de sincronização após nosso ponto de verificação para buscar e verificar um bloco que origina um comitê de sincronização no futuro.
2. Use este novo bloco para buscar o próximo comitê de sincronização.
3. Se ainda estiver atrasado, retorne ao passo 1.

Cada iteração desse processo nos permite avançar 27 horas do histórico da cadeia, começar com qualquer blockhash do passado e sincronizar com o blockhash atual.

…Na camada de execução

O objetivo do cliente leve da camada de execução é pegar cabeçalhos de bloco de beacon que são verificados pela camada de consenso e usá-los junto com um RPC da camada de execução não confiável para fornecer dados verificados da camada de execução. Esses dados podem então ser acessados ​​por meio de um servidor RPC hospedado localmente pela Helios.

Aqui está um exemplo simples de como obter o saldo de uma conta, começando com uma introdução rápida sobre como o estado é armazenado no Ethereum. Cada conta contém alguns campos, como hash do código do contrato, nonce, hash de armazenamento e saldo. Essas contas são armazenadas em um grande e modificado Árvore Merkle-Patrícia chamada de árvore de estado. Se conhecermos a raiz da árvore de estados, podemos validar provas merkle para provar a existência (ou exclusão) de qualquer conta dentro da árvore. Estas provas são efetivamente impossíveis de falsificar.

Helios possui uma raiz de estado autenticada na camada de consenso. Usando esta raiz e solicitações de prova de merkle para o RPC da camada de execução não confiável, o Helios pode verificar localmente todos os dados armazenados no Ethereum.

Aplicamos diferentes técnicas para verificar todos os tipos de dados utilizados pela camada de execução; usados ​​juntos, eles nos permitem autenticar todos os dados recuperados do RPC não confiável. Embora um RPC não confiável possa negar acesso aos dados, ele não pode mais nos fornecer resultados incorretos.

Usando Helios na natureza

A compensação entre portabilidade e descentralização é um problema comum – mas como o Helios é tão leve, os usuários podem acessar dados de cadeia segura a partir de qualquer dispositivo (incluindo telefones celulares e extensões de navegador). A capacidade de executar o Helios em qualquer lugar possibilita que mais pessoas acessem dados Ethereum confiáveis, independentemente do hardware. Isso significa que os usuários podem usar o Helios como seu provedor de RPC no MetaMask e acessar dapps sem nenhuma outra alteração. 

Além disso, o suporte do Rust para WebAssembly torna possível aos desenvolvedores de aplicativos incorporar facilmente o Helios em aplicativos Javascript (como carteiras e dapps). Essas integrações tornariam o Ethereum mais seguro e reduziriam nossa necessidade de confiar na infraestrutura centralizada.

Mal podemos esperar para ver o que a comunidade vai apresentar. Mas, enquanto isso, há muitas maneiras de contribuir com o Helios — se não estiver interessado em contribuir com a base de código, você também pode criar software que integre o Helios para aproveitar seus benefícios. Estas são apenas algumas das ideias que nos entusiasmam:

• Suporte à busca de dados leves do cliente diretamente da rede P2P, em vez de via RPC
• Implemente alguns dos métodos RPC ausentes
• Crie uma versão do Helios que compile para WebAssembly
• Integre Helios diretamente ao software de carteira
• Crie um painel da web para visualizar seus saldos de tokens que buscam dados do Helios incorporados ao site com WebAssembly
• Implementar a API do mecanismo para que a camada de consenso do Helios possa ser conectada a um nó completo da camada de execução existente

Confira a base de código para começar - agradecemos seus relatórios de bugs, solicitações de recursos e código. E se você construir algo mais, compartilhe conosco no Twitter, Telegram, ou Farcaster @a16zcrypto.

***
As opiniões expressas aqui são as do pessoal individual da AH Capital Management, LLC (“a16z”) citadas e não são as opiniões da a16z ou de suas afiliadas. Certas informações aqui contidas foram obtidas de fontes de terceiros, inclusive de empresas do portfólio de fundos administrados pela a16z. Embora retiradas de fontes consideradas confiáveis, a16z não verificou essas informações de forma independente e não faz representações sobre a precisão atual ou duradoura das informações ou sua adequação a uma determinada situação. Além disso, esse conteúdo pode incluir anúncios de terceiros; a16z não revisou tais anúncios e não endossa nenhum conteúdo de publicidade neles contido.

Este conteúdo é fornecido apenas para fins informativos e não deve ser considerado como aconselhamento jurídico, comercial, de investimento ou fiscal. Você deve consultar seus próprios conselheiros sobre esses assuntos. As referências a quaisquer valores mobiliários ou ativos digitais são apenas para fins ilustrativos e não constituem uma recomendação de investimento ou oferta para fornecer serviços de consultoria de investimento. Além disso, este conteúdo não é direcionado nem destinado ao uso por quaisquer investidores ou potenciais investidores, e não pode, em nenhuma circunstância, ser invocado ao tomar uma decisão de investir em qualquer fundo administrado pela a16z. (Uma oferta para investir em um fundo a16z será feita apenas pelo memorando de colocação privada, contrato de subscrição e outra documentação relevante de tal fundo e deve ser lida na íntegra.) Quaisquer investimentos ou empresas de portfólio mencionados, referidos ou descritos não são representativos de todos os investimentos em veículos administrados pela a16z, e não pode haver garantia de que os investimentos serão rentáveis ​​ou que outros investimentos realizados no futuro terão características ou resultados semelhantes. Uma lista de investimentos feitos por fundos administrados por Andreessen Horowitz (excluindo investimentos para os quais o emissor não deu permissão para a a16z divulgar publicamente, bem como investimentos não anunciados em ativos digitais negociados publicamente) está disponível em https://a16z.com/investments /.

Os gráficos e gráficos fornecidos são apenas para fins informativos e não devem ser considerados ao tomar qualquer decisão de investimento. O desempenho passado não é indicativo de resultados futuros. O conteúdo fala apenas a partir da data indicada. Quaisquer projeções, estimativas, previsões, metas, perspectivas e/ou opiniões expressas nestes materiais estão sujeitas a alterações sem aviso prévio e podem diferir ou ser contrárias às opiniões expressas por outros. Consulte https://a16z.com/disclosures para obter informações adicionais importantes