Analise de Riscos

O que da pra aproveitar da tua ideia

  • Validadores por Bluetooth — usar celulares próximos para assinar transações é plausível e torna a validação verdadeiramente local.

  • Recompensa distribuída (metade das taxas) — incentiva participação imediata e espalha valor pela rede local.

  • Hash única por transação — ter um tx_hash imutável (hash de todos os campos da tx) é essencial: evita alterações do conteúdo da transação.

Por que só um hash offline NÃO impede double-spend

Mesmo com um tx_hash imutável guardado localmente, nada impede que o mesmo remetente gere duas transações diferentes (com hashes diferentes) gastando o mesmo saldo em duas lojas distintas enquanto está offline. Ou seja: o hash protege a integridade da tx, mas não evita que o usuário gaste o saldo duas vezes — que é o problema real.

Riscos principais da tua proposta tal como está

  1. Sybil attack — qualquer pessoa cria muitos “validadores” falsos (vários telefones/emuladores) e aprova fraudes.

  2. Colusão local — comerciantes combinam para aceitar e gravar transações falsas.

  3. Recompensa inflacionária / exploração — bots emularão milhares de dispositivos bluetooth para ganhar taxas.

  4. Privacidade — logs BLE mal desenhados podem vazar encontros e hábitos.

  5. Estado provisório ambíguo — quem confia que a transação “está ok” antes da sincronização global?

Melhorias práticas (sem centralização) — propostas concretas

1) Exigir k-of-n assinaturas de validadores distintos

Em vez de 1 validador, cada transação precisa de k assinaturas de validadores distintos (“k de n”), por exemplo k = 3. Isso reduz risco de um único nó malicioso.

2) Identidade leve / limitação por unicidade

Permitimos validação por qualquer celular, mas aplicamos um filtro de unicidade para dificultar Sybil:

  • Trust Score inicial baixo para novos validadores; recompensa pequena até prova de honestidade.

  • Taxa decrescente: recompensa por validação diminui se o dispositivo valida muitas txs seguidas sem ganhar reputação.

  • Opcional: hardware attestation (SafetyNet/WebAuthn) — mantém descentralização, mas dificulta criação massiva de identidades falsas (trade-off privacidade).

3) Nonce + balance provisional + lock local

  • Cada wallet offline mantém um local_nonce monotônico. Validadores só assinam se a nonce bater.

  • Ao assinar, validadores geram um temporary lock (pequena prova que indica que aquela U gastou X) — esse lock é submetido em massa quando qualquer nó reconecta (pequena footprint on-chain). Locks ajudam a avisar outras lojas que o saldo está comprometido.

4) Merkle root dos LBs e submissão compacta

Validadores locais juntam txs num Local Block (LB) e publicam apenas o hash/merkle_root na L1 quando reconectam. Isso mantém prova imutável com custo on-chain baixo.

5) Janela de challenge e slashing comunitário

  • Após LB subir, existe uma janela de challenge (ex.: 24–72h) onde se pode abrir disputa.

  • Se fraude for provada, os validadores que assinaram perdem parte do stake ou reputação (slashing). Aqui entra a penalidade que desencoraja conluio.

6) Recompensa equilibrada (anti-exploit)

  • Não dar 50% direto a qualquer dispositivo: dividir em camadas:

    • 30% para os validadores que assinaram (dividido por TS ponderado),

    • 10% para um fundo de disputa/segurança,

    • 10% para a comunidade local (governança),

    • 50% restante para quem submete o LB à rede global (ou para o ecossistema — acordo opcional).

  • Limitar recompensa por dispositivo por período (rate limit).

7) Chaves efêmeras e privacidade

  • Validadores usam chaves efêmeras para assinar encontros Bluetooth e provam posse de chaves maiores somente ao subir LB, preservando privacidade.

Fluxo resumido (prático) — como a tx ocorreria com essas melhorias

  1. Sender cria TX (contendo sender_pubkey, receiver_pubkey, amount, local_nonce, timestamp) → tx_hash.

  2. Sender envia via BLE ao receiver. Receiver pede assinatura a validators próximos.

  3. ≥k validadores (com TS > threshold) assinam o tx_hash com chaves efêmeras. Cada assinatura inclui prova de proximidade (timestamp BLE + metadata).

  4. Validadores atualizam balances provisórios e gravam tx no LB local. Recompensas são atribuídas provisoriamente.

  5. Um nó qualquer submete LB (merkle_root + validator_signatures) ao GL quando reconecta.

  6. Rede global verifica assinaturas, TS, ausência de double-spend global (via nonces e locks) e aceita/rejeita. Janela de disputa ativa.