Fuente original: DeepSafe Research
El 23 de abril de 2025, un usuario de Internet llamado Brain pidió ayuda en Twitter a través de un amigo, afirmando que más de $100,000 en activos de unibtc estaban atrapados debido a la intervención de funcionarios de Bedrock, y no podían ser retirados. Según la divulgación del partido W, el 17 de abril se detectó que el precio de unibtc, emitido por Bedrock en una cadena Layer 2 de Bitcoin, era anómalo y se había desacoplado de BTC. W creía que esta desconexión sería temporal y volvería a anclarse pronto, así que decidió transferir parte de su BTC a la Layer 2, cambiarlo por unibtc y venderlo cuando regresara al anclaje.
En las 24 horas siguientes al desacoplamiento, unibtc efectivamente recuperó su anclaje, pero al intentar vender su unibtc, W se dio cuenta de que el pool de liquidez unibtc-BTC en la cadena había sido eliminado por funcionarios de Bedrock; este token era el único canal de salida del mercado secundario para unibtc en dicha cadena. W, al no poder vender su unibtc, intentó transferirlo a otras cadenas. Cuando localizó el único puente cross-chain (denominado Free) que admitía unibtc, recibió un aviso que decía: «La transacción requiere autorización de firma por parte del proyecto.» W se puso en contacto con el servicio de atención al cliente de Free, quien le explicó: «La clave de múltiples firmas del puente cross-chain de unibtc está bajo el control de Bedrock. Sin su permiso, los usuarios no pueden transferir unibtc a otras cadenas.»
Sin opciones, W se vio obligado a buscar a un empleado de Bedrock para preguntar sobre su situación. La respuesta inicial del empleado fue: «Podemos permitirle retirar su capital, pero la autorización para retirar el beneficio generado por el arbitraje aún está en revisión.» En este punto, W comprendió que su salida de unibtc estaba completamente cortada, y los unibtc que poseía, por un valor de aproximadamente $200,000, estaban «temporalmente congelados»; no había forma de venderlos en esa cadena ni de transferirlos a otras. Se sintió impotente y su principal deseo era retirar su capital sin complicaciones. Sin embargo, la actitud del personal de Bedrock fue ambigua: no aclararon cuándo podría W retirar su capital ni proporcionaron un compromiso por escrito, mientras retrasaban el proceso con excusas como «revisión de riesgos» e «investigación técnica».
Luego de un tiempo, Bedrock declaró que el desacoplamiento de unibtc fue causado por una entidad en la plataforma LayerBank que tomó prestados grandes montos de activos unibtc, lo que hundió el mercado. Bedrock sugirió a W que «llevara a LayerBank a los tribunales». Tras buscar en LayerBank, W no obtuvo respuesta durante un tiempo considerable. Desesperado, recurrió a sus amigos en Twitter. Después de más de dos semanas de negociaciones, logró obtener una respuesta positiva de LayerBank y recuperó con éxito sus activos.
La experiencia de W no es un caso aislado. Otros testimonios revelan que Bedrock utilizó tácticas similares el año pasado para cortar las vías de salida de los usuarios de unibtc, resultando en que estos activos estuvieran «sustancialmente congelados». Este artículo no pretende especular sobre las causas del incidente mencionado, sino que busca explicar desde una perspectiva técnica cómo evitar y mitigar comportamientos centralizados similares.
La posición de Bedrock y las limitaciones del sistema
Primero, al revisar eventos pasados, observamos que Bedrock, como emisor de unibtc y proveedor inicial de liquidez para el mercado secundario, tiene naturalmente la autoridad para intervenir en su circulación. Si su poder debe ser restringido, debería hacerse a través de Mecanismos de gobernanza, no por medios técnicos. Sin embargo, la colusión entre el puente Free Cross-Chain y Bedrock al rechazar las solicitudes de los usuarios expone los fallos técnicos evidentes de unibtc en el vínculo de «emisión – circulación en una sola cadena – circulación en múltiples cadenas». El Free Cross-Chain Bridge, como socio de Bedrock, es claramente altamente centralizado.
Un puente verdaderamente sin confianza debería garantizar que las autoridades del mismo no puedan impedir que los usuarios se retiren. Lamentablemente, en el caso de la congelación de unibtc, tanto Bedrock como los Free Cross-Chain Bridges tienen una fuerte autoridad central y no proporcionan vías de salida resistentes a la censura. Por supuesto, casos como el de unibtc no son raros. El bloqueo del acceso a los usuarios es común en las principales plataformas de intercambio y también se observa en puentes cross-chain y otros tipos de proyectos, que presentan numerosos antecedentes de uso de autoridad centralizada. En junio de 2022, Harmony Horizon Bridge suspendió los canales de retiro de 57 activos debido a un ataque hacker. Este comportamiento, aunque justificado, puede resultar aterrador; en el incidente de StableMagnet de 2021, el propietario del proyecto robó $24 millones a través de una vulnerabilidad en un programa preestablecido.
Al final, Hong Kong y el Reino Unido desplegaron numerosos recursos policiales y recuperaron el 91% del dinero robado con la colaboración de la comunidad. Todos estos casos ilustran claramente que si una plataforma de custodia de activos no puede ofrecer servicios sin confianza, inevitablemente llevará a consecuencias adversas. Sin embargo, la confianza sin confianza no está fácilmente disponible. Desde canales de pago y DLC hasta BitVM y ZK Rollup, se han explorado diversos métodos de implementación.
Propuesta de solución de DeepSafe
A continuación, DeepSafe Research presentará la solución de custodia de activos lanzada oficialmente por DeepSafe como ejemplo para explicar una solución de verificación de mensajes sin confianza que combina TEE, ZK y MPC. Esta solución busca equilibrar indicadores incompatibles como costo, seguridad y experiencia del usuario, y puede ofrecer servicios subyacentes de confianza para plataformas de comercio, puentes cross-chain o cualquier escenario de custodia de activos.
CRVA: Red de Verificación Aleatoria Criptográfica
Actualmente, la mayoría de las soluciones de gestión de activos más utilizadas en el mercado aplican principalmente múltiples firmas o MPC/TSS para determinar la validez de las solicitudes de transferencia de activos. Las ventajas de esta solución son su implementación sencilla, bajo costo y rápida verificación de mensajes. Sin embargo, sus desventajas son evidentes: no son suficientemente seguras y tienden a centralizarse. En el caso de Multichain en 2023, todos los 21 nodos que participaron en el cálculo de MPC estaban controlados por una única entidad, lo que constituye un ataque típico de brujería. Esto es suficiente para demostrar que un reducido número de nodos en apariencia no puede ofrecer un alto grado de descentralización.
Ante las deficiencias de las soluciones tradicionales de gestión de activos MPC/TSS, la solución CRVA de DeepSafe ha realizado diversas mejoras. Primero, los nodos de la red CRVA adopten una forma de promesa de acceso a activos; la red principal no se lanzará oficialmente hasta alcanzar alrededor de 500 nodos. Según estimaciones, los activos prometidos por estos nodos se mantendrán en decenas de millones de dólares o más durante un largo período.
En segundo lugar, para mejorar la eficiencia de los cálculos MPC/TSS, CRVA seleccionará nodos aleatoriamente a través de un algoritmo de lotería, siendo seleccionados 10 nodos cada media hora, que actuarán como validadores para verificar si una solicitud de usuario debe ser aprobada, tras lo cual generarán la firma correspondiente. Para prevenir la colusión interna o ataques de hackers externos, el algoritmo de lotería de CRVA utiliza un anillo VRF combinado con ZK para ocultar la identidad de los seleccionados, impidiendo que el mundo externo observe directamente quién ha sido elegido.
Por supuesto, esto no es suficiente. Aunque el mundo exterior no sabe quién ha sido seleccionado, el propio seleccionado sí lo sabe, lo que aún deja espacio para colusión. Para mitigar aún más la colusión, todos los nodos de CRVA deben ejecutar el código central en un entorno de hardware TEE, lo que equivale a poner el núcleo de trabajo en una caja negra. De esta manera, nadie puede saber si ha sido seleccionado a menos que logre vulnerar el hardware confiable TEE, tarea que es extremadamente difícil de llevar a cabo con la tecnología actual.
Lo anterior es la idea básica de la solución CRVA de DeepSafe. En el flujo de trabajo real, se requiere una amplia comunicación y intercambio de información entre los nodos de la red CRVA. El proceso específico es el siguiente:
- Antes de ingresar a la red CRVA, todos los nodos deben prometer activos en la cadena y dejar una clave pública como información de registro, también conocida como «clave pública permanente».
- Cada hora, la red CRVA seleccionará al azar varios nodos. No obstante, antes de esto, todos los candidatos deben generar una clave pública «temporal» de un solo uso de forma local, y también generar un ZKP que demuestre que la «clave pública temporal» está asociada con la «clave pública permanente» registrada en la cadena.
- El propósito de las «claves públicas temporales» es proteger la privacidad. Si se extraen directamente del conjunto de «claves públicas permanentes», todos sabrán quién ha sido elegido al anunciar los resultados. Si todos solo exponen una clave pública «temporal» de un solo uso y luego se seleccionan algunas del conjunto de «claves públicas temporales», al máximo sabrás que has ganado la lotería, pero no sabrás a quién pertenecen las demás claves públicas ganadoras.
- Para prevenir aún más la filtración de identidad, CRVA busca ocultar tu «clave pública temporal». El proceso de generación de esta clave se realiza en el entorno TEE del nodo, y quienes operan el TEE no pueden ver lo que sucede dentro.
- A continuación, la clave pública temporal se cifra en texto claro mediante un «código confuso» en TEE y se envía al mundo exterior. Solo un nodo Relayer específico puede restaurarla. Este proceso también se lleva a cabo en el entorno TEE del nodo Relayer, que no sabe a qué candidatos corresponden estas claves públicas.
- Después de que el Relayer restaure todas las «claves públicas temporales», las reúne y las presenta a la función VRF en la cadena, donde se seleccionan los ganadores. Estas personas verifican la solicitud de transacción enviada por la interfaz de usuario, generando una firma de umbral basada en el resultado de la verificación para enviarla finalmente a la cadena. (Es importante señalar que el Relayer también está oculto y es seleccionado periódicamente).
Algunas personas podrían preguntar, dado que cada nodo no sabe si ha sido seleccionado, ¿cómo llevarán a cabo el trabajo? En realidad, como se mencionó anteriormente, todos generarán una «clave pública temporal» en el entorno TEE local. Posteriormente, tras la selección de los resultados de la lotería, se difunde la lista completa directamente. Todos solo necesitan pasar dicha lista al TEE y verificar si han sido seleccionados. El núcleo de DeepSafe es que la mayoría de las actividades importantes se realizan en el hardware TEE, lo que hace que lo que sucede no pueda ser observado desde fuera de dicho entorno. Cada nodo no sabe quiénes son los validadores seleccionados, lo que previene la colusión y eleva considerablemente el costo de ataques externos.
Aplicación en soluciones de custodia de activos
Combinado con la solución de auto-custodia de activos de CRVA, hemos introducido los principios generales de esta tecnología y explicado cómo CRVA puede lograr tanto descentralización como confianza. Ahora utilizaremos la stablecoin algorítmica de Bitcoin llamada HelloBTU como ejemplo para ilustrar aún más la aplicación de CRVA en soluciones de custodia de activos.
Como es ampliamente conocido, dado que la cadena de Bitcoin no dispone de un entorno Turing-completo, no es posible implementar directamente lógica de contrato inteligente compleja como en DeFi; por lo tanto, el principal enfoque de BTCFi consiste en puentear Bitcoin a otras cadenas y luego interactuar con contratos inteligentes. La parte del contrato inteligente de HelloBTU se despliega en Ethereum. Los usuarios pueden depositar BTC en la dirección de pago especificada por HelloBTU, y luego el puente oficial transferirá BTC a la cadena de Ethereum y así interactuará con el contrato inteligente de HelloBTU.
Supongamos que un usuario desea prometer 10 BTC a la plataforma HelloBTU. La operación específica consiste en transferir esos 10 BTC a una dirección Taproot en la cadena de Bitcoin. El desbloqueo correspondiente requerirá 2 de 2 múltiples firmas, una generada por el usuario y otra por CRVA. Aquí se presentan varias situaciones:
- Supongamos que, una vez que los 10 BTC se transfieran a la dirección Taproot, el usuario acuña stablecoins con esos 10 BTC y ahora desea redimir los BTC. En este caso, tanto el usuario como CRVA generan cada uno una firma para desbloquear los 10 BTC y transferirlos de vuelta a la dirección del usuario. Si CRVA no coopera con el usuario durante un periodo prolongado, una vez que expira la ventana de bloqueo temporal, el usuario puede recuperar unilateralmente los 10 BTC. Esta función se denomina «redención iniciada por el usuario».
- Otra situación es que el BTC del usuario utilizado como garantía ha sido liquidado; en este caso, deberá cooperar con CRVA para transferir estos BTC a la canal unidireccional de CRVA. No obstante, si el usuario se niega a colaborar, esos BTC quedarán temporalmente atrapados y nadie podrá acceder a ellos. Tras la expiración de la ventana de bloqueo, esos fondos pueden ser transferidos por CRVA a la dirección Taproot controlada por CRVA (canal unidireccional de CRVA); cabe destacar que la ventana de bloqueo para que BTC ingrese en el canal unidireccional de CRVA es relativamente corta, mientras que la ventana de bloqueo que permite a los usuarios redimir los fondos es más prolongada. En otros términos, si CRVA y los usuarios no pueden cooperar, esos BTC finalmente ingresarán primero al canal unidireccional de CRVA. Así, el comportamiento de los usuarios que incumplen sus deudas y actúan de manera inadecuada puede ser restringido de forma eficaz.
En cuanto a los posibles comportamientos maliciosos de CRVA, hay que recordar que dado que CRVA es un sistema de nodos de operación automática, siempre que el código inicial no contenga lógica maliciosa, CRVA no rechazará activamente la cooperación con los usuarios, por lo que se puede desestimar. Si los nodos CRVA se desconectan debido a razones ajenas a su control, como cortes de energía o inundaciones, los usuarios aún podrán retirar sus activos de manera segura siguiendo el proceso descrito anteriormente. La suposición de confianza aquí es que confiamos en que CRVA es lo suficientemente descentralizada y no tomará la iniciativa de actuar de manera maliciosa (como se ha explicado completamente anteriormente).
Si los BTC se transfieren al canal unidireccional de CRVA, a menudo significa que la correspondiente posición estable en la cadena ha sido liquidada, y la propiedad real de esos BTC son del liquidator. Este último puede iniciar una solicitud de retiro, la cual será revisada por CRVA. Si es aprobada, CRVA generará una firma para ello y transferirá el monto correspondiente de BTC al liquidator. En este punto, si CRVA no responde durante un tiempo prolongado, tras la expiración del tiempo de bloqueo, esos BTC se transferirán a la dirección controlada por el DAO. Esta operación se activa mediante múltiples firmas, siendo el procesamiento posterior resuelto a través de la gobernanza del DAO, compuesto por partes del proyecto, empresas de seguridad e instituciones de inversión, con el objetivo de prevenir las malas acciones de una sola entidad.
En resumen, hemos proporcionado una explicación de la solución de auto-custodia de DeepSafe para los activos de Bitcoin. En el caso de los activos ERC-20, los principios son similares y no se detallarán aquí. Con respecto al caso de congelación de unibtc mencionado anteriormente, si el puente cross-chain de unibtc hubiera implementado la solución de auto-custodia CRVA, habría sido difícil para el emisor del activo controlar de forma unilateral la situación en general.
