El momento HTTPS de privacidad de Ethereum: de herramienta defensiva a infraestructura predeterminada

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

Escrito por: ZHIXIONG PAN

Durante Devconnect Buenos Aires 2025, el Ethereum Privacy Stack se consolidó como la reunión temática de privacidad más relevante del año en el 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 mezcladores, 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.

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 alcanzado el consenso de que Ethereum debe seguir la “teoría del barril”, reparando el eslabón más débil en 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 a la transición de HTTP a HTTPS en Web2. La tecnología de privacidad no debe seguir siendo 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 ponentes señalaron que el siguiente paso es “estigmatizar el comportamiento no privado”, es decir, hacer que las transferencias públicas sean vistas como un comportamiento tan anómalo como correr desnudo en Internet.

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

Controversias clave: el espectro de cumplimiento y el riesgo de “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 defiende el espíritu cypherpunk puro, creyendo que cualquier compromiso de cumplimiento lleva inevitablemente a la censura.

Además, Andy Guzman de PSE advirtió sobre una posible “guerra civil” inminente: si las funciones de privacidad deben incorporarse al núcleo del protocolo de Ethereum (L1). Integrarlas en L1 puede aportar liquidez unificada y protección por defecto, pero también grandes riesgos regulatorios y complejidad protocolaria; esta decisión determinará 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 los debates sobre software, el evento profundizó inusualmente en las capas física y de red. Desde “ejecutar tu propio nodo” hasta la desconfianza en entornos de ejecución confiables (TEE), la comunidad comprendió 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 tipo “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”, el objetivo es 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 crear fondos de defensa legal y grupos de lobby político sólidos. Se reconoció que proteger la privacidad no es solo escribir código, sino una batalla por el control de la narrativa: hay que 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 de código abierto, el progreso tecnológico se detendrá porque nadie se atreverá a programar.

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

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

Ponentes: 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 centrarse solo en la privacidad de las transacciones (como pruebas ZK) a una visión más holística. Esta visión abarca privacidad de escritura (envío de transacciones) y de lectura (lectura de datos RPC), evitando la filtración de IP y patrones de acceso al transmitir o leer datos on-chain.

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

Vitalik explicó las dos acepciones de “censura”: censura de transacciones en la capa de aplicación y censura de acceso en la capa de red. Ethereum aspira a ser un libro mayor globalmente accesible, permitiendo a usuarios y validadores conectarse a través de transportes plug-and-play de Tor (como Snowflake) incluso bajo firewalls estatales. Esta tecnología puede disfrazar el tráfico como videollamadas WebRTC, eludiendo bloqueos. No solo es privacidad, sino resiliencia y descentralización geográfica para Ethereum como “libro mayor mundial”.

De cara al futuro, ambos debatieron la posibilidad de que los validadores de Ethereum (Stakers) ejecuten nodos relay de Tor. Como el tráfico dirigido a 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 se logra, esto reforzará enormemente la resistencia a la censura y la privacidad de Ethereum 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)

Ponente: Hsiao-Wei Wang (Ethereum Foundation)

La charla de Hsiao-Wei giró en torno a la nueva política financiera de la Ethereum Foundation (EF) y el concepto de “DefiPunk”, que busca reinyectar el espíritu cypherpunk en DeFi. Señaló que DeFi no debe ser solo una búsqueda de rendimiento, sino también resistencia a la censura, código abierto y protección de la privacidad. EF decide la asignación de fondos no solo por retorno financiero, sino reflejando los valores fundamentales de Ethereum, apoyando proyectos que promuevan el desarrollo saludable a largo plazo, en lugar de perseguir solo altos APY o atajos centralizados.

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

En cuanto a los estándares, DefiPunk enfatiza que los protocolos deben ser sin permisos (Permissionless Access), accesibles desde cualquier región; los usuarios deben tener 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 anima a los proyectos a usar frontends distribuidos, UIs independientes o 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 un financiador, sino el respaldo de esta filosofía. Animó a los usuarios a pensar como verdaderos “DefiPunks” al elegir protocolos DeFi: revisar el código, observar la transparencia en la gobernanza y comprobar la inmutabilidad de los contratos inteligentes. Esta charla desafía el estado actual de DeFi, exigiendo un retorno a la misión original de las finanzas descentralizadas: ofrecer servicios financieros no censurables a los oprimidos y no bancarizados.

3. Privacy-Aware Mechanisms for Public Goods Funding (Mecanismos de privacidad en 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 y UNICEF, y el uso de blockchain en Brasil para gestionar monedas comunitarias. En estos contextos de ayuda humanitaria y grupos vulnerables, la privacidad no es solo protección de datos, sino clave para la seguridad de los beneficiarios.

La tensión central fue el equilibrio entre “transparencia” y “privacidad”. Para los resultados de la distribución de fondos, la transparencia es necesaria para garantizar el impacto; pero en la participación, especialmente en votaciones y verificación de identidad, la privacidad es crucial. Si el voto es totalmente público, surgen mercados de soborno y presión social, distorsionando la gobernanza. Las primitivas ZK permiten verificar la elegibilidad y resultados sin revelar votos concretos, logrando gobernanza anti-colusión.

Los panelistas discutieron cómo las herramientas técnicas deben adaptarse a distintas jurisdicciones. Por ejemplo, en algunos países recolectar ciertos datos es legal, pero en otros (como Alemania) viola el GDPR. Por tanto, las herramientas globales de financiación de bienes públicos no deben intentar cumplir todas las regulaciones, sino construir infraestructuras flexibles y privacy-first para que las comunidades locales las adapten según sus necesidades.

Finalmente, se exploraron direcciones técnicas 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”. Herramientas como ZK proof de identidad y votación privada pueden prevenir ataques Sybil y proteger datos de usuarios, estableciendo 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 coste real de construir apps alineadas)

Ponente: Lefteris Karapetsas (Rotki)

Lefteris abrió con una aguda observación sobre la industria: “Si el producto es gratis, tú eres el producto”.

Señaló que las aplicaciones de Internet actuales suelen ofrecer servicios gratuitos a cambio de un “impuesto de datos”, recolectando y vendiendo datos de usuarios. Para romper este ciclo, propuso el concepto de “aplicaciones alineadas”: software que realmente sirve al usuario, respeta la soberanía de datos, prioriza lo local y no rastrea. Sin embargo, construir estas apps implica enormes desafíos de ingeniería y costes.

Puso como ejemplo su propio desarrollo, Rotki (una herramienta local de seguimiento de portafolios), describiendo los costes ocultos de las apps de privacidad. A diferencia de los SaaS, las apps locales no pueden hacer fácilmente A/B testing ni recolectar logs de errores; el desarrollador debe empaquetar binarios para múltiples sistemas operativos, gestionar migraciones de bases de datos locales y pagar costosos certificados de firma de código. Esto reduce la eficiencia y dificulta la monetización de datos, complicando el modelo de negocio.

Lefteris desaconsejó depender de donaciones o grants, pues es un callejón sin salida. Defendió que las apps de privacidad deben tener un modelo de negocio claro y cobrar directamente al usuario. Esto no solo sostiene el desarrollo, sino que educa al usuario: la privacidad tiene un coste explícito. Mediante modelos freemium, soporte empresarial o funciones premium (como análisis avanzados), los desarrolladores pueden obtener ingresos recurrentes previsibles.

Concluyó llamando a un nuevo contrato entre usuarios y desarrolladores: los usuarios deben entender que pagar no es solo por la funcionalidad, sino por un futuro sin vigilancia ni malas prácticas. Animó a los desarrolladores a valorar su trabajo y mantener la transparencia financiera para ganar la confianza de la comunidad. Construir “aplicaciones 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 disperso 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 actual se divide en verticales: privacidad on-chain (direcciones stealth, privacy pools), privacidad de red (mixnets), y la capa de experiencia de usuario (UX), considerada el puente clave para la adopción masiva.

Se discutió la relación entre “cumplimiento” y “privacidad”. Los panelistas reflexionaron sobre las limitaciones de construir herramientas solo para defenderse de la regulación. La privacidad no debe ser solo una tecnología defensiva, sino un esfuerzo comunitario colaborativo 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 todas las jurisdicciones es irreal e ingenuo. En vez de insertar cumplimiento en el protocolo (lo que suele implicar puertas traseras), es mejor construir infraestructuras de privacidad generales y dar a los usuarios el derecho de divulgación selectiva en la capa de aplicación (como View Keys). Así se protege al usuario del monitoreo 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 fuera del cripto (Tor, EFF, Signal). El mapa futuro del ecosistema debe incluir asistencia legal, hackathons, educación y organizaciones de defensa. Normalizar, socializar e incluso 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 cumpliendo sus necesidades de privacidad. La tendencia actual 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 en Ethereum, el impacto en el ecosistema de privacidad sería enorme.

En el panel, representantes de ABN Amro (banco holandés) y Etherealize compartieron los retos reales de las instituciones. No es que no quieran la liquidez global de la blockchain pública, sino que no pueden aceptar que estrategias, posiciones o datos de clientes sean totalmente públicos. A diferencia de los minoristas, las instituciones necesitan “control”: decidir quién ve qué datos y cuándo, con un control tan granular como el flujo de negocio (emisión de bonos, liquidación de préstamos, trading secundario), cada uno con diferentes requisitos de transparencia.

Francois de Polygon Miden explicó cómo resuelven esto con un modelo híbrido de cuentas (Account + UTXO): los usuarios mantienen el estado privado localmente y solo prueban la validez de la transacción en la red pública cuando es necesario. También se discutió el uso de pruebas ZK en informes regulatorios, permitiendo demostrar solvencia o cumplimiento sin revelar datos subyacentes.

Los panelistas coincidieron en que el futuro no es crear cadenas privadas aisladas, sino construir capas de privacidad sobre la blockchain pública de Ethereum. Separando autenticación (KYC/KYB), ejecución de políticas e informes regulatorios, las instituciones pueden disfrutar de la seguridad y liquidez de Ethereum manteniendo sus secretos comerciales. La madurez de esta arquitectura será clave para la adopción institucional masiva en torno a 2026.

7. Privacy Without Terrorists (Privacidad sin terroristas)

Ponente: Ameen Suleimani (0xbow)

Ameen abrió con una parábola sobre la contaminación de un lago en la Patagonia, ilustrando el dilema de Tornado Cash: cuando unos pocos (terroristas/hackers) contaminan un recurso público (privacy pool), todos (usuarios normales) son castigados. Repasó la historia de Tornado Cash, señalando que los desarrolladores no deben ser responsables de los actos ilícitos de los usuarios, pero planteó una cuestión: al usar mezcladores, los usuarios normales en realidad dan cobertura a hackers. Por tanto, la comunidad debe construir un sistema que proteja la privacidad legítima sin empoderar a criminales.

Este 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. Esto satisface las exigencias regulatorias de AML y preserva la privacidad on-chain.

Ameen detalló el mecanismo de gestión de 0xbow. El sistema introduce controles KYT (Know Your Transaction), requiriendo aprobación para depósitos. Si 0xbow detecta un depósito ilícito, puede excluirlo del conjunto conforme, pero no congelar fondos. Destacó el mecanismo de “Rage Quit”: incluso si un depósito es marcado como no conforme 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, prevista para EthCC (París). V2 soportará transferencias con direcciones stealth (Shielded Transfers), permitiendo pagos P2P dentro del pool sin necesidad de retirar a una nueva dirección como en V1. V2 intercambia parte de la fungibilidad por recuperabilidad, construyendo infraestructura de privacidad para “buenos” y evitando que los desarrolladores acaben en prisión por escribir código.

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

Ponente: 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 apenas sobreviven? Basándose en cinco años de experiencia con Matters.news (plataforma descentralizada de contenidos), reveló la desconexión entre “demanda de mercado” y “demanda de supervivencia”. Aunque los grupos marginales (disidentes, periodistas) tienen una fuerte necesidad moral de resistencia, 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.

Profundizó en la “paradoja del honeypot”: las plataformas resistentes a la censura atraen contenido sensible, concentrando riesgos. Esto atrae tanto la censura estatal como spam y ataques de fraude. 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 masivos de spam han activado sistemas antifraude automáticos en democracias, provocando bloqueos erróneos y una nueva “censura transfronteriza conjunta”.

Ante estos retos, Mashbean propuso soluciones contraintuitivas. Primero, no construir grandes plataformas únicas, sino componentes modulares (almacenamiento, identidad, pagos) reutilizables por pequeñas comunidades, evitando ser un blanco claro. Segundo, “comer tu propia comida para perros”: los desarrolladores deben usar OpSec y pagos privados de alto nivel, 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, sino como infraestructura pública tipo “salida de emergencia” o “cinturón de seguridad”. No se pregunta el tamaño del mercado de las salidas de emergencia, pero salvan vidas en incendios. Por tanto, el modelo de financiación debe combinar fondos públicos, donaciones y propiedad comunitaria; el éxito se mide por cuántos pueden expresarse y sobrevivir bajo presión, no por ingresos.

9. Guerilla Interoperability (Interoperabilidad guerrillera)

Ponente: Andreas Tsamados (Fileverse)

La charla de Andreas fue combativa, comparando la Internet Web2 actual con una ciudad llena 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, logrando interoperabilidad sin permiso de las plataformas dominantes y recuperando la soberanía de los datos.

Describió el arsenal técnico para ello, especialmente ZK-TLS (Zero-Knowledge Transport Layer Security). Esta tecnología permite a los usuarios generar pruebas criptográficas de sus interacciones con sitios Web2 (bancos, redes sociales), trayendo datos de Web2 a Web3 sin permiso. Así, los desarrolladores pueden construir apps sobre plataformas monopolísticas, superándolas sin esperar a que abran APIs.

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

El mensaje central: no esperar a que los gigantes cambien, sino usar cuentas programables, almacenamiento descentralizado y ZK para forzar alternativas. Este movimiento por el “derecho a reparar digital” exige a los desarrolladores aprovechar la infraestructura cerrada existente para ofrecer 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 centró en las capas 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 chips de hardware totalmente open source, desde el diseño hasta la fabricación, 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 “que todos ejecuten su propio nodo”, no solo por descentralización, sino como desobediencia civil: cuando leyes como Chat Control intentan monitorear todas las comunicaciones, ejecutar tu propio relay y servidor es la forma más efectiva de hacerlas inaplicables.

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

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

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

Ponente: Nicolas Consigny (EF)

Nicolas presentó un nuevo proyecto liderado por la Ethereum Foundation: Kohaku. Es un conjunto de primitivas centradas 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 “buffet” para que otros desarrolladores eleven el estándar de privacidad en el 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 cambiar con un clic y enviar activos a pools privados desde la interfaz, 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 hardware, Kohaku logró avances importantes. En colaboración con ZKnox, permite firmar 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 funcione en Keystone, Keycard e incluso hardware DIY de bajo coste.

La demo de Nicolas mostró el enfoque pragmático 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 Tor y funciones de privacidad 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 obtiene el 99% de los votos, porque nadie quiere ser el “aguafiestas” o sufrir represalias. La votación privada no solo protege al votante, sino que permite conocer la opinión real y romper el “falso consenso”.

Representantes de Rarimo y Vocdoni compartieron experiencias en entornos de alto riesgo (bajo regímenes represivos), donde 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 el anonimato del voto.

John (MACI) destacó la importancia de la anti-colusión: la votación privada debe impedir que el votante pueda probar a quién votó, evitando mercados de soborno. Si se puede generar una prueba de voto, el soborno es posible. MACI (Minimum Anti-Collusion Infrastructure) aborda este problema. Mencionó el éxito del reciente round privado de Gitcoin, demostrando que la tecnología (voto cuadrático + ZK identidad) está casi lista para producción.

Los panelistas coincidieron en que 2026 será clave para la madurez de los protocolos de votación privada y su integración 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 ve el soborno como normal en DeFi. Cambiar esta narrativa y concienciar de 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 llamado a la acción. Joan Arús relató la creación de Sentinel Alliance, una alianza de víctimas de spyware (como Pegasus). Narró cómo los equipos de Aragon y Vocdoni fueron espiados por gobiernos por desarrollar tecnología de votación resistente a la censura. Esto muestra que la amenaza ha pasado de “procesar delitos pasados” a “vigilancia preventiva”, dirigida al potencial uso del código open source.

Los abogados analizaron la escalada de riesgos legales. Las leyes antiterroristas actuales son tan amplias que cualquier intento de “alterar estructuras políticas o económicas” puede considerarse terrorismo. Así, los desarrolladores de DeFi o privacidad pueden ser etiquetados como terroristas sin saberlo. Fatemeh advirtió que no podemos confiar solo en la burocracia para la justicia, sino que debemos construir defensas proactivas.

Marina (EUCI) aportó esperanza: compartió avances en la revisión del GDPR en la UE, donde tras el lobby, los reguladores empiezan a reconocer que las tecnologías de mejora de privacidad pueden ser compatibles con el GDPR, no un obstáculo. Esto demuestra que la defensa política funciona.

Finalmente, el panel hizo un llamado: la industria cripto tiene miles de millones de dólares y debe dejar de gastar solo en eventos, invirtiendo en fondos legales y lobby. Si no se crea un marco legal para proteger a los desarrolladores, si no se lucha contra la criminalización del open source, cualquiera podría ser el próximo en ir a prisión. 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)

Ponente: Polymutex (Walletbeat)

Polymutex repasó la transición de HTTP a HTTPS en Web2, ofreciendo 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), alto coste de rendimiento (latencia de handshake).

Resumió cuatro etapas clave de la adopción de HTTPS: 1. Hacer posible la privacidad (estándares como SSL/TLS); 2. Hacerla legal (litigios por el derecho a cifrar); 3. Hacerla barata (instrucciones de hardware); 4. Hacerla por defecto y normal. La aparición de Let’s Encrypt fue un punto de inflexión, facilitando y abaratando los certificados. Finalmente, los navegadores empezaron a marcar HTTP como “no seguro”, estigmatizando el comportamiento no privado.

Llevando este marco a Web3, estamos bien en la etapa de “posibilidad” (estándares de privacidad), avanzando en la etapa “barata” (aceleración ZK y precompilados), pero aún 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 en masa.

La conclusión de Polymutex: necesitamos herramientas (como WalletBeat) para auditar el comportamiento de privacidad de las wallets (como fugas RPC) y promover la privacidad 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 vigiladas”. Solo viendo la falta de privacidad como anómala, la privacidad se generalizará.

15. Privacy on Ethereum now: key challenges (Privacidad en Ethereum hoy: retos clave)

Ponentes: Alan Scott, Max Hampshire

Alan y Max debatieron de forma distendida los retos reales al construir protocolos de privacidad. El principal es la narrativa: usar herramientas de privacidad (como Railgun) se asocia a actividades ilícitas (“¿por qué ocultas? ¿temes a la policía?”), estigmatizando al usuario común. Hay que cambiar la narrativa de “ocultar delitos” a “proteger la seguridad financiera diaria” (como no querer que todos vean tu extracto de Visa).

La fricció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; para protocolos DeFi como Aave, integrar algo tan grande es difícil y arriesgado. Por eso, los protocolos DeFi prefieren que la capa de privacidad se adapte a ellos, no al revés. Además, muchas wallets (forks de Rabby) están llenas de trackers, lo opuesto a la privacidad.

Sobre privacidad de red, Max señaló que es un juego del gato y el ratón: las técnicas de desanonimizació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 estrechamente con los protocolos de aplicación.

Finalmente, debatieron cómo ampliar el set de anonimato. Si solo las ballenas usan herramientas de privacidad, su efecto es limitado. El objetivo debe ser que los usuarios comunes las usen sin darse cuenta (plug and play), aunque solo sea para evitar copias de trading o proteger alpha. Solo cuando haya suficientes “buenos” y transacciones normales, la red de privacidad ofrecerá verdadera protección.

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

Ponente: Andy Guzman (PSE)

Andy Guzman cerró el evento con un resumen macro y perspectivas. Presentó el modelo simplificado de PSE para la pila de privacidad: lecturas privadas (Private Reads), escrituras privadas (Private Writes) y portabilidad de datos (Private Porting). Aplicando la ley del mínimo, señaló que la fortaleza del sistema 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 técnicas distintas (de direcciones stealth a privacy pools), y esta diversidad garantiza que emergerá una solución ganadora. El futuro traerá soluciones de bajo coste (solo el doble que una transferencia normal), baja latencia y experiencia de un clic.

Planteó un punto potencialmente polémico: ¿la privacidad debe quedarse en la capa de aplicación o integrarse en el protocolo central (L1)? Esto podría provocar una “guerra civil” en el futuro. Llevar la privacidad a 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)”. 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, no único. PSE seguirá cubriendo vacíos técnicos para que Ethereum sea realmente una red privacy-first.