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:*
-
*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). -
*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). - *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.