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. ...