El cofundador de Ethereum, Vitalik Buterin, cree que la resiliencia y la escalabilidad a largo plazo de la blockchain dependen de hacerla simple, al igual que Bitcoin. En una publicación de blog del 3 de mayo, describió cómo "Ethereum en 5 años podría volverse casi tan simple como Bitcoin". Buterin escribió:
"Una de las cosas más maravillosas sobre Bitcoin es que el protocolo es extremadamente simple."
Según Buterin, el diseño minimalista y la simplicidad de Bitcoin lo hacen accesible, por lo que incluso un estudiante de secundaria puede comprender el concepto y la arquitectura del protocolo. Buterin argumenta que la simplicidad también ofrece otros beneficios, como reducir los costos de crear nueva infraestructura y mantener la infraestructura existente, así como disminuir el riesgo de errores.
Las actualizaciones recientes, como la (PoS) de prueba de participación y la integración de Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) han hecho que Ethereum sea más poderoso. Sin embargo, ignorar la simplicidad del diseño ha aumentado el costo de Ethereum. Buterin explica:
"Antes, Ethereum a menudo no hacía esto ( a veces era por decisión propia ) y esto contribuyó a causar muchos costos de desarrollo excesivos, todo tipo de riesgos de seguridad y limitaciones en la cultura de I+D, a menudo para perseguir beneficios que han demostrado ser inalcanzables."
Simplificar la capa de consenso de Ethereum
En noviembre, el investigador Justin Drake de la Ethereum Foundation propuso una actualización de la capa de consenso llamada 'Beam Chain'. Buterin cree que Beam Chain "tiene una buena posición para volverse mucho más simple" en comparación con su predecesor obsoleto, la cadena beacon actual.
Esto se debe a que la cadena de rayos permitirá rediseñar la finalización de los 3 slots, lo que eliminará conceptos complejos como slots separados, eras y comités de sincronización, observó Buterin. También enfatizó que la implementación básica de la finalización de los 3 slots se puede lograr a través de aproximadamente 200 líneas de código, lo que simplifica mucho.
La cadena de rayos también reducirá el número de validadores activos en un momento dado, lo que ayudará a "utilizar implementaciones más simples de la regla de selección de rama más segura", escribió Buterin.
La cadena de rayos también combinará protocolos de agregación basados en STARK, lo que significa que cualquiera puede ser un agregador. Buterin señala:
"La propia complejidad de la criptografía compuesta es considerable, pero al menos tiene una complejidad empaquetada de manera compacta, con un riesgo sistémico mucho más bajo para el protocolo."
Buterin agregó que reducir el número de validadores activos y combinar los sintetizadores basados en STARK "podría permitir una arquitectura P2P más simple y poderosa". Continuó diciendo que hay una oportunidad para repensar y simplificar algunos aspectos, desde la entrada y salida de validadores hasta las fugas inactivas. Y esto se puede lograr reduciendo el número de líneas de código (LoC) y creando "garantías más legibles".
Buterin enfatizó que la capa de consenso está "relativamente separada" de las operaciones de ejecución de la Máquina Virtual de Ethereum (EVM), lo que proporciona un "rango relativamente amplio" para implementar mejoras con respecto a la capa de ejecución.
Simplificar la capa de ejecución de Ethereum
El mes pasado, Buterin propuso reemplazar el lenguaje de contratos EVM por RISC-V para aumentar la eficiencia hasta 100 veces. Buterin argumentó que la adopción de RISC-V también aumentaría la simplicidad, ya que "la especificación de RISC-V es ridículamente simple en comparación con EVM".
Sin embargo, esto significa que se debe garantizar la compatibilidad hacia atrás para que las aplicaciones existentes se mantengan. Buterin escribió:
"Lo primero que es importante entender es que: no hay una única forma de definir qué es "el código base de Ethereum" ( incluso en un solo cliente )."
Según Buterin, la zona naranja no puede disminuir. Buterin declaró que el objetivo es minimizar la zona verde, moviendo el código a la zona amarilla, indicando "el código es muy valioso para entender e interpretar la cadena hoy en día o para construir bloques óptimos, pero no es parte del consenso". Buterin compara este proceso con la forma en que Apple logra la compatibilidad hacia atrás a largo plazo a través de capas de compilación. Él escribe:
"Lo importante es que las áreas de color naranja y amarillo están empaquetadas de manera compleja, cualquiera que quiera entender el protocolo puede omitirlas, la implementación de Ethereum puede omitirlas y cualquier error en esas áreas no representa un riesgo para el consenso."
Esta es la razón por la cual la complejidad del código en las áreas de color naranja y amarillo tiene "muchas menos desventajas" en comparación con la complejidad del código en el área de color verde.
Para reducir el área de vegetación, Buterin propuso los siguientes pasos:
Fase 1: Los nuevos programas de compilación se escribirán en RISC-V.
Fase 2: Los desarrolladores tendrán la opción de escribir contratos en RISC-V.
Etapa 3: Todas las traducciones anteriores serán reemplazadas por implementaciones RISC-V a través de un hard fork.
Fase 4: Implementar el intérprete EVM en RISC-V y desplegarlo en la cadena como un contrato inteligente.
Buterin afirmó que los pasos anteriores garantizarán que el consenso de Ethereum "entenderá de manera "natural" RISC-V.
Estándar de protocolo para simplificar
Buterin propuso compartir "un estándar en diferentes partes de la pila" como un camino hacia la simplificación.
Por ejemplo, Buterin propuso utilizar un código de eliminación único para muestrear datos disponibles, transmitir P2P y almacenar un historial distribuido. Esto minimizaría el número total de líneas de código, aumentaría la eficiencia y garantizaría la verificabilidad, argumentó.
De manera similar, propuso que haya un formato de serialización compartido único en las tres capas de Ethereum: capa de ejecución, capa de consenso y contrato inteligente llamado Interfaz Binaria de Aplicación (ABI). Buterin propuso usar SSZ, que es fácil de decodificar y ampliamente utilizado.
Finalmente, después de que EVM sea reemplazado por RISC-V o algún otro lenguaje más simple, Buterin propone cambiar de un árbol Merkle Patricia hexario a un árbol binario, tanto para la capa de consenso como para la capa de ejecución. Esta transición podría mejorar la eficiencia y reducir costos mientras se asegura que todas las capas de Ethereum puedan ser accesibles e interpretadas con el mismo código, escribe Buterin.
Un cambio de personalidad
Buterin concluyó sugiriendo que Ethereum, siguiendo el ejemplo de Tinygrad, aplica claramente el objetivo de máxima eficiencia del código. Buterin reiteró que el objetivo es hacer que "el código crítico para el consenso de Ethereum sea casi tan simple como Bitcoin".
Pero más importante aún, Ethereum necesita adoptar un estándar en el que se elijan opciones más simples siempre que sea posible. Esto significa priorizar la complejidad empaquetada en lugar de la complejidad sistémica.
Buterin afirma que el código que maneja las reglas históricas de Ethereum seguirá existiendo con su más reciente propuesta. Sin embargo, dicho código debe mantenerse fuera del código crítico de consenso o de la zona verde.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Vitalik Buterin quiere hacer que Ethereum sea 'tan simple como Bitcoin' en 2030
El cofundador de Ethereum, Vitalik Buterin, cree que la resiliencia y la escalabilidad a largo plazo de la blockchain dependen de hacerla simple, al igual que Bitcoin. En una publicación de blog del 3 de mayo, describió cómo "Ethereum en 5 años podría volverse casi tan simple como Bitcoin". Buterin escribió: "Una de las cosas más maravillosas sobre Bitcoin es que el protocolo es extremadamente simple." Según Buterin, el diseño minimalista y la simplicidad de Bitcoin lo hacen accesible, por lo que incluso un estudiante de secundaria puede comprender el concepto y la arquitectura del protocolo. Buterin argumenta que la simplicidad también ofrece otros beneficios, como reducir los costos de crear nueva infraestructura y mantener la infraestructura existente, así como disminuir el riesgo de errores. Las actualizaciones recientes, como la (PoS) de prueba de participación y la integración de Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARK) han hecho que Ethereum sea más poderoso. Sin embargo, ignorar la simplicidad del diseño ha aumentado el costo de Ethereum. Buterin explica: "Antes, Ethereum a menudo no hacía esto ( a veces era por decisión propia ) y esto contribuyó a causar muchos costos de desarrollo excesivos, todo tipo de riesgos de seguridad y limitaciones en la cultura de I+D, a menudo para perseguir beneficios que han demostrado ser inalcanzables." Simplificar la capa de consenso de Ethereum En noviembre, el investigador Justin Drake de la Ethereum Foundation propuso una actualización de la capa de consenso llamada 'Beam Chain'. Buterin cree que Beam Chain "tiene una buena posición para volverse mucho más simple" en comparación con su predecesor obsoleto, la cadena beacon actual. Esto se debe a que la cadena de rayos permitirá rediseñar la finalización de los 3 slots, lo que eliminará conceptos complejos como slots separados, eras y comités de sincronización, observó Buterin. También enfatizó que la implementación básica de la finalización de los 3 slots se puede lograr a través de aproximadamente 200 líneas de código, lo que simplifica mucho. La cadena de rayos también reducirá el número de validadores activos en un momento dado, lo que ayudará a "utilizar implementaciones más simples de la regla de selección de rama más segura", escribió Buterin. La cadena de rayos también combinará protocolos de agregación basados en STARK, lo que significa que cualquiera puede ser un agregador. Buterin señala: "La propia complejidad de la criptografía compuesta es considerable, pero al menos tiene una complejidad empaquetada de manera compacta, con un riesgo sistémico mucho más bajo para el protocolo." Buterin agregó que reducir el número de validadores activos y combinar los sintetizadores basados en STARK "podría permitir una arquitectura P2P más simple y poderosa". Continuó diciendo que hay una oportunidad para repensar y simplificar algunos aspectos, desde la entrada y salida de validadores hasta las fugas inactivas. Y esto se puede lograr reduciendo el número de líneas de código (LoC) y creando "garantías más legibles". Buterin enfatizó que la capa de consenso está "relativamente separada" de las operaciones de ejecución de la Máquina Virtual de Ethereum (EVM), lo que proporciona un "rango relativamente amplio" para implementar mejoras con respecto a la capa de ejecución. Simplificar la capa de ejecución de Ethereum El mes pasado, Buterin propuso reemplazar el lenguaje de contratos EVM por RISC-V para aumentar la eficiencia hasta 100 veces. Buterin argumentó que la adopción de RISC-V también aumentaría la simplicidad, ya que "la especificación de RISC-V es ridículamente simple en comparación con EVM". Sin embargo, esto significa que se debe garantizar la compatibilidad hacia atrás para que las aplicaciones existentes se mantengan. Buterin escribió: "Lo primero que es importante entender es que: no hay una única forma de definir qué es "el código base de Ethereum" ( incluso en un solo cliente )." Según Buterin, la zona naranja no puede disminuir. Buterin declaró que el objetivo es minimizar la zona verde, moviendo el código a la zona amarilla, indicando "el código es muy valioso para entender e interpretar la cadena hoy en día o para construir bloques óptimos, pero no es parte del consenso". Buterin compara este proceso con la forma en que Apple logra la compatibilidad hacia atrás a largo plazo a través de capas de compilación. Él escribe: "Lo importante es que las áreas de color naranja y amarillo están empaquetadas de manera compleja, cualquiera que quiera entender el protocolo puede omitirlas, la implementación de Ethereum puede omitirlas y cualquier error en esas áreas no representa un riesgo para el consenso." Esta es la razón por la cual la complejidad del código en las áreas de color naranja y amarillo tiene "muchas menos desventajas" en comparación con la complejidad del código en el área de color verde. Para reducir el área de vegetación, Buterin propuso los siguientes pasos: Fase 1: Los nuevos programas de compilación se escribirán en RISC-V. Fase 2: Los desarrolladores tendrán la opción de escribir contratos en RISC-V. Etapa 3: Todas las traducciones anteriores serán reemplazadas por implementaciones RISC-V a través de un hard fork. Fase 4: Implementar el intérprete EVM en RISC-V y desplegarlo en la cadena como un contrato inteligente. Buterin afirmó que los pasos anteriores garantizarán que el consenso de Ethereum "entenderá de manera "natural" RISC-V. Estándar de protocolo para simplificar Buterin propuso compartir "un estándar en diferentes partes de la pila" como un camino hacia la simplificación. Por ejemplo, Buterin propuso utilizar un código de eliminación único para muestrear datos disponibles, transmitir P2P y almacenar un historial distribuido. Esto minimizaría el número total de líneas de código, aumentaría la eficiencia y garantizaría la verificabilidad, argumentó. De manera similar, propuso que haya un formato de serialización compartido único en las tres capas de Ethereum: capa de ejecución, capa de consenso y contrato inteligente llamado Interfaz Binaria de Aplicación (ABI). Buterin propuso usar SSZ, que es fácil de decodificar y ampliamente utilizado. Finalmente, después de que EVM sea reemplazado por RISC-V o algún otro lenguaje más simple, Buterin propone cambiar de un árbol Merkle Patricia hexario a un árbol binario, tanto para la capa de consenso como para la capa de ejecución. Esta transición podría mejorar la eficiencia y reducir costos mientras se asegura que todas las capas de Ethereum puedan ser accesibles e interpretadas con el mismo código, escribe Buterin. Un cambio de personalidad Buterin concluyó sugiriendo que Ethereum, siguiendo el ejemplo de Tinygrad, aplica claramente el objetivo de máxima eficiencia del código. Buterin reiteró que el objetivo es hacer que "el código crítico para el consenso de Ethereum sea casi tan simple como Bitcoin". Pero más importante aún, Ethereum necesita adoptar un estándar en el que se elijan opciones más simples siempre que sea posible. Esto significa priorizar la complejidad empaquetada en lugar de la complejidad sistémica. Buterin afirma que el código que maneja las reglas históricas de Ethereum seguirá existiendo con su más reciente propuesta. Sin embargo, dicho código debe mantenerse fuera del código crítico de consenso o de la zona verde.