Propagação de bloco/blob mais rápida no Ethereum – Página 3 – Networking

Porque cada pedaço individual precisa ser assinado para não os nós do DOS. Como observei acima, há apenas uma assinatura necessária (para o comprometimento de todos eles), mas essa assinatura precisa vir em pedaços; portanto, você altera o esquema de assinatura atual, que é o que faz com que as profundas mudanças.

Trabalho emocionante! Obrigado por testar isso

Algumas perguntas:

• Quais são as especificações da rede das máquinas?
• Você poderia vincular o código que distribui os pedaços RLNC à malha?
• Como a paralelização acelera a computação de compromisso?

Vou adiar a primeira pergunta para @parithosh, tudo o que me lembro deles é s-8vcpu-16gb-amd para espec. O ramo que foi testado é (não se fundir) usar o RLNC para propagação de blocos por POTUZ · PULL SOITE #14813 · OFFCHAINLABS/PRYSM · GitHub sem as últimas confirmações para a paralelização. A chamada para distribuir os pedaços começa nessa linha.

O último banco que posso encontrar paralelo é

cpu: Intel(R) Core(TM) i9-14900
BenchmarkChunkMSM_6MB-32               1        1383648871 ns/op        317930016 B/op    197009 allocs/op
BenchmarkChunkMSM_2MB-32               3         355434164 ns/op        106150704 B/op     65944 allocs/op
BenchmarkChunkMSM_200KB-32            33          34271750 ns/op        10362574 B/op       6798 allocs/op

Paralellized:
BenchmarkChunkMSM_6MB-32               4         267416300 ns/op        317934364 B/op    197033 allocs/op
BenchmarkChunkMSM_2MB-32              14          82303238 ns/op        106154188 B/op     65969 allocs/op
BenchmarkChunkMSM_200KB-32           139           8521646 ns/op        10363791 B/op       6823 allocs/op

Mas esta é uma máquina rápida.

EDIT: Quero enfatizar isso de qualquer maneira, se isso entrar em produção, provavelmente queremos usar uma curva definida sobre F_2 em vez de Ristretto.

Ei, é ótimo ver! Trabalho com uma equipe chamada Optimum, estamos construindo tecnologia baseada em RLNC para Web3-nosso primeiro produto é uma biblioteca de fofocas de uso geral construído no Gossipsub.

Nós integramos nossa biblioteca com Sombrae executou as mesmas experiências do Ethereum Mainnet que @popth nas experiências de “dobrar a contagem de blob” (obrigado pelo excelente trabalho lá, foi muito fácil de construir). Vimos resultados igualmente positivos – o tempo para 99% dos nós Receber uma mensagem é geralmente sobre duas vezes mais rápido. Observe que isso é sem Parâmetros de ajuste, suspeito que possamos obter resultados significativamente melhores brincando com vários números.

Também executamos isso em alguns infra-do-mundo real e obtivemos resultados semelhantes. Parece escalar com mensagens maiores realmente Bem, ainda não encontramos seu ponto de ruptura porque minha área de trabalho fica sem memória antes disso.

Alguns pontos de diferença para observar:

• Estamos usando \ mathbb {f} _ {256} para representar coeficientes e elementos
• Ainda não estamos lidando com a possibilidade de pedaços ruins (assumindo um comportamento honesto de todos os nós). Temos algumas idéias de como podemos fazer isso, a ideia de compromisso de Pedersen é realmente legal!
• Ao contrário da abordagem aqui, modificamos o próprio protocolo Gossipsub para trabalhar com pedaços. Eu acho que isso é importante, porque assim você tem controle total sobre como os pedaços são propagados. Não tenho certeza de como funciona a abordagem neste tópico:
  • Um nó sempre encaminha um pedaço que recebe para seus colegas de malha (além de potencialmente criar um novo pedaço no nível do aplicativo publicado separadamente?)
  • É fofoca (IHAVE/IWANT/IDONTWANT) Emitido para cada pedaço?
• A modificação do GossipSub para estar ciente dos pedaços também permite que você faça algumas boas otimizações. Como exemplo, ao enviar IWANT Mensagens de controle, nós podem especificar quantos mais pedaços de que precisam (que o nó de recebimento pode ou não respeitar).

Fiquei me perguntando o que (se alguma coisa) poderíamos fazer, que seria útil para seus esforços. Fico feliz em executar mais simulações no Shadow se houver outros números que você gostaria de ver capturados (atualmente limitados pelo meu 256 Gib Ram Desktop, mas estamos procurando uma máquina maior). Também feliz em conversar sobre quaisquer perguntas abertas ou escrever qualquer código que seja útil. Muito animado para ver o RLC sendo experimentado!

Oi @arajasek, bom ver que você participa da discussão aqui!

Observe que a Shadow não explica o tempo da CPU. Dependendo de como você integrou seu código, isso pode ser uma grande diferença em comparação com as execuções nos dados de teste. Estamos investigando como contornar isso (fazia parte da sombra até certo ponto, mas removida para favorecer a reprodutibilidade).

Ao contrário da abordagem aqui, modificamos o próprio protocolo Gossipsub para trabalhar com pedaços. Eu acho que isso é importante, porque assim você tem controle total sobre como os pedaços são propagados. Não tenho certeza de como funciona a abordagem neste tópico …

Houve vários estudos sobre a propagação de grandes mensagens sobre o Gossipsub com o Chunking. No trabalho de Fulldas (onde a parte da simulação também usa o NIM-LIBP2P + Shadow), usei uma abordagem ingênua na implementação, simplesmente usando mensagens pequenas e lidando com qualquer coisa relacionada ao contexto de mensagem grande em um nível mais alto na pilha. Mas a postagem vinculada também contém propostas para IDs de mensagem estruturados, Ihave/iwant baseado em bitmap, etc.

Seria realmente interessante ver quais modificações você fez em sua versão.

Mas esse é o objetivo do problema! Não podemos usar esses pequenos campos como F_ {256} porque não podemos ter compromissos compatíveis. Não podemos assumir que todos os nós são honestos. Observe que um único nó malicioso pode injetar um número arbitrariamente alto de pedaços ruins que se propagam no envenenamento por cadeia todas as mensagens que seus colegas enviam.

Ainda não descobrimos uma boa maneira de usar um campo pequeno para escalares e, ao mesmo tempo, ter uma boa assinatura ou hash homomórfico que torna isso viável para algo como bolhas.

Para blocos e cargas úteis, Ristretto é bom o suficiente de qualquer maneira.

Depois de alguma experimentação com diferentes campos e caixotes, pude obter acelerações significativas usando os escalares do BLS12-381 com o blstrs Crate, em tudo, exceto se comprometendo com pequenos blocos.

Abriu um draft Showcase PR aqui com os resultados: Mostrar: Use BLS12-381 com Blstrs por Mempirate · Pull Solicy #1 · POTUZ/RLNC_POC · GitHub

Temos uma maneira de lidar com blocos ruins atualmente. Mencionei anteriormente as referências sobre como lidar com nós bizantinos que introduzem blocos ruins (veja meu post de 3 de fevereiro). Eu recomendaria não usar compromissos de Pedersen por causa da modularidade, por mais arrumada que o encontro de uma perspectiva técnica pura. O que você está fazendo é amarrar a representação com a validação, o que é bom, mas fecha as portas. Por exemplo, você começa com um campo de extensão binária, depois decide fazer homomórficos e precisa ir para um grande primo … não é impossível, mas também não super feliz. A abordagem que usamos não une os dois juntos.

Agora estamos gerenciando as possibilidades de pedaços ruins no ideal

Bem, ainda não descobrimos uma maneira melhor do que os compromissos de Pedersen. E sim, precisamos ir para um grande primo, um campo binário não funciona e não sabemos como fazê -lo funcionar com campos menores. A literatura que vimos sobre o assunto (incluindo as da sua mensagem em 3 de fevereiro) não parece funcionar para nossa aplicação no Ethereum L1. O único que talvez funcionasse é ter assinaturas homomórficas, mas isso é impraticável na corrente de corrida.

Se você conhece uma maneira melhor de lidar com nós maliciosos, seria útil apontar um método específico que você acha que funciona nessa configuração. Podemos então discutir isso.

Para ser concreto, olhei brevemente o artigo “Codificação de rede resiliente na presença de adversários bizantinos”. O artigo mostra, entre outros resultados, que se um adversário puder injetar z pacotes por tempo e a capacidade da rede é Centão o código atinge uma taxa de C – 2Z. Isso significa que se supõe que um receptor obtenha pacotes mais honestos do que os maliciosos. Isso não parece aplicável na configuração de blockchain, onde nós honestos tentam minimizar o tráfego de rede (em vez de esgotar a capacidade da rede) e os adversários podem enviar spam na rede. Observe que a abordagem de compromisso de Pedersen não sofre disso (mas assume um adversário limitado computacionalmente).

Em geral, qualquer mecanismo que decidimos propagar os blocos mais rapidamente deve ter como objetivo: (a) saturar todos os caminhos de malha em paralelo, (b) utilizar toda a largura de banda disponível, (c) maximizar a eficiência transmitindo informações exclusivas, (d) garantir que lidamos apenas com pedaços autenticados.

No nível da rede, devemos favorecer os pacotes dimensionados abaixo do caminho da MTU para evitar a fragmentação IP. Como agora lidamos com unidades de propagação menores e redundância de codificação de dados internos, podemos usar datagramas QIC (não confiáveis) com fanouts maiores experimentando várias estratégias de roteamento (por exemplo, caótica/aleatória, centrada na latência, etc.) para ativar a transmissão paralela a Burstier. Também podemos aproveitar a retomada da sessão Quic para “aquecer” as conexões com um grande conjunto de colegas com antecedência, para despachar mais tarde pacotes rapidamente com 0-RTT em um canal seguro restabelecido.

Infelizmente, o uso de campos grandes com o RLNC para permitir que os compromissos reduzem significativamente o espaço dos parâmetros, na medida em que nenhum dos itens acima é possível devido à sobrecarga do coeficiente.

Existem outras direções no espaço de design que estou ansioso para explorar. Aqui estão alguns que parecem conceitualmente promissores e valiosos.

1. Códigos sem rodovias/fontes como o Raptorq (RFC6330) com pacotes autenticados pela fonte carregando assinaturas sobre o pacote Index +. O principal problema é saber quando os produtores devem parar de semear pacotes. Temos um loop de feedback embutido: chegada do atestado. Atestados válidos indicam que os colegas reconstruíram com sucesso a carga útil original e podem ajudar outras pessoas na conversão. Poderíamos definir limiares de % dinâmicos sobre os atestados esperados nas sub -redes inscritas. Embora os clientes do CL atestem em momentos diferentes, existem esforços para normalizar isso para “assim que um bloco válido for visto”.

2. Reed-Solomon tradicional/sistemático com pacotes autenticados de origem, oportunisticamente pegandobacking Disponibilidade Bitmaps para uma reconciliação de conjunto em pares. Isso evita transferências duplicadas ao custo da sobrecarga do bitmap (redutível com a compressão RLE/rugindo). O principal desafio é a otimização de parâmetros, a redundância de RS concretamente, o paralelismo de bitmap, o paralelismo dos colegas e o comportamento de reconciliação.

3. IBLTS sem valor para propagação do bloco com reconhecimento de mempool. Isso reconcilia os blocos de entrada em relação ao conteúdo local do Mempool, transmitindo apenas transações ausentes. Dado ~ 60% de transações públicas em blocos, esse método pode atingir 1,35x de comunicação sobrecarga em relação às transações privadas/ausentes (40%), potencialmente reduzindo consideravelmente a largura de banda de propagação do bloco. Um colega provavelmente pode reutilizar o símbolo local definido em todos os seus colegas, embora precisemos de pesquisas extras sobre paralelização entre pares. Dito isto, há uma consideração de privacidade. Embora o Devp2p anuncie os TXs que podem ser retirados mais tarde, esse algoritmo pode revelar o estado atual do Mempool, que os adversários poderiam teoricamente explorar. No entanto, as melhorias de largura de banda e latência podem justificar essa troca.

Estamos trabalhando na prototipagem (1) e (2) na equipe de rede P2P na EF – teremos mais para compartilhar nas próximas semanas!