En el mundo real, casi todos los rascacielos tienen un elemento indispensable: una salida de emergencia. Cuando ocurren eventos imprevistos como incendios o terremotos, estas salidas son salvavidas para la seguridad de las personas. De manera similar, en el ecosistema de Capa 2 de Ethereum, que alberga miles de millones de dólares en activos, la función de "retiro forzado" que permite a los usuarios devolver los activos de forma segura a la Capa 1 se ha convertido en una instalación esencial.

Vitalik también enfatizó en su reciente artículo "Diferentes Tipos de Capa 2" que la capacidad para que los usuarios retiren activos de manera fluida de la Capa 2 de regreso a la Capa 1 es un indicador de seguridad muy importante.

Sin embargo, el tema de las "retiradas sin problemas" parece haber sido pasado por alto por la mayoría en el pasado, y muchos equipos de proyectos de Capa 2 no han implementado funciones de "retirada forzosa" o "puerta de escape". En la era en la que el ecosistema de la Capa 2 aún no estaba maduro, ignorar las "retiradas sin permiso" parecía no ser un problema. Pero ahora, con la Capa 2 manejando más de 12 mil millones de dólares en activos, se ha convertido en un rascacielos "demasiado grande para fallar". La ausencia de una salida de emergencia en un edificio tan imponente es inimaginable.

Con la intención de concienciar a los lectores sobre los riesgos de seguridad de Capa 2, “Geek Web3” utilizará el Protocolo Loopring V3 y Arbitrum como ejemplos en el siguiente texto para explicar por qué las “funciones de retiro sin permiso” como el retiro forzado y la puerta de escape son componentes indispensables de la Capa 2.

(Según el navegador L2BEAT de dYdX, hasta ahora, la función de trading/retiro forzado de dYdX se ha utilizado un total de 152 veces, con retiros grandes que superan el millón de dólares en 7 casos) La resistencia a la censura es un gran problema: ¿Qué pasa si el Secuenciador rechaza deliberadamente tu solicitud?

Artículos populares pasados sobre Capa 2 a menudo tenían un problema: mayormente enfatizaban la “seguridad” y la “usabilidad” superficial pero pasaban por alto la “resistencia a la censura”. Incluso al discutir soluciones de secuenciador descentralizado, lo que muchos notaron fue si MEV es descentralizado, en lugar de mejoras en la resistencia a la censura.

En otras palabras, la mayoría de las personas tienden a centrarse en si las transiciones de estado en Capa 2 son efectivas, si los secuenciadores pueden robar monedas y si se emplean sistemas de pruebas de fraude/pruebas de validez. Sin embargo, ignoran un riesgo que no debería pasarse por alto: ¿Qué pasa si el Secuenciador rechaza continuamente sus solicitudes de transacción, o simplemente no funciona correctamente durante un período prolongado, o incluso se apaga?

Vale la pena señalar que durante la caída de Solana, hubo casos en los que las personas no pudieron añadir colaterales a tiempo debido a los riesgos de liquidación de activos, lo que llevó a millones de dólares en activos en riesgo. Escenarios como negar las solicitudes de los usuarios pueden provocar pérdidas económicas significativas.

Incluso si solo unos pocos individuos pueden encontrarse con tales situaciones, si le sucede a algunos 'ballenas' que tienen grandes cantidades de fondos, todo el mercado podría verse afectado. Por ejemplo, supongamos que alguien con cientos de millones de dólares en activos en un protocolo de préstamos DeFi en Ethereum enfrenta una liquidación dentro de una semana pero es sancionado por OFAC debido al uso de Tornado. La mayor parte de sus fondos están en Optimism (OP), y el OP Sequencer, cumpliendo con OFAC, rechaza sus solicitudes.

Proyectemos este problema en blockchains independientes como Avalanche o Polygon, separados de Ethereum. Si más de dos tercios de los nodos de consenso de Validadores en Avalanche deciden llevar a cabo un escrutinio de transacciones en tu contra, pueden negarse a incluir tus transacciones en un bloque o denegar el reconocimiento de un bloque que contenga tus transacciones. En este caso, tus fondos quedan esencialmente enterrados en esta cadena y no se pueden retirar:

A menos que puedas persuadir a algunos Validadores para que menos de dos tercios estén involucrados en el ataque de escrutinio, o puedas reunir personas para bifurcar Avalanche a través de consenso social. Claramente, en este momento, todavía tienes formas de retirar rápidamente tus fondos de Avalanche. Sin embargo, debemos considerar que lleva tiempo que más de dos tercios de los Validadores se unan e inicien un escrutinio de transacciones contra una dirección específica, lo que proporciona al usuario escrutinizado tiempo suficiente para 'escapar'.

Pero la situación podría ser bastante diferente en Capa 2. Los secuenciadores en Capa 2 generalmente son administrados por el equipo oficial. Si un Secuenciador quiere lanzar un ataque de escrutinio contra ti, puede 'congelar tu dinero en Capa 2', negando efectivamente tus solicitudes de transferir activos de L2 a L1. Según el mecanismo operativo de L2, si no puedes evitar al Secuenciador para ejecutar un retiro, es totalmente posible que el Secuenciador congele tus activos en L2, impidiendo su transferencia.

Entonces, ¿cómo se puede resolver este problema? En pocas palabras, ¿cómo podemos implementar una función de retiro "sin permiso" que permita a los usuarios recuperar de forma segura sus activos a la Capa 1 incluso cuando están bajo el escrutinio de un secuenciador o un equipo de proyecto de la Capa 2? Algunos equipos de proyecto han propuesto la idea de secuenciadores descentralizados, pero esta es una solución superficial. Si este número limitado de secuenciadores se confabulan para escudriñarte, aún pueden "congelar" tus activos. Además, el problema de los ataques anti-Sybil en los nodos Proof of Stake (PoS) también es problemático (como se vio en el incidente de Multichain).

La solución más efectiva es establecer una 'salida' dedicada en la cadena de bloques de Capa 1, lo que permite a los usuarios retirar sus fondos de la Capa 2 a través de esta salida L1 en casos en los que no reciban respuesta del Secuenciador durante un período prolongado.

En el contexto de la versión 3 del Protocolo Loopring, describe dos escenarios diferentes para retiros forzados iniciados por el usuario. El primer escenario es el siguiente:

Los usuarios pueden iniciar directamente una retirada forzada en Capa 1 utilizando la función forcedWithdraw en el contrato ExchangeV3. Necesitan declarar cuál es su cuenta de Capa 2 en el Protocolo Loopring y qué Token desean retirar. Posteriormente, el contrato ExchangeV3 emite un evento de blockchain, señalando que alguien ha iniciado una solicitud de retirada forzada. Dado que todos los nodos en el Protocolo Loopring, incluido el Secuenciador, ejecutan el cliente Geth, serán informados sobre la retirada forzada y el evento de blockchain correspondiente desde los datos del bloque Ethereum.

Es importante tener en cuenta que una retirada forzada no se procesa de inmediato, sino que se coloca en la cola de pendingForcedWithdrawals, esperando ser procesada. Al notar una retirada forzada iniciada en Capa 1, el Secuenciador generalmente activa la función Procesar en el contrato ExchangeV3 dentro de 15 días. Esta función ejecuta la transferencia de tokens en la cadena de Ethereum al iniciador de la retirada (desde la dirección de depósito del proyecto de Capa 2 en la cadena de Ethereum al retirante).

Si el Secuenciador no responde a la solicitud de retiro forzado de un usuario en 15 días, el usuario puede llamar a la función notifyForcedRequestTooOld. Esta acción hace que el contrato ExchangeV3 emita un evento llamado WithdrawalModeActivated, notificando a todos los nodos en el Protocolo Loopring que se ha activado el modo de liquidación por quiebra.

Si se activa el modo de liquidación por quiebra, el Protocolo V3 de Loopring dejará de recibir nuevos bloques de L2 enviados por el Secuenciador, lo que significa que todo el Protocolo de Loopring dejará de operar en este momento. Este proceso durará al menos 30 días.

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

El artículo describe el modelo de liquidación por quiebra del Protocolo Loopring, que también se conoce como el mecanismo de “Escape Hatch” en L2BEAT. Este modelo se activa bajo ciertas condiciones, como cuando el secuenciador no responde a una solicitud de retiro forzoso de un usuario dentro de un tiempo especificado, o si el Secuenciador experimenta un mal funcionamiento o cierre a largo plazo. En tales casos, los usuarios pueden activar manualmente un proceso que pone el contrato Rollup en un estado congelado o detenido. Luego, los usuarios pueden construir una Prueba de Merkle para demostrar su situación de activos en la Capa 2 y retirar su parte de activos de la dirección de depósito del proyecto de Capa 2 en la Capa 1.

En la documentación de StarkEx, hay un diagrama específico que ilustra este proceso. Si una solicitud de Retiro Forzoso de un usuario de Capa 2 enviada en Capa 1 no recibe respuesta por parte del secuenciador dentro de una ventana de 7 días, el usuario puede invocar la función de solicitud de congelación para iniciar un período de congelación para la Capa 2. Durante este período, el secuenciador de Capa 2 no puede actualizar el estado de Capa 2 en Capa 1. El estado congelado de Capa 2 dura un año antes de poder descongelarse. Después, los usuarios pueden enviar una prueba de Merkle y retirar sus fondos.

Pero para construir una Prueba de Merkle, primero se necesita obtener el árbol completo del estado de Capa 2, lo que significa adquirir datos de un nodo completo de L2. Adicionalmente, se requiere un código específico para generar la Prueba de Merkle, presentando claramente un cierto nivel de barrera técnica. Para facilitar esto para la mayoría de los usuarios, L2BEAT había declarado previamente que la Capa 2 debería establecer un lote de nodos completos de acceso abierto y de código abierto, para ayudar a los usuarios a adquirir el estado de todas las cuentas en L2 (incluyendo saldo, número de transacciones, etc.). Este movimiento también subraya la importancia de los mecanismos de retiro forzoso y de escape.

La función de 'Inclusión Forzada de Transacciones' de Arbitrum

Sin embargo, las retiradas forzadas/cápsulas de escape no parecen ser la única solución contra la censura. Por ejemplo, Arbitrum emplea un método de 'inclusión forzada de transacciones', donde los usuarios pueden enviar primero las transacciones/retiradas que necesitan ser procesadas por el Secuenciador al contrato de Bandeja de entrada retrasada en la Capa 1 (L1). Si el Secuenciador no logra procesarlas en un plazo de 24 horas, los usuarios pueden llamar a la función de Inclusión forzada en el contrato de Bandeja de entrada del Secuenciador L1, permitiendo que la transacción se incluya directamente en la secuencia de transacciones de Arbitrum (lanzando un evento en cadena informando a los nodos de Arbitrum que varias transacciones registradas en la Bandeja de entrada retrasada deben incluirse en el libro mayor de Capa 2 (L2)).

El pasaje discute los enfoques de diferentes protocolos de blockchain en el manejo de transacciones, centrándose particularmente en Arbitrum en comparación con Loopring y StarkEx. Aquí está la traducción:

"En comparación con otros, el método de Arbitrum es algo más simple, pero aún tiene deficiencias. Simplemente emite un evento en cadena para informar a los nodos de Arbitrum que varias transacciones ignoradas por el secuenciador deben incluirse en la cadena más larga de L2, a diferencia del protocolo de Loopring y del modo de quiebra/pod de escape de StarkEx, que permiten a los usuarios retirar directamente sus fondos en L1. Si los nodos desafiantes en Arbitrum colaboran para lanzar un ataque de censura, parece posible congelar los fondos de los usuarios en L2."

Por lo tanto, el mecanismo de inclusión forzada de Arbitrum no es completamente sin permiso. Aunque un solo nodo honesto puede publicar una prueba de fraude para señalar una solicitud de inclusión forzada ignorada por el secuenciador, esto sigue introduciendo un grado de suposición de confianza, aunque sea menor.

Más específicamente, las 'transacciones que requieren inclusión forzada' deben ser reconocidas por al menos un nodo desafiante de ARB. Actualmente, hay nueve de estos nodos, y tienen la autoridad para decidir qué mensajes entre cadenas cruzadas entre L2 y L1 aprobar, y son los únicos que pueden emitir pruebas de fraude. Si estos nueve nodos conspiran juntos, teóricamente podrían invalidar una 'transacción forzada' de un usuario.

Por lo tanto, las transacciones actuales de inclusión o retiro de fuerza en Arbitrum no son tan permisivas como el modo de liquidación por quiebra de Loopring y StarkEx. Sin embargo, L2BEAT sigue valorando mucho este enfoque de Arbitrum. En el futuro, Arbitrum lanzará un mecanismo de publicación de pruebas de fraude sin permiso llamado BOLD, lo que dificultará, si no imposible, que los nodos desafiantes coludan (lo cual ya es difícil ahora).

Según datos de L2BEAT, actualmente, las plataformas de Capa 2 (L2) con un Valor Total Bloqueado (TVL) que supera los 50 millones de dólares estadounidenses, y que no ofrecen medidas para abordar el Fallo del Secuenciador o el Fallo del Proponente, incluyen OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM y Metis. Estas plataformas L2 podrían, en casos extremos, provocar que los activos de los usuarios se congelen y no se puedan retirar de la Capa 2.

Por lo tanto, es evidente que existe la necesidad de mecanismos como los retiros forzados o los modos de liquidación por insolvencia. Aunque actualmente se basan principalmente en la teoría de juegos entre los usuarios y los clasificadores (productores de órdenes), y no se pueden considerar realmente "retirables en cualquier momento" (Arbitrum tiene un retraso de 24 horas que podría fallar, Loopring tiene un retraso de hasta 15 días, StarkEx tiene un retraso máximo de 7 días), tener estos mecanismos es evidentemente mejor que no tenerlos en absoluto. El problema del retraso en los retiros forzados podría resolverse potencialmente en el futuro con diseños de mecanismos más sofisticados. Los diseños actuales tienen en cuenta la posible explotación de MEV (Valor Maximalmente Extraíble) a través de forceInclusion, lo que hace necesaria la introducción de retrasos. Para obtener más detalles, se debe consultar la documentación oficial de varios proyectos de Capa 2.

Con la creciente inclusión de Secuenciadores descentralizados en muchos mapas de ruta de Capa 2 y los continuos esfuerzos de entidades como la Fundación Ethereum, liderada por Vitalik Buterin, para educar a las personas sobre la seguridad de Capa 2, características como las funciones de transacciones anticensura en retiros forzados probablemente ganarán más atención. Esto acercará el ecosistema de Capa 2 de Ethereum a una infraestructura financiera resistente a la censura y minimizada en confianza. Si la Capa 2 logra una forma minimizada de confianza para mover fondos dentro y fuera, se espera que más creadores de mercado y proveedores de liquidez ingresen a la infraestructura de L2, impulsando un paso hacia la adopción masiva de web3.

Descargo de responsabilidad：

1. Este artículo es una reimpresión de [Faust, Web3 geek]. Todos los derechos de autor pertenecen al autor original [Faust, Web3 geek]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las 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 Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.