O que é a zkAPI? Como a Ethereum utiliza provas de conhecimento zero para pagamentos privados de IA

Última atualização 13-10-2026 09:20:26
Tempo de leitura: 6m
O que é a zkAPI? Descobrir como as provas de conhecimento zero podem permitir pagamentos por API de IA que preservam a privacidade, credenciais anónimas, verificação da utilização e liquidação baseada em blockchain.

zkAPI é uma solução tecnológica de privacidade que aplica provas de conhecimento zero (Zero-Knowledge Proof, ZKP) ao controlo de acesso a API e à verificação de pagamentos. O seu objetivo é reduzir a exposição direta das identidades, contas e registos de pagamento dos utilizadores quando acedem a serviços online, como modelos de IA. Ao contrário dos modelos de acesso tradicionais, que dependem de contas verificadas, chaves API e sistemas de faturação centralizados, o zkAPI procura permitir que os utilizadores comprovem, por meios criptográficos, que dispõem de direitos de acesso válidos ou de credenciais de pagamento, sem divulgarem a sua identidade completa ao prestador do serviço.

À medida que os agentes de IA, as aplicações automatizadas e os serviços de modelos com pagamento por utilização continuam a desenvolver-se, os pagamentos de API estão a tornar-se uma infraestrutura importante para a economia digital. Embora os modelos de faturação tradicionais sejam maduros, geralmente exigem que os prestadores de serviços conservem registos de contas, pedidos e pagamentos durante períodos prolongados, facilitando a associação de comportamentos dos utilizadores. As provas de conhecimento zero oferecem uma nova abordagem técnica a este problema: separar, até certo ponto, as credenciais de pagamento da utilização efetiva do serviço, mantendo as capacidades necessárias de verificação de autorização e prevenção de abusos.

Este artigo começa pelo conceito de zkAPI e explica como as provas de conhecimento zero podem ser utilizadas para autorizar o acesso a API de IA, verificar credenciais de pagamento e gerir quotas de utilização. Analisa também os potenciais papéis dos contratos inteligentes da Ethereum, dos pagamentos on-chain e das tecnologias de privacidade. Além disso, o artigo aborda a diferença entre pagamentos anónimos e anonimato completo, bem como as limitações técnicas e comerciais que o zkAPI enfrenta em implementações reais.

Principais conclusões

  • zkAPI é uma solução técnica que explora a utilização de provas de conhecimento zero para o acesso a API, a verificação de identidade e a autorização de pagamentos. Procura reduzir a exposição das informações de identidade e pagamento dos utilizadores quando utilizam serviços de IA.

  • As API de IA tradicionais dependem geralmente de contas, chaves API e sistemas de faturação centralizados, permitindo aos prestadores de serviços associar registos de pedidos a contas específicas.

  • As provas de conhecimento zero permitem aos utilizadores comprovar que reúnem as condições para aceder a um serviço ou que dispõem de capacidade de pagamento suficiente, sem divulgar todas as informações subjacentes utilizadas na verificação.

  • A Ethereum e as suas redes de camada 2 podem fornecer infraestrutura de pagamento, contratos inteligentes e verificação de credenciais para soluções relacionadas. No entanto, isto não significa que os pedidos de inferência de IA ou todas as informações das transações recebam automaticamente proteção de privacidade.

  • As aplicações reais de zkAPI ainda precisam de resolver questões como a reutilização de credenciais, a gestão de quotas, os pedidos abusivos, os custos de geração de provas e a faturação do lado do servidor.

O que é zkAPI? Porque introduziu a Ethereum uma solução de pagamento anónimo para IA?

zkAPI é um protocolo de pagamento de API centrado na privacidade, desenvolvido em conjunto pelo Open Anonymity Project e pela Ethereum Foundation. Foi concebido para permitir aos utilizadores pagar por modelos de IA e outros serviços com pagamento por utilização através de provas de conhecimento zero, sem associar diretamente cada pedido de API à sua identidade real ou ao endereço de financiamento on-chain. Em 1 de outubro de 2026, a Ethereum Foundation anunciou o lançamento do zkAPI na rede principal da Ethereum e publicou implementações para o cliente, o servidor e o contrato inteligente. O projeto teve origem na conceção ZK API Usage Credits, anteriormente proposta por Vitalik Buterin e Davide Crapis, responsável pela equipa dAI da Ethereum Foundation.

Os serviços tradicionais de API de IA utilizam habitualmente chaves API para associar os pedidos dos utilizadores a contas, que, por sua vez, estão ligadas a cartões bancários ou a outros métodos de pagamento. À medida que os utilizadores continuam a utilizar os modelos, os prestadores de serviços podem combinar o histórico de prompts, os horários de utilização, os montantes gastos e as informações das contas em registos de longo prazo. Mesmo que os utilizadores não forneçam ativamente os seus nomes nos prompts, a associação contínua às informações das contas pode criar um perfil de utilização relativamente completo. Nas aplicações de IA que envolvem investigação e desenvolvimento empresarial, análise financeira pessoal ou outras informações sensíveis, este tipo de associação de dados pode gerar preocupações adicionais de privacidade.

O zkAPI procura alterar não os próprios modelos de IA, mas o método de autorização de pagamentos utilizado pelos serviços de modelos. Os utilizadores começam por depositar fundos num contrato inteligente da Ethereum e, depois, utilizam uma prova de conhecimento zero para demonstrar ao servidor de pagamentos que dispõem de crédito suficiente. O servidor pode confirmar a elegibilidade para pagamento sem saber qual o depósito específico que suporta o pedido atual. Ao mesmo tempo, o prestador de serviços de IA pode processar os prompts enviados pelo utilizador sem conhecer a identidade de financiamento on-chain associada ao pedido.

Assim, o objetivo central do zkAPI é impedir a associação entre as identidades de pagamento e os registos de utilização de API, e não cifrar automaticamente ou anonimizar por completo todos os pedidos de IA. Esta distinção é fundamental para compreender o valor técnico do protocolo.

Como permitem as provas de conhecimento zero pagamentos privados para API de IA?

Uma prova de conhecimento zero é uma tecnologia criptográfica que permite a uma parte provar a outra, responsável pela verificação, que uma afirmação é verdadeira, sem divulgar todas as informações secretas utilizadas para gerar a prova. Por exemplo, um utilizador pode provar que dispõe de fundos suficientes para pagar um serviço sem revelar a credencial específica de saldo privado de onde provêm esses fundos.

No zkAPI, depois de os utilizadores depositarem ETH ou outros ativos suportados num contrato inteligente Vault na Ethereum, o sistema representa o saldo disponível através de uma Private Note. Uma Note pode ser entendida como uma credencial digital de pagamento controlada pelas informações secretas do utilizador. O protocolo utiliza compromissos criptográficos para registar credenciais válidas e organiza esses compromissos numa árvore de Merkle. Isto permite aos utilizadores provar que as suas credenciais pertencem a um conjunto válido, sem revelar qual a credencial específica que detêm.

Quando um utilizador precisa de fazer uma chamada a uma API de IA, o cliente local gera uma prova de conhecimento zero que demonstra que a Note correspondente é válida, dispõe de capacidade de pagamento suficiente e cumpre as condições de utilização especificadas pelo protocolo. Depois de verificar a prova, o servidor de pagamentos pode emitir uma chave API temporária para o utilizador. Este processo não exige que o servidor obtenha as informações secretas originais do utilizador ou associe diretamente cada pedido a um endereço público de financiamento.

Para impedir que o mesmo saldo seja utilizado repetidamente, o zkAPI introduz um mecanismo de Nullifier. Um Nullifier é um identificador único gerado a partir de informações secretas e utilizado para detetar se o mesmo crédito disponível foi utilizado mais do que uma vez. Se o sistema detetar um Nullifier duplicado, pode identificar um possível comportamento de gasto duplo sem divulgar a identidade completa ou os registos de financiamento do utilizador. A implementação oficial utiliza componentes técnicos que incluem provas de conhecimento zero Groth16, a curva BN254, a função de hash Poseidon e árvores de Merkle.

Como gere o zkAPI os pagamentos, desde o financiamento na Ethereum até às chamadas de modelos de IA?

zkAPI 如何完成从 Ethereum 充值到 AI 模型调用的支付流程?

O processo do zkAPI pode ser dividido em cinco etapas: financiamento, prova de pagamento, autorização temporária, chamada do modelo e faturação final. Ao contrário dos sistemas que iniciam uma transação on-chain para cada pedido de API, o zkAPI permite aos utilizadores depositar fundos antecipadamente na Ethereum e, depois, concluir várias autorizações de acesso a API através de provas off-chain, evitando a necessidade de esperar pela confirmação da blockchain sempre que fazem uma chamada a um modelo.

Primeiro, o utilizador deposita fundos num contrato Vault na Ethereum e recebe um saldo disponível representado por uma Private Note. Quando precisa de fazer uma chamada a um modelo de IA, o cliente local gera uma prova de pagamento e envia-a para o servidor zkAPI. Depois de verificar a validade da prova, o servidor gera uma chave API temporária para a sessão atual, com um prazo de caducidade e um limite de despesa definidos. O utilizador pode utilizar esta chave para aceder aos serviços de IA suportados, sem utilizar diretamente uma chave API permanentemente ligada à sua conta pessoal de pagamento.

No modelo Runtime-Key descrito nos materiais oficiais, o prompt do utilizador é enviado diretamente ao prestador de serviços de modelos de IA, em vez de ser encaminhado através do servidor de pagamentos zkAPI. O servidor de pagamentos verifica a elegibilidade para pagamento e trata da faturação, enquanto o prestador de serviços de IA trata da inferência do modelo. Após o fim da sessão, o sistema calcula a taxa efetiva com base nos registos de utilização assinados e deduz o montante correspondente do saldo privado do utilizador. O limite de despesa da chave temporária corresponde a um montante reservado e não significa que o utilizador vá necessariamente pagar a totalidade desse montante.

O zkAPI disponibiliza também um modo Proxy relativamente simples, no qual um servidor proxy encaminha os pedidos. Esta abordagem pode ser mais fácil de integrar, mas o servidor proxy pode aceder ao tráfego dos pedidos, o que cria um perímetro de privacidade diferente do modelo Runtime-Key. Por isso, ao analisar as capacidades de privacidade do zkAPI, é necessário distinguir os modos de funcionamento específicos, em vez de considerar que todos os métodos de implementação oferecem o mesmo nível de isolamento de dados.

Que papéis desempenham o Vault, a Private Note e o Nullifier?

O Vault é a infraestrutura de contratos inteligentes que o zkAPI utiliza para gerir os fundos dos utilizadores na Ethereum. Os utilizadores depositam ativos no Vault através de transações públicas on-chain e podem depois utilizar os seus saldos privados para pagar serviços de API de acordo com as regras do protocolo. Ao contrário da transferência direta de fundos para a conta de um prestador de serviços centralizado, as regras de gestão e levantamento dos fundos do Vault são implementadas através de contratos inteligentes. A conceção oficial permite aos utilizadores levantar os fundos restantes através do processo de saída on-chain correspondente, reduzindo a dependência da permanência de um único servidor de pagamentos online.

A Private Note representa o saldo privado que o utilizador pode controlar. Não é uma nova criptomoeda, mas uma credencial criptográfica utilizada para controlar e comprovar a elegibilidade para pagamento. Através da Note e da árvore de Merkle, os utilizadores podem provar que detêm um saldo válido sem divulgar os registos de financiamento correspondentes a cada pagamento. Isto significa que deixa de ser necessária uma relação direta de um para um entre o financiamento público on-chain e a utilização específica de serviços de IA.

O Nullifier impede o gasto duplo. Se um sistema de pagamentos privados ocultar as credenciais de saldo, mas não conseguir detetar a sua utilização repetida, um utilizador poderá gastar os mesmos fundos várias vezes. Por isso, o zkAPI utiliza Nullifiers para manter as verificações de unicidade necessárias, protegendo simultaneamente a privacidade das credenciais. Os três componentes tratam, respetivamente, da gestão de fundos, das provas privadas de elegibilidade para pagamento e da deteção de gasto duplo, formando em conjunto o mecanismo básico de pagamento do protocolo.

É importante salientar que o financiamento e os levantamentos do Vault continuam a ser transações públicas na Ethereum. O zkAPI oculta sobretudo a relação entre transações de financiamento específicas e a utilização posterior de API, em vez de tornar completamente invisíveis os endereços de financiamento, os montantes das transações ou toda a atividade on-chain.

Em que difere o zkAPI dos métodos tradicionais de pagamento de API de IA?

As API de IA tradicionais utilizam geralmente saldos de conta ou faturação pós-paga. Depois de registarem uma conta, os programadores recebem uma chave API, e o sistema utiliza essa chave para identificar a origem dos pedidos, acompanhar a utilização de tokens e calcular as taxas. Este modelo oferece ferramentas de desenvolvimento, gestão de faturação e sistemas de apoio ao cliente maduros, mas os prestadores de serviços também podem associar os registos de utilização de API às informações das contas durante períodos prolongados.

O zkAPI utiliza credenciais de saldo privado e provas de conhecimento zero para verificar a elegibilidade para pagamento, procurando separar a identidade do utilizador, a origem do pagamento e os pedidos específicos. A sua principal diferença não é utilizar ou não ETH para pagamento, mas sim a possibilidade de o prestador do serviço estabelecer diretamente uma relação entre a conta de pagamento e os pedidos aos modelos.

Dimensão de comparação API de IA tradicional zkAPI
Identidade de pagamento Habitualmente ligada a uma conta registada Utiliza credenciais privadas de pagamento
Autorização de API Chave API de longo prazo ou token de conta Prova de conhecimento zero e chave API temporária
Método de faturação Saldo de conta ou faturação periódica Crédito privado e registos de utilização efetiva
Associação de informações de pagamento Os prestadores de serviços podem habitualmente associar contas e pedidos Concebido para separar as origens dos pagamentos dos pedidos
Dependência da blockchain Habitualmente desnecessária Utiliza um contrato de financiamento na Ethereum
Privacidade do conteúdo dos pedidos Geralmente visível para o prestador de serviços de modelos Continua visível para o prestador de serviços de modelos
Principais limitações Centralização dos dados das contas e associação à identidade Custos das provas, complexidade do protocolo e limites de privacidade

Assim, o zkAPI não pretende substituir completamente as chaves API tradicionais. Em vez disso, utiliza autorização temporária e credenciais privadas de pagamento para alterar a relação entre as chaves API e as identidades de pagamento de longo prazo. Para aplicações que apenas precisam de faturação e gestão de acesso convencionais, o modelo tradicional pode continuar a ser mais simples. Para utilizadores ou aplicações que pretendam reduzir a exposição das identidades de pagamento, o zkAPI oferece outra opção técnica.

Pode o zkAPI permitir realmente conversas de IA totalmente anónimas?

O zkAPI pode reduzir a ligação direta entre as identidades de pagamento e os pedidos de API, mas não pode garantir conversas de IA completamente anónimas. A Ethereum Foundation afirmou claramente no seu anúncio oficial que os prestadores de serviços de IA continuam a poder ler os prompts enviados pelos utilizadores e as respostas geradas pelos modelos, porque a inferência dos modelos exige o processamento desse conteúdo. Por outras palavras, o zkAPI protege a privacidade da associação aos pagamentos; não fornece automaticamente inferência de IA com cifragem de ponta a ponta.

Os metadados de rede também representam um potencial risco para a privacidade. Se um utilizador aceder continuamente a um serviço a partir de um endereço IP fixo, o gateway de pagamentos ou o fornecedor do modelo poderá continuar a analisar o seu comportamento através dos horários de ligação, da frequência dos pedidos e de outras características da rede. Mesmo que não seja possível associar diretamente a credencial de pagamento, os padrões repetidos na camada de rede podem reduzir o anonimato. Por isso, os materiais oficiais tratam o anonimato de rede como uma questão que exige medidas técnicas adicionais, e não como uma capacidade que o zkAPI já assegura plenamente.

Além disso, os próprios prompts podem revelar a identidade. Por exemplo, se um utilizador fornecer repetidamente o mesmo contexto pessoal, nome de projeto empresarial ou conteúdo de conversas anteriores em diferentes sessões, o prestador de serviços de modelos poderá voltar a associar esses pedidos com base nas características do conteúdo. Mesmo sem um nome de conta, um estilo de escrita distintivo e informações contextuais contínuas podem fornecer indícios de identificação.

Assim, uma interpretação mais precisa é que o zkAPI pode reduzir a associação entre as identidades de pagamento e os registos de utilização de API ao nível da conceção do protocolo, mas uma proteção abrangente da privacidade na IA continua a exigir outras tecnologias, incluindo anonimato de rede, minimização de dados e computação com preservação da privacidade.

Porque é o zkAPI adequado para agentes de IA e pagamentos entre máquinas?

Os agentes de IA utilizam API de forma diferente dos utilizadores comuns em alguns aspetos. Os utilizadores tradicionais compram habitualmente subscrições de forma manual através de sites ou aplicações, enquanto os agentes de IA podem precisar de fazer chamadas automáticas a vários modelos, bases de dados ou serviços de computação em função de uma tarefa. Se cada serviço exigir uma conta, um método de pagamento e uma chave API de longo prazo distintos, a gestão de pagamentos e permissões pode tornar-se complexa para os sistemas automatizados.

Os mecanismos de crédito privado e autorização temporária disponibilizados pelo zkAPI oferecem uma abordagem técnica para serviços entre máquinas com pagamento por utilização. Um agente de IA pode obter acesso a API dentro de um montante de financiamento e de um limite de despesa predefinidos e, depois, fazer chamadas aos serviços relevantes de acordo com a tarefa concreta. Através de provas de conhecimento zero, o servidor de pagamentos pode verificar o crédito autorizado sem exigir que cada chamada esteja diretamente associada a uma conta de pagamento de longo prazo.

Além da inferência de modelos de IA, a Ethereum Foundation indicou consultas RPC de blockchain, geração de imagens e vídeos, serviços de largura de banda VPN e outras formas de faturação entre máquinas como potenciais casos de utilização. Estes serviços partilham características comuns: a faturação é habitualmente feita por chamada, tarefa de computação, tempo ou volume de tráfego, pelo que podem utilizar mecanismos semelhantes de autorização de crédito e liquidação com base em registos de utilização.

No entanto, os pagamentos automatizados por agentes de IA também exigem controlos rigorosos de fundos e permissões. Mesmo que a identidade de pagamento esteja protegida, configurações incorretas de tarefas, chamadas de API anómalas ou entradas maliciosas podem esgotar rapidamente os fundos. Por isso, as implementações reais precisam de definir limites por chamada, orçamentos de sessão, listas de serviços permitidos e monitorização de utilizações anómalas. Os pagamentos privados não devem ser equiparados à segurança dos pagamentos automatizados.

Que limitações técnicas e riscos de segurança enfrenta o zkAPI?

A primeira categoria de desafios decorre das provas criptográficas e da complexidade do sistema. Embora as provas de conhecimento zero possam ocultar algumas informações subjacentes, a geração e a verificação de provas, bem como a gestão de credenciais, aumentam os custos de desenvolvimento e operação. O protocolo tem de assegurar a atualização correta dos saldos privados dos utilizadores e impedir o gasto duplo, tratando simultaneamente da caducidade de chaves temporárias, da liquidação com base em registos de utilização, de saídas anómalas e de outras situações. Em comparação com uma base de dados tradicional de faturação centralizada, esta conceção exige que mais componentes criptográficos e de contratos inteligentes funcionem em conjunto.

A segunda categoria diz respeito à segurança dos contratos inteligentes e dos serviços de pagamento. O contrato Vault gere fundos on-chain. Se existirem vulnerabilidades no contrato, na lógica de verificação de provas ou na implementação do cliente, a segurança dos fundos dos utilizadores poderá ser afetada. Embora o projeto oficial tenha publicado o seu código-fonte e implementado componentes relacionados na rede principal da Ethereum, o seu repositório no GitHub continua a classificar o protocolo como uma implementação experimental. Isto significa que os utilizadores e os programadores não devem presumir que o protocolo dispõe de todas as proteções de segurança de um sistema comercial de pagamentos maduro apenas por estar operacional na rede principal.

A terceira categoria é o equilíbrio entre a proteção da privacidade e o funcionamento real dos serviços. Os prestadores de serviços de IA continuam a precisar de identificar abusos, aplicar limites à frequência dos pedidos e tratar de litígios de faturação, enquanto os mecanismos de pagamento anónimo podem dificultar a aplicação direta dos controlos de risco tradicionais baseados em contas. O zkAPI mantém as restrições de faturação necessárias através de chaves temporárias, limites de despesa e registos de utilização assinados, mas os prestadores de serviços continuam a precisar de desenvolver mecanismos de prevenção de abusos adequados a ambientes de pagamentos privados.

Além disso, o protocolo não resolve automaticamente o anonimato de rede nem a fuga de informação contida nos prompts. Nas aplicações de IA que processam informações altamente sensíveis, a utilização exclusiva do zkAPI não basta para assegurar uma confidencialidade abrangente dos dados. É também necessário avaliar as políticas de tratamento de dados do fornecedor do modelo, os métodos de ligação à rede e tecnologias adicionais de computação com preservação da privacidade.

O que significa o zkAPI para a Ethereum e para a infraestrutura de pagamentos de IA?

O lançamento do zkAPI reflete a expansão da exploração de aplicações de IA pela Ethereum, dos pagamentos de ativos para a autorização com privacidade e a faturação de serviços. Os pagamentos tradicionais em blockchain centram-se geralmente na capacidade de transferir ativos entre diferentes endereços. O zkAPI vai mais longe, ao analisar como concluir pagamentos reduzindo a ligação informacional entre as identidades de pagamento e a utilização efetiva dos serviços. Isto significa que os contratos inteligentes da Ethereum podem servir não só como infraestrutura de transferência de pagamentos, mas também como parte do controlo de acesso e da gestão de fundos para serviços digitais.

Na perspetiva da arquitetura técnica, o zkAPI combina gestão de fundos on-chain com autorização de API off-chain. A Ethereum trata do contrato de fundos e da lógica de verificação necessária, as provas de conhecimento zero ocultam a ligação entre as credenciais de pagamento e os comportamentos específicos de utilização, e os prestadores de serviços de IA continuam a realizar a inferência dos modelos. Esta divisão evita colocar diretamente cada chamada de API na blockchain e fornece uma conceção de referência para futuros serviços com pagamento por utilização.

No entanto, o zkAPI continua nas fases iniciais de adoção real. O seu desenvolvimento a longo prazo vai depender não só da maturidade da tecnologia de provas de conhecimento zero, mas também da disponibilidade dos prestadores de serviços de IA para o integrar, da facilidade de integração para os programadores e da necessidade efetiva dos utilizadores de separar as identidades de pagamento dos registos de utilização dos modelos. Para a Ethereum, a importância principal do zkAPI reside na demonstração de uma arquitetura operacional de pagamentos privados — e não na ideia de que todos os serviços de API de IA vão passar a utilizar pagamentos on-chain.

Conclusão

zkAPI é um protocolo de pagamento de API centrado na privacidade, lançado através de uma colaboração entre a Ethereum Foundation e o Open Anonymity Project. Através de contratos inteligentes Vault, Private Notes, provas de conhecimento zero e chaves API temporárias, separa as identidades de pagamento dos utilizadores dos seus registos de utilização de serviços de IA. Os utilizadores podem depositar fundos antecipadamente na Ethereum e, depois, obter acesso a API através de provas criptográficas, sem divulgar a origem do financiamento correspondente a cada pedido.

Em comparação com os métodos tradicionais de pagamento de API de IA, a inovação central do zkAPI não consiste simplesmente em utilizar ETH ou stablecoins para adquirir serviços de modelos. Em vez disso, procura resolver a associação de longo prazo entre contas de pagamento e conteúdo dos pedidos. Ao combinar a gestão de fundos on-chain com a faturação da utilização off-chain, o protocolo pode manter a verificação de quotas e a deteção de gasto duplo, melhorando simultaneamente a proteção da privacidade na camada de pagamento.

No entanto, o zkAPI não significa que os serviços de IA se tornem completamente anónimos. Os fornecedores de modelos podem continuar a ler os prompts, enquanto os metadados de rede e as características do conteúdo também podem revelar informações dos utilizadores. A aplicação generalizada deste tipo de tecnologia a agentes de IA, à inferência de modelos e a outros serviços com pagamento por utilização exige ainda uma validação adicional da sua segurança, escalabilidade e viabilidade comercial.

Perguntas frequentes

1. O que é zkAPI?

zkAPI é um protocolo de pagamento de API centrado na privacidade e baseado em provas de conhecimento zero. Permite aos utilizadores comprovar que dispõem de crédito suficiente para utilizar serviços através de credenciais privadas de pagamento, sem divulgar ao servidor de pagamentos a origem específica do financiamento ou a identidade de pagamento de longo prazo.

2. O zkAPI foi lançado oficialmente pela Ethereum?

O zkAPI foi desenvolvido em conjunto pelo Open Anonymity Project e pela Ethereum Foundation, e a sua entrada em funcionamento na rede principal da Ethereum foi anunciada em 1 de outubro de 2026. É uma implementação técnica experimental desenvolvida através dessa colaboração e não um protocolo obrigatório da camada base da rede Ethereum.

3. O zkAPI pode ser utilizado para pagar com ETH ou USDC?

Os materiais oficiais da Ethereum Foundation indicam que ativos como ETH e USDC podem ser utilizados em cenários de financiamento e pagamento relacionados. No entanto, os ativos específicos suportados pelo cliente, pelo contrato Vault e pela versão implementada devem ser confirmados na documentação mais recente da implementação relevante.

4. O zkAPI pode ocultar os prompts que os utilizadores enviam à IA?

Não. O zkAPI oculta sobretudo a relação entre as identidades de pagamento e os registos de utilização de API. Os prestadores de serviços de modelos de IA continuam a precisar de ler os prompts para gerar respostas, pelo que o conteúdo dos prompts não é automaticamente cifrado apenas por ser utilizado o zkAPI.

5. Porque precisa o zkAPI de Nullifiers?

Os Nullifiers são utilizados para detetar se as credenciais de saldo privado foram gastas mais do que uma vez. O sistema pode impedir a reutilização do mesmo crédito através da verificação de identificadores únicos, evitando simultaneamente a divulgação direta da totalidade das informações secretas das credenciais.

6. O zkAPI é adequado para pagamentos automatizados por agentes de IA?

O zkAPI pode fornecer aos agentes de IA faturação por utilização, autorização temporária e credenciais privadas de pagamento. No entanto, as implementações reais continuam a precisar de limites orçamentais, permissões de acesso e controlos de utilizações anómalas para reduzir os riscos financeiros associados às chamadas automatizadas.

Autor: Learn Team
Exclusão de responsabilidade

* As informações não se destinam a ser e não constituem aconselhamento financeiro ou qualquer outra recomendação de qualquer tipo oferecido ou endossado pela Gate.

* Este artigo não pode ser reproduzido, transmitido ou copiado sem fazer referência à Gate. A violação é uma violação da Lei de Direitos de Autor e pode estar sujeita a ações legais.

Artigos relacionados

Modelo Económico do Token ONDO: De que forma impulsiona o crescimento da plataforma e o envolvimento dos utilizadores?
Principiante

Modelo Económico do Token ONDO: De que forma impulsiona o crescimento da plataforma e o envolvimento dos utilizadores?

ONDO é o token central de governança e captação de valor do ecossistema Ondo Finance. Tem como objetivo principal potenciar mecanismos de incentivos em token para integrar, de forma fluida, os ativos financeiros tradicionais (RWA) no ecossistema DeFi, impulsionando o crescimento em larga escala da gestão de ativos on-chain e dos produtos de retorno.
27-03-2026 13:52:50
Morpho vs. Aave: Análise aprofundada das diferenças de mecanismo e estrutura nos protocolos de empréstimos DeFi
Principiante

Morpho vs. Aave: Análise aprofundada das diferenças de mecanismo e estrutura nos protocolos de empréstimos DeFi

A principal distinção entre o Morpho e o Aave está no mecanismo de empréstimos. O Aave opera com um modelo de pool de liquidez, enquanto o Morpho baseia-se neste sistema ao implementar uma correspondência peer-to-peer (P2P), o que permite um alinhamento superior das taxas de juros dentro do mesmo mercado. O Aave funciona como protocolo nativo de empréstimos, fornecendo liquidez de base e taxas de juros estáveis. Em contrapartida, o Morpho atua como uma camada de otimização, aumentando a eficiência do capital ao estreitar o spread entre as taxas de depósito e de empréstimo. Em suma, a diferença fundamental é que o Aave oferece infraestrutura central, enquanto o Morpho é uma ferramenta de otimização da eficiência.
03-04-2026 13:09:48
Tokenomics da Morpho: Utilidade, distribuição e proposta de valor do MORPHO
Principiante

Tokenomics da Morpho: Utilidade, distribuição e proposta de valor do MORPHO

O MORPHO é o token nativo do protocolo Morpho, criado essencialmente para a governança e incentivos do ecossistema. Ao organizar a distribuição do token e os mecanismos de incentivo, o Morpho assegura o alinhamento entre a atividade dos utilizadores, o crescimento do protocolo e a autoridade de governança, promovendo um modelo de valor sustentável no ecossistema descentralizado de empréstimos.
03-04-2026 13:13:47
Pendle vs Notional: análise comparativa dos protocolos DeFi de retorno fixo
Intermediário

Pendle vs Notional: análise comparativa dos protocolos DeFi de retorno fixo

A Pendle e a Notional posicionam-se como protocolos líderes no setor de retorno fixo DeFi, a explorar mecanismos distintos para a geração de retornos. A Pendle apresenta funcionalidades de retorno fixo e negociação de rendimento através do modelo de divisão de rendimento PT e YT, enquanto a Notional possibilita aos utilizadores fixar taxas de empréstimo através dum mercado de empréstimos com taxa de juros fixa. De forma comparativa, a Pendle adequa-se melhor à gestão de ativos de retorno e à negociação de taxas de juros, enquanto a Notional se foca em cenários de empréstimos com taxa de juros fixa. Ambas contribuem para o avanço do mercado DeFi de retorno fixo, destacando-se por abordagens distintas na estrutura dos produtos, no design de liquidez e nos segmentos-alvo de utilizadores.
21-04-2026 07:34:06
O que são PT e YT na Pendle? Uma análise detalhada do mecanismo de divisão de retorno
Intermediário

O que são PT e YT na Pendle? Uma análise detalhada do mecanismo de divisão de retorno

PT e YT são os dois tokens de rendimento fundamentais no protocolo Pendle. O PT (Principal Token) reflete o capital de um ativo de rendimento, sendo habitualmente negociado com desconto e resgatado pelo valor nominal na data de vencimento. O YT (Yield Token) confere o direito ao rendimento futuro do ativo e pode ser negociado para captar retornos antecipados. Ao dividir os ativos de rendimento em PT e YT, a Pendle estabeleceu um mercado de negociação de rendimentos no universo DeFi, permitindo aos utilizadores garantir retornos fixos, especular sobre variações do rendimento e gerir o risco associado ao rendimento.
21-04-2026 07:18:16
De que forma opera o sistema de governança do Lido DAO? Uma explicação sobre a função do Token LDO
Principiante

De que forma opera o sistema de governança do Lido DAO? Uma explicação sobre a função do Token LDO

A Lido DAO (LDO) é a organização autónoma descentralizada responsável pela gestão do protocolo de staking líquido Lido. Os titulares de Token LDO votam nos parâmetros do protocolo, nas estratégias de operação dos nodos e na orientação geral do desenvolvimento do ecossistema. Como infraestrutura fundamental no setor de staking líquido, o mecanismo de governança da Lido DAO influencia diretamente a segurança do protocolo, a estrutura de retorno e a trajetória de crescimento a longo prazo.
03-04-2026 13:37:46