Un aspecto importante, y perennialmente infravalorado, de la "falta de confianza", "superar la prueba de la salida libre" y la "autosoberanía" es la simplicidad del protocolo. Incluso si un protocolo es súper descentralizado con cientos de miles de nodos, y tiene un 49% de tolerancia a fallos bizantinos, y los nodos verifican completamente todo con peerdas y starks cuánticamente seguros, si el protocolo es un desastre incontrolable 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 las tres pruebas: * No es sin confianza porque tengas que confiar en una pequeña clase de sumos sacerdotes que te dicen qué propiedades tiene el protocolo * No pasa la prueba de la salida porque si los equipos clientes existentes desaparecen, es extremadamente difícil para los equipos nuevos alcanzar el mismo nivel de calidad * No es autosoberano porque si ni siquiera los más técnicos 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 de formas complicadas, conlleva el riesgo de que el protocolo se rompa. Uno de mis temores con el desarrollo de protocolos Ethereum es que podamos ser demasiado ansiosos por añadir nuevas funciones para satisfacer necesidades muy específicas, incluso si esas características inflan el protocolo o añaden tipos enteros de componentes interactuantes o criptografía complicada como dependencias críticas. Esto puede ser útil para ganancias funcionales a corto plazo, pero es muy destructivo para preservar la autosoberanía a largo plazo y crear una hiperestructura descentralizada de cien años que trasciende el auge y caída de imperios e ideologías. El problema principal es que si los cambios en el protocolo se juzgan desde la perspectiva de "qué tamaño tienen en cuanto a cambios respecto al protocolo existente", entonces el deseo de preservar la compatibilidad hacia atrás hace que las sumas ocurran mucho más a menudo que las restas, y el protocolo inevitablemente se hincha con el tiempo. Para contrarrestar esto, el proceso de desarrollo de Ethereum necesita una función explícita de "simplificación" / "recogida 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 de 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 retículos. Incluir isogenias es lo peor de todo, porque (perdón por los frikis realmente brillantes y trabajadores que descubrieron esas cosas) nadie entiende las isogenias. * Añadir más _invariantes_: propiedades centrales en las que el protocolo puede confiar, por ejemplo EIP-6780 (eliminación por autodestrucción) añadió la propiedad de que como máximo N ranuras de almacenamiento pueden cambiarse por ranura, simplificando significativamente el desarrollo del cliente, y EIP-7825 (tapa de gas por transferencia) añadió un máximo en el coste de procesar una transacción, lo que ayuda mucho a las ZK-EVM y la ejecución paralela. La recogida de basura puede ser fragmentada o a gran escala. El enfoque fragmentado intenta tomar características existentes y simplificarlas para que sean más simples y tengan más sentido. Un ejemplo son las reformas en el coste del gas en Glamsterdam, que hacen que muchos costes del gas que antes eran arbitrarios dependan en cambio de un pequeño número de parámetros claramente ligados al consumo de recursos. Una recogida de basura a gran escala estaba reemplazando a PoW por PoS. Es probable que ocurra otra como parte del consenso lean, abriendo la puerta para 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 complejas pero poco utilizadas siguen siendo utilizables pero se "degradan" de formar parte del protocolo obligatorio y se convierten en código de contratos inteligentes, de modo que los nuevos desarrolladores de clientes no tienen que preocuparse por ellas. Ejemplos: * Después de actualizar a abstracción nativa de cuentas completa, todos los tipos antiguos de transferencia pueden retirarse y los EOA pueden convertirse en monederos de contratos inteligentes cuyo código procese todos esos tipos de transacciones * Podemos reemplazar precompilaciones existentes (excepto aquellas que realmente se necesitan) por EVM o código RISC-V posterior * Eventualmente podemos cambiar la VM de EVM a RISC-V (u otra VM más sencilla); EVM podría convertirse en un contrato inteligente en la nueva máquina virtual. Por último, queremos alejarnos de que los desarrolladores clientes sientan la necesidad de manejar todas las versiones antiguas del protocolo Ethereum. Eso puede dejarse en versiones antiguas del cliente que se ejecutan en contenedores docker. A largo plazo, espero que la tasa de cambio hacia Ethereum pueda ser más lenta. Creo que, por varias razones, al final eso _debe_ ocurrir. Estos primeros quince años deberían considerarse en parte como una etapa adolescente en la que exploramos muchas ideas y vimos qué funciona, qué es útil y qué no. Deberíamos esforzarnos por evitar que las partes que no son útiles sean un lastre permanente para el protocolo Ethereum. Básicamente, queremos mejorar Ethereum de una manera que se parezca a esto:

2026 es el año en que recuperamos terreno perdido en términos de soberanía propia y falta de confianza. Algunas de las cosas que esto significa prácticamente: Nodos completos: gracias a ZK-EVM y BAL, volverá a ser más fácil ejecutar localmente un nodo y verificar la cadena Ethereum en tu propio ordenador. Helios: verifica realmente los datos que recibes de los RPC en lugar de confiar ciegamente en ellos. ORAM, PIR: pide datos a los RPCs sin revelar cuáles están pidiendo, para poder acceder a dapps sin que tus patrones de acceso se vendan a decenas de terceros en todo el mundo. Monederos de recuperación social y timelocks: carteras que no te hacen perder todo tu dinero si pierdes tu frase semilla, o si un atacante online o offline extrae tu frase semilla, y *además* no hacen que todo tu dinero sea por la puerta oculta por Google. Privacidad UX: realiza pagos privados desde tu cartera, con la misma experiencia de usuario que hacer pagos públicos. Resistencia a la censura de privacidad: pagos privados con el mempool ERC-4337, y pronto con AA + FOCIL nativo, sin depender del ecosistema de la radiodifusora pública. Interfazes de aplicación: usa más dapps de una interfaz onchain con IPFS, sin depender de servidores confiables que te bloquearían la recuperación práctica de tus activos si se desconectaran, y te darían una interfaz secuestrada que robaría tus fondos si los hackean aunque sea un milisegundo. En muchas de estas áreas, en los últimos diez años hemos visto un retroceso serio en Ethereum. Los nodos pasaron de ser fáciles de correr a difíciles de correr. Las dapps pasaron de páginas estáticas a gigantes complicados que filtran todos tus datos a una docena de servidores. Las carteras pasaron de enrutar todo a través del RPC, que podía ser cualquier nodo que eligieras, incluso en tu propio ordenador, a filtrar tus datos a una docena de servidores de su elección. La construcción de bloques se volvió más centralizada, poniendo las garantías de inclusión de transacciones de Ethereum a merced de un número muy reducido de constructores. En 2026, ya no. Cada compromiso de valores que Ethereum ha hecho hasta ahora —cada momento en el que podrías haber pensado, ¿realmente merece la pena diluirnos tanto en nombre de la adopción masiva?— ya no estamos haciendo ese compromiso. Será un camino largo. No conseguiremos todo lo que queremos en la próxima versión de Kohaku, ni en la próxima hard fork, ni en la que viene después. Pero convertirá a Ethereum en un ecosistema que merece no solo su lugar actual en el universo, sino uno mucho mayor. En el mundo de la computadora, no hay un señor centralizado. No hay un único punto de fallo. Solo existe el amor. Milady.