Mecanismo de salida de emergencia

¿Qué es un mecanismo de salida de emergencia en cripto?

Un mecanismo de salida de emergencia es un sistema alternativo que permite a los usuarios, administradores o sistemas automatizados de cripto recuperar activos o abandonar un protocolo cuando la vía de funcionamiento habitual deja de estar disponible o deja de ser segura.

Está diseñado para situaciones excepcionales, como una aplicación bloqueada, un operador no disponible, un secuenciador que censura transacciones, una vulnerabilidad grave en un contrato inteligente, un fallo de gobernanza o una interrupción prolongada del servicio.

En un contrato inteligente, un mecanismo de salida de emergencia puede permitir a los usuarios retirar los activos depositados después de que se active un estado de emergencia o venza un plazo.

En un sistema Layer 2, puede permitir al usuario demostrar que es el propietario y retirar activos mediante un contrato Layer 1 sin depender del operador habitual de Layer 2.

En una wallet o un acuerdo de custodia, el término puede describir una vía de recuperación que incluye claves de respaldo, varias firmas, transacciones con demora o una dirección de recuperación designada.

La documentación de Layer 2 de Ethereum utiliza el término mecanismo de salida de emergencia para describir la capacidad de recuperación que permite a los usuarios retirar activos a través de un contrato Layer 1 incluso si falla un sistema Layer 2.

El término no designa un estándar universal de contrato inteligente.

Su significado exacto depende del protocolo, los activos, el modelo de autorización, la blockchain y el escenario de fallo en cuestión.

Por qué los protocolos cripto necesitan mecanismos de salida de emergencia

Las aplicaciones cripto pueden mantener activos dentro de contratos inteligentes durante largos periodos.

Los usuarios quizá no puedan recuperar esos activos si la función de retirada habitual depende de un servidor averiado, un firmante no disponible, un oráculo defectuoso, un administrador comprometido o un secuenciador inactivo.

Además, el código inmutable puede dificultar la corrección de errores una vez desplegado.

Un mecanismo de salida de emergencia proporciona una vía de recuperación prevista antes de que ocurra una situación crítica.

Puede proteger la disponibilidad del sistema al garantizar que los usuarios conserven algún método para salir de él.

También puede proteger los fondos al permitir detener operaciones vulnerables mientras continúan las retiradas por una vía más segura.

Un mecanismo bien diseñado reduce la dependencia de la promesa de que el equipo siempre estará disponible.

Uno mal diseñado puede convertirse en una potente puerta trasera que permita a cuentas privilegiadas incautar o desviar los activos de los usuarios.

Por tanto, el valor de seguridad de un mecanismo de salida de emergencia depende de quién pueda activarlo, de sus funciones y de si los usuarios pueden verificar sus reglas on-chain.

Significados habituales de mecanismo de salida de emergencia

El término puede describir varios mecanismos cripto relacionados, pero distintos.

Una función de retirada de emergencia permite a los usuarios retirar sus propios activos cuando se han suspendido las operaciones normales del protocolo.

Una salida forzosa permite a un usuario de Layer 2 retirar activos a través de un bridge Layer 1 cuando el operador de Layer 2 se niega a procesar la solicitud o no puede hacerlo.

Un reembolso por vencimiento devuelve fondos bloqueados cuando otra parte no completa una acción antes de una fecha límite.

Una clave de recuperación permite al propietario de una wallet recuperar el control tras perder una clave de firma de uso habitual.

Una actualización de emergencia permite a la gobernanza autorizada sustituir la lógica vulnerable de un contrato.

Un proceso de cierre apaga un protocolo de manera ordenada y distribuye los activos restantes según reglas predefinidas.

Un disyuntor limita o pausa la actividad cuando los precios, saldos o volúmenes de transacciones superan las condiciones previstas.

Todos estos mecanismos pueden denominarse mecanismos de salida de emergencia, pero implican supuestos de confianza y consecuencias de seguridad diferentes.

Mecanismo de salida de emergencia en un contrato inteligente

Un mecanismo de salida de emergencia de un contrato inteligente es una función o un conjunto de funciones disponibles durante un estado anómalo del protocolo.

El contrato puede pasar del funcionamiento normal a un estado de emergencia, pausa, liquidación o retirada únicamente.

Se pueden desactivar actividades arriesgadas como nuevos depósitos, préstamos, trading, acuñación o aumento del apalancamiento.

Se puede seguir permitiendo que los usuarios retiren los activos que el contrato registra como suyos.

El contrato debería definir qué saldos se pueden retirar y cómo se calculan.

La vía de emergencia no debería depender del mismo componente que causó el fallo.

Por ejemplo, un fallo del oráculo no debería impedir a los usuarios retirar activos si el importe de la retirada puede calcularse sin dicho oráculo.

Un mecanismo de salida de emergencia de un contrato inteligente no puede resolver cualquier situación, ya que unos registros contables dañados o el robo de activos pueden dejar fondos insuficientes para completar todas las retiradas.

Mecanismo de salida de emergencia en Layer 2

Un mecanismo de salida de emergencia de Layer 2 es un método para recuperar activos a través de la capa de liquidación subyacente cuando falla el procesamiento normal de Layer 2.

Los sistemas Layer 2 suelen utilizar un operador o secuenciador para ordenar transacciones y ofrecer confirmaciones rápidas.

Si el operador deja de estar disponible o censura a un usuario, quizá no se procese la solicitud de retirada habitual.

Un mecanismo de salida de emergencia sólido proporciona una vía alternativa a través de un bridge Layer 1 o un contrato de liquidación.

El usuario puede enviar directamente a Layer 1 una transacción, una prueba de estado, una prueba de retirada o una solicitud de inclusión forzosa.

Las directrices de Ethereum sobre la capacidad de recuperación de los rollups explican que publicar los datos de las transacciones en Layer 1 puede permitir recuperar activos incluso si desaparece el operador de Layer 2.

Un mecanismo de salida de emergencia es especialmente importante cuando un único operador puede controlar temporalmente el orden de las transacciones.

Sin una vía de salida forzosa, los saldos de los usuarios pueden quedar bloqueados, aunque los activos subyacentes sigan existiendo en un contrato bridge.

Cómo funciona una salida forzosa de Layer 2

Por lo general, una salida forzosa comienza cuando un usuario no puede completar una retirada normal de Layer 2.

El usuario obtiene la información de estado necesaria para demostrar el saldo o la propiedad de la cuenta.

A continuación, envía la solicitud o prueba necesaria al contrato Layer 1.

El contrato verifica la prueba frente a un compromiso de estado Layer 2 aceptado.

Si la prueba y las condiciones de retirada son válidas, el contrato autoriza la liberación correspondiente de activos en Layer 1.

Algunos sistemas exigen un periodo de espera o impugnación antes de que la retirada sea definitiva.

Otros utilizan pruebas de validez que permiten al contrato verificar criptográficamente una transición de estado aceptada.

El proceso exacto depende del diseño de Layer 2 y puede requerir software especializado que no esté disponible en las interfaces habituales de las wallets.

Un mecanismo de salida de emergencia teórico resulta menos útil si los usuarios no pueden obtener los datos necesarios o generar la prueba requerida durante una emergencia.

Disponibilidad de los datos y mecanismos de salida de emergencia

La disponibilidad de los datos es fundamental, porque el usuario necesita información suficiente para reconstruir los saldos y demostrar que la retirada es válida.

Un compromiso de estado por sí solo puede demostrar que existe un estado sin revelar los datos necesarios para establecer la posición de un usuario concreto.

Cuando los datos necesarios de transacciones y estado están disponibles de forma fiable en Layer 1, un software independiente puede reconstruir el estado de Layer 2.

Esto permite continuar los intentos de recuperación sin la colaboración del operador original.

Las directrices de Ethereum sobre salidas forzosas advierten de que los usuarios pueden quedar bloqueados si un secuenciador centralizado puede impedir transacciones y no existe una vía de retirada forzosa en Layer 1.

Los sistemas que almacenan datos esenciales en otro lugar pueden introducir una dependencia adicional de disponibilidad.

Si esa fuente externa de datos desaparece, el contrato bridge puede seguir teniendo fondos mientras los usuarios no pueden crear pruebas de salida válidas.

Mecanismo de salida de emergencia frente a retirada normal

Una retirada normal forma parte del funcionamiento cotidiano previsto del protocolo.

Por lo general, depende de los contratos, interfaces, operadores, procesos contables y sistemas de mensajería habituales de la aplicación.

Un mecanismo de salida de emergencia es una vía alternativa pensada para condiciones anómalas.

Puede requerir una demora más prolongada, pruebas adicionales, una comisión de gas más alta o una interfaz distinta.

La vía normal puede ofrecer una liquidación más rápida y una experiencia de usuario más sencilla.

La vía de emergencia prioriza la capacidad de recuperación cuando esos servicios normales no están disponibles.

Un protocolo debería documentar ambas vías para que los usuarios entiendan que la rapidez de una retirada ordinaria no determina necesariamente el tiempo necesario para una recuperación de emergencia.

Mecanismo de salida de emergencia frente a función de pausa

Una función de pausa detiene determinadas actividades del contrato, mientras que un mecanismo de salida de emergencia proporciona una vía para salir del sistema.

Una pausa puede impedir que una vulnerabilidad activa cause más pérdidas.

Una pausa que bloquee todas las retiradas también puede dejar atrapados a los usuarios y crear dependencia del administrador que la controla.

Un diseño más seguro puede pausar los nuevos depósitos y las acciones de alto riesgo mientras mantiene limitadas las retiradas.

La autoridad que controla la pausa debería estar claramente identificada y protegida mediante controles de acceso sólidos.

El protocolo también debería definir cómo termina el estado de pausa y qué ocurre si la cuenta autorizada deja de estar disponible.

Un botón de pausa sin una vía de recuperación no constituye un mecanismo de salida de emergencia completo.

Mecanismo de salida de emergencia frente a disyuntor

Un disyuntor restringe la actividad de forma automática o manual cuando se produce una condición de riesgo especificada.

Puede limitar las retiradas, detener los préstamos, establecer un límite al tamaño de las transacciones o desactivar determinados mercados.

Un mecanismo de salida de emergencia se centra más directamente en permitir que los usuarios o el protocolo se recuperen de un fallo.

Ambos mecanismos pueden funcionar conjuntamente.

Un disyuntor puede detener primero la actividad insegura y, después, un proceso de retirada de emergencia permitir a los usuarios salir.

Unos umbrales incorrectos pueden hacer que el disyuntor se active durante una volatilidad de mercado normal o que no lo haga durante una emergencia real.

Por eso, las condiciones automatizadas deberían probarse con incidentes reales y escenarios extremos simulados.

Mecanismo de salida de emergencia frente a actualización del contrato

Una actualización de contrato cambia el código utilizado por una aplicación, mientras que un mecanismo de salida de emergencia puede permitir que los usuarios retiren sus activos sin reparar la aplicación.

Una actualización de emergencia puede eliminar una vulnerabilidad y restablecer el funcionamiento normal.

También concede un poder considerable a quien controle el mecanismo de actualización.

Una autoridad de actualización maliciosa o comprometida podría instalar código que redirija fondos o cambie las reglas de retirada.

Un mecanismo de salida de emergencia puede ofrecer una alternativa a los usuarios que no quieran confiar en una actualización propuesta.

Una actualización con demora puede dar a los usuarios la oportunidad de revisar el cambio y salir antes de que entre en vigor.

Las actuales directrices de OpenZeppelin sobre el control de acceso a contratos inteligentes explican que las operaciones con demora pueden dar tiempo a los usuarios para revisar acciones de mantenimiento y abandonar un sistema antes de que se ejecuten.

Mecanismos de salida de emergencia bajo el control del usuario

Un mecanismo de salida de emergencia controlado por el usuario permite a cada persona recuperar sus propios activos admisibles sin la aprobación de un administrador.

Este diseño reduce la dependencia de que un equipo, empresa o grupo de gobernanza siga disponible.

El contrato debe verificar que quien realiza la solicitud tiene derecho a los activos solicitados.

La prueba puede basarse en saldos almacenados, compromisos criptográficos, firmas, pruebas de Merkle o datos de estado finalizados.

Un usuario no debería poder retirar el saldo de otra cuenta ni reutilizar dos veces la misma prueba.

Los nonces, nullifiers, registros de retirada o actualizaciones de estado pueden impedir reclamaciones repetidas.

La recuperación bajo el control del usuario suele ser más sólida cuando cualquiera puede enviar la transacción y el resultado depende únicamente de las reglas públicas del protocolo.

Mecanismos de salida de emergencia controlados por administradores

Un mecanismo de salida de emergencia controlado por un administrador permite que una cuenta privilegiada active funciones de emergencia o transfiera activos.

Este método puede responder rápidamente cuando un incidente complejo requiere criterio humano.

También puede crear riesgos de censura o incautación centralizadas.

El contrato debería limitar al administrador a la autoridad mínima necesaria para afrontar la emergencia.

Por ejemplo, se podría permitir al administrador pausar los depósitos, pero no transferir los saldos de los usuarios a una dirección arbitraria.

Se pueden asignar funciones separadas para pausar, actualizar, retirar activos propiedad del protocolo y resolver reclamaciones de los usuarios.

Los cambios de permisos y las acciones de emergencia deberían generar registros de eventos para que los sistemas de monitorización puedan detectarlos.

Los usuarios deberían revisar los permisos reales on-chain en lugar de confiar únicamente en afirmaciones de que un administrador no puede acceder a los fondos.

Control de emergencia multifirma

Un sistema multifirma exige la aprobación de varias claves autorizadas antes de ejecutar una acción de emergencia.

Esto reduce el riesgo de que una sola clave robada active el mecanismo de salida de emergencia o desvíe activos.

El beneficio para la seguridad depende de que los firmantes sean realmente independientes.

Varias claves en manos de una sola persona, guardadas en un mismo lugar o gestionadas a través de un único servicio pueden fallar a la vez.

El umbral de firmas debería equilibrar la rapidez de respuesta ante emergencias con la protección frente a la colusión o el compromiso de claves.

El sistema debería definir qué ocurre si demasiados firmantes pierden el acceso a sus claves.

Un diseño multifirma sigue siendo vulnerable si los firmantes aprueban una transacción maliciosa sin comprender plenamente sus efectos.

Bloqueos temporales y ventanas de salida

Un bloqueo temporal retrasa una acción sensible después de anunciarla on-chain.

El retraso da tiempo a usuarios, desarrolladores, auditores y servicios de monitorización para revisar el cambio propuesto.

Los usuarios que no estén de acuerdo con el cambio quizá puedan retirar sus activos antes de que entre en vigor.

Una ventana de salida solo resulta útil si las retiradas siguen disponibles y hay tiempo suficiente para completarlas.

Un retraso breve puede resultar ineficaz durante una congestión de la red o si muchos usuarios intentan salir a la vez.

Un retraso demasiado prolongado puede impedir reparar rápidamente una vulnerabilidad urgente.

Algunos sistemas utilizan procedimientos distintos para las actualizaciones habituales y las acciones de emergencia.

La posibilidad de eludir un bloqueo temporal durante una emergencia debería tratarse como un privilegio importante y comunicarse con claridad.

Mecanismos de salida de emergencia automáticos

Un mecanismo de salida de emergencia automático se activa cuando se cumple una condición predefinida.

Entre los posibles activadores figuran el incumplimiento de un plazo de actualización, la falta de disponibilidad de un operador, la expiración de un periodo de impugnación, el fallo de una fuente de precios o un desequilibrio contable.

La activación automática puede reducir la dependencia de que un administrador humano detecte y responda al problema.

El activador debe poder medirse mediante datos que el contrato pueda verificar.

Un oráculo poco fiable puede activar el mecanismo por error o impedir su activación.

Un atacante también puede intentar manipular la condición de activación si el mecanismo le proporciona una ventaja financiera.

La lógica de recuperación automática debería definir cómo vuelve el sistema al funcionamiento normal una vez resuelto el incidente.

Modo de retirada únicamente

El modo de retirada únicamente desactiva la asunción de nuevos riesgos mientras permite a los usuarios retirar los activos admitidos.

El sistema puede rechazar nuevos depósitos, préstamos, operaciones de trading, emisiones de tokens o aumentos de posiciones.

Los usuarios existentes pueden reducir su exposición o retirar activos conforme a las reglas contables vigentes.

Este modo puede facilitar un cierre ordenado o dar tiempo para investigar una vulnerabilidad.

El protocolo debe decidir cómo gestionar préstamos abiertos, posiciones apalancadas, operaciones pendientes, comisiones sin liquidar y activos que no puedan transferirse con normalidad.

Un estado de retirada únicamente no garantiza la recuperación completa si el protocolo ya tiene un déficit de colateral.

Los usuarios deberían saber si las retiradas se procesan proporcionalmente, por orden de solicitud o mediante otra regla de asignación.

Retiradas de emergencia basadas en solicitudes individuales

Un diseño de retirada basada en solicitudes individuales registra cuánto puede reclamar cada usuario y exige que este envíe una transacción de retirada por separado.

Así se evita transferir activos a todos los usuarios en una sola transacción de gran tamaño.

También se impide que una transferencia fallida a un destinatario bloquee los pagos a todos los demás.

Las directrices de Solidity sobre el patrón de retirada recomiendan actualizar el saldo pendiente del usuario antes de realizar la transferencia externa.

El contrato debería marcar el importe como reclamado antes de llamar al destinatario para reducir el riesgo de reentrada.

Los usuarios necesitan disponer de suficiente moneda nativa de la blockchain para pagar la comisión de transacción necesaria para reclamar sus activos.

El protocolo quizá necesite ofrecer un método admitido a quienes no puedan acceder a la interfaz normal de la aplicación.

Riesgos al gestionar tokens

Un mecanismo de salida de emergencia debe tener en cuenta el comportamiento real de cada token admitido.

Algunos tokens cobran comisiones por transferencia, modifican los saldos automáticamente, bloquean determinadas direcciones, pausan las transferencias o devuelven valores inusuales al realizar llamadas a contratos.

El emisor de un token puede congelar el contrato de depósito en garantía o de recuperación aunque la lógica del mecanismo de salida de emergencia sea correcta.

El saldo de un token con rebase puede cambiar sin una transferencia directa.

Un token con callbacks de transferencia puede ejecutar código externo durante la retirada.

El contrato debería medir los activos con cuidado y no suponer que todos los tokens siguen un modelo sencillo de saldo fijo.

Las pruebas de emergencia deberían incluir comportamientos inusuales de tokens y transferencias fallidas.

Reentrada y llamadas externas

Una función de retirada de emergencia puede ser vulnerable a la reentrada si transfiere activos antes de actualizar el derecho de reclamación registrado del usuario.

Un contrato receptor malicioso puede volver a llamar a la función de retirada durante la primera transferencia.

El protocolo debería actualizar la contabilidad interna antes de realizar una llamada externa.

También puede utilizar protecciones contra la reentrada y funciones de retirada con un alcance limitado.

La documentación de seguridad de Solidity explica que las llamadas externas pueden ceder el control a otro contrato y deben gestionarse con cuidado.

Un mecanismo de salida de emergencia no debería introducir una nueva vulnerabilidad al intentar responder a otra ya existente.

Oráculos de precios y liquidación de emergencia

Un protocolo de préstamos o derivados puede necesitar precios de activos para determinar la reclamación final de cada usuario.

Si el oráculo de precios es el componente que ha fallado, utilizar el último precio informado puede dar lugar a liquidaciones injustas o inseguras.

El mecanismo de salida de emergencia puede utilizar un precio con demora, un proceso de referencia independiente, un precio de liquidación aprobado por la gobernanza o una regla de contingencia predefinida.

Cada alternativa implica contrapartidas relacionadas con la manipulación, los retrasos y la discrecionalidad.

El protocolo debería definir el método de valoración de emergencia antes de que ocurra un incidente.

Cambiar la regla después de que se conozcan las pérdidas puede beneficiar a un grupo de usuarios a costa de otro.

Insolvencia y recuperación proporcional

Un mecanismo de salida de emergencia no puede distribuir más activos de los que controla el sistema.

Si los activos han sido robados, perdidos, congelados o utilizados para cubrir deudas incobrables, el protocolo puede ser insolvente.

Procesar las retiradas por orden de llegada puede permitir que los primeros usuarios reciban el valor completo mientras los últimos no reciben nada.

Una liquidación proporcional puede distribuir los activos restantes de acuerdo con las reclamaciones registradas.

Este método puede exigir que el sistema detenga las retiradas ordinarias mientras calcula los saldos.

Las reclamaciones disputadas y los cambios en el valor de los activos pueden dificultar el cálculo.

Los usuarios deberían distinguir entre un mecanismo de salida de emergencia que garantiza el acceso técnico y otro que garantiza el reembolso financiero completo.

Gobernanza y mecanismos de salida de emergencia

La gobernanza puede controlar cuándo se inicia un modo de emergencia, cómo se seleccionan las reglas de liquidación y cuándo se reanuda el funcionamiento normal.

La votación con tokens puede facilitar una participación más amplia, pero quizá sea lenta durante un exploit activo.

Los comités delegados o grupos multifirma pueden responder con mayor rapidez, pero implican supuestos de confianza más exigentes.

Un atacante de gobernanza puede intentar activar un mecanismo de salida de emergencia para obtener un beneficio personal.

El poder de voto prestado o adquirido temporalmente también puede influir en una propuesta de emergencia mal diseñada.

Los cambios de gobernanza críticos pueden requerir normas de cuórum, demoras en la votación, bloqueos temporales de ejecución y límites de autoridad claros.

La gobernanza de emergencia debería probarse con el mismo cuidado que las funciones habituales de los contratos inteligentes.

Seguridad y disponibilidad

La seguridad consiste en impedir movimientos de activos no válidos o no autorizados.

La disponibilidad consiste en garantizar que los usuarios legítimos puedan completar acciones como retirar fondos.

Un mecanismo de salida de emergencia extremadamente restrictivo puede proteger contra el robo, pero dejar los fondos bloqueados indefinidamente.

Uno excesivamente permisivo puede mantener la rapidez de las retiradas y permitir reclamaciones fraudulentas.

Los diseños sólidos equilibran estos objetivos mediante pruebas, demoras, autoridad limitada, monitorización y procedimientos alternativos.

El equilibrio adecuado depende del valor depositado, la complejidad del protocolo, los modos de fallo previstos y la capacidad de los usuarios para generar pruebas de forma independiente.

Cómo probar un mecanismo de salida de emergencia

Un mecanismo de salida de emergencia debería probarse antes de que los fondos dependan de él.

Los desarrolladores deberían simular fallos del operador o del oráculo, firmantes no disponibles, pausas del contrato, congestión de la red, transferencias de tokens fallidas e insolvencia parcial.

Las pruebas deberían confirmar que las cuentas no autorizadas no pueden activar el mecanismo ni retirar activos de otro usuario.

También deberían verificar que los usuarios legítimos puedan completar la recuperación sin una aprobación oculta off-chain.

Los sistemas grandes pueden realizar pruebas públicas en redes de pruebas o despliegues con valor limitado.

El software de recuperación debería mantenerse, aunque apenas se utilice.

La documentación, las herramientas para generar pruebas, las direcciones de los contratos y las instrucciones de transacción deberían conservarse en más de una ubicación.

Un mecanismo de emergencia no probado puede fallar justo cuando los sistemas habituales de desarrollo y asistencia no estén disponibles.

Cómo pueden evaluar los usuarios un mecanismo de salida de emergencia

El primer paso es identificar los escenarios de fallo exactos para los que se ha diseñado el mecanismo.

El segundo es determinar si los usuarios pueden activarlo directamente o si necesitan la aprobación de un administrador.

El tercero es comprobar qué activos se pueden retirar y cómo se calculan los importes reclamables.

El cuarto es revisar si el mecanismo depende de un secuenciador, oráculo, sitio web, servidor, grupo de firmantes o proveedor externo de datos.

El quinto es revisar los bloqueos temporales, periodos de espera, requisitos de prueba, comisiones de transacción y límites de retirada.

El sexto es verificar on-chain los permisos del administrador, de pausa, de actualización y de transferencia de activos.

El séptimo es determinar si hay suficientes datos y software de código abierto para una recuperación independiente.

El octavo es comprobar si el mecanismo ha sido auditado y probado en simulacros de fallos realistas.

El noveno es entender qué ocurre en caso de insolvencia o cuando el contrato no dispone de activos suficientes.

El décimo es guardar las direcciones oficiales de los contratos y las instrucciones de recuperación antes de que una emergencia impida acceder a las interfaces habituales.

Ejemplo de mecanismo de salida de emergencia

Supongamos que los usuarios depositan tokens en un contrato bridge de Layer 2 y reciben saldos equivalentes en una red de ejecución más rápida.

El secuenciador habitual procesa las transferencias y solicitudes de retirada.

Más adelante, el secuenciador deja de procesar transacciones durante un periodo prolongado.

Los usuarios no pueden enviar retiradas a través de la interfaz habitual, pero los datos de las transacciones y los compromisos de estado aceptados siguen disponibles en Layer 1.

Un usuario ejecuta un software de recuperación independiente y crea una prueba de su último saldo válido.

A continuación, envía la prueba al contrato bridge de Layer 1.

El contrato verifica la prueba y registra la solicitud de salida.

Una vez transcurrido el periodo de espera o verificación requerido, el usuario reclama los tokens correspondientes en Layer 1.

La liberación final de los activos no requiere la colaboración del operador.

Esta vía de recuperación es un mecanismo de salida de emergencia porque permite al usuario abandonar el sistema cuando falla la vía habitual de Layer 2.

Errores habituales con los mecanismos de salida de emergencia

Un error habitual es suponer que cualquier función de pausa permite a los usuarios retirar fondos.

Otro es llamar mecanismo de salida de emergencia sin permisos a una función de transferencia controlada por un administrador.

Un tercer error es suponer que una salida de Layer 2 funciona sin acceso a los datos de estado y al software para generar pruebas.

Un cuarto es conceder autoridad de emergencia ilimitada a una única hot wallet.

Un quinto es permitir que un administrador eluda un bloqueo temporal sin comunicar claramente ese poder.

Un sexto es no probar el mecanismo de salida de emergencia con tokens no estándar y contratos receptores maliciosos.

Un séptimo es utilizar un proceso de retirada por orden de llegada en caso de insolvencia sin explicar sus consecuencias.

Un octavo es suponer que una auditoría garantiza que el mecanismo de emergencia funcionará en todas las situaciones de fallo.

Un noveno es esperar a que ocurra un incidente para localizar las direcciones correctas de los contratos y las instrucciones.

Un décimo es creer que el acceso técnico a las retiradas garantiza la recuperación completa después de que ya se hayan perdido activos.

Preguntas frecuentes

¿Qué significa mecanismo de salida de emergencia en cripto?

Es un sistema alternativo que permite recuperar o retirar activos cuando falla la vía habitual de funcionamiento de un sistema cripto.

¿Un mecanismo de salida de emergencia es lo mismo que una retirada de emergencia?

La retirada de emergencia es un tipo de mecanismo de salida de emergencia, pero el término también puede describir salidas forzosas de Layer 2, reembolsos por vencimiento, claves de recuperación o sistemas de liquidación de emergencia.

¿Qué es un mecanismo de salida de emergencia de Layer 2?

Es una vía de recuperación que permite a los usuarios retirar activos mediante un contrato Layer 1 cuando el operador o secuenciador habitual de Layer 2 no está disponible o censura transacciones.

¿Por qué es importante la disponibilidad de los datos?

Los usuarios necesitan suficientes datos de estado y transacciones para demostrar sus saldos y crear retiradas de recuperación válidas.

¿Una función de pausa es un mecanismo de salida de emergencia?

Una función de pausa solo se convierte en un mecanismo de salida de emergencia cuando se combina con un método fiable para que los usuarios recuperen o retiren sus activos admisibles.

¿Puede un mecanismo de salida de emergencia evitar todas las pérdidas?

No, no puede reembolsar íntegramente a los usuarios si los activos ya han sido robados, congelados, destruidos o perdidos por insolvencia.

¿Quién puede activar un mecanismo de salida de emergencia?

La activación puede depender de usuarios individuales, una condición del contrato inteligente, la gobernanza, un grupo multifirma, un administrador o una combinación de estos métodos.

¿Puede un mecanismo de salida de emergencia ser una puerta trasera?

Sí, un mecanismo demasiado potente o mal protegido puede permitir que cuentas privilegiadas incauten fondos, cambien las reglas o eludan los controles de seguridad habituales.

¿Qué es una retirada forzosa?

Una retirada forzosa permite a un usuario enviar una solicitud de recuperación mediante un contrato de la capa base sin depender de que el operador habitual incluya la transacción.

¿Un mecanismo de salida de emergencia necesita un bloqueo temporal?

No siempre, pero los bloqueos temporales pueden dar a los usuarios la oportunidad de revisar cambios sensibles y salir antes de que entren en vigor.

¿Puede un usuario activar un mecanismo de salida de emergencia de Layer 2 desde una wallet normal?

Algunos sistemas admiten transacciones sencillas; otros requieren pruebas, datos o software de recuperación especializados.

¿Un mecanismo de salida de emergencia garantiza una retirada instantánea?

No, la recuperación de emergencia puede implicar periodos de impugnación, colas, generación de pruebas, costes de gas o pasos de liquidación manuales.

¿Puede un oráculo controlar un mecanismo de salida de emergencia?

Un oráculo puede proporcionar un valor de activación o liquidación, pero esto añade el riesgo de que unos datos incorrectos o no disponibles produzcan un resultado equivocado.

¿Qué ocurre si el protocolo es insolvente?

El mecanismo de salida de emergencia solo puede distribuir los activos que queden, por lo que quizá el sistema necesite una liquidación proporcional u otro proceso para asignar las pérdidas.

¿Cómo pueden verificar los usuarios un mecanismo de salida de emergencia?

Deberían examinar los contratos, la autoridad de activación, la lógica de retirada, los bloqueos temporales, los requisitos de datos, las herramientas para generar pruebas, los permisos de actualización y las revisiones de seguridad independientes.

¿Puede la gobernanza desactivar un mecanismo de salida de emergencia?

La gobernanza quizá pueda modificarlo o desactivarlo si los contratos admiten actualizaciones, por lo que los usuarios deben revisar las facultades reales de gobernanza y actualización.

¿Una auditoría demuestra que el mecanismo de salida de emergencia funcionará?

No, una auditoría puede identificar algunos riesgos, pero no puede garantizar el funcionamiento correcto ante todos los fallos técnicos, económicos o de gobernanza.

¿Qué es el modo de retirada únicamente?

El modo de retirada únicamente bloquea la asunción de nuevos riesgos y permite que los usuarios que cumplan los requisitos retiren activos del protocolo.

¿Debería utilizarse una wallet multifirma para un mecanismo de salida de emergencia?

Un sistema multifirma puede reducir el riesgo asociado a una sola clave, pero su valor depende de la independencia de los firmantes, el diseño del umbral, la seguridad de las claves y la transparencia de los límites de autoridad.

¿Cuál es el objetivo principal de un mecanismo de salida de emergencia?

Su objetivo principal es mantener una vía de recuperación creíble cuando el sistema cripto habitual no puede procesar las salidas de los usuarios de forma segura o fiable.

Conclusión

Un mecanismo de salida de emergencia es un sistema de recuperación cripto diseñado para proteger a los usuarios cuando las operaciones normales de un protocolo dejan de estar disponibles o dejan de ser seguras.

Puede consistir en una retirada de emergencia, una salida forzosa de Layer 2, un reembolso por vencimiento, una clave de recuperación, un modo de retirada únicamente o un proceso de liquidación de emergencia.

Un mecanismo de salida de emergencia sólido preserva la disponibilidad sin conceder a una sola cuenta privilegiada un control ilimitado sobre los activos de los usuarios.

Los mecanismos de salida de emergencia de Layer 2 dependen en gran medida de la disponibilidad fiable de los datos, los compromisos de estado válidos, las herramientas accesibles para generar pruebas y el buen funcionamiento del contrato bridge Layer 1.

Los mecanismos de salida de emergencia de contratos inteligentes requieren una contabilidad segura, controles de acceso cuidadosos, llamadas externas seguras, protección contra la repetición de operaciones y compatibilidad con comportamientos inusuales de tokens.

Los bloqueos temporales, la autorización multifirma, la separación de funciones, los registros públicos de eventos y la limitación de los poderes de emergencia pueden reducir los riesgos del control privilegiado.

Un mecanismo de salida de emergencia no puede sustituir activos que ya hayan sido robados ni garantizar el reembolso completo de un protocolo insolvente.

Los usuarios deberían averiguar quién puede activarlo, qué activos permite retirar, qué dependencias conserva y si es posible recuperarlos sin el operador original.

Los desarrolladores deberían probar las vías de emergencia en condiciones de fallo realistas en lugar de tratarlas como código de respaldo que nunca se utiliza.

Comprender los mecanismos de salida de emergencia ayuda a los usuarios de cripto a distinguir una capacidad real de recuperación sin permisos de un botón de pausa, una promesa del administrador o una puerta trasera de emergencia.