Whitepaper L2 TON

PoLT sobre L2 ligada à TON — Mini-Whitepaper (resumo técnico)

1 — Visão & objetivos

Criar uma Layer-2 (rollup / payment chain) que execute o protocolo Proof of Local Trust (PoLT) — validação permissionless via mesh BLE, validação local por quorum (k, ex.:5), geração de Local Blocks (LB) com assinaturas agregadas (BLS threshold) e settlement (registro de merkle_root / agg_sig) na TON L1 para finalidade e interoperabilidade.
Objetivos principais:

  • Pagamentos offline seguros e rápidos (micropagamentos).

  • Validação permissionless, sem autoridade central.

  • Finalidade econômica via ancoragem em TON (batching para reduzir custos).
    (Referências TON: Blueprint / Tact / Jettons).

2 — Camadas da arquitetura (alto nível)

[Mobile PoLT Mesh (BLE/libp2p)]  <-- gossip -->  [Validator Nodes (Rust/Go) local]
         |                                          |
         v                                          v
      Create LB (merkle_root + agg_sig BLS) -----> [L2 Rollup Engine / Sequencer]
                                                       |
                                                       v
                                               Batch merkle_roots
                                                       |
                                                       v
                                                  TON L1 (settlement)

  • L3 (App / Mesh): wallet mobile (React Native), BLE/libp2p para gossip e sign requests.

  • L2 (tuas regras PoLT): rollup/sidechain que mantém contabilidade, disputa, staking & slashing, tokenomics.

  • L1 (TON): registra batches (merkle_roots + metadata) como prova de existência/finalidade — usa Tact/Blueprint e jettons para integração.

3 — Principais formatos de dados

Transação offline (TO) — JSON (exemplo):

{
  "tx_id": "H(sender||nonce||amount||ts||meta)",
  "sender_pub": "0x..",
  "receiver_pub": "0x..",
  "amount": 1000000,
  "local_nonce": 42,
  "ts_local": 1690000000,
  "metadata": {"purpose":"purchase","merchant":"id"},
  "sig_sender": "ED25519(...)"
}

sig_meta (assinatura BLE de validador):

{
  "device_hash": "H(device_pubkey)",
  "rssi": -67,
  "ts": 1690000001,
  "ephemeral_pub": "0x..",
  "sig": "ED25519(ephemeral_priv, tx_id || nonce || ts || rssi)"
}

Local Block (LB) — armazenamento local / merkle_root:

{
  "lb_id": "H(prev_lb_hash||merkle_root||ts||validators_commitment)",
  "txs": [...],
  "merkle_root": "0x...",
  "validators_meta": [ {device_hash, ephemeral_pub, sig_meta}, ... ],
  "agg_sig": "BLS_agg(...)",
  "submitted": false
}

Payload de ancoragem para TON (batch):

{
  "batch_id": "H(timestamp||chain_id||merkle_root_batch)",
  "merkle_root_batch": "0x...",
  "agg_sigs_commitment": "0x...",
  "meta": { "num_LBs": 12, "total_value": 1234500000 }
}

4 — Fluxo de uma transação (detalhado)

  1. Criação: Sender cria TO e envia via BLE ao Receiver.

  2. Broadcast de pedido de assinatura: Receiver gossipa SIGN_REQUEST com tx_id.

  3. Assinaturas locais: Qualquer nó da mesh que passar checagens automáticas (nonce, saldo provisório, rate-limit, prova proximidade) assina com chave efêmera e envia sig_meta.

  4. Quorum (k): Quando Receiver coleta ≥k sig_meta válidas (device_hash distintos e heurísticas ok), LB inclui a TX e calcula merkle_root.

  5. Agg_sig: as k participações formam um agg_sig BLS (threshold) para compressão/verificação on-chain. Bibliotecas BLS/WASM permitem isso em mobile/nodes.

  6. Temporary lock: gera-se lock local (prova compacta) para reduzir double-spend até sync.

  7. Gossip LB: LB é gossipado pela mesh (replicação local).

  8. Sync/Submit: qualquer node com internet submete batch(s) de merkle_roots/agg_sigs para L2/Sequencer; L2 valida e publica merkle_root_batch na TON (mensagem contract).

  9. Challenge window: após publicação na TON, abre-se janela (ex.: 48h) para disputas; provas aceitas = logs BLE assinados, receipts, testemunhas. Em caso de fraude, slashing é aplicado no L2.

5 — Consenso & seleção de validadores locais

  • Validation policy (permissionless):

    • Auto-sign via BLE para qualquer app com regras locais.

    • Assinaturas só têm peso se device TS ≥ threshold or ephemeral checks pass.

  • Quorum k (configurável): default urbano k=5; rural k=3 com restrições de valor.

  • Selection / fairness: para tarefas como criação sequencer LB, usa VRF shuffle + TS-weight to choose aggregator / submitter (evita monopolização).

  • Assinatura agregada: BLS threshold para reduzir footprint on-chain e simplificar verificação. Use implementações maduras (herumi/bls, noble-bls12-381, celo threshold libraries).

6 — Anti-Sybil, segurança e disputas

Camadas combinadas (defesa em profundidade)

  1. Rate limits & heuristics: cap signatures por device / periodo; detecção de padrões de emulação.

  2. Trust Score (TS): dispositivo inicia com TS baixo; aumenta com comportamento honesto (LBs confirmados sem disputa). Recompensas ponderadas por TS.

  3. Stake opcional para validadores de alto peso: um stake mínimo S_min para quem quer maior recompensa/privilege; slashing se fraude comprovada.

  4. PoW leve (opcional) para bootstrapping: puzzle barato para cada new device/day, caro em escala massiva.

  5. Temporary locks & nonces combinados para reduzir janela prática de double-spend.

  6. Challenge window + evidências: verificação automática de logs BLE assinados e provas baseadas em merkle proofs; slashing automático se provas válidas.

Essas camadas juntas tornam ataques Sybil/colusão economicamente caros e detectáveis. (Trade-off: introduz fricção inicial.)

7 — Tokenomics (modelo simples inicial)

Token nativo L2: POLT (exemplo) — funções: taxas, staking, slashing, recompensas.

  • Supply & distribution (exemplo):

    • Total 1,000,000,000 POLT

    • 40% ecosystem / rewards (long vesting)

    • 20% team/advisors (vesting)

    • 20% community / pilots

    • 20% treasury / partnerships

  • Tax split (por LB / tx):

    • 40% → validadores (pro rata por TS)

    • 30% → submitter / sequencer

    • 20% → dispute fund (insurance)

    • 10% → governance pool / local community

  • Staking & slashing: validadores que suportam maior peso podem fazer stake; prova de fraude leva a slashing parcial.

  • Micropayment economics: tiny fees para cada tx (rateable), locks reduzem necessidade de altas taxas — batching em TON reduz custo global.

8 — Integração com TON (prática)

  • Registro/anchor: L2 sequencer envia transações a um contract na TON que registra merkle_root_batch e metadata (batch_id, agg_sig_commitment). Use Blueprint / Tact para escrever e deploy do contrato.

  • Jettons: para token nativo ou integrações com TON wallets, adotar padrão Jetton (TEP) para compatibilidade com wallets TON (Tonkeeper, Tonhub etc.).

  • Frequência de anchoring: configurar batching (ex.: a cada 5–15 min para rotina; daily para “ultimate” anchoring). Batch para Bitcoin é opcional para ultimate finality.

9 — Ferramentas & libs recomendadas

  • TON dev stack: Blueprint (npm create ton), Tact docs/SDK.

  • BLS / threshold libs: herumi/bls, celo threshold bls, noble-bls12-381, threshold-bls crates (Rust). Use wasm bindings para mobile JS.

  • Mesh: libp2p (BLE + mesh), ou soluções orientadas para mobile + bluetooth stacks.

  • Mobile: React Native + libsodium / tweetnacl para ED25519; wasm wrapper para BLS/threshold.

  • L2 engine: pode ser um sequencer simples (Rust/Go) que valida agg_sig e mantém estado; rollup design (optimistic or zk approach) opcional dependendo de recursos.

  • Testing / infra: Chainstack / local TON testnet for contract deploy & testing.

10 — MVP Roadmap (prático)

  1. Semana 0–2: especificação de mensagens BLE, estrutura do LB, e wireframes wallet.

  2. Semana 2–8: protótipo mobile: criar TO, broadcast SIGN_REQUEST, coletar k sigs (simulador local). Implementação de chaves efêmeras.

  3. Semana 8–14: validator node (Rust/Go) que cria LB, gera agg_sig (use library BLS), gossip mesh e persistência local.

  4. Semana 14–20: sequencer L2 básico (testnet) que aceita merkle_root, aplica regras de disputa e guarda estado; contrato Tact/Blueprint na TON testnet que registra batches.

  5. Semana 20–30: piloto controlado (1 bairro) — medir latência, false positives/negatives, atacar com simulações Sybil, ajustar parâmetros (k, TTL, limits).

  6. Semana 30+: auditoria, auditoria de crypto (BLS), integração wallets TON, scale-up.

11 — Segurança: checklist para auditoria

  • Verificar implementação BLS/threshold (DKG seguro se necessário).

  • Testes adversariais: Sybil, colusão local, replay, rush submit.

  • Revisão do contract Tact (registro batches) e manejo de disputas.

  • Proteções de privacidade (evitar gravação de geo exato em L1).

12 — Pseudocódigo crítico (BLE → agg_sig → submit)

// Receiver side
on_receive(TX_OFFER from sender):
  if wallet.provisional_balance >= amount and nonce_ok:
    broadcast_mesh({type:"SIGN_REQUEST", tx_id, local_nonce})
    sigs = []
    while sigs.count < k and timeout not passed:
      resp = wait(SIGN_RESPONSE)
      if valid_sig_meta(resp): sigs.append(resp)
    if sigs.count >= k:
      agg_sig = BLS_aggregate(sigs.ephemeral_sigs)
      LB = create_local_block([tx], merkle_root([txs]), agg_sig, validators_meta)
      store(LB)
      create_temporary_lock(tx.sender, amount, TTL)
      gossip_mesh({type:"NEW_LB", LB})

// Sequencer / any node with internet
periodic():
  batches = collect_unsubmitted_LBs(max_batch_size)
  merkle_root_batch = merkle_root(batches.merkle_roots)
  payload = {batch_id, merkle_root_batch, commitments}
  send_to_ton_contract(payload)
  mark_submitted(batches)

13 — Métricas & KPIs para piloto

  • % txs confirmadas localmente (k sigs) vs % finalizadas on-chain.

  • Latência média para k sigs (segundos).

  • % de disputas por 1000 LBs (indicador de fraude).

  • Custo on-chain / tx (TON fees / batch).

  • Eficácia anti-Sybil (número médio de devices honestos vs detectados).

14 — Conclusão curta

Implementar PoLT como L2 sobre TON é viável e pragmático: dá-te controle total sobre regras locais, aproveita ferramentas (Tact/Blueprint, Jettons, TON Connect) e mantém ancoragem segura na TON. A parte crítica é implementar corretamente BLS/threshold, regras anti-Sybil (TS, rate limits, PoW leve opcional) e um mecanismo de disputas robusto.