Vitalik Buterin admite su mayor error de diseño desde 2017: ¿está tu Ethereum en riesgo?

Vitalik Buterin dijo que ya no está de acuerdo con su tuit de 2017 que minimizaba la necesidad de que los usuarios verificaran personalmente Ethereum de extremo a extremo.

Esta semana, argumentó que la red debería tratar la verificación auto-alojada como una salida de emergencia innegociable a medida que su arquitectura se vuelve más ligera y modular.

La posición original de Buterin surgió de un debate de diseño sobre si una blockchain debería comprometerse con el estado en cadena o tratar el estado como "implícito", reconstruible solo al reproducir transacciones ordenadas.

El enfoque de Ethereum, poniendo una raíz de estado en cada encabezado de bloque y admitiendo pruebas estilo Merkle, permite a un usuario probar un saldo específico, código de contrato o valor de almacenamiento sin volver a ejecutar todo el historial, siempre que el usuario acepte la validez del consenso de la cadena bajo una suposición de mayoría honesta.

En su nueva publicación, Buterin reformuló ese equilibrio como incompleto en la práctica porque aún puede acorralar a los usuarios a elegir entre reproducir la cadena completa o confiar en un intermediario como un operador RPC, un host de datos de archivo o un servicio de prueba.

El giro de Vitalik sobre la verificación personal del historial de blockchain

Ancló el cambio en dos aspectos: viabilidad y fragilidad.

Sobre la viabilidad, Buterin escribió que las Pruebas de conocimiento cero ahora ofrecen un camino para verificar la corrección 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 importa porque la hoja de ruta pública de Ethereum trata cada vez más a ZK como una primitiva de verificabilidad, con ethereum.org enmarcando las Pruebas de conocimiento cero como una forma de preservar las propiedades de seguridad mientras se reduce lo que un verificador debe calcular.

El trabajo en direcciones de "cliente ligero ZK" también apunta hacia un modelo donde un dispositivo puede sincronizarse usando pruebas compactas en lugar de confiar en una puerta de enlace siempre en línea.

Sobre la fragilidad, Buterin enumeró modos de falla que están fuera de los modelos de amenaza limpios: redes p2p degradadas, servicios de larga duración cerrando, 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 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 encuadre se alinea con una discusión más amplia sobre el fortalecimiento de la capa base de Ethereum y la limitación de cambios, en medio de un impulso hacia la "osificación" del protocolo.

En el relato de Buterin, la "cabaña en la montaña" no es un estilo de vida predeterminado.

Es un respaldo 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 llega mientras Ethereum reduce lo que se espera que almacenen los nodos ordinarios, mientras que la historia de verificación de la red debe mantenerse al día.

Uso del cliente de Ethereum e historial

Los clientes de ejecución se están moviendo hacia el vencimiento parcial del historial, y la Fundación Ethereum dijo que los usuarios pueden reducir el uso del disco en aproximadamente 300-500 GB al eliminar datos de bloques previos 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 optimizado para dispositivos de bajos recursos, confiando en un comité de sincronización de 512 validadores seleccionados aproximadamente cada 1,1 días.

Esos parámetros hacen que la verificación de clientes ligeros sea viable a escala.

Sin embargo, también concentran la experiencia del usuario en torno a la disponibilidad de datos correctos y relés que se comporten bien cuando las condiciones se deterioran.

El trabajo de "sin estado" 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 de bloques.

Ethereum.org advierte que "sin estado" es un término inapropiado, distinguiendo formas más débiles de diseños más fuertes que siguen siendo investigación, incluido el vencimiento del estado.

Los árboles Verkle se encuentran dentro de ese plan porque reducen los tamaños de las pruebas y se posicionan como un paso clave habilitador hacia la validación sin almacenar un estado grande localmente.

A medida que más de la carga de almacenamiento se desplaza hacia afuera, ya sea a hosts de historial especializados u otras redes de datos, la historia de seguridad se vuelve menos sobre quién puede almacenar todo y más sobre quién puede verificar de forma independiente la corrección y recuperar lo que necesita cuando falla una ruta predeterminada.

Lo que esto significa en el futuro

Durante los próximos 12-36 meses, la cuestión práctica es si la verificación se extiende hacia afuera a medida que Ethereum externaliza más cargas de almacenamiento, o si la confianza se agrupa en torno a nuevos puntos de estrangulamiento de servicios.

Un camino es que las wallets y la infraestructura cambien 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, moviendo 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 prueba redundantes y herramientas que permiten a los usuarios cambiar de proveedor o verificar localmente cuando un punto final censura, se 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 progresen más rápido que la UX de verificación, dejando a los usuarios con menos opciones viables durante cortes o eventos de censura.

Eso haría que la "cabaña en la montaña" fuera operativamente real solo para una porción estrecha de la red.

Buterin enmarcó la cabaña como el BATNA de Ethereum, raramente usada pero siempre disponible, porque la existencia de una opción autosuficiente restringe los términos impuestos por los intermediarios.

Cerró argumentando que mantener ese respaldo es parte de mantener Ethereum en sí mismo.

La publicación Vitalik Buterin admite su mayor error de diseño desde 2017: ¿está tu Ethereum en riesgo? apareció primero en CryptoSlate.