Gleam.br Wiki

GBR: ADR-0006 Implementação do Protocolo GossipSub v1.1 para Mensageria Inter-Agentes e Otimização FinOps | Wiki

Documentação de engenharia e especificações técnicas da Gleam-BR.

GBR: ADR-0006 Implementação do Protocolo GossipSub v1.1 para Mensageria Inter-Agentes e Otimização FinOps

*Status:* Aceite *Data:* 2026-05-01

*Contexto:*

A FVideen projetou um ecossistema onde milhares de Agentes IA precisarão de trocar modelos de linguagem (GGUF), bancos de dados vetoriais (DuckDB) e logs de raciocínio. Depender de uma infraestrutura centralizada na Nuvem (AWS, GCP) para gerir este tráfego geraria custos variáveis proibitivos (aproximadamente US$ 0,09 por GB de tráfego de saída/egress), inviabilizando financeiramente a operação de uma "Internet de Agentes" em larga escala. Além disso, a comunicação 1-para-N (um nó a alertar milhares de outros) através de ligações TCP individuais causaria exaustão rápida de recursos (CPU/File Descriptors).

*Decisão:*

  1. *Adoção do GossipSub v1.1:* Integração do protocolo de publicação/subscrição (Pub/Sub) padronizado pelo ecossistema IPFS/libp2p (gbr_p2p_gossipsub). Este protocolo permite a transmissão de mensagens em formato de "fofoca" (gossip), mitigando tempestades de broadcast (Broadcast Storms).
  2. *Separação Estrita de Tipos de Controlo e Dados:* Em Gleam, implementou-se a topologia de tipos (message.gleam) separando o que é tráfego de negócio (Message) do que é manutenção de rede (ControlMessage: IHAVE, IWANT, GRAFT, PRUNE).
  3. *Manutenção Ativa de Malha (Heartbeat):* O Ator OTP que atua como Roteador GossipSub implementa um ciclo interno de Heartbeat (pulso de 1 segundo) para otimização proativa e ininterrupta da topologia de rotas entre os peers.

*Consequências:*

  • *Positivas:* Transformação de um custo operacional variável de nuvem num custo marginal zero (o tráfego viaja livremente pela internet pública entre os peers); alta resistência a ataques Sybil e mitigação de Spam devido aos mecanismos de Peer Scoring embutidos na versão 1.1 da especificação.
  • *Negativas/Riscos:* A manutenção da "malha" (Mesh) e do "fanout" exige alocação constante de memória RAM para as tabelas de estado do Ator, além de um histórico de mensagens vistas (seen_messages) para evitar ciclos infinitos de retransmissão.