cliente ligeiro Ethereum Helios: implementar acesso à blockchain sem necessidade de confiança
No dia 8 de novembro, um novo cliente ligeiro de Ethereum, Helios, foi oficialmente lançado. Este cliente foi desenvolvido em linguagem Rust e visa oferecer acesso ao Ethereum completamente sem necessidade de confiança.
Um dos principais objetivos da utilização da Blockchain é alcançar a confiança zero. Através da Blockchain, podemos controlar autonomamente a nossa riqueza e dados. Na maioria dos casos, blockchains como o Ethereum realmente cumprem essa promessa: os nossos ativos pertencem verdadeiramente a nós.
No entanto, para buscar conveniência, também fizemos alguns compromissos. Um deles é o uso de RPC( centralizado para chamadas remotas ao servidor ). Os usuários geralmente acessam Ethereum através de provedores centralizados. Essas empresas executam nós de alto desempenho em servidores em nuvem, ajudando todos a obter facilmente dados na blockchain. Quando a carteira consulta o saldo de tokens ou verifica o status de uma transação, quase sempre utiliza esses provedores centralizados.
O problema atual do sistema é que os usuários precisam confiar nesses provedores, não podendo verificar se os resultados das consultas estão corretos.
Helios é um cliente ligeiro de Ethereum baseado em Rust, que pode fornecer acesso ao Ethereum totalmente sem confiança. Ele utiliza o protocolo de cliente ligeiro implementado após a transição do Ethereum para PoS, permitindo converter dados de provedores de RPC centralizados não confiáveis em RPC local seguro e verificável. Combinando RPC centralizados, Helios pode verificar a autenticidade dos dados sem a necessidade de executar um nó completo.
Este cliente pode completar a sincronização em cerca de dois segundos e não requer armazenamento. Os usuários podem acessar dados na blockchain de forma segura através de qualquer dispositivo (, incluindo smartphones e extensões de navegador ). Mas quais são os riscos potenciais associados à dependência de infraestruturas centralizadas? A seguir, serão analisados esses riscos, apresentado o design do Helios e fornecidas algumas ideias para ajudar a aprimorar a biblioteca de código.
Riscos potenciais de infraestrutura centralizada
Uma forma teórica de ataque está latente na "floresta negra" do Ethereum. Não se trata de procurar alvos na memória de transações, mas sim de criar armadilhas imitando a infraestrutura centralizada da qual dependemos. Os usuários, mesmo sem cometer erros, podem cair na armadilha: eles apenas negociam no DEX como de costume, estabelecendo um deslizamento razoável... mas ainda podem ser alvo de um novo tipo de ataque sandwich, uma armadilha cuidadosamente configurada nos fornecedores de RPC.
Quando uma exchange descentralizada processa transações, os usuários precisam fornecer vários parâmetros ao contrato inteligente: o token a ser trocado, o valor da troca e, mais importante, a quantidade mínima de tokens que o usuário está disposto a aceitar. O último parâmetro indica o "resultado mínimo" que a troca deve alcançar; caso contrário, a transação será cancelada. Isso é frequentemente chamado de "slippage", que efetivamente define a maior diferença de preço que pode ocorrer entre o envio da transação e a inclusão da transação na blockchain. Se o slippage estiver definido muito baixo, o usuário pode acabar recebendo menos tokens e pode sofrer um ataque de sanduíche.
Desde que o parâmetro de produção mínima esteja definido dentro de uma faixa razoável, não será afetado por ataques de sanduíche. Mas e se o fornecedor de RPC não fornecer cotações precisas do contrato inteligente DEX? Isso pode levar os usuários a serem induzidos em erro, assinando transações de troca com parâmetros de produção mínima mais baixos. Pior ainda, os usuários podem também enviar transações diretamente para fornecedores de RPC maliciosos. O fornecedor pode não transmitir a transação para o pool de memória pública, mas reter secretamente e enviar diretamente o pacote de transações atacadas para instituições específicas em busca de lucro.
A causa fundamental deste tipo de ataque é confiar em outros para obter o estado da Blockchain. Para resolver este problema, utilizadores experientes costumam executar o seu próprio nó Ethereum, mas isso requer um grande investimento de tempo e recursos, incluindo pelo menos um dispositivo que esteja sempre online, várias centenas de GB de espaço de armazenamento e cerca de um dia para sincronizar a partir do zero. Embora o limiar para executar nós tenha diminuído, ainda é muito difícil para a maioria dos utilizadores, especialmente para aqueles que usam dispositivos móveis.
É importante notar que, embora ataques a provedores de RPC centralizados possam ocorrer, geralmente são apenas ataques de phishing simples, e o tipo de ataque que descrevemos ainda não aconteceu. Embora o histórico de provedores mainstream seja confiável, é sempre uma escolha sábia fazer alguma pesquisa antes de usar provedores de RPC desconhecidos.
Helios: Implementar acesso a Ethereum sem confiança
Ethereum lançou o protocolo cliente ligeiro, abrindo novas possibilidades para interações rápidas em Blockchain e validação de pontos finais RPC com a menor exigência de hardware. Um mês após The Merge, vários clientes ligeiros independentes foram lançados, adotando diferentes métodos, mas com um objetivo comum: alcançar um acesso eficiente e sem confiança sem a necessidade de executar nós completos.
Helios é um cliente ligeiro de Ethereum, que pode completar a sincronização em cerca de dois segundos, sem necessidade de armazenamento, e oferece acesso ao Ethereum totalmente sem confiança. Tal como todos os clientes de Ethereum, Helios inclui uma camada de execução e uma camada de consenso. Mas ao contrário da maioria dos clientes, Helios acopla as duas camadas de forma estreita, permitindo que o utilizador apenas instale e execute um único software.
O funcionamento do Helios é o seguinte: a camada de consenso utiliza um hash de bloco de uma cadeia de sinal conhecida e conecta-se a um RPC não confiável, para sincronizar de forma verificável até o bloco atual. A camada de execução combina estes blocos da cadeia de sinal verificados com um RPC de camada de execução não confiável, para validar várias informações sobre o estado on-chain, como saldo de contas, armazenamento de contratos, recibos de transações e resultados de chamadas de contratos inteligentes. Estes componentes trabalham em conjunto, fornecendo aos usuários um RPC totalmente 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. O comitê de sincronização é um subconjunto de 512 validadores selecionados aleatoriamente, com um ciclo de serviço de aproximadamente 27 horas.
Após a entrada dos validadores no comitê de sincronização, eles assinarão todos os cabeçalhos dos blocos da cadeia de sinalização que virem. Se mais de 2/3 dos membros do comitê assinarem um cabeçalho de bloco, é muito provável que esse bloco esteja localizado na cadeia de sinalização normativa. Se o Helios entender a composição atual do comitê de sincronização, ele pode rastrear de forma confiável a cabeça da cadeia consultando as assinaturas recentes do comitê de sincronização.
Graças à agregação de assinaturas BLS, basta uma única consulta para validar o cabeçalho de um novo bloco. Desde que a assinatura seja válida e mais de 2/3 dos membros do comitê tenham assinado, pode-se garantir que o bloco está incluído na cadeia. Claro, o rastreamento da finalidade do bloco pode oferecer uma garantia mais forte.
Nesta estratégia, também é necessário resolver a questão de como encontrar o atual comitê de sincronização. Primeiro, é preciso obter uma raiz de confiança chamada ponto de verificação de subjetividade fraca. Isso representa um hash de bloco antigo que pode ser garantido como tendo sido incluído na cadeia em um determinado momento no passado. Quanto ao tempo de existência do ponto de verificação, a análise teórica mostra que, no pior cenário, é de cerca de duas semanas, enquanto a estimativa real pode chegar a meses.
Se o ponto de verificação for muito antigo, teoricamente existe um ataque que pode induzir 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 do Helios é fornecer um ponto de verificação inicial, que é codificado diretamente no repositório de código ( pode ser facilmente sobreposto ), ele 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 da operação de hash, os blocos da cadeia de sinalização podem facilmente gerar um hash único de bloco de sinalização. Isso permite consultar facilmente o bloco de sinalização completo e, em seguida, provar a validade do conteúdo do bloco por meio de comparação de hash. Helios utiliza essa propriedade para obter e verificar campos-chave dentro dos blocos de pontos de verificação de subjetividade fraca, incluindo o atual comitê de sincronização e o próximo comitê de sincronização. O mais importante é que o cliente ligeiro pode utilizar esse mecanismo para revisar rapidamente a história do blockchain.
Com o ponto de verificação de fraca subjetividade, podemos obter e verificar o comitê de sincronização atual e o próximo. Se a cabeça da cadeia atual e o ponto de verificação estiverem dentro do mesmo ciclo de comitês de sincronização, podemos imediatamente usar o cabeçalho do comitê de sincronização assinado para validar o novo bloco. Se o ponto de verificação for posicionado após vários comitês de sincronização, então podemos:
Use o próximo comité de sincronização após o ponto de verificação para obter e validar um bloco do comité de sincronização que será gerado no futuro.
Use este novo bloco para obter o próximo comitê de sincronização.
Se o ponto de verificação ainda estiver atrás, retorne ao passo 1.
Através do processo acima, conseguimos rever rapidamente a história dessa blockchain em intervalos de 27 horas, começando a partir de qualquer hash de bloco do passado até sincronizar com 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 sinalização validado pela camada de consenso com RPCs da camada de execução não confiáveis, fornecendo dados da camada de execução verificados. Esses dados podem ser acessados através de servidores RPC hospedados localmente pelo Helios.
Segue um exemplo simples de como obter o saldo da conta, começando por uma breve introdução sobre como o Ethereum armazena o estado. Cada conta contém vários campos, como o hash do código do contrato, um número aleatório, o hash do armazenamento e o saldo. Essas contas são armazenadas em uma grande árvore Merkle-Patricia ajustada, chamada árvore de estado. Desde que se conheça a raiz da árvore de estado, é possível verificar a prova Merkle para provar se existe alguma conta na árvore. Esta prova não pode ser falsificada.
Helios obtém a raiz de estado verificada da camada de consenso. Através da aplicação deste estado raiz e do pedido de prova Merkle na camada de execução não confiável via RPC, Helios pode validar localmente todos os dados armazenados no Ethereum.
Utilizamos diferentes tecnologias para verificar os vários dados utilizados pela camada de execução, permitindo assim 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 errados.
Perspectivas de aplicação do Helios
Dificuldade em equilibrar conveniência e descentralização é uma dor comum. Através do cliente ligeiro Helios, os usuários podem acessar dados seguros em blockchain de qualquer dispositivo (, incluindo smartphones e extensões de navegador ). Isso permitirá que mais pessoas acessem dados do Ethereum sem necessidade de confiança, independentemente do hardware utilizado. Os usuários podem usar o Helios como provedor RPC em suas carteiras, permitindo o acesso a várias DApps sem a necessidade de qualquer outra alteração.
Além disso, o suporte do Rust ao 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 necessidade de confiar em infraestruturas centralizadas.
A comunidade pode contribuir para o Helios de várias maneiras, além de aprimorar o repositório de código, também pode construir software que integre o Helios para aproveitar suas vantagens. Aqui estão algumas direções de desenvolvimento potenciais:
Suporta a obtenção direta de dados do cliente ligeiro a partir da rede P2P, em vez de depender do RPC
Implementar os métodos RPC em falta
Desenvolver uma versão do Helios que possa ser compilada para WebAssembly
Integrar o Helios diretamente no software da carteira
Construir um painel de rede para ver o saldo de tokens, incorporar o Helios em sites que utilizam WebAssembly para obter dados.
Implantar a API do motor, conectando a camada de consenso Helios ao nó completo existente da camada de execução
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Helios cliente ligeiro: Implementação de acesso a dados na cadeia Ethereum totalmente sem confiança
cliente ligeiro Ethereum Helios: implementar acesso à blockchain sem necessidade de confiança
No dia 8 de novembro, um novo cliente ligeiro de Ethereum, Helios, foi oficialmente lançado. Este cliente foi desenvolvido em linguagem Rust e visa oferecer acesso ao Ethereum completamente sem necessidade de confiança.
Um dos principais objetivos da utilização da Blockchain é alcançar a confiança zero. Através da Blockchain, podemos controlar autonomamente a nossa riqueza e dados. Na maioria dos casos, blockchains como o Ethereum realmente cumprem essa promessa: os nossos ativos pertencem verdadeiramente a nós.
No entanto, para buscar conveniência, também fizemos alguns compromissos. Um deles é o uso de RPC( centralizado para chamadas remotas ao servidor ). Os usuários geralmente acessam Ethereum através de provedores centralizados. Essas empresas executam nós de alto desempenho em servidores em nuvem, ajudando todos a obter facilmente dados na blockchain. Quando a carteira consulta o saldo de tokens ou verifica o status de uma transação, quase sempre utiliza esses provedores centralizados.
O problema atual do sistema é que os usuários precisam confiar nesses provedores, não podendo verificar se os resultados das consultas estão corretos.
Helios é um cliente ligeiro de Ethereum baseado em Rust, que pode fornecer acesso ao Ethereum totalmente sem confiança. Ele utiliza o protocolo de cliente ligeiro implementado após a transição do Ethereum para PoS, permitindo converter dados de provedores de RPC centralizados não confiáveis em RPC local seguro e verificável. Combinando RPC centralizados, Helios pode verificar a autenticidade dos dados sem a necessidade de executar um nó completo.
Este cliente pode completar a sincronização em cerca de dois segundos e não requer armazenamento. Os usuários podem acessar dados na blockchain de forma segura através de qualquer dispositivo (, incluindo smartphones e extensões de navegador ). Mas quais são os riscos potenciais associados à dependência de infraestruturas centralizadas? A seguir, serão analisados esses riscos, apresentado o design do Helios e fornecidas algumas ideias para ajudar a aprimorar a biblioteca de código.
Riscos potenciais de infraestrutura centralizada
Uma forma teórica de ataque está latente na "floresta negra" do Ethereum. Não se trata de procurar alvos na memória de transações, mas sim de criar armadilhas imitando a infraestrutura centralizada da qual dependemos. Os usuários, mesmo sem cometer erros, podem cair na armadilha: eles apenas negociam no DEX como de costume, estabelecendo um deslizamento razoável... mas ainda podem ser alvo de um novo tipo de ataque sandwich, uma armadilha cuidadosamente configurada nos fornecedores de RPC.
Quando uma exchange descentralizada processa transações, os usuários precisam fornecer vários parâmetros ao contrato inteligente: o token a ser trocado, o valor da troca e, mais importante, a quantidade mínima de tokens que o usuário está disposto a aceitar. O último parâmetro indica o "resultado mínimo" que a troca deve alcançar; caso contrário, a transação será cancelada. Isso é frequentemente chamado de "slippage", que efetivamente define a maior diferença de preço que pode ocorrer entre o envio da transação e a inclusão da transação na blockchain. Se o slippage estiver definido muito baixo, o usuário pode acabar recebendo menos tokens e pode sofrer um ataque de sanduíche.
Desde que o parâmetro de produção mínima esteja definido dentro de uma faixa razoável, não será afetado por ataques de sanduíche. Mas e se o fornecedor de RPC não fornecer cotações precisas do contrato inteligente DEX? Isso pode levar os usuários a serem induzidos em erro, assinando transações de troca com parâmetros de produção mínima mais baixos. Pior ainda, os usuários podem também enviar transações diretamente para fornecedores de RPC maliciosos. O fornecedor pode não transmitir a transação para o pool de memória pública, mas reter secretamente e enviar diretamente o pacote de transações atacadas para instituições específicas em busca de lucro.
A causa fundamental deste tipo de ataque é confiar em outros para obter o estado da Blockchain. Para resolver este problema, utilizadores experientes costumam executar o seu próprio nó Ethereum, mas isso requer um grande investimento de tempo e recursos, incluindo pelo menos um dispositivo que esteja sempre online, várias centenas de GB de espaço de armazenamento e cerca de um dia para sincronizar a partir do zero. Embora o limiar para executar nós tenha diminuído, ainda é muito difícil para a maioria dos utilizadores, especialmente para aqueles que usam dispositivos móveis.
É importante notar que, embora ataques a provedores de RPC centralizados possam ocorrer, geralmente são apenas ataques de phishing simples, e o tipo de ataque que descrevemos ainda não aconteceu. Embora o histórico de provedores mainstream seja confiável, é sempre uma escolha sábia fazer alguma pesquisa antes de usar provedores de RPC desconhecidos.
Helios: Implementar acesso a Ethereum sem confiança
Ethereum lançou o protocolo cliente ligeiro, abrindo novas possibilidades para interações rápidas em Blockchain e validação de pontos finais RPC com a menor exigência de hardware. Um mês após The Merge, vários clientes ligeiros independentes foram lançados, adotando diferentes métodos, mas com um objetivo comum: alcançar um acesso eficiente e sem confiança sem a necessidade de executar nós completos.
Helios é um cliente ligeiro de Ethereum, que pode completar a sincronização em cerca de dois segundos, sem necessidade de armazenamento, e oferece acesso ao Ethereum totalmente sem confiança. Tal como todos os clientes de Ethereum, Helios inclui uma camada de execução e uma camada de consenso. Mas ao contrário da maioria dos clientes, Helios acopla as duas camadas de forma estreita, permitindo que o utilizador apenas instale e execute um único software.
O funcionamento do Helios é o seguinte: a camada de consenso utiliza um hash de bloco de uma cadeia de sinal conhecida e conecta-se a um RPC não confiável, para sincronizar de forma verificável até o bloco atual. A camada de execução combina estes blocos da cadeia de sinal verificados com um RPC de camada de execução não confiável, para validar várias informações sobre o estado on-chain, como saldo de contas, armazenamento de contratos, recibos de transações e resultados de chamadas de contratos inteligentes. Estes componentes trabalham em conjunto, fornecendo aos usuários um RPC totalmente 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. O comitê de sincronização é um subconjunto de 512 validadores selecionados aleatoriamente, com um ciclo de serviço de aproximadamente 27 horas.
Após a entrada dos validadores no comitê de sincronização, eles assinarão todos os cabeçalhos dos blocos da cadeia de sinalização que virem. Se mais de 2/3 dos membros do comitê assinarem um cabeçalho de bloco, é muito provável que esse bloco esteja localizado na cadeia de sinalização normativa. Se o Helios entender a composição atual do comitê de sincronização, ele pode rastrear de forma confiável a cabeça da cadeia consultando as assinaturas recentes do comitê de sincronização.
Graças à agregação de assinaturas BLS, basta uma única consulta para validar o cabeçalho de um novo bloco. Desde que a assinatura seja válida e mais de 2/3 dos membros do comitê tenham assinado, pode-se garantir que o bloco está incluído na cadeia. Claro, o rastreamento da finalidade do bloco pode oferecer uma garantia mais forte.
Nesta estratégia, também é necessário resolver a questão de como encontrar o atual comitê de sincronização. Primeiro, é preciso obter uma raiz de confiança chamada ponto de verificação de subjetividade fraca. Isso representa um hash de bloco antigo que pode ser garantido como tendo sido incluído na cadeia em um determinado momento no passado. Quanto ao tempo de existência do ponto de verificação, a análise teórica mostra que, no pior cenário, é de cerca de duas semanas, enquanto a estimativa real pode chegar a meses.
Se o ponto de verificação for muito antigo, teoricamente existe um ataque que pode induzir 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 do Helios é fornecer um ponto de verificação inicial, que é codificado diretamente no repositório de código ( pode ser facilmente sobreposto ), ele 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 da operação de hash, os blocos da cadeia de sinalização podem facilmente gerar um hash único de bloco de sinalização. Isso permite consultar facilmente o bloco de sinalização completo e, em seguida, provar a validade do conteúdo do bloco por meio de comparação de hash. Helios utiliza essa propriedade para obter e verificar campos-chave dentro dos blocos de pontos de verificação de subjetividade fraca, incluindo o atual comitê de sincronização e o próximo comitê de sincronização. O mais importante é que o cliente ligeiro pode utilizar esse mecanismo para revisar rapidamente a história do blockchain.
Com o ponto de verificação de fraca subjetividade, podemos obter e verificar o comitê de sincronização atual e o próximo. Se a cabeça da cadeia atual e o ponto de verificação estiverem dentro do mesmo ciclo de comitês de sincronização, podemos imediatamente usar o cabeçalho do comitê de sincronização assinado para validar o novo bloco. Se o ponto de verificação for posicionado após vários comitês de sincronização, então podemos:
Use o próximo comité de sincronização após o ponto de verificação para obter e validar um bloco do comité de sincronização que será gerado no futuro.
Use este novo bloco para obter o próximo comitê de sincronização.
Se o ponto de verificação ainda estiver atrás, retorne ao passo 1.
Através do processo acima, conseguimos rever rapidamente a história dessa blockchain em intervalos de 27 horas, começando a partir de qualquer hash de bloco do passado até sincronizar com 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 sinalização validado pela camada de consenso com RPCs da camada de execução não confiáveis, fornecendo dados da camada de execução verificados. Esses dados podem ser acessados através de servidores RPC hospedados localmente pelo Helios.
Segue um exemplo simples de como obter o saldo da conta, começando por uma breve introdução sobre como o Ethereum armazena o estado. Cada conta contém vários campos, como o hash do código do contrato, um número aleatório, o hash do armazenamento e o saldo. Essas contas são armazenadas em uma grande árvore Merkle-Patricia ajustada, chamada árvore de estado. Desde que se conheça a raiz da árvore de estado, é possível verificar a prova Merkle para provar se existe alguma conta na árvore. Esta prova não pode ser falsificada.
Helios obtém a raiz de estado verificada da camada de consenso. Através da aplicação deste estado raiz e do pedido de prova Merkle na camada de execução não confiável via RPC, Helios pode validar localmente todos os dados armazenados no Ethereum.
Utilizamos diferentes tecnologias para verificar os vários dados utilizados pela camada de execução, permitindo assim 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 errados.
Perspectivas de aplicação do Helios
Dificuldade em equilibrar conveniência e descentralização é uma dor comum. Através do cliente ligeiro Helios, os usuários podem acessar dados seguros em blockchain de qualquer dispositivo (, incluindo smartphones e extensões de navegador ). Isso permitirá que mais pessoas acessem dados do Ethereum sem necessidade de confiança, independentemente do hardware utilizado. Os usuários podem usar o Helios como provedor RPC em suas carteiras, permitindo o acesso a várias DApps sem a necessidade de qualquer outra alteração.
Além disso, o suporte do Rust ao 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 necessidade de confiar em infraestruturas centralizadas.
A comunidade pode contribuir para o Helios de várias maneiras, além de aprimorar o repositório de código, também pode construir software que integre o Helios para aproveitar suas vantagens. Aqui estão algumas direções de desenvolvimento potenciais: