La hoja de ruta de privacidad de Ethereum: el plan técnico de tres pasos de Vitalik Buterin

Ethereum siempre ha contado con criptografía avanzada capaz de habilitar transacciones privadas. Sin embargo, en la práctica los usuarios siguen exponiendo mucha información: el orden de las transacciones, la infraestructura de las wallets y los metadatos de red pueden revelar actividad sensible.

Para abordar ese problema, Vitalik Buterin propuso una hoja de ruta de privacidad a corto plazo centrada en cambios de ingeniería concretos que puedan implementarse sin esperar una rediseño completo del protocolo. La estrategia se basa en tres mejoras: reforzar la resistencia a la censura al incluir transacciones en bloques, rediseñar el sistema de nonces para permitir actividad paralela y reducir las filtraciones de datos a nivel de wallet e infraestructura.

1. Account Abstraction + FOCIL para reducir la censura de transacciones

El primer paso se centra en cómo se incluyen las transacciones en los bloques. Actualmente, los constructores de bloques y validadores deciden qué transacciones entran en cada bloque, lo que abre la puerta a retrasos o exclusiones selectivas.

Buterin plantea combinar Account Abstraction (AA) con Fork‑Choice Enforced Inclusion Lists (FOCIL). Este mecanismo permitiría que comités de validadores garanticen que las transacciones válidas presentes en el mempool público se incluyan dentro de un número limitado de slots, reduciendo el poder discrecional de un único proponente de bloque.

FOCIL está previsto como una de las funciones principales de la actualización de red Hegota, programada para la segunda mitad de 2026. Su diseño busca garantizar que una transacción válida no pueda ser fácilmente excluida por constructores de bloques, relays o validadores.

Para los sistemas de privacidad esto es crucial: si una transacción privada puede ser censurada o retrasada por la infraestructura de la red, la privacidad pierde gran parte de su utilidad. Garantizar su inclusión fortalece una propiedad fundamental de Ethereum: la resistencia a la censura.

2. Nonces con clave (EIP‑8250) para transacciones en paralelo

El segundo componente aborda un cuello de botella técnico del modelo actual de Ethereum.

Hoy cada cuenta utiliza un único nonce secuencial para ordenar sus transacciones. Esto evita ataques de repetición, pero también crea un problema: si una transacción se queda atascada, todas las siguientes quedan bloqueadas.

La propuesta EIP‑8250 introduce un sistema de nonces con clave (keyed nonces) que divide ese flujo en múltiples “carriles”. Cada transacción incluiría dos campos:

• nonce_key: selecciona el dominio de protección contra repetición
• nonce_seq: el número de secuencia dentro de ese dominio

Las transacciones con claves diferentes pueden avanzar de forma independiente. Así, una transacción retrasada ya no bloquea a las demás.

Esto resulta especialmente útil para protocolos de privacidad y sistemas con relayers, donde muchas acciones de usuarios diferentes pueden pasar por la misma cuenta o pipeline de transacciones. Con nonces con clave, esas operaciones pueden ejecutarse en paralelo sin interferir entre sí, mejorando tanto el rendimiento como la privacidad.

Los desarrolladores han discutido integrar EIP‑8250 en la actualización Hegota, alineándola con otros cambios estructurales en el modelo de transacciones de Ethereum.

3. Privacidad en la capa de acceso: wallets, Kohaku y lecturas privadas

El tercer paso aborda un problema menos visible pero muy importante: las filtraciones de metadatos desde las wallets y los proveedores RPC.

Incluso si las transacciones fueran privadas en la cadena, un usuario podría revelar información sensible simplemente al consultar datos del blockchain —por ejemplo, al revisar saldos, interactuar con contratos o explorar ciertas aplicaciones. Los operadores de nodos y los proveedores RPC pueden observar estas consultas y construir perfiles de comportamiento.

Por eso la hoja de ruta incluye mejoras en la capa de acceso, como nuevos marcos de wallets y herramientas para consultas privadas.

Un ejemplo es Kohaku, un conjunto modular de herramientas de privacidad para wallets de Ethereum que integra primitivas criptográficas directamente en el software de la wallet en lugar de depender de aplicaciones externas especializadas.

Kohaku busca que las funciones de privacidad estén disponibles dentro de las wallets convencionales y, al mismo tiempo, mejorar la seguridad y la verificación independiente. Algunas propuestas integran tecnologías de cliente ligero para que las wallets puedan verificar datos de la cadena por sí mismas sin depender completamente de proveedores RPC centralizados.

Al trasladar las capacidades de privacidad al nivel de la wallet, el ecosistema puede reducir su dependencia de infraestructuras que hoy observan gran parte de la actividad de los usuarios.

Cómo encaja esta hoja de ruta en la estrategia general de Ethereum

El enfoque de Buterin refleja un cambio importante en la estrategia de privacidad de Ethereum. En lugar de esperar un único protocolo perfecto, el ecosistema apuesta por mejoras incrementales en varias capas del sistema.

Estas actualizaciones apuntan a dos debilidades persistentes en muchas blockchains:

• Censura de transacciones, cuando validadores o constructores pueden excluir ciertas operaciones.
• Filtración de metadatos, cuando las consultas de wallets o infraestructuras revelan el comportamiento del usuario.

Al reforzar la inclusión de transacciones, permitir flujos paralelos y proteger el acceso a datos desde las wallets, Ethereum busca convertir la privacidad en infraestructura desplegable para aplicaciones y usuarios comunes, no solo en herramientas experimentales.

El objetivo final es un ecosistema donde individuos, empresas e instituciones puedan operar en Ethereum sin exponer cada acción públicamente, manteniendo al mismo tiempo la transparencia y verificabilidad que caracterizan a las blockchains públicas.