Validacao Bluetooth

O que funciona com validação automática BLE

  • Ótimo para UX: baixa fricção — o celular apenas escuta e assina.

  • Permite validação local em massa (vários aparelhos próximos podem assinar).

  • Torna fácil pagamentos ponto-a-ponto em mercados/feiras.

Riscos e ataques óbvios

  1. Sybil / bots BLE: alguém cria/emula muitos dispositivos BLE para assinar fraudes.

  2. Replay / duplicate spending: remetente cria várias transações offline gastando o mesmo saldo.

  3. Colusão local: comerciantes e dispositivos combinam pra validar transações inválidas.

  4. Falsificação de proximidade: GPS/RSSI podem ser forjados ou manipulados.

  5. Exploração de recompensa: scripts automatizados vão "ligar" milhares de validadores virtuais.

Mudanças concretas (mantendo BLE automático, mas seguro)

  1. k-of-n automáticas (ex.: k = 3)

    • A assinatura só é válida se k dispositivos distintos assinarem. O processo continua automático — o app assina por si — mas exige múltiplas assinaturas para aceitar pagamento localmente.

  2. Chaves efêmeras + comprovação de posse

    • Cada app gera chaves efêmeras (rotativas) para assinar encontros BLE. A prova da chave mestra só é revelada no sync para provar autenticidade sem expor privacidade.

  3. Prova de proximidade reforçada

    • Não confies só no RSSI. Combine: RSSI + BLE timestamp + nonce trocado entre sender/receiver + curta janela temporal. Esses elementos entram na assinatura como metadata.

  4. Rate-limits e anti-bot heuristic

    • Device cap: um dispositivo só pode assinar N txs por hora com recompensa plena; acima disso, recompensa decresce automaticamente.

    • Heurísticas locais: comportamento anômalo (padrão de assinaturas em série, sempre nas mesmas coordenadas) reduz a confiança temporária.

  5. Trust Score bootstrap + penalidade

    • Dispositivos novos começam com TS baixo; só recebem recompensa plena após prova de honestidade (ex.: 50 assinaturas confirmadas sem disputa).

    • Slashing de reputação/stake quando a rede comprova conluio.

  6. Temporary lock / provisional balance

    • Quando k assinaturas são coletadas, geramos um temporary lock (pequena prova compacta). Esse lock é o que previne uma segunda transação imediata — outras lojas veem o lock ao sincronizar parcialmente. Locks podem ser submetidos em batches à L1 (baixo custo).

  7. Submissão Merkle & janela de challenge

    • Validadores agregam txs em um LB; só o merkle_root vai pra chain quando sincronizam. Janela de disputa (p.ex. 24–72h) permite reversão e slashing com evidências.

  8. Incentivo antifraude

    • Recompensa dividida: parte para validadores, parte para quem submete LB, parte para fundo de disputa. Limitar ganho por dispositivo.

Parâmetros práticos (sugestão inicial)

  • k = 3 assinaturas de dispositivos distintos.

  • Rate limit: max 20 assinaturas recompensadas / dispositivo / dia.

  • Lock TTL (tempo que uma temporary lock é considerado válido localmente) = 30–120 minutos (ajustável por comunidade).

  • Janela de challenge = 48 horas por default.

  • TS inicial = 0; recompensa plena depois de 50 confirmações honestas.