El cofundador de Rootstock, Sergio Lerner, ha pedido que los puentes de Bitcoin adopten retrasos obligatorios en los retiros después de que aproximadamente 4,000 BTC salieran de la billetera de la federación de Liquid Network a través de un peg-out no autorizado.
Resumen
- Un bloqueo con retardo temporal podría dar a los operadores del puente varias horas para identificar y detener retiros no autorizados.
- Los PowHSM de Rootstock esperan 4,000 bloques, o aproximadamente 36 horas, antes de firmar un peg-out.
- Lerner dijo que los funcionarios comprometidos de Rootstock podrían detener el peg pero no podrían forzar un retiro anticipado.
- El borrador de propuesta de Bitcoin BIP-443 podría respaldar diseños de bóveda que coloquen los controles de retiro en las reglas de consenso.
Sergio Lerner, científico jefe y cofundador de RootstockLabs, dijo a crypto.news que la liquidación inmediata puede convertir un solo error de validación en una pérdida antes de que los operadores del puente tengan tiempo de responder.
"Sin un bloqueo con retardo temporal, un solo error de validación y una pérdida total se convierten exactamente en el mismo evento, porque los fondos se mueven en el momento en que el software dice 'sí'", dijo Lerner.
Sus comentarios siguieron a un incidente en el que actores crearon L-BTC sin respaldo y utilizaron el servicio de peg-out de SideSwap para retirar casi 4,000 BTC de la billetera de Liquid Federation. Liquid describió a los actores como presuntos hackers de sombrero blanco, mientras que SideSwap dijo que su servicio procesó la solicitud porque el L-BTC parecía válido.
Los actores devolvieron posteriormente 3,400 BTC después de que Blockstream confirmara que los nodos de puente afectados habían sido parcheados. Quedaron pendientes aproximadamente 598 BTC, mientras que Liquid reanudó la producción de bloques sin restaurar las transacciones ni las operaciones de peg a partir del 10 de septiembre.
Un bloqueo con retardo temporal podría haber creado una ventana de intervención
Lerner dijo que un retraso obligatorio entre la creación del L-BTC sin respaldo y la liberación de BTC real podría haber reducido el daño.
Bajo tal sistema, la aprobación del software iniciaría un período de espera en lugar de completar el retiro. Las herramientas de monitoreo automatizadas podrían comparar el peg-out solicitado con el BTC que respalda al L-BTC y señalar cualquier desequilibrio antes de la liquidación.
"Si Liquid hubiera poseído un bloqueo con retardo temporal — donde los fondos no pueden moverse durante un período específico independientemente de lo que digan el software o los operadores — el error habría resultado en un incidente manejable en lugar de una catástrofe inmediata a gran escala".
Según Lerner, el retraso habría dado a los operadores una ventana de respuesta de varias horas después de que se crearan los tokens sin respaldo. Los sistemas de monitoreo que funcionan las 24 horas podrían haber detectado que el peg-out pasó las primeras verificaciones del software a pesar de carecer de la garantía correspondiente.
Los funcionarios podrían entonces haber pausado el peg antes de que el hardware firmara la transacción o liberara BTC de la billetera de la federación, añadió.
El sistema de Liquid no reportó una Clave de Autorización de Peg-out robada. SideSwap dijo que un cliente envió 4,000 L-BTC a su servicio de peg-out, que manejó la solicitud bajo su proceso normal porque los tokens no podían distinguirse del L-BTC respaldado. La federación pagó 3,996 BTC a la dirección de Bitcoin proporcionada aproximadamente 23 minutos después.
La propuesta de Lerner colocaría un control adicional después de la primera etapa de validación. Incluso si el software aprobara erróneamente un retiro, el retraso evitaría que el BTC correspondiente saliera de inmediato.
Rootstock impone un retraso de 4,000 bloques para retiros de Bitcoin
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 hacen cumplir el período de espera.
El sistema se basa en módulos de seguridad de hardware especializados llamados PowHSM. Antes de firmar un peg-out, los dispositivos verifican de forma independiente que hayan pasado 4,000 bloques de Rootstock, lo que representa aproximadamente 36 horas de prueba de trabajo acumulada.
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 fusionada, mediante la cual los mineros de Bitcoin contribuyen con prueba de trabajo a la cadena lateral.
"Incluso una mayoría en colusión de pegnatories no puede robar los fondos, porque las claves privadas nunca salen de los PowHSM, y los HSM verifican de forma independiente que hayan transcurrido 4,000 bloques de Rootstock antes de firmar", dijo Lerner.
El modelo de Rootstock asume que la mayoría de la tasa de hash de Bitcoin que participa a través de la minería combinada y los funcionarios de la federación no trabajarán juntos para detener la red. Lerner dijo que los funcionarios comprometidos podrían interrumpir las operaciones de la paridad, creando un problema de vivacidad, pero las reglas del HSM les impedirían forzar un retiro anticipado no autorizado.
Cuando las herramientas de monitoreo identifican actividad sospechosa, los funcionarios pueden apagar sus HSM para que el retiro pendiente no reciba ninguna firma. Lerner describió la pausa como una forma de proteger el BTC subyacente mientras los operadores examinan el problema y deciden cómo proceder.
“Una mayoría en colusión puede, en el peor de los casos, detener la paridad, pero no puede forzar un retiro no autorizado”, dijo.
Los controles de revocación distribuidos podrían limitar los poderes de congelación
Detener un retiro pendiente introduce otro riesgo porque el mismo poder podría usarse para retrasar a usuarios legítimos. Lerner dijo que ninguna empresa, operador o administrador individual 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 ni 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.”
Tales controles aún permitirían que un grupo de funcionarios interrumpa los retiros si suficientes participantes actuaran juntos. La distinción de Lerner se basa en el alcance de esa autoridad: los operadores podrían retener temporalmente las firmas mientras se revisa una anomalía, pero no podrían crear una transacción válida que transfiera la garantía a sí mismos.
Los retrasos de tiempo 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 inadecuada para pagos rutinarios, mientras que un puente que mantiene grandes cantidades de BTC tiene un perfil de riesgo diferente.
Lerner dijo que los sistemas de liquidación de alto valor deberían tratar el tiempo como un control de seguridad, similar a los mecanismos de retraso utilizados por las bóvedas bancarias físicas. Los períodos de retiro podrían variar según el tamaño de la transacción o requerir diferentes umbrales acumulativos de prueba de trabajo según la garantía en riesgo.
Un período más corto podría aplicarse a transferencias más pequeñas, mientras que un retraso más largo podría dar a los sistemas automatizados y a los respondedores humanos más tiempo para inspeccionar una solicitud inusualmente grande. 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.
Las bóvedas nativas de Bitcoin podrían colocar salvaguardas en el consenso
La protección actual de Rootstock depende de sus HSM y de la federación en lugar de reglas aplicadas por la red Bitcoin. Lerner dijo 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 preliminar para un código de operación 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 transacciones futuras.
BIP-443 describe OP_CCV como un cambio de consenso que requiere un soft fork. Sus usos enumerados incluyen salidas de Bitcoin que transportan estado, cadenas laterales y estructuras de retiro en dos pasos que permiten seguridad reactiva. La propuesta permanece 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 a partes designadas tiempo para cancelar un retiro después de detectar credenciales robadas, software alterado u otro evento anormal.
Mover el mecanismo al consenso de Bitcoin reduciría la dependencia de políticas de HSM específicas del puente, según Lerner. Los mineros, funcionarios o administradores tendrían que seguir las condiciones de gasto adjuntas a la salida de Bitcoin en lugar de aplicar una pausa discrecional después de que los fondos ya se hubieran movido.
Para retiros grandes de puentes, Lerner dijo que el retraso debería durar lo suficiente para que las alertas automatizadas y los operadores humanos identifiquen el problema, detengan el procesamiento y examinen el software afectado antes de que el BTC se vuelva permanentemente gastable por el receptor.
