Gran parte de la discusión en Twitter últimamente gira en torno a la descentralización de L2. ¿Los Rollups que estamos construyendo están lo suficientemente descentralizados? ¿O al menos están en el camino de la descentralización? ¿Importa?
La idea de Rollup es simple: queremos que los participantes fuera de la cadena puedan realizar transacciones que luego puedan verificarse fácilmente en la cadena. Con Rollup, la capa base permite que su base de "confianza" se utilice para actividades que ocurren fuera de su esfera inmediata. A cambio, Rollup paga una pequeña tarifa (alquiler) para aprovechar este fideicomiso.
Entonces, ¿necesitamos Rollups descentralizados?
La respuesta intuitiva es ¡sí! Este es el espíritu con el que construimos la cadena de bloques.
Sin embargo, creo que la respuesta a esta pregunta no es un simple sí o no. En cambio, tiene múltiples facetas que deben analizarse individualmente. En los capítulos siguientes, analizaré esta cuestión desde tres perspectivas: filosófica, tecnológica y económica. ****Estos tres no son necesariamente exhaustivos o exclusivos, pero deberían brindar una buena perspectiva general del problema. **
1. Perspectiva filosófica
Comencemos por llevar la conversación a un nivel superior: ¿por qué nos importa la descentralización?
Porque queremos un futuro sin permisos que promueva la innovación abierta. Queremos que los usuarios puedan construir cosas nuevas sin restricciones y sin necesidad de confiar en ninguna entidad única.
En la breve historia de blockchain, muchos desarrolladores anónimos han creado cosas increíbles. De hecho, Bitcoin en sí mismo fue creado por una entidad anónima: ¡pronto puede ser la moneda que la mayoría de las personas en el mundo usan para pagos globales! ¡Ese es el poder de la innovación sin permiso!
Blockchain nos permite colaborar con personas que no tienen nada en común y sabemos que no tienen forma de romper esa confianza - Preston Evans
La base descentralizada de redes sin confianza como Bitcoin y Ethereum nos permite construir ese futuro. ¡Entonces es obvio que cualquier cadena que tenga una relación de confianza con estas cadenas, como Rollups, también debe descentralizarse!
De hecho, plantea una pregunta interesante e importante:
**Si Rollup no está descentralizado, ¿eso significa que Ethereum no está descentralizado? **
Una forma un poco optimista de ver esto es que, en un mundo sin permisos, se debe permitir que los rollups construyan lo que quieran, incluidas (pero no limitadas a) cadenas totalmente autorizadas, y los usuarios de ese rollup aún deberían poder aprovechar la seguridad en el capa base. Incluso las cadenas autorizadas deberían ser seguras de usar siempre que la capa base esté descentralizada y el resumen esté "totalmente" implementado (hablaremos más sobre "totalmente implementado" en la sección técnica).
Pero la realidad es que la mayoría de los paquetes acumulativos actuales aún no han alcanzado la etapa de implementación completa y no brindan a los usuarios el nivel deseado de seguridad y confianza.
Entonces, ¿cómo es la implementación correcta del resumen? vamos a ver:
2. Tecnología
Para comprender verdaderamente el problema de la descentralización y la seguridad en el nivel de resumen, debemos analizarlo desde los primeros principios. No mucha gente puede explicar los primeros principios de blockchain mejor que Sreeram Kannan.
Una cadena de bloques es un libro mayor distribuido donde diferentes nodos en la red siguen un protocolo definido para obtener consenso sobre el estado del libro mayor. Dependiendo de cómo estos nodos vean la red, pueden tener diferentes reglas para confirmar el estado correcto de la red en su propio libro mayor.
Por ejemplo, en el protocolo Gasper de Ethereum, hay dos reglas de confirmación diferentes: la regla disponible (basada en la cadena más pesada) y la regla final (basada en los bloques confirmados por el dispositivo).
Especialmente en acumulaciones, los nodos completos tienen reglas de confirmación diferentes a las de los clientes ligeros. En el resumen tradicional de contratos inteligentes (SCR), el contrato inteligente (puente de verificación) tiene sus propias reglas de confirmación. Si no hay eventos adversos, estas reglas de confirmación eventualmente coinciden en las llamadas "regiones de consistencia". Como su nombre lo indica, en las zonas de consenso, todos los participantes tienen la misma vista de la red (y tienen el mismo historial en sus registros).
Si todas las reglas de confirmación son seguras, no sucederán cosas malas. Como compartió Sreeram en la publicación anterior, 5 propiedades definen principalmente la seguridad de estas reglas de confirmación.
Crecimiento del libro mayor: la cadena acumulada debe seguir creciendo (vida)
Resistencia a la censura: todos los usuarios deben poder incluir todas y cada una de las transacciones en la capa base
Resistencia a la reestructuración: la transacción no debe restablecerse una vez completada
Disponibilidad de datos: los datos de transacciones deben publicarse en algún lugar
Validez: las transacciones y las transiciones de estado deben ser válidas
Las primeras 2 propiedades juntas definen la condición "en vivo" del sistema, mientras que las últimas 3 propiedades definen la condición "segura".
Miremos cada uno desde la perspectiva de diferentes actores de agregación y veamos cuáles se pueden mitigar sin descentralización.
Diferentes actores confían en diferentes mecanismos para la seguridad y la vida.
Nodo completo:
Si ejecuta un nodo completo, tiene acceso a los datos publicados y puede verificarlos directamente. Luego puede usar esos datos para realizar transacciones usted mismo y determinar la validez de las transacciones y el estado final del Resumen después de esas transacciones.
Las restantes condiciones de seguridad son, por tanto, las propiedades de actividad y la resistencia a la recombinación. Para este último, los nodos completos se basan en los validadores de la cadena subyacente y el protocolo de consenso que utilizan, mientras que para las propiedades de vida, los nodos completos se basan en las implementaciones de secuenciador y resumen.
Cliente ligero:
La mayoría de los usuarios usan billeteras integradas en nodos ligeros o usan servicios de terceros para obtener datos de la cadena de bloques e interactuar con la cadena de bloques. Los nodos de luz pueden ser de varios tipos:
Validador de estado: verifica la validez de las transiciones de estado,
Validador DA: valida la disponibilidad de datos,
** validador de consenso: validar la prueba de consenso de la capa base, o **
verificador completo - verifica todo lo anterior
Si ejecuta un cliente ligero de validación completa, puede verificar que los datos estén disponibles a través del muestreo de disponibilidad de datos, puede verificar la validez de las transiciones de estado a través de pruebas de validez o pruebas de fraude, también puede verificar que el estado se haya finalizado en la base Consenso de capa (en Ethereum, esto se puede hacer siguiendo un comité de sincronización).
La condición de seguridad restante es entonces la propiedad de actividad, y los clientes ligeros confían en las implementaciones del secuenciador y del resumen.
Contrato inteligente incorporado (puente de verificación):
En el SCR tradicional, la "regla de confirmación" de un contrato inteligente es hacer cumplir las 5 propiedades de seguridad:
Crecimiento del libro mayor a través del protocolo de reemplazo del secuenciador
Resistir la censura haciendo cumplir la inclusión
Crear resistencia a la reorganización solo sobre el estado anterior
La disponibilidad de datos se logra mediante el envío de DA en la capa base
Verificación de validez mediante prueba de validez/fraude
Los nodos completos de SCR se basan en contratos inteligentes para hacer cumplir las propiedades de vida. Ellos "absorben" la resistencia a la reestructuración de la capa base.
Los nodos de luz se basan en contratos inteligentes para mejorar las propiedades de vida y absorber DA y resistencia a la reorganización de la capa base. Pueden verificar la prueba de validez ellos mismos o mediante contratos inteligentes.
El consenso de SCR es seguir la cadena canónica definida por el contrato inteligente.
**¿Qué pasa con la acumulación soberana? **
Los Sovereign Rollups no tienen contratos inteligentes (puentes de verificación) para hacer cumplir las condiciones de validez o vida. En su lugar, demostrarán que se "bajan" a un nodo de resumen descendente. Estos nodos aún absorben la resistencia DA y Reorg de la capa base.
Al igual que en SCR, en los nodos consolidados soberanos se necesita algún mecanismo para hacer cumplir la propiedad de actividad. Para definir la cadena canónica, optaron por mecanismos independientes como la transmisión de pruebas p2p.
¿Qué tiene que ver todo esto con la descentralización?
Ya sea que se trate de un resumen de contrato inteligente o un resumen soberano, la propiedad de vida proviene de la implementación correcta del resumen. Como hemos visto anteriormente, una correcta implementación de la agregación debe incluir dos componentes importantes:
mecanismos de inclusión obligatoria, y
Protocolo de sustitución del secuenciador
La inclusión obligatoria ayuda a generar resistencia a la censura. Este mecanismo permite a los usuarios "forzar la inclusión" de sus transacciones directamente en la capa base. Cualquier usuario en el resumen puede forzar la salida de regreso a la capa base con sus fondos. Por lo tanto, incluso si solo hay un nodo recopilador centralizado para la agregación, no puede censurar a los usuarios siempre que exista un mecanismo de cumplimiento maduro.
¿Pero es eso suficiente?
Incluso si los usuarios pueden cerrar la sesión, esto puede significar que si la mayoría de los usuarios vuelven a L1, la empresa no tiene muchos incentivos para seguir funcionando. Además, el mecanismo de inclusión obligatoria suele tener un largo tiempo de espera y puede resultar bastante caro de implementar para el usuario medio. La resistencia a la censura que proporciona este mecanismo no es precisamente práctica (ni en tiempo real). Podemos llamar a esta situación "censura débil".
Luego tenemos el atributo de vitalidad final: crecimiento del libro mayor
Si el recopilador centralizado se vuelve malicioso, puede detener el crecimiento de la cadena de resumen simplemente deteniendo la producción de bloques. Si esto sucede, no hay nada que el usuario o la empresa pueda hacer para que el resumen vuelva a estar "activo".
Para resolver este problema, necesitamos un protocolo de reemplazo de secuenciador.
La idea del protocolo de reemplazo del secuenciador es que si el secuenciador se comporta de manera maliciosa, el gobierno agregado puede iniciar el secuenciador. Una de las formas de lograr esto es reemplazar los nodos de secuenciador centralizados con un protocolo de secuenciador descentralizado. Si el clasificador está descentralizado y no monopoliza los componentes básicos del resumen, es casi imposible detener el resumen.
Por lo tanto, si bien los fondos de los usuarios siempre están seguros en los paquetes acumulativos a través del mecanismo de inclusión obligatorio, la creación de un protocolo sólido de reemplazo de pedidos ayuda a mantener vivos los paquetes acumulativos y proporciona una resistencia práctica a la censura en tiempo real.
¿esto es todo?
No exactamente. Desde un punto de vista técnico, hay un aspecto más a considerar:
¿Qué pasaría si los propios contratos inteligentes pudieran ser actualizados por un comité central agregado? Digamos que los paquetes acumulativos se implementan correctamente en la actualidad, pero mañana el comité acuerda que ya no necesitamos contratos inteligentes, sino que en su lugar, transmitimos pruebas del estado del paquete acumulativo a la red p2p.
Si, como usuario de resumen, no está de acuerdo con dicha actualización, debería poder salir del resumen antes de que se implemente la actualización (aunque nuevamente, esta no es una buena experiencia para el usuario y puede ser perjudicial para el negocio). Esto se puede lograr a través de "actualizaciones de gobernanza retrasadas". Es como un "período de notificación" después del cual se implementará la actualización. Los usuarios que no estén de acuerdo con las actualizaciones pueden retirarse dentro del período de notificación.
El extremo de la descentralización es la opción de tener contratos inteligentes completamente inmutables. Estos contratos no se rigen por ninguna billetera de firmas múltiples u otro comité, y una vez implementados, nunca se pueden actualizar.
Por supuesto, esto tiene sus propios problemas. Si hay algún error en el código, o algún evento importante requiere actualizar el contrato inteligente, la única opción para el nodo de agregación es bifurcarse con el nuevo contrato inteligente, dejando los fondos del usuario varados en el contrato anterior.
estado actual
Desafortunadamente, el estado actual de Rollup no se acerca a la implementación completa que discutimos anteriormente. La mayoría de los rollups todavía están en la fase de "ruedas de entrenamiento", tratando de hacerlo bien.
Según L2BEAT, Fuel v1 y DeGate son los dos únicos agregados que han madurado para alcanzar todas las condiciones de actividad y seguridad.
3. Economía
Veamos la economía de Rollup desde la perspectiva de los usuarios y operadores de Rollup:
1) Experiencia del usuario: los usuarios deberían obtener precios económicos y no tener que esperar demasiado para las transacciones
2) Beneficio de acumulación: debería ser rentable para los clasificadores y titulares de fichas operar acumulación
La experiencia del usuario se optimiza cuando los usuarios obtienen transacciones rápidas y económicas.
La velocidad a la que se finalizan las transacciones depende de la velocidad a la que se finalizan los bloques de la capa base. Las transacciones pueden considerarse definitivas siempre que se finalicen los datos en L1. Sin embargo, los usuarios que ejecutan nodos completos también pueden lograr una finalidad instantánea simplemente ejecutando transacciones y determinando el estado final.
Pero no es práctico para todos ejecutar un nodo completo. Por lo tanto, un cotejador centralizado es útil porque puede proporcionar a los usuarios una "confirmación suave" de que su transacción está incluida en un bloque y se finalizará. Esto es suficiente para la mayoría de los casos de uso. Sin embargo, implica confiar en una parte central que puede actuar en su contra.
Mientras que algunas soluciones de protocolo alternativo de secuenciador (p. ej., basadas en acumulaciones) renuncian a esta propiedad en detrimento de los usuarios, otras soluciones (p. ej., consenso de POS externo (p. ej., Espresso)) pueden proporcionar garantías de confirmación previa similares sin incurrir en el siguiente riesgo: Secuenciador centralizado.
¿Qué pasa con el costo para el usuario?
El precio explícito de una transacción de resumen suele ser:
Costo de gas L2 = Costo de gas L1 + Tarifa del secuenciador
Un ordenante central que actúa racionalmente siempre quiere maximizar sus propias ganancias, incluso si eso significa pasar costos más altos a los usuarios. Sin embargo, vale la pena señalar que esto tampoco puede resolverse necesariamente mediante un mecanismo de clasificación descentralizado. Incluso los nodos POS en un ordenante descentralizado quieren maximizar sus propias ganancias.
De hecho, esto crea un problema de desalineación en el que el agregado puede no querer entregar la ganancia a un clasificador externo.
Beneficio acumulado: además de las tarifas del secuenciador, Rollup también puede obtener ganancias al extraer MEV de las transacciones masivas de los usuarios. Este MEV a menudo es difícil de atribuir porque es difícil averiguar si el ordenante incluyó algunas de sus propias transacciones anticipadas en el lote.
**Si se reemplaza el Rollup por consenso de TPV externo, entregarán este MEV a los operadores externos. **
Vale la pena señalar que estos dos problemas de Rollups que entregan ingresos a mecanismos externos pueden resolverse a través de "acuerdos comerciales" entre Rollups y mecanismos externos, en los que se pueden resolver las tarifas y MEV generados por transacciones internas y cruzadas de Rollup. Redirige de nuevo al resumen.
Sin embargo, como se explicó en la charla de Jon Charbonneau durante Modular Summit y publicaciones posteriores, una mejor idea podría ser tener un delegado de gobierno acumulativo ordenando a un conjunto de nodos autorizados. Estos nodos se pueden elegir estratégicamente para que estén dispersos geográficamente, y la gobernanza puede simplemente expulsar a los malos actores.
**Esta puede ser una solución de dos pájaros de un tiro, ya que permite acumulaciones para mantener los márgenes internamente, al mismo tiempo que mitiga los efectos adversos de los clasificadores centralizados. **
Pero lo contrario de esto es que con una rotación limitada de clasificadores, los clasificadores pueden tener un comportamiento no miope, lo que puede conducir a precios de monopolio/aumento de precios a expensas de los usuarios de agregación.
De cualquier manera, está claro que es necesario algún protocolo de reemplazo del secuenciador para que el resumen sea rentable para los usuarios. Si se trata de una prueba de gobernanza, un mecanismo de consenso externo o cualquier otra cosa, es una discusión para otro artículo.
4. Conclusión
Esperemos que ahora quede claro que, sea cual sea el camino que tome el paquete acumulativo, es fundamental que el objetivo sea una implementación completa con mecanismos maduros para el reemplazo del clasificador, la inclusión forzada y las actualizaciones de gobernanza de retrasos. Incluso si se trata solo de una inclusión obligatoria y actualizaciones retrasadas, los fondos de los usuarios están seguros cuando el paquete acumulativo se implementa por completo, independientemente de si el coordinador está centralizado.
Sin embargo, un protocolo robusto de reemplazo de secuenciador podría mejorar las garantías de vida y potencialmente mejorar la economía de los usuarios de Rollup.
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.
Vea la importancia de la descentralización de Rollup desde tres aspectos
Autor: Shivanshu Madan; Compilador: Huohuo/Vernacular Blockchain
Gran parte de la discusión en Twitter últimamente gira en torno a la descentralización de L2. ¿Los Rollups que estamos construyendo están lo suficientemente descentralizados? ¿O al menos están en el camino de la descentralización? ¿Importa?
La idea de Rollup es simple: queremos que los participantes fuera de la cadena puedan realizar transacciones que luego puedan verificarse fácilmente en la cadena. Con Rollup, la capa base permite que su base de "confianza" se utilice para actividades que ocurren fuera de su esfera inmediata. A cambio, Rollup paga una pequeña tarifa (alquiler) para aprovechar este fideicomiso.
Entonces, ¿necesitamos Rollups descentralizados?
La respuesta intuitiva es ¡sí! Este es el espíritu con el que construimos la cadena de bloques.
Sin embargo, creo que la respuesta a esta pregunta no es un simple sí o no. En cambio, tiene múltiples facetas que deben analizarse individualmente. En los capítulos siguientes, analizaré esta cuestión desde tres perspectivas: filosófica, tecnológica y económica. ****Estos tres no son necesariamente exhaustivos o exclusivos, pero deberían brindar una buena perspectiva general del problema. **
1. Perspectiva filosófica
Comencemos por llevar la conversación a un nivel superior: ¿por qué nos importa la descentralización?
Porque queremos un futuro sin permisos que promueva la innovación abierta. Queremos que los usuarios puedan construir cosas nuevas sin restricciones y sin necesidad de confiar en ninguna entidad única.
En la breve historia de blockchain, muchos desarrolladores anónimos han creado cosas increíbles. De hecho, Bitcoin en sí mismo fue creado por una entidad anónima: ¡pronto puede ser la moneda que la mayoría de las personas en el mundo usan para pagos globales! ¡Ese es el poder de la innovación sin permiso!
La base descentralizada de redes sin confianza como Bitcoin y Ethereum nos permite construir ese futuro. ¡Entonces es obvio que cualquier cadena que tenga una relación de confianza con estas cadenas, como Rollups, también debe descentralizarse!
De hecho, plantea una pregunta interesante e importante:
**Si Rollup no está descentralizado, ¿eso significa que Ethereum no está descentralizado? **
Una forma un poco optimista de ver esto es que, en un mundo sin permisos, se debe permitir que los rollups construyan lo que quieran, incluidas (pero no limitadas a) cadenas totalmente autorizadas, y los usuarios de ese rollup aún deberían poder aprovechar la seguridad en el capa base. Incluso las cadenas autorizadas deberían ser seguras de usar siempre que la capa base esté descentralizada y el resumen esté "totalmente" implementado (hablaremos más sobre "totalmente implementado" en la sección técnica).
Pero la realidad es que la mayoría de los paquetes acumulativos actuales aún no han alcanzado la etapa de implementación completa y no brindan a los usuarios el nivel deseado de seguridad y confianza.
Entonces, ¿cómo es la implementación correcta del resumen? vamos a ver:
2. Tecnología
Para comprender verdaderamente el problema de la descentralización y la seguridad en el nivel de resumen, debemos analizarlo desde los primeros principios. No mucha gente puede explicar los primeros principios de blockchain mejor que Sreeram Kannan.
Una cadena de bloques es un libro mayor distribuido donde diferentes nodos en la red siguen un protocolo definido para obtener consenso sobre el estado del libro mayor. Dependiendo de cómo estos nodos vean la red, pueden tener diferentes reglas para confirmar el estado correcto de la red en su propio libro mayor.
Por ejemplo, en el protocolo Gasper de Ethereum, hay dos reglas de confirmación diferentes: la regla disponible (basada en la cadena más pesada) y la regla final (basada en los bloques confirmados por el dispositivo).
Especialmente en acumulaciones, los nodos completos tienen reglas de confirmación diferentes a las de los clientes ligeros. En el resumen tradicional de contratos inteligentes (SCR), el contrato inteligente (puente de verificación) tiene sus propias reglas de confirmación. Si no hay eventos adversos, estas reglas de confirmación eventualmente coinciden en las llamadas "regiones de consistencia". Como su nombre lo indica, en las zonas de consenso, todos los participantes tienen la misma vista de la red (y tienen el mismo historial en sus registros).
Si todas las reglas de confirmación son seguras, no sucederán cosas malas. Como compartió Sreeram en la publicación anterior, 5 propiedades definen principalmente la seguridad de estas reglas de confirmación.
Las primeras 2 propiedades juntas definen la condición "en vivo" del sistema, mientras que las últimas 3 propiedades definen la condición "segura".
Miremos cada uno desde la perspectiva de diferentes actores de agregación y veamos cuáles se pueden mitigar sin descentralización.
Diferentes actores confían en diferentes mecanismos para la seguridad y la vida.
Nodo completo:
Si ejecuta un nodo completo, tiene acceso a los datos publicados y puede verificarlos directamente. Luego puede usar esos datos para realizar transacciones usted mismo y determinar la validez de las transacciones y el estado final del Resumen después de esas transacciones.
Las restantes condiciones de seguridad son, por tanto, las propiedades de actividad y la resistencia a la recombinación. Para este último, los nodos completos se basan en los validadores de la cadena subyacente y el protocolo de consenso que utilizan, mientras que para las propiedades de vida, los nodos completos se basan en las implementaciones de secuenciador y resumen.
Cliente ligero:
La mayoría de los usuarios usan billeteras integradas en nodos ligeros o usan servicios de terceros para obtener datos de la cadena de bloques e interactuar con la cadena de bloques. Los nodos de luz pueden ser de varios tipos:
Si ejecuta un cliente ligero de validación completa, puede verificar que los datos estén disponibles a través del muestreo de disponibilidad de datos, puede verificar la validez de las transiciones de estado a través de pruebas de validez o pruebas de fraude, también puede verificar que el estado se haya finalizado en la base Consenso de capa (en Ethereum, esto se puede hacer siguiendo un comité de sincronización).
La condición de seguridad restante es entonces la propiedad de actividad, y los clientes ligeros confían en las implementaciones del secuenciador y del resumen.
Contrato inteligente incorporado (puente de verificación):
En el SCR tradicional, la "regla de confirmación" de un contrato inteligente es hacer cumplir las 5 propiedades de seguridad:
Los nodos completos de SCR se basan en contratos inteligentes para hacer cumplir las propiedades de vida. Ellos "absorben" la resistencia a la reestructuración de la capa base.
Los nodos de luz se basan en contratos inteligentes para mejorar las propiedades de vida y absorber DA y resistencia a la reorganización de la capa base. Pueden verificar la prueba de validez ellos mismos o mediante contratos inteligentes.
El consenso de SCR es seguir la cadena canónica definida por el contrato inteligente.
**¿Qué pasa con la acumulación soberana? **
Los Sovereign Rollups no tienen contratos inteligentes (puentes de verificación) para hacer cumplir las condiciones de validez o vida. En su lugar, demostrarán que se "bajan" a un nodo de resumen descendente. Estos nodos aún absorben la resistencia DA y Reorg de la capa base.
Al igual que en SCR, en los nodos consolidados soberanos se necesita algún mecanismo para hacer cumplir la propiedad de actividad. Para definir la cadena canónica, optaron por mecanismos independientes como la transmisión de pruebas p2p.
¿Qué tiene que ver todo esto con la descentralización?
Ya sea que se trate de un resumen de contrato inteligente o un resumen soberano, la propiedad de vida proviene de la implementación correcta del resumen. Como hemos visto anteriormente, una correcta implementación de la agregación debe incluir dos componentes importantes:
mecanismos de inclusión obligatoria, y
Protocolo de sustitución del secuenciador
La inclusión obligatoria ayuda a generar resistencia a la censura. Este mecanismo permite a los usuarios "forzar la inclusión" de sus transacciones directamente en la capa base. Cualquier usuario en el resumen puede forzar la salida de regreso a la capa base con sus fondos. Por lo tanto, incluso si solo hay un nodo recopilador centralizado para la agregación, no puede censurar a los usuarios siempre que exista un mecanismo de cumplimiento maduro.
¿Pero es eso suficiente?
Incluso si los usuarios pueden cerrar la sesión, esto puede significar que si la mayoría de los usuarios vuelven a L1, la empresa no tiene muchos incentivos para seguir funcionando. Además, el mecanismo de inclusión obligatoria suele tener un largo tiempo de espera y puede resultar bastante caro de implementar para el usuario medio. La resistencia a la censura que proporciona este mecanismo no es precisamente práctica (ni en tiempo real). Podemos llamar a esta situación "censura débil".
Luego tenemos el atributo de vitalidad final: crecimiento del libro mayor
Si el recopilador centralizado se vuelve malicioso, puede detener el crecimiento de la cadena de resumen simplemente deteniendo la producción de bloques. Si esto sucede, no hay nada que el usuario o la empresa pueda hacer para que el resumen vuelva a estar "activo".
Para resolver este problema, necesitamos un protocolo de reemplazo de secuenciador.
La idea del protocolo de reemplazo del secuenciador es que si el secuenciador se comporta de manera maliciosa, el gobierno agregado puede iniciar el secuenciador. Una de las formas de lograr esto es reemplazar los nodos de secuenciador centralizados con un protocolo de secuenciador descentralizado. Si el clasificador está descentralizado y no monopoliza los componentes básicos del resumen, es casi imposible detener el resumen.
Por lo tanto, si bien los fondos de los usuarios siempre están seguros en los paquetes acumulativos a través del mecanismo de inclusión obligatorio, la creación de un protocolo sólido de reemplazo de pedidos ayuda a mantener vivos los paquetes acumulativos y proporciona una resistencia práctica a la censura en tiempo real.
¿esto es todo?
No exactamente. Desde un punto de vista técnico, hay un aspecto más a considerar:
¿Qué pasaría si los propios contratos inteligentes pudieran ser actualizados por un comité central agregado? Digamos que los paquetes acumulativos se implementan correctamente en la actualidad, pero mañana el comité acuerda que ya no necesitamos contratos inteligentes, sino que en su lugar, transmitimos pruebas del estado del paquete acumulativo a la red p2p.
Si, como usuario de resumen, no está de acuerdo con dicha actualización, debería poder salir del resumen antes de que se implemente la actualización (aunque nuevamente, esta no es una buena experiencia para el usuario y puede ser perjudicial para el negocio). Esto se puede lograr a través de "actualizaciones de gobernanza retrasadas". Es como un "período de notificación" después del cual se implementará la actualización. Los usuarios que no estén de acuerdo con las actualizaciones pueden retirarse dentro del período de notificación.
El extremo de la descentralización es la opción de tener contratos inteligentes completamente inmutables. Estos contratos no se rigen por ninguna billetera de firmas múltiples u otro comité, y una vez implementados, nunca se pueden actualizar.
Por supuesto, esto tiene sus propios problemas. Si hay algún error en el código, o algún evento importante requiere actualizar el contrato inteligente, la única opción para el nodo de agregación es bifurcarse con el nuevo contrato inteligente, dejando los fondos del usuario varados en el contrato anterior.
estado actual
Desafortunadamente, el estado actual de Rollup no se acerca a la implementación completa que discutimos anteriormente. La mayoría de los rollups todavía están en la fase de "ruedas de entrenamiento", tratando de hacerlo bien.
Según L2BEAT, Fuel v1 y DeGate son los dos únicos agregados que han madurado para alcanzar todas las condiciones de actividad y seguridad.
3. Economía
Veamos la economía de Rollup desde la perspectiva de los usuarios y operadores de Rollup:
1) Experiencia del usuario: los usuarios deberían obtener precios económicos y no tener que esperar demasiado para las transacciones
2) Beneficio de acumulación: debería ser rentable para los clasificadores y titulares de fichas operar acumulación
La experiencia del usuario se optimiza cuando los usuarios obtienen transacciones rápidas y económicas.
La velocidad a la que se finalizan las transacciones depende de la velocidad a la que se finalizan los bloques de la capa base. Las transacciones pueden considerarse definitivas siempre que se finalicen los datos en L1. Sin embargo, los usuarios que ejecutan nodos completos también pueden lograr una finalidad instantánea simplemente ejecutando transacciones y determinando el estado final.
Pero no es práctico para todos ejecutar un nodo completo. Por lo tanto, un cotejador centralizado es útil porque puede proporcionar a los usuarios una "confirmación suave" de que su transacción está incluida en un bloque y se finalizará. Esto es suficiente para la mayoría de los casos de uso. Sin embargo, implica confiar en una parte central que puede actuar en su contra.
Mientras que algunas soluciones de protocolo alternativo de secuenciador (p. ej., basadas en acumulaciones) renuncian a esta propiedad en detrimento de los usuarios, otras soluciones (p. ej., consenso de POS externo (p. ej., Espresso)) pueden proporcionar garantías de confirmación previa similares sin incurrir en el siguiente riesgo: Secuenciador centralizado.
¿Qué pasa con el costo para el usuario?
El precio explícito de una transacción de resumen suele ser:
Costo de gas L2 = Costo de gas L1 + Tarifa del secuenciador
Un ordenante central que actúa racionalmente siempre quiere maximizar sus propias ganancias, incluso si eso significa pasar costos más altos a los usuarios. Sin embargo, vale la pena señalar que esto tampoco puede resolverse necesariamente mediante un mecanismo de clasificación descentralizado. Incluso los nodos POS en un ordenante descentralizado quieren maximizar sus propias ganancias.
De hecho, esto crea un problema de desalineación en el que el agregado puede no querer entregar la ganancia a un clasificador externo.
Beneficio acumulado: además de las tarifas del secuenciador, Rollup también puede obtener ganancias al extraer MEV de las transacciones masivas de los usuarios. Este MEV a menudo es difícil de atribuir porque es difícil averiguar si el ordenante incluyó algunas de sus propias transacciones anticipadas en el lote.
**Si se reemplaza el Rollup por consenso de TPV externo, entregarán este MEV a los operadores externos. **
Vale la pena señalar que estos dos problemas de Rollups que entregan ingresos a mecanismos externos pueden resolverse a través de "acuerdos comerciales" entre Rollups y mecanismos externos, en los que se pueden resolver las tarifas y MEV generados por transacciones internas y cruzadas de Rollup. Redirige de nuevo al resumen.
Sin embargo, como se explicó en la charla de Jon Charbonneau durante Modular Summit y publicaciones posteriores, una mejor idea podría ser tener un delegado de gobierno acumulativo ordenando a un conjunto de nodos autorizados. Estos nodos se pueden elegir estratégicamente para que estén dispersos geográficamente, y la gobernanza puede simplemente expulsar a los malos actores.
**Esta puede ser una solución de dos pájaros de un tiro, ya que permite acumulaciones para mantener los márgenes internamente, al mismo tiempo que mitiga los efectos adversos de los clasificadores centralizados. **
Pero lo contrario de esto es que con una rotación limitada de clasificadores, los clasificadores pueden tener un comportamiento no miope, lo que puede conducir a precios de monopolio/aumento de precios a expensas de los usuarios de agregación.
De cualquier manera, está claro que es necesario algún protocolo de reemplazo del secuenciador para que el resumen sea rentable para los usuarios. Si se trata de una prueba de gobernanza, un mecanismo de consenso externo o cualquier otra cosa, es una discusión para otro artículo.
4. Conclusión
Esperemos que ahora quede claro que, sea cual sea el camino que tome el paquete acumulativo, es fundamental que el objetivo sea una implementación completa con mecanismos maduros para el reemplazo del clasificador, la inclusión forzada y las actualizaciones de gobernanza de retrasos. Incluso si se trata solo de una inclusión obligatoria y actualizaciones retrasadas, los fondos de los usuarios están seguros cuando el paquete acumulativo se implementa por completo, independientemente de si el coordinador está centralizado.
Sin embargo, un protocolo robusto de reemplazo de secuenciador podría mejorar las garantías de vida y potencialmente mejorar la economía de los usuarios de Rollup.