Vitalik Buterin dijo que ya no está de acuerdo con su tweet de 2017 que minimizó la necesidad de que los usuarios verifiquen personalmente Ethereum de un extremo a otro.
Esta semana, argumentó que la red debería tratar la verificación autohospedada como una vía de escape no negociable a medida que su arquitectura se vuelve más liviana y modular.
La posición original de Buterin surgió de un debate de diseño sobre si una cadena de bloques debería comprometerse con el estado en la cadena o tratar el estado como “implícito”, reconstruible sólo mediante la reproducción de transacciones ordenadas.
El enfoque de Ethereum, que coloca una raíz de estado en cada encabezado de bloque y admite pruebas de estilo Merkle, permite al usuario probar un saldo, código de contrato o valor de almacenamiento específico sin volver a ejecutar todo el historial, siempre y cuando el usuario acepte la validez del consenso de la cadena bajo un supuesto de mayoría honesta.
La idea de que los usuarios promedio validen personalmente toda la historia del sistema es una extraña fantasía del montañés. Ahí lo dije. (2017)
En su nueva publicación, Buterin reformuló esa compensación como incompleta en la práctica porque aún puede obligar a los usuarios a elegir entre reproducir la cadena completa o confiar en un intermediario como un operador RPC, un servidor de datos de archivo o un servicio de prueba.
Ya no estoy de acuerdo con este tuit anterior: desde 2017, me he convertido en un conocedor de las montañas mucho más dispuesto(…) No necesitamos empezar a vivir todos los días en la cabaña del Hombre de la Montaña. Pero parte del mantenimiento del jardín infinito de Ethereum es ciertamente mantener la cabaña en buen estado. (2026)
El cambio de sentido de Vitalik en la verificación personal del historial de blockchain
Ancló el cambio en dos turnos: viabilidad y fragilidad.
En cuanto a la viabilidad, Buterin escribió que las pruebas de conocimiento cero ahora ofrecen un camino para verificar la exactitud sin “literalmente volver a ejecutar cada transacción”.
En 2017, argumentó que esto habría empujado a Ethereum hacia una menor capacidad para mantener la verificación al alcance.
El cambio es importante porque la hoja de ruta pública de Ethereum trata cada vez más a ZK como una primitiva de verificabilidad, y ethereum.org enmarca las pruebas de conocimiento cero como una forma de preservar las propiedades de seguridad y al mismo tiempo reducir lo que un verificador debe calcular.
El trabajo en las direcciones “ZK-light-client” también apunta hacia un modelo en el que un dispositivo puede sincronizarse usando pruebas compactas en lugar de confiar en una puerta de enlace siempre en línea.
En cuanto a la fragilidad, Buterin enumeró modos de falla que quedan fuera de los modelos de amenazas limpias: redes p2p degradadas, cierre de servicios de larga duración, concentración de validadores que cambia el significado práctico de “mayoría honesta” y presión de gobernanza informal que convierte “llamar a los desarrolladores” en el respaldo.
Citó la presión de la censura en torno a Tornado Cash como un ejemplo de cómo los intermediarios pueden limitar el acceso, argumentando que la opción de último recurso de un usuario debería ser “usar directamente la cadena”.
Ese marco sigue una discusión más amplia sobre el endurecimiento de la capa base de Ethereum y la limitación de la rotación, en medio de un impulso hacia la “osificación” del protocolo.
Según Buterin, la “cabaña de montaña” no es un estilo de vida predeterminado.
Es un recurso creíble que cambia los incentivos, porque el conocimiento de que los usuarios pueden salir reduce el apalancamiento de cualquier capa de servicio individual.
Ese argumento surge cuando Ethereum reduce lo que se espera que almacenen los nodos ordinarios, mientras que la historia de verificación de la red tiene que seguir el ritmo.
Historial y uso del cliente Ethereum
Los clientes de ejecución están avanzando hacia la caducidad parcial del historial, y la Fundación Ethereum dijo que los usuarios pueden reducir el uso del disco entre 300 y 500 GB eliminando los datos del bloque previo a la fusión, poniendo un nodo al alcance en un disco de 2 TB.
Al mismo tiempo, los clientes ligeros ya reflejan un modelo de confianza formalizado y optimizado para dispositivos de bajos recursos, que depende de un comité de sincronización de 512 validadores seleccionados aproximadamente cada 1,1 días.
Esos parámetros hacen que la verificación del cliente ligero sea viable a escala.
Sin embargo, también concentran la experiencia del usuario en torno a la disponibilidad de datos correctos y retransmisiones con buen comportamiento cuando las condiciones se deterioran.
El trabajo de “apatridia” a largo plazo de Ethereum tiene como objetivo reducir la necesidad de que los nodos mantengan un estado grande mientras mantienen intacta la validación del bloque.
Ethereum.org advierte que “apatridia” es un nombre inapropiado, que distingue las formas más débiles de los diseños más fuertes que siguen siendo investigación, incluida la caducidad del estado.
Los árboles Verkle se encuentran dentro de ese plan porque reducen el tamaño de las pruebas y se posicionan como un paso clave que permite la validación sin almacenar un estado grande localmente.
A medida que una mayor parte de la carga de almacenamiento se desplaza hacia afuera, ya sea hacia hosts de historial especializados u otras redes de datos, la cuestión de la seguridad se centra menos en quién puede almacenar todo y más en quién puede comprobar de forma independiente la corrección y recuperar lo que necesita cuando falla una ruta predeterminada.
| que esta cambiando | Por qué es importante para la verificación | Parámetro o figura concreta |
|---|---|---|
| Soporte de vencimiento parcial del historial en clientes de ejecución. | Un menor almacenamiento local puede aumentar la dependencia de la disponibilidad del historial externo a menos que las rutas de recuperación y verificación permanezcan abiertas. | ~300–500 GB de reducción de disco, “cómodo” en un disco de 2 TB |
| Modelo de confianza del cliente ligero PoS | La verificación de bajos recursos depende de las firmas del comité y la disponibilidad de datos a través de pares o servicios. | Comité de sincronización de 512 validadores, rota aproximadamente cada 1,1 días |
| Los árboles Verkle como habilitadores de clientes sin estado | Pruebas más pequeñas pueden hacer que la validación con menos estado almacenado sea más práctica | El marco de la hoja de ruta vincula los árboles de Verkle con los objetivos de validación sin estado |
| Distinciones en la hoja de ruta sobre apatridia | Separa los enfoques a corto plazo de los elementos de investigación como el vencimiento del estado. | Terminología de apatridia débil versus fuerte |
| EF trabaja en los fundamentos de seguridad de L1 zkEVM | El rigor y la estabilidad del sistema de prueba se convierten en parte de la historia de seguridad básica de Ethereum | Énfasis en la estabilización y la preparación para la verificación formal. |
¿Qué significa esto en el futuro?
Durante los próximos 12 a 36 meses, la pregunta práctica es si la verificación se extiende hacia afuera a medida que Ethereum externaliza más cargas de almacenamiento, o si se crean grupos de confianza en torno a nuevos puntos de estrangulamiento de servicios.
Un camino es que las billeteras y la infraestructura pasen de “confiar en el RPC” a “verificar la prueba”, mientras que la producción de pruebas se consolida en un pequeño conjunto de pilas optimizadas que son difíciles de replicar, trasladando la dependencia de una clase de proveedor a otra.
Otro camino es que la verificación basada en pruebas se vuelva ordinaria, con implementaciones de pruebas redundantes y herramientas que permitan a los usuarios cambiar de proveedor o verificar localmente cuando un punto final censura, degrada o desaparece, alineándose con los esfuerzos dirigidos a flujos de verificación livianos.
Un tercer camino es que la poda y la modularidad progresan más rápido que la verificación UX, lo que deja a los usuarios con menos opciones viables durante interrupciones o eventos de censura.
Eso haría que la “cabaña de montaña” fuera operativamente real sólo para una porción estrecha de la red.
Buterin enmarcó la cabina como la BATNA de Ethereum, rara vez utilizada pero siempre disponible, porque la existencia de una opción autosuficiente limita los términos impuestos por los intermediarios.
Cerró argumentando que mantener ese respaldo es parte del mantenimiento del propio Ethereum.
