Nota del editor: Esta tarde, en el lugar principal del evento Devcon en Bangkok, el desarrollador principal de Ethereum, Justin Drake, anunció la propuesta de cambio de capa de consenso 'más ambiciosa' de Ethereum en los últimos años: Beam Chain, que introduce una serie de tecnologías ZK para reemplazar la 'antigua' Ethereum Beacon Chain. En la reunión, Justin dijo que el desarrollo de la nueva capa de consenso podría continuar hasta 2030. Sin embargo, el mercado no parecía creerlo, y mientras se llevaba a cabo la conferencia de prensa, el precio de Ethereum cayó bruscamente. Todos parecen estar pensando: ¿Tiene la fundación otra excusa para vender monedas?

El siguiente es el texto completo del discurso:

El proyecto en el que he invertido mucho tiempo este año se llama "Beam Chain". Beam Chain es una reconfiguración de la capa de consenso que incorpora las últimas y más avanzadas ideas del plan de investigación. El objetivo es hacer la transición desde la actual Beacon Chain a este diseño de manera segura y rápida, que estará más cerca de Ethereum en su forma final.

Fuente de la imagen: Uncommons Dasong

Antes de compartir más, dos advertencias: Primero, esto es una propuesta, solo mía, y solo avanzará con consenso. Segundo, no hay un nuevo token, no hay una nueva red, seguiremos usando el mismo ticker, Vitalik fue muy claro al respecto.

En la siguiente charla, intentaré explicar una idea aparentemente loca en una propuesta razonable, a saber, rediseñar por completo la capa de consenso.

Primero que todo, me gustaría hablar sobre la gran visión del marco de Beam Chain. El alcance de Beam Chain se centra en la capa de consenso y no incluye blobs en la capa de datos y EVM en la capa de ejecución, ya que los blobs y EVM son utilizados directamente por las aplicaciones y necesitan mantener la compatibilidad hacia adelante, por lo que las oportunidades de cambiar estas dos capas son relativamente limitadas. La capa de consenso no es consumida directamente por las aplicaciones, lo que nos permite tener más margen de ajuste en este sentido.

¿Por qué Beam Chain?

Entonces, ¿por qué estoy proponiendo esta masiva refactorización de la capa de consenso ahora?

La razón principal es que Beacon Chain ya está un poco "vieja".

Hace cinco años, las "especificaciones" quedaron congeladas, y mucho ha cambiado en esos cinco años, especialmente que nuestra comprensión de nuevas perspectivas es mucho más profunda que hace cinco años. Éramos relativamente ingenuos en lo que respecta a PoW hace cinco años, pero desde entonces el mercado ha crecido rápidamente y tenemos un mejor entendimiento de los mecanismos que pueden ayudar a mitigar las externalidades negativas de MEV.

En segundo lugar, desde una perspectiva de ingeniería, ahora tenemos una tecnología muy poderosa llamada SNARKs. En los últimos cinco años, ha habido numerosos avances en la tecnología de SNARKs, aumentando las velocidades en órdenes de magnitud. Al mismo tiempo, también vimos el nacimiento de zkVMs, una tecnología increíble que permite a cualquier programador en el mundo aprovechar esta tecnología poderosa sin necesidad de conocer la criptografía o tener un profundo conocimiento de SNARKs.

Además, con el tiempo, ahora tenemos una comprensión clara de los errores que se cometieron en Beacon Chain y la deuda técnica que se acumuló. Estas deudas son muy tercas y crecerán con el tiempo.

Ahora, quizás tengamos la oportunidad de saldar esta deuda técnica. Por lo tanto, recomiendo integrar las tecnologías más avanzadas del mapa de capa de consenso en Beam Chain.

¿Qué cambios incluye Beam Chain?

A continuación, me tomaré un momento para describir qué está incluido exactamente en la hoja de ruta de la capa de consenso. Básicamente, hay nueve proyectos diferentes, y los dividí en tres categorías: producción de bloques, participación y criptografía.

Fuente: Aaros.183

El primero es la producción de bloques, que implica MEV. Actualmente existen muchos problemas de centralización a nivel de generadores de bloques y relayers. Esperamos introducir una “lista de inclusión” para mejorar significativamente la resistencia a la censura. Una vez que la lista de inclusión sea resistente a la censura, podremos separar claramente a los validadores del proceso de producción de bloques. Esto se llama separación de proponentes-generadores (PBS) e incluye ideas como funciones de ejecución.

El último elemento en la categoría de producción de bloques es ranuras de tiempo más rápidas, tal vez podamos reducir aún más las ranuras de tiempo manteniendo las actuales ranuras de 12 segundos sin cambios y asegurarnos de que incluso a través de una conexión de red doméstica, incluso si la latencia de la red es alta en Australia, los usuarios aún puedan participar como validadores y disfrutar de derechos de primera clase.

La segunda categoría es el compromiso. Los investigadores han llegado en gran medida a un consenso de que la curva actual de emisión es defectuosa y que existen oportunidades para hacer ajustes y mejorar la salud y el desarrollo a largo plazo de Ethereum. El segundo proyecto en la categoría de apuesta es reducir significativamente la cantidad de ETH requerida para convertirse en validador de los actuales 32 ETH a solo 1 ETH.

Recientemente ha habido algunas ideas sobre "Orbit". Además, otra idea que se ha discutido durante años es la finalidad de un solo slot, lo que podría acelerar significativamente el proceso de finalidad de Ethereum.

La última categoría es criptografía, que contiene dos proyectos importantes. El primer proyecto es la verificación SNARK de toda la capa de consenso en tiempo real, con soporte de hardware razonable.

Finalmente, ¿podemos hacer que la criptografía que asegura Ethereum sea sostenible y resistente a los ataques cuánticos durante décadas o incluso siglos por venir?

Aquí utilizo diferentes colores para diferenciar si los elementos en la hoja de ruta se pueden completar fácilmente o gradualmente, o si son difíciles de lograr. Los cuatro proyectos verdes en la esquina superior izquierda son proyectos que creo que se pueden y se deben implementar gradualmente en la Beacon Chain, y cuando se completen estos proyectos más pequeños, lo que queda son algunos proyectos importantes (partes rojas) que creo que son los mejores a través de un enfoque más integral.

Tomando la "Notificación de Cambio" como ejemplo, para lograr una prueba en tiempo real de Beacon Chain en hardware razonable, necesitamos cambiar la función hash, el método de firma y los métodos de serialización y Merkleización del estado. Esto será un gran cambio para Beacon Chain, por lo que tal vez haya una oportunidad para que hagamos estos ajustes junto con otras mejoras.

Una situación similar se aplica a “Faster Slots” y “Faster Finality” en los dos recuadros rojos en la parte inferior. Cuando diseñamos Beacon Chain hace cinco años, nuestro enfoque estaba en la seguridad, no en el rendimiento. Sin embargo, ahora estamos descubriendo que existen diseños que pueden mantener la seguridad que necesitamos mientras mejoran el rendimiento y aprovechan algunas mejoras de rendimiento fáciles de lograr.

Esta presentación muestra la asignación desde la hoja de ruta de la capa de consenso que acabo de mencionar hasta la hoja de ruta más amplia de Vitalik. Algunos de nuestros proyectos están en la fase Merge, algunos están en la fase Scourge, y algunos están en las fases Verge y Scourge.

El propósito principal de esta presentación es transmitir que Beam Chain no está cambiando todo el plan de ruta, sino identificando un subconjunto específico de él, acelerándolo y dándole un significado único.

Fuente: Aaros.183

Los "intervalos de tiempo más rápidos" en la hoja de ruta de la capa de consenso son nuevos, ya que las discusiones sobre intervalos de tiempo más rápidos comenzaron en 2024 y la hoja de ruta de Vitalik se actualizó por última vez en 2023.

Además de poder acelerar estos proyectos importantes, también podemos eliminar parte de la deuda técnica mencionada anteriormente. Si implementamos la finalidad de fuente única, los epoch ya no serán necesarios y los slots se podrán usar directamente. Además, el contrato de depósito actual es un poco complejo y es un legado de la fusión; infraestructuras como el comité de sincronización ya no serán necesarias una vez que se logre el SNARK en tiempo real de Beacon Chain. Esta es una oportunidad para limpiar de una sola vez.

Si está interesado en algunos de los problemas de diseño de Beacon Chain, el año pasado di una charla completa discutiendo más de 20 errores que cometimos al diseñar Beacon Chain.

Esta imagen muestra la imagen completa de nuestras actualizaciones en la capa de consenso desde su creación. Como puede ver en la esquina inferior izquierda, el génesis ocurrió en 2020, y desde entonces hemos tenido un nuevo fork cada año, y con cada fork hemos realizado mejoras incrementales en la capa de consenso.

En 2021 agregamos un comité de sincronización, en 2022 realizamos una fusión, en 2023 agregamos capacidades de retiro y fragmentación dinámica nativa, y en 2025 aumentaremos el saldo efectivo máximo.

Espéranos para seguir haciendo estas bifurcaciones incrementales durante los próximos años, tomando los proyectos de baja dificultad marcados en verde en la esquina superior izquierda del mapa de ruta.

Gradualmente nos encontraremos con un cuello de botella. Una vez que se completen todos los proyectos de baja dificultad, el resto son proyectos importantes que son difíciles de implementar gradualmente. En este momento, se necesita un "Beam Fork". Beam Fork brinda la oportunidad de dar un gran salto adelante en la capa de consenso a través de una actualización única. Piense en Beam Fork como una oportunidad de agrupación, donde múltiples actualizaciones se fusionan en una sola bifurcación, con beneficios técnicos y de gobernanza.

Esta oportunidad de procesamiento por lotes se puede llamar 'aceleracionismo solidificado'. Esto suena como un oxímoron, pero la idea básica es querer que Ethereum entre en modo de mantenimiento lo antes posible, y existe esa tensión en este momento. Sabemos que hay algunos proyectos importantes que requieren una reestructuración fundamental de Ethereum, y cuanto más se retrasen estos cambios, más lejos estará Ethereum de alcanzar un estado estable.

¿Qué tecnologías utiliza Beam Chain?

A continuación viene la segunda parte, donde presento algunas de las técnicas que se utilizarán en Beam Chain. Piense en esto como diferentes épocas del mecanismo de consenso de Ethereum: inicialmente la época de Prueba de Trabajo (POW), luego pasando a la época de Prueba de Participación (POS), y ahora posiblemente estemos entrando en una era de Prueba de Conocimiento Cero (ZK).

En la era de ZK, haremos un uso intensivo de la tecnología SNARKs. Un lugar donde ya estamos utilizando SNARKs es para proporcionar verificación de conocimiento cero para toda la Beam Chain - toda la capa de consenso - y aquí es donde los zkVMs (máquinas virtuales de conocimiento cero) son muy útiles.

Imagina que pudiéramos implementar Beam Chain en diferentes lenguajes de programación de alto nivel, como Rust y Go, y luego compilar estos lenguajes de alto nivel en bytecode que los zkVM puedan entender para lograr la verificación de SNARK sin preocuparse por los detalles de bajo nivel.

Un punto que necesita ser enfatizado es que la única parte que requiere verificación de SNARK es la Función de Transición de Estado, que es el núcleo para convertirse en un cliente de consenso. Básicamente, la función de transición de estado es una parte muy pequeña de la construcción del cliente, y la infraestructura circundante (como la red, la sincronización, la optimización de caché o las reglas de selección de bloques) no requiere verificación de SNARK.

RISC-V se ha convertido en el estándar de la industria para estos zkVM en los últimos años. RISC-V es un conjunto de instrucciones que básicamente compila código de alto nivel en instrucciones RISC-V. Ahora hay siete empresas que ofrecen zkVM RISC-V, como RISC Zero y SP1, de las cuales puede que hayas oído hablar.

Es importante tener en cuenta que esta potente tecnología también se puede utilizar en la capa de ejecución, que es una historia diferente de Beam Chain, pero es muy emocionante porque significa que podemos aumentar significativamente el límite de gas y mejorar Ethereum como escalabilidad vertical L1, pero ese es otro tema.

Otro lugar donde SNARKs se utiliza mucho en Beam Chain es en las firmas agregables. Nos gustaría tener firmas agregables resistentes a los cuánticos, y la propuesta aquí es utilizar funciones hash. Las funciones hash son resistentes a los cuánticos y se pueden utilizar como módulo básico para construir la criptografía.

Utilizaremos firmas basadas en hash, generadas por verificadores y demostradores, y también introduciremos SNARKs basados en hash que pueden comprimir miles de firmas en una sola prueba. Al combinar ambos, podemos construir una solución basada en hash resistente a los ataques cuánticos que se puede utilizar en Ethereum. Un detalle interesante es que este esquema de agregación tiene la capacidad de agregación recursiva infinita, lo que significa que los resultados de la agregación se pueden volver a agregar continuamente, lo cual no es posible actualmente con las firmas BLS y es más flexible.

La razón por la que estoy proponiendo esto hoy es que ha habido grandes mejoras en el rendimiento de la función hash SNARK en los últimos meses. Para aquellos que están al tanto, ahora hemos podido verificar esto en una computadora portátil.

Este punto de referencia se completó en una CPU MacBook Pro y ahora puede verificar 2 millones de hashes por segundo. Esta es una velocidad asombrosa, lo que significa que esta propuesta basada en hash tiene un gran rendimiento en Beam Chain. potential.

Además de zkVM y SNARKs que usaremos, también quiero enfatizar que reutilizaremos en gran medida la infraestructura existente.

Por ejemplo, la biblioteca de red libp2p, la biblioteca de serialización Simple Serialize, etc. se pueden reutilizar directamente. Lo mismo ocurre con el marco Pyspec, el marco de especificación de Python que utilizamos para escribir especificaciones formales y pruebas unitarias.

Además, la infraestructura como Protocol Guild también se puede reutilizar. Esto no existía en los primeros días de Beacon Chain, pero ahora se puede reutilizar de forma gratuita.

Del mismo modo, ahora hay varios equipos que apoyan el desarrollo de Beacon Chain. En ese momento, no teníamos un equipo cliente de consenso. Los actuales cinco equipos cliente de consenso se pueden utilizar directamente sin necesidad de reorganización.

Además, tenemos equipos dedicados responsables de operaciones combinadas, como el soporte de DevOps proporcionado por el equipo de Panda Ops, grupos de investigación de aplicaciones como el equipo de seguridad y el equipo de motivación, todos estos son recursos que se pueden aprovechar directamente.

En la última parte, quiero hablar sobre los próximos pasos y las perspectivas futuras. Un posible resultado es que a partir de 2025 entraremos en un proceso de normalización. Esto será llevado a cabo por un pequeño equipo de investigadores y puede llevar todo el año. En 2026, se iniciará el proceso de desarrollo con equipos de clientes que escribirán código de calidad de producción, seguido de un proceso de pruebas muy exhaustivo en 2027 para garantizar la seguridad y estabilidad de las implementaciones de producción.

Fuente de la imagen: Uncommons Dasong

Mi próxima tarea como investigador es comenzar a escribir una especificación ejecutable, a la que llamo un "mapa de ruta ejecutable". La idea es combinar los "píxeles" en el mapa de ruta, los cientos de miles de palabras en varios documentos de investigación y académicos, y las diversas ideas en las mentes de los investigadores, extraer su esencia principal y formar un documento de especificación ejecutable. En última instancia, este será un documento muy compacto, alrededor de 1000 líneas de código Python.

Lo emocionante para mí es que si hay un consenso general sobre la nueva dirección de Beam Chain, esta será una gran oportunidad para inyectar nueva sangre en el cliente de consenso.

Actualmente, nuestro equipo de clientes de consenso está distribuido en América del Norte, Europa y Oceanía. Hoy, me complace anunciar que un nuevo equipo ha estado dispuesto a desarrollar el cliente Beam. Uno de los equipos está en India, se llama Zine, y están escribiendo un cliente Beam utilizando el lenguaje Zig. También hay un equipo de Clase Lambda en Sudamérica que también ha expresado interés en desarrollar un cliente Beam.

Si también estás interesado en participar, necesitamos un montón de personas talentosas, incluyendo expertos en especificaciones y redes, coordinadores, expertos en criptografía y desarrolladores de clientes. Por favor, contáctanos a través de este correo electrónico para unirte a nosotros y comenzar esta nueva aventura juntos. ¡Muchas gracias!

Descargo de responsabilidad：

1. Este artículo se reproduce de [BlockBeats], Todos los derechos de autor pertenecen al autor original [BlockBeats]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Renuncia de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Aprender de gate. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.