Estructura de los componentes de Arbitrum interpretada por el ex embajador técnico de Arbitrum (Parte 2)

En el artículo anterior, “La estructura de los componentes de Arbitrum interpretada por el ex embajador técnico de Arbitrum (Parte 1)”, presentamos las funciones de los componentes clave de Arbitrum, incluido el secuenciador, el validador, el contrato de la bandeja de entrada del secuenciador, el bloque acumulativo y la función de Pruebas de fraude no interactivas. En el artículo de hoy, nos centraremos en explicar los componentes relacionados con el paso de mensajes entre cadenas y la entrada de transacciones anticensura en los componentes centrales de Arbitrum.

Texto principal: en artículos anteriores, mencionamos que el contrato Sequencer Inbox 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 “caja rápida” y, en cambio, existe la “caja lenta” o Bandeja de entrada retrasada (denominada Bandeja de entrada). A continuación, proporcionaremos una interpretación detallada de los componentes relacionados con el paso de mensajes entre cadenas, incluida la Bandeja de entrada retrasada.

El principio de cadena cruzada y puente.

Las transacciones entre cadenas se pueden dividir en transacciones de L1 a L2 (depósito) y transacciones de L2 a L1 (retiro). Es importante tener en cuenta que los términos "depósito" y "retiro" aquí no necesariamente implican la transferencia de activos entre cadenas; pueden referirse al paso de mensajes sin transferir activos directamente. Por lo tanto, estos términos simplemente representan las dos direcciones de acciones relacionadas entre cadenas.

En comparación con las transacciones L2 puras, las transacciones entre cadenas implican el intercambio de información entre dos sistemas diferentes, L1 y L2, lo que hace que el proceso sea más complejo.

Además, cuando hablamos de acciones entre cadenas, generalmente se refiere al cruce entre dos redes completamente no relacionadas utilizando un puente entre cadenas en un modelo federado. La seguridad de tales operaciones entre cadenas depende del operador del puente entre cadenas e históricamente, los incidentes de robo han sido frecuentes en puentes entre cadenas basados en testigos.

Por otro lado, las acciones entre cadenas entre Rollup y la red principal de ETH son fundamentalmente diferentes de los procesos entre cadenas antes mencionados. Esto se debe a que el estado de la Capa2 está determinado por los datos registrados en la Capa1. Siempre que utilice el puente de cadenas cruzadas Rollup oficial, es estructuralmente seguro en sus operaciones.

Esto resalta la esencia de Rollup, que, desde la perspectiva del usuario, aparece como una cadena independiente, pero en realidad, la llamada "Capa2" es solo una ventana de visualización rápida que Rollup abre a los usuarios, y su verdadera estructura en forma de cadena. todavía está grabado en Layer1. Por lo tanto, podemos considerar L2 como media cadena o "una cadena creada en la Capa1".

Reintentables

Tenga en cuenta que las transacciones entre cadenas son asincrónicas y no atómicas. A diferencia de las transacciones en una sola cadena, completar una transacción y confirmar el resultado después de una transacción en una cadena no es posible en las transacciones entre cadenas. Tampoco hay garantía de que algo específico suceda en el otro lado en un momento determinado. Por lo tanto, las transacciones entre cadenas pueden fallar debido a algunos problemas menores, pero con el uso de técnicas adecuadas, como tickets reintentables, no ocurrirán problemas difíciles como el bloqueo de fondos.

Los tickets reintentables son herramientas fundamentales utilizadas en el puente oficial de Arbitrum durante los depósitos, aplicables tanto a depósitos ETH como ERC20. El ciclo de vida consta de tres pasos:

1. Envío del ticket en L1: use 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 el boleto para el usuario sin requerir acciones manuales adicionales.
3. Canje manual en L2: en ciertos casos extremos, como un aumento repentino en los precios del gas en L2, si el gas prepago en el boleto es insuficiente, no se puede realizar el canje automático. En este escenario, es necesaria la intervención manual del usuario. Es importante tener en cuenta que si falla el canje automático, el usuario debe canjear manualmente el boleto dentro de los 7 días; de lo contrario, el boleto se eliminará (lo que resultará en una pérdida permanente de fondos) o el usuario deberá pagar una tarifa determinada para renovar el almacenamiento del boleto.

Además, en cuanto al proceso de retiro en el puente oficial de Arbitrum, aunque existe cierta similitud simétrica en el proceso respecto a los depósitos, no existe el concepto de boletos reintentables. Esto se puede entender desde la perspectiva del propio protocolo Rollup, y se pueden destacar algunas diferencias:

• No hay canje automático durante el proceso de retiro porque el EVM no tiene temporizadores ni automatización. En L2, se puede implementar el canje automático, facilitado por el secuenciador. Por lo tanto, los usuarios de L1 deben interactuar manualmente con el contrato de Bandeja de salida para reclamar sus activos.
• No hay problema de vencimiento del boleto durante los retiros. Siempre que haya pasado el período de desafío, los usuarios pueden reclamar sus activos en cualquier momento.

Puerta de enlace entre cadenas para activos ERC-20

El encadenamiento cruzado de activos ERC-20 es complejo. Podemos pensar en varias cuestiones:

• ¿Cómo implementar un token implementado en L1 en L2?
• ¿Es necesario implementar manualmente su contrato L2 correspondiente con anticipación, o puede el sistema 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 se pueden encadenar los 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 escalado utilizan soluciones de lista blanca y lista manual para evitar diversos problemas complejos y condiciones de contorno.

Arbitrum utiliza el sistema Gateway para resolver la mayoría de los problemas de adherencia 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. Además, el mapeo 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 quemar y ETH se puede retirar. Obviamente, la proporción entre WETH circulante y ETH bloqueado es siempre 1:1.

Si ahora cruzamos directamente la cadena WETH a 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. Por lo tanto, cuando WETH tiene una cadena cruzada, ya sea un depósito o un retiro, primero debe desenvolverse en ETH, luego cruzarse al otro lado y luego envolverse en WETH. Este es el papel 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

La contraparte de la bandeja de entrada rápida, conocida como Bandeja de entrada del secuenciador, es la bandeja de entrada lenta (denominada en su totalidad Bandeja de entrada retrasada). ¿Por qué diferenciar entre rápido y lento? Esto se debe a que la bandeja de entrada rápida está dedicada a recibir lotes de transacciones L2 publicadas por el secuenciador, y cualquier transacción no preprocesada por el secuenciador dentro de la red L2 no debe aparecer en el contrato de la bandeja de entrada rápida.

La primera función de la bandeja de entrada lenta es manejar el proceso de depósito de L1 a L2. Los usuarios inician depósitos a través de la bandeja de entrada lenta y, una vez que el secuenciador observa esto, refleja en L2. Finalmente, el secuenciador incluye este registro de depósito en la secuencia de transacciones L2 y lo envía al contrato de bandeja de entrada rápida (Bandeja de entrada del secuenciador).

En este escenario, no es apropiado que los usuarios envíen transacciones de depósito directamente a la bandeja de entrada rápida (Bandeja de entrada del secuenciador) porque las transacciones enviadas a la bandeja de entrada rápida pueden alterar el orden normal de las transacciones en la Capa 2, afectando así el funcionamiento del secuenciador.

La segunda función de la bandeja de entrada lenta es resistente a la censura. Las transacciones enviadas directamente al contrato de bandeja de entrada lenta generalmente se agregan a la bandeja de entrada rápida en 10 minutos mediante el secuenciador. Sin embargo, si el secuenciador ignora maliciosamente su solicitud, la bandeja de entrada lenta tiene una función de inclusión forzada:

Si una transacción se envía a la Bandeja de entrada retrasada y, después de 24 horas, el secuenciador no la incorpora a la secuencia de transacciones, los usuarios pueden activar manualmente la función de inclusión forzada en la Capa1. Esta acción obliga a que las transacciones ignoradas por el secuenciador se agreguen por la fuerza a la bandeja de entrada rápida (Bandeja de entrada del secuenciador). Posteriormente, serán detectados por todos los nodos de Arbitrum One y se incluirán forzosamente en la secuencia de transacciones de Layer2.

Acabamos de mencionar que los datos en la bandeja de entrada rápida representan la entidad de datos históricos de L2. Por lo tanto, en casos de censura maliciosa, el uso de la bandeja de entrada lenta permite que las instrucciones de transacción eventualmente se incluyan en el libro mayor L2, cubriendo escenarios como retiros forzados para escapar de la Capa 2.

A partir de esto, se puede ver que para cualquier dirección y nivel de transacciones, el secuenciador en última instancia no puede censurarlo permanentemente.

Varias funciones principales de la bandeja de entrada lenta (Bandeja de entrada):

• depositETH(): La función más simple para depositar ETH.
• createRetryableTicket(): se utiliza para depositar ETH, ERC20 y mensajes. Ofrece mayor flexibilidad en comparación con depositETH(), permitiendo especificaciones como la dirección de recepción en L2 después del depósito.
• forceInclusion(): Cualquiera puede llamar a esta función, la característica de inclusión forzada. La función verifica si una transacción enviada al contrato de bandeja de entrada lenta no se ha procesado después de 24 horas. Si se cumplen las condiciones, incluye con fuerza el mensaje.

Sin embargo, es importante tener en cuenta que la función de inclusión forzada en realidad se encuentra en el contrato de la bandeja de entrada rápida. Para facilitar la comprensión, lo explicamos junto con la bandeja de entrada lenta.

Bandeja de salida

Outbox solo está relacionado con 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 aproximadamente 7 días para que finalice el período de desafío, y el retiro solo se puede implementar después de que se finalice el Rollup Block. 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. Registra la correspondencia entre el índice de gasto y la información de la solicitud de retiro utilizando 'mapping(uint256 => bytes32) public gastado'. Si mapeo[spentIndex] != bytes32(0), la solicitud ha sido retirada. El principio es similar al contador de transacciones Nonce para prevenir 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 ETH es que el primero usa Gateway. No lo explicaremos en detalle.

Depósito ETH

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

2. Esta función seguirá llamando a 'bridge.enqueueDelayedMessage()', Registre el mensaje en el contrato puente y envíe ETH al contrato puente. Todos los fondos de depósito de ETH se guardan en el contrato puente, que equivale a una dirección de depósito.

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

4. El secuenciador incluye el registro de depósito 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 y el número correspondiente de ET se quema 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á las transacciones de retiro anteriores.

4. Después de que el bloque acumulativo pasa por el período de desafío que también se confirma, 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 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.

Retiro rápido de efectivo

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

• Intercambio de cerraduras atómicas. Este método sólo 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 con un método peer-to-peer.F
• Los testigos cruzan el puente de las cadenas. 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 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 nivel de seguridad en este modo no es tan alto como el del puente Rollup oficial. \

Retiro forzado

La función force Inclusion() se utiliza para resistir la censura 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 censura maliciosa del secuenciador afecta gravemente la experiencia de la transacción. En la mayoría de los casos, optaremos por retirar dinero y dejar L2. Por lo tanto, a continuación se utiliza el retiro forzado como ejemplo para presentar el uso de forceInclusion.

Volviendo a los pasos de retiro de ETH, solo los pasos 1 y 2 implican censura del secuenciador, por lo que solo es necesario cambiar estos dos pasos:

• Al llamar 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 un período de espera de inclusión forzada de 24 horas, se llama a la inclusión forzada () en el cuadro rápido para realizar la inclusión forzada. El contrato de caja rápida comprobará si hay un mensaje correspondiente en el puente.

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

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

Descargo de responsabilidad:

1. Este artículo se reimprime de [极客 Web3]. Todos los derechos de autor pertenecen al autor original [极客 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 están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.