Créditos de uso da API ZK: LLMs e além – Aplicativos

Davide Crapis e Vitalik Buterin

Um desafio central na medição de API é alcançar privacidade, segurançae eficiência simultaneamente. Isto é particularmente crítico para a inferência de IA com LLMs, onde os utilizadores submetem dados pessoais altamente sensíveis, mas aplica-se geralmente a qualquer serviço digital de alta frequência. Atualmente, os provedores de API são forçados a escolher entre dois caminhos abaixo do ideal:

1. Identidade Web2: Exigir autenticação (e-mail/cartão de crédito), que vincula cada solicitação a uma identidade do mundo real, criando enormes vazamentos de privacidade e riscos de criação de perfil.
2. Pagamentos em cadeia: Exigir uma transação por solicitação, o que é proibitivamente lento, caro e dificulta ofuscar o gráfico de transações completo do usuário.

Precisamos de um sistema onde um usuário possa deposite fundos uma vez e faça milhares de chamadas de API de forma anônima, segura e eficiente. Ao provedor deve ser garantido o pagamento e a proteção contra spam, enquanto o usuário deve ter a garantia de que suas solicitações não podem ser vinculadas à sua identidade ou entre si. Nós nos concentramos na inferência LLM como o caso de uso motivador, mas a abordagem é geral e também se aplica a chamadas RPC ou qualquer outra API de custo fixo, geração de imagens, serviços de computação em nuvem, VPNs, APIs de dados, etc.

Exemplos:

1. Inferência LLM: Um usuário deposita 100 USDC em um contrato inteligente e faz 500 consultas em um LLM hospedado. O provedor recebe 500 solicitações pagas válidas, mas não pode vinculá-las ao mesmo depositante (ou entre si), enquanto os prompts do usuário permanecem desvinculados da identidade do usuário.
2. RPC Ethereum: Um usuário deposita 10 USDC e faz 10.000 solicitações para um nó Ethereum RPC (por exemplo, eth_call / eth_getLogs) para alimentar uma carteira, indexador ou bot. O provedor RPC está protegido contra spam e pagamento garantido, mas não pode correlacionar as solicitações em um perfil de usuário persistente.

Visão geral da proposta: Aproveitamos os Nulificadores de Limite de Taxa (RLN) para vincular o anonimato a uma participação financeira: usuários honestos que permanecem dentro dos limites do protocolo permanecem invinculáveis, enquanto usuários que gastam o dobro (ou excedem sua capacidade permitida) revelam criptograficamente sua chave secreta, permitindo cortes. Projetamos o protocolo para funcionar quando o uso da API incorre em custos variáveis, mas ele também suporta diretamente o custo fixo por chamada mais simples como um caso especial.

Usamos um protocolo de contabilidade flexível no qual cada solicitação define antecipadamente um custo máximo por chamada e, uma vez determinado o custo real no final da chamada, o servidor emite um reembolso. Os usuários acumulam de forma privada tíquetes de reembolso assinados para recuperar créditos não utilizados e desbloquear capacidade futura, mesmo quando o custo real por chamada só é conhecido após a execução. Um mecanismo Dual Stake permite que o servidor aplique políticas de conformidade enquanto permanece publicamente responsável.

Protocolo de crédito de uso da API ZK

O protocolo utiliza reembolsos de servidor emparelhado com acumulação de reembolso e uma prova de solvência do lado do cliente. O modelo reforça a solvência ao exigir que o usuário prove que seus gastos cumulativos – representados por seus gastos atuais índice de tickets—permanece estritamente dentro dos limites do seu depósito inicial e do seu histórico de reembolso verificado.

A proteção anti-spam é aplicada de forma econômica: o rendimento de um usuário é naturalmente limitado pelo buffer de depósito disponível, enquanto qualquer tentativa de reutilizar um índice de ticket específico (gasto duplo) é evitada pelo Rate-Limit Nullifier.

Primitivos

• k: Chave secreta do usuário.
• D: Depósito Inicial.
• C_{máx}: o custo máximo por solicitação (deduzido antecipadamente).
• eu: O Índice de Tickets (Um contador estritamente crescente: 0, 1, 2, \pontos).
• \{r_1, r_2, \pontos, r_n\}: Uma coleção particular de tickets de reembolso assinados e recebidos do servidor.

Fluxo de protocolo

Cadastro
O usuário gera segredo kderiva um compromisso de identidade ID = hash(k)e depósitos D no contrato inteligente. O contrato insere EU IA na Merkle Tree on-chain.

Cobrança de reembolso (assíncrona)
Depois que uma solicitação é processada, o servidor fornece um tíquete de reembolso assinado r = \{v, \text{sig}\}onde v é o valor do reembolso e \text{sig} é a assinatura do servidor v (e potencialmente um ID de solicitação exclusivo). O usuário os armazena localmente.

Geração de solicitação (paralelizável)
O usuário escolhe o próximo índice de tickets disponível eu. Eles podem gerar múltiplas solicitações (por exemplo, tickets eu, eu+1, eu+2) simultaneamente.

O usuário gera um ZK-STARK \pi_{requisito} provando:

1. Associação: ID \in MerkleRoot.

2. Soma do reembolso:
   O circuito leva a lista de passagens com reembolso \{r_1, \pontos, r_n\} como insumos privados.

   • Para cada bilhete, o circuito:
     • Verifica a assinatura do servidor.
     • Extrai o valor v_j.
   • O circuito calcula a soma: R = \soma_{j=1}^{n} v_j.

3. Solvência (a verificação de crédito): O gasto potencial total no índice eu é coberto pelo depósito mais a soma de todos os reembolsos verificados:

   (i + 1) \cdot C_{max} \le D + R.

4. Compartilhamento e anulador RLN:

   • Declive: uma = Hash (k, eu).
   • Sinal:
     • x= Hash(M),
     • y = k + a\cdot x.
   • Anulificador: Anulificador = Hash(a).

Submissão

O usuário envia: Carga útil (M) + Nulificador + Sinal (x, y) + Prova.

Verificação e redução
O Servidor verifica o Nullifier em seu banco de dados de “Tickets Gastos”:

• Verificação de garfo/gasto duplo: Se o Nullifier existir com um diferente x (Mensagem), o usuário tentou gastar o mesmo ticket em duas solicitações diferentes. Resolva para k e SLASH.
• Verificação de solvência: Verificar \pi_{requisito} para garantir o índice do ticket eu é autorizado pelo nível de financiamento atual do usuário.

Povoado

• Servidor executa solicitação.
• Reembolso: Servidor emite um ticket de reembolso assinado r = (C_{máx} – C_{real}).
• O usuário adiciona R ao seu acumulador para “desbloquear” índices de tickets mais altos para uso futuro.

Responsabilidade do lado do servidor (estacionamento duplo)

Para impedir o abuso da API além da simples limitação de taxa (por exemplo, violação dos Termos de Serviço, geração de conteúdo ilegal ou tentativas de jailbreak), introduzimos uma camada secundária de piquetagem. Por exemplo, um usuário pode enviar um prompt solicitando ao modelo que gere instruções para a construção de uma arma ou para ajudá-lo a contornar os controles de segurança – solicitações que violariam as políticas de uso de muitos fornecedores. Gostaríamos de encontrar uma forma de aplicar tais políticas sem dar ao fornecedor uma forma simples de lucrar com falsos positivos.

Concretamente:

O usuário deposita uma quantia total Total = D + S.

• D (Estaca RLN): Governado pela matemática do protocolo. Pode ser reivindicado por qualquer um (incluindo o Servidor) que fornece prova matemática de sinalização dupla (segredo revelado k).
• S (Aposta Política): Governado pela política do servidor. Pode ser cortado (queimado), mas não reivindicadopelo Servidor se o usuário violar as políticas de uso.

O propósito de fazer isso, em vez de simplesmente definir D maior, é remover o incentivo do servidor para retirar fraudulentamente os depósitos dos usuários, o que pode ser alto dependendo do valor do depósito.

Mecanismo de corte para S

Se um usuário enviar uma solicitação RLN válida que viole a política (mas não acione a armadilha matemática de gasto duplo):

1. Violação: O servidor detecta violação de política na carga útil da solicitação (por exemplo, conteúdo proibido).
2. Gravar transação: O Servidor chama um slashPolicyStake() função no contrato inteligente.
   • Entrada: O Nullifier do pedido ofensivo e do ViolationEvidence (hash/motivo opcional).
   • Ação: O contrato queima valor S do depósito do usuário.
   • Restrição: O servidor não pode alegar S por si só, ele é enviado para um endereço de gravação. Isso evita que o servidor seja incentivado a banir falsamente usuários com fins lucrativos.
3. Responsabilidade Pública: O evento de corte é registrado na cadeia com o associado Nullifier. Embora a identidade do usuário permaneça oculta, a comunidade pode auditar o avaliar em que o Servidor queima as apostas e as evidências publicadas para essas queimadas.