Vitalik advierte que la complejidad de Ethereum amenaza el diseño sin confianza

• Buterin dice que la complejidad del protocolo debilita la verificación sin confianza al obligar a los usuarios a depender de expertos en lugar de la autoinspección.
• La compatibilidad hacia atrás impulsa la acumulación de funciones innecesarias, aumentando los riesgos de seguridad a medida que se acumulan funciones no utilizadas e interacciones complejas.
• Insta a realizar una “recolección de basura” en el protocolo para reducir el código, limitar la criptografía y simplificar el desarrollo futuro de clientes.

El cofundador de Ethereum, Vitalik Buterin, emitió una advertencia directa sobre la dirección técnica de Ethereum en una publicación compartida en X el domingo 18 de enero. Escribiendo públicamente, Buterin dijo que la creciente complejidad del protocolo de Ethereum ahora amenaza la confianza sin confianza, la seguridad y la soberanía del usuario. Sus comentarios se centraron en la disciplina de gobernanza, no en los precios, la competencia o la escalabilidad de la red.

Simplicidad como base para la confianza y la salida

Según Vitalik Buterin, la simplicidad del protocolo sustenta los sistemas sin confianza más que el número de nodos o los umbrales de tolerancia a fallos. Dijo que los diseños complejos obligan a los usuarios a depender de expertos para interpretar el comportamiento del protocolo. Notablemente, esa dependencia debilita la verificación independiente, incluso cuando las métricas de descentralización parecen sólidas.

También hizo referencia a la “prueba de salida”, que mide si los nuevos equipos pueden reconstruir clientes de forma segura. Sin embargo, Buterin dijo que las bases de código hinchadas aumentan las barreras para los desarrolladores de reemplazo. A medida que crece la complejidad, la diversidad de clientes disminuye porque menos equipos pueden gestionar la carga técnica.

Buterin vinculó además la complejidad con la soberanía del usuario. Dijo que los sistemas que los usuarios no pueden inspeccionar o entender no les pertenecen completamente. En consecuencia, los protocolos ilegibles debilitan el control del usuario, independientemente de la sofisticación técnica.

Compatibilidad hacia atrás y compensaciones en gobernanza

Buterin rastreó la hinchazón de Ethereum a cómo se evalúan los cambios en el protocolo. Los desarrolladores a menudo priorizan la compatibilidad hacia atrás, lo que favorece agregar funciones sobre eliminarlas. Con el tiempo, ese desequilibrio acumula componentes no utilizados en todo el protocolo.

Sin embargo, cada función retenida aumenta el riesgo de interacción. Buterin dijo que las interacciones complejas hacen que las fallas sean más difíciles de predecir y depurar. Según él, la seguridad se erosiona a medida que los sistemas se vuelven más difíciles de razonar.

También advirtió contra las dependencias criptográficas pesadas. Los protocolos que dependen de menos primitivas siguen siendo más fáciles de auditar y asegurar. En contraste, la criptografía en capas complica la verificación y aumenta el riesgo de mantenimiento a largo plazo.

“Recolección de basura” y simplificación medida

Para contrarrestar la hinchazón, Buterin propuso una “recolección de basura” explícita en el protocolo. Esbozó tres métricas, comenzando por minimizar el total de líneas de código. Dijo que los protocolos concisos siguen siendo más fáciles de inspeccionar y mantener.

En segundo lugar, instó a limitar la dependencia de criptografía compleja. Menos supuestos, señaló, mejoran la claridad de la seguridad. En tercer lugar, enfatizó la adición de invariantes que simplifiquen el desarrollo de clientes.

Citó EIP-6780 y EIP-7825 como ejemplos. Estos cambios redujeron la complejidad de la mutación del estado y limitaron los costos de procesamiento de transacciones. También hizo referencia a limpiezas anteriores, incluida la transición de Ethereum de prueba de trabajo a prueba de participación.

Buterin describió los primeros quince años de Ethereum como experimentales. Dijo que el desarrollo futuro debería evitar llevar funciones no utilizadas hacia adelante.