Texto principal: En artículos anteriores, mencionamos que el contrato de la bandeja de entrada del secuenciador está diseñado específicamente para recibir lotes de datos 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 la "caja rápida", y la contraparte es la bandeja de entrada retrasada (conocida como bandeja de entrada). A continuación, proporcionaremos una explicación detallada de los componentes relacionados con la transmisión de mensajes entre cadenas, como la bandeja de entrada retrasada.

El principio de la cadena cruzada y el puente

Las transacciones entre cadenas se pueden dividir en L1 a L2 (depósito) y L2 a L1 (retiro). Tenga en cuenta que el depósito y el retiro mencionados aquí no están necesariamente relacionados con activos entre cadenas, sino que pueden ser mensajes que no incluyen directamente activos. Por lo tanto, estas dos palabras solo representan dos direcciones de comportamientos relacionados con la cadena cruzada.

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 solemos llamar comportamiento entre cadenas es la cadena cruzada en dos redes no relacionadas utilizando un puente entre cadenas en modo testigo. La seguridad de esta cadena cruzada depende del puente de cadena cruzada. Históricamente, los puentes entre cadenas basados en un modo testigo han experimentado con frecuencia incidentes de robo.

Por el contrario, el comportamiento entre cadenas entre Rollup y la red principal de Ethereum es fundamentalmente diferente de las operaciones entre cadenas antes mencionadas. Esto se debe a que el estado de la Capa 2 está determinado por los datos registrados en la Capa 1. Siempre que utilice el puente de cadena cruzada oficial de Rollup, su estructura operativa es absolutamente segura.

Esto también resalta la esencia de Rollup, que, desde la perspectiva del usuario, aparece como una cadena independiente. Sin embargo, en realidad, la llamada "Capa 2" es solo una ventana de visualización rápida abierta por Rollup a los usuarios, y su verdadera estructura en forma de cadena todavía se registra en la Capa 1. Por lo tanto, podemos considerar L2 como la mitad de una cadena, o como una "cadena creada en la Capa 1".

Reintentables

Es importante tener en cuenta que las operaciones entre cadenas son asincrónicas y no atómicas. A diferencia de una sola cadena en la que se conoce el resultado de una transacción una vez que se confirma, las transacciones entre cadenas no pueden garantizar que ciertos eventos ocurran en el otro lado en un momento específico. Por lo tanto, las transacciones entre cadenas pueden fallar debido a problemas blandos, pero con los métodos correctos, como los tickets reintentables, no habrá ningún problema como que los fondos se atasquen.

Los tickets reintentables son herramientas básicas que se utilizan al depositar fondos a través del puente oficial de Arbitrum para tokens ETH y ERC20. Su ciclo de vida consta de tres pasos:

1. Envío del ticket en L1: cree un ticket de depósito con el método createRetryableTicket() en el contrato Bandeja de entrada retrasada y envíelo.

2. Canje automático en L2: En la mayoría de los casos, el secuenciador puede canjear automáticamente el ticket para el usuario sin más intervención manual.

3. Canje manual en L2: En ciertos casos extremos, como un aumento repentino en los precios de la gasolina en L2 donde la gasolina prepagada en el boleto es insuficiente, el canje automático puede fallar. En tales casos, se requiere la intervención manual del usuario. Tenga en cuenta que si falla el canje automático, el boleto debe canjearse manualmente dentro de los 7 días; De lo contrario, el boleto puede ser eliminado (lo que resulta en la pérdida permanente de fondos) o requerir el pago de una tarifa para renovar su arrendamiento.

Además, en el proceso de retiro del puente oficial de Arbitrum, aunque existe cierta similitud simétrica con el comportamiento del depósito en cuanto al proceso, no existe el concepto de Retryables. Esto se puede entender tanto desde la perspectiva del propio protocolo Rollup como examinando algunas diferencias:

• No hay canje automático durante el retiro porque la EVM no tiene temporizadores ni automatización. Si bien el canje automático se puede implementar en L2 con la ayuda del secuenciador, los usuarios en L1 deben interactuar manualmente con el contrato de la Bandeja de salida para reclamar sus activos.

• Tampoco hay problemas de caducidad del billete durante la retirada; Siempre que haya pasado el período de impugnación, los activos se pueden reclamar en cualquier momento.

ERC-20 Puerta de enlace de cadena cruzada de activos

Las transacciones entre cadenas que involucran activos ERC-20 son complejas. Podemos plantearnos varias preguntas:

• ¿Cómo se implementa un token en L2 si se implementa en L1?
• ¿Su contrato correspondiente en L2 debe implementarse manualmente por adelantado o el sistema puede implementar automáticamente contratos de activos para tokens que se han transferido pero que aún no se han implementado?
• ¿Cuál es la dirección contractual de un activo ERC-20 en L2 correspondiente a su dirección en L1? ¿Debería coincidir con la dirección de L1?
• ¿Cómo se encadenan los tokens emitidos de forma nativa en L2 a L1?
• ¿Cómo se cruzan los tokens con funcionalidades especiales, como los tokens Rebase de suministro ajustable o los tokens de staking automático?

No tenemos la intención de responder a todas estas preguntas, ya que son demasiado complejas para abordarlas de manera integral. Estas preguntas simplemente pretenden ilustrar la complejidad de las transacciones entre cadenas ERC-20.

Actualmente, muchas soluciones de escalado utilizan soluciones de lista blanca + lista manual para evitar varios problemas complejos y condiciones de contorno.

Arbitrum emplea un sistema de puerta de enlace para abordar la mayoría de los puntos débiles de las transacciones entre cadenas ERC20, con las siguientes características:

• Los componentes de la puerta de enlace aparecen en pares tanto en L1 como en L2.
• El enrutador de puerta de enlace es responsable de mantener las asignaciones de direcciones entre el token L1 <-> el token L2 y algunos tokens <-> alguna puerta de enlace.
• La puerta de enlace en sí se puede dividir en varios tipos, como la puerta de enlace ERC20 estándar, la puerta de enlace genérica-personalizada, la puerta de enlace personalizada, etc., para abordar los problemas de puente para diferentes tipos y funcionalidades de tokens ERC20.

Para ilustrar la necesidad de puertas de enlace personalizadas, consideremos un ejemplo relativamente simple de transferencia WETH entre cadenas.

WETH es un equivalente ERC20 de ETH. Dado que Ether sirve como moneda principal, muchas funcionalidades complejas en dApps son imposibles de lograr directamente. Por lo tanto, se necesita un equivalente ERC20 como WETH. Al depositar algo de ETH en el contrato WETH, se bloquean dentro del contrato, generando una cantidad equivalente de WETH.

Del mismo modo, WETH se puede quemar para retirar ETH. Claramente, la cantidad circulante de WETH y la cantidad bloqueada de ETH siempre mantendrán una proporción de 1:1.

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

• Es imposible desenvolver WETH en ETH en L2 porque no hay ETH correspondiente para bloquear en L2.
• Se puede usar la función Wrap, pero si estos WETH recién generados se cruzan de nuevo a L1, no se pueden desenvolver en ETH en L1 porque los contratos WETH en L1 y L2 no son "simétricos"。

Claramente, esto viola los principios de diseño de WETH. Por lo tanto, al cruzar la cadena cruzada de WETH, ya sea depositando o retirando, es necesario desenvolverlo primero en ETH, luego cruzarlo y volver a envolverlo en WETH. Aquí es donde entra en juego el WETH Gateway.

Del mismo modo, para otros tokens con lógicas más complejas, requieren puertas de enlace más sofisticadas y cuidadosamente diseñadas para funcionar correctamente en un entorno de cadena cruzada. La puerta de enlace personalizada de Arbitrum hereda la lógica de comunicación entre cadenas de una puerta de enlace estándar y permite a los desarrolladores personalizar los comportamientos entre cadenas relacionados con las lógicas de tokens, satisfaciendo la mayoría de los requisitos.

Bandeja de entrada retrasada

La contraparte de la bandeja de entrada del secuenciador, también conocida como la caja rápida, es la bandeja de entrada (oficialmente llamada bandeja de entrada retrasada). ¿Por qué hace una distinción entre cajas rápidas y retardadas? Debido a que la caja rápida está diseñada específicamente para recibir lotes de transacciones L2 publicadas por el secuenciador, y cualquier transacción no procesada previamente por el secuenciador dentro de la red L2 no debe aparecer en el contrato de caja rápida.

La primera función de la caja lenta es manejar el comportamiento del depósito de L1 a L2. Los usuarios inician los depósitos a través de la caja lenta, que luego el secuenciador refleja en L2. Eventualmente, este registro de depósito será incluido en la secuencia de transacciones L2 por el secuenciador y enviado al contrato de caja rápida, el SequencerInbox.

En este escenario, no es adecuado que los usuarios envíen directamente transacciones de depósito a la caja rápida porque las transacciones enviadas a SequencerInbox interferirían con la secuencia normal de transacciones de la capa 2, lo que afectaría al funcionamiento del secuenciador.

La segunda función de la caja retardada es la resistencia a la censura. Las transacciones enviadas directamente al contrato de caja retrasada suelen ser agregadas a la caja rápida en un plazo de 10 minutos por el secuenciador. Sin embargo, si el secuenciador ignora maliciosamente su solicitud, el cuadro retrasado tiene una función de inclusión forzada:

Si una transacción se envía a la bandeja de entrada retrasada y el secuenciador permanece sin agregar a la secuencia de transacciones después de 24 horas, los usuarios pueden activar manualmente la función de inclusión forzada en la capa 1. Esta acción obliga a que las solicitudes de transacción ignoradas por el secuenciador se agreguen a la caja rápida, la bandeja de entrada del secuenciador, y posteriormente sean detectadas por todos los nodos de Arbitrum One, por lo que se incluyen a la fuerza en la secuencia de transacciones de capa 2.

Como mencionamos anteriormente, los datos en el cuadro rápido representan la entidad de datos históricos de L2. Por lo tanto, en casos de censura maliciosa, las transacciones se pueden incluir en última instancia en el libro mayor L2 mediante el uso de la caja retrasada, cubriendo escenarios como retiros forzados de la capa 2.

A partir de esto, se puede ver que, en última instancia, el secuenciador no puede censurar permanentemente las transacciones en ninguna dirección o capa.

Varias funciones principales de la bandeja de entrada de cuadro lento son las siguientes:

• depositETH(): Esta función es el método más simple para depositar ETH.
• createRetryableTicket(): Esta función se puede utilizar para depositar ETH, tokens ERC20 y mensajes. En comparación con depositETH(), ofrece una mayor flexibilidad, como especificar la dirección de recepción en L2 después del depósito.
• forceInclusion(): También conocida como función de inclusión de fuerza, que puede ser llamada por cualquiera. Esta función verifica si una transacción enviada al contrato de caja lenta no se ha procesado después de 24 horas. Si se cumple la condición, la función agrega el mensaje de forma forzada.

Sin embargo, es importante tener en cuenta que la función forceInclusion() en realidad reside en el contrato de caja rápida. Para mayor claridad, lo discutimos aquí junto con las funciones de caja lenta.

Buzón

Outbox solo se relaciona con los retiros y puede entenderse como un sistema de registro y gestión de comportamientos de retiro:

• Sabemos que los retiros en el puente oficial de Arbitrum deben esperar unos 7 días para que finalice el período de desafío, y el retiro solo se puede implementar después de que finalice el Rollup Block. Una vez finalizado el período de impugnación, el usuario envía la prueba de Merkle correspondiente al contrato de la bandeja de salida en la capa 1, que luego se comunica con los contratos para otras funciones (como el desbloqueo de activos bloqueados en otros contratos) y, finalmente, completa el retiro.
• El contrato de la Bandeja de salida registra qué mensajes de cadena cruzada de L2 a L1 se han procesado para evitar que alguien envíe repetidamente solicitudes de retiro ejecutadas. Esto lo logra a través de un mapeo llamado gastado, que asocia los índices gastados de las solicitudes de retiro con su información correspondiente. Si mapping[spentIndex] != bytes32(0), indica que la solicitud ya se ha retirado. El principio es similar al de un contador de transacciones nonce, que se utiliza para evitar ataques de reproducción.

A continuación, explicaremos el proceso de depósito y retiro utilizando ETH como ejemplo. El proceso para los tokens ERC20 es similar, con la adición de una puerta de enlace, pero no lo explicaremos aquí.

Depósito de ETH

1. El usuario llama a la función depositETH() de la bandeja de entrada retrasada.
2. A continuación, esta función llama a bridge.enqueueDelayedMessage(), que registra el mensaje en el contrato puente y envía el ETH al contrato puente. Todos los fondos de ETH depositados se mantienen en el contrato puente, actuando como una dirección de depósito.
3. El secuenciador supervisa el mensaje de depósito en la bandeja de entrada retrasada y refleja la operación de depósito en la base de datos L2. Los usuarios pueden ver sus activos depositados en la red L2.
4. El secuenciador incluye el registro de depósito en un lote de transacciones y lo envía al contrato de bandeja de entrada rápida en L1.

Retiro de ETH

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

2. El secuenciador envía la solicitud de retiro a la caja rápida.

3. El nodo Validador crea un nuevo bloque acumulativo basado en la secuencia de transacciones en el cuadro rápido, que contendrá las transacciones de retiro anteriores.

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

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

Retiros rápidos

Usar el puente oficial optimista de Rollup implica esperar un período de desafío. Para evitar este problema, podemos utilizar un puente de cadena cruzada privado de terceros:

• Atomic Swap Exchange: En este enfoque, los activos se intercambian entre las partes dentro de sus respectivas cadenas, y es atómico, lo que significa que si una de las partes proporciona la preimagen, ambas partes pueden obtener los activos correspondientes. Sin embargo, la liquidez es relativamente escasa, lo que requiere la búsqueda de contrapartes entre pares.
• Puente de cadena cruzada basado en testigos: La mayoría de los tipos de puentes de cadena cruzada entran en esta categoría. Los usuarios envían sus solicitudes de retiro, especificando el destino como el operador o el grupo de liquidez del puente de terceros. Una vez que el testigo descubre que la transacción entre cadenas se ha enviado al contrato de bandeja de entrada rápida en L1, puede transferir fondos directamente al usuario en L1. Esencialmente, este método utiliza otro sistema de consenso para monitorear la Capa 2 y realizar operaciones basadas en los datos enviados a la Capa 1. Sin embargo, el nivel de seguridad en este modo es menor en comparación con el puente oficial de Rollup.

Forzar retirada

La función forceInclusion() se utiliza para contrarrestar la censura del secuenciador. Se puede aplicar a cualquier transacción local de L2, transacciones de L1 a L2 y transacciones de L2 a L1. Dado que la censura maliciosa del secuenciador afecta significativamente a la experiencia de la transacción, a menudo optamos por retirarnos de L2. A continuación se muestra un ejemplo del uso de forceInclusion() para forzar retiros:

En el contexto de los retiros de ETH, solo los pasos 1 y 2 implican la censura del secuenciador. Por lo tanto, solo necesitamos modificar estos dos pasos:

• Llame a inbox.sendL2Message() en el contrato de bandeja de entrada retrasada en L1, con los parámetros necesarios al llamar a withdrawEth() en L2. Este mensaje se comparte con el contrato de puente en L1.
• Después de esperar el período de espera de inclusión forzada de 24 horas, llame a forceInclusion() en el contrato de bandeja de entrada rápida para forzar la inclusión. El contrato de bandeja de entrada rápida comprobará si hay un mensaje correspondiente en el puente.

Finalmente, los usuarios pueden retirar de la bandeja de salida, y los pasos restantes son los mismos que en un proceso de retiro normal.

Además, hay tutoriales detallados en el repositorio arbitrum-tutorials que guían a los usuarios sobre cómo realizar transacciones locales de L2 y transacciones de L2 a L1 usando forceInclusion() a través del SDK de Arb.

Renuncia:

1. Este artículo es una reimpresión de [Geek Web3], Todos los derechos de autor pertenecen al autor original [Luo Benben, ex embajador técnico de Arbitrum, colaborador de geek web3]]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.