O cofundador do Ethereum, Vitalik Buterin, testou uma configuração de IA focada em privacidade que usa um modelo local, zkAPI e Tor para gerar recomendações personalizadas de dieta e exercícios, limitando as informações pessoais enviadas a modelos remotos.
Resumo
- Vitalik Buterin está testando aconselhamento privado de saúde com IA usando Qwen local, zkAPI e roteamento Tor.
- Seu modelo local reescreve os prompts antes que modelos remotos recebam dados limitados de saúde e viagem remotamente.
- O zkAPI separa a identidade de pagamento das solicitações ao modelo, enquanto o Tor é usado para mascarar informações de IP.
- Buterin disse que a latência do Tor permanece de 10 a 100 vezes maior, tornando a desvinculação solicitação por solicitação ineficiente nos testes atuais.
- O Qwen3.8-Flash-Next roda em torno de 20–30 TPS localmente, enquanto Buterin quer velocidades acima de 100 TPS para conforto.
Buterin disse em 4 de outubro que o autoexperimento usa suas informações de saúde e viagem localmente, enquanto modelos remotos mais poderosos lidam com perguntas selecionadas que exigem raciocínio ou conhecimento mais forte.
A configuração usa o Qwen3.8-Flash-Next da Alibaba como modelo local. Buterin disse que o sistema local decide quais informações um modelo remoto precisa e reescreve as solicitações antes de enviá-las, reduzindo a chance de que detalhes pessoais ou seu estilo de escrita revelem sua identidade.
Vitalik Buterin usa três camadas para separar sua identidade
Buterin descreveu o design como uma configuração de privacidade em três camadas que cobre o conteúdo das solicitações, informações de pagamento e tráfego de internet. O modelo Qwen local lida com a primeira camada ao construir as consultas por conta própria, em vez de enviar suas palavras originais e o contexto pessoal completo a sistemas de IA remotos.
A segunda camada usa zkAPI para separar pagamentos de solicitações individuais à IA. A Ethereum Foundation apresentou o zkAPI em 1º de outubro, descrevendo-o como um sistema que permite aos usuários pagar por APIs medidas sem vincular solicitações individuais à sua identidade. O projeto foi construído pelo Open Anonymity Project em colaboração com a Ethereum Foundation e está rodando na mainnet do Ethereum.
No zkAPI, um usuário financia um saldo privado e depois prova que fundos suficientes estão disponíveis sem mostrar qual depósito está pagando por uma solicitação específica. O serviço que lida com o pagamento não precisa do prompt do usuário, enquanto o provedor de IA recebe o prompt sem saber a identidade de cobrança vinculada ao depósito.
O Tor fornece a terceira camada ao ocultar o endereço IP normal do usuário dos serviços que recebem solicitações de rede. Buterin escreveu que todas as três proteções são necessárias porque ocultar apenas as informações de pagamento não impede que um provedor de IA descubra detalhes por meio do conteúdo do prompt ou de metadados de rede.
“Você precisa das três”, disse Buterin.
O zkAPI não oculta tudo o que é enviado a um modelo de IA
A configuração de privacidade não impede que provedores remotos de IA leiam informações deliberadamente incluídas em um prompt. A documentação oficial do zkAPI afirma que o provedor upstream ainda vê os prompts, enquanto informações de rede e de tempo podem permanecer observáveis fora do sistema de prova de conhecimento zero.
A Ethereum Foundation fez a mesma distinção quando lançou o zkAPI. Sua explicação de 1º de outubro disse que o sistema de pagamento oculta o vínculo entre um usuário e uma solicitação, mas a privacidade do conteúdo e o anonimato da rede exigem proteções separadas. Detalhes pessoais reutilizados, padrões de escrita, histórico de conversas ou documentos ainda podem permitir que sessões sejam conectadas.
O modelo local de Buterin tem como objetivo reduzir essa exposição de conteúdo. Um arquivo de habilidade instrui o modelo sobre quando usar um sistema remoto e como construir uma solicitação que contenha menos informações identificáveis. Seus registros pessoais de saúde e viagem permanecem disponíveis para o sistema local, enquanto o modelo remoto recebe apenas a parte selecionada para uma tarefa específica.
Buterin disse que a configuração produziu recomendações de dieta e exercícios e que as informações retornadas por modelos de fronteira melhoraram os resultados. Ele não publicou os registros de saúde subjacentes, as recomendações detalhadas nem uma avaliação independente de sua precisão.
O experimento se alinha com seu foco anterior na privacidade, à medida que os sistemas de IA lidam com mais informações pessoais. Como relatado anteriormente na cobertura do crypto.news sobre as preocupações de privacidade de Buterin, ele argumentou em abril de 2025 que as crescentes capacidades de IA e a coleta centralizada de dados aumentaram a necessidade de ferramentas de privacidade mais fortes.
O suporte ao Tor chegou à base de código do zkAPI
Buterin vinculou a uma nova mudança no repositório zkAPI do Ethereum que adiciona suporte a cliente roteado pelo Tor. O GitHub mostra o pull request #16 como aberto em 4 de outubro, com um commit propondo mudanças em sete arquivos. Ele ainda não foi mesclado ao branch principal do projeto.
O código proposto cria um novo cliente Tor temporário quando o daemon zkAPI é iniciado. O script usa um novo diretório de dados e conexão Tor, enquanto outro comando pode reiniciar o serviço para uma nova identidade de rede antes que uma nova solicitação única ou conversa comece.
O patch altera vários tempos limite de rede porque as solicitações roteadas pelo Tor podem demorar mais. Um tempo limite de lista de modelos aumenta de um minuto para três minutos, enquanto outros limites de solicitação aumentam de 15 segundos para 60 segundos e de cinco segundos para 30 segundos.
Um script de cliente Tor separado incluído na proposta diz que um novo servidor é criado para uma única solicitação ou o início de uma nova conversa. Mensagens contínuas dentro da mesma conversa mantêm o servidor existente em execução, o que significa que elas não recebem automaticamente uma nova identidade Tor para cada mensagem.
A latência do Tor e a velocidade da IA local continuam sendo problemas
Buterin identificou o Tor como uma das partes mais fracas do experimento atual. Ele disse que o Tor não foi projetado para o tipo de desvinculação solicitação por solicitação que ele deseja, onde chamadas de IA separadas idealmente seriam difíceis de associar umas às outras.
Em seus testes, o Tor produziu latência aproximadamente 10 a 100 vezes maior do que ele considerava desejável. As mudanças no GitHub que aumentam vários limites de tempo limite são consistentes com a expectativa de solicitações de rede mais lentas quando o cliente zkAPI é roteado pelo Tor.
O modelo local apresenta outro limite de desempenho. Buterin disse que o Qwen3.8-Flash-Next estava rodando a aproximadamente 20 a 30 tokens por segundo em sua configuração, mas ele acreditava que a inferência local só começaria a parecer rápida a mais de 100 tokens por segundo.
A equipe Qwen da Alibaba lançou o Qwen3.8-Flash-Next em 26 de agosto. O repositório oficial o descreve como um modelo de fundação de pesos abertos que pode ser executado por meio de estruturas de inferência local, incluindo implantações usando vLLM e SGLang.
Buterin já vinha experimentando modelos Qwen locais antes do mais recente teste de privacidade. Sua configuração atual vai um passo além, permitindo que o modelo local atue como intermediário entre arquivos privados e sistemas de IA remotos, em vez de manter cada tarefa inteiramente no dispositivo do usuário.
A privacidade também permaneceu parte de seu trabalho no Ethereum. Em cobertura relacionada,o crypto.news relatou sobre o roteiro atualizado do Ethereum em agosto, que incluía privacidade de protocolo mais forte ao lado de trabalho em resistência quântica e rollups nativos.
Buterin disse que as regras de redação de solicitações em seu experimento atual ainda precisam de melhorias, porque remover mais contexto pessoal pode reduzir a utilidade dos modelos remotos. Ele descreveu o limite diretamente: “quanto mais cuidadoso você for” com as informações enviadas remotamente, menos assistência o modelo remoto poderá fornecer.
A documentação do zkAPI da Ethereum Foundation faz uma distinção técnica semelhante. A camada de pagamento pode quebrar a conexão entre um saldo financiado e o uso individual da API, mas não pode remover informações identificáveis que um usuário ou agente local coloca dentro do próprio prompt.
