cliente ligeiro Ethereum Helios: implementar acesso ao Blockchain sem confiança
No dia 8 de novembro, um novo cliente ligeiro Ethereum, Helios, foi lançado. Este cliente, desenvolvido em linguagem Rust, visa proporcionar um acesso totalmente sem confiança ao Ethereum.
Uma das principais razões pelas quais usamos Blockchain é a falta de necessidade de confiança. Através do Blockchain, podemos controlar autonomamente a nossa riqueza e dados. Na maioria dos casos, blockchains como Ethereum realmente cumpriram esta promessa: os nossos ativos pertencem verdadeiramente a nós.
No entanto, para buscar conveniência, também fizemos algumas concessões. Uma delas é o uso de chamadas remotas RPC( centralizadas. Os usuários geralmente acessam Ethereum através de provedores centralizados. Essas empresas executam nós de alto desempenho em servidores em nuvem, ajudando os usuários a acessar facilmente os dados na cadeia. Quando a carteira consulta o saldo de tokens ou verifica se as transações pendentes foram incluídas em um bloco, quase sempre utiliza esses provedores centralizados.
O problema atual do sistema é que os usuários precisam confiar nesses fornecedores, sem poder verificar se os resultados da consulta 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 o PoS, podendo 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 a necessidade de executar um nó completo.
Dificuldade em conciliar conveniência e descentralização é um ponto comum de dor, este novo cliente pode completar a sincronização em cerca de dois segundos, e não requer armazenamento, os usuários podem acessar dados seguros na blockchain através de qualquer dispositivo ), incluindo smartphones e extensões de navegador (. Mas quais são os potenciais riscos de depender de infraestruturas centralizadas? Este artigo irá explorar esses riscos, apresentar o design do Helios, e fornecer algumas ideias para ajudar os desenvolvedores a contribuir para o repositório de código.
Riscos de Infraestrutura Centralizada: Produtos Teóricos na "Floresta Escura" do Ethereum
Um produto teórico está escondido na floresta negra. Ele não está à procura de presas no pool de memória de transações do Ethereum, mas cria armadilhas simulando a infraestrutura centralizada de que dependemos. Os usuários que caem nessa armadilha não cometeram nenhum erro: eles apenas acessaram a exchange descentralizada que costumam usar, definiram um deslizamento razoável e compraram e venderam tokens como de costume... eles não fizeram nada de errado, mas ainda assim enfrentaram um novo tipo de ataque sanduíche, uma armadilha cuidadosamente montada na entrada da floresta negra do Ethereum — o provedor RPC.
Antes de detalhar, vamos primeiro observar como as exchanges descentralizadas lidam com as transações. Quando os usuários executam uma troca, eles fornecem 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 deve receber para prosseguir com a transação. O último parâmetro indica a "saída mínima" que a troca deve alcançar, caso contrário, a transação será cancelada. Isso é geralmente chamado de "slippage", pois efetivamente estabelece a diferença máxima de preço que pode ocorrer entre o envio da transação para o pool de memórias e a inclusão da transação no bloco. Se o slippage estiver configurado muito baixo, o usuário pode acabar recebendo menos tokens. Essa situação também pode levar a um ataque de sanduíche, onde o atacante pode colocar a oferta do usuário entre duas transações maliciosas. Essas transações irão aumentar 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 este parâmetro de produção mínima esteja definido perto do valor justo, você não será afetado por ataques de sanduíche. Mas e se o seu provedor de RPC não fornecer cotações precisas para contratos inteligentes de intercâmbio descentralizados? Nesse caso, os usuários podem ser enganados e assinar transações de troca com parâmetros de produção mínima mais baixos. Pior ainda, os usuários podem enviar transações diretamente para provedores de RPC maliciosos. O provedor pode não divulgar essa transação para o pool de memórias públicas ), onde dezenas de robôs competem para realizar ataques de sanduíche (, mas reter privadamente e enviar o pacote de transações atacadas diretamente para alguma plataforma MEV para lucrar com isso.
A causa fundamental deste ataque é confiar nos outros para ajudá-lo a obter o estado do blockchain. Para resolver este problema, os usuários experientes geralmente executam seus próprios nós Ethereum, e este trabalho exige um grande investimento de tempo e recursos, necessitando de pelo menos um dispositivo sempre online, centenas de GB de espaço de armazenamento, e cerca de um dia para sincronizar do zero. Este processo é claramente mais simplificado do que no passado. Alguns grupos têm trabalhado incansavelmente para ajudar todos a executarem nós através de hardware de baixo custo, como por exemplo, um microcomputador Raspberry Pi com um disco rígido externo ). Mas mesmo com exigências significativamente reduzidas, executar um nó ainda é muito difícil para a maioria dos usuários, especialmente para aqueles que utilizam dispositivos móveis.
É importante notar que, embora ataques de fornecedores de RPC centralizados possam ocorrer, geralmente se tratam apenas de ataques de phishing simples, o tipo de ataque que mencionamos ainda não aconteceu. Embora o histórico passado de grandes fornecedores não nos dê razões para duvidar deles, vale a pena fazer mais pesquisas antes de adicionar fornecedores de RPC desconhecidos à carteira.
Introdução ao Helios: Acesso ao Ethereum totalmente sem confiança
O Ethereum lançou um protocolo de cliente ligeiro, abrindo possibilidades empolgantes para interações rápidas com a blockchain e validação de pontos finais RPC com os menores requisitos de hardware. Um mês após The Merge, uma série de clientes ligeiros independentes surgiu, cada um seguindo seu próprio caminho, mas todos com o mesmo objetivo: acesso eficiente sem necessidade de confiança, sem ter que usar 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 a Ethereum totalmente sem confiança. Tal como todos os clientes de Ethereum, Helios é composto por uma camada de execução e uma camada de consenso. Mas, ao contrário da maioria dos outros clientes, Helios combina estas duas camadas de forma estreita, permitindo que os utilizadores apenas instalem e executem um único software.
Como funciona? A camada de consenso Helios utiliza um hash de bloco de uma cadeia de sinalização conhecida 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 de cadeia de sinalização verificados com RPC de camada de execução não confiáveis, para verificar várias informações sobre o estado na cadeia, como saldos de conta, armazenamento de contratos, recibos de transações e resultados de chamadas de contratos inteligentes. Esses componentes trabalham juntos para fornecer aos usuários um RPC totalmente sem confiança, sem necessidade de executar um nó completo.
( camada de consenso
O cliente ligeiro da camada de consenso cumpre as normas do cliente ligeiro da Beacon Chain e utiliza o Comitê de Sincronização da Beacon Chain ), que foi lançado antes do Merge do hard fork Altair ###. O Comitê de Sincronização é um subconjunto de 512 validadores selecionados aleatoriamente, com um ciclo de serviço de cerca de 27 horas.
Depois que os validadores entram no comitê de sincronização, eles assinarão todos os cabeçalhos de bloco da cadeia de sinalização que veem (block header). Se mais de dois terços dos membros do comitê assinam um cabeçalho de bloco, é muito provável que esse bloco esteja na cadeia de sinalizaçã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 confiança consultando assinaturas do comitê de sincronização recente por meio 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, pode-se garantir que o bloco foi incluído na cadeia (. Claro, ele também pode ser reorganizado para fora da cadeia, e o rastreamento da finalização do bloco pode fornecer garantias mais fortes ).
Mas este estratégia claramente falta um elemento: 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 (weak subjectivity checkpoint). Não se deixe assustar pelo nome, ele simplesmente indica um hash de bloco antigo que pode garantir que foi incluído na cadeia em um determinado momento no passado. Quanto ao tempo exato de existência do ponto de verificação, há alguns cálculos matemáticos interessantes por trás: a análise do pior cenário mostra cerca de duas semanas, enquanto estimativas mais práticas indicam 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, que é codificado no repositório ( e facilmente substituído ), ele irá armazenar localmente o hash do bloco final mais recente, para ser usado como ponto de verificação quando os nós se sincronizarem.
Através da operação de hash, os blocos da cadeia de beacon podem facilmente gerar um hash único para o bloco da beacon. Desta forma, é possível consultar facilmente o bloco completo da beacon para os nós, e então, através da operação de hash e comparação com o hash de bloco conhecido, provar a validade do conteúdo do bloco. O Helios utiliza esta propriedade para obter e verificar certos campos dentro dos blocos de ponto 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 utilizar este mecanismo para revisar rapidamente a história da blockchain.
Agora que temos o ponto de verificação de fraca subjetividade, podemos obter e verificar o atual e o próximo comitê de sincronização. Se o cabeçalho da cadeia atual e o ponto de verificação estiverem dentro do mesmo ciclo do comitê de sincronização, podemos começar imediatamente a usar o cabeçalho do comitê de sincronização assinado para verificar novos blocos. Se o nosso ponto de verificação estiver depois de 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 validar um bloco que irá gerar um comité de sincronização 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 revisar rapidamente a história dessa Blockchain em intervalos de 27 horas, começando 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 beacon verificado 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 então ser acessados através de um servidor RPC hospedado localmente pelo Helios.
Aqui está um exemplo simples de como obter o saldo de uma conta. Primeiro, vamos apresentar brevemente 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 de 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 comprovar se existe alguma conta na árvore. Esta prova não pode ser falsificada.
Helios tem uma raiz de estado verificada )state root### da camada de consenso. Ao aplicar esta raiz de estado e o pedido de prova Merkle na camada de execução RPC não confiável, o Helios pode validar localmente todos os dados armazenados na Ethereum.
Utilizamos diferentes tecnologias para validar os diversos dados utilizados pela camada de execução, permitindo-nos verificar todos os dados provenientes de RPCs não confiáveis. Os RPCs não confiáveis podem recusar o acesso aos dados, mas nunca mais poderão fornecer resultados errados.
Usando o Helios no mundo real
É um ponto comum a dificuldade em equilibrar a conveniência e a descentralização. Com o Helios leve, os usuários podem acessar dados seguros na cadeia 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 seu provedor de RPC em uma carteira, para acessar várias DApps sem necessidade de 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 DApp ). Essas integrações aumentarão a segurança do Ethereum, reduzindo nossa necessidade de confiança em infraestrutura centralizada.
Existem várias maneiras de contribuir para o Helios, além de adicionar ao repositório de código; você também pode desenvolver software que integre o Helios para aproveitar suas vantagens. Aqui estão algumas ideias empolgantes:
Suporta obter dados de cliente ligeiro diretamente da rede P2P, em vez de RPC
Implantar alguns métodos RPC que estão em falta
Construir 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, integrar o Helios em sites que utilizam WebAssembly para obter dados
Implantar a API do motor, ligando 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.
23 Curtidas
Recompensa
23
4
Repostar
Compartilhar
Comentário
0/400
AirdropHarvester
· 07-23 19:58
rpc afinal quando é que pode ser Descentralização?
Ver originalResponder0
All-InQueen
· 07-20 22:35
Esta fechadura, definitivamente é uma boa escolha!
Helios cliente ligeiro: implementar acesso ao Ethereum sem necessidade de confiança
cliente ligeiro Ethereum Helios: implementar acesso ao Blockchain sem confiança
No dia 8 de novembro, um novo cliente ligeiro Ethereum, Helios, foi lançado. Este cliente, desenvolvido em linguagem Rust, visa proporcionar um acesso totalmente sem confiança ao Ethereum.
Uma das principais razões pelas quais usamos Blockchain é a falta de necessidade de confiança. Através do Blockchain, podemos controlar autonomamente a nossa riqueza e dados. Na maioria dos casos, blockchains como Ethereum realmente cumpriram esta promessa: os nossos ativos pertencem verdadeiramente a nós.
No entanto, para buscar conveniência, também fizemos algumas concessões. Uma delas é o uso de chamadas remotas RPC( centralizadas. Os usuários geralmente acessam Ethereum através de provedores centralizados. Essas empresas executam nós de alto desempenho em servidores em nuvem, ajudando os usuários a acessar facilmente os dados na cadeia. Quando a carteira consulta o saldo de tokens ou verifica se as transações pendentes foram incluídas em um bloco, quase sempre utiliza esses provedores centralizados.
O problema atual do sistema é que os usuários precisam confiar nesses fornecedores, sem poder verificar se os resultados da consulta 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 o PoS, podendo 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 a necessidade de executar um nó completo.
Dificuldade em conciliar conveniência e descentralização é um ponto comum de dor, este novo cliente pode completar a sincronização em cerca de dois segundos, e não requer armazenamento, os usuários podem acessar dados seguros na blockchain através de qualquer dispositivo ), incluindo smartphones e extensões de navegador (. Mas quais são os potenciais riscos de depender de infraestruturas centralizadas? Este artigo irá explorar esses riscos, apresentar o design do Helios, e fornecer algumas ideias para ajudar os desenvolvedores a contribuir para o repositório de código.
Riscos de Infraestrutura Centralizada: Produtos Teóricos na "Floresta Escura" do Ethereum
Um produto teórico está escondido na floresta negra. Ele não está à procura de presas no pool de memória de transações do Ethereum, mas cria armadilhas simulando a infraestrutura centralizada de que dependemos. Os usuários que caem nessa armadilha não cometeram nenhum erro: eles apenas acessaram a exchange descentralizada que costumam usar, definiram um deslizamento razoável e compraram e venderam tokens como de costume... eles não fizeram nada de errado, mas ainda assim enfrentaram um novo tipo de ataque sanduíche, uma armadilha cuidadosamente montada na entrada da floresta negra do Ethereum — o provedor RPC.
Antes de detalhar, vamos primeiro observar como as exchanges descentralizadas lidam com as transações. Quando os usuários executam uma troca, eles fornecem 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 deve receber para prosseguir com a transação. O último parâmetro indica a "saída mínima" que a troca deve alcançar, caso contrário, a transação será cancelada. Isso é geralmente chamado de "slippage", pois efetivamente estabelece a diferença máxima de preço que pode ocorrer entre o envio da transação para o pool de memórias e a inclusão da transação no bloco. Se o slippage estiver configurado muito baixo, o usuário pode acabar recebendo menos tokens. Essa situação também pode levar a um ataque de sanduíche, onde o atacante pode colocar a oferta do usuário entre duas transações maliciosas. Essas transações irão aumentar 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 este parâmetro de produção mínima esteja definido perto do valor justo, você não será afetado por ataques de sanduíche. Mas e se o seu provedor de RPC não fornecer cotações precisas para contratos inteligentes de intercâmbio descentralizados? Nesse caso, os usuários podem ser enganados e assinar transações de troca com parâmetros de produção mínima mais baixos. Pior ainda, os usuários podem enviar transações diretamente para provedores de RPC maliciosos. O provedor pode não divulgar essa transação para o pool de memórias públicas ), onde dezenas de robôs competem para realizar ataques de sanduíche (, mas reter privadamente e enviar o pacote de transações atacadas diretamente para alguma plataforma MEV para lucrar com isso.
A causa fundamental deste ataque é confiar nos outros para ajudá-lo a obter o estado do blockchain. Para resolver este problema, os usuários experientes geralmente executam seus próprios nós Ethereum, e este trabalho exige um grande investimento de tempo e recursos, necessitando de pelo menos um dispositivo sempre online, centenas de GB de espaço de armazenamento, e cerca de um dia para sincronizar do zero. Este processo é claramente mais simplificado do que no passado. Alguns grupos têm trabalhado incansavelmente para ajudar todos a executarem nós através de hardware de baixo custo, como por exemplo, um microcomputador Raspberry Pi com um disco rígido externo ). Mas mesmo com exigências significativamente reduzidas, executar um nó ainda é muito difícil para a maioria dos usuários, especialmente para aqueles que utilizam dispositivos móveis.
É importante notar que, embora ataques de fornecedores de RPC centralizados possam ocorrer, geralmente se tratam apenas de ataques de phishing simples, o tipo de ataque que mencionamos ainda não aconteceu. Embora o histórico passado de grandes fornecedores não nos dê razões para duvidar deles, vale a pena fazer mais pesquisas antes de adicionar fornecedores de RPC desconhecidos à carteira.
Introdução ao Helios: Acesso ao Ethereum totalmente sem confiança
O Ethereum lançou um protocolo de cliente ligeiro, abrindo possibilidades empolgantes para interações rápidas com a blockchain e validação de pontos finais RPC com os menores requisitos de hardware. Um mês após The Merge, uma série de clientes ligeiros independentes surgiu, cada um seguindo seu próprio caminho, mas todos com o mesmo objetivo: acesso eficiente sem necessidade de confiança, sem ter que usar 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 a Ethereum totalmente sem confiança. Tal como todos os clientes de Ethereum, Helios é composto por uma camada de execução e uma camada de consenso. Mas, ao contrário da maioria dos outros clientes, Helios combina estas duas camadas de forma estreita, permitindo que os utilizadores apenas instalem e executem um único software.
Como funciona? A camada de consenso Helios utiliza um hash de bloco de uma cadeia de sinalização conhecida 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 de cadeia de sinalização verificados com RPC de camada de execução não confiáveis, para verificar várias informações sobre o estado na cadeia, como saldos de conta, armazenamento de contratos, recibos de transações e resultados de chamadas de contratos inteligentes. Esses componentes trabalham juntos para fornecer aos usuários um RPC totalmente sem confiança, sem necessidade de executar um nó completo.
( camada de consenso
O cliente ligeiro da camada de consenso cumpre as normas do cliente ligeiro da Beacon Chain e utiliza o Comitê de Sincronização da Beacon Chain ), que foi lançado antes do Merge do hard fork Altair ###. O Comitê de Sincronização é um subconjunto de 512 validadores selecionados aleatoriamente, com um ciclo de serviço de cerca de 27 horas.
Depois que os validadores entram no comitê de sincronização, eles assinarão todos os cabeçalhos de bloco da cadeia de sinalização que veem (block header). Se mais de dois terços dos membros do comitê assinam um cabeçalho de bloco, é muito provável que esse bloco esteja na cadeia de sinalizaçã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 confiança consultando assinaturas do comitê de sincronização recente por meio 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, pode-se garantir que o bloco foi incluído na cadeia (. Claro, ele também pode ser reorganizado para fora da cadeia, e o rastreamento da finalização do bloco pode fornecer garantias mais fortes ).
Mas este estratégia claramente falta um elemento: 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 (weak subjectivity checkpoint). Não se deixe assustar pelo nome, ele simplesmente indica um hash de bloco antigo que pode garantir que foi incluído na cadeia em um determinado momento no passado. Quanto ao tempo exato de existência do ponto de verificação, há alguns cálculos matemáticos interessantes por trás: a análise do pior cenário mostra cerca de duas semanas, enquanto estimativas mais práticas indicam 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, que é codificado no repositório ( e facilmente substituído ), ele irá armazenar localmente o hash do bloco final mais recente, para ser usado como ponto de verificação quando os nós se sincronizarem.
Através da operação de hash, os blocos da cadeia de beacon podem facilmente gerar um hash único para o bloco da beacon. Desta forma, é possível consultar facilmente o bloco completo da beacon para os nós, e então, através da operação de hash e comparação com o hash de bloco conhecido, provar a validade do conteúdo do bloco. O Helios utiliza esta propriedade para obter e verificar certos campos dentro dos blocos de ponto 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 utilizar este mecanismo para revisar rapidamente a história da blockchain.
Agora que temos o ponto de verificação de fraca subjetividade, podemos obter e verificar o atual e o próximo comitê de sincronização. Se o cabeçalho da cadeia atual e o ponto de verificação estiverem dentro do mesmo ciclo do comitê de sincronização, podemos começar imediatamente a usar o cabeçalho do comitê de sincronização assinado para verificar novos blocos. Se o nosso ponto de verificação estiver depois de 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 validar um bloco que irá gerar um comité de sincronização 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 revisar rapidamente a história dessa Blockchain em intervalos de 27 horas, começando 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 beacon verificado 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 então ser acessados através de um servidor RPC hospedado localmente pelo Helios.
Aqui está um exemplo simples de como obter o saldo de uma conta. Primeiro, vamos apresentar brevemente 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 de 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 comprovar se existe alguma conta na árvore. Esta prova não pode ser falsificada.
Helios tem uma raiz de estado verificada )state root### da camada de consenso. Ao aplicar esta raiz de estado e o pedido de prova Merkle na camada de execução RPC não confiável, o Helios pode validar localmente todos os dados armazenados na Ethereum.
Utilizamos diferentes tecnologias para validar os diversos dados utilizados pela camada de execução, permitindo-nos verificar todos os dados provenientes de RPCs não confiáveis. Os RPCs não confiáveis podem recusar o acesso aos dados, mas nunca mais poderão fornecer resultados errados.
Usando o Helios no mundo real
É um ponto comum a dificuldade em equilibrar a conveniência e a descentralização. Com o Helios leve, os usuários podem acessar dados seguros na cadeia 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 seu provedor de RPC em uma carteira, para acessar várias DApps sem necessidade de 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 DApp ). Essas integrações aumentarão a segurança do Ethereum, reduzindo nossa necessidade de confiança em infraestrutura centralizada.
Existem várias maneiras de contribuir para o Helios, além de adicionar ao repositório de código; você também pode desenvolver software que integre o Helios para aproveitar suas vantagens. Aqui estão algumas ideias empolgantes: