Propuesta de Retrasos en Retiros de Bitcoin
El cofundador de Rootstock, Sergio Lerner, ha propuesto que los puentes de Bitcoin adopten retrasos obligatorios en los retiros, tras un incidente en el que aproximadamente 4,000 BTC fueron retirados de la billetera de la federación de Liquid Network mediante un peg-out no autorizado.
Incidente de Peg-Out No Autorizado
Lerner, quien es científico jefe y cofundador de Rootstock Labs, comentó a crypto.news que la liquidación inmediata puede convertir un solo error de validación en una pérdida total antes de que los operadores del puente tengan tiempo de reaccionar.
«Sin un bloqueo temporal, un solo error de validación y una pérdida total se convierten en el mismo evento, ya que los fondos se mueven en el instante en que el software dice ‘sí'»
, afirmó Lerner.
Sus declaraciones se produjeron después de que actores malintencionados generaran L-BTC no respaldados y utilizaran el servicio de peg-out de SideSwap para retirar casi 4,000 BTC de la billetera de la federación Liquid. Liquid describió a estos actores como supuestos hackers de sombrero blanco, mientras que SideSwap indicó que su servicio procesó la solicitud porque el L-BTC parecía válido.
Propuesta de Lerner para Mitigar Daños
Lerner sugirió que un retraso obligatorio entre la creación del L-BTC no respaldado y la liberación del BTC real podría haber mitigado el daño. En un sistema así, la aprobación del software iniciaría un período de espera en lugar de completar el retiro de inmediato. Herramientas de monitoreo automatizadas podrían comparar el peg-out solicitado con el BTC que respalda el L-BTC y señalar cualquier desequilibrio antes de la liquidación.
«Si Liquid hubiera implementado un bloqueo temporal —donde los fondos no pueden moverse durante un período especificado, independientemente de lo que diga el software o los operadores— el error habría resultado en un incidente manejable en lugar de una catástrofe inmediata y a gran escala»
.
Según Lerner, el retraso habría proporcionado a los operadores una ventana de respuesta de varias horas después de la creación de los tokens no respaldados. Los sistemas de monitoreo que operan las 24 horas podrían haber detectado que el peg-out pasó las primeras verificaciones de software a pesar de carecer de colateral correspondiente.
Seguridad en el Sistema de Rootstock
Rootstock ya utiliza un mecanismo de retraso para retiros de BTC a través de su peg bidireccional, aunque las reglas de consenso de Bitcoin no imponen el período de espera. El sistema se basa en módulos de seguridad de hardware especializados llamados PowHSMs. Antes de firmar un peg-out, los dispositivos verifican de forma independiente que se hayan pasado 4,000 bloques de Rootstock, lo que representa aproximadamente 36 horas de prueba de trabajo acumulativa.
Las claves privadas permanecen dentro de los dispositivos, según Lerner, y los funcionarios no pueden instruir al hardware para que omita el período requerido. Rootstock combina las reglas de HSM con la minería combinada, a través de la cual los mineros de Bitcoin contribuyen con prueba de trabajo a la sidechain.
«Incluso una mayoría coludida de pegnatories no puede robar los fondos, porque las claves privadas nunca salen de los PowHSMs, y los HSMs verifican de forma independiente que han transcurrido 4,000 bloques de Rootstock antes de que firmen»
.
Consideraciones sobre el Mecanismo de Revocación
Lerner enfatizó que ninguna empresa, operador o administrador único debería controlar el mecanismo de revocación. En cambio, los funcionarios independientes deberían compartir la autoridad a través de una estructura multipartita, con reglas de hardware que limiten lo que pueden hacer. Bajo su modelo propuesto, los funcionarios podrían pausar el procesamiento, pero no podrían redirigir el BTC a otra dirección o confiscarlo.
«Para prevenir puntos únicos de falla o censura centralizada, los controles de revocación deberían distribuirse entre funcionarios independientes y multipartitos utilizando reglas impuestas por hardware en lugar de claves administrativas centralizadas»
.
Los retrasos temporales también tendrían que tener en cuenta el valor y el propósito de cada transacción. Una espera de 36 horas puede ser inapropiada para pagos rutinarios, mientras que un puente que maneja grandes cantidades de BTC tiene un perfil de riesgo diferente.
Conclusiones y Futuras Propuestas
Lerner no prescribió un retraso para cada puente, pero citó el requisito de 4,000 bloques de Rootstock como un período efectivo para la infraestructura que asegura grandes saldos de BTC. La protección actual de Rootstock depende de sus HSMs y federación en lugar de reglas impuestas por la red de Bitcoin.
Lerner mencionó que las bóvedas nativas de Bitcoin y las claves de revocación podrían trasladar controles comparables al protocolo base. Un posible bloque de construcción es BIP-443, una propuesta de borrador para un opcode llamado OP_CHECKCONTRACTVERIFY, o OP_CCV. La propuesta permitiría que una salida de Bitcoin lleve datos y restrinja cómo sus fondos pueden moverse a través de futuras transacciones.
La propuesta sigue en estado de borrador y su proceso de activación no ha sido determinado. Lerner citó OP_CCV y BIP-443 como ejemplos de cómo las bóvedas nativas podrían dar a los usuarios o partes designadas tiempo para cancelar un retiro después de detectar credenciales robadas, software alterado u otro evento anormal.
