Ethereum mismo debe pasar la prueba de abandono. Ethereum está destinado a ser un hogar para aplicaciones sin confianza y minimizadas en confianza, ya sea en finanzas, gobernanza o en otros lugares. Debe apoyar aplicaciones que sean más como herramientas - el martillo que una vez que lo compras es tuyo - que como servicios que pierden toda funcionalidad una vez que el proveedor pierde interés en mantenerlos (o peor, es hackeado o se convierte en extractivo de valor). Incluso cuando las aplicaciones tienen funcionalidad que depende de un proveedor, Ethereum puede ayudar a reducir esas dependencias tanto como sea posible y proteger al usuario tanto como sea posible en aquellos casos donde las dependencias fallan. Pero construir tales aplicaciones no es posible en una capa base que depende de actualizaciones continuas de un proveedor para seguir siendo usable - incluso si ese "proveedor" es el proceso de todos los desarrolladores principales. Ethereum, la blockchain, debe tener las características que buscamos en las aplicaciones de Ethereum. Por lo tanto, Ethereum mismo debe pasar la prueba de abandono. Esto significa que Ethereum debe llegar a un lugar donde _podemos ossificar si queremos_. No tenemos que dejar de hacer cambios en el protocolo, pero debemos llegar a un lugar donde la propuesta de valor de Ethereum no dependa estrictamente de ninguna característica que no esté ya en el protocolo. Esto incluye lo siguiente: * Resistencia cuántica total. Debemos resistir la trampa de decir "esperemos la resistencia cuántica hasta el último momento posible en nombre de obtener más eficiencias por un tiempo más largo". Los usuarios individuales tienen ese derecho, pero el protocolo no debería. Poder decir "el protocolo de Ethereum, tal como está hoy, es criptográficamente seguro durante cien años" es algo a lo que debemos esforzarnos por llegar lo antes posible, y insistir en ello como un punto de orgullo. * Una arquitectura que pueda expandirse a una escalabilidad suficiente. El protocolo necesita tener las propiedades que le permitan expandirse a miles de TPS con el tiempo, notablemente la validación ZK-EVM y el muestreo de datos a través de PeerDAS. Idealmente, llegamos a un punto donde la escalabilidad adicional se realiza a través de cambios "solo de parámetros" - y idealmente _esos_ cambios no son bifurcaciones al estilo BPO, sino que se realizan con el mismo mecanismo de votación de validadores que usamos para el límite de gas. * Una arquitectura de estado que pueda durar décadas. Esto significa decidir e implementar cualquier forma de falta de estado parcial y expiración de estado que nos permita sentirnos cómodos dejando que Ethereum funcione con miles de TPS durante décadas, sin romper la sincronización o los requisitos de disco duro o I/O. También significa preparar el árbol y los tipos de almacenamiento para que funcionen bien con este entorno a largo plazo. * Un modelo de cuenta que sea de propósito general (esto es "abstracción total de cuentas": alejarse de la ECDSA consagrada para la validación de firmas) * Un calendario de gas del que estemos seguros que está libre de vulnerabilidades de DoS, tanto para la ejecución como para la prueba ZK * Un modelo económico de PoS que, con todo lo que hemos aprendido en el último medio decenio de prueba de participación en Ethereum y una década más allá, estemos seguros de que puede durar y permanecer descentralizado durante décadas, y apoya la utilidad de ETH como colateral sin confianza (por ejemplo, en stablecoins respaldadas por ETH minimizadas en gobernanza) * Un modelo de construcción de bloques del que estemos seguros que resistirá la presión de centralización y garantizará la resistencia a la censura incluso en entornos futuros desconocidos Idealmente, hacemos el trabajo duro en los próximos años, para llegar a un punto donde en el futuro casi toda la innovación futura pueda ocurrir a través de la optimización del cliente, y reflejarse en el protocolo a través de cambios de parámetros. Cada año, deberíamos marcar al menos una de estas casillas, y idealmente múltiples. Hacer lo correcto una vez, basado en el conocimiento de lo que es verdaderamente lo correcto (y no comprometerse con soluciones a medias), y maximizar la robustez tecnológica y social de Ethereum a largo plazo. Ethereum va con todo. Este es el gwei.