El momento HTTPS de la privacidad en Ethereum: de herramienta defensiva a infraestructura por defecto

Este evento de Ethereum Privacy Stack fue coorganizado por el equipo Privacy & Scaling Explorations (PSE), Web3Privacy Now y miembros clave de la Ethereum Foundation (EF), y es uno de los eventos verticales de mayor nivel durante Devconnect ARG 2025. El evento reunió a Vitalik Buterin, al fundador de Tor, investigadores principales de la EF, fundadores de protocolos de privacidad (Railgun, 0xbow, Aztec, entre otros) y expertos legales de primer nivel. Su objetivo central es, en un punto de inflexión donde la presión regulatoria aumenta y la tecnología madura, reorganizar el mapa del ecosistema de privacidad de Ethereum, cerrar las brechas entre islas tecnológicas y definir la hoja de ruta de privacidad para los próximos 3-5 años.

Redactado por: ZHIXIONG PAN

Durante Devconnect Buenos Aires 2025, el evento Ethereum Privacy Stack fue la reunión temática sobre privacidad más relevante del año dentro del ecosistema de Ethereum.

El consenso más destacado del evento fue la consolidación del concepto de “Privacidad Holística”: la privacidad ya no es solo una suma de herramientas on-chain como pruebas ZK o mixers, sino un ciclo completo que abarca desde la capa de transmisión de red (Tor), la capa de lectura RPC, el almacenamiento de datos, hasta el frontend de interacción con el usuario.

Tal como enfatizaron Vitalik Buterin y Roger Dingledine, fundador del proyecto Tor, si la red subyacente filtra la IP, el anonimato en la capa de aplicación carece de sentido. La comunidad ha llegado a un consenso: Ethereum debe seguir la “teoría del barril”, reparando el eslabón más débil de la filtración de metadatos para convertirse realmente en el “libro mayor mundial” resistente a la censura.

Perspectivas de tendencia: Hacia la “privacidad por defecto” y la batalla por la experiencia de usuario

Los asistentes coincidieron en que la privacidad en Web3 está atravesando un momento clave similar al paso de HTTP a HTTPS en Web2. La tecnología de privacidad no debe ser más patrimonio de “geeks” o “hackers”, ni cargar con el estigma moral de “ocultar delitos”. Comparando experiencias históricas de Web2 y herramientas como Railgun y la wallet Kohaku, los oradores señalaron que el próximo paso es “estigmatizar el comportamiento no privado”, es decir, hacer que las transferencias públicas sean vistas como algo tan anómalo como correr desnudo por internet.

Para 2026, el objetivo de la comunidad de Ethereum es reducir el costo de las transferencias privadas a un rango aceptable (por ejemplo, solo el doble de una transferencia normal) y lograr una experiencia sin fricciones y de un solo clic, de modo que no solo sirva a usuarios minoristas, sino que también abra la puerta a instituciones financieras tradicionales que no han ingresado por falta de protección de secretos comerciales.

Controversias clave: El espectro de cumplimiento y la “guerra civil” en L1

Aunque la hoja de ruta tecnológica se va aclarando, la tensión ideológica persiste. El mayor punto de controversia es la pugna entre “privacidad conforme” y “privacidad sin permisos”. Un lado, representado por Privacy Pools, aboga por aislar fondos ilícitos mediante “pruebas de disociación” para obtener tolerancia regulatoria y adopción institucional; el otro lado defiende el espíritu cypherpunk puro, creyendo que cualquier compromiso con el cumplimiento llevará finalmente a la censura.

Además, Andy Guzman de PSE advirtió sobre una posible “guerra civil” inminente: si las funciones de privacidad deben integrarse en el protocolo central de Ethereum (L1). Incluirlas en L1 puede aportar liquidez unificada y protección por defecto, pero también grandes riesgos regulatorios y complejidad protocolar. Esta decisión definirá la naturaleza política futura de Ethereum.

El despertar de la infraestructura: Hardware y la última línea de defensa contra la censura

Además de las discusiones a nivel de software, este evento profundizó inusualmente en las capas física y de red. Desde “correr tu propio nodo” hasta la “desconfianza en entornos de ejecución confiables (TEE)”, la comunidad reconoció que si el hardware tiene puertas traseras, toda la criptografía superior es inútil. La resistencia a la censura se redefinió como infraestructura pública similar a una “salida de emergencia”: parece innecesaria en tiempos de paz, pero es la única esperanza en crisis. Ya sea construyendo VPNs descentralizadas (como Nym, HOPR) o usando ZK-TLS para “interoperabilidad guerrillera”, se busca un sistema robusto incluso bajo conflictos geopolíticos extremos.

Autodefensa legal y cultural

Ante el caso de los desarrolladores de Tornado Cash, el evento estuvo impregnado de una urgente atmósfera de “autodefensa”. Expertos legales y desarrolladores coincidieron en la necesidad de establecer fondos de defensa legal sólidos y grupos de lobby político. Se reconoció que proteger la privacidad no es solo escribir código, sino una guerra por el control del relato: es necesario transformar la imagen del desarrollador de “posible colaborador de terroristas” a “defensor de la libertad en la era digital”. Si la industria no se une para proteger a los contribuyentes open source, el progreso tecnológico se detendrá porque nadie se atreverá a escribir código.

A continuación, un resumen detallado de las 16 charlas y paneles del evento.

1. Onionizing Ethereum (La “onionización” de Ethereum)

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

Esta conversación marcó un cambio conceptual importante en la visión de privacidad de Ethereum. Vitalik señaló que la Ethereum Foundation está impulsando la integración profunda de Tor y Onion Services en toda la pila tecnológica de Ethereum. Esto representa un cambio de mentalidad: de enfocarse solo en la privacidad de las transacciones (como las pruebas ZK) a una visión más completa de “privacidad holística”. Esta visión abarca privacidad de escritura (envío de transacciones) y de lectura (lectura de datos RPC), buscando evitar que los usuarios filtren su IP o patrones de acceso al transmitir transacciones o leer datos on-chain.

Roger Dingledine compartió el estado de Tor como infraestructura subyacente de Bitcoin, señalando que actualmente alrededor de tres cuartos de los nodos de Bitcoin se conectan mediante direcciones onion. Enfatizó que la privacidad en la capa de aplicación no basta si la capa de transmisión de red filtra la IP. El objetivo de Ethereum es introducir mixnets y onion routing no solo en los contratos inteligentes, sino también en la capa de red P2P, para defenderse de ataques DoS a validadores (Proposers) y aumentar la resistencia a la censura.

Vitalik explicó las dos formas de “censura”: censura de transacciones en la capa de aplicación y censura de acceso en la capa de red. Ethereum busca ser un libro mayor globalmente accesible, de modo que incluso bajo bloqueos de firewalls estatales, usuarios y validadores puedan acceder a la red mediante transportes plug-and-play de Tor (como Snowflake), que disfrazan el tráfico como videollamadas WebRTC para evadir bloqueos. Esto no solo es privacidad, sino resiliencia y descentralización geográfica para Ethereum como “libro mayor mundial”.

En cuanto al futuro, ambos discutieron la posibilidad de que los validadores (Stakers) de Ethereum corran nodos relay de Tor. Como el tráfico para servicios onion específicos no requiere nodos de salida, los validadores pueden operar relays no de salida fácilmente, solo aportando ancho de banda sin riesgos legales. Si esto se logra, la resistencia a la censura y la privacidad de Ethereum se verán enormemente reforzadas en los próximos años, mejorando tanto la experiencia de usuario como la resiliencia de la red.

2. Ethereum is for DefiPunk (Ethereum es para DefiPunk)

Oradora: Hsiao-Wei Wang (Ethereum Foundation)

La charla de Hsiao-Wei giró en torno a la nueva política fiscal de la Ethereum Foundation (EF) y presentó el concepto “DefiPunk”, buscando reinyectar el espíritu cypherpunk en el ecosistema DeFi. Señaló que DeFi no debe ser solo búsqueda de rentabilidad, sino también resistencia a la censura, open source y protección de la privacidad. EF decide su asignación de fondos no solo por retorno financiero, sino por reflejar los valores centrales de Ethereum, apoyando proyectos que promuevan la salud a largo plazo de Ethereum, en vez de perseguir solo altos APY o atajos centralizados.

Para guiar esta estrategia, detalló los seis atributos clave de DefiPunk: seguridad, open source, autosuficiencia financiera, minimización de confianza, soporte de herramientas cripto y privacidad. En particular, EF prefiere proyectos con licencias FLOSS para fomentar transparencia y colaboración genuinas, no solo protección comercial del código.

En cuanto a los estándares, DefiPunk enfatiza que los protocolos deben ser permissionless (acceso sin permisos) y que los usuarios tengan control total sobre sus activos (User Sovereignty), sin depender de custodios. Además, la privacidad no debe ser un lujo en DeFi, sino un derecho de primera clase. EF incentiva el uso de frontends distribuidos, UIs independientes e incluso herramientas de línea de comandos para evitar riesgos de censura por frontends centralizados.

Finalmente, Hsiao-Wei llamó a la comunidad y desarrolladores a practicar estos valores. EF no es solo financiador, sino respaldo de esta filosofía. Animó a los usuarios a pensar como verdaderos “DefiPunk” al elegir protocolos DeFi: revisar el código, la transparencia de la gobernanza y la inmutabilidad de los contratos. Esta charla desafía el estado actual de DeFi, exigiendo un retorno al propósito original de las finanzas descentralizadas: proveer servicios financieros no censurables a los oprimidos y no bancarizados.

3. Privacy-Aware Mechanisms for Public Goods Funding (Mecanismos de privacidad para la financiación de bienes públicos)

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

Este panel se centró en cómo equilibrar transparencia y privacidad en la financiación de bienes públicos. Los panelistas compartieron casos reales, como el proyecto de ayuda de Xcapit con UNICEF y el uso de blockchain en Brasil para gestionar monedas comunitarias. En estos contextos de ayuda humanitaria y grupos vulnerables, la privacidad es clave para la seguridad de los beneficiarios, no solo para la protección de datos.

La tensión central es el equilibrio entre “transparencia” y “privacidad”. Para los resultados de la asignación de fondos, la transparencia es necesaria para asegurar el impacto; pero en la participación, especialmente en votación y verificación de identidad, la privacidad es esencial. Si la votación es pública, surgen mercados de sobornos y presión social, distorsionando la gobernanza. Las pruebas ZK permiten verificar elegibilidad y resultados sin revelar votos, logrando gobernanza anti-colusión.

Los panelistas también discutieron cómo las herramientas técnicas deben adaptarse a distintas jurisdicciones. En algunos países, recolectar ciertos datos es legal, pero en otros (como Alemania) puede violar GDPR. Por eso, las herramientas globales de financiación de bienes públicos deben ser flexibles y priorizar la privacidad, permitiendo que las comunidades locales las adapten según sus necesidades.

Finalmente, se discutieron direcciones futuras como mercados predictivos privados y mecanismos de financiación autosostenibles. Los panelistas coincidieron en que la tecnología debe volver a un diseño “centrado en las personas”. Con pruebas de identidad ZK y votación privada, se puede proteger contra ataques Sybil y resguardar datos de usuarios, construyendo una gobernanza comunitaria más justa y segura.

4. Who pays for privacy? The real cost of building aligned apps (¿Quién paga por la privacidad? El costo real de construir apps alineadas)

Orador: Lefteris Karapetsas (Rotki)

Lefteris abrió con una frase punzante sobre la industria: “Si el producto es gratis, vos sos el producto”.

Señaló que las apps actuales suelen intercambiar servicios gratuitos por “impuesto de datos”, recolectando y vendiendo datos de usuarios. Para romper esto, propuso el concepto de “apps alineadas”: software que sirve realmente al usuario, respeta la soberanía de datos, prioriza lo local y no rastrea. Pero construir estas apps implica enormes desafíos de ingeniería y costos.

Usó su propia app Rotki (herramienta local de seguimiento de portafolios) como ejemplo para describir los costos ocultos de desarrollar apps de privacidad. A diferencia de SaaS, las apps locales no pueden hacer A/B testing ni recolectar logs de errores fácilmente, requieren empaquetar binarios para varios sistemas operativos, manejar migraciones de bases de datos locales y pagar costosos certificados de firma de código. Esto reduce la eficiencia y dificulta monetizar datos, complicando el modelo de negocio.

Lefteris aconsejó no depender de donaciones o grants, pues es un callejón sin salida. Sostuvo que las apps de privacidad deben tener un modelo de negocio claro y cobrar directamente a los usuarios, no solo para sostener el desarrollo, sino para educar: la privacidad tiene un costo explícito. Con modelos freemium, soporte empresarial o funciones premium, los desarrolladores pueden obtener ingresos recurrentes y previsibles.

Al final, llamó a establecer un nuevo contrato entre usuarios y desarrolladores: pagar no solo por la función actual, sino por un futuro sin vigilancia ni malas prácticas. Animó a los desarrolladores a valorar su trabajo y mantener transparencia financiera para ganar la confianza de la comunidad. Construir “apps alineadas” es un acto punk, una rebelión contra el monopolio y la vigilancia de los gigantes de la nube.

5. Ethereum Privacy Ecosystem mapping (Mapa del ecosistema de privacidad de Ethereum)

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

Este panel intentó clarificar el complejo y fragmentado ecosistema de privacidad de Ethereum. Los panelistas coincidieron en que el núcleo no es solo listar protocolos de privacidad, sino entender sus relaciones. El ecosistema se divide en áreas verticales: privacidad on-chain (direcciones stealth, privacy pools), privacidad de red (mixnets), y la capa clave de conexión: la experiencia de usuario (UX). La UX es el puente que determina si la tecnología de privacidad será adoptada masivamente.

Se discutió la relación entre “cumplimiento” y “privacidad”. Los panelistas reflexionaron sobre las limitaciones de construir herramientas de privacidad solo para defenderse de la regulación. La privacidad no debe ser solo una tecnología defensiva, sino un esfuerzo colaborativo comunitario que desbloquee nuevas capacidades. Enfatizar demasiado la narrativa defensiva puede limitar la imaginación del producto.

Sobre regulación y cumplimiento, los panelistas fueron claros: construir productos globales que cumplan con todas las jurisdicciones es irreal e ingenuo. En vez de incluir cumplimiento en la capa de protocolo (lo que suele implicar puertas traseras), es mejor construir infraestructura de privacidad general y dar a los usuarios el derecho de divulgación selectiva en la capa de aplicación (como View Keys). Así se protege contra la vigilancia total y se conserva la capacidad de demostrar cumplimiento cuando sea necesario.

Finalmente, enfatizaron la importancia de romper la “cámara de eco” tecnológica y conectar con organizaciones de privacidad no cripto (Tor, EFF, Signal). El futuro mapa del ecosistema debe incluir ayuda legal, hackathons, educación y advocacy. Normalizar, socializar y hasta hacer divertida la privacidad es clave para el próximo desarrollo del ecosistema.

6. Ethereum Institutional Privacy now (Estado actual de la privacidad institucional en Ethereum)

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

Oskar Thorin presentó el grupo de trabajo de privacidad institucional (IPTF) de la EF y su misión: ayudar a instituciones financieras tradicionales a migrar a Ethereum, satisfaciendo sus necesidades de privacidad. La tendencia es que las instituciones ya no rechazan la blockchain por regulación, sino por falta de privacidad. Incluso si solo el 1% de los fondos tradicionales entra a Ethereum, el impacto en el ecosistema de privacidad sería enorme.

En el panel, representantes de ABN Amro y Etherealize compartieron los verdaderos dolores institucionales. Las instituciones quieren la liquidez global de la blockchain pública, pero no pueden aceptar que estrategias, posiciones o datos de clientes sean totalmente públicos. A diferencia de los minoristas, necesitan “control”: saber quién ve qué datos y cuándo, con un nivel de detalle que varía según el flujo de negocio (emisión de bonos, liquidación de préstamos, trading secundario, etc.).

Francois de Polygon Miden explicó cómo resuelven esto con un modelo híbrido de cuentas y UTXO: el usuario mantiene el estado privado localmente y solo prueba la validez de la transacción en la red pública cuando es necesario. También se discutió el uso de ZK en reportes regulatorios, permitiendo demostrar solvencia o cumplimiento sin revelar datos subyacentes.

Los panelistas coincidieron en que el futuro no es construir cadenas privadas aisladas, sino capas de privacidad sobre la blockchain pública de Ethereum. Separando autenticación (KYC/KYB), ejecución de políticas y reportes regulatorios, las instituciones pueden disfrutar de seguridad y liquidez de Ethereum sin perder secretos comerciales. Esta arquitectura madura será clave para la adopción institucional masiva alrededor de 2026.

7. Privacy Without Terrorists (Privacidad sin terroristas)

Orador: Ameen Suleimani (0xbow)

Ameen abrió con una parábola sobre la contaminación de lagos en la Patagonia, ilustrando el dilema de Tornado Cash: cuando unos pocos (“terroristas”/hackers) contaminan un recurso público (privacy pool), todos los usuarios son castigados. Repasó la historia de Tornado Cash, señalando que los desarrolladores no deben ser responsables por actos ilegales de usuarios, pero planteó el problema de que los usuarios comunes, al usar mixers, en la práctica encubren a hackers. Por eso, la comunidad debe construir sistemas que protejan la privacidad de usuarios legítimos sin empoderar a criminales.

Ese es el núcleo de Privacy Pools. A diferencia de Tornado Cash, Privacy Pools permite a los usuarios, mediante pruebas ZK, disociarse públicamente de fondos ilícitos (como los de hackers norcoreanos). Al retirar, el usuario puede probar que sus fondos provienen de un conjunto legítimo sin revelar la fuente exacta. Así se cumple con AML y se preserva la privacidad on-chain.

Ameen detalló el mecanismo de gestión de 0xbow. El sistema introduce chequeos KYT (Know Your Transaction), requiriendo aprobación para depósitos. Si se detecta un depósito ilícito, se puede remover del conjunto compliant, pero no congelar fondos. Destacó el mecanismo de “Rage Quit”: incluso si un depósito es marcado como no compliant o 0xbow cesa operaciones, el contrato inteligente garantiza que el usuario puede retirar su principal en cualquier momento. Esto logra una privacidad “no custodial pero con permisos”.

Finalmente, Ameen adelantó la hoja de ruta de Privacy Pools V2, a lanzarse en EthCC (París). V2 soportará transferencias shielded dentro del pool, permitiendo pagos P2P sin necesidad de retirar a una nueva dirección. V2 intercambia parte de la fungibilidad por recuperabilidad, buscando infraestructura de privacidad para “buenos” y evitar que desarrolladores terminen presos por escribir código.

8. Is censorship resilience truly necessary? (¿Es realmente necesaria la resistencia a la censura?)

Oradora: Mashbean (Matters.lab)

Mashbean planteó una pregunta incómoda: si la resistencia a la censura es tan importante, ¿por qué los productos centrados en ella sobreviven con dificultad? Basándose en cinco años de experiencia con Matters.news (plataforma descentralizada de publicación de contenidos), reveló la desconexión entre “demanda de mercado” y “demanda de supervivencia”. Los grupos marginales (disidentes, periodistas) tienen una fuerte necesidad moral de resistencia a la censura, pero el mercado es pequeño y carece de poder adquisitivo. La mayoría solo se preocupa por la calidad del contenido, no por la resistencia a la censura de la plataforma.

Exploró la “paradoja del honeypot”: construir plataformas resistentes a la censura atrae contenido sensible, concentrando el riesgo. Esto atrae bloqueos estatales y ataques de spam y estafas. Irónicamente, para combatir el spam, la plataforma debe introducir algún tipo de moderación, en tensión con la resistencia a la censura. Incluso, ataques de spam han activado sistemas anti-fraude automáticos en países democráticos, causando bloqueos erróneos y una nueva “censura transnacional conjunta”.

Ante estos dilemas, Mashbean propuso soluciones contrarias a la intuición. Primero, no construir una gran plataforma única, sino componentes modulares (almacenamiento, identidad, pagos) reutilizables por pequeñas comunidades, evitando ser un blanco obvio. Segundo, “comer tu propia comida para perros”: los desarrolladores deben usar OpSec fuerte y pagos privados, pues también son un grupo de alto riesgo.

La conclusión es que la resistencia a la censura no debe verse como un producto comercial común, sino como infraestructura pública tipo “salida de emergencia” o “cinturón de seguridad”. No preguntás el tamaño de mercado de una salida de emergencia, pero salva vidas en incendios. Por eso, el financiamiento debe combinar fondos públicos, donaciones y propiedad comunitaria, y el éxito se mide por cuántos pueden expresarse y sobrevivir bajo presión.

9. Guerilla Interoperability (Interoperabilidad guerrillera)

Orador: Andreas Tsamados (Fileverse)

La charla de Andreas fue combativa, comparando la internet Web2 actual con una ciudad de “arquitectura hostil”, donde los gigantes controlan a los usuarios mediante jardines amurallados, DRM y bloqueo de datos. Para combatir la “Enshittification” (degradación de plataformas), propuso la “interoperabilidad guerrillera”: resistencia táctica impulsada por usuarios, usando tecnología para forzar la interoperabilidad sin permiso de las plataformas dominantes y recuperar la soberanía de datos.

Detalló el arsenal técnico para esto, especialmente ZK-TLS (Zero Knowledge Transport Layer Security). Esta tecnología permite a los usuarios generar pruebas cifradas de sus interacciones con sitios Web2 (bancos, redes sociales), trayendo datos Web2 a Web3 sin permisos. Así, los desarrolladores pueden construir apps sobre plataformas cerradas, superándolas sin esperar apertura de APIs.

Andreas aboga por una cultura de “optimismo revolucionario”, rechazando el fatalismo sobre el estado actual de internet. Mostró herramientas de Fileverse como ddocs.new y dsheets.new, alternativas descentralizadas a Google Workspace, con cifrado end-to-end, invitaciones por ENS y almacenamiento en IPFS.

La recomendación central es: no esperar que los gigantes cambien, sino usar cuentas programables, almacenamiento descentralizado y ZK para forzar alternativas. Este “derecho a reparar digital” exige a los desarrolladores aprovechar la infraestructura cerrada existente para dar mejores opciones de privacidad y soberanía, hasta que los gigantes acepten la nueva normalidad.

10. Building infrastructural resilience (Construyendo resiliencia en la infraestructura)

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

Este panel se enfocó en la capa física y de hardware. Los panelistas señalaron que si el hardware subyacente no es confiable, la privacidad del software es como construir sobre arena. Los chips actuales (como Intel SGX) sacrifican seguridad por rendimiento y son vulnerables a ataques de canal lateral. ml_sudo presentó la iniciativa Trustless TEE, que busca construir chips de hardware open source, con diseño y fabricación totalmente verificables, para enfrentar amenazas geopolíticas crecientes.

Pol Lanski (Dappnode) enfatizó la importancia del self-hosting doméstico. Aunque la UX aún no es ideal, el objetivo debe ser “cada uno corra su propio nodo”. Esto no solo descentraliza, sino que es una forma de desobediencia civil: cuando leyes como Chat Control buscan monitorear todas las comunicaciones, correr tu propio relay y servidor hace imposible la aplicación de la ley.

Sebastian (HOPR) aportó: “Los nerds protegen las redes”. Aunque se espera que todos participen, en la práctica son los pocos dispuestos a trastear con hardware y correr nodos quienes forman la primera línea de defensa. El ecosistema debe empoderar esta cultura geek y bajar las barreras de hardware para ampliar la participación.

La discusión volvió al “por qué”: en una era de deepfakes y conectividad total, solo con hardware y bases trustless podemos preservar la “humanidad” digital: saber que interactuás con personas reales y que tus datos no son robados. La resiliencia de la infraestructura es la última defensa contra el totalitarismo digital.

11. Kohaku wallet on Ethereum (Kohaku wallet en Ethereum)

Orador: Nicolas Consigny (EF)

Nicolas presentó el nuevo proyecto liderado por la Ethereum Foundation: Kohaku. Es un conjunto de primitivas enfocadas en privacidad y seguridad, con un SDK y una wallet de referencia como extensión de navegador (fork de Ambire). Kohaku no busca ser una wallet más, sino ofrecer componentes open source de alta calidad, como un “buffet” para que otros desarrolladores eleven el estándar de privacidad del ecosistema.

El punto fuerte de Kohaku es simplificar enormemente el uso de protocolos de privacidad. Integra Railgun, Privacy Pools y otros, permitiendo a los usuarios enviar activos a pools privados con un solo clic, sin configuraciones complejas. Además, Kohaku introduce un sistema de “una cuenta por dApp”, evitando que el usuario relacione la misma dirección con varias apps y reduciendo la filtración de metadatos.

En seguridad de hardware, Kohaku logró avances importantes. En colaboración con ZKnox, implementaron firmas de transacciones ZK de Railgun directamente en hardware wallets, satisfaciendo la demanda de “cold storage + privacidad”. También mostraron una capa de aplicación de hardware universal, permitiendo que la misma lógica de firma privada corra en Keystone, Keycard y hardware DIY de bajo costo.

La demo de Nicolas mostró la actitud pragmática de la EF en privacidad: no buscan cambiar el mundo de la noche a la mañana, sino construir SDKs seguros y fáciles de usar (como OpenLV), para que las wallets existentes integren soporte Tor y transacciones privadas fácilmente. Kohaku planea lanzar testnet pública en EthCC el próximo abril, marcando una nueva etapa de estandarización y modularidad en la privacidad de aplicaciones Ethereum.

12. Private voting in DAOs (Votación privada en DAOs)

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

Este panel profundizó en la necesidad de votación privada en DAOs y gobernanza real. Anthony (Aragon) fue claro: la falta de privacidad genera gobernanza falsa; bajo presión de votos transparentes, el 99% de las propuestas recibe 99% de votos positivos porque nadie quiere ser “el aguafiestas” o sufrir represalias. La votación privada protege a los votantes y permite conocer la verdadera opinión, rompiendo el “consenso falso”.

Representantes de Rarimo y Vocdoni compartieron experiencias en entornos de alto riesgo (bajo regímenes represivos). Allí, votar puede llevar a prisión, por lo que la privacidad de identidad es vital. El reto técnico es combinar identidad real (pasaporte, biometría) con privacidad on-chain, evitando ataques Sybil y asegurando que los votos no sean rastreables.

John (MACI) destacó la importancia de la anti-colusión. La votación privada no es solo anonimato, sino que debe ser “inverificable” para evitar mercados de sobornos. Si un votante puede probar a un comprador que votó por A, se crea un mercado de compra de votos. MACI (Minimum Anti-Collusion Infrastructure) busca resolver esto. Mencionó que la ronda privada de Gitcoin fue un experimento exitoso, mostrando que la tecnología (voto cuadrático + ZK identidad) está casi lista para producción.

Los panelistas creen que 2026 será clave para que los protocolos de votación privada sean integrados en herramientas DAO mainstream (Snapshot, Tally). Aunque la tecnología está lista, el mayor obstáculo es cultural: la comunidad cripto asocia “transparencia” con justicia y hasta ve los sobornos como normales en DeFi. Cambiar la narrativa y mostrar que la privacidad es la base de la democracia es la próxima tarea política.

13. From Tornado Cash to future developers protection (De Tornado Cash a la protección de futuros desarrolladores)

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

Este panel estuvo cargado de urgencia y llamados a la acción. Joan Arús compartió la historia de Sentinel Alliance, una alianza de víctimas de spyware como Pegasus. Relató cómo los equipos de Aragon y Vocdoni fueron espiados por gobiernos por desarrollar tecnología de votación resistente a la censura. La amenaza pasó de “procesar delitos pasados” a “vigilancia preventiva”, apuntando al potencial uso del código open source.

Los abogados analizaron el aumento del riesgo legal. Las leyes antiterroristas son tan amplias que cualquier intento de “alterar estructuras políticas o económicas” puede ser considerado terrorismo. Así, los desarrolladores de DeFi o herramientas de privacidad pueden ser etiquetados como terroristas sin saberlo. Fatemeh advirtió que no se puede confiar solo en la burocracia para obtener justicia; se necesitan defensas proactivas.

Marina (EUCI) trajo algo de esperanza. Compartió avances en la revisión de GDPR en la UE: tras lobby, los reguladores empiezan a reconocer la especificidad de blockchain y podrían admitir que las tecnologías de mejora de privacidad ayudan al cumplimiento de GDPR, no lo obstaculizan. Esto prueba que el advocacy político funciona.

Finalmente, el panel hizo un llamado fuerte: la industria cripto tiene miles de millones de dólares y debe dejar de gastar solo en fiestas y destinar fondos a defensa legal y lobby. Si no se construye un marco legal para proteger a los desarrolladores, cualquiera podría ser el próximo preso. No es solo un tema de cumplimiento, sino una batalla por la libertad.

14. Protocol-level privacy: Lessons from web2 (Privacidad a nivel de protocolo: lecciones de Web2)

Orador: Polymutex (Walletbeat)

Polymutex repasó la transición de HTTP a HTTPS en Web2 para ofrecer un marco valioso para la privacidad en Web3. Señaló que la internet temprana, como la blockchain actual, carecía de privacidad por razones similares: criptografía inmadura, incertidumbre regulatoria (la criptografía era considerada armamento), y alto costo de rendimiento (latencia de handshake).

Resumió cuatro etapas clave de la adopción de HTTPS: 1. Hacer la privacidad posible (estándares como SSL/TLS); 2. Hacerla legal (ganar el derecho a cifrar en tribunales); 3. Hacerla barata (instrucciones de hardware); 4. Hacerla por defecto y normal. Let’s Encrypt fue un punto de inflexión al facilitar y abaratar los certificados. El último paso fue que los navegadores marcaran HTTP como “no seguro”, estigmatizando el comportamiento no privado.

Aplicando esto a Web3, estamos bien en la etapa de “posibilidad” (estándares de privacidad), avanzando en la de “barato” (aceleración ZK y precompilados), pero con grandes retos en la etapa “legal” (caso Tornado Cash) y “simple” (integración en wallets). Falta un “momento Oh Shit” como el caso Snowden para despertar la conciencia de privacidad masiva.

La conclusión de Polymutex es que necesitamos herramientas (como WalletBeat) para monitorear el comportamiento de privacidad de las wallets (como filtraciones RPC) y empujar la privacidad como configuración por defecto. Más importante aún, la comunidad debe estigmatizar el comportamiento no privado: así como los navegadores advierten sobre HTTP, las wallets deberían advertir “esta es una transacción pública, tus finanzas serán monitoreadas”. Solo considerando anormal no proteger la privacidad, esta podrá generalizarse.

15. Privacy on Ethereum now: key challenges (Privacidad en Ethereum hoy: desafíos clave)

Oradores: Alan Scott, Max Hampshire

Alan y Max discutieron, en tono distendido, los verdaderos dolores de construir protocolos de privacidad en la primera línea. El principal reto es la narrativa: hoy, usar herramientas de privacidad (como Railgun) se asocia a actividades ilegales (“¿qué tenés que ocultar? ¿tenés miedo de la policía?”), estigmatizando a los usuarios comunes. Hay que cambiar la narrativa de “ocultar delitos” a “proteger la seguridad financiera diaria” (como no querer que todos vean tu resumen de Visa).

La fricción en la integración técnica es otro gran obstáculo. Alan mencionó que el SDK de Railgun tiene cientos de miles de líneas de código, y para protocolos DeFi mainstream como Aave, integrar algo tan grande es técnicamente difícil y riesgoso. Por eso, los protocolos DeFi prefieren que la capa de privacidad se adapte a ellos, no al revés. Además, las wallets existentes (muchas forks de Rabby) suelen estar llenas de trackers, lo que contradice los objetivos de privacidad.

Sobre privacidad de red, Max señaló que es un juego del gato y el ratón: las técnicas de deanomización (análisis de tráfico) y anonimización (mixnets) evolucionan constantemente. Solo la privacidad en la capa de aplicación no basta; si el ISP o el nodo RPC ve tu IP y patrones de acceso, la privacidad on-chain se debilita. Por eso, infraestructuras como Nym deben integrarse con los protocolos de aplicación.

Finalmente, discutieron cómo ampliar el anonymity set. Si solo las ballenas usan herramientas de privacidad, el efecto es limitado. El objetivo es que los usuarios comunes usen privacidad sin darse cuenta (plug and play), aunque solo sea para evitar ser copiados o proteger alpha. Solo cuando haya suficientes “buenos” y transacciones normales, la red de privacidad podrá proteger realmente.

16. Ethereum Privacy Roadmap (Hoja de ruta de privacidad de Ethereum)

Orador: Andy Guzman (PSE)

Andy Guzman cerró el evento con un resumen macro y perspectivas. Propuso un modelo simplificado de la pila tecnológica de privacidad de PSE: lecturas privadas, escrituras privadas y portabilidad de datos. Usó la ley del mínimo (teoría del barril): la fortaleza del sistema de privacidad depende de su eslabón más débil. Si logramos privacidad ZK perfecta on-chain pero filtramos IP en la capa RPC, el sistema falla.

En cuanto a la hoja de ruta, Andy predijo que para noviembre de 2026 (próximo Devcon), el problema de las transferencias privadas en Ethereum estará resuelto. Ya hay más de 35 equipos explorando unas 13 rutas tecnológicas (de direcciones stealth a privacy pools), y esta diversidad garantiza que emergerá una solución ganadora. El futuro traerá soluciones de bajo costo (solo el doble de una transferencia normal), baja latencia y experiencia de un clic.

Planteó una posible controversia: ¿la privacidad debe quedarse en la capa de aplicación o bajar al protocolo central (L1)? Esto podría causar una “guerra civil” en el futuro. Incluir privacidad en L1 unifica liquidez y privacidad por defecto, pero implica riesgos regulatorios y complejidad. Llamó a la comunidad a debatirlo abiertamente.

Finalmente, sobre cumplimiento, Andy mostró un espectro de “privacidad sin permisos (cypherpunk)” a “privacidad conforme (practical)”. Cree que, aunque el espíritu cypherpunk es valioso, para la adopción institucional y gubernamental se necesitan soluciones responsables como Privacy Pools. El futuro de la privacidad en Ethereum debe ser diverso e inclusivo. PSE seguirá cubriendo vacíos tecnológicos para que Ethereum sea realmente una red privacy-first.