¿Qué importancia tienen las retiradas forzadas y las funciones de la cápsula de escape para la capa 2?

Autor: Faust, Geek Web3

En el mundo real, casi todos los edificios altos tienen un ingrediente indispensable: una salida de seguridad. Cuando ocurren emergencias como incendios y terremotos, las salidas de seguridad son un salvavidas para garantizar la seguridad de la vida de las personas. En el sistema de plataforma de custodia de la capa 2 de Ethereum, que transporta decenas de miles de millones de dólares en activos, la función de “retiro forzoso”, que permite a los usuarios retirar activos de forma segura a la capa 1, se ha convertido en una instalación indispensable y necesaria.

En su reciente artículo “Diferentes tipos de capa 2”, Vitalik también enfatizó que la capacidad de los usuarios para retirar activos sin problemas de la capa 2 a la capa 1 es un indicador de seguridad muy importante.

Sin embargo, el tema de la “retirada suave” no parece haber recibido mucha atención por parte de la mayoría de la gente en el pasado, e incluso muchos proyectos de Capa 2 no han lanzado la función de “retirada forzada” o “cápsula de escape”. En la era en la que el ecosistema L2 no está en pleno apogeo, ignorar los “retiros sin permiso” no parece ser un problema. Pero ahora que Layer 2 tiene más de 12.000 millones de dólares en activos, se ha convertido en un edificio “demasiado grande para quebrar”. Si un rascacielos de este tipo no tiene una salida de seguridad, las consecuencias son simplemente inimaginables.

Con el propósito de hacer que los lectores presten atención a los riesgos de seguridad de la Capa 2, “Geek Web3” tomará el Protocolo Loopring V3 y Arbitrum como ejemplos a continuación para explicar por qué las “funciones de retiro sin permiso”, como el desenfundado forzado y la escotilla de escape, son una parte indispensable de la Capa 2.

(De acuerdo con el navegador L2BEAT dYdX, la función de transacción/retiro forzado dYdX se ha utilizado 152 veces hasta ahora, y ha habido 7 retiros grandes de más de $ 1 millón).

La resistencia a la censura es el gran problema: qué hacer si el secuenciador rechaza deliberadamente su solicitud****

En el pasado, los artículos de divulgación científica sobre la Capa 2 a menudo tenían un problema, es decir, la mayoría de las veces se centraban en la “seguridad” y la “usabilidad” en la superficie, pero ignoraban la “resistencia a la censura”. Incluso cuando se habla de soluciones de secuenciadores descentralizados, muchas personas prestan atención a si MEV está descentralizado, no a la resistencia a la censura.

En otras palabras, la mayoría de las personas tienden a centrarse en si las transiciones de estado de la Capa 2 son válidas, si el secuenciador puede robar monedas y si el sistema de prueba de validez de fraude/validez está en uso, pero ignoran un riesgo que no debe pasarse por alto: ¿qué pasa si el secuenciador sigue rechazando sus solicitudes de transacción, o simplemente falla durante mucho tiempo, o incluso se cae? **

Ya sabes, durante la interrupción de Solana, hubo personas que no pudieron cubrir sus posiciones a tiempo porque sus activos se enfrentaban a la liquidación, lo que puso en riesgo millones de dólares en activos. **Una vez que se produce dicho rechazo de la solicitud del usuario, la pérdida económica ocasionada no es despreciable.

Incluso si solo unas pocas personas pudieran estar en esta situación, si cayera sobre alguna ballena con mucho dinero, todo el mercado podría sufrir (digamos que alguien tiene cientos de millones de dólares en activos en un protocolo de préstamos Defi en Ethereum que podrían liquidarse en una semana, pero está en la lista de sanciones de la OFAC por usar Tornado). La mayoría de los fondos de esta persona están en el OP, y el secuenciador del OP trabaja con la OFAC para rechazar su solicitud)

También podríamos proyectar este problema en cadenas públicas como avalanche o polygon, que son independientes de Ethereum. Si más de 2/3 de los nodos de consenso del validador en Avalanche deciden censurar sus transacciones, pueden negarse a incluir su Txn en un bloque o no reconocer el bloque que contiene su Txn. En este momento, tu dinero está básicamente enterrado en esta cadena y no puede salir:**

A menos que puedas cooptar a algunos validadores para que menos de 2/3 de los validadores estén involucrados en el ataque de censura, o puedas llamar a algunas personas para bifurcar Avalanche a través del consenso social. Obviamente, en este punto, todavía tiene una forma de retirar fondos rápidamente de Avalanche, y tenemos que considerar que más de 2/3 de los Validadores unen fuerzas para iniciar una revisión de transacciones de una determinada dirección, lo que en sí mismo lleva un tiempo lograr, lo que dejará tiempo suficiente para que los usuarios censurados “escapen”.

Pero en la capa 2, la situación puede ser muy diferente. Layer 2 Sequencer generalmente está dirigido por el propio funcionario, y si Sequencer quiere lanzar un ataque de censura contra usted, puede “congelar su dinero en Layer 2”, es decir, rechazar por completo su solicitud de transacción para cruzar activos de L2 a L1. Obviamente, de acuerdo con el mecanismo de operación de L2, si no puede omitir el secuenciador para realizar una operación de retiro, es muy posible que el secuenciador congele los activos en L2 y no se pueda transferir.

Entonces, ¿cómo resolver este tipo de problema? De hecho, para decirlo sin rodeos, ¿cómo implementar la función de retiro “sin permiso”, de modo que los usuarios puedan retirar sus activos a la Capa 1 sin ningún daño cuando sean revisados por el Secuenciador o las partes del proyecto de la Capa 2? Hay algunos proyectos que han propuesto un secuenciador descentralizado, pero esta no es una solución paliativa, y si un número muy limitado de secuenciadores unen fuerzas para revisarlo, aún puede “congelar” sus activos, y la anti-bruja de los nodos POS también es un problema complicado (ver Eventos multicadena).

La forma más efectiva de hacer esto es configurar una “salida” directamente en la cadena L1, lo que permite a los usuarios retirar fondos de L2 a través de una salida dedicada en L1 si no obtienen una respuesta de Sequencer durante mucho tiempo. **

Modelo de Liquidación Forzosa y Liquidación por Quiebra de Loopring Protocol V3

Aquí tomamos como ejemplo la versión V3 del protocolo Loopring, que enumera dos escenarios diferentes para retiros forzados iniciados por el usuario, el primer caso es:

Los usuarios pueden iniciar un retiro forzado directamente en la capa 1 a través de la función forcedWithdraw en el contrato ExchangeV3 y declarar qué cuenta L2 tienen en el protocolo Loopring y qué tipo de token desean retirar. Después de eso, el contrato ExchangeV3 lanza un evento en cadena para indicar que alguien ha iniciado una solicitud de retiro forzado. Dado que todos los nodos del protocolo Loopring (incluido Sequencer) ejecutan clientes Geth, se sabe por el bloque de Ethereum que alguien inició un retiro forzado y desencadenó el evento on-chain correspondiente.

Es importante tener en cuenta que los retiros forzados no se procesan inmediatamente, sino que se colocan en la cola pendingForcedWithdrawals y están pendientes. ** El secuenciador notó que después de que alguien inicia un retiro forzado en la Capa 1, la función Proceso en el contrato ExchangeV3 se activa dentro de los 15 días para transferir el token al iniciador del retiro en la cadena Ethereum (desde la dirección de depósito de la parte del proyecto L2 en la cadena Ethereum para transferir dinero al retirado).

Si Sequencer no responde a la solicitud de retirada forzada del usuario en un plazo de 15 días, el usuario puede llamar a la función notifyForcedRequestTooOld para que el contrato de ExchangeV3 produzca un evento denominado WithdrawalModeActivated para notificar al nodo completo del protocolo Loopring que el modo de liquidación por quiebra está activado. **

**Si se activa el modo de liquidación, Loopring V3 dejará de recibir nuevos bloques L2 enviados por Sequencer, lo que significa que todo el protocolo Loopring dejará de funcionar. Este proceso dura al menos 30 días.

Sin embargo, en el modo de liquidación por bancarrota, los usuarios aún pueden retirar sus activos en la Capa 1, pero deben presentar una prueba de merkle para demostrar su estado/estado de activos, que se puede verificar en el árbol de estado L2. (Demostrar que el saldo de sus activos en la Capa 2 es consistente con la cantidad que declaró cuando inició el retiro)

Este modelo de liquidación por bancarrota del Protocolo Loopring también se conoce como el mecanismo Escape Hatch en L2BEAT. Este modo se activa como requisito previo para que el secuenciador no responda a la solicitud de retiro forzado del usuario dentro del tiempo especificado, o si el secuenciador tiene una falla o tiempo de inactividad a largo plazo. En este momento, el usuario puede activar manualmente el contrato Rollup en modo de congelación o detener la ejecución. A continuación, los usuarios pueden construir pruebas de merkle para demostrar sus activos en la capa 2 y retirar sus propios activos de la dirección de depósito de la parte del proyecto L2 en la capa 1. **

En la documentación de StarkEx, también se dibuja un diagrama esquemático dedicado a este proceso. Si el usuario de L2 no recibe una respuesta del secuenciador al final de la ventana de 7 días cuando el usuario de L2 envía una solicitud de retiro forzado en L1, el usuario de L2 puede llamar a la función de solicitud de congelación para hacer que la L2 entre en el período de congelación. En este caso, el secuenciador L2 no podrá actualizar el estado de L2 en L1 y tardará 1 año después de que se congele el estado L2. Después de eso, los usuarios pueden enviar una prueba de Merkle y retirar dinero.

Sin embargo, para construir Merkle Proof, primero debe conocer el árbol de estado L2 completo, es decir, debe encontrar un nodo completo L2 para solicitar datos y, al mismo tiempo, necesita un fragmento de código para generar Merkle Proof, lo que obviamente requiere un cierto umbral técnico. Para la comodidad de la mayoría de los usuarios, L2BEAT ha declarado anteriormente que la Capa 2 debe configurar una serie de nodos completos con permisos abiertos y código fuente abierto para ayudar a los usuarios a conocer el estado de todas las cuentas en L2 (incluido el saldo, el número de transacciones, etc.). Esta medida también ilustra la importancia de los retiros obligatorios y los mecanismos de cápsulas de escape.

Función “Transacciones de inclusión forzada” de Arbitrum

Pero los retiros forzados y las cápsulas de escape no parecen ser la única solución resistente a la censura. Por ejemplo, Arbitrum utiliza el método de “forzar la inclusión de transacciones”, el usuario puede enviar primero el Txn/retiro que necesita ser procesado por el secuenciador en el contrato de bandeja de entrada retrasado en L1, y si el secuenciador no lo ha procesado durante más de 24 horas, el usuario puede llamar a la función de inclusión forzada del contrato de bandeja de entrada del secuenciador en L1. Deje que Txn se incluya directamente en la secuencia de transacciones de Arbitrum** (lance un evento on-chain para informar a los nodos completos de Arbitrum que Txn con algunos registros de bandeja de entrada retrasados deben incluirse en el libro mayor L2).

Por el contrario, el enfoque de Arbitrum es más simple, pero todavía es un poco deficiente: solo lanza un evento en la cadena que le dice al nodo de Arbitrum que hay algunas transacciones que el secuenciador ignora que deben incluirse en la cadena más larga de L2, en lugar de permitir a los usuarios retirar dinero directamente en L1 como lo hacen Loopring Protocol y el modo de bancarrota / cápsula de escape de StarkEx. Si los nodos retadores de Arbitrum se unen para lanzar un ataque de censura, parece que aún sería posible congelar el dinero de los usuarios en L2. **

Por lo tanto, la inclusión forzada de Arbitrum no es lo suficientemente sin permisos, y aunque sería bueno decir que el secuenciador ignoró la solicitud forceInclusion de un usuario siempre que hubiera un nodo honesto dispuesto a publicar una prueba de fraude, esto aún introduce un cierto grado de suposición de confianza, aunque en menor medida.

Más precisamente, las “transacciones que deben incluirse obligatoriamente” deben ser reconocidas por al menos un nodo retador de ARB, que actualmente tiene 9 nodos que tienen derecho a decidir qué mensajes de cadena cruzada L2-L1 permitir, y ahora solo ellos pueden emitir pruebas de fraude. ** Mientras estos 9 nodos se confabulen, teóricamente la “transacción forzada” del usuario aún puede ser invalidada. **

Por lo tanto, la inclusión obligatoria actual de transacciones/retiros en Arbitrum no es como el modelo de liquidación por bancarrota de Loopring y StarkEx que no requiere el permiso del nodo L2. Sin embargo, L2BEAT aún le dio a Arbitrum una alta calificación por esta solución. Porque en el futuro, Arbitrum lanzará un mecanismo de liberación a prueba de fraude sin permiso llamado BOLD, y será difícil o imposible que los nodos retadores se confabulen en ese momento (en realidad es difícil coludirse ahora).

Según L2BEAT, el TVL actual supera los 50 millones de dólares, y no hay respuesta a ninguno de los fallos del secuenciador o del proponente: **OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM, Metis. Estas L2 pueden hacer que los activos de usuario se congelen en L2 en casos extremos. **

Así que obviamente, el modelo de retirada forzosa o liquidación por quiebra tiene su necesidad, aunque por el momento solo se basa en el usuario-secuenciador como juego de contraparte para funcionar, ** no está realmente “listo para retirarse” ** (Arbitrum tiene un retraso de 24 horas y puede fallar, Loopring tiene un retraso máximo de 15 días, StarkEx tiene un retraso máximo de 7 días), pero está claro que “algo es mejor que nada”. Además, se cree que el problema de los retrasos en los retiros forzosos se resolverá adecuadamente en el futuro con un diseño de mecanismos más sofisticados** (en la actualidad, se debe principalmente al hecho de que algunos científicos de MEV pueden usar forceInclusion para iniciar transacciones anticipadas, por lo que es necesario introducir retrasos). Para obtener más detalles, consulte los documentos oficiales de las principales partes del proyecto L2).

Con la inclusión de Sequencer descentralizado en más y más hojas de ruta L2, y la Fundación Ethereum dirigida por Vitalik continúa educando a las personas sobre la seguridad de la Capa 2, las características de las transacciones resistentes a la censura, como los retiros forzosos, seguramente recibirán cada vez más atención, lo que hará que el sistema de la Capa 2 de Ethereum se acerque más a un sistema de infraestructura financiera resistente a la censura y sin confianza. Si la capa 2 implementa el acceso sin confianza a los fondos, se cree que más creadores de mercado y proveedores de liquidez entrarán en la infraestructura L2, y la adopción masiva de toda la web3 se impulsará un paso más.