Protocolo OPoI

OPoI — Optimistic Proof of Inference — é como a Cloud Service paga mineradores por executar inferência de IA. Ele roda ao lado do Proof of Work: o mesmo minerador pode minerar blocos e responder requisições de IA.

Esta página documenta as regras de consenso. Para usar o chat, veja Chat de IA; para configurar mineração, veja Mineração OPoI.

O ciclo

REQUEST  →  atribuição  →  inferência  →  COMMIT  →  janela  →  REVEAL  →  pagamento
 on-chain    off-chain     off-chain     on-chain    fecha     on-chain    coinbase

O solicitante publica uma REQUEST on-chain com o nome do modelo, o hash do prompt e um pagamento declarado. O texto do prompt nunca vai para a cadeia — ele chega ao minerador por fora.

O minerador executa o modelo e publica um COMMIT: o hash da resposta mais um nonce secreto. Quando a janela de commit fecha, um minerador elegível publica o REVEAL, e a resposta se torna pública e provável.

Transações não carregam valor

Transações OPoI são obrigadas a ter entradas e saídas vazias. O consenso rejeita qualquer uma que tenha. Elas não movem fundos.

Mineradores são pagos pela coinbase do bloco, e esse pagamento precisa caber dentro do subsídio normal — ele não é somado por cima. Um bloco cuja coinbase excede o subsídio é inválido, então um payment inflado não cunha moeda; ele só torna o bloco impossível de minerar, e nenhum minerador o incluiria.

A consequência prática: o solicitante não precisa de saldo. O pagamento declarado dimensiona a fatia do minerador numa recompensa que já existe.

A janela de commit-reveal

Nenhum REVEAL é aceito antes de a janela fechar, e nenhum COMMIT depois. Fechar a fase de commit para todos na mesma altura é o que impede a cópia: enquanto os commits estão abertos, não há resposta pública para copiar.

Rede	Janela	No ritmo-alvo de bloco
Mainnet	144 blocos	~4,8 horas
Testnet	20 blocos	~20 minutos
Regtest	3 blocos	segundos

Liquidação não é entrega

A janela governa quando uma resposta se torna pública e provável — não quando quem perguntou pode vê-la. Espera-se que os clientes entreguem a resposta ao solicitante assim que o minerador a produz, deixando a liquidação terminar em segundo plano. A janela protege mineradores uns dos outros, não o solicitante da própria resposta.

Quem pode responder: sorteio VRF

Nem todo minerador pode revelar uma resposta. A elegibilidade é decidida por um sorteio ECVRF, semeado pelo hash do bloco em que a própria REQUEST foi minerada.

Esse seed nunca muda depois de minerado, o que torna a elegibilidade determinística e permanente para cada par (request, endereço). Um minerador não sorteado para uma request nunca será sorteado para ela — retentar é inútil.

Limiar adaptativo

O limiar é derivado do número de stakers ACTIVE registrado quando a request foi minerada:

limiar = 2^256 × alvo / stakers

com alvo (nOPoIVrfTargetEligible) valendo 3 por padrão — cerca de três mineradores elegíveis por request.

Isso mantém a cobertura perto de 95% em qualquer tamanho de rede. Um limiar fixo só funciona num tamanho específico: calibrado para mil mineradores, ele deixa uma rede de dez respondendo uma fração pequena das requisições — e o solicitante paga de qualquer jeito.

Stakers ativos	Limiar	Chance de a request ser respondida
10	30%	97%
25	12%	96%
100	3%	95%
1000	0,3%	95%

Adicionar endereços próprios não ajuda

Se você controla todos os stakers, a cobertura fica perto de 95% independente de quantos endereços você opere — adicionar endereços também aumenta o denominador. Mais endereços só multiplicam as transações de commit que você paga.

A contagem de stakers é congelada no bloco da própria request, nunca lida ao vivo. Uma contagem ao vivo diferiria entre a aceitação no mempool e a mineração, e entre a visão de um nó e a de outro — que é como uma cadeia racha.

Ativação: mainnet no bloco 100000 (a própria ativação do OPoI), testnet no bloco 50. Abaixo dessa altura vale o nOPoIVrfThreshold fixo. Requests são julgadas pela regra vigente quando foram feitas, por toda a sua vida.

Renovação de stake

Um staker precisa provar liveness periodicamente com uma transação RENEW. Perder o prazo deixa a stake SUSPENDED — ela continua travada, mas o consenso rejeita suas respostas até ser renovada. Nenhum colateral é confiscado.

Rede	Prazo
Mainnet	20160 blocos
Testnet	200 blocos

O prazo é em blocos, não em tempo

Uma stake envelhece no ritmo dos blocos, não no ritmo em que um temporizador dispara. Qualquer renovação agendada num intervalo fixo de tempo sai de compasso sempre que o ritmo de blocos diferir do suposto — e a falha é silenciosa: as respostas simplesmente param de ser aceitas. Derive a renovação de last_renewal_height e da altura atual.

O modelo precisa bater

Um minerador só pode responder requisições do modelo que sua stake declara. Se stake.model_id está preenchido e difere do modelo da request, o consenso rejeita o commit.

Um model_id vazio serve qualquer modelo.

Falha silenciosa

Uma divergência não produz erro visível em lugar nenhum: a request simplesmente nunca é respondida, e expira. Operadores que configuram um chat devem conferir que pelo menos uma stake ACTIVE serve o modelo escolhido antes de ligá-lo.

Vazão

Limite	Mainnet
Requests por bloco	50
Respostas por bloco	100

Com blocos de dois minutos, isso dá 36.000 requisições por dia para a rede inteira. É parâmetro de consenso — adicionar mineradores aumenta a capacidade de atender, mas não esse teto.

Expiração

Uma request PENDING que ninguém responde expira: 2016 blocos na mainnet, 200 na testnet. O pagamento declarado não é pago.