Atualização do Nimbus: sincronização de checkpoint, arquivos de era, Vouch

(imagem do Lennon Wall cortesia da IFMSA)

Enquanto essas notas estavam sendo escritas, a guerra sem sentido de Putin na Ucrânia não deixou ninguém intocado e o Status não é exceção: Nossos colaboradores ucranianos foram forçados a entrar em abrigos antiaéreos com suas famílias à medida que as brutalidades aumentam. Aqui estão várias maneiras de ajudar: https://hrf.org/how-to-support-ukrainians/

Além disso, um número crescente de civis na Rússia e na Ucrânia está usando o projeto Tor para se comunicar, acessar notícias e contornar a censura. Você pode ajudá-los configurando uma bridge Tor: https://community.torproject.org/relay/setup/bridge/

Há duas semanas, publicamos o Nimbus v1.7.0, uma versão particularmente repleta de recursos para nosso cliente de camada de consenso.

@jcksie: "Até agora tudo bem"

@ethnimbus: Temos um novo lançamento :)
Nimbus v1.7.0 é uma atualização repleta de recursos de baixa urgência.
Os destaques incluem:

• Tempos de inicialização mais rápidos (3-5x)
• Menor uso de memória (<1GB na rede principal)
• Suporte para sincronização de nó confiável
• Suporte para provedores web3 HTTP(S)

Se você ainda não fez isso, recomendamos que você veja as notas de lançamento completas para todos os pequenos detalhes.

Há um punhado de tópicos importantes que não foram abordados nas notas, os quais acreditamos que vale a pena explorar em um formato mais longo.

Em particular, gostaríamos de abrir uma discussão sobre como melhorar a segurança da sincronização de pontos de verificação e outra sobre como buscar consultas de dados históricos em um mundo pós-EIP-4444.

Rede Insecura (ou como explorar a sincronização do ponto de verificação)

@jcksie: Ah não! Um "pato" malicioso pegou mais de 12.000 chaves de validação de um grande operador de custódia na rede #eth2 pyrmont e agora está oferecendo uma visão muito mais orientada ao nó mestre para a cadeia beacon, chamada "insecura" - o que aconteceu aqui?

Um dos ataques infames ao Proof-of-Stake é o chamado ataque de longo alcance, onde as chaves que foram comprometidas são usadas para criar um novo histórico que os nós honestos (que ficaram offline por um tempo suficiente) aceitam como válido.

@asglidden: Se for clara e exclusivamente atribuível, você não precisa de um hard fork. Você apenas corta de acordo com as regras do protocolo.

@edmundedgar: Eu não acho que isso esteja certo, por exemplo, se você tiver um ataque PoS de longo alcance em que alguém reuniu chaves de 3 anos atrás para fazer criar um novo histórico, todo mundo sabe qual cadeia é legítima e qual é a cadeia desonesta, mas você tem que olhar para evidências fora do protocolo para provar isso.

Como isso poderia acontecer na prática? O resumo disso é que a cadeia beacon possui um mecanismo de vivacidade (liveness) que sai dos validadores inativos. É possível que um player minoritário abuse desse mecanismo para criar um histórico no qual todos os validadores, exceto o seu, sejam forçados a sair, transformando sua minoria em maioria (em seu fork).

Uma vez que tal fork exista, a ideia é que um invasor possa tentar explorar a subjetividade fraca para fazer com que outros nós o aceitem como autêntico.

Felizmente, a subjetividade fraca, como originalmente pensada, é bastante resistente a tal ataque. Desde que menos de 1/3 das chaves no momento da bifurcação sejam comprometidas, os nós honestos fornecem um histórico muito mais plausível do que o do atacante: porque em contraste com a cadeia do atacante que contém um longo período de não-finalidade durante, os nós honestos têm uma cadeia de finalização.

Mesmo que um único invasor controle mais de 2/3 de todas as chaves que estavam ativas no ponto da fork hostil, não está claro se eles serão capazes de convencer a rede de que seu histórico alternativo está correto. Em particular, se um nó honesto não estiver sendo eclipsado, ele provavelmente escolherá a cadeia canônica simplesmente porque há mais pares servindo a ela.

No entanto, verifica-se que a sincronização do ponto de verificação muda as coisas drasticamente. Em particular, não está claro se o argumento acima ainda é válido. Isso é bastante contra-intuitivo. Afinal, por que passar uma URL em vez de um hash faria tanta diferença para as suposições de segurança da rede?

Como costuma ser o caso das suposições de segurança, o diabo está nos detalhes. O que se resume é o seguinte: sutilmente mudamos o comportamento esperado de "obter um hash de bloco de um amigo" (conforme articulado na postagem original de Vitalik sobre a Subjetividade Fraca) para "confiar em uma URL de um punhado de entidades centralizadas". Isso tem consequências importantes.

Parafraseando Jacek aqui, a sincronização de ponto de verificação ensina os usuários a passar uma única URL de uma entidade centralizada (pense em Infura ou Etherscan) para o nó beacon.

Se essa URL estiver comprometida (pense em uma violação de segurança em uma entidade centralizada), um invasor pode alimentar o cliente com qualquer estado que desejar, e o cliente “acreditará” desde que passe em algumas verificações básicas de sanidade. Em particular, o invasor pode passar ao usuário um estado que finalizou um histórico alternativo (ou seja, um ponto diferente de onde estão os validadores canônicos).

Se um nó começar a sincronizar a partir desse estado comprometido, ele acabará rejeitando todas as conexões e bloqueará os pares honestos e corretos que encontrar. Ele só poderá aceitar pares comprometidos ou desonestos, porque a cadeia do invasor é finalizada em um ponto que não pode ser reconciliado com a canônica.

Felizmente, Jacek ressalta que a maneira como esse problema específico surge pode ser detectado de várias formas. Em particular, esse ataque nos fornece várias bandeiras vermelhas ao longo do caminho (veja o final deste post para uma articulação completa sobre o assunto).Danny Ryan postou mais algumas ideias sobre como podemos abordar esse problema. Dois dos caminhos mais interessantes a seguir incluem:

• Download do checkpoint de N participantes: em vez de confiar na confiabilidade de uma entidade centralizada, consulte N entidades e verifique a unanimidade
• Projete uma maneira para que os bootnodes incluam pontos de verificação em seus ENRs publicados -- por exemplo, adicionando um campo opcional wsr (weak-subjectivity-root, ou seja, raiz de subjetividade fraca). Observe que não podemos simplesmente confiar na consulta de nós de inicialização, pois eles quase sempre estão em seus limites de pares. Em outras palavras, não podemos assumir que todos os clientes poderão manter uma conexão com um bootnode.
  

Achamos que é hora de levar essa discussão adiante.

Se você quiser entrar nos pormenores, certifique-se de verificar o artigo detalhado de Jacek sobre ethresearch. Ele executou de verdade esse ataque na rede Pyrmont, e o post mostra como isso foi feito.

Arquivos de Era (uma solução proposta para consultas de dados históricos)

Os clientes Ethereum atualmente armazenam 275 GB de dados históricos. Mas esses dados não são realmente necessários para validar a cadeia.

Está crescendo a uma taxa de cerca de 140 GB por ano e deve acelerar em um mundo pós-merge. O EIP-4444 é uma proposta que busca lidar com esse inchaço de dados fazendo com que os clientes removam dados com mais de 1 ano.

No entanto, algumas preocupações válidas foram expressas pela comunidade. Em particular, não está claro quanto é perdido ao impedir que os nós forneçam dados históricos pela camada p2p (algo que o EIP-4444 exige explicitamente).

@ercwl: Eu costumava ter a capacidade de baixar e validar o histórico e o estado completos apenas definindo um sinalizador no geth. Com essas alterações, os nós padrão se recusarão a servir para mim. Pode não importar para “a maioria”, mas alguns de nós se preocupam com isso e fazem isso.

@lightclients respondendo a @ercwl: A maioria dos usuários inicializa seus clientes com sincronização rápida/snap para que eles já não validem o estado desde a origem. Também é irrelevante porque os usuários não estão verificando a implementação do protocolo pelo cliente, portanto, confiam implicitamente nas equipes do cliente. WS torna isso explícito.

À luz dessas preocupações, a recente proposta de arquivos de Era de Jacek (veja um rascunho aqui) pode ser vista como uma espécie de meio termo.

@jcksie: No #eth, é amplamente reconhecido que ter cada nó sincronizando o histórico completo via p2p não é sustentável, e propostas como "rent" e EIP-4444 visam limitar o que os clientes "ao vivo" devem suportar. No entanto, também é amplamente reconhecido que os dados históricos são úteis!

O que exatamente é um arquivo de Era? Para pegar emprestadas as palavras de Jacek, um arquivo de Era é simplesmente um dia de blocos seguido pelos dados necessários para recriar o consenso naquele ponto: se você tiver um nó sincronizado que conhece a cabeça da cadeia beacon atual, os dados nos arquivos de Era podem ser usados ​​para recriar o estado histórico totalmente verificado para esse intervalo de tempo.

Os arquivos de Era, uma vez criados, são facilmente identificáveis, imutáveis ​​e idempotentes: qualquer pessoa com um nó totalmente sincronizado pode criar e/ou verificar um, e podem ser compartilhados por terceiros não confiáveis ​​sem introduzir novos problemas de segurança.

É importante ressaltar que em um arquivo de Era no futuro, o banco de dados permanece como a fonte da verdade para fins de segurança - ele armazena a raiz principal sincronizada mais recente que, por sua vez, determina onde um nó "inicia" sua participação de consenso. O diretório Era, no entanto, pode ser compartilhado livremente entre nós/pessoas sem quaisquer implicações de segurança (significativas), assumindo que os arquivos de Era são consistentes (ou seja, não quebrados).

Destaca-se que, por enquanto, os arquivos de Era cobrem apenas o consenso - em outras palavras, não o estado completo do Ethereum.

Após o merge, eles começarão a cobrir os dados do bloco, mas ainda não cobrirão o estado do Ethereum. Apoiar o mundo EIP 4444 completo é um tópico de pesquisa aberto. Mas, focar no consenso resolve uma parte importante do problema: ou seja, saber qual estado é relevante; isso transforma o problema mais amplo em um problema tratável.

Idéias para melhorias futuras incluem servir os arquivos de Era via REST: diferentemente da implementação atual que faz downloads bloco por bloco, baixar uma Era de cada vez cortaria quase inteiramente a sobrecarga de solicitação.

Uma pergunta natural a ser feita é, como os arquivos de Era afetam os requisitos de armazenamento em disco para nós?

Acontece que a resposta depende do tipo de nó que você está executando, bem como de como os metaparâmetros relevantes são escolhidos.

@jcksie: Depende! Os arquivos de Era dão à rede uma opção para degradar a funcionalidade normalmente - se definirmos o horizonte de poda para Era em 5 meses (com base nos requisitos de sincronização p2p na cadeia beacon), os dados de consenso totalizarão apenas 15 GB.. com o merge, adicione aproximadamente o que um cliente usa hoje (~ 1 TB) para obter a funcionalidade "equivalente", mas, mais importante, ela para de crescer lá, em geral, para o participante "normal"... nós leves usariam muito menos etc...

Gostaríamos muito de ouvir alguns comentários ponderados nesta fase. Essa é uma boa ideia ou não? Onde pode ser melhorado? O que está faltando?

Além disso, acreditamos que os arquivos de Era (ou algo semelhante) têm um papel a desempenhar no nível de execução (eth1). Esses arquivos (torrentados) podem ser usados para propagar a rede Portal. De fato, a rede do Portal mudou recentemente a prioridade, de trabalhar na rede State para o histórico da cadeia, principalmente devido ao EIP-4444. Veja aqui uma atualização geral.

Um protocolo libp2p para sincronização de clientes leves

Publicamos um rascunho de implementação do nosso protocolo libp2p proposto (no lado do servidor) para sincronização de clientes leves.

@ethnimbus: Servidor de sincronização leve - o que faz com que a familiarização com o consenso da cadeia beacon seja trivial para qualquer participante, grande ou pequeno - chegando a um @ethnimbus perto de você: https://github.com/status-im/nimbus-eth2/pull/3341

@jcksie: Se alguém tivesse que escolher um RP para contar a história por que o @ethnimbus foi iniciado como um projeto, isso com certeza chegaria perto.

Os clientes leves exigem nós completos para fornecer dados adicionais para que possam permanecer sincronizados com a rede. Este esboço contém uma nova opção de inicialização --serve-light-client-data que permite que um nó completo colete e divulgue os dados relevantes para clientes leves.

É uma implementação de nossa recente contribuição para as especificações de consenso.

Para algum contexto, as especificações do Altair precisavam ser atualizadas, porque, embora definisse estruturas para ajudar no desenvolvimento de clientes leves, faltava a definição do protocolo de rede.

Para preencher essa lacuna, Etan introduziu um protocolo baseado em libp2p para permitir que clientes leves sincronizem com o BeaconBlockHeader mais recente de maneira confiável e descentralizada. Isso se baseia no trabalho anterior de Hsiao-Wei Wang e Jin Huang. Você pode acompanhar as atualizações do Etan aqui.

Contexto útil: no final do ano passado, escrevemos sobre como os clientes leves são cruciais para um Ethereum pós-merge. Em um post separado, também abordamos como essa será uma área de foco para nós daqui para frente.

Suporte ao Vouch!

Por último, mas não menos importante, agora somos totalmente compatíveis com o Vouch! Um grande agradecimento ao Jim, que tem nos ajudado incansavelmente a testar, enfatizar e verificar a compatibilidade de nossa implementação de API REST.

@jgm: Acabei de lançar o Vouch 1.4.0 com suporte para @ethnimbus. Animado para adicionar outro nó beacon à mistura.

Como o Vouch parece estar se tornando uma espécie de padrão para provedores de staking, essa é uma ótima notícia para a diversidade de clientes: agora é perfeito para os provedores que usam o Vouch adicionar o Nimbus como um cliente alternativo.

O Vouch também permite que outros clientes validadores sejam executados com o Nimbus como nó beacon. Por exemplo, a Lighthouse executou com sucesso seu VC com uma Nimbus BN.

No momento, estamos conversando com vários fornecedores sobre o que eles podem fazer para adicionar o Nimbus à sua frota. Se você é um provedor e está pensando em adicionar o Nimbus à sua, entre em contato conosco em nimbus@status.im ou, alternativamente, entre em contato conosco em nosso discord. Estaremos mais do que felizes em responder a quaisquer perguntas que você possa ter e fornecer qualquer orientação e suporte que você possa precisar.

❤️