RFC 032 - Ripple Effect Protocol (REP) Primário (Privacidade Diferencial)
Status: Rascunho Aprovado (Visão v2+) Pilar: S3 (Economia) / S2 (Biologia) / S1 (Segurança)
1. Resumo
A visão para a v2+ do PAEBIRU promove o Ripple Effect Protocol (REP) de uma função interna de roteamento para um subsistema de classe superior. O protocolo permite o vazamento de intenções econômicas e computacionais complexas para otimização sistêmica, utilizando mecanismos de Privacidade Diferencial para garantir anonimato e prevenir ataques de manipulação de mercado (front-running).
2. Motivação
Na v1, o REP é confinado à termodinâmica de rede. No entanto, antecipar a demanda por recursos do Barter Engine ou alocações no C.A.P.I.B.A. Storage permitiria que o enxame “pré-aquecesse” recursos (ex: saindo de deep sleep ou reservando cache) antes do fechamento formal dos contratos (Plasmídeos). O desafio é realizar essa antecipação sem vazar dados sensíveis ou permitir que atores maliciosos explorem a intenção alheia para ganho financeiro.
3. Especificação Técnica
3.1. Privacidade Diferencial Estigmergica
Nenhuma intenção vaza em sua forma bruta. O módulo REP aplica ruído estatístico ($\epsilon$-differential privacy) utilizando a distribuição de Laplace:
$$ \mathcal{M}(x) = f(x) + \text{Laplace}\left(\frac{\Delta f}{\epsilon}\right) $$
Onde:
- $f(x)$: A intenção real (ex: volume de dados a ser alocado).
- $\Delta f$: Sensibilidade da transação.
- $\epsilon$: Parâmetro de privacidade (nível de anonimato desejado).
3.2. Pré-Aquecimento de Enxame
Os nós vizinhos recebem o gradiente ofuscado e o interpretam não como uma ordem de execução, mas como uma tendência de metabolismo. Isso aciona a alocação passiva de infraestrutura, reduzindo drasticamente a latência de cold-start para o Compute-over-Data.
3.3. Proteção contra Front-Running
Como o sinal do REP é estatisticamente incerto, é matematicamente impossível para um atacante isolar a identidade do solicitante ou os termos exatos do contrato para aplicar ataques de sandwich ou antecipação financeira.
4. Impacto Arquitetural Futuro (v2)
- Economy: Implementação de “Dicas de Intenção” (Intention Hints) opacas despachadas antes do handshake x402.
- Math: Adição de geradores de ruído de Laplace otimizados para
no_std. - Capiba: Reação proativa a pulsos REP para gestão de cache e hierarquia de armazenamento (Ocean vs Spring).
5. Estado de Implementação (v0.0.1)
| Componente | Status | Arquivos Principais |
|---|---|---|
| Math | ✅ Implementado | crates/math/src/domain/privacy/laplace.rs — LaplaceNoiseGenerator com PRNG xorshift64* puro no_std e transformada inversa da CDF de Laplace. |
| Biology | ✅ Implementado | crates/biology/src/domain/agent/rep.rs — RepConfig, ObfuscatedDeliberationGradient, RepManager::obfuscate_local_gradient(). ports/out_network.rs — broadcast_deliberation_gradient. |
| Economy | ✅ Implementado | crates/economy/src/domain/types.rs — OpaqueIntentionHint com amount_bucket logarítmico. actor/mod.rs — processamento de DispatchIntentionHint com sinalização no InternalEventBus. |
| Capiba | ✅ Implementado | crates/capiba/src/domain/rep.rs — RepComputeHint, RepPulseMetadata. actor/mod.rs — PreWarmForCompute (mantém chunks na Nascente) e ReactToRepPulse (ajuste térmico proativo). |
| Kernel | ✅ Implementado | crates/kernel/src/infra/bus.rs — novos eventos RepGradientEmitted, IntentionHintDispatched, CapibaPreWarmed. crates/kernel/src/domain/network/rep.rs — RepIntentScore (kernel-safe, opaque). crates/kernel/src/domain/network/stigmergic.rs — StigmergicRouter::update_rep_intent() para pré-aquecimento proativo de rotas e decaimento temporal. |
| Node | ✅ Implementado | apps/node/src/node/mod.rs — RepConfig injetada no AbaporuActor. lifecycle.rs — encaminhamento cross-cutting de gradientes para Economy e Capiba. apps/node/src/node/handlers/network.rs — recepção de gradientes paebiru-consciousness e integração no router. |