Consenso k-of-n

Validação com 5 dispositivos (k = 5) — como tornar seguro e prático

1) Regra básica

  • Uma transação offline só é considerada localmente confirmada se pelo menos 5 dispositivos distintos próximos assinarem o tx_hash.

  • Cada assinatura é feita automaticamente pelo app via Bluetooth (chave efêmera).

Isso por si só aumenta a resistência a ataques (um único dispositivo malicioso já não basta). Mas precisamos de camadas extras.

2) Medidas essenciais para evitar ataques

A — Diversidade obrigatória

Exigir que os 5 validadores venham de identidades distintas e idealmente com distância/assinatura RSSI variada. Não pode aceitar 5 assinaturas do mesmo IP/emulador.
Implementação prática:

  • cada assinatura inclui device_id_hash + rssi + timestamp + nonce.

  • rejeitar assinaturas com mesmo device_id_hash (ou muito semelhantes).

B — Chaves efêmeras + prova de entidade

  • Cada app gera chaves efêmeras rotativas (por exemplo, trocam diariamente).

  • As chaves efêmeras são assinadas por uma chave de longo prazo do app (guardada no dispositivo). Ao sincronizar, só se revela prova da relação efêmera→long_term sem expor a private key.

C — Threshold signatures (BLS) para compactar

  • Em vez de enviar 5 assinaturas separadas para a chain, usa-se BLS threshold signatures: as 5 assinaturas combinam-se num único agg_sig.

  • Vantagem: economia de espaço on-chain e verificação única.

D — Rate limits e heurísticas anti-bot

  • Cada dispositivo só pode assinar X txs recompensadas por hora/dia.

  • Comportamentos anormais (muitas assinaturas desde mesmas coordenadas) reduzem temporariamente confiança.

E — Temporary lock + local nonce

  • Quando a transação coleta k=5 assinaturas, gera-se um temporary lock (pequena prova assinada) que previne gasto imediato do mesmo saldo por outro vendedor local que reconcilie logo em seguida.

  • Wallet mantém local_nonce monotônico e só permite nova tx se nonce avançou.

F — Trust Score e slashing leve

  • Dispositivos têm TS inicial baixo; ganham TS com LBs honestos.

  • Se um LB contiver fraude, os validadores que assinaram perdem parte do TS / recompensa.

G — Janela de challenge

  • Após submissão do LB global, abrir uma janela (ex.: 48h) pra disputas. Se alguém provar double-spend, aplicar slashing.

3) Fluxo proposto (k=5) — passo a passo curto

  1. Sender cria tx e tx_hash.

  2. Sender envia via BLE ao Receiver.

  3. Receiver broadcast pedido de assinatura local com tx_hash + nonce.

  4. App dos dispositivos próximos (auto) verifica saldo provisório local e, se OK, assina tx_hash com chave efêmera e retorna sig_meta (device_hash, rssi, ts).

  5. Quando já tiver 5 sig_meta válidas (de device_hash distintos e rssi coerente), o Receiver marca a tx como locally confirmed e gera temporary_lock.

  6. Um nó local ou qualquer participante submete o LB (contendo a tx e agg_sig BLS) à Rede Global quando conectar.

  7. Rede Global verifica: agg_sig, TS dos validadores (mínimo), nonces globais; grava merkle_root do LB; janela de challenge abre.

4) Como lidar com disponibilidade (se nem sempre há 5 devices por perto)

  • Fallbacks:

    • aceitar k=3 em locais rurais com maior trust_score mínimo e menor valor transacionado.

    • aceitar validação de trusted anchors (p.ex. pontos fixos como lojas grandes) se a região não tiver massa crítica — porém só como exceção configurável por comunidade.

  • Parâmetro dinâmico:

    • k pode ser ajustado por governance local (k=5 padrão em zonas urbanas; k=3 em zonas rurais).

5) Parâmetros sugeridos iniciais

  • k = 5 (padrão urbano).

  • Rate limit por device: 20 assinaturas recompensadas / dia.

  • Temporary lock TTL: 30–90 minutos.

  • Janela de challenge: 48 horas.

  • TS mínimo para validators que participam em agg_sig: > threshold_low (ex.: 100/1000).

6) Trade-offs importantes

  • Segurança aumenta com k, mas UX piora (pode demorar mais pra encontrar 5 devices).

  • Threshold signatures resolvem o custo on-chain, mas adicionam complexidade de implementação.

  • Mecanismos anti-Sybil (TS, rate limits, opcional stake) introduzem alguma fricção no onboarding.