El ex embajador técnico de Arbitrum explica la estructura de los componentes de Arbitrum (Parte 2)

¿Cómo maneja Arbitrum los mensajes entre cadenas y las transacciones resistentes a la censura? ¿Cuál es su modelo de puente entre cadenas?

Escrito por: Luo Benben, ex embajador técnico de Arbitrum y colaborador geek de web3

En el artículo anterior* “El ex embajador técnico de Arbitrum interpreta la estructura de los componentes de Arbitrum (Parte 1)”**, presentamos el secuenciador, el validador, el contrato de la bandeja de entrada del secuenciador, el bloque acumulativo y la prueba de fraude no interactiva en los componentes principales de Arbitrum. En el artículo de hoy, nos centraremos en los componentes relacionados con la mensajería entre cadenas y las entradas de transacciones resistentes a la censura entre los componentes principales de Arbitrum. *

En el artículo anterior, mencionamos que el contrato Sequencer Inbox recibe específicamente el paquete de datos de transacciones Batch publicado por el secuenciador en Layer1. Al mismo tiempo, señalamos que La Bandeja de entrada del secuenciador también se denomina bandeja de entrada rápida, a diferencia de la Bandeja de entrada retrasada (denominada Bandeja de entrada). A continuación, proporcionaremos una explicación detallada de los componentes relacionados con la mensajería entre cadenas, como la Bandeja de entrada retrasada.

Principios de cadena cruzada y puente

Las transacciones entre cadenas se pueden dividir en L1 a L2 (recarga) y L2 a L1 (retiro). Tenga en cuenta que la recarga y el retiro mencionados aquí no están necesariamente relacionados con activos entre cadenas, pero pueden ser mensajes que no incluyen activos directamente. Entonces, estas dos palabras solo representan dos direcciones de comportamientos relacionados entre cadenas.

En comparación con las transacciones L2 puras, las transacciones entre cadenas intercambian información en dos sistemas diferentes, L1 y L2, por lo que el proceso es más complicado.

Además, lo que generalmente llamamos comportamiento de cadena cruzada es la cadena cruzada en dos redes no relacionadas utilizando un puente de cadena cruzada en modo testigo. La seguridad de esta cadena cruzada depende del puente de cadena cruzada. Operadores, robo de cadena cruzada Los puentes de cadenas basados en el modelo de testigos se han producido con frecuencia en la historia.

El comportamiento de la cadena cruzada entre Rollup y la red principal de ETH es esencialmente diferente de la cadena cruzada mencionada anteriormente, porque el estado de Layer2 está determinado por los datos registrados en Layer1, ** siempre que esté utilizando el Rollup oficial. El puente de cadenas transversales es absolutamente seguro en su estructura operativa. **

Esto también resalta la esencia de Rollup. Desde la perspectiva del usuario, solo parece una cadena independiente, pero en realidad la llamada “**Layer2” es solo una ventana de visualización rápida que Rollup abre a los usuarios. Su estructura de tipo de cadena real todavía está grabado en Layer1. **Entonces, podemos pensar en L2 como media cadena o “una cadena creada en la Capa1”.

Tickets reintentablesRetryables

Cabe señalar que las cadenas cruzadas son asincrónicas y no atómicas: es imposible saber el resultado después de confirmar una transacción como en una cadena, ni puede garantizar que algo sucederá en el otro lado en un momento determinado. . Por lo tanto, la cadena cruzada puede fallar debido a algunos problemas menores, pero siempre que se utilicen los medios correctos, como Ticket reintentable, no ocurrirán problemas difíciles como atascos de fondos.

**Los boletos reintentables son las herramientas básicas utilizadas al depositar a través del puente oficial de Arbitrum. **Se utilizarán depósitos ETH y ERC20. Su ciclo de vida se divide en tres pasos:

**1. Presentar el ticket en L1. **Utilice el método createRetryableTicket() en el contrato de Bandeja de entrada retrasada para crear un ticket de recarga y enviarlo.

**2. Redención automática en L2. **En la mayoría de los casos, el clasificador puede ayudar automáticamente a los usuarios a pagar facturas sin operaciones manuales posteriores.

**3. Canje manual en L2. **En algunos casos extremos, como un aumento repentino en los precios del gas en la L2 y un prepago de gas insuficiente en el billete, no se puede realizar el pago automático. En este momento, se requiere la operación manual por parte del usuario.

Tenga en cuenta que si falla el canje automático, el pagaré deberá canjearse manualmente dentro de los 7 días; de lo contrario, el pagaré se eliminará (los fondos se perderán permanentemente) o será necesario pagar una tarifa para guardar el pagaré y renovar el contrato de arrendamiento.

Además, aunque el proceso de retiro del puente oficial Arbitrum tiene cierta similitud simétrica con el comportamiento de recarga, no existe el concepto de Retryables, que por un lado se puede entender desde el propio protocolo Rollup, y por otro lado, Podemos entenderlo a partir de algunas diferencias:

• **No hay canje automático durante el proceso de retiro, **porque EVM no tiene un temporizador ni automatización, y el canje automático se puede lograr en L2, que se implementa con la ayuda del secuenciador, por lo que los usuarios en L1 deben hacerlo manualmente. interactuar con el contrato de Bandeja de salida para reclamar activos de recuperación.
• **No hay problema de vencimiento del boleto al retirar efectivo. **Mientras haya pasado el período del desafío, puedes recibirlo en cualquier momento.

Puerta de enlace entre cadenas de activos ERC-20

Los activos ERC-20 entre cadenas son complejos. Podemos pensar en varias preguntas:

• Un token desplegado en L1, ¿cómo implementarlo en L2?
• ¿Es necesario implementar manualmente su contrato L2 correspondiente con anticipación, o el sistema puede implementar automáticamente contratos de activos para tokens que se han cruzado pero que aún no han implementado un contrato?
• Para los activos ERC-20 en L1, ¿cuál es la dirección del contrato correspondiente en L2? ¿Debería ser coherente con L1?
• ¿Cómo cruzar la cadena de tokens emitidos de forma nativa en L2 a L1?
• ¿Cómo se pueden encadenar tokens con funciones especiales, como tokens de rebase con cantidades ajustables y tokens que generan intereses y que crecen automáticamente?

No vamos a responder a todas estas preguntas porque son demasiado complejas para desarrollarlas. Estas preguntas solo se utilizan para ilustrar la complejidad de la cadena cruzada ERC20.

Actualmente, muchas soluciones de expansión utilizan soluciones de lista blanca + lista manual para evitar diversos problemas complejos y condiciones de contorno.

**Arbitrum utiliza el sistema Gateway para resolver la mayoría de los puntos débiles de la cadena cruzada ERC20. **Tiene las siguientes características:

• Los componentes de la puerta de enlace aparecen en pares en L1 y L2.
• **Gateway Router es responsable de mantener la asignación de direcciones entre Token L1<->Token L2, ** y la asignación entre algún token<->alguna puerta de enlace.
• La puerta de enlace en sí se puede dividir en puerta de enlace ERC20 estándar, puerta de enlace personalizada genérica, puerta de enlace personalizada, etc. para resolver diferentes tipos y funciones de problemas de puente ERC20.

Tomemos como ejemplo la cadena cruzada WETH relativamente simple para ilustrar la necesidad de personalizar la puerta de enlace.

WETH es un equivalente ERC20 de ETH. Como moneda principal, Ether no puede implementar funciones complejas en muchas dApps, por lo que se necesita un equivalente ERC20. Transfiera algo de ETH al contrato WETH, quedarán bloqueados en el contrato y se generará la misma cantidad de WETH.

De la misma manera, WETH también se puede destruir y extraer ETH. Obviamente, la cantidad de WETH circulantes y ETH bloqueados es siempre 1:1. **

Si ahora cruzamos WETH directamente con L2, encontraremos algunos problemas extraños:

• Es imposible desenvolver WETH en ETH en L2 porque no hay ETH correspondiente para bloquear en L2.
• Se puede utilizar la función Wrap, pero si estos WETH recién generados se vuelven a cruzar a L1, no se pueden decapsular en ETH en L1 porque los contratos WETH en L1 y L2 no son “simétricos”**.

Obviamente esto viola los principios de diseño de WETH. ** Luego, cuando WETH es de cadena cruzada, ya sea que se esté recargando o retirando, primero debe desenvolverse en ETH, luego cruzarse al otro lado y luego envolverse en WETH. **Esta es la función de WETH Gateway.

Lo mismo ocurre con otros tokens con lógica más compleja, que requieren una puerta de enlace más compleja y cuidadosamente diseñada para funcionar correctamente en un entorno entre cadenas. El Gateway personalizado de Arbitrum hereda la lógica de comunicación entre cadenas del Gateway normal y permite a los desarrolladores personalizar el comportamiento entre cadenas relacionado con la lógica del token, que puede satisfacer la mayoría de las necesidades.

Bandeja de entrada retrasada

Correspondiente al cuadro rápido, también conocido como SequencerInbox, está el cuadro lento Inbox (nombre completo Delayed Inbox)**. ¿Por qué debería haber una distinción entre velocidad y lentitud? Debido a que la caja rápida está dedicada a recibir el lote de transacciones L2 emitido por el secuenciador, todas las transacciones que no hayan sido preprocesadas por el secuenciador en la red L2 no deben aparecer en el contrato de caja rápida.

**La primera función de la caja lenta es manejar el comportamiento de recarga de L1 a L2. ** El usuario recarga a través de la caja lenta, y el secuenciador lo monitorea y luego lo refleja en L2. Finalmente, el secuenciador incluirá el registro de recarga en la secuencia de transacciones L2 y lo enviará a la bandeja de entrada del secuenciador del contrato de caja rápida.

En este ejemplo, no es apropiado que los usuarios envíen transacciones de recarga directamente a Express Box, porque las transacciones enviadas a Express Box Sequencer Inbox interferirán con la clasificación normal de transacciones de la Capa 2 y luego afectarán el trabajo del secuenciador.

La segunda función de la caja lenta es resistir la censura. Los usuarios envían transacciones directamente al contrato de caja lenta y el clasificador generalmente las agregará a la caja rápida en 10 minutos. Pero si el clasificador ignora maliciosamente su solicitud, la caja lenta también tiene una función de forzar inclusión:

Si se envía una transacción a la Bandeja de entrada retrasada, y después de 24 horas, el secuenciador no ha incluido la transacción en la casilla lenta en la secuencia de transacciones, ** el usuario puede activar manualmente la función de inclusión forzada en la Capa1, ** para el secuenciador lo ignora. Las solicitudes de transacción se recopilan a la fuerza en la bandeja de entrada del secuenciador y luego serán monitoreadas por todos los nodos de Arbitrum One y se incluirán a la fuerza en la secuencia de transacciones de Capa 2. **

Como acabamos de mencionar, los datos en el cuadro rápido son la entidad de datos históricos de L2. Por lo tanto, en el caso de censura maliciosa, las instrucciones de la transacción finalmente se pueden incluir en el libro mayor L2 a través de la caja lenta, que cubre escenarios como retiros forzados y escape de la Capa 2. **

De esto se puede ver que para transacciones en cualquier dirección y nivel, el secuenciador finalmente no podrá revisarlo permanentemente.

Varias funciones principales de Slow Box Inbox:

• depositETH(), la función más sencilla para depositar ETH.
• createRetryableTicket(), que se puede utilizar para ETH, ERC20 y recarga de mensajes. En comparación con depositETH(), tiene mayor flexibilidad; por ejemplo, puede especificar la dirección de pago L2 después del depósito, etc.
• Cualquiera puede llamar a forceInclusion(), que es la función de recopilación forzada. Esta función verificará si una transacción enviada al contrato de caja lenta no se ha procesado después de 24 horas. Si se cumplen las condiciones, los mensajes se recopilarán por la fuerza.

Sin embargo, cabe señalar que la función de inclusión de fuerza en realidad se encuentra en el contrato de caja rápida. Solo para facilitar la comprensión, la explicaremos juntos en la caja lenta.

Bandeja de salida Bandeja de salida

La Bandeja de salida solo está relacionada con retiros y puede entenderse como un sistema de registro y gestión de retiros:

• Sabemos que los retiros del puente oficial de Arbitrum deben esperar aproximadamente 7 días para que finalice el período de desafío y se finalice el bloque acumulativo antes de que se pueda implementar el retiro. Una vez finalizado el período de desafío, el usuario envía la prueba Merkle correspondiente al contrato de la bandeja de salida en Layer1, que luego se comunica con los contratos para otras funciones (como desbloquear activos bloqueados en otros contratos) y finalmente completa el retiro.
• El contrato OutBox registrará qué mensajes entre cadenas de L2 a L1 se han procesado para evitar que alguien envíe repetidamente solicitudes de retiro ejecutadas. pasó
• mapeo (uint256 => bytes32) gasto público, registra la correspondencia entre el índice de gasto de la solicitud de retiro y la información, si se mapea [spentIndex] != bytes32(0) entonces la solicitud ha sido retirada. El principio es similar al contador de transacciones Nonce para evitar ataques de repetición.

A continuación tomaremos ETH como ejemplo para explicar completamente el proceso de depósito y retiro. La única diferencia entre ERC20 y Gateway es que no se describirá en detalle.

Depósito ETH

1. El usuario llama a la función depositETH() de la caja lenta.

2. Esta función continuará llamando a bridge.enqueueDelayedMessage (), registrará el mensaje en el contrato puente y enviará ETH al contrato puente. **Todos los fondos de recarga de ETH se guardan en el contrato puente, que equivale a una dirección de recarga. **

3. El secuenciador monitorea los mensajes de recarga en el cuadro lento y refleja la operación de recarga en la base de datos L2. Los usuarios pueden ver los activos que han recargado en la red L2.

4. El secuenciador incluye el registro de recarga en el lote de transacciones y lo envía al contrato de caja rápida en L1.

Retiro de ETH

1. El usuario llama a la función retiroEth() del contrato ArbSys en L2 para destruir la cantidad correspondiente de ETH en L2.

2. El secuenciador envía la solicitud de retiro a la casilla express.

3 **El nodo Validador crea un nuevo bloque acumulativo basado en la secuencia de transacciones en el cuadro rápido, que contendrá la transacción de retiro anterior. **

4. Después de que el bloque acumulativo pasa el período de desafío y se confirma, el usuario puede llamar a la función Outbox.ute Transaction() en L1 para demostrar que los parámetros están dados por el contrato ArbSys mencionado anteriormente.

5. Una vez que se confirme que el contrato de la Bandeja de salida es correcto, se enviará al usuario la cantidad correspondiente de ETH en el puente desbloqueado.

Retiro rápido

**Si utiliza el puente oficial Optimistic Rollup para retirar efectivo, habrá un problema de espera hasta el período del desafío. Podemos utilizar un puente de cadena cruzada privado de terceros para evitar este problema: **

• Intercambio de cerraduras atómicas. Este método solo intercambia activos entre las dos partes dentro de sus respectivas cadenas y es atómico: siempre que una de las partes proporcione Preimage, ambas partes definitivamente obtendrán los activos que merecen. Pero el problema es que la liquidez es relativamente escasa y es necesario encontrar contrapartes punto a punto.
• **Testigo del puente de cadenas cruzadas. **Los tipos generales de puentes de cadenas cruzadas son puentes testigo. Los usuarios envían sus propias solicitudes de retiro y el destino del retiro apunta al operador del puente de terceros o del fondo de liquidez. Después de que el testigo descubre que la transacción entre cadenas se ha enviado al contrato de caja rápida de L1, puede transferir dinero directamente al usuario en el lado L1. Este enfoque utiliza esencialmente otro sistema de consenso para monitorear la Capa 2 y operar en función de los datos que ha enviado a la Capa 1. **El problema es que el factor de seguridad en este modo no es tan alto como el del puente Rollup oficial. **

Retiro forzado

force Inclusion() La función forzar inclusión se utiliza para resistir la revisión del secuenciador. Cualquier transacción local L2, transacción L1 a L2 y transacción L2 a L1 se puede implementar usando esta función. La revisión maliciosa del secuenciador afecta gravemente la experiencia de la transacción. En la mayoría de los casos, elegiremos retirar dinero y dejar L2. Por lo tanto, a continuación se utiliza el retiro forzado como ejemplo para introducir el uso de forceInclusion.

**Recuerde que en los pasos de retiro de ETH, solo los pasos 1 y 2 implican la revisión del secuenciador, por lo que solo es necesario cambiar estos dos pasos: **

• Llame a inbox.sendL2Message () en el contrato de cuadro lento en L1. Los parámetros de entrada son los parámetros que deben ingresarse al llamar a retiroEth () en L2. Este mensaje se compartirá con el contrato puente de la L1.
• Después de esperar el período de espera de inclusión forzada de 24 horas, llame a forzar inclusión () en el cuadro rápido para realizar la inclusión forzada. El contrato de caja rápida verificará si hay un mensaje correspondiente en el puente.

Los usuarios finales pueden retirar dinero en la Bandeja de salida y los pasos restantes son los mismos que los de los retiros normales.

Además, arbitrum-tutorials también tiene tutoriales detallados sobre el uso de Arb SDK para guiar a los usuarios sobre cómo realizar transacciones locales L2 y transacciones L2 a L1 a través de forceInclusion().