Cuando observamos la visión y la hoja de ruta de varias soluciones acumuladas, encontraremos que casi todas las acumulaciones tienen un objetivo final. Si este objetivo se condensa en una oración: construir una pila de tecnología, proporcionarla a la comunidad, resolver La expansión de la blockchain y, en última instancia, la descentralización de la pila tecnológica de operaciones y gobernanza. Esto lleva al término resumen descentralizado.
Entonces, ¿qué es exactamente la descentralización? ¿Cuál es la división del trabajo entre las distintas partes del sistema Rollup? ¿La descentralización significa maximizar los participantes en la operación del sistema? ¿Qué impacto tendrá un clasificador centralizado? ¿Cómo se debe diseñar el ordenamiento compartido y el consenso local L2? ¿Cuál es la función del probador único en ZK-Rollup? ¿Cómo sería una red de probadores abierta y descentralizada? ¿Por qué necesitamos la aceleración de hardware zk? ¿Cuál es la solución al problema de disponibilidad de datos? ....
Hay discusiones interminables sobre el resumen descentralizado en la comunidad, por lo que ECN seleccionó una serie de entrevistas de podcast con el tema "Resumen descentralizado" e invitó a fundadores e investigadores destacados en este campo para hablar sobre su comprensión del resumen descentralizado.
A medida que se vierte más y más liquidez en la plataforma de Capa 2, aparecen más y más proveedores de servicios de resumen, no solo soluciones de resumen de propósito general, cadenas de resumen de aplicaciones específicas, sino también plataformas de resumen como servicio. Por lo tanto, a más y más personas les preocupa que un "secuenciador" de rol muy crítico en casi todos los rollups aún esté centralizado. ¿Cuáles son los riesgos de un clasificador centralizado? ¿Es un clasificador descentralizado un trabajo urgente?
**En el segundo episodio, invitamos a Yaoqi Jia, fundador de AltLayer Network, Toghrul Maharramov, investigador de Scroll, y Abdelhamid Bakhta, Starknet Exploration Lead, a realizar una mesa redonda sobre el tema de los clasificadores descentralizados, para que la audiencia y los lectores puede entender el actual Algunos avances y dilemas de clasificadores descentralizados. **
Invitados en este número:
Yaoqi Jia, fundador de AltLayer Network, twitter @jiayaoqi
Investigador de pergaminos Toghrul Maharramov, twitter @toghrulmaharram
Líder de exploración de Starknet, Abdelhamid Bakhta, twitter @dimahledba
Pasado
Problema 1: ¿Cómo descentralizar Rollup?
Investigador de Arbitrum Patrick McCorry
Avance
Problema 3: Prover network y aceleración de hardware zk
Ye Zhang, cofundador de Scroll
Leo Fan, cofundador de Cysic
Problema 4: Disponibilidad de datos y almacenamiento descentralizado
Qi Zhou, fundador de EthStorage
Escuchar
Haga clic para suscribirse al podcast para obtener más información:
YouTube:
Microcosmo:
marca de tiempo
00:49 Yaoqi se presenta
01:37 Abdelhamid se presenta
02:50 Toghrul se presenta
04:03 El papel del clasificador en el resumen
08:37 Ordenador descentralizado: mejorar la experiencia del usuario y abordar los problemas de censura y vitalidad
19:43 Cómo Starknet descentralizará el clasificador
22:59 Cómo Scroll descentralizará el clasificador
26:34 La diferencia entre el consenso L2 en el contexto de Optimistic rollup y zkRollup
32:28 zkRollup descentraliza el clasificador y también necesita considerar el probador
36:01 ¿Qué es el resumen basado?
40:53 Desventajas del secuenciador compartido y el resumen basado, y sus escenarios de aplicación
49:02 ¿Qué impacto tendrá un pedido descentralizado en MEV?
Presentación de invitados
Yaoqi
Soy el fundador de AltLayer. AltLayer está construyendo una plataforma de "Resumen como servicio" donde los desarrolladores simplemente hacen clic en algunos botones y configuran parámetros. Usando nuestra plataforma de lanzamiento o panel de control, pueden lanzar rápidamente paquetes acumulativos específicos de aplicaciones en minutos. Eso es lo que estamos tratando de hacer ahora, proporcionar a los desarrolladores un entorno de ejecución y una funcionalidad comunes. También proporcionamos múltiples secuenciadores, múltiples sistemas de máquinas virtuales y varios sistemas de prueba para que los desarrolladores puedan elegir.
Abdelhamid
Trabajo en Starkware y soy el líder del equipo de exploración. El objetivo de este grupo es básicamente lanzar proyectos de código abierto que son similares a la investigación pero con un enfoque de ingeniería. Nuestro objetivo es trabajar en proyectos de código abierto en estrecha colaboración con la comunidad y con personas de otros ecosistemas. Uno de esos proyectos es Madara, que en realidad es un clasificador de Starknet. No solo es un candidato para la red pública Starknet, sino también un secuenciador para la cadena de aplicaciones Starknet y Layer3. Esto también está relacionado con lo que dijo el invitado anterior, también estamos pensando en proporcionar la función de acumulación como servicio, las personas pueden implementar su cadena de aplicaciones Starknet y elegir diferentes soluciones de disponibilidad de datos de una manera algo modular. Antes de eso, trabajé como desarrollador central de Ethereum durante cuatro años, siendo el principal responsable del trabajo de EIP-1559.
Elección
Soy investigador en Scroll, y mis principales responsabilidades en Scroll son el diseño de protocolos, el diseño de puentes, la descentralización, los incentivos, ese tipo de cosas. Entonces, cuando no estoy tuiteando, la mayor parte del tiempo solo estoy trabajando en cómo descentralizar el protocolo o los encargados, probadores, cosas así. Al igual que Starkware, una de las cosas en las que estamos trabajando es un SDK acumulativo. Por lo tanto, puede emitir un resumen basado en Scroll y usar de forma modular diferentes opciones de disponibilidad de datos, etc. Todavía estamos considerando la opción de que los paquetes acumulativos basados en Scroll SDK puedan usar el clasificador de Scroll para ayudarlos a lograr la descentralización sin requerir que cada paquete acumulativo maneje la descentralización por sí mismo. Por supuesto, el plan aún no se ha finalizado. Sin embargo, esta es también la dirección en la que estamos trabajando.
Sección de entrevistas
tema uno
Explicar el clasificador de rollup?
Abdelhamid
El clasificador es un componente muy importante en la arquitectura de capa 2, este componente recibe transacciones de los usuarios, luego las empaqueta y las agrupa en bloques, ejecuta transacciones, etc. Es muy crítico porque este es el componente responsable de crear bloques, ya que la capa 2 también es una cadena de bloques con bloques de transacciones. Los ordenadores crean estos bloques y los probadores dan fe de estos bloques.
Yaoqi
Como mencionó Abdel, el ordenador es una combinación de muchas funciones en la cadena de bloques. Entonces, en realidad, es posible que le estemos dando al ordenante demasiada responsabilidad ahora en comparación con una cadena de bloques pública típica. Primero necesita agregar todas las transacciones de los usuarios y luego ordenar esas transacciones, ya sea en función del precio del gas o por orden de llegada. Posteriormente, el secuenciador necesita ejecutar estas transacciones. Como ahora, algunos Layer2 usan EVM (Starware tiene una máquina virtual diferente), pero básicamente el secuenciador necesita usar una máquina virtual dedicada para ejecutar transacciones y generar estado. Luego, la transacción llega a una etapa de preconfirmación, lo que significa que si ve un tiempo de confirmación de uno o dos segundos, o incluso subsegundos, es básicamente un estado de preconfirmación completado por el secuenciador. Luego, para la mayoría de los clasificadores, también necesitan cargar o publicar puntos de control o hashes de estado en L1. Esta es la confirmación en el nivel L1, que llamamos disponibilidad de datos. Entonces, el clasificador en realidad tiene muchas funciones en el sistema de acumulación. Pero en general, creo que es el componente más crítico del sistema de resumen.
** Tema 2 **
¿Por qué es importante un clasificador descentralizado? Si usamos un clasificador centralizado, ¿cuáles son los peligros ocultos para los usuarios y el sistema?
Elección
En primer lugar, debemos saber que, a excepción de Fuel V1 en la etapa actual, no hay un paquete acumulativo real, porque otros paquetes acumulativos todavía tienen ruedas de entrenamiento.
Sin embargo, podemos decir que una vez que se clasifica como rollup, significa que se elimina multi-sig y así sucesivamente. Entonces, el problema de la descentralización del clasificador se convierte en un problema de experiencia del usuario, no en un problema de seguridad. Entonces, cuando la gente habla de, por ejemplo, descentralizar L1, el problema es completamente diferente. Porque L1 tiene que dar garantías para los clientes que hacen pedidos y son ligeros. Entonces, si un cliente ligero quiere verificar que el estado es correcto, debe confiar en los validadores L1. Para rollup, este no es el caso. Porque el clasificador solo proporciona una clasificación temporal, que luego finaliza L1. Y, debido a que también se garantiza que los paquetes acumulativos son resistentes a la censura, no necesitamos descentralización para que esto suceda.
Entonces, hay varias razones por las que necesita un clasificador descentralizado. En primer lugar, si, por ejemplo, la finalización de L1 es lenta (ya sea porque las pruebas de validez enviadas son demasiado lentas o debido al mecanismo del período de desafío de las pruebas de fraude acumuladas optimistas), debe confiar en algo para lograr una confirmación rápida de la transacción. En esta etapa de confirmación rápida, aunque puedes confiar en que Starkware o Scroll no te engañarán, indican que luego de que se confirme un bloque, no habrá reorganización. Esta es una suposición de confianza. Y la descentralización puede añadir algunas garantías económicas, etc.
Pero en base a esto, el resumen tampoco tiene garantía de finalidad en tiempo real. Esencialmente, puede forzar el empaquetado de transacciones a través de L1, pero lleva horas empaquetar esa transacción. Entonces, por ejemplo, si hay un oráculo responsable de la actualización y el tiempo fluctúa, básicamente, si el oráculo se actualiza durante una hora o más, las aplicaciones del resumen no estarán disponibles. Esencialmente, la descentralización nos permite brindar algunas garantías más fuertes de resistencia a la censura en tiempo real, porque entonces un adversario necesitaría comprometer no solo una entidad o un puñado de entidades, sino toda la red de ordenadores.
Entonces, para nosotros, la descentralización es más una solución para mejorar la experiencia del usuario o solucionar el problema de las actualizaciones de Oracle, etc. En lugar de proporcionar garantías de seguridad básicas, esto es lo que hace L1.
Abdelhamid
Sí, la pregunta sobre el clasificador descentralizado que mencionaste no es exactamente lo mismo que el L1 descentralizado, lo cual creo que es muy importante. Porque cuando vemos que algunos L1 critican a los clasificadores centralizados, no analizan correctamente las compensaciones que hacen los clasificadores centralizados.
Sobre esta base, me gustaría agregar algo relacionado con la experiencia del usuario, relacionado con la actividad. Porque cuando solo tiene un clasificador, corre un mayor riesgo de que el clasificador falle. Por lo tanto, un ordenador descentralizado también aumenta la resiliencia y la vitalidad de la red. Pero incluso en un contexto centralizado, tenemos buena seguridad cuando se trata de seguridad. Porque cuando puede forzar transacciones de paquetes a través de L1, la diferencia entre los dos es solo la línea de tiempo. Y tener un clasificador descentralizado le permite tener garantías rápidas resistentes a la censura, como mencionó Toghrul. Entonces, solo quiero agregar que también es importante para liveness tener una red descentralizada de ordenadores.
Yaoqi
Me gustaría agregar algo. La actividad es probablemente lo más importante que debemos considerar en esta etapa. Los casos más recientes de airdrops en los L2 más populares, como Optimism y Arbitrum, tuvieron un período de inactividad. Por lo tanto, creo que lo que debemos resolver es cómo manejar miles de solicitudes de transacciones por segundo cuando solo tenemos un clasificador. Incluso en teoría, si solo tiene un nodo, en realidad no puede manejar tantas solicitudes al mismo tiempo. Entonces, con respecto a la vida, definitivamente necesitamos múltiples clasificadores. El punto único de falla es un obstáculo real, no solo para Web3, incluso Web2 es un gran problema.
Más allá de eso, está el tema de la censura. Si solo tenemos un coordinador, incluso si vemos que puede estar a cargo del equipo, aún debe demostrar que el equipo en realidad no revisará las transacciones. A veces es posible y capaz que partes malintencionadas incluyan en la lista negra ciertas transacciones. Ese es un sistema de pedidos descentralizado, también pueden intentar enviar transacciones a través de otros pedidos. Es por eso que últimamente hemos recibido muchas críticas en torno a los clasificadores individuales.
Más allá de eso, hay otros problemas como MEV y ejecuciones tempranas. En un sistema con clasificadores centralizados, especialmente para los protocolos DeFi, es posible que puedan verificar el mempool fácilmente. Probablemente no en la forma de favorito, pero tienen una mejor oportunidad de seguir el intercambio y arbitrarlo.
Muchos de estos problemas, por varias razones, aunque vemos que L2 es muy diferente de L1. Pero, en última instancia, todavía tenemos que hacerlo lo más descentralizado posible. Entonces, tenemos que enfrentar algunos de los problemas similares que tenemos con las cadenas de bloques públicas o L1.
Abdelhamid
Sí, estoy de acuerdo en que un clasificador descentralizado es importante. Pero también quiero decir que, como todos sabemos, esta no es una pregunta fácil.
Además, **ya que los rollups tienen una arquitectura muy específica, con múltiples entidades. Estamos hablando de un solo ordenador, pero también hay un probador, y necesitamos descentralizar ambos. **Habrá algunas compensaciones y algunas dificultades en la forma de cotizar las transacciones porque se necesitan diferentes factores para operar la red. Entonces, ¿cómo le pones precio a la oferta? El clasificador y la cámara de fermentación tienen diferentes requisitos de hardware, la cámara de fermentación necesita una máquina superpotente, etc. Por lo tanto, fijar el precio de las transacciones en un mundo descentralizado también es un problema muy difícil, por lo que necesitamos tiempo para avanzar lentamente.
Por lo tanto, todos nos enfrentaremos a una compensación de este tipo. Si queremos descentralizar rápidamente, es posible que debamos tomar algunas ruedas de entrenamiento y descentralizar gradualmente, porque si queremos directamente una arquitectura perfecta, tomará varios años. Así que creo que adoptaremos un enfoque pragmático e intentaremos descentralizar gradualmente. Al menos ese es nuestro plan actual, tal vez comenzar con un mecanismo de consenso BFT simple y luego agregar otro mecanismo de consenso a corto plazo o algo así. Así que solo quiero decir que no es una pregunta fácil. Porque obviamente existe una compensación entre la velocidad de desarrollo y la aplicabilidad de la arquitectura a un entorno descentralizado.
Tema 3
¿Cómo descentralizar el clasificador?
Abdelhamid
Hay muchas características que queremos descentralizar, y todas tienen diferentes ventajas y desventajas.
Por ejemplo, al descentralizar, desea introducir algún tipo de mecanismo de consenso. En el mecanismo de consenso, sin embargo, hay múltiples partes. El primero es la elección del líder, es decir, cómo elegir quién creará los bloques, quién será el ordenante responsable de crear los bloques en un espacio determinado o dentro de un tiempo determinado. **Lo que el equipo de Starknet planea hacer es utilizar la capa 1 tanto como sea posible. Es decir, en nuestro algoritmo de elección de líder, queremos apostar en la capa 1. Por ejemplo, tenemos tokens y el compromiso se realizará en el contrato inteligente de capa 1 Ethereum, que se utiliza para determinar el mecanismo de elección del líder. **Esto significa que necesitamos tener alguna interacción en la que el ordenante de L2 consulte el contrato inteligente de Ethereum para saber quién será el próximo líder o algo así. Entonces, obviamente, se necesita algún tipo de aleatoriedad y otras cosas. Así que no es una pregunta simple. Pero esa es la primera parte. Entonces necesitas tener un mecanismo para el consenso mismo. Hay múltiples opciones: el mecanismo de cadena más larga o BFT, o un híbrido de los dos. Al igual que Ethereum, tiene LMG Ghost y Casper FFG para fines definitivos.
Entonces, podríamos adoptar un enfoque pragmático y comenzar primero con BFT. ¿por qué? Cuando la capa 2 considera la descentralización, nuestro objetivo no es tener una escala de clasificador tan grande como la capa 1. Por ejemplo, en Ethereum, el objetivo es que participen millones de validadores. En este caso, no puede simplemente usar el mecanismo BFT, porque tendrá una eficiencia muy mala y causará problemas muy grandes. Por ejemplo, si hay un problema en la red Bitcoin, si es un mecanismo BFT, la cadena se detendrá por completo. Pero no es así, la red Bitcoin sigue creando bloques, solo se ataca el mecanismo de finalidad.
Pero en la capa 2, si el objetivo es de unos pocos cientos a 1000 clasificadores, podría ser bueno comenzar con un mecanismo BFT. Entonces, tenemos el mecanismo de elección de líder, luego el consenso, y luego hay otras dos partes, pero dejaré que los otros invitados continúen agregando. Pero las otras dos partes son actualizaciones de estado y generación de pruebas.
Elección
Primero, en L2, la descentralización es un problema multifacético, como lo describe Abdel. Especialmente en zkRollup, debido a que hay probadores y ordenadores, debe coordinarse entre ellos, debe descentralizar a ambos. Este problema es completamente diferente de L1.
Otra diferencia es que en L2, todo su diseño es para convencer al puente subyacente de que el consenso es correcto, no para convencer a otros nodos. Obviamente, debe hacer lo mismo, pero su enfoque principal debe ser el puente en sí.
Actualmente, estamos trabajando en dos direcciones diferentes. Número uno, creo que, como todos los demás, estamos trabajando en un protocolo BFT. Esto no es muy eficiente y hay algunos problemas que deben resolverse. Se nos ocurrió una solución aproximada, pero aún no es la óptima. Por ejemplo, una de las preguntas es, ¿cómo equilibra los incentivos entre clasificadores y probadores? Debido a que el ordenante controla MEV y el probador no tiene acceso a MEV, existe un incentivo para que las personas ejecuten el ordenador en lugar del probador. Pero en realidad, necesitamos más probadores que encargados, entonces, ¿cómo equilibra los incentivos entre los dos? Este es uno de esos problemas.
La segunda solución en la que estamos trabajando es otra dirección. Recuerde, las cosas pueden cambiar. Todos los días salen nuevas propuestas. Por ejemplo, últimamente se ha hablado mucho sobre el resumen basado y cómo puede subcontratar completamente la clasificación a L1. La segunda dirección es básicamente deshacerse del clasificador por completo y usar algún constructor externo. Por ejemplo, los constructores de ethereum o Flashbots SUAVE, etc. proponen bloques ordenados y luego ejecutan el consenso dentro del probador. La ventaja aquí es que no tiene que lidiar con incentivos porque básicamente puede usar PBS dentro del protocolo y crea un protocolo más simple. Pero la desventaja es que, dado que necesitamos una gran cantidad de probadores (porque podemos probar en paralelo), es bastante difícil ejecutar un protocolo BFT clásico con ellos. Entonces, la pregunta es ¿cómo optimizar un protocolo BFT existente para ejecutarlo con cientos o incluso miles de probadores? Y esa no es una pregunta fácil de responder.
¿Es necesario introducir el consenso L2 para un ordenante descentralizado?
Yaoqi
Puedo responder aproximadamente a esta pregunta porque recientemente lanzamos algo así.
Entonces, introducir el consenso no depende de si lo queremos o no. Una vez que tenga muchos ordenantes o incluso solo nodos, debe lograr que estén de acuerdo. Realmente depende de tus suposiciones. Si se trata de una suposición bizantina, podemos usar BFT o cualquier protocolo de consenso bizantino existente. Si se trata de una configuración no bizantina, por ejemplo, si asumimos que un nodo solo puede estar en línea y fuera de línea, y que no puede actuar maliciosamente, entonces podemos usar el protocolo Raft o algún otro protocolo de consenso más rápido. Pero de todos modos, si tenemos un grupo de ordenadores o probadores, si queremos organizarlos juntos para producir bloques durante un período de tiempo, entonces tienes que tener un protocolo de consenso alrededor de ellos.
Entonces, como acaban de mencionar Toghrul y Abdel, creo que hay muchas propuestas y temas de investigación sobre cómo podemos implementar un sistema de pruebas o pedidos descentralizados. Entonces, debido a que acabamos de lanzar una red de prueba para un sistema de acumulación de clasificador múltiple (actualmente solo admite pruebas de fraude para acumulaciones optimistas), según nuestra experiencia en diseño e implementación, hay algunas cosas que puedo compartir sobre las dificultades. Como acaba de mencionar Toghrul, la dificultad no radica en el protocolo de consenso en sí mismo, la verdadera dificultad radica en otras cosas además de esto, como la parte de la prueba. Porque si se trata de un solo clasificador, no necesita muchos nodos. Podemos pensar en ello como un EVM, una máquina virtual. Entonces, solo busque transacciones y ejecute, haga transiciones de estado. El probador es responsable de generar pruebas para la transición de estado del conjunto anterior de transacciones. Sin embargo, si ejecutamos el protocolo de consenso para el recopilador y el probador en el resumen, entonces debemos introducir una lógica de consenso adicional allí. Además de esto, también necesita un sistema de prueba para el protocolo de consenso. Por lo tanto, esto introducirá mucho trabajo para que el sistema de prueba lo genere. Luego, una vez que genera la prueba, puede verificarla fácilmente en L1 Ethereum.
Es por eso que, en cierto modo, cuando lanzamos la primera red de prueba de pedidos múltiples, el resumen optimista tenía algunas ventajas en ese sentido. En general, puede simplificar muchas cosas, como no considerar la parte de prueba de validez. Al igual que nosotros, básicamente comparamos todo con WASM. Así que al final es una instrucción WASM. Entonces, al verificar estas instrucciones WASM, es relativamente fácil verificar usando el código de Solidity. Si acabamos de volver a implementar todas las interpretaciones de instrucciones WASM en Ethereum.
Pero en general, el problema no es singular. Si tenemos una solución al problema, en consecuencia, habrá algún otro trabajo de seguimiento que debe resolverse al mismo tiempo. Por supuesto, habrá problemas de MEV, como cómo distribuir MEV de manera justa. Puede asignar todos los ordenadores y probadores en función de si produjeron un bloque o validaron un bloque. Pero al final, es realmente una combinación de muchos problemas, no solo técnicos, sino también de incentivos económicos.
Y debemos recordar que se propone L2 porque queremos reducir significativamente el costo del gas. Así que no podemos tener tantos nodos. Incluso al generar pruebas, L2 puede ser más costoso que L1. Así que realmente necesitamos llegar a un enfoque equilibrado para este tipo de problema.
Abdelhamid
Me gustaría añadir un punto más. En primer lugar, actualmente no existe una prueba real de fraude sin permiso para acumulaciones optimistas. Y sigo enfatizando esto cada vez que tengo la oportunidad, porque es importante ser honesto sobre esto al comparar. Entonces no son L2 en absoluto. Eso es lo primero.
Luego me gustaría agregar algo sobre la asincronía entre la clasificación y las pruebas, porque es muy importante. Como dijiste, queremos optimizar la clasificación, porque actualmente esto es un cuello de botella para todas las soluciones. Pero eso está bien en el contexto de una clasificación centralizada, porque sabemos que el clasificador solo producirá transiciones de valor y podremos verificarlas. Pero será más difícil en el contexto de una clasificación descentralizada, porque tal vez su clasificador pueda producir algo que no se puede verificar. Entonces tendrás que lidiar con eso más tarde.
En el contexto de la clasificación centralizada, para optimizar la clasificación, dado que no tenemos que generar pruebas durante el proceso de clasificación, podemos intentar hacerlo a velocidad local, que es lo que queremos hacer. Traduzca Cairo a un lenguaje de máquina de bajo nivel como LLVM y ejecute súper rápido en el clasificador. Entonces puedes probar de forma asíncrona. Y lo mejor de las pruebas es que puedes hacerlas en paralelo. La paralelización masiva se logra demostrando que la recursividad es posible. Es por eso que podremos alcanzar la velocidad del clasificador. Pero es difícil cuando está descentralizado, porque debemos asegurarnos de que el ordenante solo produzca transiciones de estado válidas.
Elección
Agregaré que no estoy seguro de qué está haciendo Starknet aquí. Pero para nosotros, supongo que es una suposición general de cada zkRollup que si descentraliza el clasificador, su sistema de prueba debe poder manejar lotes no válidos. Básicamente, si, por ejemplo, envía un lote con una firma no válida, debe poder demostrar que el estado resultante es equivalente al estado inicial. Así que habrá algunos gastos generales de cualquier manera. Se trata de cómo minimizar la probabilidad de que esto suceda.
Abdelhamid
Sí, eso es correcto. Es por eso que presentamos Sierra en Cairo 1 para que todo sea verificable. Esta representación intermedia asegurará que cada programa de Cairo 1 sea verificable para que podamos incluir una transacción de reversión.
¿Qué es el resumen basado?
Yaoqi
El resumen basado originalmente provino de una publicación de blog de Justin Drake en los foros de Ethereum. Una de sus ideas es que podemos reutilizar algunos verificadores de Ethereum para verificar transacciones acumulativas, de modo que no necesitemos un grupo separado de nodos para verificar diferentes transacciones acumulativas. En particular, tendremos muchos resúmenes en el futuro, incluidos resúmenes de uso general y muchos resúmenes de aplicaciones específicas. Entonces, en este caso, sería genial si pudiéramos encontrar un lugar común como el grupo de validadores de Ethereum para validar estas transacciones.
Por supuesto, esto es solo una idea, ya que también presenta muchas dificultades técnicas. Por ejemplo, en teoría, podríamos requerir validadores de Ethereum para verificar las transacciones acumuladas, pero es muy difícil obtener la lógica de verificar acumulaciones agrupadas o integradas en el propio protocolo Ethereum. A esto lo llamamos verificación en protocolo, que requiere una bifurcación dura de los nodos de Ethereum. Por supuesto, en este caso, podemos verificar algunas transacciones acumulativas. Pero si lo hacemos, verás problemas. Es un poco como si quisiéramos que el resumen de L2 comparta la presión de Ethereum, pero al final aún le pedimos a los validadores de Ethereum que asuman parte del trabajo descargado a L2. Mucha gente habla de cómo podemos hacer esto.
Luego hablamos con Barnabe, un investigador de la Fundación Ethereum que actualmente trabaja en PBS. Esta es una propuesta de Ethereum, que consiste en dividir la tarea de los validadores en múltiples roles, constructores y proponentes. Ahora tenemos Flashbots para asumir el papel de constructores en PBS, componen todos los bloques y los envían a los proponentes de Ethereum. Entonces, una vez que estos bloques estén empaquetados en la red Ethereum, los constructores también obtendrán algunas recompensas. Entonces, en este caso, ¿cómo recompensar a estos validadores de la red Ethereum? También son responsables de la validación del resumen.
Una de las soluciones es "retomar", que puede haber escuchado mucho de EigenLayer o de algunos otros protocolos. Los usuarios pueden volver a apostar ETH en otras redes de clasificación. O recompense a los validadores de Ethereum por ejecutar realmente el software para hacer el trabajo de validación para el resumen. En este caso, pueden ser recompensados tanto desde L2 como a través del protocolo de re-staking. Ha habido muchas propuestas para esto hasta ahora, pero en general es una idea de cómo poder reutilizar los validadores de Ethereum existentes. ¿Cómo podemos reutilizar ETH existente para ayudar a marcar el comienzo de una nueva era de sistemas acumulativos o L2? Entonces, básicamente está tratando de simplificar muchas cosas para el proyecto de resumen. Si un rollup quiere un clasificador nuevo, si quiere una nueva fuente de garantía, puede reutilizar la infraestructura existente o la garantía existente. Es por eso que está construido sobre Ethereum, y luego se puede reutilizar más infraestructura y staking para rollup y L2 también.
Desventajas del secuenciador compartido y el resumen basado, y sus escenarios de aplicación.
Elección
Quiero quejarme de esta propuesta, no me convence la propuesta relacionada con el secuenciador compartido. Por supuesto, todavía están en pañales, y si estos diseños mejoran en el futuro, es muy posible que los apoye. Es solo que la forma actual no me convence. Hay muchas razones.
En primer lugar, para mí, la principal propuesta de valor de un clasificador compartido es permitir a los usuarios obtener una componibilidad atómica entre paquetes acumulativos de propósito general como Scroll o Starknet. Pero el problema es que si tiene componibilidad atómica, su resumen es tan definitivo como el resumen más lento con el que se combina. Entonces, suponiendo que Scroll se combine con Optimistic Rollup, la finalidad de Scroll será de siete días. Si bien la principal propuesta de valor de ZKRollup es lograr una finalidad relativamente rápida, los usuarios pueden retirarse a L1 en cuestión de minutos. Y en este caso, básicamente renunciar a eso.
Otro inconveniente es que si desea una finalidad fuera de la cadena, debe ejecutar un nodo L2 y, siempre que L1 finalice los datos enviados a la cadena, obtendrá la finalidad localmente en L2. Si cada L2 combinado no ejecuta un nodo completo, es prácticamente imposible lograr la finalización local. Esto significa que ejecutar este sistema puede ser más costoso que ejecutar un sistema como Solana, porque tiene varios nodos completos ejecutándose al mismo tiempo, con su propia sobrecarga, etc.
Entonces, por esas razones, simplemente no creo que tenga sentido para L2. Es un poco diferente para L3, porque si alguien quiere construir una cadena específica de aplicación y no quiere lidiar con la descentralización. Digamos que estoy creando un juego y solo quiero ocuparme de la construcción del juego, luego puedo subcontratar el trabajo descentralizado. Pero no creo que tenga sentido para L2 en este momento.
En cuanto al resumen basado, también tengo mis preocupaciones. Por ejemplo, ¿cómo comparte las ganancias de MEV con los probadores? Porque si no se considera el problema de asignación, básicamente L1 puede obtener todas las ganancias de MEV. Otra pequeña cosa es que su tiempo de confirmación es igual al tiempo de confirmación de L1, que es de 12 minutos, que no puede ser más rápido. Otro problema es que, dado que no tiene permiso, varios buscadores pueden enviar lotes de transacciones al mismo tiempo, lo que significa que puede terminar con resultados centralizados. Porque los constructores tienen incentivos para incluir sus transacciones si un buscador se conecta más fácilmente que otros. Por lo tanto, puede resultar en que solo un Buscador proponga lotes para L2 al final, lo cual no es una muy buena solución, porque si esto sucede, básicamente estamos de vuelta al punto de partida.
Yaoqi
Curiosamente, acabo de recibir una llamada de Ben, el fundador de Espresso, la semana pasada. Hablamos mucho de esto en el tema de los clasificadores compartidos. Como mencionó Toghrul, creo que existe cierta incertidumbre sobre los escenarios de uso de un sistema de pedidos compartido. Esto se debe principalmente a que para un L2 de uso general, generalmente no tenemos una gran cantidad de clasificadores debido a la eficiencia, la complejidad y la economía. Y sigo sintiendo que, ya sea para un secuenciador compartido, un resumen basado o una recuperación, el mejor caso de uso es principalmente para RAS (Resumen como servicio) o plataformas en las que podemos implementar muchos resúmenes. Para ser honestos, realmente no necesitamos una gran red de clasificación si no hay muchos rollups. Estos rollups ya tienen sus propios sistemas de clasificación y ya tienen sus propias comunidades o socios, cuando solo hay algunos L2 genéricos. Realmente no necesitan tener una red separada y de terceros. Además, esto es una carga para la red de terceros, porque tiene que personalizar para cada L2, y cada L2 tiene una pila de prueba diferente. Esto requiere muchos cambios en su propia red.
Pero al mismo tiempo, como mencionó Toghrul, para algunos casos de uso especiales. Por ejemplo, si quisiéramos tener algo de interoperabilidad en el nivel del clasificador, los clasificadores compartidos podrían ser una forma potencial de hacerlo. Por ejemplo, el mismo clasificador se usa para varios paquetes acumulativos. En este caso, este clasificador básicamente puede manejar algunas transacciones de resumen cruzado para garantizar la atomicidad de cadena cruzada entre el resumen A, B y C.
Pero también puedes ver el problema aquí cuando describo la situación. Si realmente tuviéramos muchos de estos secuenciadores compartidos, volverían a convertirse en un cuello de botella y en un nuevo punto único de falla. Estamos dando demasiado poder a estos llamados ordenadores compartidos. Se están volviendo más como una red, controlando muchos paquetes acumulativos. Finalmente, nuevamente debemos encontrar una forma de descentralizar este clasificador compartido.
Pero de todos modos, creo que es bueno que la gente descubra gradualmente más y más problemas y encuentre más y más soluciones. En general, es emocionante ver qué hay de nuevo en este campo todos los días. Con todas estas nuevas soluciones, al menos estamos en el camino correcto para descentralizar verdaderamente todo el espacio de resumen.
Abdel
Sí, estoy de acuerdo con los dos. Creo que tiene más sentido para Layer3 y Lisk porque ya no quieren asumir la responsabilidad de incentivar una red descentralizada y necesitan encontrar socios para iniciar cosas como clasificadores. Así que creo que para Lisk tiene sentido. Pero al igual que Toghrul, no creo que tenga mucho sentido para Layer2 todavía.
Tema 4
¿Qué impacto tendrá un pedido descentralizado en MEV?
Abdel
Para Starknet, en el contexto de la centralización, no hacemos ningún tipo de MEV y adoptamos un modelo de orden de llegada. Es decir, en el contexto de la descentralización, por supuesto, se incorporarán más MEV más adelante. Pero es demasiado pronto para decir qué proporción, porque también depende del diseño del mecanismo de consenso y otros aspectos.
Elección
Pero la cosa es que, incluso si no haces MEV, es posible que todavía haya MEV en Starknet. Bueno, la descentralización por sí sola no disminuye ni aumenta el MEV. Por supuesto, si aplica algún tipo de protocolo de pedido justo o cifrado de umbral, por ejemplo, entonces sí, minimiza MEV. Pero no puedes eliminarlo por completo. Mi filosofía es: MEV no se puede eliminar. Pero digamos que solo está creando un consenso BFT, o construyendo algo sobre un consenso BFT. Esto en realidad no afecta MEV en absoluto. El MEV todavía existe, debería ser una cuestión de cómo funciona el buscador con el clasificador para extraer ese MEV.
Yaoqi
El problema es que incluso el modelo de orden de llegada tiene partes complicadas. Una vez que exponemos el mempool a algunos buscadores, todavía tienen la ventaja de jugar más. Por ejemplo, para los secuenciadores, equivalen a esperar en la puerta de tu oficina. Entonces, en este caso, una vez que ven algún tipo de oportunidad de arbitraje, no solo sobre la ejecución frontal o un ataque sándwich, tan pronto como un usuario envía una transacción, puede verla inmediatamente en el mempool. Por lo tanto, pueden colocar rápidamente sus operaciones por delante de los demás. Por lo tanto, tienen una ventaja sobre otros buscadores.
Pero volviendo a la descentralización, creo que se trata principalmente de resistencia a la censura, como discutimos al principio. Los secuenciadores son administrados por el equipo. El equipo puede decir que están siendo justos con todos. Pero esto no se previene en el código. Entonces, si pudiéramos tener una red P2P, sería genial si sintiéramos que estos nodos examinan mis transacciones y luego podemos enviarlas a otros nodos. Entonces, realmente se trata de la justicia de procesar transacciones en L2.
En cuanto a los MEV, porque recientemente, además de los MEV generados dentro de un solo resumen, hay algunos MEV generados a través de puentes. En esta red de clasificación relativamente descentralizada, tendrá más oportunidades para extraer MEV. Suponiendo que tenemos una red de pedidos compartidos, si de alguna manera puede influir en el ordenante compartido para reordenar las transacciones, básicamente tiene una gran ventaja sobre todos los demás.
Hay ventajas y desventajas en una red de secuenciadores compartidos. En el lado positivo, podemos descentralizar aún más el sistema de clasificación. Pero por otro lado, todos tienen la oportunidad de ser clasificadores. Entonces, básicamente pueden hacer lo que quieran, y es un bosque oscuro nuevamente. Entonces, introdujimos la descentralización y luego tuvimos que enfrentar problemas similares a los que enfrentamos en Ethereum. Es por eso que Flashbots y la gente de la Fundación Ethereum quieren avanzar con PBS, proponer y construir por separado, y luego tratar de tener una solución única en el lado del constructor.
Entonces, cuando miramos el problema, no es solo un problema. Ya no es un problema uno a uno, sino uno a seis, y más.
Ver originales
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.
Diálogo con los equipos AltLayer, Scroll, Starknet: secuenciador compartido y consenso L2
Introducción
Cuando observamos la visión y la hoja de ruta de varias soluciones acumuladas, encontraremos que casi todas las acumulaciones tienen un objetivo final. Si este objetivo se condensa en una oración: construir una pila de tecnología, proporcionarla a la comunidad, resolver La expansión de la blockchain y, en última instancia, la descentralización de la pila tecnológica de operaciones y gobernanza. Esto lleva al término resumen descentralizado.
Entonces, ¿qué es exactamente la descentralización? ¿Cuál es la división del trabajo entre las distintas partes del sistema Rollup? ¿La descentralización significa maximizar los participantes en la operación del sistema? ¿Qué impacto tendrá un clasificador centralizado? ¿Cómo se debe diseñar el ordenamiento compartido y el consenso local L2? ¿Cuál es la función del probador único en ZK-Rollup? ¿Cómo sería una red de probadores abierta y descentralizada? ¿Por qué necesitamos la aceleración de hardware zk? ¿Cuál es la solución al problema de disponibilidad de datos? ....
Hay discusiones interminables sobre el resumen descentralizado en la comunidad, por lo que ECN seleccionó una serie de entrevistas de podcast con el tema "Resumen descentralizado" e invitó a fundadores e investigadores destacados en este campo para hablar sobre su comprensión del resumen descentralizado.
A medida que se vierte más y más liquidez en la plataforma de Capa 2, aparecen más y más proveedores de servicios de resumen, no solo soluciones de resumen de propósito general, cadenas de resumen de aplicaciones específicas, sino también plataformas de resumen como servicio. Por lo tanto, a más y más personas les preocupa que un "secuenciador" de rol muy crítico en casi todos los rollups aún esté centralizado. ¿Cuáles son los riesgos de un clasificador centralizado? ¿Es un clasificador descentralizado un trabajo urgente?
**En el segundo episodio, invitamos a Yaoqi Jia, fundador de AltLayer Network, Toghrul Maharramov, investigador de Scroll, y Abdelhamid Bakhta, Starknet Exploration Lead, a realizar una mesa redonda sobre el tema de los clasificadores descentralizados, para que la audiencia y los lectores puede entender el actual Algunos avances y dilemas de clasificadores descentralizados. **
Invitados en este número:
Pasado
Problema 1: ¿Cómo descentralizar Rollup?
Avance
Problema 3: Prover network y aceleración de hardware zk
Problema 4: Disponibilidad de datos y almacenamiento descentralizado
Escuchar
Haga clic para suscribirse al podcast para obtener más información:
YouTube:
Microcosmo:
marca de tiempo
00:49 Yaoqi se presenta
01:37 Abdelhamid se presenta
02:50 Toghrul se presenta
04:03 El papel del clasificador en el resumen
08:37 Ordenador descentralizado: mejorar la experiencia del usuario y abordar los problemas de censura y vitalidad
19:43 Cómo Starknet descentralizará el clasificador
22:59 Cómo Scroll descentralizará el clasificador
26:34 La diferencia entre el consenso L2 en el contexto de Optimistic rollup y zkRollup
32:28 zkRollup descentraliza el clasificador y también necesita considerar el probador
36:01 ¿Qué es el resumen basado?
40:53 Desventajas del secuenciador compartido y el resumen basado, y sus escenarios de aplicación
49:02 ¿Qué impacto tendrá un pedido descentralizado en MEV?
Presentación de invitados
Yaoqi
Soy el fundador de AltLayer. AltLayer está construyendo una plataforma de "Resumen como servicio" donde los desarrolladores simplemente hacen clic en algunos botones y configuran parámetros. Usando nuestra plataforma de lanzamiento o panel de control, pueden lanzar rápidamente paquetes acumulativos específicos de aplicaciones en minutos. Eso es lo que estamos tratando de hacer ahora, proporcionar a los desarrolladores un entorno de ejecución y una funcionalidad comunes. También proporcionamos múltiples secuenciadores, múltiples sistemas de máquinas virtuales y varios sistemas de prueba para que los desarrolladores puedan elegir.
Abdelhamid
Trabajo en Starkware y soy el líder del equipo de exploración. El objetivo de este grupo es básicamente lanzar proyectos de código abierto que son similares a la investigación pero con un enfoque de ingeniería. Nuestro objetivo es trabajar en proyectos de código abierto en estrecha colaboración con la comunidad y con personas de otros ecosistemas. Uno de esos proyectos es Madara, que en realidad es un clasificador de Starknet. No solo es un candidato para la red pública Starknet, sino también un secuenciador para la cadena de aplicaciones Starknet y Layer3. Esto también está relacionado con lo que dijo el invitado anterior, también estamos pensando en proporcionar la función de acumulación como servicio, las personas pueden implementar su cadena de aplicaciones Starknet y elegir diferentes soluciones de disponibilidad de datos de una manera algo modular. Antes de eso, trabajé como desarrollador central de Ethereum durante cuatro años, siendo el principal responsable del trabajo de EIP-1559.
Elección
Soy investigador en Scroll, y mis principales responsabilidades en Scroll son el diseño de protocolos, el diseño de puentes, la descentralización, los incentivos, ese tipo de cosas. Entonces, cuando no estoy tuiteando, la mayor parte del tiempo solo estoy trabajando en cómo descentralizar el protocolo o los encargados, probadores, cosas así. Al igual que Starkware, una de las cosas en las que estamos trabajando es un SDK acumulativo. Por lo tanto, puede emitir un resumen basado en Scroll y usar de forma modular diferentes opciones de disponibilidad de datos, etc. Todavía estamos considerando la opción de que los paquetes acumulativos basados en Scroll SDK puedan usar el clasificador de Scroll para ayudarlos a lograr la descentralización sin requerir que cada paquete acumulativo maneje la descentralización por sí mismo. Por supuesto, el plan aún no se ha finalizado. Sin embargo, esta es también la dirección en la que estamos trabajando.
Sección de entrevistas
tema uno
Explicar el clasificador de rollup?
Abdelhamid
El clasificador es un componente muy importante en la arquitectura de capa 2, este componente recibe transacciones de los usuarios, luego las empaqueta y las agrupa en bloques, ejecuta transacciones, etc. Es muy crítico porque este es el componente responsable de crear bloques, ya que la capa 2 también es una cadena de bloques con bloques de transacciones. Los ordenadores crean estos bloques y los probadores dan fe de estos bloques.
Yaoqi
Como mencionó Abdel, el ordenador es una combinación de muchas funciones en la cadena de bloques. Entonces, en realidad, es posible que le estemos dando al ordenante demasiada responsabilidad ahora en comparación con una cadena de bloques pública típica. Primero necesita agregar todas las transacciones de los usuarios y luego ordenar esas transacciones, ya sea en función del precio del gas o por orden de llegada. Posteriormente, el secuenciador necesita ejecutar estas transacciones. Como ahora, algunos Layer2 usan EVM (Starware tiene una máquina virtual diferente), pero básicamente el secuenciador necesita usar una máquina virtual dedicada para ejecutar transacciones y generar estado. Luego, la transacción llega a una etapa de preconfirmación, lo que significa que si ve un tiempo de confirmación de uno o dos segundos, o incluso subsegundos, es básicamente un estado de preconfirmación completado por el secuenciador. Luego, para la mayoría de los clasificadores, también necesitan cargar o publicar puntos de control o hashes de estado en L1. Esta es la confirmación en el nivel L1, que llamamos disponibilidad de datos. Entonces, el clasificador en realidad tiene muchas funciones en el sistema de acumulación. Pero en general, creo que es el componente más crítico del sistema de resumen.
** Tema 2 **
¿Por qué es importante un clasificador descentralizado? Si usamos un clasificador centralizado, ¿cuáles son los peligros ocultos para los usuarios y el sistema?
Elección
En primer lugar, debemos saber que, a excepción de Fuel V1 en la etapa actual, no hay un paquete acumulativo real, porque otros paquetes acumulativos todavía tienen ruedas de entrenamiento.
Sin embargo, podemos decir que una vez que se clasifica como rollup, significa que se elimina multi-sig y así sucesivamente. Entonces, el problema de la descentralización del clasificador se convierte en un problema de experiencia del usuario, no en un problema de seguridad. Entonces, cuando la gente habla de, por ejemplo, descentralizar L1, el problema es completamente diferente. Porque L1 tiene que dar garantías para los clientes que hacen pedidos y son ligeros. Entonces, si un cliente ligero quiere verificar que el estado es correcto, debe confiar en los validadores L1. Para rollup, este no es el caso. Porque el clasificador solo proporciona una clasificación temporal, que luego finaliza L1. Y, debido a que también se garantiza que los paquetes acumulativos son resistentes a la censura, no necesitamos descentralización para que esto suceda.
Entonces, hay varias razones por las que necesita un clasificador descentralizado. En primer lugar, si, por ejemplo, la finalización de L1 es lenta (ya sea porque las pruebas de validez enviadas son demasiado lentas o debido al mecanismo del período de desafío de las pruebas de fraude acumuladas optimistas), debe confiar en algo para lograr una confirmación rápida de la transacción. En esta etapa de confirmación rápida, aunque puedes confiar en que Starkware o Scroll no te engañarán, indican que luego de que se confirme un bloque, no habrá reorganización. Esta es una suposición de confianza. Y la descentralización puede añadir algunas garantías económicas, etc.
Pero en base a esto, el resumen tampoco tiene garantía de finalidad en tiempo real. Esencialmente, puede forzar el empaquetado de transacciones a través de L1, pero lleva horas empaquetar esa transacción. Entonces, por ejemplo, si hay un oráculo responsable de la actualización y el tiempo fluctúa, básicamente, si el oráculo se actualiza durante una hora o más, las aplicaciones del resumen no estarán disponibles. Esencialmente, la descentralización nos permite brindar algunas garantías más fuertes de resistencia a la censura en tiempo real, porque entonces un adversario necesitaría comprometer no solo una entidad o un puñado de entidades, sino toda la red de ordenadores.
Entonces, para nosotros, la descentralización es más una solución para mejorar la experiencia del usuario o solucionar el problema de las actualizaciones de Oracle, etc. En lugar de proporcionar garantías de seguridad básicas, esto es lo que hace L1.
Abdelhamid
Sí, la pregunta sobre el clasificador descentralizado que mencionaste no es exactamente lo mismo que el L1 descentralizado, lo cual creo que es muy importante. Porque cuando vemos que algunos L1 critican a los clasificadores centralizados, no analizan correctamente las compensaciones que hacen los clasificadores centralizados.
Sobre esta base, me gustaría agregar algo relacionado con la experiencia del usuario, relacionado con la actividad. Porque cuando solo tiene un clasificador, corre un mayor riesgo de que el clasificador falle. Por lo tanto, un ordenador descentralizado también aumenta la resiliencia y la vitalidad de la red. Pero incluso en un contexto centralizado, tenemos buena seguridad cuando se trata de seguridad. Porque cuando puede forzar transacciones de paquetes a través de L1, la diferencia entre los dos es solo la línea de tiempo. Y tener un clasificador descentralizado le permite tener garantías rápidas resistentes a la censura, como mencionó Toghrul. Entonces, solo quiero agregar que también es importante para liveness tener una red descentralizada de ordenadores.
Yaoqi
Me gustaría agregar algo. La actividad es probablemente lo más importante que debemos considerar en esta etapa. Los casos más recientes de airdrops en los L2 más populares, como Optimism y Arbitrum, tuvieron un período de inactividad. Por lo tanto, creo que lo que debemos resolver es cómo manejar miles de solicitudes de transacciones por segundo cuando solo tenemos un clasificador. Incluso en teoría, si solo tiene un nodo, en realidad no puede manejar tantas solicitudes al mismo tiempo. Entonces, con respecto a la vida, definitivamente necesitamos múltiples clasificadores. El punto único de falla es un obstáculo real, no solo para Web3, incluso Web2 es un gran problema.
Más allá de eso, está el tema de la censura. Si solo tenemos un coordinador, incluso si vemos que puede estar a cargo del equipo, aún debe demostrar que el equipo en realidad no revisará las transacciones. A veces es posible y capaz que partes malintencionadas incluyan en la lista negra ciertas transacciones. Ese es un sistema de pedidos descentralizado, también pueden intentar enviar transacciones a través de otros pedidos. Es por eso que últimamente hemos recibido muchas críticas en torno a los clasificadores individuales.
Más allá de eso, hay otros problemas como MEV y ejecuciones tempranas. En un sistema con clasificadores centralizados, especialmente para los protocolos DeFi, es posible que puedan verificar el mempool fácilmente. Probablemente no en la forma de favorito, pero tienen una mejor oportunidad de seguir el intercambio y arbitrarlo.
Muchos de estos problemas, por varias razones, aunque vemos que L2 es muy diferente de L1. Pero, en última instancia, todavía tenemos que hacerlo lo más descentralizado posible. Entonces, tenemos que enfrentar algunos de los problemas similares que tenemos con las cadenas de bloques públicas o L1.
Abdelhamid
Sí, estoy de acuerdo en que un clasificador descentralizado es importante. Pero también quiero decir que, como todos sabemos, esta no es una pregunta fácil.
Además, **ya que los rollups tienen una arquitectura muy específica, con múltiples entidades. Estamos hablando de un solo ordenador, pero también hay un probador, y necesitamos descentralizar ambos. **Habrá algunas compensaciones y algunas dificultades en la forma de cotizar las transacciones porque se necesitan diferentes factores para operar la red. Entonces, ¿cómo le pones precio a la oferta? El clasificador y la cámara de fermentación tienen diferentes requisitos de hardware, la cámara de fermentación necesita una máquina superpotente, etc. Por lo tanto, fijar el precio de las transacciones en un mundo descentralizado también es un problema muy difícil, por lo que necesitamos tiempo para avanzar lentamente.
Por lo tanto, todos nos enfrentaremos a una compensación de este tipo. Si queremos descentralizar rápidamente, es posible que debamos tomar algunas ruedas de entrenamiento y descentralizar gradualmente, porque si queremos directamente una arquitectura perfecta, tomará varios años. Así que creo que adoptaremos un enfoque pragmático e intentaremos descentralizar gradualmente. Al menos ese es nuestro plan actual, tal vez comenzar con un mecanismo de consenso BFT simple y luego agregar otro mecanismo de consenso a corto plazo o algo así. Así que solo quiero decir que no es una pregunta fácil. Porque obviamente existe una compensación entre la velocidad de desarrollo y la aplicabilidad de la arquitectura a un entorno descentralizado.
Tema 3
¿Cómo descentralizar el clasificador?
Abdelhamid
Hay muchas características que queremos descentralizar, y todas tienen diferentes ventajas y desventajas.
Por ejemplo, al descentralizar, desea introducir algún tipo de mecanismo de consenso. En el mecanismo de consenso, sin embargo, hay múltiples partes. El primero es la elección del líder, es decir, cómo elegir quién creará los bloques, quién será el ordenante responsable de crear los bloques en un espacio determinado o dentro de un tiempo determinado. **Lo que el equipo de Starknet planea hacer es utilizar la capa 1 tanto como sea posible. Es decir, en nuestro algoritmo de elección de líder, queremos apostar en la capa 1. Por ejemplo, tenemos tokens y el compromiso se realizará en el contrato inteligente de capa 1 Ethereum, que se utiliza para determinar el mecanismo de elección del líder. **Esto significa que necesitamos tener alguna interacción en la que el ordenante de L2 consulte el contrato inteligente de Ethereum para saber quién será el próximo líder o algo así. Entonces, obviamente, se necesita algún tipo de aleatoriedad y otras cosas. Así que no es una pregunta simple. Pero esa es la primera parte. Entonces necesitas tener un mecanismo para el consenso mismo. Hay múltiples opciones: el mecanismo de cadena más larga o BFT, o un híbrido de los dos. Al igual que Ethereum, tiene LMG Ghost y Casper FFG para fines definitivos.
Entonces, podríamos adoptar un enfoque pragmático y comenzar primero con BFT. ¿por qué? Cuando la capa 2 considera la descentralización, nuestro objetivo no es tener una escala de clasificador tan grande como la capa 1. Por ejemplo, en Ethereum, el objetivo es que participen millones de validadores. En este caso, no puede simplemente usar el mecanismo BFT, porque tendrá una eficiencia muy mala y causará problemas muy grandes. Por ejemplo, si hay un problema en la red Bitcoin, si es un mecanismo BFT, la cadena se detendrá por completo. Pero no es así, la red Bitcoin sigue creando bloques, solo se ataca el mecanismo de finalidad.
Pero en la capa 2, si el objetivo es de unos pocos cientos a 1000 clasificadores, podría ser bueno comenzar con un mecanismo BFT. Entonces, tenemos el mecanismo de elección de líder, luego el consenso, y luego hay otras dos partes, pero dejaré que los otros invitados continúen agregando. Pero las otras dos partes son actualizaciones de estado y generación de pruebas.
Elección
Primero, en L2, la descentralización es un problema multifacético, como lo describe Abdel. Especialmente en zkRollup, debido a que hay probadores y ordenadores, debe coordinarse entre ellos, debe descentralizar a ambos. Este problema es completamente diferente de L1.
Otra diferencia es que en L2, todo su diseño es para convencer al puente subyacente de que el consenso es correcto, no para convencer a otros nodos. Obviamente, debe hacer lo mismo, pero su enfoque principal debe ser el puente en sí.
Actualmente, estamos trabajando en dos direcciones diferentes. Número uno, creo que, como todos los demás, estamos trabajando en un protocolo BFT. Esto no es muy eficiente y hay algunos problemas que deben resolverse. Se nos ocurrió una solución aproximada, pero aún no es la óptima. Por ejemplo, una de las preguntas es, ¿cómo equilibra los incentivos entre clasificadores y probadores? Debido a que el ordenante controla MEV y el probador no tiene acceso a MEV, existe un incentivo para que las personas ejecuten el ordenador en lugar del probador. Pero en realidad, necesitamos más probadores que encargados, entonces, ¿cómo equilibra los incentivos entre los dos? Este es uno de esos problemas.
La segunda solución en la que estamos trabajando es otra dirección. Recuerde, las cosas pueden cambiar. Todos los días salen nuevas propuestas. Por ejemplo, últimamente se ha hablado mucho sobre el resumen basado y cómo puede subcontratar completamente la clasificación a L1. La segunda dirección es básicamente deshacerse del clasificador por completo y usar algún constructor externo. Por ejemplo, los constructores de ethereum o Flashbots SUAVE, etc. proponen bloques ordenados y luego ejecutan el consenso dentro del probador. La ventaja aquí es que no tiene que lidiar con incentivos porque básicamente puede usar PBS dentro del protocolo y crea un protocolo más simple. Pero la desventaja es que, dado que necesitamos una gran cantidad de probadores (porque podemos probar en paralelo), es bastante difícil ejecutar un protocolo BFT clásico con ellos. Entonces, la pregunta es ¿cómo optimizar un protocolo BFT existente para ejecutarlo con cientos o incluso miles de probadores? Y esa no es una pregunta fácil de responder.
¿Es necesario introducir el consenso L2 para un ordenante descentralizado?
Yaoqi
Puedo responder aproximadamente a esta pregunta porque recientemente lanzamos algo así.
Entonces, introducir el consenso no depende de si lo queremos o no. Una vez que tenga muchos ordenantes o incluso solo nodos, debe lograr que estén de acuerdo. Realmente depende de tus suposiciones. Si se trata de una suposición bizantina, podemos usar BFT o cualquier protocolo de consenso bizantino existente. Si se trata de una configuración no bizantina, por ejemplo, si asumimos que un nodo solo puede estar en línea y fuera de línea, y que no puede actuar maliciosamente, entonces podemos usar el protocolo Raft o algún otro protocolo de consenso más rápido. Pero de todos modos, si tenemos un grupo de ordenadores o probadores, si queremos organizarlos juntos para producir bloques durante un período de tiempo, entonces tienes que tener un protocolo de consenso alrededor de ellos.
Entonces, como acaban de mencionar Toghrul y Abdel, creo que hay muchas propuestas y temas de investigación sobre cómo podemos implementar un sistema de pruebas o pedidos descentralizados. Entonces, debido a que acabamos de lanzar una red de prueba para un sistema de acumulación de clasificador múltiple (actualmente solo admite pruebas de fraude para acumulaciones optimistas), según nuestra experiencia en diseño e implementación, hay algunas cosas que puedo compartir sobre las dificultades. Como acaba de mencionar Toghrul, la dificultad no radica en el protocolo de consenso en sí mismo, la verdadera dificultad radica en otras cosas además de esto, como la parte de la prueba. Porque si se trata de un solo clasificador, no necesita muchos nodos. Podemos pensar en ello como un EVM, una máquina virtual. Entonces, solo busque transacciones y ejecute, haga transiciones de estado. El probador es responsable de generar pruebas para la transición de estado del conjunto anterior de transacciones. Sin embargo, si ejecutamos el protocolo de consenso para el recopilador y el probador en el resumen, entonces debemos introducir una lógica de consenso adicional allí. Además de esto, también necesita un sistema de prueba para el protocolo de consenso. Por lo tanto, esto introducirá mucho trabajo para que el sistema de prueba lo genere. Luego, una vez que genera la prueba, puede verificarla fácilmente en L1 Ethereum.
Es por eso que, en cierto modo, cuando lanzamos la primera red de prueba de pedidos múltiples, el resumen optimista tenía algunas ventajas en ese sentido. En general, puede simplificar muchas cosas, como no considerar la parte de prueba de validez. Al igual que nosotros, básicamente comparamos todo con WASM. Así que al final es una instrucción WASM. Entonces, al verificar estas instrucciones WASM, es relativamente fácil verificar usando el código de Solidity. Si acabamos de volver a implementar todas las interpretaciones de instrucciones WASM en Ethereum.
Pero en general, el problema no es singular. Si tenemos una solución al problema, en consecuencia, habrá algún otro trabajo de seguimiento que debe resolverse al mismo tiempo. Por supuesto, habrá problemas de MEV, como cómo distribuir MEV de manera justa. Puede asignar todos los ordenadores y probadores en función de si produjeron un bloque o validaron un bloque. Pero al final, es realmente una combinación de muchos problemas, no solo técnicos, sino también de incentivos económicos.
Y debemos recordar que se propone L2 porque queremos reducir significativamente el costo del gas. Así que no podemos tener tantos nodos. Incluso al generar pruebas, L2 puede ser más costoso que L1. Así que realmente necesitamos llegar a un enfoque equilibrado para este tipo de problema.
Abdelhamid
Me gustaría añadir un punto más. En primer lugar, actualmente no existe una prueba real de fraude sin permiso para acumulaciones optimistas. Y sigo enfatizando esto cada vez que tengo la oportunidad, porque es importante ser honesto sobre esto al comparar. Entonces no son L2 en absoluto. Eso es lo primero.
Luego me gustaría agregar algo sobre la asincronía entre la clasificación y las pruebas, porque es muy importante. Como dijiste, queremos optimizar la clasificación, porque actualmente esto es un cuello de botella para todas las soluciones. Pero eso está bien en el contexto de una clasificación centralizada, porque sabemos que el clasificador solo producirá transiciones de valor y podremos verificarlas. Pero será más difícil en el contexto de una clasificación descentralizada, porque tal vez su clasificador pueda producir algo que no se puede verificar. Entonces tendrás que lidiar con eso más tarde.
En el contexto de la clasificación centralizada, para optimizar la clasificación, dado que no tenemos que generar pruebas durante el proceso de clasificación, podemos intentar hacerlo a velocidad local, que es lo que queremos hacer. Traduzca Cairo a un lenguaje de máquina de bajo nivel como LLVM y ejecute súper rápido en el clasificador. Entonces puedes probar de forma asíncrona. Y lo mejor de las pruebas es que puedes hacerlas en paralelo. La paralelización masiva se logra demostrando que la recursividad es posible. Es por eso que podremos alcanzar la velocidad del clasificador. Pero es difícil cuando está descentralizado, porque debemos asegurarnos de que el ordenante solo produzca transiciones de estado válidas.
Elección
Agregaré que no estoy seguro de qué está haciendo Starknet aquí. Pero para nosotros, supongo que es una suposición general de cada zkRollup que si descentraliza el clasificador, su sistema de prueba debe poder manejar lotes no válidos. Básicamente, si, por ejemplo, envía un lote con una firma no válida, debe poder demostrar que el estado resultante es equivalente al estado inicial. Así que habrá algunos gastos generales de cualquier manera. Se trata de cómo minimizar la probabilidad de que esto suceda.
Abdelhamid
Sí, eso es correcto. Es por eso que presentamos Sierra en Cairo 1 para que todo sea verificable. Esta representación intermedia asegurará que cada programa de Cairo 1 sea verificable para que podamos incluir una transacción de reversión.
¿Qué es el resumen basado?
Yaoqi
El resumen basado originalmente provino de una publicación de blog de Justin Drake en los foros de Ethereum. Una de sus ideas es que podemos reutilizar algunos verificadores de Ethereum para verificar transacciones acumulativas, de modo que no necesitemos un grupo separado de nodos para verificar diferentes transacciones acumulativas. En particular, tendremos muchos resúmenes en el futuro, incluidos resúmenes de uso general y muchos resúmenes de aplicaciones específicas. Entonces, en este caso, sería genial si pudiéramos encontrar un lugar común como el grupo de validadores de Ethereum para validar estas transacciones.
Por supuesto, esto es solo una idea, ya que también presenta muchas dificultades técnicas. Por ejemplo, en teoría, podríamos requerir validadores de Ethereum para verificar las transacciones acumuladas, pero es muy difícil obtener la lógica de verificar acumulaciones agrupadas o integradas en el propio protocolo Ethereum. A esto lo llamamos verificación en protocolo, que requiere una bifurcación dura de los nodos de Ethereum. Por supuesto, en este caso, podemos verificar algunas transacciones acumulativas. Pero si lo hacemos, verás problemas. Es un poco como si quisiéramos que el resumen de L2 comparta la presión de Ethereum, pero al final aún le pedimos a los validadores de Ethereum que asuman parte del trabajo descargado a L2. Mucha gente habla de cómo podemos hacer esto.
Luego hablamos con Barnabe, un investigador de la Fundación Ethereum que actualmente trabaja en PBS. Esta es una propuesta de Ethereum, que consiste en dividir la tarea de los validadores en múltiples roles, constructores y proponentes. Ahora tenemos Flashbots para asumir el papel de constructores en PBS, componen todos los bloques y los envían a los proponentes de Ethereum. Entonces, una vez que estos bloques estén empaquetados en la red Ethereum, los constructores también obtendrán algunas recompensas. Entonces, en este caso, ¿cómo recompensar a estos validadores de la red Ethereum? También son responsables de la validación del resumen.
Una de las soluciones es "retomar", que puede haber escuchado mucho de EigenLayer o de algunos otros protocolos. Los usuarios pueden volver a apostar ETH en otras redes de clasificación. O recompense a los validadores de Ethereum por ejecutar realmente el software para hacer el trabajo de validación para el resumen. En este caso, pueden ser recompensados tanto desde L2 como a través del protocolo de re-staking. Ha habido muchas propuestas para esto hasta ahora, pero en general es una idea de cómo poder reutilizar los validadores de Ethereum existentes. ¿Cómo podemos reutilizar ETH existente para ayudar a marcar el comienzo de una nueva era de sistemas acumulativos o L2? Entonces, básicamente está tratando de simplificar muchas cosas para el proyecto de resumen. Si un rollup quiere un clasificador nuevo, si quiere una nueva fuente de garantía, puede reutilizar la infraestructura existente o la garantía existente. Es por eso que está construido sobre Ethereum, y luego se puede reutilizar más infraestructura y staking para rollup y L2 también.
Desventajas del secuenciador compartido y el resumen basado, y sus escenarios de aplicación.
Elección
Quiero quejarme de esta propuesta, no me convence la propuesta relacionada con el secuenciador compartido. Por supuesto, todavía están en pañales, y si estos diseños mejoran en el futuro, es muy posible que los apoye. Es solo que la forma actual no me convence. Hay muchas razones.
En primer lugar, para mí, la principal propuesta de valor de un clasificador compartido es permitir a los usuarios obtener una componibilidad atómica entre paquetes acumulativos de propósito general como Scroll o Starknet. Pero el problema es que si tiene componibilidad atómica, su resumen es tan definitivo como el resumen más lento con el que se combina. Entonces, suponiendo que Scroll se combine con Optimistic Rollup, la finalidad de Scroll será de siete días. Si bien la principal propuesta de valor de ZKRollup es lograr una finalidad relativamente rápida, los usuarios pueden retirarse a L1 en cuestión de minutos. Y en este caso, básicamente renunciar a eso.
Otro inconveniente es que si desea una finalidad fuera de la cadena, debe ejecutar un nodo L2 y, siempre que L1 finalice los datos enviados a la cadena, obtendrá la finalidad localmente en L2. Si cada L2 combinado no ejecuta un nodo completo, es prácticamente imposible lograr la finalización local. Esto significa que ejecutar este sistema puede ser más costoso que ejecutar un sistema como Solana, porque tiene varios nodos completos ejecutándose al mismo tiempo, con su propia sobrecarga, etc.
Entonces, por esas razones, simplemente no creo que tenga sentido para L2. Es un poco diferente para L3, porque si alguien quiere construir una cadena específica de aplicación y no quiere lidiar con la descentralización. Digamos que estoy creando un juego y solo quiero ocuparme de la construcción del juego, luego puedo subcontratar el trabajo descentralizado. Pero no creo que tenga sentido para L2 en este momento.
En cuanto al resumen basado, también tengo mis preocupaciones. Por ejemplo, ¿cómo comparte las ganancias de MEV con los probadores? Porque si no se considera el problema de asignación, básicamente L1 puede obtener todas las ganancias de MEV. Otra pequeña cosa es que su tiempo de confirmación es igual al tiempo de confirmación de L1, que es de 12 minutos, que no puede ser más rápido. Otro problema es que, dado que no tiene permiso, varios buscadores pueden enviar lotes de transacciones al mismo tiempo, lo que significa que puede terminar con resultados centralizados. Porque los constructores tienen incentivos para incluir sus transacciones si un buscador se conecta más fácilmente que otros. Por lo tanto, puede resultar en que solo un Buscador proponga lotes para L2 al final, lo cual no es una muy buena solución, porque si esto sucede, básicamente estamos de vuelta al punto de partida.
Yaoqi
Curiosamente, acabo de recibir una llamada de Ben, el fundador de Espresso, la semana pasada. Hablamos mucho de esto en el tema de los clasificadores compartidos. Como mencionó Toghrul, creo que existe cierta incertidumbre sobre los escenarios de uso de un sistema de pedidos compartido. Esto se debe principalmente a que para un L2 de uso general, generalmente no tenemos una gran cantidad de clasificadores debido a la eficiencia, la complejidad y la economía. Y sigo sintiendo que, ya sea para un secuenciador compartido, un resumen basado o una recuperación, el mejor caso de uso es principalmente para RAS (Resumen como servicio) o plataformas en las que podemos implementar muchos resúmenes. Para ser honestos, realmente no necesitamos una gran red de clasificación si no hay muchos rollups. Estos rollups ya tienen sus propios sistemas de clasificación y ya tienen sus propias comunidades o socios, cuando solo hay algunos L2 genéricos. Realmente no necesitan tener una red separada y de terceros. Además, esto es una carga para la red de terceros, porque tiene que personalizar para cada L2, y cada L2 tiene una pila de prueba diferente. Esto requiere muchos cambios en su propia red.
Pero al mismo tiempo, como mencionó Toghrul, para algunos casos de uso especiales. Por ejemplo, si quisiéramos tener algo de interoperabilidad en el nivel del clasificador, los clasificadores compartidos podrían ser una forma potencial de hacerlo. Por ejemplo, el mismo clasificador se usa para varios paquetes acumulativos. En este caso, este clasificador básicamente puede manejar algunas transacciones de resumen cruzado para garantizar la atomicidad de cadena cruzada entre el resumen A, B y C.
Pero también puedes ver el problema aquí cuando describo la situación. Si realmente tuviéramos muchos de estos secuenciadores compartidos, volverían a convertirse en un cuello de botella y en un nuevo punto único de falla. Estamos dando demasiado poder a estos llamados ordenadores compartidos. Se están volviendo más como una red, controlando muchos paquetes acumulativos. Finalmente, nuevamente debemos encontrar una forma de descentralizar este clasificador compartido.
Pero de todos modos, creo que es bueno que la gente descubra gradualmente más y más problemas y encuentre más y más soluciones. En general, es emocionante ver qué hay de nuevo en este campo todos los días. Con todas estas nuevas soluciones, al menos estamos en el camino correcto para descentralizar verdaderamente todo el espacio de resumen.
Abdel
Sí, estoy de acuerdo con los dos. Creo que tiene más sentido para Layer3 y Lisk porque ya no quieren asumir la responsabilidad de incentivar una red descentralizada y necesitan encontrar socios para iniciar cosas como clasificadores. Así que creo que para Lisk tiene sentido. Pero al igual que Toghrul, no creo que tenga mucho sentido para Layer2 todavía.
Tema 4
¿Qué impacto tendrá un pedido descentralizado en MEV?
Abdel
Para Starknet, en el contexto de la centralización, no hacemos ningún tipo de MEV y adoptamos un modelo de orden de llegada. Es decir, en el contexto de la descentralización, por supuesto, se incorporarán más MEV más adelante. Pero es demasiado pronto para decir qué proporción, porque también depende del diseño del mecanismo de consenso y otros aspectos.
Elección
Pero la cosa es que, incluso si no haces MEV, es posible que todavía haya MEV en Starknet. Bueno, la descentralización por sí sola no disminuye ni aumenta el MEV. Por supuesto, si aplica algún tipo de protocolo de pedido justo o cifrado de umbral, por ejemplo, entonces sí, minimiza MEV. Pero no puedes eliminarlo por completo. Mi filosofía es: MEV no se puede eliminar. Pero digamos que solo está creando un consenso BFT, o construyendo algo sobre un consenso BFT. Esto en realidad no afecta MEV en absoluto. El MEV todavía existe, debería ser una cuestión de cómo funciona el buscador con el clasificador para extraer ese MEV.
Yaoqi
El problema es que incluso el modelo de orden de llegada tiene partes complicadas. Una vez que exponemos el mempool a algunos buscadores, todavía tienen la ventaja de jugar más. Por ejemplo, para los secuenciadores, equivalen a esperar en la puerta de tu oficina. Entonces, en este caso, una vez que ven algún tipo de oportunidad de arbitraje, no solo sobre la ejecución frontal o un ataque sándwich, tan pronto como un usuario envía una transacción, puede verla inmediatamente en el mempool. Por lo tanto, pueden colocar rápidamente sus operaciones por delante de los demás. Por lo tanto, tienen una ventaja sobre otros buscadores.
Pero volviendo a la descentralización, creo que se trata principalmente de resistencia a la censura, como discutimos al principio. Los secuenciadores son administrados por el equipo. El equipo puede decir que están siendo justos con todos. Pero esto no se previene en el código. Entonces, si pudiéramos tener una red P2P, sería genial si sintiéramos que estos nodos examinan mis transacciones y luego podemos enviarlas a otros nodos. Entonces, realmente se trata de la justicia de procesar transacciones en L2.
En cuanto a los MEV, porque recientemente, además de los MEV generados dentro de un solo resumen, hay algunos MEV generados a través de puentes. En esta red de clasificación relativamente descentralizada, tendrá más oportunidades para extraer MEV. Suponiendo que tenemos una red de pedidos compartidos, si de alguna manera puede influir en el ordenante compartido para reordenar las transacciones, básicamente tiene una gran ventaja sobre todos los demás.
Hay ventajas y desventajas en una red de secuenciadores compartidos. En el lado positivo, podemos descentralizar aún más el sistema de clasificación. Pero por otro lado, todos tienen la oportunidad de ser clasificadores. Entonces, básicamente pueden hacer lo que quieran, y es un bosque oscuro nuevamente. Entonces, introdujimos la descentralización y luego tuvimos que enfrentar problemas similares a los que enfrentamos en Ethereum. Es por eso que Flashbots y la gente de la Fundación Ethereum quieren avanzar con PBS, proponer y construir por separado, y luego tratar de tener una solución única en el lado del constructor.
Entonces, cuando miramos el problema, no es solo un problema. Ya no es un problema uno a uno, sino uno a seis, y más.