Regras de Seguranca

Regras e mecanismos para validação permissionless e segura (resumo prático)

1 — Regra principal: validação permissionless + camadas de segurança

Qualquer app/dispositivo pode assinar automaticamente via BLE, mas a assinatura só tem peso se obedecer a regras que impedem Sybil, colusão e replay. Peso = capacidade de gerar agg_sig que torne a transação localmente confirmada.

2 — Regras obrigatórias (checagens que cada validador realiza automaticamente antes de assinar)

  1. Verificação do nonce local do sender — rejeitar se nonce inválido.

  2. Checagem de saldo provisório (wallet offline) — garantia mínima de fundos.

  3. Rate-limit local — o dispositivo só assina N txs recompensadas por hora/dia.

  4. Prevenção replay — aceitar só tx_hash que não exista no cache local de 24–72h.

  5. Prova mínima de proximidade — incluir RSSI + timestamp + nonce trocado e assinado.

  6. Chave efêmera obrigatória — assinar com chave rotativa; relação efêmera→longterm só é provada na sync.

3 — Anti-Sybil combinatório (sem KYC central)

Use três mecanismos simultâneos para dificultar criação massiva de identities:

A) Trust Score leve (TS_bootstrap)

  • Novo dispositivo começa com TS baixo. TS sobe com comportamento honesto (txs assinadas que entram no GL sem disputa). TS baixa com disputas/slashing.

B) Rate limits + heurísticas

  • Hard caps (e.g., 20 assinaturas recompensadas/dia).

  • Heurísticas detectam padrões de emulação (mesmas coordenadas, mesma hora, assinatura idêntica).

C) Proof-of-work/effort alternativo opcional

  • Para quem quer spamar: exigir um pequeno PoW (p.ex. puzzle leve) antes da primeira assinatura do dia — barato para humanos, caro em escala massiva.

Esses três em conjunto tornam bot-farms caras e detectáveis sem fechar a rede.

4 — Requisito de quorum dinâmico (k-of-n) e diversidade

  • Definir k mínimo (p.ex. k=5 padrão urbano).

  • Exigir device diversity: os k assinantes devem ter device_id_hash distintos; não aceitar assinaturas de um único fabricante/emulador detectado.

  • k pode ser dinâmico: se densidade baixa, baixar k (ex.: k=3) mas exigir TS mínimo mais alto + limites de valor transacionado.

5 — Compactação de assinaturas e submissão eficiente

  • Usar threshold/BLS para agregar k assinaturas em 1 agg_sig (eficiente on-chain).

  • Validadores só enviam agg_sig+merkle_root do LB à L1 quando sincronizam.

6 — Locks provisórios e prevenção de double-spend

  • Quando agg_sig com k assina, gerar temporary lock local (pequena prova com TTL, p.ex. 30–90 min).

  • Locks são submetidos em batches para L1 (pequenas footprints) para avisar o mundo que saldo foi comprometido.

  • Ao tentar outra tx, wallets verificam locks recebidos recentemente.

7 — Dispute window, provas e slashing

  • Janela de challenge (ex.: 48h) depois que um LB é publicado.

  • Em caso de disputa, aceitar provas: logs BLE assinados, receipts, testemunhas (outros devices).

  • Penalizar validadores culpados com slashing de reputação e perda de recompensa. Slashing automático se provas criptográficas forem válidas.

8 — Incentivos alinhados (recompensa e cortes)

  • Recompensa dividida: exemplo prático

    • 40% para validadores que assinaram (peso TS ponderado)

    • 30% para quem submete o LB à rede global (incentiva sync)

    • 20% para fundo de disputa / seguro (cobrir chargebacks)

    • 10% para comunidade local (governance)

  • Limitar ganho por dispositivo (daily cap) evita exploração.

9 — Privacidade e chaves

  • Validadores usam chaves efêmeras para assinaturas BLE; só provas necessárias são reveladas na sincronização.

  • Não gravar localização precisa no GL — usar geo-hash grosseiro ou apenas prova de proximidade (RSSI/time) para evitar vazamentos.

10 — Parâmetros iniciais sugeridos (ajustáveis via governance)

  • k padrão urbano = 5

  • k rural = 3 (com restrições de valor)

  • Rate limit por device = 20 assinaturas recompensadas/dia

  • Temporary lock TTL = 30–90 minutos

  • Janela de challenge = 48 horas

  • TS bootstrap: recompensa plena após 50 txs confirmadas sem disputa

11 — Fallbacks e usabilidade

  • Se não há k suficientes, wallet mostra “esperando validação” ou oferece aceitar com k menor mas cobrando taxa extra/limite de valor.

  • Merchants podem indicar um threshold local aceitável (por exemplo: aceitar txs com k=3 para compras < X Kz).

12 — Monitoramento e auditoria descentralizada

  • Ferramentas públicas para visualizar LBs, TS agregados e disputas ajudam a detectar padrões de abuso.

  • Bots de auditoria descentralizados (curadores) podem sinalizar regiões com alto risco.

Trade-offs resumidos

  • Segurança ↑ com mais regras (k alto, TS, slashing) — mas UX pode degradar em locais de baixa densidade.

  • Sistema permissionless + defenses probabilísticas (rate-limits, PoW leve, TS) é o melhor caminho para manter abertura sem instituição central.