zkAPI da Ethereum esconde quem paga pela IA. Mas o modelo ainda vê o prompt

A Fundação Ethereum e o Open Anonymity Project lançaram o zkAPI na mainnet da Ethereum em 1º de outubro. Um usuário pode depositar créditos e provar que uma solicitação posterior de API de IA foi paga sem fornecer ao servidor de pagamento uma identidade ou ao provedor do modelo o endereço de financiamento. O provedor ainda recebe o prompt. Essa separação é útil, mas é uma alegação de privacidade mais restrita do que uma conversa anônima com um modelo.

O anúncio técnico da Fundação Ethereum é excepcionalmente explícito sobre o limite. A prova oculta qual nota paga pelo uso, enquanto o provedor opera o modelo e vê a solicitação. Ele também nomeia metadados de rede e conteúdo do prompt como fontes remanescentes de correlação. Isso importa porque a frase pagamentos privados de IA pode facilmente ser entendida como uso privado de IA.

O projeto está ativo, segundo a Fundação, com um repositório público no GitHub, um cofre na mainnet contendo créditos USDC e uma interface de chat de demonstração vinculada em seu anúncio. A implantação ativa estabelece que há código e um contrato para inspecionar. Isso não estabelece adoção por usuários, o escopo de uma auditoria de segurança, anonimato em todas as configurações de cliente ou proteção contra um provedor que reconhece a escrita e os documentos de um usuário.

Um depósito substitui uma trilha de faturas de API

A maioria das APIs comerciais de IA conecta uma chave a uma conta e a um método de pagamento. O provedor pode associar solicitações a uma identidade de cobrança, mesmo que um usuário nunca assine o prompt com um nome. O zkAPI introduz um cofre financiado e uma nota privada. Um usuário deposita ativos suportados, como USDC, em um contrato; o software na máquina do usuário posteriormente produz uma prova de conhecimento zero de que uma nota financiada válida pode pagar por uso limitado sem divulgar qual nota é.

O servidor de pagamento verifica a prova e emite uma chave de API de curta duração, com limite em dólares. No modo direto de chave de tempo de execução descrito pela Fundação, os prompts vão do dispositivo do usuário para o provedor de IA com essa chave. Após a sessão, um recibo assinado registra o uso medido, e o saldo privado é cobrado pelo valor usado, em vez de simplesmente o limite reservado. Uma prova pode cobrir uma sessão de múltiplas solicitações.

Isso evita colocar cada solicitação de modelo na Ethereum. A cadeia vê depósitos, encerramentos e saques do cofre, enquanto o servidor verifica provas de gasto offchain. O provedor do modelo vê o texto e o tráfego da API. O servidor de pagamento vê evidências de que a sessão está financiada e o valor total da cobrança, mas no modo direto não recebe o prompt. Essas são alegações sobre a arquitetura descrita, não prova de que os logs ou a configuração de rede de uma implantação específica nunca possam correlacionar usuários.

Há um modo proxy mais simples. Nele, o servidor zkAPI retransmite a solicitação do usuário para o provedor do modelo. Esse servidor pode ver o tráfego, segundo a Fundação. Uma pessoa decidindo entre os modos deve perguntar em qual parte ela confia o conteúdo e qual delas só precisa validar uma prova de pagamento. Uma interface local que parece idêntica pode encaminhar solicitações de maneira diferente nos bastidores.

A nota prova valor sem nomear seu depositante

A construção criptográfica usa compromissos em uma árvore de Merkle. Uma prova diz que a nota do usuário está entre as notas financiadas válidas sem identificar sua folha. Um nullifier, derivado de um segredo da nota, impede que o mesmo saldo seja gasto duas vezes. A Fundação nomeia provas Groth16 em BN254 e hashes Poseidon, com uma árvore de 32 níveis. Esses detalhes importam para implementadores, mas o princípio financeiro é mais simples: verificar a associação e a autoridade restante para gastar sem publicar a conta que forneceu o crédito.

O usuário não obtém uso gratuito ocultando uma identidade. O servidor deve verificar a prova de gasto e reservar um limite antes de emitir a chave temporária. O provedor mede o uso. O recibo liquida o valor real após a chave expirar. Se um limite de $10 for reservado e $3 de serviço forem consumidos, o sistema deve cobrar $3, não $10. Esse exemplo ilustra a lógica de reserva, não um preço publicado ou mínimo garantido. O saldo restante permanece na nota privada sujeito às regras da implementação.

O nullifier aborda uma falha específica: uma tentativa de gastar uma nota duas vezes. Ele não prova que o modelo de IA respondeu com precisão, não preserva a confidencialidade do prompt, nem impede o provedor de registrar solicitações. Uma prova de conhecimento zero é uma declaração sobre a validade de uma transação sob um circuito definido. Suas garantias não se expandem automaticamente para outros dados que se movem junto com a transação.

O caminho de saída do contrato também importa. A Fundação diz que um usuário pode fechar o saldo do cofre e sacar onchain mesmo se os servidores zkAPI desaparecerem. Isso evita tornar o servidor de pagamento a única rota para recuperar fundos. Não torna as saídas invisíveis: o Ethereum registra as transações relevantes. A capacidade do usuário de sair depende do contrato e da posse do segredo necessário, e um usuário prudente deve inspecionar endereços de implantação, permissões e qualquer revisão independente antes de atribuir grande valor ao mecanismo.

O provedor pode reconhecer o que a prova não pode revelar

A prova de pagamento pode ocultar uma fonte de financiamento enquanto o corpo da solicitação contém o nome de uma pessoa, empregador, histórico médico ou código proprietário. Um provedor de modelo que lê o prompt pode vinculá-lo a sessões anteriores usando frases repetidas, arquivos enviados, histórico de conversa ou fatos altamente distintivos. Nenhum vínculo de carteira é necessário. Um prompt sobre um produto não publicado com o mesmo nome interno de projeto em três sessões é seu próprio identificador.

Metadados de rede fornecem outro caminho. No modo de chave de tempo de execução, o provedor pode ver o endereço IP do qual o dispositivo se conecta. No modo proxy, o intermediário pode ver o tráfego e potencialmente suas informações de rede de origem. A Fundação diz explicitamente que um IP estável e timing correlacionado podem enfraquecer a privacidade, e sugere ferramentas de anonimato de rede para usuários que buscam proteção mais forte. Uma VPN ou Tor pode alterar o caminho da rede, mas nenhum remove um nome digitado no prompt.

Há um teste de privacidade em três camadas. A privacidade de pagamento pergunta se uma conta pode ser vinculada a uma nota de financiamento ou pessoa. A privacidade de rede pergunta se o serviço pode identificar uma conexão por IP, timing ou características do dispositivo. A privacidade de conteúdo pergunta se qualquer pessoa que opera o modelo pode ler o prompt. O zkAPI é projetado principalmente para a primeira camada. Ele pode reduzir um vínculo em nível de conta entre o log de uso do provedor do modelo e a fonte de pagamento do usuário. Ele não entrega as outras duas por si só.

Isso não é um defeito escondido nas letras miúdas. O próprio anúncio do projeto diz que o provedor vê as solicitações. A descrição honesta é mais forte do que um slogan de anonimato expansivo porque diz aos usuários onde focar precauções adicionais. Uma pessoa que usa o serviço para fazer perguntas genéricas pode ganhar desvinculação de pagamento substancial. Uma pessoa que cola um contrato assinado e um nome completo divulgou identidade no conteúdo, independentemente da rota de pagamento.

O conjunto de anonimato pode ser pequeno mesmo com provas sólidas

Conhecimento zero pode ocultar qual de várias notas pagou, mas a multidão prática importa. Se apenas um usuário financia um cofre em uma janela de tempo estreita com um valor de depósito incomum, e uma retirada igualmente distintiva segue uma sessão, um observador pode formar uma correlação plausível a partir do timing e valores públicos. A prova pode permanecer criptograficamente válida e intacta. A inferência a partir de informações externas é um ataque separado.

A árvore de 32 níveis é um parâmetro de capacidade no design, não evidência de que bilhões de usuários distintos estão misturando seus créditos hoje. Um serviço recém-lançado pode ter um pequeno conjunto de notas financiadas. Para avaliar o anonimato na prática, seria desejável ter contagens datadas de depósitos, notas ativas distintas e padrões de retirada, com agregação consciente da privacidade. Um repositório ou tamanho teórico da árvore não fornece esses números.

Suponha que dez notas sejam elegíveis para uma sessão e fatos públicos eliminem nove delas. A prova matemática ainda pode esconder sua testemunha perfeitamente, enquanto as informações ao redor apontam para a décima. Este exemplo de brinquedo explica por que o tamanho e a diversidade do conjunto plausível importam mais do que o número bruto de transações no cofre. A padronização de valores, a atividade atrasada e o uso regular podem ajudar, mas o comportamento do usuário e o design do serviço determinam o que está disponível para correlacionar.

Há um segundo tipo de conjunto no provedor de IA: o grupo de requisições que compartilham uma chave de curta duração. A chave pode vincular requisições dentro de sua sessão limitada, mesmo que não consiga identificar o depósito. Isso é inerente à medição de uma sessão. Se o cliente enviar repetidamente os mesmos documentos em sessões posteriores, o provedor pode vinculá-los entre chaves também. Ocultar a conta de cobrança é valioso, mas não obriga o provedor a esquecer o que leu.

Desenhe os registros para uma única sessão sem assumir que alguém trapaceia. O Ethereum registra a transação de depósito e seu endereço de financiamento. O dispositivo do usuário retém o segredo da nota e envia uma prova ao servidor de pagamento. O servidor registra a validade da prova, um nullifier e um evento de emissão para uma chave limitada. O provedor do modelo registra essa chave, as requisições e o uso que cobrou. O recibo assinado vincula a chave a um total medido. No encerramento, o contrato pode registrar uma saída. Cada parte tem um livro-razão parcial.

A propriedade de privacidade pretendida é que nenhum livro-razão de uma única parte honesta ligue diretamente o endereço de financiamento aos prompts do provedor. Uma coalizão, vazamento de dados ou observador externo com carimbos de data/hora pode ter mais informações. Se um usuário depositar um valor incomum e imediatamente enviar uma única requisição incomum, correlacionar eventos pode se tornar mais fácil. Se um provedor receber um documento que identifica o usuário, ele pode saber quem perguntou, apesar de nunca ter visto o endereço do cofre. Este é um problema de composição, não uma prova de conhecimento zero falha.

O exercício do livro-razão também expõe a importância dos tempos de vida das chaves. Uma credencial de sessão agrupa deliberadamente todas as requisições que autoriza para que um provedor possa medi-las. Um limite de $50 pode permitir muitos prompts sob uma única chave. Limites mais baixos e sessões mais curtas podem reduzir quanto conteúdo é vinculado dentro de uma credencial, mas exigem provas mais frequentes e podem adicionar latência ou despesa. Não há configuração universalmente privada; o usuário e o provedor escolhem entre conveniência, custo e capacidade de vinculação.

Um modelo de ameaça público deve nomear exatamente quais registros são retidos e por quanto tempo. Deve dizer se o servidor registra endereços IP de origem durante o envio da prova, se armazena nullifiers indefinidamente e se o provedor pode associar identificadores de recibo ao conteúdo da requisição após a liquidação. Excluir um nome de cobrança de um banco de dados é útil. É insuficiente se um identificador de dispositivo persistente recriar silenciosamente o mesmo perfil.

Um recibo de uso assinado move a confiança para a medição

O provedor ou servidor precisa de uma maneira de cobrar pelo trabalho realmente realizado. O design usa um recibo assinado associado à chave de curta duração e seu uso. Isso desloca uma questão comercial central para a precisão da medição. Se um provedor contar tokens, requisições ou tempo a mais, uma prova de pagamento válida não pode corrigir a conta subjacente. A assinatura torna um total declarado difícil de reescrever posteriormente; ela não estabelece que o uso declarado foi justo sob a tabela de preços do provedor.

Um cliente deve perguntar qual unidade é cobrada, quem assina o recibo, como a reserva não utilizada é liberada e o que acontece quando uma requisição falha no meio do caminho. Estas são perguntas comuns de cobrança em roupas criptográficas incomuns. Um limite limita o tamanho de uma cobrança inesperada em uma sessão, mas muitas sessões pequenas ainda podem acumular custo substancial. Limites de taxa e faturas podem precisar de um processo de disputa que preserve a privacidade.

O trade-off é operacional. Contas de API tradicionais simplificam o suporte ao cliente, reembolsos e investigação de abuso porque um provedor pode identificar o comprador. O zkAPI remove uma identidade de cobrança persistente do caminho de pagamento pretendido. Os provedores ainda podem precisar de controles de abuso, triagem de sanções quando aplicável e aplicação de uso. A Fundação diz que preços e limites de taxa podem permanecer, mas integrações reais mostrarão como os serviços equilibram pagamentos sem conta com suas obrigações e controles de fraude.

Um teste prático é uma sessão deliberadamente interrompida. O cliente obtém uma chave limitada, faz várias requisições, perde acesso à rede e depois se reconecta. O recibo reflete apenas o uso entregue? Um usuário pode auditar o valor medido localmente sem enviar o prompt ao servidor de pagamento? Se o servidor desaparecer, o usuário pode recuperar o saldo não utilizado através do contrato conforme anunciado? Esses testes vão além de verificar se uma prova é válida para verificar se o produto preserva a separação prometida em caso de falha.

O contrato onchain é uma rota de escape, não um escudo de privacidade

O contrato do cofre pode verificar provas para operações de depósito, fechamento e escape, de acordo com a Fundação. Uma rota de saída onchain é importante porque um desligamento do provedor não deve deixar fundos dos usuários presos em um banco de dados do operador. O contrato substitui parte da confiança institucional por risco de contrato inteligente. Um bug na verificação de provas, na contabilidade ou na lógica de saque pode afetar os fundos, apesar de um conceito de privacidade sólido. Um endereço ativo é evidência de implantação, não um certificado de auditoria.

Depósitos e saques públicos também têm um custo de privacidade. Alguém que conhece o endereço de financiamento de um usuário pode observar que ele interagiu com o cofre. Essa pessoa pode não ver qual sessão de API foi paga, mas pode ver a participação e os valores. Se o mesmo usuário sacar rapidamente um valor incomum para um endereço já associado a ele, parte do anonimato ao redor pode diminuir. A nota privada quebra um vínculo determinístico de cobrança; ela não apaga a transação pública de financiamento.

O projeto tem raízes em um design de créditos de API com conhecimento zero no Ethereum Research, que a Fundação identifica como trabalho de Davide Crapis e Vitalik Buterin. Uma proposta de pesquisa e um sistema em produção respondem a perguntas diferentes. A primeira estabelece uma construção; o segundo deve lidar com armazenamento de chaves, comportamento do front-end, interrupções, disputas de recibos, atualizações e adversários reais. O lançamento de 1º de outubro move a ideia para uma implantação testável, e esse é o gancho relevante e novo.

Os esforços mais amplos de privacidade do Ethereum não são o mesmo produto. A cobertura do Crypto.news sobre um design nativo de privacidade proposto diz respeito a uma mudança de protocolo em rascunho, enquanto o zkAPI é um aplicativo em execução agora. O recente lançamento da carteira zk.money diz respeito a transferências privadas em outro ambiente. Nenhum dos dois deve ser citado como evidência de que um prompt de IA enviado através do zkAPI está oculto de seu provedor de modelo.

As alegações de privacidade devem sobreviver a um teste reproduzível

Um revisor independente poderia criar duas notas financiadas a partir de endereços não relacionados, emitir sessões curtas com o mesmo provedor de modelo e inspecionar cada pacote e log visível ao cliente, ao servidor de pagamento e ao provedor. O revisor deve testar os modos direto e proxy separadamente. Se o servidor de pagamento no modo direto receber um prompt, isso contradiz a separação descrita. Se o provedor receber um endereço de depósito ou um identificador durável de conta de cobrança, a desvinculação pretendida falhou na camada de integração, mesmo que o circuito de prova seja sólido.

O teste mais difícil é estatístico. Execute muitas sessões com valores e tempos variados e, em seguida, pergunte se uma parte com apenas dados públicos da chain e logs do servidor consegue correlacionar financiamento e uso melhor do que o acaso. O benchmark depende do conjunto de anonimato real e de quais dados auxiliares o adversário possui. Uma pequena demonstração bem-sucedida em laboratório não estabelece privacidade sob uma base de usuários de produção minúscula, mas cria um método para medir se as implantações melhoram com o tempo.

O teste de conteúdo é direto e sóbrio. Envie o mesmo documento distintivo sob duas chaves de sessão novas. Se um provedor conseguir reconhecê-lo em ambas, a desvinculação de pagamento não deu ao usuário desvinculação de conversa. Uma alegação sobre pagamento deve ser avaliada pelos dois primeiros testes; uma alegação sobre uso anônimo de IA também deve sobreviver ao terceiro. Publicar o modo, o modelo de ameaça e os resultados permitiria aos usuários escolher a ferramenta certa para sua preocupação real.

O caso mais forte é desvincular a cobrança do conteúdo útil

Há muitas razões legítimas para fazer a um provedor de IA uma pergunta sensível sem construir um dossiê permanente de uso vinculado a uma conta. Um jornalista testando um documento público, um pesquisador explorando uma hipótese controversa ou um desenvolvedor usando uma API dentro de um agente podem querer que o provedor veja a solicitação atual enquanto cortam a relação durável de cobrança. O design do zkAPI aborda essa necessidade mais restrita. Ele também permite que uma máquina pague por serviços medidos sem gerenciar uma conta pessoal de longa duração para cada solicitação.

O argumento contra exagerar nas alegações é igualmente forte. Os provedores ainda veem os prompts, e alguns prompts necessariamente revelam identidade. Uma empresa com requisitos rigorosos de confidencialidade pode precisar de controles contratuais, modelos locais ou computação confidencial, além da desvinculação de pagamento. Alguns usuários podem preferir uma conta comum com suporte e reembolsos estabelecidos a uma camada de pagamento criptográfica cujos mecanismos de disputa ainda são imaturos. A escolha depende do modelo de ameaça real.

O roteiro de privacidade do Ethereum discutido pela crypto.news enquadra a privacidade como um objetivo mais amplo. Um roteiro não confere suas proteções futuras a este aplicativo hoje. Um usuário de IA deve julgar o caminho ativo do cliente e do provedor que realmente lida com um prompt.

A Crypto.news explicou a mecânica mais restrita das provas de conhecimento zero em um guia separado. Uma prova revela um fato definido sem revelar uma testemunha; não é uma capa de invisibilidade de uso geral. Sua entrevista sobre infraestrutura Ethereum focada em privacidade ressalta como produtos diferentes protegem dados diferentes. A pergunta útil para o zkAPI é qual parte vê qual registro em cada etapa, não se o projeto se qualifica para a palavra ampla privado.

A melhor evidência contrária a uma leitura cética seria o uso medido sem um vínculo de identidade persistente, rótulos de modo claros, revisão de segurança independente e um modelo de ameaças publicado cobrindo IP, telemetria do navegador e recibos. A melhor evidência contrária a uma alegação de marketing expansiva já está no post da Fundação: o provedor vê o prompt. Ambas as observações podem ser verdadeiras ao mesmo tempo.

A Fundação lista pagamentos de API máquina a máquina como uma aplicação possível. Um agente autônomo pode enviar centenas de chamadas usando uma nota financiada ou muitas sessões curtas. Se suas tarefas carregarem registros de clientes, o provedor do modelo pode aprender sobre esses clientes mesmo enquanto a fonte de pagamento do agente permanece privada. O benefício de privacidade pertence ao vínculo de cobrança; ele não deve ser repassado a cada sujeito nomeado em uma solicitação.

Um agente também precisa de controles de orçamento. Um limite por chave limita uma sessão, mas um loop pode obter chaves repetidas até que a nota seja drenada, a menos que o cliente imponha uma política de gastos mais ampla. O operador deve definir um limite diário ou por tarefa, alertas e um controle de pausa separado da prova criptográfica. A prova verifica crédito autorizado, não se a chamada do agente era necessária ou econômica.

Quando vários agentes compartilham um único pool de créditos, a contabilidade interna pode se tornar o sistema de cobrança oculto. O operador pode precisar alocar cobranças a equipes ou clientes sem exportar suas identidades para o provedor da API. Isso pode ser feito com um livro-razão local, mas cria outro conjunto de dados sensíveis a proteger. A mudança da cobrança por conta para a cobrança por nota não abole a reconciliação; ela a realoca.

Finalmente, um agente pode se revelar por meio de comportamento. Chamadas repetidas no mesmo horário, os mesmos cabeçalhos de ferramenta e as mesmas frases específicas de tarefa podem tornar chaves separadas de curta duração fáceis de agrupar. Ocultar uma nota de financiamento onchain é útil contra a vigilância de pagamentos. Não é uma defesa contra uma impressão digital comportamental que o agente envia com cada solicitação.

Uma implantação ainda precisa de uma auditoria de modelo de ameaças

Em 2 de outubro, a Fundação afirma que o código, o servidor, o cliente e o cofre estão ativos. O post vincula um contrato na mainnet e um repositório. Ele não publica no anúncio uma contagem definitiva de usuários, valor total auditado, todas as integrações de terceiros ou uma garantia de que toda configuração de cliente usa o modo direto de chave de tempo de execução. Este recurso não alega uma violação ou mau comportamento por parte de um provedor nomeado. Ele identifica as informações que cada parte deve receber e os vazamentos adicionais que os autores do projeto reconhecem.

Uma avaliação externa deve inspecionar os padrões do cliente e as conexões de saída. A demonstração no navegador envia telemetria para domínios não relacionados? O cliente local retém chaves ou registros de prompt? O servidor de pagamento pode unir carimbos de data/hora de emissão com endereços de rede? Os recibos são vinculáveis entre sessões? Como as atualizações de circuito e contrato são governadas? Uma prova pode ser matematicamente sólida enquanto uma interface de usuário acidentalmente entrega a identidade que deveria separar.

A mesma avaliação deve testar a visão de um provedor de IA. Ele verá o conteúdo que processa e uma credencial de sessão. Pode coletar metadados de dispositivo ou rede dependendo do caminho da solicitação. A política de retenção de dados de um provedor e quaisquer termos contratuais permanecem centrais. A camada de pagamento pode reduzir uma fonte de informação identificadora sem restringir todas as outras.

zkAPI dá um avanço real se impedir de forma confiável que um provedor de modelo vincule solicitações úteis a uma conta de cobrança, preservando ao mesmo tempo a capacidade do usuário de recuperar fundos. Ele decepcionará quem espera uma conversa privada simplesmente porque o pagamento foi comprovado em conhecimento zero. As duas afirmações devem ser julgadas separadamente.

O que observar

• Rótulo de modo: Verifique se cada cliente torna visível o roteamento direto por chave de tempo de execução ou por proxy antes que o usuário envie prompts.
• Atividade na mainnet: Procure contagens datadas de notas financiadas e uso, relatadas sem comprometer o anonimato dos usuários.
• Revisões de segurança: Leia o escopo de avaliações independentes que cobrem saídas de contrato, circuitos de prova, armazenamento do cliente e liquidação de recibos.
• Controles de metadados: Teste o tratamento de IP, telemetria, tempos de vida de chaves e retenção do provedor em integrações reais.
• Disputas de cobrança: Verifique como solicitações falhas, liberação de limite e recibos contestados são tratados sem forçar a divulgação de identidade.

Perguntas frequentes