Además de los conocidos Validity Rollup y Optimistic Rollup, ¿cuáles son los diferentes métodos de clasificación de Rollup?
Escrito por: NIC Lin
Conocimiento previo:
Comprender cómo funciona el resumen y el problema de disponibilidad de datos (disponibilidad de datos) del resumen
Resumen del resumen
Independientemente de si se trata de Validity Rollup o Optimistic Rollup, cargarán datos en L1 (como Ethereum), para que todos puedan acceder a los datos del Rollup accediendo a L1, y usar esto para derivar el estado más reciente de Rollup, como Alice tiene 10 USDT y Bob tiene 5 USDT.
Los que no suben datos a L1 no pertenecen a Rollup (como Validium, zkPorter o Arbitrum AnyTrust), y no son objeto de este artículo. Además, este artículo no discutirá cómo el Rollup verifica la validez del estado, es decir, la diferencia entre Validity Rollup y Optimistic Rollup.
La primera parte de este artículo presentará Sovereign Rollup. Sovereign Rollup, como su nombre lo indica, es un Rollup con autonomía. Las actualizaciones de versión de Rollup o hard forks ocurren en Sovereign Rollups. La ubicación de la bifurcación no está en Classic Rollup, sino en el contrato L1 Rollup: el contrato L1 Rollup realiza la versión actualizaciones a través de billeteras de múltiples firmas o votación de gobierno. Es decir, un contrato en L1 determina qué versión debe usar un Rollup en la actualidad. Y si hay un ataque al Rollup en L1, como atacar el mecanismo de gobierno o atacar el propio contrato de Rollup, el Rollup se verá afectado. Por el contrario, debido a que Sovereign Rollup simplemente considera a L1 como un lugar para almacenar datos, todos los miembros de Sovereign Rollup pueden decidir qué versión usar actualmente bajo la cadena, y sin importar lo que suceda con L1, siempre que L1 no sea atacado (como como reorganización o cierre de cadena), el paquete acumulativo soberano no se verá afectado.
La segunda parte presentará el resumen basado. El resumen basado elimina el rol de secuenciador y entrega el poder de clasificación de transacciones a mineros L1, validadores, buscadores MEV, etc. No solo hace que la clasificación de las transacciones sea más descentralizada, sino que también simplifica el diseño y elimina muchos componentes del sistema.
Resumen soberano
Capa de disponibilidad de datos y capa de liquidación
Classic Rollup como Arbitrum, Optimism, StarkNet, etc., no solo considera a Ethereum (L1) como un lugar para almacenar datos (es decir, capa de disponibilidad de datos), sino que también considera a Ethereum como una capa de liquidación al mismo tiempo: la liquidación es realizado en Ethereum, y el estado de L2 es (es decir, el saldo de cada dirección en L2) se escribe en L1.
¿Por qué necesita escribir el estado L2 en L1? Porque de esta manera, L2 y L1 pueden intercambiar información y activos: L1/L2 dApps pueden sincronizar información y cooperar, ETH de L1 se puede transferir de forma segura entre L1/L2 y ARB/OP de L2 también se puede transferir de forma segura entre L1/L2. transferencia entre L2.
L1 puede leer el estado de L2 y puede transmitir mensajes de forma segura, y L1/L2 pueden comunicarse entre sí
El Sovereign Rollup elimina la capa de liquidación (o se convierte en una capa de liquidación) y simplemente usa L1 como la capa de disponibilidad de datos.
L1 solo lee los datos de bloque o transacción que Sovereign Rollup pone en L1, pero no conoce el estado más reciente de L2, por lo que no hay forma de comunicarse
¿Por qué eliminar la capa de liquidación? Existen diferentes motivos o causas:
Como se mencionó al principio, si la capa de liquidación de Rollup está en L1, se verá afectada por L1, ya sea que se actualice o se ataque.
Tal vez L1 en sí mismo no admita cálculos complejos para registrar el estado de resumen y usar este estado para comunicar activos de información. Por ejemplo, en Celestia, solo puede poner datos en él, o en Bitcoin, solo puede realizar cálculos. con capacidades limitadas, y tal L1 no puede convertirse en una capa de liquidación
Quizás el Rollup en sí mismo no necesite otra cadena como la Capa de liquidación, tiene sus propios tokens y ecología nativos, y no necesita intercambiar activos con L1
Cómo funciona la acumulación soberana
Sovereign Rollup simplemente usa L1 como la capa de disponibilidad de datos, carga datos en L1 y confía en L1 para garantizar que los datos estén disponibles y que el orden de los datos no cambie. Los nodos de Sovereign Rollup se basan en la lectura e interpretación de los datos en L1 para calcular el estado más reciente del Sovereign Rollup. La "interpretación y el cálculo" en realidad representan las reglas de consenso de Sovereign Rollup y la función de transición de estado: cómo filtrar bloques y transacciones que se ajustan al formato y las reglas de Sovereign Rollup a partir de datos L1, cómo verificar estos bloques y transacciones después de la selección, y verificar Luego cómo ejecutar estas transacciones para calcular el último estado.
El nodo Sovereign Rollup filtra sus propios bloques de los datos L1 e interpreta y calcula el estado más reciente
Si dos nodos de Sovereign Rollup son de versiones diferentes, pueden interpretar datos diferentes o calcular estados más recientes diferentes y, por lo tanto, estos dos nodos no estarán en la misma cadena, lo que ven es en realidad una de dos cadenas bifurcadas.
Diferentes versiones de nodos pueden obtener diferentes estados y están bifurcados en diferentes cadenas *
En realidad, esto es lo mismo que ejecutar diferentes versiones de los nodos de Ethereum, las dos versiones pueden no ser la misma cadena. Por ejemplo, después de la bifurcación dura, aquellos que se olviden de actualizar la versión del nodo o no estén dispuestos a actualizar la versión del nodo permanecerán naturalmente en la cadena original (como ETC, ETHPoW), mientras que aquellos que actualicen la versión del nodo estarán en la cadena original. nueva cadena (ETH).
Los lectores aquí también deben saber por qué se llama Sovereign Rollup, porque en Sovereign Rollup, todos pueden elegir la versión del nodo e interpretar los datos de acuerdo con el consenso (social) de su propio grupo. Si hay un desacuerdo en la comunidad de Sovereign Rollup hoy en día, como ETHPoW vs ETH, significa que todos siguen su propio camino y eligen diferentes versiones de nodos para interpretar los datos, pero los datos siguen siendo los originales y no han cambiado.
*Nota: Por supuesto, después de la bifurcación, los nodos de sus respectivas versiones cargarán datos que cumplan con sus propias reglas a L1, y luego ambos lados filtrarán directamente los datos cargados por la otra parte. *
En el punto medio en el tiempo, los siguientes nodos se bifurcaron a la versión v1.1.2, y luego los bloques de cada uno fueron independientes
¿Qué resúmenes soberanos hay?
Actualmente no hay ejemplos de Sovereign Rollups, pero a medida que la tendencia de diseño modular de la cadena de bloques se vuelve cada vez más popular, definitivamente habrá muchos Sovereign Rollups. Por ejemplo, el marco modular Rollkit que está diseñando Celestia puede crear un Sovereign Rollup a través de Cosmos SDK. A diferencia de la cadena original (una L1) creada con Cosmos SDK, que necesitaría implementar el consenso de Tendermint para determinar el orden de las transacciones, Sovereign Rollup puede usar un solo secuenciador para clasificar transacciones como el actual Rollup común, eliminando la necesidad de múltiples consensos. nodos y confiando en sus preocupaciones de seguridad y los recursos consumidos para ejecutar el algoritmo de consenso. Y el Sovereign Rollup carga los datos de la transacción a Celestia, pero al mismo tiempo, debido a que es un Sovereign Rollup, no se verá afectado por L1 (como una actualización o un ataque).
*Nota 1: Más tarde, Rollkit también admitió el uso de Bitcoin como una capa de disponibilidad de datos. Tal paquete acumulativo puede heredar la seguridad de Bitcoin, pero el rendimiento se limitará a Bitcoin. *
*Nota 2: Básicamente, las cadenas basadas en Celestia pueden llamarse Sovereign Rollup. *
O supongamos que Arbitrum ya no usa Ethereum como una capa de liquidación, ya no necesita intercambiar información o activos con Ethereum, y simplemente considera a Ethereum como un lugar para almacenar datos, entonces dicho Arbitrum también se convertirá en un Sovereign Rollup.
Resumen de liquidación
También hay definiciones como Liquidación acumulada, pero básicamente es Soberana acumulada, y luego esta soberana acumulada también será la capa de liquidación de otras cadenas. Es decir, si hay otras cadenas en un Sovereign Rollup, y otros Rollups lo consideran una Capa de liquidación, este Sovereign Rollup puede llamarse Settlement Rollup.
*Nota: Para poder convertirse en la capa de liquidación de otras cadenas, debe tener funciones básicas de contrato inteligente, para que las dos partes puedan intercambiar información y activos. *
Si se cambia Ethereum para cargar toda la información de la cadena a Celestia hoy, entonces dicho Ethereum será un paquete acumulativo soberano en Celestia, y también será un paquete acumulativo de liquidación, porque hay muchas cadenas en Ethereum, y muchos acumulativos lo consideran una capa de liquidación. .
Ethereum es el Sovereign Rollup en Celestia y también el Settlement Rollup
Nota: Quizás en el futuro, todos se familiaricen gradualmente con la modularización y las funciones de las diferentes Capas, y ya no comiencen desde la perspectiva de Rollup, y términos como Sovereign Rollup o Settlement Rollup desaparezcan gradualmente. De todos modos, lo importante es cómo diseñar su cadena (ya sea L1, L2, L3, etc.), cómo hacer concesiones y elegir las herramientas de construcción adecuadas para las diferentes capas.
Resumen basado en ##
Otra clasificación de Rollup que ha surgido recientemente es el Rollup basado, o conocido como Rollup secuenciado L1. Basado en Rollup Basado se refiere a clasificar transacciones. Rollup no se entrega a un secuenciador (o múltiples secuenciadores) para clasificar transacciones, sino que se entrega completamente a mineros L1, validadores o buscadores MEV, etc. para clasificar transacciones. Cuando Classic Rollup carga datos en L1, el contrato de L1 Rollup verificará si los carga un secuenciador calificado, mientras que el resumen basado no tiene restricciones y cualquiera puede cargarlo.
Cualquiera puede cargar bloques de resumen basado
La mayor ventaja de la acumulación basada en datos es que no hay un secuenciador, por lo que no hay un punto único de falla o incluso la necesidad de preocuparse de que el secuenciador tenga el poder completo de ordenar transacciones, es decir, no hay necesidad de preocuparse de que el secuenciador se bloquee y provoque el cierre de la cadena. o no aceptar deliberadamente transacciones de usuarios específicos, o preocuparse de que el secuenciador capture maliciosamente el MEV del usuario. El resumen basado hereda completamente el grado de descentralización de L1 en la generación de bloques.
El resumen basado tiene las siguientes ventajas:
El costo para que los usuarios dejen Rollup es muy bajo
En general, Rollup diseñará un mecanismo de inclusión forzada o un mecanismo de escotilla de escape para que los usuarios puedan instalarse directamente en L1 sin usar Sequencer para evitar que Sequencer no acepte intencionalmente transacciones de usuarios específicos o interrupciones de Sequencer que impidan que los usuarios abandonen las transacciones de Rollup en el bloque L2. Sin embargo, el primer costo de dicho diseño es alto. Los usuarios tienen que pagar la tarifa del minero L1 para insertar transacciones. El segundo costo es que las transacciones insertadas desde L1 pueden afectar el proceso de empaquetado de bloques L2 de Sequencer: es posible que L1 insert La transacción invalidará la transacción que el secuenciador pretende recopilar en el bloque L2. Por ejemplo, la transacción insertada por Alice en L1 transfiere todo el dinero a Bob, lo que resulta en la falla de la transacción en la que Alice transfiere dinero a Carol en el bloque L2.
Después de recibir la transacción de Alice, Sequencer confirma el resultado de la transacción y lo coloca en el siguiente bloque
Pero Alice envía otra transacción directamente a L1 a través de Force Inclusion, lo que provoca que la transacción de Alice recibida por Sequencer falle
Para evitar que la transacción insertada por L1 afecte el proceso de empaquetado de bloques L2 de Sequencer, Arbitrum no entrará en vigencia inmediatamente cuando la transacción insertada por L1 deba esperar a que Sequencer solicite activamente que la transacción se incluya en el último bloque antes tendrá efecto, o si Sequencer no responde, tendrá efecto después de un período de tiempo. El optimismo permite que la transacción surta efecto de inmediato.Si la transacción insertada por L1 afecta la transacción en el bloque L2, Sequencer debe encontrar una forma de tratarla. Puede leer esta introducción para obtener más información sobre la comparación entre Arbitrum y Optimism en el procesamiento de transacciones de colocación L1.
Diseño mucho más simple
El Rollup basado tiene menos funciones de Sequencer que el Rollup general y, por lo tanto, menos carga de hardware (no es necesario preocuparse por la carga de la máquina del Sequencer) y cualquier mecanismo para hacer que la clasificación de las transacciones sea más justa (como el mecanismo del Sequencer descentralizado). Entonces no hay necesidad del mecanismo Force Inclusion/Escape Hatch, incluidos los contratos relacionados con L1 y las herramientas fuera de la cadena relacionadas para facilitar que los usuarios realicen transacciones en L1 por sí mismos.
Pero el resumen basado también tiene algunas desventajas:
No hay servicio de confirmación de transacciones por adelantado
Con Sequencer, Sequencer puede decirle rápidamente al usuario el resultado de la ejecución de su transacción. Siempre que el usuario confíe en Sequencer, el resultado de la transacción se puede confirmar de inmediato sin esperar a que la transacción se cargue en L1.
En el resumen basado, Alice espera hasta que la transacción se cargue en L1 antes de creer que su transacción está incluida y tiene que esperar al menos un bloque L1
En resumen general, si Alice cree que el secuenciador aceptará su transacción, puede confirmar inmediatamente si la transacción será aceptada
El protocolo pierde la fuente de ingresos MEV
MEV ya no se entrega a Sequencer para verificar y extraer, sino a L1, por lo que L2 en sí no tiene forma de obtener los beneficios de MEV. Los ingresos de MEV se pueden capturar mediante el diseño de un mecanismo de licitación para los derechos de producción de bloques, pero aumentará relativamente el umbral para que los participantes de L1 participen en la producción de bloques, lo que reducirá el grado de descentralización, y la introducción de un mecanismo de licitación también traerá un cierto grado de complejidad.
Referencias y lecturas adicionales recomendadas
Resumen soberano
Resumen basado
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.
Un artículo para entender la clasificación de Rollup
Escrito por: NIC Lin
Conocimiento previo:
Comprender cómo funciona el resumen y el problema de disponibilidad de datos (disponibilidad de datos) del resumen
Resumen del resumen
Independientemente de si se trata de Validity Rollup o Optimistic Rollup, cargarán datos en L1 (como Ethereum), para que todos puedan acceder a los datos del Rollup accediendo a L1, y usar esto para derivar el estado más reciente de Rollup, como Alice tiene 10 USDT y Bob tiene 5 USDT.
Los que no suben datos a L1 no pertenecen a Rollup (como Validium, zkPorter o Arbitrum AnyTrust), y no son objeto de este artículo. Además, este artículo no discutirá cómo el Rollup verifica la validez del estado, es decir, la diferencia entre Validity Rollup y Optimistic Rollup.
La primera parte de este artículo presentará Sovereign Rollup. Sovereign Rollup, como su nombre lo indica, es un Rollup con autonomía. Las actualizaciones de versión de Rollup o hard forks ocurren en Sovereign Rollups. La ubicación de la bifurcación no está en Classic Rollup, sino en el contrato L1 Rollup: el contrato L1 Rollup realiza la versión actualizaciones a través de billeteras de múltiples firmas o votación de gobierno. Es decir, un contrato en L1 determina qué versión debe usar un Rollup en la actualidad. Y si hay un ataque al Rollup en L1, como atacar el mecanismo de gobierno o atacar el propio contrato de Rollup, el Rollup se verá afectado. Por el contrario, debido a que Sovereign Rollup simplemente considera a L1 como un lugar para almacenar datos, todos los miembros de Sovereign Rollup pueden decidir qué versión usar actualmente bajo la cadena, y sin importar lo que suceda con L1, siempre que L1 no sea atacado (como como reorganización o cierre de cadena), el paquete acumulativo soberano no se verá afectado.
La segunda parte presentará el resumen basado. El resumen basado elimina el rol de secuenciador y entrega el poder de clasificación de transacciones a mineros L1, validadores, buscadores MEV, etc. No solo hace que la clasificación de las transacciones sea más descentralizada, sino que también simplifica el diseño y elimina muchos componentes del sistema.
Resumen soberano
Capa de disponibilidad de datos y capa de liquidación
Classic Rollup como Arbitrum, Optimism, StarkNet, etc., no solo considera a Ethereum (L1) como un lugar para almacenar datos (es decir, capa de disponibilidad de datos), sino que también considera a Ethereum como una capa de liquidación al mismo tiempo: la liquidación es realizado en Ethereum, y el estado de L2 es (es decir, el saldo de cada dirección en L2) se escribe en L1.
¿Por qué necesita escribir el estado L2 en L1? Porque de esta manera, L2 y L1 pueden intercambiar información y activos: L1/L2 dApps pueden sincronizar información y cooperar, ETH de L1 se puede transferir de forma segura entre L1/L2 y ARB/OP de L2 también se puede transferir de forma segura entre L1/L2. transferencia entre L2.
L1 puede leer el estado de L2 y puede transmitir mensajes de forma segura, y L1/L2 pueden comunicarse entre sí
El Sovereign Rollup elimina la capa de liquidación (o se convierte en una capa de liquidación) y simplemente usa L1 como la capa de disponibilidad de datos.
L1 solo lee los datos de bloque o transacción que Sovereign Rollup pone en L1, pero no conoce el estado más reciente de L2, por lo que no hay forma de comunicarse
¿Por qué eliminar la capa de liquidación? Existen diferentes motivos o causas:
Cómo funciona la acumulación soberana
Sovereign Rollup simplemente usa L1 como la capa de disponibilidad de datos, carga datos en L1 y confía en L1 para garantizar que los datos estén disponibles y que el orden de los datos no cambie. Los nodos de Sovereign Rollup se basan en la lectura e interpretación de los datos en L1 para calcular el estado más reciente del Sovereign Rollup. La "interpretación y el cálculo" en realidad representan las reglas de consenso de Sovereign Rollup y la función de transición de estado: cómo filtrar bloques y transacciones que se ajustan al formato y las reglas de Sovereign Rollup a partir de datos L1, cómo verificar estos bloques y transacciones después de la selección, y verificar Luego cómo ejecutar estas transacciones para calcular el último estado.
El nodo Sovereign Rollup filtra sus propios bloques de los datos L1 e interpreta y calcula el estado más reciente
Si dos nodos de Sovereign Rollup son de versiones diferentes, pueden interpretar datos diferentes o calcular estados más recientes diferentes y, por lo tanto, estos dos nodos no estarán en la misma cadena, lo que ven es en realidad una de dos cadenas bifurcadas.
En realidad, esto es lo mismo que ejecutar diferentes versiones de los nodos de Ethereum, las dos versiones pueden no ser la misma cadena. Por ejemplo, después de la bifurcación dura, aquellos que se olviden de actualizar la versión del nodo o no estén dispuestos a actualizar la versión del nodo permanecerán naturalmente en la cadena original (como ETC, ETHPoW), mientras que aquellos que actualicen la versión del nodo estarán en la cadena original. nueva cadena (ETH).
Los lectores aquí también deben saber por qué se llama Sovereign Rollup, porque en Sovereign Rollup, todos pueden elegir la versión del nodo e interpretar los datos de acuerdo con el consenso (social) de su propio grupo. Si hay un desacuerdo en la comunidad de Sovereign Rollup hoy en día, como ETHPoW vs ETH, significa que todos siguen su propio camino y eligen diferentes versiones de nodos para interpretar los datos, pero los datos siguen siendo los originales y no han cambiado.
*Nota: Por supuesto, después de la bifurcación, los nodos de sus respectivas versiones cargarán datos que cumplan con sus propias reglas a L1, y luego ambos lados filtrarán directamente los datos cargados por la otra parte. *
En el punto medio en el tiempo, los siguientes nodos se bifurcaron a la versión v1.1.2, y luego los bloques de cada uno fueron independientes
¿Qué resúmenes soberanos hay?
Actualmente no hay ejemplos de Sovereign Rollups, pero a medida que la tendencia de diseño modular de la cadena de bloques se vuelve cada vez más popular, definitivamente habrá muchos Sovereign Rollups. Por ejemplo, el marco modular Rollkit que está diseñando Celestia puede crear un Sovereign Rollup a través de Cosmos SDK. A diferencia de la cadena original (una L1) creada con Cosmos SDK, que necesitaría implementar el consenso de Tendermint para determinar el orden de las transacciones, Sovereign Rollup puede usar un solo secuenciador para clasificar transacciones como el actual Rollup común, eliminando la necesidad de múltiples consensos. nodos y confiando en sus preocupaciones de seguridad y los recursos consumidos para ejecutar el algoritmo de consenso. Y el Sovereign Rollup carga los datos de la transacción a Celestia, pero al mismo tiempo, debido a que es un Sovereign Rollup, no se verá afectado por L1 (como una actualización o un ataque).
*Nota 1: Más tarde, Rollkit también admitió el uso de Bitcoin como una capa de disponibilidad de datos. Tal paquete acumulativo puede heredar la seguridad de Bitcoin, pero el rendimiento se limitará a Bitcoin. *
*Nota 2: Básicamente, las cadenas basadas en Celestia pueden llamarse Sovereign Rollup. *
O supongamos que Arbitrum ya no usa Ethereum como una capa de liquidación, ya no necesita intercambiar información o activos con Ethereum, y simplemente considera a Ethereum como un lugar para almacenar datos, entonces dicho Arbitrum también se convertirá en un Sovereign Rollup.
Resumen de liquidación
También hay definiciones como Liquidación acumulada, pero básicamente es Soberana acumulada, y luego esta soberana acumulada también será la capa de liquidación de otras cadenas. Es decir, si hay otras cadenas en un Sovereign Rollup, y otros Rollups lo consideran una Capa de liquidación, este Sovereign Rollup puede llamarse Settlement Rollup.
*Nota: Para poder convertirse en la capa de liquidación de otras cadenas, debe tener funciones básicas de contrato inteligente, para que las dos partes puedan intercambiar información y activos. *
Si se cambia Ethereum para cargar toda la información de la cadena a Celestia hoy, entonces dicho Ethereum será un paquete acumulativo soberano en Celestia, y también será un paquete acumulativo de liquidación, porque hay muchas cadenas en Ethereum, y muchos acumulativos lo consideran una capa de liquidación. .
Ethereum es el Sovereign Rollup en Celestia y también el Settlement Rollup
Nota: Quizás en el futuro, todos se familiaricen gradualmente con la modularización y las funciones de las diferentes Capas, y ya no comiencen desde la perspectiva de Rollup, y términos como Sovereign Rollup o Settlement Rollup desaparezcan gradualmente. De todos modos, lo importante es cómo diseñar su cadena (ya sea L1, L2, L3, etc.), cómo hacer concesiones y elegir las herramientas de construcción adecuadas para las diferentes capas.
Resumen basado en ##
Otra clasificación de Rollup que ha surgido recientemente es el Rollup basado, o conocido como Rollup secuenciado L1. Basado en Rollup Basado se refiere a clasificar transacciones. Rollup no se entrega a un secuenciador (o múltiples secuenciadores) para clasificar transacciones, sino que se entrega completamente a mineros L1, validadores o buscadores MEV, etc. para clasificar transacciones. Cuando Classic Rollup carga datos en L1, el contrato de L1 Rollup verificará si los carga un secuenciador calificado, mientras que el resumen basado no tiene restricciones y cualquiera puede cargarlo.
Cualquiera puede cargar bloques de resumen basado
La mayor ventaja de la acumulación basada en datos es que no hay un secuenciador, por lo que no hay un punto único de falla o incluso la necesidad de preocuparse de que el secuenciador tenga el poder completo de ordenar transacciones, es decir, no hay necesidad de preocuparse de que el secuenciador se bloquee y provoque el cierre de la cadena. o no aceptar deliberadamente transacciones de usuarios específicos, o preocuparse de que el secuenciador capture maliciosamente el MEV del usuario. El resumen basado hereda completamente el grado de descentralización de L1 en la generación de bloques.
El resumen basado tiene las siguientes ventajas:
El costo para que los usuarios dejen Rollup es muy bajo
En general, Rollup diseñará un mecanismo de inclusión forzada o un mecanismo de escotilla de escape para que los usuarios puedan instalarse directamente en L1 sin usar Sequencer para evitar que Sequencer no acepte intencionalmente transacciones de usuarios específicos o interrupciones de Sequencer que impidan que los usuarios abandonen las transacciones de Rollup en el bloque L2. Sin embargo, el primer costo de dicho diseño es alto. Los usuarios tienen que pagar la tarifa del minero L1 para insertar transacciones. El segundo costo es que las transacciones insertadas desde L1 pueden afectar el proceso de empaquetado de bloques L2 de Sequencer: es posible que L1 insert La transacción invalidará la transacción que el secuenciador pretende recopilar en el bloque L2. Por ejemplo, la transacción insertada por Alice en L1 transfiere todo el dinero a Bob, lo que resulta en la falla de la transacción en la que Alice transfiere dinero a Carol en el bloque L2.
Después de recibir la transacción de Alice, Sequencer confirma el resultado de la transacción y lo coloca en el siguiente bloque
Pero Alice envía otra transacción directamente a L1 a través de Force Inclusion, lo que provoca que la transacción de Alice recibida por Sequencer falle
Para evitar que la transacción insertada por L1 afecte el proceso de empaquetado de bloques L2 de Sequencer, Arbitrum no entrará en vigencia inmediatamente cuando la transacción insertada por L1 deba esperar a que Sequencer solicite activamente que la transacción se incluya en el último bloque antes tendrá efecto, o si Sequencer no responde, tendrá efecto después de un período de tiempo. El optimismo permite que la transacción surta efecto de inmediato.Si la transacción insertada por L1 afecta la transacción en el bloque L2, Sequencer debe encontrar una forma de tratarla. Puede leer esta introducción para obtener más información sobre la comparación entre Arbitrum y Optimism en el procesamiento de transacciones de colocación L1.
Diseño mucho más simple
El Rollup basado tiene menos funciones de Sequencer que el Rollup general y, por lo tanto, menos carga de hardware (no es necesario preocuparse por la carga de la máquina del Sequencer) y cualquier mecanismo para hacer que la clasificación de las transacciones sea más justa (como el mecanismo del Sequencer descentralizado). Entonces no hay necesidad del mecanismo Force Inclusion/Escape Hatch, incluidos los contratos relacionados con L1 y las herramientas fuera de la cadena relacionadas para facilitar que los usuarios realicen transacciones en L1 por sí mismos.
Pero el resumen basado también tiene algunas desventajas:
No hay servicio de confirmación de transacciones por adelantado
Con Sequencer, Sequencer puede decirle rápidamente al usuario el resultado de la ejecución de su transacción. Siempre que el usuario confíe en Sequencer, el resultado de la transacción se puede confirmar de inmediato sin esperar a que la transacción se cargue en L1.
En el resumen basado, Alice espera hasta que la transacción se cargue en L1 antes de creer que su transacción está incluida y tiene que esperar al menos un bloque L1
En resumen general, si Alice cree que el secuenciador aceptará su transacción, puede confirmar inmediatamente si la transacción será aceptada
El protocolo pierde la fuente de ingresos MEV
MEV ya no se entrega a Sequencer para verificar y extraer, sino a L1, por lo que L2 en sí no tiene forma de obtener los beneficios de MEV. Los ingresos de MEV se pueden capturar mediante el diseño de un mecanismo de licitación para los derechos de producción de bloques, pero aumentará relativamente el umbral para que los participantes de L1 participen en la producción de bloques, lo que reducirá el grado de descentralización, y la introducción de un mecanismo de licitación también traerá un cierto grado de complejidad.
Referencias y lecturas adicionales recomendadas