El cofundador de Ethereum, Vitalik Buterin, cree que la resiliencia y escalabilidad a largo plazo de la cadena de bloques dependen de hacerlo simple, como Bitcoin. En una publicación de blog el 3 de mayo, describió cómo “Ethereum dentro de 5 años puede acercarse a Bitcoin”. Buterin escribió:
“Una de las mejores cosas de Bitcoin es lo maravillosamente simple que es el protocolo”.
Según Buterin, el diseño minimalista y la simplicidad de Bitcoin lo hacen accesible, de modo que incluso un estudiante de secundaria puede comprender el concepto y la arquitectura del protocolo. La simplicidad, argumentó Buterin, también trae otros beneficios, como reducir el costo de crear una nueva infraestructura y mantenimiento de la infraestructura existente, así como reducir el riesgo de errores.
Las actualizaciones recientes como la prueba de estancamiento (POS) y la integración sucinta del conocimiento del conocimiento del conocimiento (ZK-SNARK) han hecho que Ethereum sea más robusto. Sin embargo, descuidar la simplicidad del diseño se ha agregado a los costos de Ethereum. Buterin explicó:
“Históricamente, Ethereum a menudo no ha hecho esto (a veces debido a mis propias decisiones), y esto ha contribuido a gran parte de nuestro gasto excesivo de desarrollo, todo tipo de riesgo de seguridad e insularidad de la cultura de I + D, a menudo en busca de beneficios que han demostrado ser ilusorio”.
Simplificación de la capa de consenso de Ethereum
En noviembre, el investigador de la Fundación Ethereum, Justin Drake, propuso una actualización de capa de consenso llamada ‘cadena de haz’. Buterin cree que la cadena de haz está “bien posicionada para ser mucho más simple” que su predecesor anticuado, la cadena de baliza actual.
Esto se debe a que la cadena de haz permitirá un rediseño final de 3 pisos, que eliminará conceptos complejos como espacios separados, épocas y comités de sincronización, señaló Buterin. También destacó que una implementación básica de la finalidad de 3 ranuras se puede lograr a través de aproximadamente 200 líneas de código, lo que la hace mucho más simple.
La cadena de haz también reducirá el número de validadores activos a la vez, lo que haría que sea “más seguro usar implementaciones más simples de la regla de elección de la horquilla”, escribió Buterin.
La cadena de haz también incorporará protocolos de agregación basados en Stark, lo que significa que cualquiera puede ser un agregador. Buterin señaló:
“La complejidad de la criptografía de agregación en sí es significativa, pero es al menos una complejidad altamente encapsulada, que tiene un riesgo sistémico mucho menor hacia el protocolo”.
Buterin agregó que la reducción de validadores activos y la incorporación de agregadores basados en Stark “probablemente habilitará una arquitectura P2P más simple y robusta”. Continuó diciendo que existe la oportunidad de repensar y simplificar varias facetas, desde la entrada y salida de validador y la fuga de inactividad. Y esto se puede lograr tanto reduciendo el recuento de línea de código (LOC) y creando “garantías más legibles”.
Buterin destacó que la capa de consenso está “relativamente desconectada” de las ejecuciones de Ethereum Virtual Machine (EVM), que proporciona una “latitud relativamente amplia” para hacer mejoras en comparación con la capa de ejecución.
Simplificación de la capa de ejecución de Ethereum
El mes pasado, Buterin propuso reemplazar el lenguaje de contrato EVM con RISC-V para aumentar la eficiencia de hasta 100x. Buterin argumentó que la adopción de RISC-V también aumentará la simplicidad, ya que la “especificación de RISC-V es absurdamente simple en comparación con el EVM”.
Sin embargo, esto significaría garantizar que se preservan la compatibilidad hacia atrás para las aplicaciones existentes. Buterin escribió:
“Lo primero que es importante entender es: no hay una sola forma de delinear cuál es la” base de código Ethereum “(incluso dentro de un solo cliente)”.
Según Buterin, el área naranja no puede disminuir. El objetivo, afirmó Buterin, es minimizar el área verde, moviendo el código al área amarilla, que indica “un código que es muy valioso para comprender e interpretar la cadena hoy en día, o para la construcción de bloques óptimo, pero no es parte del consenso”. Buterin comparó este proceso con cómo Apple logra la compatibilidad al revés a largo plazo a través de las capas de traducción. Él escribió:
“Es importante destacar que las áreas naranjas y amarillas son complejidad encapsulada, cualquiera que quiera comprender el protocolo puede omitirlas, las implementaciones de Ethereum son libres de omitirlas y cualquier error en esas áreas no plantea riesgos de consenso”.
Esta es la razón por la cual la complejidad del código en las áreas naranjas y amarillas tiene “muchas menos desventajas” en comparación con la complejidad del código en el área verde.
Para reducir el área verde, Buterin propuso los siguientes pasos:
Fase 1: Se escribirán nuevas precompilas en RISC-V.
Fase 2: los desarrolladores tendrán la opción de escribir contratos en RISC-V.
Fase 3: Todas las precompilas se reemplazarán con implementaciones de RISC-V a través de una horquilla dura.
Fase 4: Implemente un intérprete EVM en RISC-V y presione la cadena como un contrato inteligente.
Los pasos anteriores asegurarían que el consenso de Ethereum entendiera “de forma nativa” solo RISC-V, declaró Buterin.
Estándares para la simplificación de todo el protocolo
Buterin propuso compartir “un estándar en diferentes partes de la pila” como un camino hacia la simplificación.
Por ejemplo, Buterin sugirió usar un código de borrado único para muestreo de disponibilidad de datos, transmisión P2P y almacenamiento de historial distribuido. Esto minimizaría las líneas totales de código, aumentaría la eficiencia y garantizaría la verificabilidad, argumentó.
Del mismo modo, propuso tener un solo formato de serialización compartido en las tres capas de Ethereum: capa de ejecución, capa de consenso e interfaz binaria de aplicaciones de llamadas de contrato inteligentes (ABI). Buterin sugirió usar SSZ, que es fácil de decodificar y ampliamente utilizado.
Por último, una vez que el EVM ha sido reemplazado por RISC-V u otro lenguaje simple, Buterin propone cambiar a un árbol binario del árbol hexario de Merkle Patricia, tanto para el consenso como para las capas de ejecución. Esta transición podría mejorar la eficiencia y reducir los costos, al tiempo que garantiza que se puedan acceder e interpretar todas las capas de Ethereum utilizando el mismo código, escribió Buterin.
Un cambio en el ethos
Buterin concluyó proponiendo que Ethereum, siguiendo el ejemplo de Tinygrad, adopte una línea máxima de código máxima explícita. El objetivo, reiteró Buterin, es hacer que el “código crítico de consenso de Ethereum sea tan simple como Bitcoin”.
Pero lo más importante, Ethereum necesita adoptar un ethos donde la opción más simple se elige siempre que sea posible. Esto significaría favorecer la complejidad encapsulada sobre la complejidad sistémica.
Buterin aseguró que el código que se ocupa del procesamiento de las reglas históricas de Ethereum continuará existiendo con su última propuesta. Sin embargo, dicho código debe mantenerse fuera del código crítico de consenso o el área verde.
Mencionado en este artículo
(Tagstotranslate) bitcoin
