Un aspecto importante, y perpetuamente subestimado, de la "falta de confianza", "pasar la prueba de abandono" y "autosuficiencia" es la simplicidad del protocolo. Incluso si un protocolo es súper descentralizado con cientos de miles de nodos, y tiene una tolerancia a fallos bizantinos del 49%, y los nodos verifican todo completamente con peerdas y starks a prueba de quantum, si el protocolo es un lío ingobernable de cientos de miles de líneas de código y cinco formas de criptografía a nivel de doctorado, en última instancia, ese protocolo falla en las tres pruebas: * No es sin confianza porque tienes que confiar en una pequeña clase de altos sacerdotes que te dicen qué propiedades tiene el protocolo. * No pasa la prueba de abandono porque si los equipos de clientes existentes se van, es extremadamente difícil para nuevos equipos alcanzar el mismo nivel de calidad. * No es autosuficiente porque si incluso las personas más técnicas no pueden inspeccionar y entender la cosa, no es completamente tuya. También es menos seguro, porque cada parte del protocolo, especialmente si puede interactuar con otras partes de maneras complicadas, conlleva un riesgo de que el protocolo se rompa. Uno de mis temores con el desarrollo del protocolo de Ethereum es que podemos estar demasiado ansiosos por agregar nuevas características para satisfacer necesidades altamente específicas, incluso si esas características inflan el protocolo o añaden tipos enteros de componentes interactivos o criptografía complicada como dependencias críticas. Esto puede ser bueno para ganancias funcionales a corto plazo, pero es altamente destructivo para preservar la autosuficiencia a largo plazo y crear una hiperestructura descentralizada de cien años que trascienda el auge y la caída de imperios e ideologías. El problema central es que si los cambios en el protocolo se juzgan desde la perspectiva de "qué tan grandes son como cambios en el protocolo existente", entonces el deseo de preservar la compatibilidad hacia atrás significa que las adiciones ocurren con mucha más frecuencia que las sustracciones, y el protocolo inevitablemente se infla con el tiempo. Para contrarrestar esto, el proceso de desarrollo de Ethereum necesita una función explícita de "simplificación" / "recolección de basura". "Simplificación" tiene tres métricas: * Minimizar el total de líneas de código en el protocolo. Un protocolo ideal cabe en una sola página - o al menos en unas pocas páginas. * Evitar dependencias innecesarias en componentes técnicos fundamentalmente complejos. Por ejemplo, un protocolo cuya seguridad depende únicamente de hashes (aún mejor: de exactamente una función hash) es mejor que uno que depende de hashes y reticulados. Incluir isogenias es lo peor de todo, porque (lo siento a los verdaderamente brillantes y trabajadores nerds que descubrieron eso) nadie entiende las isogenias. * Agregar más _invariantes_: propiedades centrales de las que el protocolo puede depender, por ejemplo, EIP-6780 (eliminación de selfdestruct) agregó la propiedad de que como máximo N slots de almacenamiento pueden ser cambiados por slot, simplificando significativamente el desarrollo del cliente, y EIP-7825 (límite de gas por transacción) agregó un máximo en el costo de procesar una transacción, lo que ayuda enormemente a los ZK-EVMs y la ejecución paralela. La recolección de basura puede ser fragmentaria, o puede ser a gran escala. El enfoque fragmentario intenta tomar características existentes y simplificarlas para que sean más simples y tengan más sentido. Un ejemplo son las reformas de costos de gas en Glamsterdam, que hacen que muchos costos de gas que antes eran arbitrarios, ahora dependan de un pequeño número de parámetros que están claramente relacionados con el consumo de recursos. Una recolección de basura a gran escala fue reemplazar PoW con PoS. Otra probablemente sucederá como parte del consenso Lean, abriendo la posibilidad de corregir un gran número de errores al mismo tiempo ( ). Otro enfoque es la "compatibilidad hacia atrás al estilo Rosetta", donde las características que son complejas pero poco utilizadas siguen siendo utilizables pero son "degradadas" de ser parte del protocolo obligatorio y en su lugar se convierten en código de contrato inteligente, para que los nuevos desarrolladores de clientes no necesiten preocuparse por ellas. Ejemplos: * Después de que actualicemos a la abstracción de cuenta nativa completa, todos los tipos de tx antiguos pueden ser retirados, y los EOAs pueden convertirse en billeteras de contrato inteligente cuyo código puede procesar todos esos tipos de transacción. * Podemos reemplazar los precompilados existentes (excepto aquellos que son _realmente_ necesarios) con código EVM o más tarde RISC-V. * Eventualmente podemos cambiar la VM de EVM a RISC-V (u otra VM más simple); EVM podría convertirse en un contrato inteligente en la nueva VM. Finalmente, queremos alejarnos de que los desarrolladores de clientes sientan la necesidad de manejar todas las versiones anteriores del protocolo de Ethereum. Eso puede dejarse a versiones anteriores de clientes que se ejecutan en contenedores de docker. A largo plazo, espero que la tasa de cambio de Ethereum pueda ser más lenta. Creo que por varias razones, en última instancia, eso _debe_ suceder. Estos primeros quince años deberían verse en parte como una etapa de adolescencia donde exploramos muchas ideas y vimos qué funciona y qué es útil y qué no. Debemos esforzarnos por evitar que las partes que no son útiles sean un lastre permanente en el protocolo de Ethereum. Básicamente, queremos mejorar Ethereum de una manera que se vea así: