O momento HTTPS da privacidade do Ethereum: de ferramenta defensiva a infraestrutura padrão

O evento Ethereum Privacy Stack foi organizado em conjunto pela equipe Privacy & Scaling Explorations (PSE), Web3Privacy Now e membros centrais da Ethereum Foundation (EF), sendo um dos eventos verticais de maior prestígio durante o Devconnect ARG 2025. O evento reuniu Vitalik Buterin, o fundador do Tor, pesquisadores centrais da EF, fundadores de protocolos de privacidade (Railgun, 0xbow, Aztec, entre outros) e especialistas jurídicos de destaque. Seu objetivo central é, em um momento de crescente pressão regulatória e amadurecimento tecnológico, reestruturar o mapa do ecossistema de privacidade do Ethereum, eliminar ilhas tecnológicas e definir o roteiro de privacidade para os próximos 3-5 anos.

Por: ZHIXIONG PAN

O Ethereum Privacy Stack, realizado durante o Devconnect Buenos Aires 2025, foi o encontro mais importante do ano sobre privacidade no ecossistema Ethereum.

O consenso mais marcante do evento foi o estabelecimento do conceito de “Privacidade Holística”: privacidade não é mais apenas uma soma de ferramentas on-chain como provas de conhecimento zero (ZK) ou mixers, mas um ciclo completo que abrange desde a camada de transmissão de rede (Tor), leitura RPC, armazenamento de dados até a interface de interação do usuário.

Como enfatizaram Vitalik Buterin e Roger Dingledine, fundador do projeto Tor, se a rede subjacente vaza o IP, o anonimato na camada de aplicação é inútil. A comunidade chegou ao consenso de que o Ethereum deve seguir a “teoria do barril”, corrigindo o elo mais fraco de vazamento de metadados para realmente se tornar o “livro-razão mundial” resistente à censura.

Insights de Tendência: Caminhando para “Privacidade Padrão” e a Batalha pela Experiência do Usuário

Os participantes geralmente acreditam que a privacidade no Web3 está passando por um momento crucial, semelhante à transição do Web2 de HTTP para HTTPS. A tecnologia de privacidade não deve mais ser privilégio de “geeks” ou “hackers”, nem carregar o fardo moral de “esconder crimes”. Comparando Railgun, a carteira Kohaku e experiências históricas do Web2, os palestrantes apontaram que o próximo passo é “estigmatizar comportamentos não privados”, ou seja, fazer com que transferências públicas e transparentes sejam vistas como algo tão estranho quanto correr nu na internet.

Até 2026, o objetivo da comunidade Ethereum é reduzir o custo das transferências privadas para um nível aceitável (por exemplo, apenas o dobro de uma transferência comum) e alcançar uma experiência sem atrito e com um clique, servindo não apenas investidores de varejo, mas também abrindo portas para instituições financeiras tradicionais que não ingressam por falta de proteção de segredos comerciais.

Controvérsia Central: O Espectro da Conformidade e o Risco de “Guerra Civil” no L1

Apesar do roteiro tecnológico estar cada vez mais claro, a tensão ideológica persiste. O maior ponto de controvérsia é a disputa entre “privacidade compatível” e “privacidade sem permissão”. De um lado, representado pelo Privacy Pools, defende-se o uso de “provas de dissociação” para isolar ativamente fundos ilícitos, em troca de tolerância regulatória e adoção institucional; do outro, mantém-se o espírito cypherpunk puro, acreditando que qualquer forma de compromisso regulatório acabará levando à censura.

Além disso, Andy Guzman, da PSE, alertou para uma possível “guerra civil” iminente: se as funções de privacidade devem ser incorporadas ao núcleo do protocolo Ethereum (L1). Escrevê-las no L1 pode trazer liquidez unificada e proteção padrão, mas também pode acarretar grandes riscos regulatórios e complexidade do protocolo, decisão que determinará o perfil político futuro do Ethereum.

O Despertar da Infraestrutura: Hardware e a Última Linha de Defesa Contra a Censura

Além das discussões de software, o evento aprofundou-se raramente nas camadas física e de rede. Desde “rodar seu próprio nó” até a “desconfiança de ambientes de execução confiáveis (TEE)”, a comunidade percebeu que, se o hardware tiver backdoors, toda a criptografia superior será inútil. A resistência à censura foi redefinida como uma infraestrutura pública semelhante a “rotas de fuga de incêndio”: parece desnecessária em tempos de paz, mas é a única esperança de sobrevivência em crises. Seja construindo VPNs descentralizadas (como Nym, HOPR) ou usando ZK-TLS para “interoperabilidade de guerrilha”, o objetivo é criar um sistema robusto mesmo sob conflitos geopolíticos extremos.

Autodefesa Legal e Cultural

Diante do caso dos desenvolvedores do Tornado Cash, o evento foi permeado por um senso urgente de “autodefesa”. Especialistas jurídicos e desenvolvedores clamaram pela criação de fundos de defesa legal robustos e grupos de lobby político. Todos perceberam que proteger a privacidade não é apenas escrever código, mas também uma guerra pela narrativa: é preciso transformar a imagem do desenvolvedor de “possível cúmplice de terroristas” para “defensor da liberdade na era digital”. Se o setor não se unir para proteger os contribuidores de código aberto, o progresso tecnológico estagnará por medo de represálias.

A seguir, um resumo detalhado das 16 palestras e painéis do evento.

1. Onionizing Ethereum (A “cebolização” do Ethereum)

Palestrantes: Vitalik Buterin (Ethereum Foundation), Roger Dingledine (Tor Project)

Este diálogo marcou uma grande mudança conceitual na visão de privacidade do Ethereum. Vitalik apontou que a Ethereum Foundation está promovendo um plano para integrar profundamente o Tor e Onion Services em toda a stack tecnológica do Ethereum. Isso representa uma mudança de mentalidade: de focar apenas na privacidade das transações (como provas ZK) para uma visão mais abrangente de “privacidade holística”. Essa visão cobre privacidade de escrita (envio de transações) e de leitura (leitura de dados RPC), visando evitar que usuários vazem IPs e padrões de acesso ao transmitir transações ou ler dados on-chain.

Roger Dingledine compartilhou o status do Tor como infraestrutura subjacente do Bitcoin, apontando que cerca de três quartos dos nós do Bitcoin se conectam via endereços onion. Ele destacou que anonimato apenas na camada de aplicação não é suficiente: se a camada de transporte de rede vazar IPs, a privacidade da aplicação é anulada. O objetivo do Ethereum é introduzir mixnets e onion routing não só na camada de contratos inteligentes, mas também na camada de rede P2P, protegendo validadores (Proposers) contra ataques DoS e aumentando a resistência à censura.

Vitalik detalhou ainda os dois tipos de “censura”: censura de transações na camada de aplicação e censura de acesso na camada de rede. Ele enfatizou que o objetivo do Ethereum é ser um livro-razão globalmente acessível, permitindo que usuários e validadores se conectem via transportes plugáveis do Tor (como Snowflake) mesmo sob bloqueios nacionais. Essa tecnologia pode disfarçar o tráfego como chamadas de vídeo WebRTC comuns, contornando bloqueios. Isso não é apenas sobre privacidade, mas sobre a resiliência e descentralização geográfica do Ethereum como “livro-razão mundial”.

No futuro, ambos discutiram a possibilidade de validadores do Ethereum (Stakers) rodarem nós de retransmissão do Tor. Como o tráfego para serviços onion específicos não requer saída (Exit Relay), validadores podem facilmente operar relays não-exit, contribuindo apenas com banda sem riscos legais. Se implementado, isso aumentará significativamente a resistência à censura e a privacidade do Ethereum nos próximos anos, melhorando tanto a experiência do usuário quanto a resiliência da rede.

2. Ethereum is for DefiPunk (Ethereum pertence ao DefiPunk)

Palestrante: Hsiao-Wei Wang (Ethereum Foundation)

O núcleo da palestra de Hsiao-Wei girou em torno da nova política financeira da Ethereum Foundation (EF), apresentando o conceito de “DefiPunk”, que visa reinjetar o espírito cypherpunk no DeFi. Ela destacou que o DeFi não deve ser apenas sobre retorno financeiro, mas também sobre resistência à censura, código aberto e proteção da privacidade. A EF decidiu que sua alocação de fundos deve refletir os valores centrais do Ethereum, apoiando projetos que promovam o desenvolvimento saudável de longo prazo, e não apenas perseguindo altos APYs ou atalhos centralizados.

Para orientar essa estratégia, ela detalhou os seis atributos centrais do DefiPunk: Segurança, Código Aberto, Autossuficiência Financeira, Confiança Minimizada, Suporte a Ferramentas Criptográficas e Privacidade. Especialmente para código aberto, a EF prefere apoiar projetos com licenças FLOSS, incentivando transparência e colaboração genuínas, em vez de proteção comercial de código.

Nos critérios específicos, DefiPunk enfatiza que protocolos devem ser permissionless (acesso sem permissão), permitindo que usuários de qualquer região participem; e que usuários tenham controle total sobre seus ativos (User Sovereignty), sem depender de custódia de terceiros. Ela destacou que privacidade não deve ser um luxo no DeFi, mas sim um direito fundamental. A EF incentiva projetos a evitarem riscos de censura de front-ends centralizados, usando front-ends distribuídos, UIs independentes ou até ferramentas de linha de comando.

Por fim, Hsiao-Wei convocou a comunidade e desenvolvedores a praticarem esses valores. O papel da EF não é apenas financiar, mas ser o pilar dessa filosofia. Ela encorajou usuários a pensarem como verdadeiros “DefiPunks” ao escolher protocolos DeFi: revisar o código, observar a transparência da governança e verificar contratos inteligentes imutáveis. Essa palestra desafia o status quo do setor DeFi, pedindo um retorno às raízes da descentralização financeira: fornecer serviços financeiros inquebráveis para os oprimidos e desbancarizados.

3. Privacy-Aware Mechanisms for Public Goods Funding (Mecanismos de Privacidade para Financiamento de Bens Públicos)

Convidados: Camila Rioja (Plexos), Thomas Humphreys (EF), Tanisha Katara, Beth McCarthy, José Ignacio Trajtenberg

Este painel focou em como equilibrar transparência e privacidade no financiamento de bens públicos. Os painelistas compartilharam casos do mundo real, como o projeto de distribuição de ajuda da Xcapit com a UNICEF e o uso de blockchain no Brasil para gerenciar moedas comunitárias. Nesses cenários de ajuda humanitária e grupos vulneráveis, privacidade não é apenas proteção de dados, mas questão de segurança de vida.

O núcleo da discussão foi o equilíbrio entre “transparência” e “privacidade”. Para os resultados da alocação de fundos, transparência é necessária para garantir que o dinheiro chegue ao destino certo e tenha impacto; mas na participação, especialmente em votação e verificação de identidade, privacidade é crucial. Se o voto for totalmente público, surgem mercados de suborno e pressão social, distorcendo a governança. Com provas ZK, é possível validar elegibilidade e resultados sem revelar votos, alcançando governança anti-conluio.

Os convidados também discutiram como ferramentas técnicas podem se adaptar a diferentes jurisdições. Em alguns países, coletar certos dados é legal, mas em outros (como Alemanha), pode violar o GDPR. Portanto, ferramentas globais de financiamento de bens públicos devem ser flexíveis e priorizar privacidade, permitindo que comunidades locais adaptem conforme suas necessidades.

Por fim, o painel vislumbrou direções futuras, como mercados preditivos com privacidade e mecanismos de financiamento autossustentáveis. Todos concordaram que a tecnologia deve resolver não só eficiência, mas também voltar ao design centrado no ser humano. Com provas de identidade ZK e ferramentas de votação privada, é possível proteger dados dos usuários e construir governança comunitária mais justa e segura.

4. Who pays for privacy? The real cost of building aligned apps (Quem paga pela privacidade? O custo real de construir apps alinhados)

Palestrante: Lefteris Karapetsas (Rotki)

Lefteris começou com uma frase impactante: “Se o produto é gratuito, você é o produto.”

Ele apontou que aplicativos de internet atuais geralmente trocam serviços gratuitos por “imposto de dados”, coletando e vendendo dados dos usuários. Para mudar isso, propôs o conceito de “aplicativos alinhados”: software que realmente serve aos interesses do usuário, respeita a soberania dos dados, prioriza o local e não rastreia. No entanto, construir esses apps enfrenta enormes desafios de engenharia e custos.

Usando o Rotki (um rastreador de portfólio local) como exemplo, detalhou os custos ocultos de desenvolver apps de privacidade. Diferente de SaaS, apps locais não podem fazer facilmente testes A/B ou coletar logs de erro; desenvolvedores precisam empacotar binários para vários sistemas operacionais, lidar com migração de bancos de dados locais e pagar certificados caros de assinatura de código. Isso reduz a eficiência e impossibilita monetizar dados dos usuários, tornando o modelo de negócios mais difícil.

Lefteris aconselha fortemente desenvolvedores a não dependerem de doações ou grants, pois isso é um beco sem saída. Apps de privacidade precisam de modelo de negócios claro, cobrando diretamente dos usuários. Isso não só mantém o desenvolvimento, mas educa o usuário: privacidade tem custo explícito. Com modelos freemium, suporte corporativo ou recursos pagos (como análise avançada), desenvolvedores podem obter receita recorrente previsível.

No final, ele pediu um novo contrato entre usuários e desenvolvedores: pagar não só pelo software, mas para apoiar um futuro sem vigilância ou más práticas. Incentivou desenvolvedores a precificarem com confiança, não desvalorizarem seu trabalho e manterem transparência financeira para ganhar confiança da comunidade. Construir “apps alinhados” é um ato punk, uma rebelião contra o monopólio e vigilância dos gigantes da nuvem.

5. Ethereum Privacy Ecosystem mapping (Mapeamento do Ecossistema de Privacidade do Ethereum)

Convidados: Mykola Siusko, Antonio Seveso, cyp, Alavi, Kassandra.eth

Este painel buscou esclarecer o complexo e fragmentado ecossistema de privacidade do Ethereum. Os convidados concordaram que o núcleo do ecossistema não é listar todos os protocolos, mas entender suas relações. O ecossistema atual se divide em áreas verticais: privacidade on-chain (endereços stealth, pools de privacidade), privacidade na camada de rede (mixnets) e, o mais importante, a camada de experiência do usuário (UX), vista como ponte para adoção em massa.

Discutiu-se a relação sutil entre “conformidade” e “privacidade”. Os convidados refletiram sobre as limitações de construir ferramentas de privacidade apenas para defesa regulatória. Privacidade não deve ser só tecnologia defensiva, mas um esforço colaborativo comunitário, desbloqueando novas capacidades para usuários e comunidades. Enfatizar demais a narrativa defensiva pode limitar a imaginação dos produtos.

Sobre regulação e conformidade, os convidados foram enfáticos: construir produtos globais que atendam a todas as jurisdições é irreal e até ingênuo. Em vez de embutir conformidade no protocolo (o que geralmente cria backdoors), é melhor construir infraestrutura de privacidade genérica e dar ao usuário o direito de divulgação seletiva na aplicação (como View Keys). Assim, protege-se contra vigilância total, mantendo a capacidade de provar conformidade quando necessário.

Por fim, destacaram a importância de romper a “bolha técnica”, pedindo mais conexão com organizações de privacidade fora do cripto (Tor, EFF, Signal). O futuro do ecossistema deve incluir assistência jurídica, hackathons, educação e advocacy, não só pilhas técnicas. Tornar a privacidade normal, social e até divertida é chave para o próximo passo do ecossistema.

6. Ethereum Institutional Privacy now (Privacidade Institucional no Ethereum Hoje)

Convidados: Oskar Thorin, Zach Obront, Amzah Moelah, Eugenio Reggianini, Francois

Oskar Thorin apresentou o grupo de trabalho de privacidade institucional da EF (IPTF) e sua missão: ajudar instituições financeiras tradicionais a migrarem para o Ethereum, atendendo suas necessidades de privacidade. Agora, as instituições não evitam blockchains por regulação, mas por falta de privacidade. Mesmo que apenas 1% dos fundos tradicionais entrem no Ethereum, o impacto no ecossistema de privacidade será enorme.

No painel, representantes do ABN Amro (banco holandês) e Etherealize compartilharam as dores reais das instituições. Elas querem a liquidez global das blockchains públicas, mas não podem aceitar que estratégias, posições ou dados de clientes fiquem totalmente públicos. Diferente do varejo, instituições precisam de “controle”: saber exatamente quem pode ver quais dados e quando, com granularidade para cada fluxo de negócio (emissão de títulos, liquidação de empréstimos, negociação secundária), pois cada cenário exige transparência diferente.

Francois, do Polygon Miden, explicou como usam modelo híbrido de contas (Account + UTXO): usuários mantêm estado privado localmente e só provam validade das transações à rede pública quando necessário. Discutiu-se também o uso de provas ZK para relatórios regulatórios, permitindo provar solvência ou conformidade sem revelar dados subjacentes.

Todos concordaram que o futuro não é criar blockchains privadas isoladas, mas construir camadas de privacidade na rede pública do Ethereum. Ao desacoplar autenticação (KYC/KYB), execução de políticas e relatórios regulatórios, instituições podem manter segredos comerciais e ainda aproveitar segurança e liquidez do Ethereum. A maturidade dessa arquitetura será o ponto de virada para adoção institucional em massa por volta de 2026.

7. Privacy Without Terrorists (Privacidade sem Terroristas)

Palestrante: Ameen Suleimani (0xbow)

Ameen começou com uma parábola sobre poluição em lagos da Patagônia, ilustrando o dilema do Tornado Cash: quando poucos (“terroristas”/hackers) poluem um recurso público (pool de privacidade), todos são punidos. Ele revisou a história do Tornado Cash, defendendo que desenvolvedores não devem ser responsabilizados por atos ilícitos dos usuários, mas levantou a questão: ao usar mixers, usuários comuns acabam dando cobertura a hackers. Assim, a comunidade deve criar sistemas que protejam usuários legítimos sem empoderar criminosos.

Esse é o cerne do Privacy Pools. Diferente do Tornado Cash, Privacy Pools permite que usuários, via provas ZK, se “dissociem” publicamente de fundos ilícitos (como de hackers norte-coreanos). Ao sacar, o usuário pode provar que seus fundos vêm de um conjunto legítimo, sem revelar a origem exata. Isso atende exigências de AML sem sacrificar a privacidade on-chain.

Ameen detalhou o mecanismo de gestão do 0xbow. O sistema introduz checagens KYT (Know Your Transaction), exigindo aprovação para depósitos. Se um depósito for considerado ilícito, pode ser removido do conjunto compatível, mas não congelado. Destacou o mecanismo “Rage Quit”: mesmo que um depósito seja posteriormente marcado como não compatível ou o 0xbow encerre operações, o contrato inteligente garante que o usuário pode sacar o principal a qualquer momento. Isso cria um modelo “não custodial, mas com permissão”.

Por fim, Ameen antecipou o roteiro do Privacy Pools V2, previsto para lançamento no EthCC (Paris). O V2 suportará transferências com endereços stealth, permitindo pagamentos P2P dentro do pool sem precisar sacar para novo endereço. O V2 troca parte da fungibilidade por recuperabilidade, visando construir infraestrutura de privacidade para “bons usuários” e evitar que desenvolvedores sejam presos por escrever código.

8. Is censorship resilience truly necessary? (A resistência à censura é realmente necessária?)

Palestrante: Mashbean (Matters.lab)

Mashbean levantou uma questão desconfortável: se resistência à censura é tão importante, por que produtos com esse foco têm dificuldade para sobreviver? Com base em cinco anos de experiência no Matters.news (plataforma descentralizada de publicação), revelou o descompasso entre “demanda de mercado” e “demanda de sobrevivência”. Grupos marginais (dissidentes, jornalistas) têm forte necessidade moral, mas o mercado é pequeno e sem poder de compra. Usuários comuns só se importam com qualidade do conteúdo, não com resistência à censura.

Ele explorou o “Paradoxo do Honeypot”: plataformas resistentes à censura atraem conteúdos sensíveis, concentrando riscos. Isso atrai bloqueios de governos autoritários e ataques de spam e golpes. Ironicamente, para combater spam, a plataforma precisa de alguma moderação, criando tensão com o objetivo original. Ataques de spam já ativaram sistemas antifraude de países democráticos, levando a bloqueios acidentais e criando uma “censura conjunta transnacional”.

Diante desses desafios, Mashbean sugeriu soluções contraintuitivas. Primeiro, não construir uma plataforma única e grande, mas componentes modulares (armazenamento, identidade, pagamento) para que pequenas comunidades possam reutilizar a infraestrutura, evitando ser alvo fácil. Segundo, “comer sua própria comida de cachorro”: desenvolvedores devem adotar OpSec forte e pagamentos privados, pois também são grupo de risco.

Conclusão: resistência à censura não deve ser vista como produto comercial comum, mas como infraestrutura pública como “rotas de incêndio” ou “cintos de segurança”. Ninguém pergunta o TAM de uma rota de incêndio, mas em emergências ela salva vidas. Assim, o modelo de financiamento deve misturar fundos públicos, doações e propriedade comunitária, e o sucesso se mede por quantos conseguem se expressar e sobreviver sob pressão.

9. Guerilla Interoperability (Interoperabilidade de Guerrilha)

Palestrante: Andreas Tsamados (Fileverse)

A palestra de Andreas foi combativa, comparando a internet Web2 a uma cidade cheia de “arquitetura hostil”, onde gigantes controlam usuários com jardins murados, DRM e bloqueio de dados. Para combater a “Enshittification” (degradação de plataformas), propôs o conceito de “interoperabilidade de guerrilha”: resistência tática dos usuários, forçando interoperabilidade sem permissão das plataformas, recuperando a soberania dos dados.

Ele detalhou o arsenal técnico para isso, especialmente o ZK-TLS (Zero-Knowledge Transport Layer Security). Essa tecnologia permite que usuários gerem provas criptográficas de interações com sites Web2 (bancos, redes sociais), trazendo dados para o Web3 sem permissão das plataformas. Assim, desenvolvedores podem construir apps sobre plataformas monopolistas, sugando e superando-as sem esperar APIs abertas.

Andreas defende uma cultura de “otimismo revolucionário”, rejeitando o fatalismo da internet atual. Mostrou ferramentas do Fileverse como ddocs.new e dsheets.new, alternativas descentralizadas ao Google Workspace, com criptografia ponta a ponta, convites via ENS e armazenamento em IPFS.

O conselho central: não espere boa vontade dos gigantes, mas use contas programáveis, armazenamento descentralizado e ZK para forçar alternativas. Esse movimento de “direito ao conserto digital” pede que desenvolvedores usem a infraestrutura fechada existente para dar aos usuários mais privacidade e soberania, até que os gigantes aceitem a nova normalidade.

10. Building infrastructural resilience (Construindo Resiliência de Infraestrutura)

Convidados: Sebastian Burgel, ml_sudo, Pol Lanski, Kyle Den Hartog

Este painel focou nas camadas física e de hardware. Os convidados apontaram que, se o hardware subjacente não for confiável, a privacidade do software é como construir sobre areia. Chips atuais (como Intel SGX) sacrificam segurança por desempenho e são vulneráveis a ataques de canal lateral. ml_sudo apresentou a iniciativa Trustless TEE, visando construir chips de hardware totalmente open source, com design e fabricação transparentes, adaptados ao cenário geopolítico atual.

Pol Lanski (Dappnode) destacou a importância do auto-hospedagem doméstica. Embora a experiência do usuário ainda não seja ideal, o objetivo deve ser “cada um rodar seu próprio nó”. Isso não é só descentralização, mas uma forma de desobediência civil: quando leis tentam monitorar todas as comunicações, rodar seu próprio relay e servidor é a melhor forma de tornar a lei inexequível.

Sebastian (HOPR) trouxe um ponto interessante: “Nerds protegem redes”. Embora se deseje participação de todos, são os nerds que mexem com hardware e rodam nós que formam a linha de defesa. O ecossistema deve valorizar e empoderar essa cultura, ao mesmo tempo em que reduz barreiras para mais participação.

No fim, voltaram ao “porquê”: em uma era de deepfakes e hiperconectividade, só com hardware e infraestrutura trustless podemos manter a “humanidade” digital — saber que se interage com pessoas reais e que seus dados não são roubados. Essa resiliência é a última linha de defesa contra o totalitarismo digital.

11. Kohaku wallet on Ethereum (Carteira Kohaku no Ethereum)

Palestrante: Nicolas Consigny (EF)

Nicolas lançou um novo projeto liderado pela Ethereum Foundation: Kohaku. É um conjunto de primitivas focadas em privacidade e segurança, incluindo um SDK e uma extensão de carteira de referência (fork do Ambire). O objetivo não é ser mais uma carteira concorrente, mas fornecer componentes open source de alta qualidade para que outros desenvolvedores possam usá-los como “buffet”, elevando o padrão de privacidade do ecossistema.

O destaque do Kohaku é simplificar o uso de protocolos de privacidade. Ele integra Railgun, Privacy Pools e outros, permitindo que usuários enviem ativos para pools de privacidade com um clique, sem configurações complexas. Kohaku também introduz um sistema de “uma conta por dApp”, evitando que o mesmo endereço seja vinculado a vários apps e reduzindo vazamento de metadados.

Em segurança de hardware, Kohaku fez avanços importantes. Em parceria com a ZKnox, implementou assinatura de transações ZK do Railgun diretamente em hardware wallets, atendendo usuários avançados que querem “cold storage + privacidade”. Também mostrou uma camada de aplicação de hardware universal, permitindo que a mesma lógica de assinatura rode em Keystone, Keycard e até hardware DIY de baixo custo.

A demonstração de Nicolas mostrou a abordagem pragmática da EF: não mudar o mundo da noite para o dia, mas construir SDKs seguros e fáceis de usar (como OpenLV), facilitando a integração de suporte ao Tor e transações privadas em carteiras existentes. O Kohaku deve lançar testnet pública no EthCC do próximo ano, marcando uma nova fase de padronização e modularização da privacidade no Ethereum.

12. Private voting in DAOs (Votação Privada em DAOs)

Convidados: Joshua Davila, Lasha Antadze, Anthony Leuts, Jordi Pinyana, John Guilding

O painel discutiu profundamente a necessidade de votação privada em DAOs e governança do mundo real. Anthony (Aragon) foi direto: a falta de privacidade leva a governança falsa — 99% das propostas recebem 99% de aprovação, pois ninguém quer ser “o chato” ou sofrer retaliação. Votação privada protege eleitores e revela opiniões reais, quebrando o “falso consenso”.

Representantes da Rarimo e Vocdoni compartilharam experiências em ambientes de alto risco (sob regimes opressores), onde votar pode levar à prisão, tornando privacidade de identidade vital. O desafio técnico é combinar identidade do mundo real (passaporte, biometria) com privacidade on-chain, prevenindo ataques Sybil (votos múltiplos) e garantindo votos não rastreáveis.

John (MACI) destacou a importância do anti-conluio. Votação privada não é só anonimato, mas impedir que se prove em quem votou, evitando compra de votos. Se eleitores puderem provar “votei no A”, surgem mercados de suborno. O MACI (Minimum Anti-Collusion Infrastructure) visa resolver isso. Ele citou o sucesso do round privado do Gitcoin, mostrando que a tecnologia (voto quadrático + identidade ZK) está quase pronta para produção.

Todos concordaram que 2026 será o ano-chave para maturidade dos protocolos de votação privada e integração em ferramentas DAO mainstream (Snapshot, Tally). Apesar da tecnologia pronta, o maior obstáculo é cultural: a comunidade cripto associa “transparência à justiça” e até normaliza subornos como mecanismo DeFi. Mudar essa narrativa e mostrar que privacidade é base da democracia é a próxima tarefa política.

13. From Tornado Cash to future developers protection (Do Tornado Cash à Proteção de Desenvolvedores Futuros)

Convidados: Marina Markezic, Fatemeh Fannisadeh, Ayanfeoluwa Olajide, Joan Arús

Este painel foi urgente e com chamado à ação. Joan Arús contou a origem da Sentinel Alliance: uma aliança de vítimas de spyware como Pegasus. Relatou como equipes do Aragon e Vocdoni foram monitoradas por governos por desenvolverem tecnologia de votação resistente à censura, mostrando que a ameaça evoluiu de “processar crimes passados” para “monitoramento preventivo”, mirando o potencial uso de código aberto.

Advogados analisaram o aumento dos riscos legais. Leis antiterrorismo agora têm definições amplas: qualquer tentativa de “desestabilizar estruturas políticas ou econômicas” pode ser rotulada como terrorismo. Assim, desenvolvedores de DeFi ou ferramentas de privacidade podem ser acusados sem saber. Fatemeh alertou que não se pode depender só de burocracia para justiça, sendo necessário criar defesas ativas.

Marina (EUCI) trouxe esperança: compartilhou avanços na revisão do GDPR na UE, onde, após lobby, reguladores começaram a reconhecer que tecnologias de privacidade podem ajudar na conformidade, não ser obstáculo. Isso mostra que advocacy política funciona.

Por fim, o painel fez um apelo: o setor cripto tem bilhões em capital e deve investir em fundos de defesa legal e lobby, não só em festas. Sem um quadro legal protetor, qualquer desenvolvedor pode ser o próximo preso. Isso é uma luta pela sobrevivência da liberdade, não só uma questão de conformidade.

14. Protocol-level privacy: Lessons from web2 (Privacidade em Nível de Protocolo: Lições do Web2)

Palestrante: Polymutex (Walletbeat)

Polymutex revisou a transição do Web2 de HTTP para HTTPS, oferecendo um valioso referencial para a privacidade no Web3. Ele apontou que a internet inicial, como o blockchain hoje, não tinha privacidade, pelos mesmos motivos: criptografia imatura, incerteza regulatória (criptografia já foi considerada armamento), alto custo de desempenho (latência de handshake).

Resumiu quatro estágios da popularização do HTTPS: 1. Tornar privacidade possível (padrões como SSL/TLS); 2. Tornar privacidade legal (vitórias judiciais); 3. Tornar privacidade barata (instruções aceleradas por hardware); 4. Tornar privacidade padrão. O surgimento do Let’s Encrypt foi um divisor de águas, tornando certificados fáceis e gratuitos. O estágio final foi navegadores rotulando sites HTTP como “inseguros”, estigmatizando comportamentos não privados.

No Web3, já estamos bem no estágio “possível” (padrões de protocolo de privacidade); o estágio “barato” avança com aceleração ZK e pré-compilados; mas nos estágios “legal” (caso Tornado Cash) e “simples” (integração em carteiras) ainda há grandes desafios. Falta ao Web3 um “momento Oh Shit” como o caso Snowden para despertar a consciência de privacidade do público.

Polymutex concluiu que precisamos de ferramentas (como WalletBeat) para monitorar o comportamento de privacidade das carteiras (vazamentos RPC) e promover privacidade como padrão. Mais importante, a comunidade deve estigmatizar comportamentos não privados — assim como navegadores alertam sobre HTTP, carteiras deveriam avisar: “Esta é uma transação pública, suas finanças serão monitoradas”. Só quando não proteger a privacidade for visto como anormal, a privacidade se popularizará.

15. Privacy on Ethereum now: key challenges (Privacidade no Ethereum Hoje: Desafios-Chave)

Palestrantes: Alan Scott, Max Hampshire

Alan e Max discutiram, em tom descontraído, os desafios reais de construir protocolos de privacidade na linha de frente. O principal desafio é a narrativa: hoje, usar ferramentas de privacidade (como Railgun) é associado a atividades ilícitas — “Por que esconder? Tem medo da polícia?” Essa estigmatização afasta usuários comuns. É preciso mudar a narrativa de “esconder crimes” para “proteger segurança financeira cotidiana” (como não querer que todos vejam sua fatura do Visa).

Outro obstáculo é o atrito na integração técnica. Alan comentou que o SDK do Railgun tem centenas de milhares de linhas de código; para protocolos DeFi como Aave, integrar algo tão grande é tecnicamente difícil e arriscado. Por isso, protocolos DeFi preferem que a camada de privacidade se adapte a eles, não o contrário. Além disso, carteiras existentes (forks do Rabby) estão cheias de rastreadores, o oposto do objetivo dos protocolos de privacidade.

Sobre privacidade na camada de rede, Max apontou que é um jogo de gato e rato: técnicas de deanonymização (análise de tráfego) e anonimização (mixnets) evoluem constantemente. Só privacidade na aplicação não basta: se ISP ou nó RPC veem seu IP e padrões de acesso, a privacidade on-chain é comprometida. Por isso, infraestrutura de rede como Nym deve ser integrada aos protocolos de aplicação.

Por fim, discutiram como ampliar o conjunto de anonimato. Se só “baleias” usam ferramentas de privacidade, o efeito é limitado. O objetivo é que usuários comuns usem privacidade sem perceber (plug and play), mesmo só para evitar cópias de trades ou proteger alphas. Só quando “bons usuários” e transações comuns forem maioria, a rede de privacidade oferecerá proteção real.

16. Ethereum Privacy Roadmap (Roteiro de Privacidade do Ethereum)

Palestrante: Andy Guzman (PSE)

Andy Guzman fez um resumo macro e perspectivas para o dia. Ele apresentou um modelo simplificado da stack de privacidade da PSE: leitura privada, escrita privada e portabilidade de dados. Usando a “teoria do barril”, apontou que a força do sistema depende do elo mais fraco: se tivermos ZK perfeito on-chain, mas vazarmos IP na camada RPC, o sistema falha.

No roteiro, Andy previu ousadamente: até novembro de 2026 (próximo Devcon), o problema das transferências privadas no Ethereum estará resolvido. Já há mais de 35 equipes explorando cerca de 13 caminhos técnicos (de endereços stealth a pools de privacidade), garantindo que uma solução vencedora surgirá. O futuro terá baixo custo (apenas o dobro de uma transferência comum), baixa latência e experiência com um clique.

Ele levantou um ponto controverso: privacidade deve ficar na camada de aplicação ou ser incorporada ao núcleo do protocolo (L1)? Isso pode causar uma “guerra civil” no futuro. Escrever privacidade no L1 traz liquidez unificada e privacidade padrão, mas também riscos regulatórios e complexidade. Ele pediu debate aberto na comunidade.

Por fim, sobre conformidade, Andy mostrou um espectro de “privacidade sem permissão (Cypherpunk)” a “privacidade compatível (Practical)”. Embora o espírito cypherpunk seja valioso, para adoção institucional e governamental, precisamos de soluções responsáveis como Privacy Pools. O futuro da privacidade no Ethereum não deve ser único, mas um ecossistema diversificado para diferentes necessidades. A PSE continuará preenchendo lacunas técnicas para garantir que o Ethereum seja realmente uma rede privacy-first.