Introducción al mecanismo de inclusión de fuerza de Rollup

Autor original: NIC Lin
Fuente original: medio
Que la fuerza esté con usted. Este artículo presentará el mecanismo anticensura de transacciones de Rollup: Forzar la inclusión, y utilizará el diseño y la práctica de varios Rollups famosos como ejemplos.
Foto de Artur Tumasjan en Unsplash
Conocimientos previos:
Sepa cómo funciona Rollup y por qué Rollup necesita cargar transacciones en L1
Resistencia a la censura de transacciones
La capacidad de las transacciones para ser resistentes a la censura (resistentes a la censura) es muy importante para una cadena de bloques. Si una cadena de bloques puede realizar transacciones para cualquier usuario de censura, entonces esta cadena de bloques no es diferente de un servidor Web2. La actual resistencia de las transacciones de Ethereum a la censura proviene de la gran cantidad de validadores. Si Alice quiere revisar las transacciones de Bob y evitar que sus transacciones se carguen en la cadena, entonces Alice tendrá que intentar sobornar a todos los validadores de la red, o lo hará. basura. Toda la red de correo electrónico continúa enviando transacciones de spam que son más altas que las transacciones de Bob para llenar los bloques. De cualquier manera, sus costos serán muy altos.
Nota: En la arquitectura PBS actual de Ethereum, el costo de revisión se ha reducido significativamente. Puede consultar la revisión de la OFAC sobre la proporción de bloques en las transacciones de Tornado Cash. La resistencia actual a la censura se basa en verificadores e intermediarios independientes fuera de la OFAC y de la jurisdicción gubernamental.
Pero ¿qué pasa con los rollups? Rollup no requiere una gran cantidad de validadores para garantizar su seguridad. Además, Rollup solo tiene una función centralizada (secuenciador, llamado secuenciador o secuenciador) para procesar bloques por lotes y es tan seguro como L1. Pero la seguridad y la resistencia a la censura son dos cosas diferentes. La creación de un Rollup es tan segura como Ethereum, pero solo tiene un secuenciador centralizado que luego puede revisar las transacciones de cualquier usuario si así lo desea.
Sequencer puede negarse a recibir transacciones de los usuarios, lo que hace que los usuarios no puedan usar o abandonar Rollup.
mecanismo de inclusión forzada
Al mismo tiempo, se requiere que Rollup tenga tantos validadores como L1 para garantizar la resistencia a la censura. Es mejor usar directamente la resistencia a la censura de L1: el secuenciador también comprime los datos de la transacción en el contrato Rollup de L1. una función en el contrato acumulativo para monitorear a los usuarios. También puede insertar transacciones en la clasificación. Este método se llama inclusión forzada. Mientras Sequencer no pueda revisar las "transacciones L1" de los usuarios monitoreados, no puede evitar que los usuarios inserten por la fuerza transacciones Rollup a través de L1, y la operación y seguridad de Rollup se basan en las capacidades anticensura de L1.
El secuenciador no puede revisar las transacciones L1 del usuario a menos que exista un costo muy complejo.
Nota: La inclusión forzada solo es posible si se diseña el Rollup. Los usuarios definitivamente pueden atravesar L1 e insertar con fuerza transacciones Rollup. Si Rollup no proporciona un mecanismo de inclusión forzada, entonces los usuarios sólo pueden rezar para que la revisión de Sequencer no se negocie por sí sola.
La transacción entra en vigor inmediatamente versus efecto retardado
Si permitimos que las transacciones insertadas a través de Force Inclusion se escriban directamente en el historial de transacciones de Rollup (con efecto inmediato), entonces el estado de Rollup cambiará inmediatamente. Por ejemplo, Bob inserta un bolígrafo a través del mecanismo de Force Inclusion "Transfirió 1000 DAI. Para la transacción "Carol", si la transacción entra en vigor inmediatamente, entonces el saldo de Bob en el último estado será 1000 DAI menos y Carol será 1000 DAI más (por supuesto, la premisa es que el saldo de Bob supera los 1000 DAI).
Si la transacción de Bob se puede escribir directamente en el historial de transacciones y entrar en vigencia de inmediato, entonces el estado del Rollup cambiará de inmediato.
Si el secuenciador está recopilando transacciones fuera de la cadena en este momento y espera hasta que la siguiente transacción se envíe al contrato acumulativo, puede verse afectado por la transacción que Bob inserta a la fuerza y ​​entra en vigor de inmediato. Por ejemplo, Bob solo necesita enviar una transacción de pago de "él" transfiere 1000 DAI a Alice" al Sequencer por adelantado. Sequencer equivale a verificar que no hay ningún problema y promete recibir ingresos. Tanto Alice como Bob pueden consultar a Sequencer si Se recibirá la transacción y se calculará el resultado. El estado más reciente (Alice tiene 1000 DAI más y Bob tiene 1000 DAI menos). Pero cuando el secuenciador descubrió que Bob se había apresurado a insertar la transacción por la fuerza, el estado de ejecución de las transacciones en sus manos había cambiado. Sabía que la transacción "Bob transfirió 1000 DAI a Alice" se había convertido en un error de ejecución y Alice no pudo. Consíguelo a 1000 DAI.
El secuenciador recibe la transacción de Bob, por lo que Alice cree que recibirá 1000 DAI
Como resultado, Bob se vio obligado directamente a recibir otra transacción conflictiva en L1, lo que provocó que la transacción en la mano de Sequencer no se recibiera y Alice no pudiera obtener DAI.
Es posible que esta no sea una buena experiencia para el usuario, por lo que Rollup generalmente hace que la transacción de inclusión forzada entre en vigor de inmediato, pero hace avanzar la transacción a un estado de "preparación". El secuenciador puede elegir si desea agregar las transacciones que ingresan al estado de "preparación" al final del lote cuando se envía la transacción presupuestaria. Si el secuenciador nunca quiere procesar estos estados de "preparación", estas transacciones se procesarán después de un. Después de un cierto período de tiempo, se puede insertar por la fuerza en el historial de transacciones.
Bob quiere engañar a Alice forzando la transacción de ingresos, pero en realidad la transacción se pondrá en cola primero.
El secuenciador puede decidir por sí mismo cuándo "incluir" las transacciones en espera en la cola, por lo que la transacción de Bob a Alice DAI se ejecutará primero.
Si el secuenciador no está esperando transacciones en la cola, después de un cierto período de tiempo, el usuario (o cualquier persona) puede forzar los ingresos por sí mismo.
El secuenciador se niega a recibir la transacción de Bob, por lo que Bob pone en cola la transacción desde L1
El secuenciador aún puede continuar rechazando transacciones en la cola durante algún tiempo.
Sin embargo, Sequencer no puede rechazar transacciones que esperan en la cola para siempre. Después de un período de tiempo, cualquiera puede activar ingresos forzados. A continuación, presentaremos la implementación del mecanismo de contención de fuerza de los Rollup más famosos, como Optimism, Arbitrum, StarkNet y zkSync. .
Mecanismo optimista de inclusión del poder
Primero, introduzcamos el proceso de depósito de Optimismo. Este depósito no solo se refiere a depositar dinero en Optimismo, sino que es equivalente al más general "depositar mensajes para L2" en L2. Después de recibir el mensaje recién depositado, el nodo L2 transmite el mensaje y lo convierte en una transacción del puerto L2 para su ejecución y transmite el mensaje al destinatario designado.
Mensaje del usuario depositando dinero de L1 a L2
Contrato L1CrossDomainMessenger
Cuando un usuario decide depositar tokens ETH o ERC-20 en Optimism, interactúa (a través de la web) con el contrato L1StandardBridge en L1, especificando cuánto depositar y de qué dirección recibirlo, etc. Luego, el mensaje de conexión L1StandardBridge se pasa al contrato L1CrossDomainMessenger de la siguiente capa. Este contrato se utiliza principalmente como un contrato de comunicación general entre L1 y L2. L1StandardBridge utiliza este contrato de comunicación general para comunicarse con L2StandardBridge en L2 para decidir quién puede comenzar a acuñar. tokens de L2 o retirar tokens de L1. Si un desarrollador necesita desarrollar un contrato para la interoperabilidad y el estado de sincronización entre L1 y L2, entonces puede construirlo en L1CrossDomainMessenger.
El contrato CrossChainMessenger de mensajería del usuario se pasa de L1 a L2
Contrato Portal Optimismo
El contrato L1CrossDomainMessenger enviará el mensaje al contrato OptimismPortal de nivel más bajo. Una vez procesado el contrato OptimismPortal, emitirá un evento TransactionDeposited. Los parámetros del evento incluyen "la persona que envió el mensaje" y "la persona que recibió el mensaje". ", y parámetros de ejecución relacionados.
Luego, el nodo Optimism de L2 escuchará el evento TransactionDeposited emitido por el acuerdo OptimismPortal y convertirá los parámetros del evento en una transacción que registre L2. El iniciador de esta transacción L2 puede ser el "remitente del mensaje" en el evento TransactionDeposited. la persona que envió la transacción El receptor será la "persona que recibe el mensaje" en el evento, y los parámetros del evento también pasan otros parámetros de ejecución.
El nodo L2 inserta el evento TransactionDeposited emitido por OptimismPortal en transacciones L2 anotadas
Por ejemplo, esta es una transacción en la que un usuario deposita 0,01 ETH a través del contrato L1StandardBridge. Este mensaje y el ETH se transmiten hasta el contrato OptimismPortal (la dirección es 0xbEb5...06Ed). en una transacción L2 y el iniciador del mensaje es el contrato L1CrossDomainMessenger. El destinatario es el contrato L2CrossDomainMessenger en L2 que viene con 0,01 ETH;
inclusión forzada
Cuando el usuario quiere forzar que su transacción se ejecute de manera optimista, no necesita enviar un mensaje de L1 a L2, por lo que no utilizará el contrato L1CrossDomainMessenger. El efecto que quiere lograr es hacer que la factura especifique que "la transacción que envía y ejecuta en L2 desde su dirección L2" se ejecute sin problemas, por lo que interactuará directamente con el contrato OptimismPortal y dejará que su dirección L2 llame al contrato OptimismPortal, entonces que cuando el evento TransactionDeposited se convierta en una transacción L2, el "iniciador de la transacción" será su dirección L2", para que la transacción se pueda ver nuevamente.
En la transacción L2 convertida del evento TransactionDeposited, el iniciador será el propio Bob; el destinatario es el contrato Uniswap y irá acompañado del ETH especificado, tal como el propio Bob inició la transacción L2;
Utilice la dirección L2 para llamar a la función depositTransaction firmada por OptimismPortal y recuerde completar los parámetros de la transacción L2 uno por uno.
Hice una transacción de inclusión forzada simple: transferirme dinero a mí mismo a mi dirección L2 (0xeDc1...6909) y adjunté un mensaje de texto de "inclusión forzada". Esta es la transacción L1 en la que ejecuto la función DepositTransaction a través del contrato OptimismPortal. 5Be00000000000000C350006666F72636520696E636C7573696F6E) cuánto se codifica "Cuánto ETH trae la persona", "El iniciador de la transacción L2 debe llevar ETH al destinatario L2", "Límite de gas de la transacción L2" y "Datos al destinatario L2" y otra información.
Evento TransactionDeposited emitido por la transacción L1
Después de interpretar los valores numéricos de varios datos en este opaqueData, obtendrá:
"Cuánto ETH está adjunto a la persona que llamó a DepositTransaction": 0 porque no quiero recargar ETH de L1 a L2
"¿Cuánto ETH debe enviar el iniciador de la transacción L2 al destinatario L2": 5566 (wei), porque quiero transferirme dinero a mí mismo
"Límite de gas de transacción L2": 50.000
"Datos para receptor L2": 0x666f72636520696e636c7573696f6e, borra "inclusión forzada" de la codificación hexadecimal de esta cadena
No mucho después, apareció la transacción L2 convertida: registre la transacción L2. Me transfirí dinero a mí mismo, la cantidad es 5566 y los datos son la cadena de "inclusión obligatoria". Y puede observar que el Tipo de Txn (tipo de transacción) en Otros atributos en la penúltima línea de la figura es la transacción del sistema 126 (Sistema), lo que significa que la transacción no fue iniciada por mí en L2, sino que se convirtió de el evento L1TransactionDeposited.
Conversión de transacción L2 completada
Si el usuario desea recuperar otros contratos con datos diferentes, lo mismo se hace completando los parámetros en la carta depositTransaction uno por uno. Solo recuerde usar la dirección L2 para ejecutar en L1, de modo que el iniciador de la transacción L2. será la dirección L2.
ventana del secuenciador
El nodo Optimism L2 mencionado anteriormente convierte el evento TransactionDeposited en una transacción L2. De hecho, este nodo Optimism se refiere al nodo Sequencer. Después de todo, se trata de secuenciación de transacciones, por lo que solo el Sequencer puede decidir cuándo convertirlo en una transacción L2. . Al escuchar el evento TransactionDeposited, es posible que el secuenciador no necesariamente convierta el evento en una transacción L2 de inmediato, pero puede decidir convertirlo por un período de tiempo. Este período de tiempo se denomina ventana del secuenciador en Optimism. mainnet es actualmente de 24 horas. Luego, cuando el usuario comience a depositar dinero desde L1 o reciba un recordatorio, o incluya por la fuerza una transacción de recarga, el peor de los casos será que se incluya oficialmente en el historial de transacciones de L2 24 horas después. pero al menos esto es mejor que la transacción en la que nunca se puede evitar el resultado de estar incluido.
El mecanismo de inclusión forzosa de Arbitrum
En optimismo, la operación de depósito de L1 emitirá un evento TransactionDeposited, y el resto es esperar a que el Secuenciador reciba la operación de depósito pero en cualquier operación de L1 (depositar dinero o enviar mensajes a L2, etc.) se almacenará; en una cola acordada por L1, en lugar de simplemente emitir eventos. Al secuenciador se le dará un período de tiempo para agregar las operaciones L1 en esta cola al historial de transacciones. Si el secuenciador se agota cuando se acabe el tiempo, se puede completar sin que nadie tenga que reemplazar el secuenciador.
El arbitraje mantendrá una cola en el contrato L1. Si el secuenciador no recibe activamente transacciones en la cola, cuando se acabe el tiempo, cualquiera puede forzar que las transacciones en la cola se ingresen en el historial de transacciones.
Todas las operaciones L1 son contratos de Bandeja de entrada retrasada. Como su nombre lo indica, las operaciones aquí se retrasarán y expirarán. El otro contrato es Sequencer Inbox, que es una interfaz para cargar transacciones L2 en Sequencer. Las transacciones cargadas por Sequencer se escribirán directamente en el historial de transacciones. Además, cuando se cargue Sequencer, puede elegir cuántas operaciones L1 tomar de la Bandeja de entrada retrasada y escribirlas juntas en el historial de transacciones, para que estas operaciones L1 puedan tomarse. efecto.
SequencerInbox contiene el historial de transacciones. Generalmente, solo Sequencer puede escribir directamente nuevas transacciones; DelayedInbox contiene transacciones en espera de ser recibidas.
Cuando Sequencer escribe una nueva transacción, puede iniciar una transacción desde DelayedInbox y escribirla juntos.
Diseños complejos y documentación impresionante.
Si los lectores consultan directamente el capítulo oficial de Arbitrum sobre Secuenciador y Force Inclusion, verán que la Force Inclusion mencionada allí es compatible, así como algunos nombres de parámetros y nombres de funciones: El usuario primero va a la Bandeja de entrada para programar una cita para llamar a la función sendUnsignedTransaction. Si el secuenciador no está en el ingreso de la cita dentro de las 24 horas, el usuario puede llamar a la función forceInclusion firmada por la bandeja de entrada del secuenciador. De esta manera, ni siquiera se incluye el enlace y usted mismo solo puede aceptar la función correspondiente en el código del programa.
Cuando encuentra la función sendUnsignedTransaction, descubre que en realidad necesita completar el valor nonce y el valor maxFeePerGas usted mismo. ¿Qué dirección es el nonce? ¿Qué red es el valor maxFeePerGas? ¿Cuál es la mejor manera de completarlo? No hay documentación, ni siquiera de Natpsec. Luego también encuentra una función que acumula máscaras: sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction Tampoco hay ningún documento que le indique la diferencia entre estas funciones, cómo usarlas y cómo completar los parámetros, ni siquiera Natpsec.
Lo considera todo y lo prueba antes de completar los parámetros y enviar la transacción. Quiere usar prueba y error para ver si puede encontrar el método correcto, pero descubre que todas estas funciones usarán su dirección L1 como una. alias de dirección, lo que resulta en el final. El iniciador de la transacción en L2 es básicamente una dirección diferente, por lo que su dirección L2 no se mueve en absoluto.
Enviar mensaje L2
Más tarde, accidentalmente hice clic en un enlace en la página de búsqueda de Google y descubrí que Arbitrum originalmente tenía una biblioteca de tutoriales. Había un script que demostraba cómo enviar transacciones L2 desde L1 (o lo que significa Force Inclusion), y su función era completa. diferente del mencionado anteriormente ¿Alguno de ellos es solo una función llamada sendL2Message, y el parámetro del mensaje es en realidad una transacción Arbitrum L2 firmada? ? ? ¿Quién hubiera sabido que "enviar mensajes L2" en realidad significaría "transacción L2 firmada"? ? Y una vez más, no hay documentación ni Natspec que explique cuándo y cómo utilizar esta función.
Conclusión: es problemático generar manualmente una transacción de ingreso forzoso de Arbitrum. Se recomienda seguir el tutorial oficial y ejecutar el SDK de Arbitrum. A diferencia de otros paquetes acumulativos, Arbitrum tiene documentación clara para desarrolladores y notas de código de proyecto. El propósito y los parámetros de muchas funciones carecen de explicación, lo que hace que los desarrolladores dediquen más tiempo del esperado a acceder a ellos y utilizarlos. También le pregunté a la gente de Arbitrum sobre Arbitrum Discord pero no obtuve una respuesta satisfactoria.
Nota: Cuando pregunté en Discord, la otra parte simplemente me pidió que escuchara sendL2Message. No hubo necesidad de explicar para qué se usan otras funciones (incluso sendUnsignedTransaction mencionada en el archivo de inclusión obligatoria), cómo usarlas y cuándo. usalos, usalos a ellos.
Desafortunadamente, StarkNet actualmente no exige la inclusión. Sólo hay dos artículos en el foro oficial que discuten la censura y los mecanismos de inclusión obligatoria.
No se puede demostrar el error de la transacción
La razón es que el sistema de prueba de conocimiento cero de StarkNet no puede probar transacciones que no se registraron, por lo que no se puede permitir el crédito forzado. Porque si alguien fuerza maliciosamente (o involuntariamente) la entrada de una transacción que falla y no se puede probar, StarkNet se quedará directamente estancado: porque después de que la transacción se ingresa por la fuerza, Prover debe probar la transacción fallida, pero no tiene forma de probarla. .
StarkNet espera introducir la función de probar transacciones fallidas en la versión v0.15.0, y luego debería ser posible implementar aún más el mecanismo de inclusión obligatoria.
Mecanismo de inclusión obligatoria de zkSync
El mecanismo de transferencia de mensajes L1->L2 y de inclusión forzada de zkSync se realiza a través de la función requestL2Transaction del contrato MailBox. El usuario especifica la dirección L2 a la que se llamará, los datos de la llamada, la cantidad de ETH en el cinturón y el valor del límite de gas L2. , etc., y divide los parámetros de requestL2Transaction. Combínelos en una transacción L2 y luego simule la cola de prioridad (El secuenciador especificará cuántas transacciones sacar de la cola de prioridad cuando la copia de seguridad de la transacción se cargue en L1). (función confirmarBatches).
zkSync es muy similar a Optimistic en términos de la interfaz de inclusión forzada. Ambos usan la dirección L2 del usuario para llamar y completar datos relevantes (llamado, datos de llamada, etc.), en lugar de completar una transacción L2 firmada como Arbitrum; En términos de diseño, las transacciones son las mismas que Arbitrum en cuanto a mantener una cola de entidades en L1, y Sequencer toma transacciones de la cola y las escribe en el historial de transacciones.
El usuario inserta transacciones L2 en la cola de prioridad a través de requestL2Transaction, y el secuenciador puede comunicarse con la transacción desde la cola de prioridad al confirmar lotes.
Si recarga ETH a través del puente oficial de zkSync, que es equivalente a la transacción en este momento, llamará a la función requestL2Transaction del contrato MailBox. Mantendrá el ETH recargado en la cola de prioridad de transacciones L2 y emitirá un evento NewPriorityRequest. Debido a que el contrato codifica los datos de la transacción L2 en una cadena de bytes, no es fácil de leer. Si observa los parámetros de la transacción L1, verá que el destinatario de L2 en los parámetros también es el iniciador de la transacción. transacción porque (es un depósito para usted mismo), por lo que después de un tiempo, cuando el secuenciador saca la transacción L2 de intercambio de la cola de prioridad y la incluye en el historial de transacciones, se convertirá en L2 en una transacción que registra la transferencia. a sí mismo, y el monto de la transferencia es del iniciador de la transacción en L1. La cantidad de ETH llevada al depósito de intercambio ETH.
En la transacción de recarga L1, el iniciador y el receptor de la transacción son 0xeDc1…6909, la cantidad es 0,03 ETH y los datos de la llamada están vacíos.
La contabilidad 0xeDc1…6909 aparecerá en L2, una transacción que usted se transfiere a usted mismo. El tipo de transacción (Tipo Txn) es 255, que es una transacción del sistema.
A continuación, llamé a la carta requestL2Transaction directamente de acuerdo con el script y me envié la transacción que registró la llamada: sin ningún ETH, los datos de la llamada incluían la codificación hexadecimal de la cadena de "inclusión forzada". La fórmula siguiente se convierte en una transacción en L2 que registra su propia llamada. Los datos de la llamada contienen la cadena de "inclusión forzada": 0x666f72636520696e636c7573696f6e.
Cuando el secuenciador saca la transacción de la cola de prioridad y la escribe en el historial de transacciones, se puede convertir en la transacción L2 correspondiente en L2.
A través de la función requestL2Transaction, los usuarios pueden solicitar una transacción L2 en L1 con la dirección L2, especificando el destinatario L2, la cantidad de ETH aportada y los datos de la llamada. Si el usuario desea llamar a otros contratos con datos diferentes, también debe completar los parámetros uno por uno en la función requestL2Transaction. Solo recuerde usar la dirección L2 para ejecutar en L1, de modo que el iniciador de la transacción L2 sea L2. DIRECCIÓN. .
No existe ninguna función que permita a los usuarios forzar el ingreso
Aunque colocar las transacciones L2 en la cola de prioridad calculará automáticamente el período para que el secuenciador recopile las transacciones L2, el diseño actual de zkSync no incluye funciones relacionadas obligatorias que los usuarios puedan ejecutar ellos mismos, lo que equivale a la mitad de un conjunto. Entonces, aunque existe un "período de validez de ingresos", de hecho todavía depende de si el secuenciador quiere recibir ingresos: el secuenciador puede esperar hasta la transición para recibir ingresos, o nunca podrá recibir ninguna transacción en la cola de prioridad. En el futuro, zkSync debería agregar funciones relevantes para que los usuarios puedan forzar el ingreso cuando el ingreso haya pasado pero aún no haya sido recibido por el secuenciador. Este es un mecanismo de inclusión forzada verdaderamente efectivo.
Resumir
L1 depende de un gran grupo de personas para garantizar la "seguridad" y la "resistencia a la censura" de Internet, mientras que Rollup se basa en la "resistencia a la censura de L1" para obtener "la misma seguridad que L1", pero no incluye la resistencia a la censura de Rollup. capacidad
Por el contrario, debido a que Rollup utiliza un pequeño número o incluso un solo secuenciador para escribir transacciones, su capacidad anticensura es aún más débil. Por lo tanto, Rollup necesita un mecanismo de inclusión forzada para permitir a los usuarios omitir Sequencer y escribir transacciones en el historial para evitar que Sequencer las revise y no puedan usar o abandonar Rollup.
La inclusión forzada permite a los usuarios forzar que las transacciones se escriban en el historial, pero en el diseño, deben elegir si la transacción se puede insertar inmediatamente en el historial y entrar en vigor de inmediato. Si se permite que las transacciones entren en vigor inmediatamente, causará problemas al secuenciador y dificultad en la experiencia del usuario, porque las transacciones que esperan ser recibidas en L2 pueden verse afectadas por transacciones recibidas por la fuerza en L1.
Por lo tanto, el mecanismo de inclusión forzada actual de Rollup primero pondrá las transacciones insertadas en L1 en un estado de espera y le dará al secuenciador un período de tiempo para reaccionar y elegir si incluye estas transacciones en espera.
Tanto zkSync como Arbitrum mantienen una cola de entidades en L1 para administrar las transacciones de L2 enviadas por los usuarios desde L1 o los mensajes a L2. Arbitrum lo llama bandeja de entrada diferida; zkSync lo llama cola prioritaria;
Sin embargo, la forma en que zkSync envía transacciones L2 es similar a Optimism. Se envían a L1 utilizando la dirección L2, por lo que el iniciador de la transacción L2 será la dirección L2. La función de Optimism para enviar transacciones L2 se llama depositTransaction; zkSync se llama requestL2Transaction. Arbitrum crea una transacción L2 completa y la firma, y ​​luego la envía a través de la carta sendL2Message. Arbitrum restaurará al firmante a través de la firma en L2 como el iniciador de la transacción L2.
StarkNet actualmente no tiene un mecanismo de inclusión forzada; zkSync ha implementado medio conjunto de inclusiones obligatorias: hay una cola prioritaria y las transacciones L2 en cada cola tienen un período de validez de ingreso, pero este período de validez actualmente es solo para decoración. , el secuenciador puede elegir No recibir más transacciones L2 en la cola de prioridad