Extensão de mensagens parciais do Gossipsub e disseminação no nível celular – rede de rede

ou como tornar a propagação do blob mais rápida e mais eficiente

Graças a Raúl Kripalani, Alex Stokes e Csaba Kiraly pelo feedback sobre os primeiros rascunhos.

Visão geral

A nova extensão de mensagem parcial do Gossipsub permite que os nós atualizem para a disseminação do nível das células sem um garfo duro. Aumentando a utilidade dos dados do mempool local (getBlobs).

Existe um rascunho de relações públicas que especifica como os clientes de consenso usam a extensão parcial da mensagem aqui: Adicione a disseminação de células por meio da especificação de mensagens parciais por Marcopolo · Pull Solicy #4558 · Ethereum/consenso-specs · Github.

Introdução

Fusaka apresenta Peerdas com EIP-7594. Conforme explicado no EIP, os blobs codificados por apagamento são disseminados como colunas de células. As colunas são digitadas como datacolumnsidecar. Essas colunas são propagadas via Gossipsub para a rede. Se um nó já possui todos os blobs referenciados em uma coluna de seu mempool local, ele pode derivar o próprio Datacolumnsidecar sem esperar a propagação do GossipSub. Em seguida, também propaga a coluna para ajudar na rápida disseminação. A mensagem IDONTWANT do Gossipsub serve para suprir esses empurrões de um colega que já possui a mensagem IDONTWANT.

No caso de todas as bolhas referenciadas de um bloco aparecer na maioria dos mempool dos nós, atingir o requisito de custódia é rápido. Os dados já são locais. No entanto, se ainda estiver faltando um único blob, os nós devem aguardar a propagação das colunas completas pela rede antes de atingir seu requisito de custódia.

Idealmente, disseminaríamos apenas as células que estão ausentes para uma determinada linha. Permitindo que um nó use os dados que ele já possui localmente. É isso que a extensão de mensagem parcial do Gossipsub faz.

A extensão de mensagem parcial permite que nós envie, solicite e anuncie células de maneira sucinta. É uma alteração na camada de rede que não requer alterações de consenso, pode ser implantada de maneira compatível com versões anteriores e não requer um garfo duro.

Extensão de mensagem parcial, uma visão geral

A especificação de rascunho completa pode ser encontrada em libp2p/especificações.

As mensagens parciais se comportam de maneira semelhante às mensagens normais do GossipSub. A principal diferença é que, em vez de serem referenciados por um hash, eles são referenciados por um ID do grupo. O ID do grupo é definido pelo aplicativo e deve ser derivável sem exigir a mensagem completa. Com um ID de grupo e um bitmap, um nó pode especificar com eficiência quais peças está faltando e quais peças ele pode fornecer.

Para Peerdas, o ID do grupo é a raiz do bloco. É único por tópico. Uma coluna completa é uma mensagem completa e a célula é a menor mensagem parcial. Uma célula é identificada de maneira única e sucinta pelo tópico da sub -rede (o índice da coluna), ID do grupo (raiz do bloco) e posição no bitmap. Um nó pode começar a anunciar e solicitar células assim que receber o bloco. O que é o mais rápido possível, porque o bloco declara os blobs incluídos.

A disseminação no nível da célula com mensagens normais de fofocas é complicado, na melhor das hipóteses. Cada célula teria que ser referenciada por seu ID de mensagem completo (20 bytes) e os nós não podem solicitar células ausentes a priori; Eles devem primeiro saber como uma célula mapeia o ID de mensagem correspondente. Por outro lado, com mensagens parciais, os nós fazem referência a cada célula um pouco em um bitmap e podem trocar informações do que podem fornecer e o que precisam com parcial IHAVEs e parcial IWANTs.

As mensagens parciais podem ser ansiosamente empurradas para um colega sem esperar que o colega solicite peças ou possa ser fornecido mediante solicitação.

As mensagens parciais do GossipSub exigem cooperação do aplicativo, pois o aplicativo sabe como as mensagens compõem e dividem. Os aplicativos são responsáveis ​​por: – codificação disponível e peças ausentes (por exemplo, um bitmap). – decodificar uma solicitação de peças e responder com uma mensagem parcial codificada. – Validando uma mensagem parcial codificada. – mesclando uma mensagem parcial codificada.

Exemplo hipotético flui

Para ajudar a construir uma intuição sobre como as mensagens parciais funcionarão na prática, considere esses dois exemplos. O primeiro exemplo usa pressões ansiosas para reduzir a latência, o segundo exemplo aguarda uma solicitação de pares que pode reduzir duplicatas às custas da latência (1/2 RTT neste exemplo).

Para ambos os exemplos, suponha:

• PEER P é o proponente de um bloco. Ele conhece todos os bolhas em um bloco.
• Os pares A e B são validadores.
• A primeira bolha no bloco não foi compartilhada publicamente a A e B antes da mão, então ambos estão perdendo essa bolha de sua única mempool local.
• P está conectado a A está conectado a B. p <=> A <=> B

Ansioso por empurrar

┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐
│        P         │   │        A         │   │        B         │
└──────────────────┘   └──────────────────┘   └──────────────────┘
 ┌────────────────┐             │                      │
 │Proposes Block B│             │                      │
 └───────┬────────┘             │                      │
         │   ┌──────────────┐   │                      │
         ├───│Forwards block│──▶│   ┌──────────────┐   │
         │   └──────────────┘   ├───│Forwards block│──▶│
         │   ┌──────────────┐   │   └──────────────┘   │
         │   │  Eager push  │   │  ┌──────────────┐    │
         ├───│cell at idx=0 │──▶│  │  Eager push  │    │
         │   └──────────────┘   ├──│cell at idx=0 │──▶ │
         │                      │  └──────────────┘    │
         │                      │                      │
         │                      │                      │
         │                      │                      │
         ▼                      ▼                      ▼

Solicitação/resposta

┌──────────────────┐   ┌──────────────────┐   ┌──────────────────┐
│        P         │   │        A         │   │        B         │
└──────────────────┘   └──────────────────┘   └──────────────────┘
         │                      │                      │
 ┌───────┴────────┐             │                      │
 │Proposes Block B│             │                      │
 └───────┬────────┘             │                      │
         │   ┌──────────────┐   │                      │
         ├───│Forwards block│──▶│   ┌──────────────┐   │
         │   └──────────────┘   ├───│Forwards block│──▶│
         │   ┌──────────────┐   │   └──────────────┘   │
         │   │    IWANT     │   │   ┌──────────────┐   │
         │◀──│    idx=0     │───│   │    IWANT     │   │
         │   └──────────────┘   │◀──│    idx=0     │───│
         │   ┌──────────────┐   │   └──────────────┘   │
         │   │ Respond with │   │   ┌──────────────┐   │
         ├───│  cell@idx=0  │──▶│   │ Respond with │   │
         │   └──────────────┘   ├───│  cell@idx=0  │──▶│
         │                      │   └──────────────┘   │
         ▼                      ▼                      ▼

Observe que os colegas solicitam dados antes de saber o que um colega tem. A solicitação faz parte do Iwant Bitmap do par, que é enviado ao lado de seu Ihave Bitmap. Isso significa que os dados podem ser recebidos em um único RTT quando o par pode fornecer os dados. Por outro lado, um fluxo de anúncio, solicitação e resposta requer 1,5 rtt.

Estratégia de publicação

O empurrão ansioso é mais rápido que a solicitação/resposta, mas corre o risco de enviar informações duplicadas.

A estratégia de publicação deve, portanto, ser:

Push ansioso quando houver confiança de que esta será a primeira entrega desta mensagem parcial.

Em um cenário com bolhas particulares, é razoável que um nó encaminhe com um empurrão ansioso quando recebe uma bolha privada.

Em um cenário com Mempools Sharded, é razoável que um nó empurre ansiosamente as células que conhece um colega não teria devido à sua estratégia de fragmentação.

Algumas informações duplicadas são esperadas e necessárias como uma forma de resiliência. A quantidade de duplicatas pode ser ajustada ajustando a probabilidade de empurrar ansiosos e a probabilidade de solicitar um par.

No entanto, mesmo uma estratégia ingênua simples deve superar significativamente nossa atual abordagem de coluna completa, aproveitando os dados locais do Mempool. Mensagens parciais duplicadas resultariam em células duplicadas em vez de duplicar colunas completas.

Prova de conceito de devnet

Há uma implementação de trabalho em andamento da extensão parcial da mensagem. Há também um patch no prysm que usa mensagens parciais.

Como prova de conceito, criamos uma devnet de curtose usando os clientes do PRYSM corrigidos conectados a clientes Geth corrigidos (para retornar blobs parciais na chamada GetBlobs). Alguns nós construiriam blocos com bolhas “privadas”. Quando isso aconteceu, outros nós solicitavam apenas as células “privadas” ausentes e preenchiam o restante da coluna com bolhas de seu mempool local.

Para obter uma sensação difícil de economia de largura de banda, também criamos uma rede de curtose menor de apenas dois nós “super”, nós que recebem e enviam todas as colunas. Um dos nós propõe blobs particulares. Os meios que o GetBlobs não retornarão uma coluna completa para o outro nó quando o nó mencionado acima propõe.

Medimos dados enviados para DataColumnSidecar mensagens sem e com mensagens parciais. Os resultados mostram com mensagens parciais, os nós enviam 10x menos dados. Existem duas razões para isso:

1. A atual implementação do PRYSM de mensagens parciais nunca empurra ansiosamente. Os nós esperam para ver uma solicitação antes de responder com dados.
2. Somente as peças solicitadas são enviadas. Se uma coluna tivesse uma única bolha privada, enviamos apenas uma bolha.

Nesse ambiente de baixa latência (em execução localmente com curtose), o IDONTWANTS não é eficaz. Portanto, vemos um grande benefício em simplesmente não pressionar ansiosamente os dados.

No entanto, nos casos em que há bolhas privadas, o IDONTWANT não seria aplicável; portanto, os benefícios de desempenho aqui ainda são representativos da maior latência mais realista.

Gráficos:

Este é um experimento com apenas dois colegas, mas cada interação pareada em uma malha com mais colegas deve se comportar da mesma forma. É a largura de banda usada para disseminar colunas de dados.

Mempool Sharding

As direções futuras do sharding de Mempool só aumentarão a probabilidade de que os nós estejam faltando algumas células e, portanto, exijam alguma forma de disseminação no nível celular.

Disseminação baseada em “Linha”

Observe que, se um nó estiver faltando uma célula em algum índice em uma coluna, provavelmente está ausente de células na mesma posição em todas as outras colunas. Uma melhoria futura pode ser permitir que nós anunciem linhas completas para seus colegas de malha. O benefício é que um nó preenche todas as suas células ausentes por uma linha de uma só vez. A desvantagem é o risco de maiores mensagens duplicadas.

PRÓXIMOS PASSOS

• Especifique a API GetBlobs V3 que suporta retornar os blobs parciais.
• Implementar a extensão de mensagem parcial na ferrugem libp2p. (em andamento)
• Especifique a codificação de mensagem parcial de DatacolumnSidecars. Em andamento
• Integrar os clientes CL.
• Implantar no TestNets
• Implantar no Mainnet
• contagem de blob em escala