Teoria das Filas e a Lei de Little Aplicadas ao ZeroTrustPipeline

Referência cruzada: RFC 003 (Pipeline de Portais Ordenados), RFC 048 (eBPF/XDP Physical Blade), docs/src/benches/README.md.

1. Introdução

O ZeroTrustPipeline do PAEBIRU é composto por cinco portões sequenciais que todo pacote ou operação deve atravessar antes de interagir com o domínio do nó. Cada portão pode ser modelado como uma fila de serviço clássica, onde pacotes chegam a uma taxa $\lambda$ e são processados a uma taxa $\mu$.

Este documento aplica a Lei de Little ($L = \lambda W$) e modelos de filas M/M/1 e M/D/1 para:

1. Dimensionar os parâmetros operacionais de cada portão.
2. Definir SLIs (Service Level Indicators) mensuráveis.
3. Prever o comportamento do pipeline sob estresse (ataques volumétricos, picos de transações).

2. Modelagem por Portão

2.1. Portão 1 — Load Shedder (eBPF/XDP)

• Natureza: Fila M/D/1 (processamento determinístico em kernel space).
• $\lambda_1$: Taxa de chegada de pacotes (pps — packets per second).
• $\mu_1$: Taxa de processamento do eBPF/XDP (depende do programa BPF e da NIC).
• Serviço: Descarte ou encaminhamento baseado em regras estáticas e estado de congestão.

Lei de Little:

$$L_1 = \lambda_1 \cdot W_1$$

Onde $W_1$ é o tempo médio de decisão no eBPF (< 50 ns, conforme benchmarks). Para $\lambda_1 = 10 \text{ Mpps}$:

$$L_1 = 10 \times 10^6 \times 50 \times 10^{-9} = 0.5 \text{ pacotes em fila}$$

Ou seja, o Portão 1 opera com quase zero enfileiramento em condições normais. O dimensionamento depende exclusivamente da capacidade da NIC + XDP.

SLI proposto:

O Portão 1 deve sustentar $\lambda = 14 \text{ Mpps}$ com latência p99 < 100 ns e taxa de drop de pacotes legítimos < 0.001%.

2.2. Portão 2 — Proof-of-Work (BLAKE3)

• Natureza: Fila M/M/1 (processamento com variabilidade dependente do nonce).
• $\lambda_2$: Taxa de operações que requerem PoW (ops/s).
• $\mu_2$: Taxa de verificação BLAKE3 (~500 ns/op em hardware moderno).

Utilização:

$$\rho_2 = \frac{\lambda_2}{\mu_2}$$

Para evitar saturação, $\rho_2 < 0.7$ (regra prática para filas M/M/1). Se $\mu_2 \approx 2 \times 10^6 \text{ ops/s}$:

$$\lambda_{2,max} \approx 1.4 \times 10^6 \text{ ops/s}$$

Custo operacional: O parâmetro PAEBIRU_GATE_SECURITY_COST_MICRO_JOULES debita o custo energético por operação PoW. O dimensionamento energético total do Portão 2 é:

$$E_2 = \lambda_2 \times \text{cost}_{\mu J} \times 10^{-6} \quad [J/s]$$

SLI proposto:

O Portão 2 deve processar 1.000.000 verificações BLAKE3/s com latência p99 < 2 μs e custo energético debitado corretamente em 100% das operações.

2.3. Portão 3 — Assinaturas PQC (ML-DSA-65)

• Natureza: Fila M/M/1 (variabilidade alta: assinatura vs verificação).
• $\lambda_3$: Taxa de operações criptográficas PQC.
• $\mu_3^{\text{verif}} \approx 66.000 \text{ ops/s}$ (~15 μs/verificação).
• $\mu_3^{\text{sign}} \approx 10.000 \text{ ops/s}$ (~100 μs/assinatura).

Gargalo típico: Verificação de assinaturas em batch de gossip. Para uma malha de 1000 nós, cada nó pode receber até $N \times f$ assinaturas por segundo, onde $f$ é a frequência de heartbeat.

Para $f = 1 \text{ Hz}$ e $N = 1000$:

$$\lambda_3 = 1000 \text{ verificações/s} \ll \mu_3^{\text{verif}}$$

Margem de segurança: $\rho_3 \approx 0.015$ (muito baixa utilização). O gargalo só aparece sob ataque Sybil massivo.

SLI proposto:

O Portão 3 deve processar 10.000 assinaturas PQC/s com latência p99 < 5 ms e rejeitar assinaturas inválidas em < 1 μs (fail-fast).

2.4. Portão 4 — ZK-PoL (Groth16)

• Natureza: Fila M/M/1 com serviço pesado e variável.
• $\lambda_4$: Taxa de provas de localização submetidas.
• $\mu_4^{\text{verif}} \approx 500 \text{ ops/s}$ (~2 ms/verificação Groth16).

Este é o portão mais pesado do pipeline. Para cenários de alta densidade (ex: cidade inteligente com 10.000 nós móveis):

$$\lambda_4 = 10.000 \times \frac{1}{60} \approx 167 \text{ provas/s}$$

$$\rho_4 = \frac{167}{500} \approx 0.33$$

Ainda confortável, mas requer atenção se múltiplas provas forem verificadas em série.

SLI proposto:

O Portão 4 deve verificar 500 provas ZK-PoL/s com latência p99 < 10 ms e throughput mínimo de 250 provas/s mesmo sob spike 3×.

2.5. Portão 5 — Contrato de Dados (CDDL + Semântica)

• Natureza: Fila M/D/1 (validação de schema é determinística).
• $\lambda_5$: Taxa de payloads que chegam à camada de aplicação.
• $\mu_5$: Taxa de validação CDDL (tipicamente < 100 μs para payloads < 10 KB).

Este portão é o mais leve em termos de CPU, mas o mais complexo em termos de lógica. A validação semântica pode envolver callbacks para a MacrophageVM (RFC 049).

SLI proposto:

O Portão 5 deve validar 50.000 payloads/s com latência p99 < 500 μs e taxa de falso-positivo (payload legítimo rejeitado) < 0.01%.

3. Pipeline Completo como Rede de Filas

Os cinco portões estão em série. Para uma operação que passa por todos os portões, o tempo total médio é:

$$W_{\text{total}} = \sum_{i=1}^{5} W_i$$

Onde cada $W_i$ é o tempo médio de espera + serviço no portão $i$.

Para filas M/M/1:

$$W_i = \frac{1}{\mu_i - \lambda_i}$$

Exemplo numérico (cenário nominal de malha saudável com 1000 nós):

*XDP opera em taxa de linha; não é limitado por $\mu$ na prática.

Tempo total médio: $W_{\text{total}} \approx 3.13 \text{ ms}$.

Conclusão: O Portão 4 (ZK-PoL) domina a latência do pipeline. Otimizações futuras devem focar em:

• Verificação em batch de provas Groth16.
• Caching de provas já verificadas (com invalidação por epoch).
• Offloading para GPU/acelerador ZK quando disponível.

4. Backpressure e Dimensionamento

A Lei de Little permite prever o comportamento sob spike. Se $\lambda_4$ dobra para 334 provas/s:

$$W_4 = \frac{1}{500 - 334} = 6.0 \text{ ms}$$

O tempo total dobra para ~6.1 ms. Se $\lambda_4$ se aproximar de 500, o tempo explode (assíntota vertical).

Mecanismo de backpressure: O Kernel deve monitorar $\rho_i$ de cada portão. Se $\rho_4 > 0.8$, o nó pode:

1. Aumentar o custo PAEBIRU_GATE_SECURITY_COST_MICRO_JOULES (Portão 2) para desincentivar spam.
2. Solicitar à malha (via gossip) que reduza a frequência de provas ZK (modo Coarse da Camada 9).
3. Ativar o Circuit Breaker/Febre (ver RFC futuro sobre imunologia adaptativa) para rejeitar conexões de peers com alta taxa de submissão.

5. Referências

• RFC 003 — Pipeline de Portais Ordenados (ZeroTrust).
• RFC 048 — eBPF/XDP: A Lâmina Física.
• RFC 049 — Macrophage VM.
• Little, J. D. C. A Proof for the Queuing Formula: L = λW. Operations Research, 1961.
• Kleinrock, L. Queueing Systems, Volume I: Theory. Wiley, 1975.