Comparativa de soluciones de gestión de activos Web3: multifirma, MPC y CRVA

Escrito por: Shew, Xianrang

En el mundo de Web3, la gestión de claves privadas es un asunto de vida o muerte; una vez que la clave privada de la billetera es robada o perdida, millones de dólares en activos pueden desaparecer en un instante. Sin embargo, la gran mayoría de las personas se acostumbran a utilizar una gestión de claves privadas de un solo punto, lo que es como poner todos los huevos en una sola canasta, ya que en cualquier momento se pueden perder todos los activos debido a un enlace de pesca.

Para hacer frente a este problema, en el campo de la blockchain han surgido diversas soluciones. Desde wallets multisig hasta MPC, y el CRVA propuesto por el equipo del proyecto DeepSafe, cada avance tecnológico abre nuevos caminos para la gestión de activos. Este artículo explorará los principios, características y escenarios de aplicación de estas tres soluciones de gestión de activos, ayudando a los lectores a elegir el camino que mejor se adapte a sus necesidades.

Cartera multi-firma: aceptable, pero no excelente

La idea de la billetera multifirma proviene de una sabiduría sencilla: no concentres todos los permisos en un solo lugar. Este pensamiento ya se ha aplicado ampliamente en la realidad, como en la separación de poderes y en las votaciones del consejo de administración.

De manera similar, en Web3, las carteras multi-firma crean múltiples claves independientes para diversificar el riesgo. El modelo más común es el de “M-de-N”; por ejemplo, en una configuración de “2-de-3”, el sistema genera un total de tres claves privadas, pero solo se requiere que cualquiera de las dos claves privadas genere una firma para permitir que la cuenta designada ejecute la transacción.

Este diseño ofrece cierta capacidad de tolerancia a fallos: incluso si se pierde una de las claves privadas, los activos siguen siendo seguros y controlables. Si tienes varios dispositivos independientes para almacenar las claves, un esquema de firma múltiple será más confiable.

En general, las carteras multi-firma se dividen técnicamente en dos categorías: una es la multi-firma convencional, que generalmente utiliza contratos inteligentes en la cadena o componentes de soporte en la capa base de la cadena pública para implementarse, y a menudo no depende de herramientas criptográficas específicas. La otra es la cartera multi-firma que depende de algoritmos criptográficos especiales, cuya seguridad depende del algoritmo específico, y a veces puede funcionar completamente sin la participación de contratos en la cadena. A continuación, discutiremos respectivamente las dos soluciones.

El esquema de multi-firma estándar representa: Billetera Safe y Bitcoin Taproot

Safe Wallet, como una de las soluciones multifirma más populares en la actualidad, implementa firmas múltiples utilizando contratos inteligentes de Solidity convencionales. En la arquitectura de Safe Wallet, cada participante multifirma controla una clave independiente, y el contrato inteligente en la cadena actúa como “árbitro”, permitiendo que el contrato apruebe la ejecución de transacciones en la cuenta asociada multifirma solo cuando se recopilan suficientes firmas válidas.

La ventaja de este método radica en la transparencia y la verificabilidad; todas las reglas de múltiples firmas están claramente codificadas en el contrato inteligente, y cualquier persona puede auditar la lógica del código. Además, los usuarios pueden agregar módulos a la cuenta de múltiples firmas, lo que le otorga funcionalidades más ricas, como limitar el límite de fondos de cada transacción. Sin embargo, esta transparencia también significa que los detalles de la billetera de múltiples firmas son completamente públicos en la blockchain, lo que puede exponer la estructura de gestión de activos del usuario.

Además de soluciones de múltiples firmas conocidas dentro del ecosistema de Ethereum como Safe Wallet, también existen billeteras de múltiples firmas en la red de Bitcoin construidas con scripts BTC, como las soluciones basadas en el opcode OP_CHECKMULTISIG. Este opcode puede verificar si la cantidad de firmas contenidas en el script de desbloqueo UTXO cumple con los requisitos.

Es importante señalar que los algoritmos de múltiples firmas convencionales mencionados anteriormente admiten “M-de-N”, pero los algoritmos de múltiples firmas basados en algoritmos criptográficos específicos que se presentan más adelante, algunos solo admiten el modo “M-de-M”, es decir, los usuarios deben proporcionar todas las claves para poder realizar la transacción.

Implementación de múltiples firmas a nivel criptográfico

A nivel criptográfico, se puede implementar el efecto de verificación múltiple a través de algoritmos criptográficos específicos, y esta solución a veces puede prescindir de la participación de contratos inteligentes en la cadena. A menudo clasificamos de la siguiente manera:

1. Algoritmo de múltiples firmas ( Multisignatures ). Este algoritmo de firma solo admite el modo “M-of-M”, los usuarios deben presentar todas las firmas correspondientes a las claves de una sola vez.

2. Algoritmo de firma umbral ( Threshold Signatures ). Este algoritmo admite el modo “M-of-N”, pero en general, la dificultad de construcción es más compleja en comparación con el algoritmo de firma múltiple mencionado anteriormente.

3. Algoritmo de división de claves ( Secret sharing ). En el diseño de este algoritmo, el usuario puede dividir una única clave privada en múltiples partes; cuando el usuario recopila suficientes fragmentos de clave privada, puede restaurar la clave privada original y generar una firma.

Bitcoin introdujo el algoritmo Schnorr después de la actualización de SegWit (, lo que permite naturalmente la verificación de múltiples firmas. Por otro lado, la capa de consenso de Ethereum utiliza el algoritmo BLS de umbral para implementar la función de votación más central dentro del sistema PoS.

Este esquema de múltiples firmas que depende únicamente de algoritmos criptográficos tiene una mejor compatibilidad, ya que puede implementarse sin depender de contratos inteligentes, por ejemplo, utilizando una solución completamente fuera de la cadena.

Las firmas generadas por un esquema de múltiples firmas puramente criptográfico son idénticas en formato a las firmas de una sola clave privada tradicional, y pueden ser aceptadas por cualquier blockchain que soporte el formato estándar de firma, por lo que tienen una gran versatilidad. Sin embargo, los algoritmos de múltiples firmas basados en criptografía específica son bastante complejos y difíciles de implementar, y a menudo requieren depender de ciertas instalaciones específicas al usarlos.

Los desafíos reales de la tecnología de múltiples firmas

A pesar de que las carteras multifirma comunes mejoran significativamente la seguridad de los activos, también traen nuevos riesgos. El problema más evidente es el aumento de la complejidad operativa: cada transacción requiere coordinación y confirmación de múltiples partes, lo que se convierte en un obstáculo importante en escenarios sensibles al tiempo.

Lo que es más grave, las billeteras multisig a menudo trasladan el riesgo de la gestión de claves privadas a la coordinación y verificación de firmas. Como se demostró en el reciente robo de Bybit, los atacantes lograron engañar a los administradores multisig de Bybit para que firmaran transacciones de phishing al inyectar código de interfaz frontal de Safe en las instalaciones de AWS de las que depende Safe. Esto demuestra que, incluso al utilizar tecnología multisig más avanzada, la seguridad de la interfaz frontal y los procesos de verificación y coordinación de firmas aún presenta numerosas vulnerabilidades.

Además, no todos los algoritmos de firma utilizados en blockchain admiten nativamente la multi-firma, como el que se utiliza en la capa de ejecución de Ethereum, donde hay pocas implementaciones de algoritmos de multi-firma en la curva secp 256 k 1, lo que limita la aplicación de billeteras de multi-firma en diferentes ecosistemas. Para las redes que requieren implementar la multi-firma a través de contratos inteligentes, también existen consideraciones adicionales como vulnerabilidades de contrato y riesgos de actualización.

MPC: un avance revolucionario

Si se dice que una billetera multisig aumenta la seguridad mediante la descentralización de las claves privadas, entonces la tecnología MPC (cómputo seguro multipartito) va un paso más allá, eliminando fundamentalmente la existencia de claves privadas completas. En el mundo de MPC, nunca aparecen claves privadas completas en ningún lugar singular, ni siquiera durante el proceso de generación de claves. Al mismo tiempo, MPC suele soportar funciones más avanzadas, como la actualización de claves privadas o el ajuste de permisos.

En el contexto de las aplicaciones de criptomonedas, el flujo de trabajo de MPC muestra ventajas únicas. En la fase de generación de claves, múltiples partes generan números aleatorios por separado y luego, a través de protocolos criptográficos complejos, cada parte calcula su propio “fragmento de clave”. Estas partes no tienen ningún significado por sí solas, pero están matemáticamente interrelacionadas y pueden corresponder conjuntamente a una clave pública y una dirección de billetera específicas.

Cuando se necesita firmar una operación en la cadena, cada parte participante puede generar una “firma parcial” utilizando su propio fragmento de clave, y luego combinar estas firmas parciales de manera ingeniosa a través del protocolo MPC. La firma final generada es idéntica en formato a la firma de una única clave privada, de modo que los observadores externos ni siquiera pueden notar que es una firma generada por la infraestructura de MPC.

La revolución de este diseño radica en que la clave privada completa nunca ha aparecido en ningún lugar durante todo el proceso. Incluso si un atacante logra infiltrarse en el sistema de alguna de las partes involucradas, no podrá obtener la clave privada completa, ya que esta clave esencialmente no existe en ningún lugar.

La diferencia esencial entre MPC y la firma múltiple

Aunque MPC y las firmas múltiples implican la participación de múltiples partes, existen diferencias fundamentales entre ambos en su esencia. Desde la perspectiva de un observador externo, las transacciones generadas por MPC son indistinguibles de las transacciones de firma única, lo que proporciona a los usuarios una mejor privacidad.

Esta diferencia también se refleja en términos de compatibilidad. Las billeteras multifirma requieren soporte nativo de la red blockchain o dependen de contratos inteligentes, lo que limita su uso en ciertos lugares. Por otro lado, las firmas generadas por MPC utilizan el formato estándar ECDSA, que se puede usar en cualquier lugar que soporte este algoritmo de firma, incluyendo Bitcoin, Ethereum y varias plataformas DeFi.

La tecnología MPC también ofrece una mayor flexibilidad para ajustar los parámetros de seguridad. En una billetera multisig tradicional, cambiar el umbral de firma o el número de participantes a menudo requiere crear una nueva dirección de billetera, lo que conlleva riesgos. ) Por supuesto, una billetera multisig basada en contratos inteligentes puede modificar fácilmente los participantes y sus permisos (, mientras que en un sistema MPC, estos ajustes de parámetros se pueden realizar de manera más flexible y simplificada, sin necesidad de cambiar la cuenta en la cadena y el código del contrato, lo que proporciona una mayor conveniencia para la gestión de activos.

Desafíos que enfrenta el MPC

Sin embargo, aunque MPC es superior a la firma múltiple tradicional, todavía presenta desafíos correspondientes. Primero, está la complejidad en la implementación. El protocolo MPC implica cálculos criptográficos complejos y comunicación entre múltiples partes, lo que hace que la implementación y mantenimiento del sistema sea más difícil. Cualquier error podría provocar graves vulnerabilidades de seguridad. En febrero de 2025, Nikolaos Makriyannis y otros descubrieron un método para robar sus claves dentro de la billetera MPC.

El costo de rendimiento es otro problema. El protocolo MPC requiere cálculos complejos e intercambios de datos entre múltiples partes, consumiendo más recursos de cálculo y ancho de banda de red que las operaciones de firma única tradicionales. Aunque este costo puede ser aceptable en la mayoría de los casos, en ciertos escenarios con requisitos de rendimiento extremadamente altos, puede convertirse en un factor limitante. Además, el sistema MPC aún necesita la coordinación en línea de todas las partes participantes para completar la firma. Aunque esta coordinación es transparente para el usuario, en caso de una conexión de red inestable o cuando ciertas partes están fuera de línea, puede afectar la disponibilidad del sistema.

Además, el MPC aún no puede garantizar la descentralización. 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 representa un típico ataque de brujas. Este asunto es suficiente para demostrar que simplemente tener decenas de nodos en la superficie no puede proporcionar una alta garantía de descentralización.

DeepSafe: Construyendo la próxima generación de redes de verificación de seguridad

En un contexto donde la tecnología de multi-firma y MPC ya ha madurado relativamente, el equipo de DeepSafe ha propuesto una solución más prospectiva: CRVA (Agente de Verificación Aleatoria Criptográfica). La innovación de DeepSafe radica en que no reemplaza simplemente la tecnología de firma existente, sino que construye una capa de verificación de seguridad adicional sobre la base de las soluciones actuales.

Verificación multifactorial de CRVA

La idea central de DeepSafe es “doble seguro”: los usuarios pueden seguir utilizando sus soluciones de billetera familiares, como la billetera Safe, cuando una transacción de firma múltiple se envía a la cadena, se envía automáticamente a la red CRVA para una verificación adicional, similar a la verificación de múltiples factores 2FA de Alipay.

En esta arquitectura, el CRVA actúa como un guardián, revisando cada transacción según las reglas preestablecidas por el usuario. Por ejemplo, límites de cantidad por transacción, lista blanca de direcciones de destino, frecuencia de transacciones y otras restricciones, y puede interrumpir la transacción en caso de situaciones anómalas.

La ventaja de esta verificación de múltiples factores 2FA es que, incluso si el proceso de firma múltiple es manipulado (como en el ataque de phishing en el frontend del evento de Bybit), el CRVA como seguro aún puede rechazar transacciones de riesgo según las reglas preestablecidas, protegiendo así la seguridad de los activos del usuario.

Actualización tecnológica basada en soluciones MPC tradicionales

Para abordar las deficiencias de las soluciones tradicionales de gestión de activos MPC, 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 no se lanzará oficialmente hasta que se alcancen aproximadamente 500 nodos; según 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 a través de un algoritmo de sorteo, por ejemplo, cada media hora seleccionará 10 nodos, que actuarán como validadores para verificar si las solicitudes de los usuarios deben ser aprobadas, y luego generarán la firma umbral correspondiente para su liberación. Para prevenir la colusión interna o los ataques de hackers externos, el algoritmo de sorteo de CRVA utiliza un VRF circular original, combinado con ZK para ocultar la identidad de los seleccionados, de modo que el exterior no pueda observar directamente a los seleccionados.

Por supuesto, no es suficiente llegar a este punto; aunque el mundo exterior no sabe quién ha sido seleccionado, en este momento la persona seleccionada sí lo sabe, por lo que todavía hay una ruta de 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 puede saber si ha sido seleccionado, a menos que pueda romper el hardware confiable de TEE; por supuesto, según las condiciones tecnológicas actuales, esto es muy difícil de lograr.

Lo mencionado anteriormente es el enfoque básico del plan CRVA de DeepSafe. En el flujo de trabajo real, los nodos dentro de la red CRVA deben realizar una gran cantidad de comunicación por difusión e intercambio de información, y el proceso específico es el siguiente:

1. Todos los nodos, antes de ingresar a la red CRVA, deben primero hacer staking de activos en la cadena y dejar 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 algunos nodos. Pero antes de eso, todos los candidatos deben generar localmente una “clave pública temporal” única, al mismo tiempo que generan un ZKP para demostrar que la “clave pública temporal” está asociada con la “clave pública permanente” registrada en la cadena; en otras palabras, cada persona debe probar a través de ZK que existe en la lista de candidatos, pero sin revelar quién es.

3. La función de la “clave pública temporal” radica en la protección de la privacidad. Si se sortea directamente del conjunto de “claves públicas permanentes” y se publican los resultados, todos sabrán directamente quiénes fueron elegidos. Si todos solo exponen una “clave pública temporal” una vez, y luego se eligen a algunas personas del conjunto de “claves públicas temporales”, solo sabrás que tú has ganado, pero no sabrás a quiénes corresponden las claves públicas temporales ganadoras.

4. Para prevenir aún más la filtración de identidad, CRVA tiene la intención de 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 ejecutas el TEE, no puedes ver lo que sucede dentro.

5. Luego, dentro del TEE, se cifra el texto plano de la clave pública temporal como “garabato” 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.

6. El Relayer, después de restaurar todas las “claves públicas temporales”, las agrupa y las envía a la función VRF en la cadena, desde donde se seleccionan los ganadores. Estas personas validan las solicitudes de transacción enviadas por el front-end del usuario, y luego generan una firma umbral según los resultados de la validación, que finalmente se envía a la cadena. (Es importante notar que aquí el Relayer también tiene una identidad oculta y es seleccionado periódicamente).

Puede que algunos se pregunten, dado 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 introducir la lista en el TEE y verificar si ha sido seleccionada.

El núcleo de la solución DeepSafe radica en que casi todas las actividades importantes se realizan dentro del hardware TEE, lo que hace que no se pueda observar lo que sucede desde fuera del TEE. Cada nodo no sabe quiénes son los validadores seleccionados, lo que previene la colusión maliciosa y aumenta significativamente 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 incrementa drásticamente la dificultad del ataque.

En cuanto a la situación de CRVA actuando maliciosamente, dado que CRVA es un sistema de red de nodos que opera de manera automatizada, siempre que el código de su inicio no contenga lógica maliciosa, no habrá casos en los que CRVA se niegue activamente a cooperar con el usuario, por lo que se puede ignorar en gran medida.

Si CRVA sufre una gran cantidad de inactividad de nodos debido a eventos de fuerza mayor como cortes de energía o inundaciones, los usuarios aún tendrán una forma de retirar sus activos de manera segura, según el proceso mencionado en el esquema anterior. La suposición de confianza aquí es que confiamos en que CRVA es lo suficientemente descentralizado como para no actuar maliciosamente (las razones ya se han explicado suficientemente anteriormente).

Resumen

El desarrollo de la tecnología de firma Web3 muestra la incansable exploración de la humanidad en el campo de la seguridad digital. Desde la clave privada única inicial, hasta las carteras multi-firma, pasando por MPC y nuevas soluciones emergentes como CRVA, cada avance abre nuevas posibilidades para la gestión segura de activos digitales.

Sin embargo, el avance tecnológico no significa la eliminación de riesgos. Cada nueva tecnología, al abordar problemas existentes, también puede introducir nuevas complejidades y puntos de riesgo. A partir del incidente de Bybit, vemos que incluso al utilizar tecnología avanzada de múltiples firmas, los atacantes aún pueden eludir la protección técnica a través de ingeniería social y ataques a la cadena de suministro. Esto nos recuerda que las soluciones tecnológicas deben combinarse con buenas prácticas operativas y conciencia de seguridad.

Al final, la seguridad de los activos digitales no es solo un problema técnico, sino un desafío sistémico. Ya sea con múltiples firmas, MPC o CRVA, son solo soluciones tentativas para los riesgos potenciales. A medida que la industria blockchain avanza, en el futuro se necesitarán innovaciones para encontrar caminos más seguros y sin necesidad de confianza.