Cofundador de Rootstock pide retiros diferidos para proteger los puentes de Bitcoin

El incidente de Liquid, que derivó en la transferencia de casi 4.000 BTC desde una billetera federada, llevó al cofundador de Rootstock a reclamar bloqueos de tiempo obligatorios para los puentes de Bitcoin. Sergio Lerner sostiene que varias horas de espera permitirían detectar errores de verificación antes de liberar los fondos reales.
***

• Sergio Lerner propuso que los puentes de Bitcoin incorporen retiros diferidos como requisito de seguridad.
• Una salida de 3.996 BTC desde la billetera de Liquid ocurrió después de la creación de L-BTC sin garantía suficiente.
• Rootstock utiliza un período de espera de aproximadamente 33 a 36 horas, equivalente a 4.000 bloques, antes de que sus dispositivos de seguridad firmen retiros de BTC.

El incidente que reabrió el debate

El cofundador y científico jefe de Rootstock, Sergio Lerner, propuso que los puentes entre cadenas de Bitcoin adopten los retiros diferidos como un mecanismo obligatorio de seguridad. Su planteamiento surgió después de un incidente en Liquid Network, donde una operación de retiro no autorizado terminó con la transferencia de casi 4.000 BTC desde una billetera controlada por la Liquid Federation. Lerner advirtió que la liberación inmediata puede convertir un error de verificación en una pérdida total antes de que los operadores tengan tiempo para reaccionar.

Según la información difundida por KuCoin, Lerner explicó a crypto.news que un puente sin bloqueo temporal ofrece una ventana de respuesta prácticamente inexistente. Si el software acepta una solicitud defectuosa y el sistema libera los fondos inmediatamente, los equipos de monitoreo y los responsables humanos solo pueden actuar después de que el BTC real ya haya salido de la reserva. Un retraso de varias horas, en cambio, permitiría revisar la operación, comparar los saldos y detener el proceso ante cualquier anomalía.

El episodio de Liquid comenzó con la creación de L-BTC sin una garantía suficiente, de acuerdo con los reportes citados en la información. Después, los fondos fueron enviados mediante el servicio de peg-out de SideSwap, que permite convertir los activos vinculados a Liquid nuevamente en BTC de la red principal. SideSwap indicó que procesó la solicitud conforme a sus procedimientos habituales, porque los L-BTC involucrados parecían indistinguibles de aquellos respaldados normalmente por reservas.

Aproximadamente 23 minutos después de la solicitud, la billetera de la federación transfirió 3.996 BTC a la dirección de Bitcoin designada. Liquid describió a las partes implicadas como los llamados hackers white-hat, mientras que Blockstream confirmó que los nodos del puente afectados ya fueron corregidos. Hasta ese momento se habían devuelto 3.400 BTC, pero aproximadamente 598 BTC continuaban sin recuperarse, una diferencia que mantiene abierta la preocupación sobre los controles previos a la liberación.

Cómo funcionaría el retiro diferido

La propuesta de Lerner consiste en separar la verificación inicial de la transferencia definitiva de BTC. Una vez que el software aprueba la solicitud, el retiro no se ejecutaría de inmediato, sino que entraría en una fase de espera durante la cual los sistemas automáticos y los operadores podrían revisar la operación. El objetivo sería introducir una barrera entre la detección de una condición aparentemente válida y la aplicación final de las firmas que liberan los fondos.

Durante ese período, las herramientas de monitoreo podrían comprobar si las solicitudes de peg-out coinciden con las reservas que respaldan la emisión de L-BTC. También podrían comparar la oferta de tokens, el volumen de BTC disponible y el historial de las operaciones antes de autorizar la salida. Si apareciera una discrepancia entre los activos emitidos y la garantía existente, los responsables tendrían la posibilidad de pausar el retiro antes de que el dinero abandone la billetera de la federación.

Lerner considera que una demora obligatoria habría reducido significativamente el impacto del incidente de Liquid. Bajo ese diseño, la creación de L-BTC sin respaldo suficiente habría quedado expuesta durante el intervalo previo a la liberación de los BTC, en lugar de avanzar directamente desde la validación del software hasta la transferencia. La idea no elimina por sí misma los errores de código ni las fallas operativas, pero transforma una respuesta posterior al incidente en una oportunidad de prevención.

El argumento también plantea una diferencia importante entre validar una solicitud y demostrar que existe respaldo suficiente para cumplirla. Un token puede aparentar ser legítimo para un servicio de peg-out si el sistema no incorpora una comprobación independiente de las reservas, aunque la emisión original haya sido irregular. La espera busca que esa segunda revisión ocurra antes de que las firmas de hardware conviertan una decisión digital en una salida irreversible de BTC.

Al 10 de septiembre, Liquid había reanudado la producción de bloques, pero las transacciones de recuperación y las operaciones de peg todavía no se habían reiniciado. Ese estado mostraba que corregir los nodos afectados era solo una parte de la respuesta, porque la red también debía evaluar la recuperación de fondos y las condiciones para restablecer sus operaciones vinculadas. La pausa operativa refleja la dificultad de reactivar un sistema cuando la confianza en sus controles de emisión y retiro ha sido puesta a prueba.

El modelo de Rootstock y el futuro de Bitcoin

Rootstock ya utiliza un período de espera de aproximadamente 33 a 36 horas en su mecanismo de peg bidireccional, según explicó Lerner. Sus módulos especializados de seguridad de hardware, conocidos como PowHSMs, verifican de manera independiente que hayan transcurrido 4.000 bloques de Rootstock antes de firmar los retiros de BTC. La arquitectura busca impedir que una solicitud aprobada por los nodos se convierta automáticamente en una transferencia anticipada.

El cofundador de Rootstock señaló que la clave privada permanece dentro del dispositivo y que los nodos funcionales no pueden pedirle al hardware que ignore el período de espera. Incluso si una mayoría de los participantes encargados de las firmas actuara de forma coordinada, el máximo efecto sería retrasar el retiro, no forzar una transferencia temprana del BTC subyacente. Ese diseño introduce una protección adicional frente a la presión operativa, la coordinación maliciosa y los errores en la lógica de validación.

Sin embargo, las medidas actuales de Rootstock dependen de módulos de seguridad de hardware y de una arquitectura federada, no del consenso de la red principal de Bitcoin. Lerner planteó que una futura solución de bóveda nativa en Bitcoin podría codificar controles similares directamente en el protocolo, de modo que las restricciones no dependieran únicamente de dispositivos externos o de un grupo de operadores. Esa posibilidad trasladaríaparte de la seguridad desde la infraestructura del puente hacia las reglas verificadas por la propia red.

En ese contexto, Lerner mencionó BIP-443, que todavía se encuentra en fase de borrador. La propuesta contempla un opcode llamado OP_CCV, capaz de imponer restricciones a las salidas de Bitcoin y limitar la forma en que los fondos pueden moverse posteriormente. Entre los casos de uso considerados aparecen las sidechains, las salidas con estado y los procesos de retiro en dos pasos que podrían revocarse antes de completarse.

La discusión sobre BIP-443 no significa que la propuesta ya forme parte del consenso de Bitcoin ni que resuelva de inmediato las vulnerabilidades de Liquid u otros puentes. Su importancia dentro de este debate radica en que muestra cómo los desarrolladores podrían construir mecanismos de espera y revocación con reglas más cercanas a la capa base. Mientras esas alternativas siguen en evaluación, los operadores deben decidir cuánto riesgo aceptan al equilibrar velocidad de retiro, facilidad de uso y protección de las reservas.

El incidente de Liquid deja así una advertencia concreta para los sistemas que conectan activos entre distintas cadenas: la rapidez puede convertirse en una desventaja cuando una validación equivocada libera fondos irreversibles. La propuesta de Lerner busca que los puentes compren tiempo para detectar anomalías, mientras Rootstock presenta su espera de aproximadamente 33 a 36 horas como un ejemplo de cómo ese principio puede aplicarse mediante hardware especializado. El debate continuará entre soluciones federadas, controles criptográficos y posibles cambios futuros en el protocolo de Bitcoin.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.
Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín