Vitalik Buterin enmarcó el año 2026 como el año en que Ethereum revierte una década de compromisos que priorizan la conveniencia. Su tesis: el protocolo siguió siendo desconfiable, pero los valores predeterminados variaron. Wallets subcontrató la verificación a RPC centralizados.
Las aplicaciones descentralizadas se convirtieron en gigantes dependientes del servidor que filtran datos de los usuarios a docenas de puntos finales. La construcción de bloques se concentra en manos de unos pocos actores sofisticados. La capa base aguantó, pero la experiencia se convirtió en algo completamente distinto.
La respuesta es un menú concreto de correcciones de infraestructura diseñadas para hacer que el camino de la confianza minimizada sea el camino fácil.
Clientes RPC verificados que convierten a proveedores que no son de confianza en puntos finales verificables localmente. Recuperación de información privada para ocultar lo que los usuarios consultan desde los servidores que consultan. Listas de inclusión forzadas mediante elecciones bifurcadas que hacen que la resistencia a la censura sea estructuralmente ejecutable. Las listas de acceso a nivel de bloque hacen que ejecutar un nodo sea más económico y rápido.
Además, Kohaku es el vehículo de entrega de billeteras de la Fundación Ethereum para convertir la investigación de protocolos en un comportamiento de usuario predeterminado.
Helios y el problema RPC local
Hoy en día, las billeteras Ethereum enrutan casi todo a través de proveedores de llamadas a procedimientos remotos: servicios centralizados que responden consultas sobre saldos, estado y estado de las transacciones.
Helios, un cliente ligero creado con criptografía a16z, convierte datos de un RPC que no es de confianza en un RPC local verificablemente seguro. Se sincroniza en aproximadamente 2 segundos, ejecuta un servidor JSON-RPC local en el puerto 8545 y es compatible con redes Ethereum y OP Stack como Optimism y Base.
En lugar de confiar ciegamente en lo que devuelve un servidor remoto, Helios verifica pruebas criptográficas y proporciona datos verificados localmente.
La compensación es explícita: Helios todavía depende de puntos de control de subjetividad débiles para el arranque y se apoya en un punto final de ejecución ascendente para ciertas rutas de datos. Reduce la confianza, pero no la borra.
Sin embargo, el punto es la verificabilidad como una experiencia de usuario predeterminada, no como una postura de aficionado. Si las billeteras incorporan una ruta de cliente ligero verificada de forma predeterminada, la descentralización de RPC se convierte en una característica que los usuarios experimentan en lugar de una preferencia técnica que deben configurar.
El esfuerzo de la billetera Kohaku, respaldado por la Fundación Ethereum, planea explícitamente enviarse con Helios integrado.
PIR, ORAM y el problema de la fuga de metadatos
Los pagos privados son inútiles si cada verificación de saldo e interacción con dapp filtra metadatos a servidores que pueden monetizar los patrones de acceso.
La recuperación de información privada y la RAM ajena son herramientas criptográficas diseñadas para ocultar lo que los usuarios consultan a los proveedores que consultan. La hoja de ruta de privacidad de Vitalik describe una progresión desde entornos de ejecución confiables hacia PIR como el final de las lecturas privadas.
El equipo de Exploraciones de Privacidad y Escalamiento enmarca claramente el desafío de escala: un intento con aproximadamente 33 millones de hojas equivale aproximadamente a 1 gigabyte, y PIR apunta a reducir el ancho de banda por consulta al rango de kilobytes, con importantes compensaciones computacionales del lado del servidor.
Esto todavía es investigación e ingeniería temprana. El lenguaje de alrededor de 2026 debería presentar PIR y ORAM como trayectorias y prototipos, en lugar de algo que los usuarios tienen hoy.
Sin embargo, el ángulo de visión de futuro es estructural: las lecturas privadas son la mitad faltante de la experiencia de privacidad del usuario.
La hoja de ruta de Kohaku incluye explícitamente la abstracción del servicio de privacidad como entregable de la primera fase, lo que indica que las herramientas del lado de la billetera para lecturas privadas están pasando de la teoría a la implementación.
FOCIL y la inclusión exigible
La centralización de los constructores es el retroceso más visible en las garantías de inclusión de transacciones de Ethereum. Unos pocos constructores sofisticados dominan la producción de bloques, y la resistencia a la censura se degrada cuando la inclusión depende de su cooperación.
Las listas de inclusión forzadas por elección de bifurcación, formalizadas como EIP-7805, son la respuesta estructural.
Un comité de 16 validadores produce listas de inclusión, que son pequeños lotes de transacciones que deben incluirse en el siguiente bloque. Los constructores y proponentes que ignoran la lista se enfrentan a una penalización por elección bifurcada: los verificadores no votarán por bloques que violen las restricciones de inclusión.
El tamaño máximo por lista de inclusión es de ocho kilobytes.
FOCIL está explícitamente motivado por el dominio de los constructores. El fundamento del EIP establece que unos pocos constructores que controlan la producción de bloques degradan la resistencia a la censura, y que las listas de inclusión impuestas mediante elección de bifurcación permiten que el conjunto de validadores fuerce la inclusión incluso cuando la construcción de bloques está centralizada.
El mecanismo importa más a medida que los flujos de transacciones privadas, como la abstracción de cuentas y los mempools privados, se vuelven comunes, porque esos flujos son más fáciles de censurar en la capa de construcción si no existe una garantía de inclusión estructural.
FOCIL es actualmente un borrador y el EIP analiza explícitamente las preocupaciones sobre el ancho de banda y la denegación de servicio que aún deben resolverse.
Listas de acceso a nivel de bloque y el problema de sincronización
Administrar un nodo pasó de ser fácil a difícil a medida que el estado crecía y los costos de ejecución aumentaban.
Las listas de acceso a nivel de bloque, formalizadas como EIP-7928, son tuberías que hacen que los nodos sean más baratos de ejecutar y más rápidos de sincronizar.
El bloque registra a qué cuentas y ranuras de almacenamiento se accedió, junto con los valores posteriores al estado, lo que permite lecturas de disco paralelas, validación de transacciones paralelas, cálculo de raíz de estado paralelo y actualizaciones de estado sin ejecución.
Un punto de referencia inicial ampliamente difundido en el hilo de Ethereum Magicians informa una mejora de aproximadamente el 30% en la sincronización en vivo con Geth usando una variante BAL inicial, aunque el resultado es preliminar.
Los equipos de clientes están tratando los BAL como una prioridad. Un problema de seguimiento de Besu etiqueta a EIP-7928 como relacionado con Glamsterdam, el término general para el grupo de actualización anticipado de Ethereum para 2026, y describe por qué es importante para la ejecución paralela y la curación de sincronización instantánea.
Los BAL son una infraestructura aburrida, pero la infraestructura aburrida es lo que empuja a Ethereum a volver a “ejecutar un nodo es normal”.
Kohaku y la implementación de referencia.
Kohaku es el esfuerzo de la Fundación Ethereum para convertir la investigación de protocolos en valores predeterminados de billetera. La tercera actualización del protocolo describe a Kohaku como un SDK más una billetera de referencia para usuarios avanzados, comenzando con una extensión del navegador para reducir las suposiciones de confianza.
La primera fase se entrega con un cliente ligero Helios, abstracción de servicios de privacidad, direcciones privadas y saldo privado y flujos de envío.
La hoja de ruta aclara que la billetera de referencia no está orientada al consumidor, sino más bien una bifurcación de Ambire diseñada para demostrar cómo se ven en la práctica la privacidad por defecto y la RPC verificada por defecto.
La hoja de ruta también enumera explícitamente la abstracción de cuentas nativas como una dependencia y establece que el equipo trabajará para lograrlo en 2026.
Kohaku es la capa de “hacerlo real”. Si el RPC verificado, las lecturas privadas y los patrones de recuperación más seguros permanecen en los artículos de investigación y en los EIP, no cambian el comportamiento del usuario. Si incluyen funciones de billetera predeterminadas en un SDK de código abierto que otras billeteras pueden adoptar, cambian la línea de base.
Verificación sin reejecución
Las pruebas de máquinas virtuales Ethereum de conocimiento cero en la capa 1 a menudo se enmarcan como una historia de escalamiento, pero el sitio zkEVM de la Fundación Ethereum las enmarca como un mecanismo de protección de descentralización.
Hoy en día, cada validador vuelve a ejecutar cada transacción para verificar la cadena. En un mundo zkEVM, los validadores verifican una prueba barata, pasando de la ejecución N de N a la prueba 1 de N.
El desafío principal es lograr un bloqueo completo en el espacio de 12 segundos, y la hoja de ruta de investigación de zkEVM trata los incentivos y la resistencia a la censura como preocupaciones de primera clase.
Es por eso que Vitalik agrupa “los nodos completos se vuelven más fáciles” con zkEVM y BAL al mismo tiempo. Si la prueba es barata y la verificación es más barata, el costo de la participación sin confianza disminuye.
Si el mercado de proveedores se concentra, el problema de confianza reaparece en una capa diferente. La hoja de ruta de zkEVM trata explícitamente ese riesgo como un flujo de trabajo central.
| corte de confianza | Lo que se rompió (derivación predeterminada) | Arreglar (mecanismo) | Especificación/número concreto (de su texto) | Estado | Compensación/riesgo clave |
|---|---|---|---|---|---|
| Helios (RPC verificado) | Carteras predeterminadas a confiar en RPC centralizados para lecturas (saldos/estado), convirtiendo “verificar” en una opción de suscripción. | Cliente ligero que verifica datos de un canal ascendente que no es de confianza y lo sirve como RPC locales. | ~2s de sincronización, JSON-RPC local: 8545usos puntos de control de subjetividad débiles. | Vivo / utilizable | todavía necesita confianza inicial (subjetividad débil) y puede depender de una punto final de ejecución ascendente para algunos caminos. |
| Lecturas privadas (PIR / ORAM) | Fugas de uso de Dapp metadatos y patrones de acceso a RPC y middleware (incluso si los pagos son privados). | Técnicas criptográficas/de sistemas para ocultar lo que preguntaste desde el servidor (PIR/ORAM). | ~33 millones de hojas ≈ ~1 GB de intentosobjetivos PIR KB/consultacon computación pesada del lado del servidor. | Investigación / primeros prototipos | Los costos se trasladan a los servidores (cómputo), la complejidad de la ingeniería y probablemente compensaciones entre latencia y UX en implementaciones tempranas. |
| FOCIL (EIP-7805) | Construcción de bloques concentrada; las garantías de inclusión se volvieron dependientes de unos pocos actores, debilitando resistencia a la censura en la práctica. | Elección de horquilla impuesta listas de inclusión: el comité publica las transacciones que deben incluirse o los bloques serán penalizados. | Comité = 16, lista de inclusión máxima = 8 KiB. | Borrador (EIP) | Nuevas superficies DoS/ancho de banda; comité + lista, el tamaño, la propagación y la aplicación necesitan límites estrictos. |
| BAL (EIP-7928) | Ejecutar un nodo se volvió más difícil a medida que aumentaron los costos de estado/ejecución; las cargas de sincronización/verificación aumentaron. | Listas de acceso a nivel de bloque: registro del estado accedido + estado posterior para habilitar paralelización y sin ejecución Actualizar rutas. | “Actualizaciones de estado sin ejecución”; reclamo temprano: ~30% de mejora en la sincronización en vivo (preliminar) en Geth. | Prototipo / EIP en progreso | Datos adicionales/complejidad; “30%” es preliminar; Las ganancias reales dependen de la adopción del cliente + finalización de las especificaciones. |
| Kohaku (pista de ejecución de billetera) | Incluso una buena investigación de protocolos no cambia la realidad si las billeteras siguen utilizando infraestructura centralizada + UX con fugas. | Respaldado por EF SDK + billetera de referencia enviar “recortes de confianza” como valores predeterminados (RPC verificado + plomería de privacidad). | “Se envía con Helios”, “abstracción del servicio de privacidad”, “dependencia nativa de AA (trabajará hasta 2026)”. | Prototipo / hoja de ruta | No orientado al consumidor; La adopción depende de que otras billeteras integren los cronogramas AA nativos de SDK +. |
| zkEVM en L1 | Requiere verificación reejecución por cada validadorelevando los costos y dejando fuera de su alcance la participación minimizada en la confianza. | Cambiar de Ejecución N de N → demostración 1 de N; Los validadores verifican pruebas baratas en lugar de volver a ejecutarlas. | probar dentro espacio de 12 segundos; riesgo: concentración del mercado demostrador recrea puntos de estrangulamiento centrales. | Investigación/hoja de ruta | Restricción de prueba dura en tiempo real + diseño de incentivos; La “confianza” puede migrar a la capa de prueba si los mercados se centralizan. |
¿Qué significa esto?
El escenario base para 2026 es que el RPC verificado se convierta en una opción de billetera, los BAL avancen a través de prototipos de clientes y FOCIL permanezca en el borrador hasta que los riesgos estén mejor delimitados.
El escenario de aceleración es que Glamsterdam aterrice con BAL, las billeteras integren RPC verificado de forma predeterminada y la “confianza en RPC” deje de ser una suposición silenciosa.
El escenario de riesgo es que zkEVM y los mercados de prueba escale pero se concentren, recreando retransmisiones centralizadas en la capa de prueba y cambiando el problema de confianza sin resolverlo.
El mensaje de Vitalik estaba dirigido a la comunidad de constructores de Ethereum, pero las tuberías que describió son las mismas que determinan si la soberanía propia y la falta de confianza son propiedades del protocolo o afirmaciones de marketing.
El retroceso fue real. La reversión está comenzando.
