Whitepaper Tecnico v1

Proof of Local Trust (PoLT) — Whitepaper inicial (resumo técnico)

1. Visão geral

PoLT é um protocolo de consenso híbrido pensado para pagamentos offline + economia local, onde validadores locais (representantes comunitários) ganham poder de validação com base em Trust Score (reputação local) e colaboram com a cadeia global para evitar double-spend e manter segurança.

Objetivos principais:

  • Permitir pagamentos entre pares sem conexão contínua.

  • Preservar segurança global ao sincronizar blocos locais.

  • Incentivar participação social (voluntariado, serviços) como moeda social.

  • Ser leve para dispositivos móveis e suportar comunicações Bluetooth / mesh / QR.

2. Componentes principais

  1. Usuários (U) — portadores de wallets com chaves privadas.

  2. Validadores Locais (VL) — nós comunitários (p.ex. vendedores, ONGs, escolas) com boa Trust Score.

  3. Mininó (MN) — dispositivo móvel que cria e guarda transações locais.

  4. Bloco Local (LB) — agrupamento de transações offline assinado por um conjunto de validadores locais.

  5. Rede Global (RG) — L1/L2 principal que recebe e armazena LBs como provas.

  6. Oráculos de Confirmação (OC) — serviços (descentralizados) que verificam provas externas (ex: dados de energia, ações sociais).

  7. Ledger Global (GL) — blockchain global que registra hashes dos LBs e confirma transações finalizadas.

3. Estrutura de dados (simplificada)

Transação Offline (TO):

  • tx_id = H(pubkey_sender || nonce || amount || timestamp || metadata)

  • sender_pubkey, receiver_pubkey

  • amount

  • local_nonce (monotônico por wallet local)

  • timestamp_local

  • signature_sender

Mini-bloco local (LB):

  • lb_id = H(prev_lb_hash || timestamp || merkle_root(transactions) || validator_signatures)

  • transactions[] (list of TO)

  • validator_signatures[] (sig of each VL que aprovou o LB)

  • attestation_metadata (local group id, geo-hash opcional)

Entradas no Ledger Global:

  • registro: (lb_id, merkle_root, validator_commitment, sync_timestamp, global_signature)

4. Trust Score (TS)

Trust Score é numérico (por exemplo 0–10,000) e recalculado periodicamente.

Fontes de aumento:

  • transações validadas (peso leve)

  • tempo de operação sem reporte de fraude (peso médio)

  • avaliações P2P (votos positivos)

  • validação de oráculos externos (p.ex. participação social)

Penalidades:

  • transações revertidas por double-spend

  • taxas de disputa vencidas

  • reports com evidência

Fórmula base (exemplo):
TS_new = TS_old + α valid_tx + β uptime + γ positive_votes − δ fraud_penalties
(α,β,γ,δ parâmetros ajustáveis por governance)

Trust Score é atestado por assinaturas de múltiplos nodes e colocado no perfil do validador.

5. Fluxo de pagamento offline (alto nível)

  1. Sender cria TO, assina com chave privada.

  2. Sender transmite TO via Bluetooth/NFC/QR para Receiver.

  3. Receiver checa local_nonce + saldo local contabilizado (wallet offline mantém “estado provisório”).

  4. Um conjunto de ≥k validadores locais (por proximidade/participação) assinam a TO, formando prova local.

    • k pode variar por segurança (p.ex. 3).

  5. TO entra no LB local e é dada confirmação local (wallets podem aceitar pagamento com confirmação local).

  6. Ao reconectar, o MN (ou VL) submete LB para Rede Global.

  7. Rede Global verifica:

    • assinaturas dos validadores (e TS mínima),

    • ausência de double-spend (checa nonces e histórico global),

    • se ok → grava hash do LB no GL (finalidade).

  8. Se houver conflito (double-spend identificado), aplica regras de disputa (ver abaixo).

Observação: até sincronização, estados são provisionais; aplicações podem decidir nível de confiança aceitável (ex: loja aceita com 1 validação; mercado exige LB gravado na rede).

6. Anti–Double-Spending e resolução de conflitos

Mecanismos combinados:

  1. Local nonces: cada wallet offline mantém um contador monotônico. Validadores exigem nonce correto.

  2. Multi-sig local (k-of-n): exige assinatura de múltiplos VLs para cada TO; dificulta gasto duplicado por um único nó comprometido.

  3. Timeout & lock: quando uma TO é assinada localmente, a wallet pode publicar um temporary lock na rede (pequena prova que ocupa um espaço no GL sem custo alto) — opcional.

  4. Reconciliation on sync:

    • Ao receber LBs, RG checa para cada tx se já existe gasto globalmente.

    • Conflitos: resolve por timestamp_global + Trust Score weight dos validadores; pode reverter transações menos confiáveis ou penalizar VLs culpados.

  5. Challenge window: janela (ex: 24–72h) após LB submission onde disputas podem ser abertas; provas e testemunhas (logs Bluetooth, receipts) são aceitas como evidência.

7. Incentivos e Tokenomics

Token nativo (POLT) funções:

  • pagamento de taxas de sincronização

  • recompensa para VLs (por validação e honestidade)

  • staking para candidatar-se a VL

  • comprar reputação/votes em governance

Modelo:

  • VL stake mínimo S_min para participar.

  • Recompensa por LB validado = base_reward + fee_share.

  • Penalidade: stake slashing quando fraude comprovada.

  • Parte das taxas vai para fundo comunitário (governance local).

Monetização para fundadores/operadores:

  • reservas iniciais do token (vesting)

  • taxas de integração com empresas/merchants

  • venda de serviços de nó/hosting para regiões sem infraestrutura

8. Segurança — ameaças e proteções

Principais ameaças:

  • Sybil (criar muitos nós falsos) → mitigado por stake + verificação social + oráculos.

  • Collusão de validadores locais → mitigado por k-of-n, penalidades e verificação externa.

  • Reprodução de transações offline (replay) → nonces + timestamps + merkle proofs.

  • Ataque de sincronização adversária → nós honestos com maior TS e oráculos escalonam.

  • Falsificação de evidências → aceitar apenas provas assinadas criptograficamente (logs assinado, receipts).

Boas práticas:

  • usar ED25519 para assinaturas

  • SHA-3/Keccak para hashing

  • relógio seguro com drift mitigation (tolerância de tempo)

  • usar oráculos descentralizados para dados externos quando necessário

9. Regras de governança e parâmetros ajustáveis

  • Parâmetros (k, S_min, slashing rates, challenge window) ajustáveis via DAO local/global.

  • Governança multi-nível: decisões locais por comunidades; mudanças de protocolo por voto global ponderado por TS e stake.

10. APIs e interfaces (MVP)

  • Wallet mobile: gerar tx offline, view provisional balance, sync LB.

  • VL node: recebe TOs via BLE/mesh, verifica, assina, cria LB, submete.

  • Sync API: endpoint para enviar LB ao RG; resposta com status (accepted / rejected / dispute).

  • Explorer: view global de LBs e Trust Scores.

Exemplos endpoints (simplificados):

  • POST /lb/submit {lb, proof} -> {status, lb_hash}

  • GET /tx/{tx_id} -> {status, confirmations, lb_hash}

  • POST /dispute {evidence} -> {status}

11. Tecnologia sugerida (stack)

  • Client / Wallet: React Native (mobile), libs: libsodium / tweetnacl (crypto)

  • VL Node: lightweight Go / Rust binary (para baixo consumo)

  • Comm channels: Bluetooth Low Energy, libp2p (mesh), QR fallback

  • Global Chain: Substrate (Polkadot) ou TON/EVM-compatible as L1 — facilita criar L2 custom

  • Oráculos: Chainlink type or decentralized relay

  • Database local: SQLite (mobile) para ledger provisório

12. MVP Roadmap (prático)

  1. Semana 0–4: especificação técnica + protótipo do formato de tx + wireframes da wallet.

  2. Semana 4–12: protótipo mobile que cria TOs e envia por BLE; simples VL em NodeJS que assina.

  3. Semana 12–20: mini-rede local (3 VLs) com LB creation e sincronização para um testnet L1 (Substrate local).

  4. Semana 20–28: mecanismo de Trust Score básico e UI de avaliação P2P.

  5. Semana 28–40: stress tests offline, ataques simulados, ajustes; criar docs e whitepaper público.

  6. Lançamento pilot: 1 comunidade/região (por exemplo, um bairro ou escola) por 6 meses.

13. Casos de uso (exemplos reais)

  • micropagamentos em mercados sem internet

  • pagamentos escolares (cantina)

  • economia local entre produtores e consumidores rurais

  • programas sociais com distribuição de benefícios controlada por confiança

Resumo rápido