jakiro
Fuente: David C, Bankless; Compilación: Deng Tong, Visión de Bittain
Después de que la Fundación Ethereum anunció recientemente su expansión de L1, Vitalik publicó un artículo el viernes titulado «Simplificando L1», explicando cómo Ethereum simplifica y fortalece su capa subyacente para hacer frente al desarrollo a largo plazo.
Para Vitalik, la escalabilidad no es suficiente: si Ethereum quiere ser una «plataforma para almacenar activos y registros civilizados», también debe ser fácil de entender, mantener y asegurar.Él cree que es hora de abandonar las arquitecturas hinchadas, repensar los sistemas de núcleo y reemplazar EVM con sistemas más simples.Su objetivo es construir un Ethereum que sea casi tan simple como Bitcoin en cinco años.
Lo siguiente es TL; DR: cubre ideas centrales, como simplificar el consenso y la ejecución.
¿Por qué es importante la simplicidad?
Para Vitalik, la simplicidad no solo significa que el código es más conciso, sino que también hace que Ethereum sea más poderoso.Cuanto más personas puedan entender y usar el protocolo, más segura y descentralizada será, y más adaptable será.
Tomó Bitcoin como ejemplo: su capa básica es muy simplificada, e incluso los estudiantes de secundaria (él cree) pueden construir un cliente.Esta simplicidad lo ayuda a mantener la estabilidad, la auditabilidad extensa y es difícil de destruir.
Por el contrario, Ethereum aumenta gradualmente la complejidad con el tiempo, a veces necesaria, pero a menudo no.Esta complejidad ralentiza la escalada, aumenta los riesgos y hace que las contribuciones sean más difíciles.
La simplificación ahora desbloquea ventajas clave:
-
Más fácil de verificar y asegurar:Menos código significa menos vulnerabilidades o ataques para ocultar espacio.
-
Carga de mantenimiento más baja:Menos sistemas heredados hacen que las futuras actualizaciones sean más suaves.
-
Un grupo de colaboradores más amplio:Los diseños más simples pueden atraer a más desarrolladores para participar.
-
Neutralidad más fuerte:Las reglas claras y predecibles son más difíciles de manipular o politizar.
Con la red estable y lista para madurar, Vitalik cree que es hora de limpiar la redundancia.
1. Una capa de consenso más simple
Para simplificar el consenso, Buterin señaló la nueva propuesta de cadena de haz que aboga por reemplazar sistemas antiguos y complejos con un diseño más limpio:
-
Un núcleo más aerodinámico con finalidad de tres ranuras:Elimine los sistemas técnicos como ciclos, reorganizaciones del comité y comités de sincronización para que los motores de consenso sean más fáciles de entender, auditar y mantener.
-
Reglas de selección de horquillas más fáciles:Reduzca el número de validadores activos en cualquier momento, reduzca la complejidad de decidir qué cadena de versiones seguir y mejorar la seguridad.
-
Recopilación de votación más simple (basada en Stark):Haciendo que sea más fácil y más económico recopilar votos de validador sin confiar en participantes específicos o procesar datos duplicados.
-
Un ciclo de vida de validador más claro:Haga que la unión, la salida, las actualizaciones de clave y la recuperación fuera de línea de validador sean más directos, reduzcan los casos de borde y ayuden a la red a definir una ventana de seguridad más clara.
-
Comunicación simplificada entre pares:Menos componentes de protocolo hacen que los nodos sean más fáciles de conectar, sincronizar y mantenerse consistentes.
2. Capa de ejecución más simple
Vitalik reitera el apoyo para reemplazar la máquina virtual actual de Ethereum EVM con una alternativa más simple y moderna a RISC-V, que él cree que está hinchada y dificulta la escalabilidad.
Para aquellos que se perdieron nuestro artículo sobre RISC-V, esta máquina virtual universal podría considerarse como una versión de hardware de Linux: un plan de código abierto ordenado que ha sido utilizado por compañías como Intel y Arm para construir chips.En Ethereum, servirá como un nuevo motor de contrato inteligente, ofreciendo las siguientes ventajas:
-
Especificación de máquina virtual más simple:Es más fácil de entender que EVM, reduce los errores, es más conveniente de actualizar y es más adecuado para el mantenimiento a largo plazo.
-
Menos atajos de casos menos especiales (precompilado):Reemplace la mayoría de las funciones incorporadas con un código de contrato inteligente regular, agilice el protocolo básico y facilite la mantenimiento.
-
Ya utilizado en ZK:Debido a que RISC-V acelera la prueba de conocimiento cero, ha sido adoptado por proyectos como Polygon, RISC Zero y SP1.
-
Lenguaje más flexible:Los desarrolladores pueden usar idiomas como óxido o movimiento, no solo solidez.
Vitalik ve esto como una oportunidad para reconstruir mejor la base, mejorando potencialmente su rendimiento en 100 veces.
3. Transición compatible hacia atrás
¿Qué sucede con todas las aplicaciones y herramientas que aún dependen de EVM?Vitalik ha desarrollado un plan de transición por etapas que tiene como objetivo mantener todo en funcionamiento sin dejar los protocolos subyacentes para siempre.
El objetivo es mover las características heredadas del protocolo central, que aún son válidos pero no arrastrarán a Ethereum hacia abajo.Al igual que almacenar archivos antiguos en la nube, todavía están disponibles si es necesario, pero no ocupan su espacio de escritorio.Esto mantiene el protocolo central optimizado mientras se conserva la compatibilidad con todo el contenido de compilación existente. Su sugerencia es la siguiente:
-
Comience con la precompilación de RISC-V:Las nuevas características se construirán utilizando RISC-V para que el ecosistema se adapte mejor a las máquinas virtuales.
-
Admite dos máquinas virtuales:Durante el período de transición, los desarrolladores pueden implementarse en EVM o RISC-V y lograr una compatibilidad cruzada completa.
-
Reemplace el código precompilado con el código RISC-V:Reemplace la mayoría de las funciones incorporadas con un código RISC-V simple en cadena para reducir el hinchazón de protocolo.
-
Encapsular el EVM en el contrato:Migrar el EVM a un contrato inteligente RISC-V significa que la lógica antigua aún puede funcionar, pero no interfiere con las partes más sensibles del protocolo.
De esta manera, Ethereum puede limpiar su base sin destruir la base ya establecida.
4. Compartir estándar = reducir la complejidad
por fin,Vitalik espera simplificar Ethereum estandarizando las herramientas en toda la red.
Actualmente, diferentes partes del protocolo a menudo resuelven el mismo problema de maneras ligeramente diferentes, principalmente porque los equipos individuales los construyen individualmente.Unificar estas partes en estándares compartidos reduce la complejidad y hace que toda la pila sea más fácil de mantener. Su consejo es:
-
Sistema de codificación compartida unificada (SSZ):Ya se usa para rastrear el estado de la red en la capa de consenso.Extenderlo a través de Ethereum simplificará las herramientas y facilitará las aplicaciones de construir y conectar.
-
Método de división de datos unificados (código de error):Ethereum divide y valida los datos en múltiples aspectos: muestreo de disponibilidad de datos, transmisión de P2P y almacenamiento del historial.El uso del mismo método en todas partes puede reducir la cantidad de código, aumentar la velocidad y garantizar una verificación precisa de los datos.
-
Estructura de estado unificada (estructura de árbol):Reemplazar el árbol de datos de Merkle actualmente complejo con un árbol de datos binario más simple puede ahorrar espacio, acelerar las pruebas y ayudar a las aplicaciones livianas a funcionar de manera más eficiente.
Estos pequeños cambios pueden no sonar convincentes, pero reducen el peso total del sistema, lo que hace que Ethereum sea más fácil de ejecutar y más difícil de romper.
En general, la ventaja de Ethereum siempre es la flexibilidad, pero también se acompaña de una creciente complejidad.
La visión de Vitalik tiene como objetivo recuperar la simplicidad sin perder su poder, haciendo que Ethereum sea más aerodinámico, más claro y más fácil de construir.Si Ethereum quiere apoyar los datos y sistemas más importantes del mundo, no solo debe ser escalable, sino también para ser persistente.
Vitalik cree que,En primer lugar, necesitamos racionalizarlo.
