Vitalik Buterin: El desarrollo del protocolo de Ethereum requiere introducir funciones de simplificación y "recolección de basura" para evitar la hinchazón

PANews 18 de enero de 2024: Vitalik Buterin publicó en la plataforma X que, “confianza cero”, “pasar la ‘prueba de salida’” y la “autonomía propia” son aspectos importantes y subestimados a largo plazo del simplificación de protocolos. Incluso si un protocolo cuenta con decenas de miles de nodos, tiene una tolerancia a fallos bizantinos del 49% y los nodos verifican todo mediante peerdas y starks resistentes a la computación cuántica, si dicho protocolo está compuesto por decenas de miles de líneas de código y cinco tipos de criptografía de nivel doctoral, terminará fallando en las tres pruebas: No es confiable, porque los usuarios deben confiar en una pequeña élite de funcionarios superiores para conocer las propiedades del protocolo. No pasa la “prueba de salida”, porque si el equipo del cliente actual se retira, es muy difícil para un nuevo equipo alcanzar el mismo nivel de calidad. No tiene soberanía propia, porque incluso las personas con mayor capacidad técnica no pueden inspeccionarlo ni entenderlo, por lo que no pertenece completamente a los usuarios. Al mismo tiempo, su seguridad también es baja, ya que cada parte del protocolo, especialmente cuando interactúa de manera compleja con otras partes, presenta riesgos de colapso del protocolo. Una preocupación que tengo respecto al desarrollo del protocolo de Ethereum es que quizás estamos demasiado ansiosos por agregar nuevas funciones para satisfacer necesidades altamente específicas, incluso si estas funciones hacen que el protocolo sea inflado o añaden nuevos tipos de componentes de interacción o criptografía compleja como dependencias clave. Esto puede ser beneficioso a corto plazo para el incremento de funciones, pero es altamente destructivo para mantener la soberanía a largo plazo y crear una superestructura descentralizada que trascienda las eras de imperios e ideologías. El problema central es que, si evaluamos los cambios en el protocolo desde la perspectiva de “cuánto afectan a la versión actual”, el deseo de mantener la compatibilidad hacia atrás implica que las adiciones superan en número a las eliminaciones, y el protocolo inevitablemente se inflará con el tiempo. Para abordar esto, el proceso de desarrollo de Ethereum necesita una función clara de “simplificación” o “recolección de basura”. La “simplificación” tiene tres criterios:

1. Minimizar la cantidad total de líneas de código del protocolo.
2. Evitar dependencias innecesarias en componentes técnicos fundamentalmente complejos.
3. Añadir más invariantes: propiedades centrales en las que el protocolo puede confiar, como EIP-6780 (eliminación de selfdestruct), que permite cambiar como máximo N registros por bloque, simplificando enormemente el desarrollo del cliente. La recolección de basura puede ser dispersa o a gran escala. La aproximación dispersa intenta simplificar funciones existentes para hacerlas más limpias y racionales. Un ejemplo de recolección de basura a gran escala es reemplazar PoW por PoS. Otra estrategia es la “compatibilidad hacia atrás estilo Rosetta”, donde funciones complejas pero poco usadas permanecen disponibles, pero se degradan a código de contratos inteligentes en lugar de formar parte del protocolo obligatorio, evitando que los nuevos desarrolladores tengan que gestionarlas. Por ejemplo, tras la actualización a la abstracción de cuentas completamente nativa, todos los tipos de transacciones antiguos pueden ser eliminados; reemplazar los precompilados existentes con código EVM o RISC-V; y eventualmente cambiar la máquina virtual de EVM a RISC-V. Finalmente, espero que los desarrolladores de clientes ya no tengan que gestionar todas las versiones antiguas del protocolo de Ethereum. A largo plazo, la velocidad de cambios en Ethereum debería desacelerarse, y se debe evitar que las partes inútiles se conviertan en una carga permanente para el protocolo.