El 23 de abril de 2025, un usuario de Twitter llamado Brain pidió ayuda a través de un amigo, afirmando que más de 100,000 dólares en activos de unibtc quedaron atrapados y no podían ser retirados en una operación de arbitraje en una cadena Layer2 de Bitcoin, debido a Bedrock.
Según la divulgación de la parte involucrada W, el 17 de abril, descubrió que el unibtc emitido por Bedrock presentaba una anomalía de precios en una cadena L2 de Bitcoin y se desacoplaba de BTC. W cree que el desacoplamiento es temporal y que pronto volverá a anclarse, por lo que hay una buena oportunidad de arbitraje. Decidió transferir parte de su BTC a esa L2 de Bitcoin, intercambiarlo por unibtc y venderlo una vez que regresara a su anclaje.
Solo 24 horas después de la desvinculación, unibtc había vuelto a anclarse, pero cuando W intentó vender el unibtc que tenía, descubrió que el fondo de liquidez unibtc-BTC en esa cadena había sido retirado por los oficiales de Bedrock, y este token era el único canal de salida del mercado secundario unibtc en esa cadena. W no pudo deshacerse del unibtc que tenía, así que intentó transferir el unibtc a otras cadenas.
Cuando encontró el único puente entre cadenas en la cadena que soporta unibtc (llamado Free), recibió el aviso: “La transacción requiere la autorización de firma del proyecto”. W se puso en contacto con el servicio al cliente del puente Free, y del otro lado explicaron: “La clave multifirma para el cruce de unibtc está gestionada por Bedrock, sin su permiso, los usuarios no pueden llevar unibtc a otras cadenas.”
No hay manera, W solo puede contactar a las personas relacionadas con Bedrock para preguntar sobre este asunto. La respuesta preliminar fue: "Podemos permitirle retirar el capital, pero si puede retirar las ganancias generadas por el arbitraje, deberá ser revisado temporalmente."
Hasta este momento, W se dio cuenta de que la ruta de salida de unibtc en esta cadena estaba completamente cortada, y que los unibtc que tenía, con un valor de aproximadamente 200,000 U, estaban "temporalmente congelados" - no podía venderlos en esa cadena ni transferirlos a otras cadenas. En ese momento, se sintió muy impotente, solo deseando poder retirar su capital sin problemas.
Sin embargo, la actitud de las personas relacionadas con BedRock se volvió ambigua: no aclaran cuándo se puede retirar el capital, ni proporcionan ningún compromiso por escrito, utilizando razones como "revisión de riesgos" y "inspección técnica" para retrasar el proceso.
Después de una demora, BedRock afirmó que el desacoplamiento de unibtc se originó en la plataforma LayerBank, donde alguien tomó prestados activos unibtc a gran escala y realizó una venta masiva. Luego, la gente de BedRock sugirió a W que "responsabilizara a LayerBank". Sin embargo, W no recibió respuesta durante mucho tiempo después de contactar a LayerBank.
Sin otra opción, W tuvo que buscar ayuda de amigos en Twitter. Después de más de dos semanas de negociaciones, finalmente recibió una respuesta positiva de las oficinas de LayerBank y BedRock, logrando recuperar sus activos.
El encuentro de W no es un caso aislado. Según los comentarios de otros implicados, el año pasado BedRock también utilizó métodos similares para cortar la ruta de salida de los usuarios de unibtc, lo que llevó a que estos unibtc fueran "sustancialmente congelados". Por supuesto, este artículo no tiene la intención de especular sobre las razones detrás de los eventos mencionados, sino que se propone explicar desde un punto de vista técnico cómo evitar y erradicar comportamientos maliciosos centralizados similares.
Primero, al revisar el evento mencionado, podemos ver que BedRock, como emisor de unibtc y LP inicial del fondo de liquidez del mercado secundario, tiene naturalmente el derecho de acceso al canal de salida del mercado secundario de unibtc. Si se desea restringir su poder, esto debe hacerse más a través de la gobernanza que de medios técnicos.
Sin embargo, el asunto en el que el puente cross-chain Free y BedRock conspiraron para rechazar las solicitudes de los usuarios expone una clara deficiencia técnica en la etapa de "emisión - circulación en una sola cadena - circulación en múltiples cadenas" de unibtc: el puente cross-chain Free, como socio de BedRock, es claramente altamente centralizado.
Un puente verdaderamente Trustless debería garantizar que la autoridad del puente no pueda impedir que los usuarios salgan. Sin embargo, en el caso de congelación de unibtc, tanto BedRock como el puente cross-chain Free tienen poderosas autoridades centralizadas y no han proporcionado un canal de salida resistente a la censura.
Por supuesto, casos similares al de unibtc no son poco comunes, y cortar la ruta de salida de los usuarios es algo que se ve con frecuencia en los principales intercambios. Para los puentes entre cadenas o otros tipos de proyectos, tampoco faltan ejemplos de este tipo de acciones que utilizan permisos centralizados. En junio de 2022, el Harmony Horizon Bridge suspendió los canales de retiro de 57 activos debido a un ataque de hackers. Aunque esta acción tenía "razones justificadas", aún dejó a algunas personas sintiéndose inquietas.
Durante el evento StableMagnet de 2021, el equipo del proyecto robó 24 millones de dólares a través de una vulnerabilidad que habían reservado con anticipación. Finalmente, se movilizó una gran cantidad de fuerzas policiales en Hong Kong y el Reino Unido, y con la ayuda de la comunidad, se recuperó el 91% de los fondos robados. Estos casos demuestran claramente que si una plataforma de custodia de activos no puede ofrecer un servicio sin confianza, inevitablemente resultará en consecuencias negativas.
Sin embargo, el Trustless no es algo que se obtenga fácilmente; desde canales de pago y DLC hasta BitVM y ZK Rollup, la gente ha intentado diversas formas de implementación. Aunque se puede garantizar en gran medida la autonomía del usuario y proporcionar salidas confiables para la retirada de activos, aún existen defectos inevitables detrás de esto.
Por ejemplo, los canales de pago requieren que las partes monitoreen el comportamiento malicioso potencial de la contraparte, los DLC dependen de oráculos; mientras que BitVM tiene un alto costo y presenta otras suposiciones de confianza en la fase práctica; el módulo de escape de ZK Rollup debe pasar por un largo período de tiempo para activarse y necesita que el Rollup se detenga primero, lo que conlleva un costo muy alto.
A juzgar por la implementación actual de las principales soluciones técnicas, no existe un plan perfecto de custodia y salida de activos, y el mercado aún necesita innovar. A continuación, DeepSafe Research tomará como ejemplo la solución de custodia de activos lanzada oficialmente por DeepSafe para ilustrar un esquema de verificación de mensajes sin confianza que combina TEE con ZK y MPC, que equilibra el costo, la seguridad, la experiencia del usuario y otros indicadores que no pueden ser ambos, y puede proporcionar servicios subyacentes confiables para plataformas de negociación, puentes entre cadenas o escenarios de custodia de activos arbitrarios.
CRVA: Red de verificación aleatoria criptográfica
Las soluciones de gestión de activos más ampliamente utilizadas en el mercado actualmente suelen utilizar métodos de firma múltiple o MPC/TSS para determinar la validez de las solicitudes de transferencia de activos. La ventaja de este tipo de soluciones radica en su implementación sencilla, bajo costo y rápida velocidad de verificación de mensajes; sin embargo, las desventajas son evidentes: no son lo suficientemente seguras y tienden a ser centralizadas. En el caso de Multichain de 2023, los 21 nodos que participaron en el cálculo de MPC estaban controlados por una sola persona, lo que constituye un ataque típico de brujería. Este incidente es suficiente para demostrar que la mera apariencia de decenas de nodos no puede proporcionar una alta garantía de descentralización.
Para abordar las deficiencias de las soluciones tradicionales de gestión de activos MPC/TSS, la solución CRVA de DeepSafe ha realizado numerosas mejoras. En primer lugar, los nodos de la red CRVA adoptan una forma de acceso basada en la garantía de activos, y la red principal solo se activará oficialmente después de alcanzar aproximadamente 500 nodos. Según las estimaciones, los activos garantizados por estos nodos se mantendrán a largo plazo en decenas de millones de dólares o más.
En segundo lugar, para mejorar la eficiencia del cálculo MPC/TSS, CRVA seleccionará aleatoriamente nodos mediante un algoritmo de sorteo, por ejemplo, seleccionando 10 nodos cada media hora, que actuarán como validadores para verificar si las solicitudes de los usuarios deben ser aprobadas, y luego generarán la firma de umbral correspondiente para permitir el acceso. Para evitar conspiraciones internas o ataques de hackers externos, el algoritmo de sorteo de CRVA utiliza un VRF en anillo original, combinado con ZK para ocultar la identidad de los seleccionados, de modo que el exterior no pueda observar directamente a los elegidos.
Por supuesto, alcanzar solo este nivel no es suficiente. Aunque el mundo exterior no sabe quién ha sido seleccionado, en este momento, la persona seleccionada lo sabe, por lo que todavía existe un camino para la conspiración. Para eliminar aún más la conspiración, todos los nodos de CRVA deben ejecutar el código central en un entorno de hardware TEE, lo que equivale a realizar el trabajo central en una caja negra. De esta manera, nadie podrá saber si ha sido seleccionado, a menos que pueda romper el hardware confiable de TEE, lo cual, según las condiciones tecnológicas actuales, es muy difícil de lograr.
Lo que se mencionó anteriormente es la idea básica del esquema CRVA de DeepSafe. En el flujo de trabajo real, los nodos dentro de la red CRVA deben realizar una gran cantidad de comunicaciones por difusión e intercambio de información. El proceso específico es el siguiente:
Todos los nodos deben apostar activos en la cadena antes de ingresar a la red CRVA, dejando una clave pública como información de registro. Esta clave pública también se conoce como "clave pública permanente".
2.Cada hora, la red CRVA seleccionará aleatoriamente varios nodos. Pero antes de esto, todos los candidatos deben generar localmente una "clave pública temporal" de un solo uso, al mismo tiempo que generan ZKP, para demostrar que la "clave pública temporal" está relacionada con la "clave pública permanente" registrada en la cadena; en otras palabras, cada persona debe demostrar su existencia en la lista de candidatos a través de ZK, sin revelar quién es.
La función de la "clave pública temporal" radica en la protección de la privacidad. Si se realiza un sorteo directamente desde el conjunto de "claves públicas permanentes" y se publica el resultado, todos sabrán directamente quiénes han sido elegidos. Si solo se expone una "clave pública temporal" única, y luego se eligen a algunas personas del conjunto de "claves públicas temporales", tú solo sabrás si has ganado, pero no sabrás a quién corresponden las otras claves públicas temporales ganadoras.
Para prevenir aún más la filtración de identidad, CRVA planea que ni siquiera tú sepas cuál es tu "clave pública temporal". El proceso de generación de la clave pública temporal se lleva a cabo en el entorno TEE del nodo, y tú, que estás ejecutando el TEE, no puedes ver lo que está sucediendo en su interior.
Luego, dentro del TEE, se cifra el texto plano de la clave pública temporal como "caracteres basura" y se envía al exterior, solo nodos Relayer específicos pueden restaurarlo. Por supuesto, el proceso de restauración también se completa en el entorno TEE del nodo Relayer, y el Relayer no sabe a qué candidatos corresponden estas claves públicas temporales.
Después de que el Relayer restablezca todas las "claves públicas temporales", las agrupa y las envía a la función VRF en la cadena, de donde se seleccionan los ganadores. Estas personas verifican las solicitudes de transacción enviadas por el frontend del usuario y, según los resultados de la verificación, generan una firma umbral, que luego se envía a la cadena.
Puede que algunos se pregunten, ya que cada nodo no sabe si ha sido seleccionado, ¿cómo se lleva a cabo el trabajo? En realidad, como se mencionó anteriormente, cada persona generará una "clave pública temporal" en su entorno TEE local. Una vez que se obtenga el resultado del sorteo, simplemente transmitimos la lista. Cada persona solo necesita ingresar la lista en el TEE y verificar dentro de ella si ha sido seleccionada.
El núcleo de la solución DeepSafe radica en que casi todas las actividades importantes se llevan a cabo dentro del hardware TEE, de modo que no se puede observar lo que está sucediendo desde el exterior del TEE. Cada nodo no sabe quiénes son los validadores seleccionados, lo que previene la colusión maliciosa y aumenta considerablemente el costo de los ataques externos. Para atacar al comité CRVA basado en DeepSafe, teóricamente se debe atacar toda la red CRVA, además de que cada nodo tiene protección TEE, lo que dificulta enormemente el ataque.
Implementar el esquema de auto-custodia de activos de CRVA
Arriba hemos presentado el principio general de CRVA, aclarando cómo CRVA logra la descentralización sin confianza. A continuación, tomaremos como caso un stablecoin de algoritmo de Bitcoin llamado HelloBTU para aclarar aún más la forma en que CRVA se aplica en los esquemas de custodia de activos.
Como todos saben, debido a que la cadena de Bitcoin no cuenta con un entorno Turing completo, no es posible implementar directamente lógicas complejas de contratos inteligentes como DeFi, por lo que el BTCFi principal consiste en puentear Bitcoin a otras cadenas para interactuar con contratos inteligentes. La parte del contrato inteligente de HelloBTU está desplegada en Ethereum, los usuarios pueden depositar BTC en la dirección de recepción designada por HelloBTU, y luego el puente oficial de este último transfiere el BTC a la cadena de Ethereum, donde se puede interactuar con el contrato inteligente de estabilidad de HelloBTU.
Supongamos que el usuario desea bloquear 10 BTC en la plataforma HelloBTU. La operación específica es transferir primero 10 BTC a una dirección Taproot en la cadena de Bitcoin, donde se requiere un desbloqueo de 2/2 de firma múltiple, siendo una firma generada por el usuario y la otra por CRVA.
Las siguientes situaciones están involucradas:
Supongamos que 10 BTC se transfieren a la dirección Taproot mencionada anteriormente, el usuario utiliza estos 10 BTC para acuñar una stablecoin y ahora planea redimir activamente los BTC. En este momento, el usuario y el CRVA generan una firma cada uno, desbloqueando estos 10 BTC y transfiriéndolos de vuelta a la dirección del usuario. Si el CRVA no coopera con el usuario a largo plazo, una vez que el período de bloqueo de tiempo haya expirado, el usuario puede unilateralmente recuperar estos 10 BTC, esta función se llama "redención autónoma del usuario".
Otra situación es que el BTC del usuario como colateral ha sido liquidado, ahora debería cooperar con CRVA para transferir estos BTC y entregarlos al control del canal unidireccional de CRVA. Pero el usuario puede negarse a cooperar, en este caso, estos BTC quedan temporalmente atrapados, nadie puede acceder a ellos; una vez que pase el período de bloqueo temporal, este dinero puede ser transferido por CRVA, entrando en la dirección Taproot controlada por CRVA bajo ( canal unidireccional de CRVA );
Hay un detalle aquí, que es que el bloqueo temporal para que BTC entre en el canal unidireccional CRVA es más corto, mientras que el bloqueo temporal para el rescate autónomo por parte del usuario es más largo. En otras palabras, si CRVA y el usuario no pueden colaborar entre sí, estos BTC finalmente entrarían primero en el canal unidireccional CRVA. De esta manera, se puede limitar de manera efectiva el comportamiento de incumplimiento y fraude por parte de los usuarios.
En cuanto a la situación de CRVA actuando de manera maliciosa, dado que CRVA es un sistema de red de nodos que funciona de manera automatizada, siempre que el código que se utilizó para su inicio no contenga lógica maliciosa, no habrá casos en los que CRVA se niegue a colaborar con el usuario, por lo que se puede ignorar básicamente.
Si CRVA sufre una gran cantidad de paradas de nodos debido a fuerzas mayores como cortes de energía o inundaciones, los usuarios aún tienen una forma de retirar sus activos de manera segura según el proceso mencionado en el plan anterior. La suposición de confianza aquí radica en que confiamos en que CRVA es lo suficientemente descentralizado como para no actuar maliciosamente (la razón ya ha sido explicada anteriormente).
Si BTC se transfiere a un canal unidireccional de CRVA, a menudo indica que la posición de garantía en la cadena correspondiente ha sido liquidada, en este momento la propiedad real de BTC pertenece al liquidador. El liquidador puede iniciar una solicitud de retiro, que será revisada por CRVA, si es aprobada, CRVA generará una firma para él y transferirá la cantidad correspondiente de BTC al liquidador.
En este momento, si CRVA no responde durante un largo período, después de que expire el bloqueo de tiempo, estos BTC se transferirán a una dirección controlada por el DAO. Esta operación será activada por una firma múltiple, y el manejo posterior será resuelto por la gobernanza del DAO, el cual está compuesto por proyectos reconocidos, empresas de seguridad e instituciones de inversión, con el objetivo de prevenir que una única entidad actúe de manera maliciosa.
En resumen, hemos realizado una descripción general del plan de autogestión de activos de DeepSafe para Bitcoin, y en el caso de los activos ERC-20, el principio es similar, por lo que no se elaborará más al respecto. En cuanto al caso de congelación de unibtc mencionado anteriormente, si el puente de cadena cruzada unibtc utiliza el plan de autogestión CRVA, será difícil que el emisor de activos tenga el control total de la situación.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
1 me gusta
Recompensa
1
1
Compartir
Comentar
0/400
HaveSmallGoals
· 05-06 08:50
Recuerda que cualquier cosa que aproveche las vulnerabilidades del equipo detrás del proyecto tendrá un noventa por ciento de probabilidad de perder todo. Esto se llama aprovecharse de la situación. Si el problema de la vulnerabilidad se soluciona y te enriquece de forma accidental, tarde o temprano también perderás ese dinero.
Más de 100,000 dólares fueron bloqueados, lo que resalta la importancia de la custodia sin confianza a partir del evento de congelación de unibtc.
Autor original: Xianrang GodRealmX
El 23 de abril de 2025, un usuario de Twitter llamado Brain pidió ayuda a través de un amigo, afirmando que más de 100,000 dólares en activos de unibtc quedaron atrapados y no podían ser retirados en una operación de arbitraje en una cadena Layer2 de Bitcoin, debido a Bedrock.
Según la divulgación de la parte involucrada W, el 17 de abril, descubrió que el unibtc emitido por Bedrock presentaba una anomalía de precios en una cadena L2 de Bitcoin y se desacoplaba de BTC. W cree que el desacoplamiento es temporal y que pronto volverá a anclarse, por lo que hay una buena oportunidad de arbitraje. Decidió transferir parte de su BTC a esa L2 de Bitcoin, intercambiarlo por unibtc y venderlo una vez que regresara a su anclaje.
Solo 24 horas después de la desvinculación, unibtc había vuelto a anclarse, pero cuando W intentó vender el unibtc que tenía, descubrió que el fondo de liquidez unibtc-BTC en esa cadena había sido retirado por los oficiales de Bedrock, y este token era el único canal de salida del mercado secundario unibtc en esa cadena. W no pudo deshacerse del unibtc que tenía, así que intentó transferir el unibtc a otras cadenas.
Cuando encontró el único puente entre cadenas en la cadena que soporta unibtc (llamado Free), recibió el aviso: “La transacción requiere la autorización de firma del proyecto”. W se puso en contacto con el servicio al cliente del puente Free, y del otro lado explicaron: “La clave multifirma para el cruce de unibtc está gestionada por Bedrock, sin su permiso, los usuarios no pueden llevar unibtc a otras cadenas.”
No hay manera, W solo puede contactar a las personas relacionadas con Bedrock para preguntar sobre este asunto. La respuesta preliminar fue: "Podemos permitirle retirar el capital, pero si puede retirar las ganancias generadas por el arbitraje, deberá ser revisado temporalmente."
Hasta este momento, W se dio cuenta de que la ruta de salida de unibtc en esta cadena estaba completamente cortada, y que los unibtc que tenía, con un valor de aproximadamente 200,000 U, estaban "temporalmente congelados" - no podía venderlos en esa cadena ni transferirlos a otras cadenas. En ese momento, se sintió muy impotente, solo deseando poder retirar su capital sin problemas.
Sin embargo, la actitud de las personas relacionadas con BedRock se volvió ambigua: no aclaran cuándo se puede retirar el capital, ni proporcionan ningún compromiso por escrito, utilizando razones como "revisión de riesgos" y "inspección técnica" para retrasar el proceso.
Después de una demora, BedRock afirmó que el desacoplamiento de unibtc se originó en la plataforma LayerBank, donde alguien tomó prestados activos unibtc a gran escala y realizó una venta masiva. Luego, la gente de BedRock sugirió a W que "responsabilizara a LayerBank". Sin embargo, W no recibió respuesta durante mucho tiempo después de contactar a LayerBank.
Sin otra opción, W tuvo que buscar ayuda de amigos en Twitter. Después de más de dos semanas de negociaciones, finalmente recibió una respuesta positiva de las oficinas de LayerBank y BedRock, logrando recuperar sus activos.
El encuentro de W no es un caso aislado. Según los comentarios de otros implicados, el año pasado BedRock también utilizó métodos similares para cortar la ruta de salida de los usuarios de unibtc, lo que llevó a que estos unibtc fueran "sustancialmente congelados". Por supuesto, este artículo no tiene la intención de especular sobre las razones detrás de los eventos mencionados, sino que se propone explicar desde un punto de vista técnico cómo evitar y erradicar comportamientos maliciosos centralizados similares.
Primero, al revisar el evento mencionado, podemos ver que BedRock, como emisor de unibtc y LP inicial del fondo de liquidez del mercado secundario, tiene naturalmente el derecho de acceso al canal de salida del mercado secundario de unibtc. Si se desea restringir su poder, esto debe hacerse más a través de la gobernanza que de medios técnicos.
Sin embargo, el asunto en el que el puente cross-chain Free y BedRock conspiraron para rechazar las solicitudes de los usuarios expone una clara deficiencia técnica en la etapa de "emisión - circulación en una sola cadena - circulación en múltiples cadenas" de unibtc: el puente cross-chain Free, como socio de BedRock, es claramente altamente centralizado.
Un puente verdaderamente Trustless debería garantizar que la autoridad del puente no pueda impedir que los usuarios salgan. Sin embargo, en el caso de congelación de unibtc, tanto BedRock como el puente cross-chain Free tienen poderosas autoridades centralizadas y no han proporcionado un canal de salida resistente a la censura.
Por supuesto, casos similares al de unibtc no son poco comunes, y cortar la ruta de salida de los usuarios es algo que se ve con frecuencia en los principales intercambios. Para los puentes entre cadenas o otros tipos de proyectos, tampoco faltan ejemplos de este tipo de acciones que utilizan permisos centralizados. En junio de 2022, el Harmony Horizon Bridge suspendió los canales de retiro de 57 activos debido a un ataque de hackers. Aunque esta acción tenía "razones justificadas", aún dejó a algunas personas sintiéndose inquietas.
Durante el evento StableMagnet de 2021, el equipo del proyecto robó 24 millones de dólares a través de una vulnerabilidad que habían reservado con anticipación. Finalmente, se movilizó una gran cantidad de fuerzas policiales en Hong Kong y el Reino Unido, y con la ayuda de la comunidad, se recuperó el 91% de los fondos robados. Estos casos demuestran claramente que si una plataforma de custodia de activos no puede ofrecer un servicio sin confianza, inevitablemente resultará en consecuencias negativas.
Sin embargo, el Trustless no es algo que se obtenga fácilmente; desde canales de pago y DLC hasta BitVM y ZK Rollup, la gente ha intentado diversas formas de implementación. Aunque se puede garantizar en gran medida la autonomía del usuario y proporcionar salidas confiables para la retirada de activos, aún existen defectos inevitables detrás de esto.
Por ejemplo, los canales de pago requieren que las partes monitoreen el comportamiento malicioso potencial de la contraparte, los DLC dependen de oráculos; mientras que BitVM tiene un alto costo y presenta otras suposiciones de confianza en la fase práctica; el módulo de escape de ZK Rollup debe pasar por un largo período de tiempo para activarse y necesita que el Rollup se detenga primero, lo que conlleva un costo muy alto.
A juzgar por la implementación actual de las principales soluciones técnicas, no existe un plan perfecto de custodia y salida de activos, y el mercado aún necesita innovar. A continuación, DeepSafe Research tomará como ejemplo la solución de custodia de activos lanzada oficialmente por DeepSafe para ilustrar un esquema de verificación de mensajes sin confianza que combina TEE con ZK y MPC, que equilibra el costo, la seguridad, la experiencia del usuario y otros indicadores que no pueden ser ambos, y puede proporcionar servicios subyacentes confiables para plataformas de negociación, puentes entre cadenas o escenarios de custodia de activos arbitrarios.
CRVA: Red de verificación aleatoria criptográfica
Las soluciones de gestión de activos más ampliamente utilizadas en el mercado actualmente suelen utilizar métodos de firma múltiple o MPC/TSS para determinar la validez de las solicitudes de transferencia de activos. La ventaja de este tipo de soluciones radica en su implementación sencilla, bajo costo y rápida velocidad de verificación de mensajes; sin embargo, las desventajas son evidentes: no son lo suficientemente seguras y tienden a ser centralizadas. En el caso de Multichain de 2023, los 21 nodos que participaron en el cálculo de MPC estaban controlados por una sola persona, lo que constituye un ataque típico de brujería. Este incidente es suficiente para demostrar que la mera apariencia de decenas de nodos no puede proporcionar una alta garantía de descentralización.
Para abordar las deficiencias de las soluciones tradicionales de gestión de activos MPC/TSS, la solución CRVA de DeepSafe ha realizado numerosas mejoras. En primer lugar, los nodos de la red CRVA adoptan una forma de acceso basada en la garantía de activos, y la red principal solo se activará oficialmente después de alcanzar aproximadamente 500 nodos. Según las estimaciones, los activos garantizados por estos nodos se mantendrán a largo plazo en decenas de millones de dólares o más.
En segundo lugar, para mejorar la eficiencia del cálculo MPC/TSS, CRVA seleccionará aleatoriamente nodos mediante un algoritmo de sorteo, por ejemplo, seleccionando 10 nodos cada media hora, que actuarán como validadores para verificar si las solicitudes de los usuarios deben ser aprobadas, y luego generarán la firma de umbral correspondiente para permitir el acceso. Para evitar conspiraciones internas o ataques de hackers externos, el algoritmo de sorteo de CRVA utiliza un VRF en anillo original, combinado con ZK para ocultar la identidad de los seleccionados, de modo que el exterior no pueda observar directamente a los elegidos.
Por supuesto, alcanzar solo este nivel no es suficiente. Aunque el mundo exterior no sabe quién ha sido seleccionado, en este momento, la persona seleccionada lo sabe, por lo que todavía existe un camino para la conspiración. Para eliminar aún más la conspiración, todos los nodos de CRVA deben ejecutar el código central en un entorno de hardware TEE, lo que equivale a realizar el trabajo central en una caja negra. De esta manera, nadie podrá saber si ha sido seleccionado, a menos que pueda romper el hardware confiable de TEE, lo cual, según las condiciones tecnológicas actuales, es muy difícil de lograr.
Lo que se mencionó anteriormente es la idea básica del esquema CRVA de DeepSafe. En el flujo de trabajo real, los nodos dentro de la red CRVA deben realizar una gran cantidad de comunicaciones por difusión e intercambio de información. El proceso específico es el siguiente:
2.Cada hora, la red CRVA seleccionará aleatoriamente varios nodos. Pero antes de esto, todos los candidatos deben generar localmente una "clave pública temporal" de un solo uso, al mismo tiempo que generan ZKP, para demostrar que la "clave pública temporal" está relacionada con la "clave pública permanente" registrada en la cadena; en otras palabras, cada persona debe demostrar su existencia en la lista de candidatos a través de ZK, sin revelar quién es.
La función de la "clave pública temporal" radica en la protección de la privacidad. Si se realiza un sorteo directamente desde el conjunto de "claves públicas permanentes" y se publica el resultado, todos sabrán directamente quiénes han sido elegidos. Si solo se expone una "clave pública temporal" única, y luego se eligen a algunas personas del conjunto de "claves públicas temporales", tú solo sabrás si has ganado, pero no sabrás a quién corresponden las otras claves públicas temporales ganadoras.
Para prevenir aún más la filtración de identidad, CRVA planea que ni siquiera tú sepas cuál es tu "clave pública temporal". El proceso de generación de la clave pública temporal se lleva a cabo en el entorno TEE del nodo, y tú, que estás ejecutando el TEE, no puedes ver lo que está sucediendo en su interior.
Luego, dentro del TEE, se cifra el texto plano de la clave pública temporal como "caracteres basura" y se envía al exterior, solo nodos Relayer específicos pueden restaurarlo. Por supuesto, el proceso de restauración también se completa en el entorno TEE del nodo Relayer, y el Relayer no sabe a qué candidatos corresponden estas claves públicas temporales.
Después de que el Relayer restablezca todas las "claves públicas temporales", las agrupa y las envía a la función VRF en la cadena, de donde se seleccionan los ganadores. Estas personas verifican las solicitudes de transacción enviadas por el frontend del usuario y, según los resultados de la verificación, generan una firma umbral, que luego se envía a la cadena.
Puede que algunos se pregunten, ya que cada nodo no sabe si ha sido seleccionado, ¿cómo se lleva a cabo el trabajo? En realidad, como se mencionó anteriormente, cada persona generará una "clave pública temporal" en su entorno TEE local. Una vez que se obtenga el resultado del sorteo, simplemente transmitimos la lista. Cada persona solo necesita ingresar la lista en el TEE y verificar dentro de ella si ha sido seleccionada.
El núcleo de la solución DeepSafe radica en que casi todas las actividades importantes se llevan a cabo dentro del hardware TEE, de modo que no se puede observar lo que está sucediendo desde el exterior del TEE. Cada nodo no sabe quiénes son los validadores seleccionados, lo que previene la colusión maliciosa y aumenta considerablemente el costo de los ataques externos. Para atacar al comité CRVA basado en DeepSafe, teóricamente se debe atacar toda la red CRVA, además de que cada nodo tiene protección TEE, lo que dificulta enormemente el ataque.
Implementar el esquema de auto-custodia de activos de CRVA
Arriba hemos presentado el principio general de CRVA, aclarando cómo CRVA logra la descentralización sin confianza. A continuación, tomaremos como caso un stablecoin de algoritmo de Bitcoin llamado HelloBTU para aclarar aún más la forma en que CRVA se aplica en los esquemas de custodia de activos.
Como todos saben, debido a que la cadena de Bitcoin no cuenta con un entorno Turing completo, no es posible implementar directamente lógicas complejas de contratos inteligentes como DeFi, por lo que el BTCFi principal consiste en puentear Bitcoin a otras cadenas para interactuar con contratos inteligentes. La parte del contrato inteligente de HelloBTU está desplegada en Ethereum, los usuarios pueden depositar BTC en la dirección de recepción designada por HelloBTU, y luego el puente oficial de este último transfiere el BTC a la cadena de Ethereum, donde se puede interactuar con el contrato inteligente de estabilidad de HelloBTU.
Supongamos que el usuario desea bloquear 10 BTC en la plataforma HelloBTU. La operación específica es transferir primero 10 BTC a una dirección Taproot en la cadena de Bitcoin, donde se requiere un desbloqueo de 2/2 de firma múltiple, siendo una firma generada por el usuario y la otra por CRVA.
Las siguientes situaciones están involucradas:
Supongamos que 10 BTC se transfieren a la dirección Taproot mencionada anteriormente, el usuario utiliza estos 10 BTC para acuñar una stablecoin y ahora planea redimir activamente los BTC. En este momento, el usuario y el CRVA generan una firma cada uno, desbloqueando estos 10 BTC y transfiriéndolos de vuelta a la dirección del usuario. Si el CRVA no coopera con el usuario a largo plazo, una vez que el período de bloqueo de tiempo haya expirado, el usuario puede unilateralmente recuperar estos 10 BTC, esta función se llama "redención autónoma del usuario".
Otra situación es que el BTC del usuario como colateral ha sido liquidado, ahora debería cooperar con CRVA para transferir estos BTC y entregarlos al control del canal unidireccional de CRVA. Pero el usuario puede negarse a cooperar, en este caso, estos BTC quedan temporalmente atrapados, nadie puede acceder a ellos; una vez que pase el período de bloqueo temporal, este dinero puede ser transferido por CRVA, entrando en la dirección Taproot controlada por CRVA bajo ( canal unidireccional de CRVA );
Hay un detalle aquí, que es que el bloqueo temporal para que BTC entre en el canal unidireccional CRVA es más corto, mientras que el bloqueo temporal para el rescate autónomo por parte del usuario es más largo. En otras palabras, si CRVA y el usuario no pueden colaborar entre sí, estos BTC finalmente entrarían primero en el canal unidireccional CRVA. De esta manera, se puede limitar de manera efectiva el comportamiento de incumplimiento y fraude por parte de los usuarios.
En cuanto a la situación de CRVA actuando de manera maliciosa, dado que CRVA es un sistema de red de nodos que funciona de manera automatizada, siempre que el código que se utilizó para su inicio no contenga lógica maliciosa, no habrá casos en los que CRVA se niegue a colaborar con el usuario, por lo que se puede ignorar básicamente.
Si CRVA sufre una gran cantidad de paradas de nodos debido a fuerzas mayores como cortes de energía o inundaciones, los usuarios aún tienen una forma de retirar sus activos de manera segura según el proceso mencionado en el plan anterior. La suposición de confianza aquí radica en que confiamos en que CRVA es lo suficientemente descentralizado como para no actuar maliciosamente (la razón ya ha sido explicada anteriormente).
Si BTC se transfiere a un canal unidireccional de CRVA, a menudo indica que la posición de garantía en la cadena correspondiente ha sido liquidada, en este momento la propiedad real de BTC pertenece al liquidador. El liquidador puede iniciar una solicitud de retiro, que será revisada por CRVA, si es aprobada, CRVA generará una firma para él y transferirá la cantidad correspondiente de BTC al liquidador.
En este momento, si CRVA no responde durante un largo período, después de que expire el bloqueo de tiempo, estos BTC se transferirán a una dirección controlada por el DAO. Esta operación será activada por una firma múltiple, y el manejo posterior será resuelto por la gobernanza del DAO, el cual está compuesto por proyectos reconocidos, empresas de seguridad e instituciones de inversión, con el objetivo de prevenir que una única entidad actúe de manera maliciosa.
En resumen, hemos realizado una descripción general del plan de autogestión de activos de DeepSafe para Bitcoin, y en el caso de los activos ERC-20, el principio es similar, por lo que no se elaborará más al respecto. En cuanto al caso de congelación de unibtc mencionado anteriormente, si el puente de cadena cruzada unibtc utiliza el plan de autogestión CRVA, será difícil que el emisor de activos tenga el control total de la situación.
Si el problema de la vulnerabilidad se soluciona y te enriquece de forma accidental, tarde o temprano también perderás ese dinero.