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

Autor: Benben Luo, ex embajador técnico de Arbitrum, colaborador geek de web3

En el artículo anterior, “Los antiguos embajadores técnicos de Arbitrum explican la estructura de componentes de Arbitrum (Parte I)”, presentamos el papel de los secuenciadores, validadores, contratos de SequencerInbox, bloques acumulativos y pruebas de fraude no interactivas en los componentes principales de Arbitrum, y en el artículo de hoy, nos centraremos en los componentes de los componentes principales de Arbitrum relacionados con la mensajería de interacción entre cadenas y las entradas de transacciones resistentes a la censura.

Cuerpo: En un artículo anterior, mencionamos que el contrato de la bandeja de entrada del secuenciador recibe específicamente el lote de paquetes de transacciones publicados por el secuenciador en la capa 1. Al mismo tiempo, señalamos que la bandeja de entrada del secuenciador también se conoce como caja rápida, a diferencia de la bandeja de entrada retrasada de caja lenta (bandeja de entrada para abreviar). **A continuación, analizaremos más de cerca los componentes relacionados con la mensajería de interacción entre cadenas, como la bandeja de entrada retrasada.

Principios de Interacción y Puente entre Cadenas

Las transacciones de interacción entre cadenas se pueden dividir en L1 a L2 (depósito) y L2 a L1 (retiro). Tenga en cuenta que los depósitos y retiros mencionados aquí no están necesariamente relacionados con la interacción entre cadenas de activos y pueden ser mensajes que no vinculan directamente los activos. Por lo tanto, estas dos palabras solo significan dos direcciones de comportamiento relacionado con la interacción entre cadenas.

La transacción de interacción entre cadenas es más complicada que las transacciones L2 puras, las transacciones de interacción entre cadenas tienen información intercambiada en dos sistemas diferentes, L1 y L2.

Además, lo que solemos llamar comportamiento de interacción entre cadenas es la interacción entre cadenas en dos redes no relacionadas con un puente de interacción entre cadenas en modo testigo, y la seguridad de esta interacción entre cadenas depende del operador del puente de interacción entre cadenas, y el robo de puentes de interacción entre cadenas basado en el modelo testigo ha ocurrido con frecuencia en la historia.

El comportamiento de la interacción entre cadenas entre el Rollup y el ETHMainnet es fundamentalmente diferente de la interacción entre cadenas anterior, porque el estado de la Capa 2 está determinado por los datos registrados en la Capa 1, siempre que utilice el puente oficial de interacción entre cadenas Rollup, es absolutamente seguro en términos de estructura de operación. **

Esto también resalta la esencia de Rollup, es solo desde el punto de vista del usuario, como una cadena independiente, pero de hecho, la llamada ** “Capa 2” es solo una ventana de visualización rápida de Rollup abierta a los usuarios, y su estructura de cadena real todavía se quema en la Capa 1. Por lo tanto, podemos pensar en L2 como la mitad de una cadena, o “una cadena creada en la Capa 1”.

Ticket que se puede volver a intentar

Cabe señalar que la interacción entre cadenas es asíncrona y no atómica, es imposible conocer el resultado después de completar la confirmación de una transacción como en una cadena, y no hay garantía de que algo suceda en el otro lado en un momento determinado. Por lo tanto, la interacción entre cadenas puede fallar debido a algunos problemas blandos, pero siempre que se utilicen los medios adecuados, como el ticket reintentable, no se producirán problemas difíciles como fondos atascados.

**Los tickets reintentables son las herramientas básicas que se utilizan cuando se deposita a través del puente oficial de Arbitrum, **se utilizan depósitos de ETH y ERC20. Su ciclo de vida se divide en tres etapas:

**1. Envíe el ticket en L1. **Utilice el método createRetryableTicket() en el contrato de bandeja de entrada retrasada para crear un ticket de depósito y enviarlo.

**2. Canje automático en L2. ** En la mayoría de los casos, el secuenciador puede canjear automáticamente la factura para el usuario, sin necesidad de una operación manual posterior.

**3. L2. ** En algunos casos marginales, como un aumento repentino en los precios de la gasolina en L2 y un prepago insuficiente de gas en la nota, no se canjeará automáticamente. En este caso, el usuario debe hacerlo manualmente.

Tenga en cuenta que si el canje automático falla, deberá canjear manualmente el pagaré dentro de los 7 días, de lo contrario, la factura se eliminará (los fondos se perderán permanentemente) o deberá pagar una tarifa para renovar el contrato de arrendamiento para la preservación de la factura.

Además, aunque existe cierta similitud simétrica entre el proceso de retirada del puente oficial de Arbitrum y el comportamiento de los depósitos, no existe el concepto de Retryables, que se puede entender desde el propio protocolo Rollup por un lado, y algunas diferencias por otro:

No hay canje automático en el proceso de retiro, porque no hay temporizador ni automatización en la EVM, y el canje automático se puede realizar en L2, lo que se logra con la ayuda del secuenciador, por lo que los usuarios en L1 deben interactuar manualmente con el contrato de Bandeja de salida para recuperar activos con Claim. No hay problema de facturas vencidas por retiros, siempre que haya pasado el período de impugnación, se puede reclamar en cualquier momento.

Puerta de enlace de interacción entre cadenas de activos ERC-20

• La interacción entre cadenas de los activos ERC-20 es compleja. Hay algunas preguntas que podemos reflexionar:
• Token desplegado en L1, ¿cómo se despliega en L2?
• ¿Es necesario implementar manualmente su contraparte L2 por adelantado o el sistema puede implementar automáticamente contratos de activos para tokens que se cruzan pero aún no han implementado el contrato?
• ¿Cuál es la dirección contractual de los activos ERC-20 en L1 correspondiente a L2? ¿Debe ser coherente con L1?
• ¿Cómo la interacción entre cadenas a L1 para tokens emitidos de forma nativa en L2?
• Tokens con funciones especiales, como un número ajustable de tokens de rebase, tokens que devengan intereses de crecimiento propio, ¿cómo la interacción entre cadenas?

No vamos a responder a todas estas preguntas, porque es demasiado complicado ampliarlo. Estas preguntas solo se utilizan para ilustrar la complejidad de la interacción entre cadenas ERC20.

En la actualidad, muchas soluciones de escalado utilizan soluciones de lista de permitidos + inventario manual para evitar varios problemas complejos y situaciones límite.

Arbitrum utiliza el sistema Gateway para resolver la mayoría de los puntos débiles de la interacción entre cadenas ERC20, con las siguientes características:

• Los componentes de la puerta de enlace aparecen en pares en L1 y L2. El enrutador de puerta de enlace es responsable de mantener las asignaciones de direcciones entre Token L1<->Token L2, así como entre algunos tokens <-> algunas puertas de enlace.
• Las puertas de enlace se pueden dividir en puertas de enlace ERC20 estándar, puertas de enlace genéricas personalizadas, puertas de enlace personalizadas, etc., para resolver diferentes tipos y problemas de puente ERC20 funcionales.

Tomemos como ejemplo la relativamente simple interacción entre cadenas WETH para ilustrar la necesidad de una puerta de enlace personalizada.

WETH es un equivalente ERC20 de ETH. Como Ether es la moneda principal, muchas funciones complejas en las dApps no son posibles, por lo que se requiere un equivalente a ERC20. Transfiera algunos ETH al contrato WETH, se bloquearán en el contrato y se generará la misma cantidad de WETH.

De la misma manera, también es posible quemar WETH y sacar ETH. **Obviamente, la cantidad de WETH en circulación y la cantidad de ETH posición de bloqueo siempre será de 1:1. **

Si ahora cruzamos la interacción de cadena cruzada WETH directamente en L2, encontraremos algunos problemas extraños:

• No es posible desenvolver WETH en ETH en L2 porque no hay una posición de bloqueo correspondiente a ETH en L2.
• Se puede usar la función Wrap, pero estos WETH recién generados no se pueden desencapsular como ETH en L1 si vuelven a cruzar a L1, porque los contratos WETH en L1 y L2 no son “simétricos”.

Obviamente, esto viola los principios de diseño de WETH. **Entonces, cuando WETH es una interacción entre cadenas, ya sea un depósito o un retiro, primero debe desenvolverse en ETH y luego cruzarse al lado opuesto y luego envolverse en WETH. Aquí es donde entra en juego el WETH Gateway.

Otros tokens con una lógica más compleja hacen lo mismo, lo que requiere pasarelas más complejas y bien diseñadas para funcionar correctamente en un entorno de interacción entre cadenas. La puerta de enlace personalizada de Arbitrum hereda la lógica de interacción entre cadenas de las puertas de enlace ordinarias y permite a los desarrolladores personalizar el comportamiento de interacción entre cadenas relacionado con la lógica del token, lo que puede satisfacer la mayoría de las necesidades.

Bandeja de entrada retrasada

La contraparte de SequencerInbox es la Bandeja de entrada retrasada (Delayed Inbox). Debido a que la caja rápida está dedicada a recibir el lote de transacciones L2 publicadas 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 realiza un depósito a través de la caja lenta, y el secuenciador lo escucha y luego lo refleja en L2, y finalmente el secuenciador incluirá el registro de depósito en la secuencia de transacciones L2 y se enviará a la bandeja de entrada del secuenciador.

En este ejemplo, no es apropiado que el usuario envíe la transacción de depósito directamente a la bandeja de entrada del secuenciador, ya que la transacción enviada a la bandeja de entrada del secuenciador interferirá con el orden normal de las transacciones de la capa 2 y, a continuación, afectará al trabajo del secuenciador.

La segunda función de la caja lenta es resistir la censura. ** Las transacciones enviadas directamente por los usuarios al contrato de Slowbox serán recogidas por el secuenciador en un plazo de 10 minutos. Pero si el secuenciador ignora maliciosamente su solicitud, el slowbox también tiene una función de inclusión forzada:

Si la transacción se envía a la Bandeja de entrada retrasada, después de 24 horas, la transacción en el Slowbox no ha sido incluida en la secuencia de transacciones por el secuenciador, El usuario puede activar manualmente la función de inclusión forzada en la Capa 1, y las solicitudes de transacción ignoradas por el secuenciador se agrupan a la fuerza en la bandeja de entrada del secuenciador Fastbox, 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 mencionamos anteriormente, los datos en el fastbox son la entidad de datos históricos de L2. Por lo tanto, en el caso de censura maliciosa, ** finalmente puede incluir instrucciones de transacción en el libro mayor L2 a través de la caja lenta, que cubre escenarios como retiros forzados para escapar de la Capa 2. **

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

Varias funciones principales de la bandeja de entrada de Slowbox:

• depositETH(), la función más simple para depositar ETH.
• createRetryableTicket(), que se puede usar para depositar ETH y ERC20, así como mensajes. En comparación con depositETH(), tiene una mayor flexibilidad, como la capacidad de especificar la dirección de recepción de L2 después del depósito.
• forceInclusion(), que es la función de agregación forzada, puede ser llamada por cualquiera. Esta función verifica si una transacción enviada al contrato de Slowbox no se ha procesado después de 24 horas. Si se cumplen las condiciones, el mensaje se agregará a la fuerza.

Sin embargo, debe tenerse en cuenta que la función de inclusión de fuerza se encuentra en realidad en el contrato de Slowbox, solo para que sea más fácil de entender, la pondremos aquí en Slowbox y la explicaremos juntos.

Bandeja de salida

La bandeja de salida solo está relacionada con los retiros, que se puede entender como un sistema de registro y gestión del comportamiento de retiro:**

• Sabemos que los retiros del puente oficial de Arbitrum deben esperar al final del período de desafío de aproximadamente 7 días antes de que se pueda implementar el retiro después de que finalice el Rollup Block. Al final del período de desafío, el usuario envía la prueba de Merkle correspondiente al contrato de bandeja de salida en la capa 1, que se comunica con otros contratos funcionales (como el desbloqueo de activos bloqueados en otros contratos) y finalmente completa el retiro.
• El contrato de OutBox registrará qué mensajes de interacción entre cadenas L2 a L1 se han procesado para evitar que alguien envíe repetidamente solicitudes de retiro ejecutadas. Utiliza mapping(uint256 = > bytes32) spen público para registrar el índice gastado de la solicitud de retiro y la correspondencia entre la información, si se mapea[spentIndex] != bytes32(0), la solicitud ya ha sido retirada. El principio es similar al nonce del contador de transacciones que evita los ataques de reproducción.

A continuación, tomaremos ETH como ejemplo para explicar completamente el proceso de depósito y retiro. La diferencia entre ERC20 y ERC20 es que solo pasa por el Gateway, así que no lo repetiré.

ETH depósito

1. El usuario llama a la función depositETH() del Slowbox.

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

3. El secuenciador escucha el mensaje de depósito en el cuadro lento y refleja la operación de depósito a la base de datos L2, para que los usuarios puedan ver los activos que han depositado en la red L2.

4. El secuenciador incluirá el registro de depósito en el lote y lo enviará al contrato Express en L1.

ETH retiros

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

2. El secuenciador envía la solicitud de retiro a Quickbox.

**3.El Nodo Validador crea un nuevo Rollup Block basado en la secuencia de transacciones en el Fastbox, que contendrá las transacciones de retiro anteriores. **

4. Después de que el Rollup Block haya pasado el período de desafío y se confirme, 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 antes mencionado.

5. Después de que el contrato de la Bandeja de salida confirme que es correcto, se envía al usuario la cantidad correspondiente de ETH en el puente desbloqueado.

Pagos rápidos

** Los retiros utilizando el puente oficial de Optimistic Rollup resultarán en un período de espera para el período de desafío. Podemos eludir este problema con puentes privados de interacción entre cadenas de terceros:**

• Intercambio de cerraduras atómicas. Este método solo permite a las dos partes intercambiar activos dentro de sus respectivas cadenas, y es atómico, siempre que una de las partes proporcione una preimagen, ambas partes definitivamente obtendrán los activos que se merecen. Pero el problema es que la liquidez es relativamente escasa, y es necesario encontrar contrapartes peer-to-peer.
• Testigo del puente de interacción entre cadenas. ** El tipo general de puente de interacción entre cadenas es un puente testigo. Los usuarios envían sus propias solicitudes de retiro al operador del puente de terceros o del fondo de liquidez. Después de que el testigo descubre que la interacción entre cadenas se ha sometido al contrato de caja rápida 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 con los datos que ha comprometido con la Capa 1. **El problema es que el factor de seguridad en este modo no es tan alto como el puente Rollup oficial. **

Pagos forzados

force Inclusion() se usa para contrarrestar la censura del secuenciador y se puede usar para cualquier transacción local L2, L1 a L2 y L2 a L1. La censura maliciosa del secuenciador ha afectado seriamente a la experiencia de trading, y en la mayoría de los casos optaremos por retirarnos y abandonar L2, por lo que el siguiente es un ejemplo de retirada forzada para introducir el uso de forceInclusion.

Recuerde que en el ETH paso de retirada, 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 slowbox en L1, y el parámetro de entrada es el parámetro que debe ingresarse al llamar a withdrawEth() en L2. El mensaje se comparte con el contrato de puente en L1.
• Después de esperar el período de espera de agregación forzada de 24 horas, llame a force Inclusion() en el cuadro rápido para forzar la recopilación, y el contrato del cuadro rápido comprobará si hay un mensaje correspondiente en el puente.

El usuario final puede retirar en la Bandeja de salida, y el resto de los pasos son los mismos que los retiros normales.

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