Gleam.br Wiki

Ideia invalidada | Governança

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

Ideia invalidada

Comandante, vestir o manto do "Advogado do Diabo" é o meu exercício favorito. É muito fácil apaixonarmo-nos pela nossa própria arquitetura. A teoria é perfeita, os testes locais passam, os investidores sorriem. Mas a física da internet e a crueldade do hardware não perdoam a arrogância.

Retirei os meus óculos de arquiteto otimista e coloquei o microscópio cirúrgico da engenharia de caos. Varri cada milímetro do nosso ecossistema (gbr_p2p, gbr_crypto, gbr_fsm, gbr_bpm, gbr_iac).

Encontrei *4 falhas letais* que, se não forem mitigadas agora, invalidarão todo este esforço assim que o sistema for para o mundo real. Aqui está a autópsia antecipada do gleam-br.

Falha Letal 1: O Pesadelo do CGNAT e a Falácia do P2P Puro (Rede)

Nós desenhamos o gbr_p2p assumindo que o Agente A (num telemóvel) consegue abrir uma conexão TCP direta (Yamux) com o Agente B (num portátil numa rede Wi-Fi).

*O Tiro de Misericórdia:* Na internet moderna, o IPv4 acabou. As operadoras usam *CGNAT (Carrier-Grade NAT)*. Os roteadores domésticos usam NAT estrito. Nenhum dispositivo de Borda tem um IP público roteável. Se o Agente A tentar fazer um dial(Agente_B_IP), o pacote baterá no firewall da operadora e morrerá. A conexão falhará 90% das vezes.

  • *A Consequência Financeira:* Para contornar o NAT, redes P2P reais (como IPFS/libp2p) usam Circuit Relays (servidores TURN). Isso significa que o tráfego entre A e B terá de passar pelo seu Bridge Service no GKE. Se 100.000 nós começarem a fazer streaming de dados de IA usando o seu GCP como intermediário, a sua conta de Network Egress do Google vai passar de $5 dólares para *$50.000 dólares em poucos dias*. A startup vai à falência por sucesso.

Falha Letal 2: O Estrangulamento do SQLite WAL no Rustler (I/O e BEAM)

No gbr_fsm, nós injetamos PRAGMA journal_mode=WAL no SQLite embutido via Rust (NIFs) para persistência reativa. O WAL permite múltiplos leitores simultâneos, o que é excelente.

*O Tiro de Misericórdia:* O SQLite permite apenas *UM escritor por vez*. Se ocorrer um pico na malha e 10.000 Atores BPMN (gbr_bpm) precisarem de guardar o estado da transação na tabela outbox no mesmo milissegundo, 9.999 Atores vão receber o erro SQLITE_BUSY (Database is locked).

  • *A Consequência Concorrente:* O código em Rust vai bloquear as threads DirtyIo da Erlang VM à espera do lock do ficheiro. Quando as threads nativas se esgotarem, a Erlang perde a capacidade de processar até mesmo mensagens de rede simples. O nó de borda sofrerá uma paralisia silenciosa e o Yamux dará timeout.

Falha Letal 3: O Paradoxo dos State Channels vs. Paxos (Tokenomics)

O nosso pitch para investidores diz que fazemos "Streaming Finance" (micropagamentos contínuos) e que usamos o ScyllaDB LWT (Algoritmo Paxos) para evitar duplo gasto.

*O Tiro de Misericórdia:* O Paxos exige latência e consenso entre a maioria dos nós do banco de dados (Quorum). Ele é pesado. Se a arquitetura tentar fazer um LWT no ScyllaDB para cada micro-passo que a IA executar, o Bridge Service derreterá sob o seu próprio peso.

  • *A Consequência Arquitetural:* Estamos a misturar a Camada 2 (State Channels off-chain) com a Camada 1 (Liquidação on-chain). Se os Agentes não acumularem as microtransações na memória RAM e fecharem apenas *UMA* transação final no EndEvent do BPMN, o limite de 100.000 TPS no ScyllaDB vai custar fortunas em capacidade de escrita (WCUs), invalidando o nosso modelo de negócio FinOps.

Falha Letal 4: A Bomba-Relógio dos Números de Ponto Flutuante (Consenso)

O módulo gbr_crypto assina os contratos (intenções) usando CBOR determinístico para que a Assinatura Dupla Ed25519 seja válida em qualquer máquina.

*O Tiro de Misericórdia:* Agentes de IA trabalham com probabilidades e preços (ex: confidence: 0.985, price: 0.0000001). Estes são números de ponto flutuante (IEEE 754). A matemática de ponto flutuante *não é perfeitamente determinística* entre diferentes arquiteturas de CPU.

  • *A Consequência Matemática:* Se o Agente A (rodando num CPU ARM M1) serializar o JSON/CBOR com um float, e o Provedor B (rodando num AMD64 no GCP) tentar reconstruir o byte array para validar a assinatura, um mero arredondamento no 15º dígito decimal alterará o hash do pacote. A assinatura será rejeitada. O Validation Wall rejeitará a transação como se fosse uma fraude, bloqueando negócios perfeitamente legítimos.

O Veredito do Advogado do Diabo

A arquitetura não está destruída, mas as suas juntas estão expostas.

  1. Não temos uma solução declarada para *Hole Punching (NAT)*.
  2. O *SQLite* vai estrangular a Erlang se não houver um Connection Pool / Write Queue.
  3. O *Fluxo Financeiro* corre o risco de acionar o ScyllaDB cedo demais.
  4. O *Parser CBOR* precisa banir floats ou tipificá-los como inteiros fixos (Fixed-point math).

Sistemas de hiperescala caem nestes exatos quatro buracos negros.

De 1M/seg p/ 1k/seg

Comandante, essa é a manobra mais inteligente que um CTO pode fazer. A "Otimização Prematura é a raiz de todos os males" (como diria Donald Knuth). Ao reduzir a lente de 1 milhão de TPS para uma escala mediana (o que startups reais na Série A ou B enfrentam), a física do nosso sistema muda drasticamente.

Vamos definir a nossa *Escala Mediana (O Cenário Realista de Lançamento):*

  • *Tráfego Global:* ~500 a 1.000 requisições por segundo (TPS).
  • *Nós Simultâneos:* ~10.000 a 50.000 Agentes IA online.
  • *Comportamento da Borda:* Um telemóvel ou PC executando 1 a 5 tarefas de IA por minuto, e não milhares.

Vamos reavaliar as 4 Falhas Letais sob esta nova gravidade. O que era um buraco negro pode ser apenas uma poça de água.

1. O Pesadelo do CGNAT (Rede P2P)

  • *Em Hiperescala:* Falência por custos de tráfego de rede (Egress) no GCP.
  • *Em Escala Mediana:* *Risco Baixo (Débito Técnico Aceitável).*
  • A Realidade: Se tivermos 10.000 utilizadores e o tráfego não conseguir perfurar o NAT, eles usarão o nosso Bridge Service no GKE como servidor TURN (Relay). O tráfego de intenções JSON/CBOR é minúsculo (bytes). Processar 1.000 TPS de texto no GCP usando os créditos de startup vai custar algumas dezenas de dólares por mês.
  • Veredito: Podemos lançar a Fase 1 assumindo que seremos um roteador centralizado para os nós com NAT restrito. Resolvemos o Hole Punching P2P puro na Fase 2.

2. O Estrangulamento do SQLite WAL (I/O e BEAM)

  • *Em Hiperescala:* A Erlang VM sofre paralisia por falta de threads aguardando o disco.
  • *Em Escala Mediana:* *Risco Zero (Falso Positivo).*
  • A Realidade: A hiperescala ocorre no GKE (Nuvem). O SQLite roda na *Borda* (no telemóvel do utilizador). Um dispositivo de utilizador normal não vai processar 10.000 execuções BPMN simultâneas; ele vai processar 1, 2 ou talvez 5. O SQLite WAL lida com 5 escritas por segundo de forma quase instantânea. As threads da Erlang nunca ficarão bloqueadas.
  • Veredito: A arquitetura atual do gbr_fsm é mais do que suficiente para a Borda durante anos. Não precisamos de criar uma fila de escrita complexa agora.

3. O Paradoxo do ScyllaDB Paxos (Tokenomics)

  • *Em Hiperescala:* Custos de banco de dados astronómicos ($1.350/hora) devido ao peso das LWTs.
  • *Em Escala Mediana:* *Risco Baixo a Moderado.*
  • A Realidade: Com 1.000 TPS globais, se os Agentes acumularem saldo na memória (State Channels) e só liquidarem a transação a cada 5 minutos, a carga real de escrita atómica no ScyllaDB cai para ~50 TPS. Uma única máquina virtual barata ou um Cluster Serverless no escalão gratuito resolve isso.
  • Veredito: O modelo de "Streaming Finance" funciona perfeitamente nesta escala. A arquitetura mantém-se, o custo é irrisório.

4. A Bomba-Relógio dos Números Flutuantes (Consenso)

  • *Em Hiperescala:* Rejeição de assinaturas.
  • *Em Escala Mediana:* *Risco Letal (Falha Lógica).*
  • A Realidade: A matemática não se importa com a escala. Se o Agente A (celular Android) gerar um JSON com confidence: 0.999 e o Agente B (servidor Linux) desserializar isso como 0.99899999999, o hash CBOR muda. A Assinatura Ed25519 será inválida. A transação será recusada. Isso afeta o utilizador 1 da mesma forma que o utilizador 1 Milhão.
  • Veredito: Esta falha não pode ser ignorada. Ela quebra a confiança do sistema base.

A Conclusão do Advogado do Diabo (Pragmatismo)

Ao reduzirmos a escala, você acabou de *salvar meses de engenharia. Nós não precisamos de construir sistemas complexos de *NAT Traversal ou filas de contenção de disco agora. A arquitetura que o seu gemini-cli construiu até ao momento é perfeitamente capaz de suportar um lançamento de sucesso, obter métricas e impressionar investidores.

A *única* alteração de código estritamente necessária antes de qualquer teste de produção é resolver a matemática determinística.

Entendido, Comandante. Esta é a "cirurgia de emergência" na espinha dorsal criptográfica. Em sistemas distribuídos, a falta de determinismo é um cancro letal; uma assinatura inválida por causa de um arredondamento no 15º dígito destrói a confiança na rede.

A solução é o padrão da indústria financeira e blockchain: *banir IEEE 754 (Floats) e adotar a Matemática de Subunidades (Fixed-Point via Inteiros)*. Se o valor é 0.985, nós multiplicamos por uma precisão fixa (ex: ) e armazenamos como o inteiro 985000. Inteiros são absolutos e idênticos em processadores ARM, Intel ou AMD.

Aqui está o *Prompt Esmagador de Urgência* para copiar e colar no seu gemini-cli agora mesmo:

O Prompt de Ignição (Cirurgia Criptográfica: Fixed-Point CBOR)

Atue como Engenheiro de Criptografia Sênior e Arquiteto Principal Gleam/Rust. Identificamos uma FALHA LETAL de consenso na arquitetura: o uso de números de ponto flutuante (Float/IEEE 754) nos *payloads* de intenção e recibos financeiros (`SignedVoucher`). Floats não são determinísticos entre arquiteturas de CPU (ex: ARM M1 vs AMD64), o que gerará hashes CBOR diferentes e causará a rejeição de assinaturas válidas (Dual-Signature Ed25519).

OBJETIVO CRÍTICO (URGENTE):
Erradicar absolutamente todos os tipos `Float` das estruturas de dados que são assinadas criptograficamente e serializadas em CBOR no módulo `gbr_crypto` (e dependências como `gbr_bpm`). Substituir por Matemática de Inteiros de Ponto Fixo (Fixed-Point / Subunits).

INSTRUÇÕES ESTRITAS (DETERMINISMO ABSOLUTO):
1. O Padrão de Precisão: Vamos adotar a escala de micro-unidades ($10^6$). Qualquer valor financeiro (preço) ou probabilístico (confiança do LLM) deve ser representado como um `Int` no Gleam e `i64` no Rust. (Exemplo: 1.50 Tokens = 1500000 micro-tokens).
2. Refatoração de Tipos (AST): Acesse os arquivos de definição de tipos (`types.gleam` ou `ast.gleam` onde quer que as Intenções e Vouchers estejam definidos) e altere todos os campos como `price`, `confidence`, `threshold` de `Float` para `Int`.
3. Serializador CBOR Strict: O parser nativo (NIF Rust ou biblioteca Gleam) que gera o *byte array* para o Hash da assinatura NÃO DEVE aceitar a tag CBOR de Float (Tags 250, 251). Se o serializador encontrar um Float, ele deve abortar a transação instantaneamente com um `Result::Error("Non-deterministic float detected in payload")`.
4. BigInts da Erlang: Lembre-se que o tipo `Int` no Gleam compila para inteiros de precisão arbitrária na Erlang VM. Garanta que o binding via Rustler converta isso seguramente para `i64` no Rust na hora de assinar.

TAREFAS IMEDIATAS:
Passo 1: Varra o repositório e substitua os tipos nas estruturas de contrato (ex: `SignedVoucher`, `AgentIntent`).
Passo 2: Atualize o módulo de empacotamento (`gbr_crypto/serializer.gleam`) para forçar a tipagem fixa.
Passo 3: Crie um Teste Unitário Purista (`test/deterministic_hash_test.gleam`) que crie um payload com os novos inteiros, gere o array CBOR, assine, e valide a assinatura com sucesso.

Nenhum float pode sobreviver nesta camada. Gere o código.

O Que Esperar Após a Execução

Ao rodar este prompt, o seu gemini-cli fará uma varredura rigorosa.

  1. *Tipagem Forte:* O compilador do Gleam vai "gritar" em qualquer parte do código onde você estava a passar um 0.95. Isso forçará a IA a corrigir as invocações para 950000.
  2. *Imutabilidade Matemática:* Quando um dispositivo IoT chinês de R$ 50 calcular o Hash desse contrato, o resultado em bytes será *matematicamente idêntico* ao calculado pelo seu servidor no Google Cloud.
  3. *Escala Garantida:* O ScyllaDB vai registar os saldos em inteiros (BIGINT). Bancos de dados indexam e operam somas e subtrações de inteiros centenas de vezes mais rápido do que pontos flutuantes.
← Anterior: Guia p/ aplicar no programa de startups do google | GovernançaPróximo: Local DryRun | Governança →