rfc-5 · persistence

persistence pool

versão 0.1 · atualizado 2026-04-16 · status: publicado

§1

escopo

Este documento define o Persistence Pool: contrato Solidity em Base que custodia cUSDC e compensa provider nodes por replicação auditada. Especifica a interface do contrato, o protocolo de challenge-response, a fórmula de compensação e os parâmetros governáveis via Conselho (RFC-7). Provider nodes MUST implementar respostas válidas a challenges conforme §3 para serem elegíveis a pagamento.

MUST, SHOULD, MAY seguem RFC 2119.

§2

interface do contrato

A interface canônica do Persistence Pool inclui, no mínimo:

interface IPersistencePool {
  // Um provider node se registra com região e intenção de replicar.
  function register(uint8 region) external;

  // O contrato emite um desafio de byte-range para um CID sob custódia.
  event Challenge(
    bytes32 indexed challengeId,
    address indexed provider,
    bytes32 cidHash,
    uint64 rangeStart,
    uint64 rangeEnd,
    uint64 deadlineBlock
  );

  // Provider responde com os bytes solicitados + prova Merkle.
  function respond(
    bytes32 challengeId,
    bytes calldata rangeBytes,
    bytes32[] calldata merkleProof
  ) external;

  // Epoch fecha e disbursement é computado off-chain, submetido em batch.
  function submitSettlement(
    uint64 epoch,
    bytes32 merkleRoot,
    address[] calldata providers,
    uint256[] calldata amounts
  ) external;
}

Implementações de referência estão em packages/contracts/src/PersistencePool.sol. O endereço canônico em Base Sepolia é publicado no footer da network.

§3

protocolo challenge-response

Em intervalos aleatórios (Poisson com taxa λ por nó por epoch), o contrato emite um challenge consistindo de:

challengeId — identificador único;
cidHash — hash do CID alvo sob custódia do provider;
[rangeStart, rangeEnd] — byte-range aleatório dentro do objeto;
deadlineBlock — número de bloco até o qual a resposta deve ser submetida.

Provider nodes MUST, dentro do deadline:

ler os bytes O[rangeStart..rangeEnd] dos dados armazenados localmente;
computar o Merkle proof do range contra a raiz pré-calculada do CID (árvore de chunks de 64 KiB);
submeter via respond() os bytes e a prova.

O contrato verifica a prova; resposta válida incrementa R_i do provider. Resposta ausente ou inválida a decrementa. A janela de deadline SHOULD ser curta o suficiente (tipicamente ≤ 2 minutos) para derrotar fetch inter-peer no momento do challenge.

§4

fórmula de compensação

A compensação de um provider node na epoch t é:

P_i(t) = R_i(t) · B_i(t) · W_region(i) · ρ(t)

R_i(t) ∈ [0,1] — fração de challenges respondidos corretamente na epoch.
B_i(t) — byte-horas de conteúdo replicado auditado (soma do tamanho dos objetos sob custódia × horas da epoch).
W_region(i) ∈ {0.5, 1.0, 1.5} — peso regional (§5).
ρ(t) — taxa unitária do pool na epoch: ε · S(t) / Σ_i (R_i · B_i · W_region), onde S(t) é o saldo do pool e ε a fração de desembolso por epoch.

Por construção, Σ_i P_i(t) = ε · S(t). O contrato MUST recusar settlements que violem essa conservação.

§5

pesos de região

Pesos regionais codificam escassez geográfica de custódia. Valores iniciais:

região	peso	racional
0 (padrão)	1.0	norte global — baseline
1 (baixa escassez)	0.5	regiões com >30% dos nós — pondera-se menos
2 (alta escassez)	1.5	sul global, ásia central, áfrica — pondera-se mais

A classificação regional é reavaliada a cada 6 epochs pelo Conselho, com base em mapa de distribuição pública de nós. Mudanças MUST ser anunciadas no Trust Ledger com ≥ 14 dias de antecedência.

§6

epochs e disbursement

duração de epoch padrão: 168 horas (7 dias).
fração de disbursement ε padrão: 0.10 (10% do saldo por epoch).
taxa de challenge λ padrão: 100 challenges por nó por epoch — suficiente para que a probabilidade de um provider desonesto sobreviver uma epoch seja (1 − p)^λ ≈ 10^-100 para p = 0.9.
o settlement é computado off-chain por um agregador confiável (atualmente Aevia LLC), produzindo uma Merkle root de (provider → amount); o contrato verifica a conservação e executa os pagamentos.

Parâmetros ε, λ, e duração de epoch são governáveis via Conselho (RFC-7) com processo de veto.

§7

considerações de segurança

provider desonesto: derrotado pela combinação de random byte-range + deadline curto (§3). Probabilidade de sobrevivência explicitada em §10(a) do whitepaper.
Sybil: neutralizado porque pagamento é proporcional a B_i efetivamente replicado, não à contagem de nós.
captura do agregador: uma agregadora maliciosa pode submeter settlements errados. Mitigação: settlements MUST ter prazo de contestação on-chain (ex: 72h após submissão) durante o qual qualquer provider pode submeter contra-prova. A migração para agregação descentralizada está em escopo do RFC-7.
ataque econômico via dumping de B: um ator grande poderia inflar B deprimindo ρ para operadores pequenos. Conselho pode propor fork do contrato excluindo o ator.

§8

referências

IETF RFC 2119 — Key words for RFCs
Aevia Whitepaper §5, §10, §12
RFC-2 — Content Addressing
RFC-6 — Risk Score (draft)
RFC-7 — Moderation and Ecumenical Jury (draft)
cUSDC on Base — Circle documentation
PersistencePool.sol — reference implementation