Google lanzará una plataforma de custodia criptográfica institucional en 2027: cómo funciona su tecnología MPC
Google Cloud ha introducido Google Multi-Party Compute (MPC), una solución especializada de gestión y custodia de claves para activos digitales diseñada para bancos globales, gestores de activos e instituciones financieras reguladas. Actualmente operando en una previsualización privada por invitación, el proveedor de nube tiene como objetivo la disponibilidad general comercial (GA) a principios de 2027. Antes del lanzamiento comercial amplio, Google ha validado la arquitectura en entornos de producción internos que respaldan importantes ecosistemas de cadena de bloques, incluyendo Ethereum y Solana.
Esta iniciativa representa una expansión notable en la infraestructura en la nube institucional de Web3. Durante varios años, los principales proveedores de nube centraron sus servicios de activos digitales principalmente en alojar nodos de llamada a procedimiento remoto (RPC), indexar conjuntos de datos de cadenas de bloques públicos en BigQuery y explorar redes de liquidación empresarial.
Al introducir una infraestructura MPC nativa, Google Cloud se adentra más en la pila de seguridad de las finanzas digitales institucionales: la generación distribuida, la verificación de políticas y la firma umbral de claves criptográficas. A medida que las instituciones financieras reguladas amplían su participación en depósitos tokenizados, productos intercambiables en spot (ETPs) y liquidación de activos del mundo real (RWA), la MPC integrada en la nube ofrece una base técnica modular junto con proveedores de custodia tradicionales y bóvedas de hardware heredadas.
Compromiso de clave y compensaciones en la custodia institucional
El crecimiento de la participación institucional en activos digitales ha subrayado la importancia de sistemas resilientes de gestión de claves. El seguimiento de seguridad de la industria de plataformas como DeFiLlama muestra consistentemente que los credenciales comprometidos y las explotaciones de claves privadas representan uno de los mayores vectores de pérdida de capital en el sector de las criptomonedas, con miles de millones de dólares en pérdidas acumuladas de la industria durante los últimos ciclos de mercado.
Históricamente, el almacenamiento institucional de activos digitales ha dependido de dos modelos arquitectónicos principales, cada uno con distintas compensaciones operativas para instituciones financieras comerciales.
-
Módulos de seguridad de hardware heredados y riesgos de punto único
La gestión de claves financieras tradicionales depende en gran medida de módulos de seguridad hardware (HSM) físicos y entornos de almacenamiento en frío aislados. Aunque los HSM aíslan las claves criptográficas dentro de hardware resistente a manipulaciones, las configuraciones estándar de clave única aún pueden introducir un punto único de falla estructural (SPOF).
Para autorizar una transacción de cadena de bloques convencional de firma única, la clave privada completa debe existir dentro del límite de memoria de un solo módulo durante la generación de la firma. Si un atacante compromete la capa de gestión del host, explota una vulnerabilidad de firmware o elude los controles de acceso administrativos, los activos controlados por esa clave única enfrentan una exposición inmediata.
-
Limitaciones de la firma múltiple en la cadena
Para evitar dependencias de una sola clave, muchos protocolos Web3 utilizan contratos inteligentes de firma múltiple en cadena (Multi-Sig), como Safe. En una estructura estándar M de N Multi-Sig, múltiples claves privadas independientes deben enviar aprobaciones separadas para satisfacer las reglas de ejecución del contrato inteligente.
Aunque altamente efectivo para tesorerías descentralizadas, Multi-Sig en cadena presenta tres obstáculos prácticos para los flujos de trabajo bancarios tradicionales:
Incompatibilidad entre cadenas: La lógica Multi-Sig de los contratos inteligentes no es uniforme en cadenas de bloques heterogéneas de Capa-1. Aunque está ampliamente estandarizada en redes de la Máquina Virtual de Ethereum (EVM), implementar gobernanza de contrato inteligente idéntica en cadenas no-EVM (como Bitcoin o Solana) requiere scripts nativos diferentes y pipelines operativos separados.
Costos más altos de transacciones en la red: Debido a que múltiples firmas criptográficas o llamadas de contrato se verifican directamente en la cadena, las transacciones Multi-Sig consumen espacio adicional en los bloques y comisiones de gas en comparación con las transferencias estándar de firma única.
Visibilidad pública de las reglas de gobernanza: Debido a que las reglas de Multi-Sig se ejecutan mediante contratos inteligentes públicos, los umbrales de cuórum, las direcciones de los firmantes y los patrones de aprobación organizacional de una institución son visibles en el libro mayor público.
Estas restricciones han impulsado la demanda institucional de criptografía umbral fuera de la cadena que unifica las políticas de seguridad en múltiples cadenas de bloques.
Cómo funciona la computación multipartita de Google
Google Cloud Multi-Party Compute aborda los riesgos de punto único de clave implementando Esquemas de Firma Umbral (TSS) construidos sobre Cómputo Multi-Parte (MPC). Bajo este modelo criptográfico, una clave privada completa nunca se ensambla en ningún dispositivo, bus de memoria del servidor o centro de datos en ninguna etapa de generación, almacenamiento o firma de transacciones.
El protocolo de firma de umbral Hardened DKLs23
Según las especificaciones técnicas de la plataforma, el motor de firma ECDSA de Google incorpora una implementación fortalecida del protocolo DKLs23. Denominado así en honor a los criptógrafos Döttling, Komargodski, Lai y Shen, DKLs23 es un protocolo moderno de firma umbral diseñado para calcular firmas de curva elíptica de forma segura entre partes distribuidas con un mínimo sobrecarga de comunicación.
La implementación de Google se centra en tres prioridades operativas:
-
Resistencia a adversarios maliciosos: el protocolo está diseñado para mantener la no falsificabilidad incluso si un atacante compromete un subconjunto de nodos participantes por debajo del umbral de firma. Las comprobaciones de consistencia integradas detectan fracciones criptográficas malformadas durante la ceremonia de firma y abortan automáticamente la sesión antes de que se pueda producir una firma inválida.
-
Optimización de ronda de baja latencia: Las implementaciones tempranas de MPC a menudo sufrían tiempos de firma lentos debido a múltiples rondas de comunicación de ida y vuelta por red. Al utilizar la estructura de ronda optimizada de DKLs23, los cálculos criptográficos locales se completan en milisegundos, permitiendo flujos de firma de extremo a extremo por debajo del segundo una vez que pasan las verificaciones de política institucional.
-
Soporte para múltiples curvas de cadena de bloques: La arquitectura admite nativamente el Algoritmo de Firma Digital de Curva Elíptica (ECDSA) sobre la curva secp256k1, el estándar para Bitcoin, Ethereum y redes Layer-2 compatibles con EVM, junto con soporte provisional para el Algoritmo de Firma Digital de Curva de Edwards (EdDSA) sobre Ed25519 para cubrir redes de alto rendimiento como Solana.
División heterogénea de claves: El modelo de cuórum 2-de-3
En lugar de generar una clave privada en un solo lugar y dividirla después, la plataforma utiliza la Generación Distribuida de Claves (DKG), donde nodos independientes calculan matemáticamente sus respectivas partes de la clave sin que ningún nodo vea nunca la clave completa.
Para evitar concentrar el riesgo en un solo proveedor de nube, las implementaciones institucionales suelen utilizar una estructura de cuórum heterogénea de 2 de 3:
-
Compartir 1 (Entorno controlado por el cliente): Hospedado directamente dentro del centro de datos on-premises de la institución financiera o entorno HSM dedicado.
-
Compartir 2 (Enclave de Google Cloud): Alojado dentro del entorno aislado por hardware de Confidential Space de Google Cloud.
-
Compartir 3 (Recuperación independiente o nube de terceros): Alojado en un entorno de nube externo (como AWS o Azure) o almacenado fuera de línea por un fiduciario de recuperación independiente.
Bajo esta estructura de umbral 2 de 3, cualquier par de acciones autorizadas puede colaborar fuera de la cadena para generar una firma criptográfica estándar. Para la cadena de bloques subyacente, la transacción resultante se ve idéntica a una transferencia normal de una sola clave.
Si un atacante lograra comprometer un solo entorno, obtendría solo una parte aislada de la clave, que matemáticamente no revela nada sobre la clave privada completa y no puede autorizar transacciones por sí sola. Por el contrario, si se compromete la estación de trabajo local de una institución, el atacante aún no puede mover fondos unilateralmente a menos que el enclave de Google Cloud verifique independientemente que la transacción cumple con las políticas de seguridad preestablecidas.
Aislamiento a nivel de hardware: Google Cloud Confidential Space (TEE)
Una preocupación histórica con la gestión de claves alojadas en la nube es el aumento de privilegios a nivel de host: si el sistema operativo o el hipervisor de un servidor en la nube se vieran comprometidos, un administrador con privilegios podría intentar inspeccionar el material criptográfico almacenado en la memoria del sistema (RAM).
Google mitiga este riesgo ejecutando sus nodos de firma MPC dentro de Google Cloud Confidential Space, un Entorno de Ejecución Confiable (TEE) respaldado por hardware de cómputo confidencial:
Cifrado de memoria en hardware: Confidential Space utiliza el cifrado de memoria a nivel de procesador (como AMD SEV-SNP), asegurando que las partes clave y los cálculos intermedios de firma permanezcan cifradas en la RAM utilizando claves de hardware inaccesibles para el sistema operativo anfitrión.
Atestación criptográfica: Antes de acceder a una parte de la clave o de iniciar una ronda de firma, el enclave genera un token de atestación basado en hardware que verifica el hash criptográfico exacto de la imagen del contenedor y la línea base del firmware. Si la imagen del software ha sido modificada de cualquier manera, la verificación de atestación falla y se bloquea el proceso de firma.
Acceso administrativo restringido: Confidential Space impone una aislamiento estricto de cargas de trabajo que elimina el acceso root estándar o las capacidades de depuración interactiva, impidiendo que incluso los administradores de infraestructura en la nube vean los datos dentro de un enclave activo.
Cumplimiento de la política de transacciones y mecanismos de actualización de claves compartidas
Proteger las partes clave de la extracción resuelve solo parte del desafío de custodia. En la práctica, muchos incidentes de seguridad institucional provienen de credenciales de API comprometidas, ataques de phishing o aprobaciones internas no autorizadas que engañan a sistemas válidos para firmar transacciones maliciosas.
Motores de verificación de política de pre-firma
Para protegerse contra transferencias no autorizadas en la capa de aplicación, Google Cloud incorpora un motor de verificación de políticas deterministas directamente dentro del enclave Confidential Space. Antes de que el nodo MPC de Google participe en una ronda de firma umbral, la carga útil de la transacción propuesta se verifica contra reglas de gobernanza definidas por la institución, como direcciones de destino permitidas, límites máximos de valor de transacción, límites de velocidad, ventanas horarias y firmas de cuórum con múltiples aprobadores.
Si un terminal endpoint comprometido intenta solicitar una transferencia a una dirección no aprobada o por encima de los umbrales permitidos, el enclave rechaza la solicitud de firma antes de que se realice cualquier cálculo de parte criptográfica.
Compartición proactiva de secretos (actualización de la clave compartida)
Para reducir el riesgo de que un atacante sofisticado comprometa gradualmente múltiples nodos durante un largo período, la arquitectura admite el Compartimiento Secreto Proactivo (PSS), comúnmente conocido como rotación o actualización de las claves compartidas.
En una base programada o tras cambios de personal, los nodos participantes ejecutan un protocolo de actualización matemática:
-
Los nodos calculan colaborativamente un nuevo conjunto de participaciones criptográficas.
-
Las anteriores claves compartidas se invalidan y sobrescriben permanentemente.
-
La clave pública maestra subyacente y la dirección del monedero en la cadena permanecen completamente inalteradas.
Esto significa que incluso si un atacante lograra robar una sola parte de la clave en un mes, ese fragmento se vuelve inútil una vez que ocurre la siguiente actualización programada de la parte, permitiendo a las instituciones rotar regularmente su material de seguridad subyacente sin tener que mover fondos a una nueva dirección de cadena de bloques ni pagar comisiones de gas en la cadena.
Agilidad post-cuántica y preparación comercial para 2027
A medida que las instituciones financieras evalúan la infraestructura de custodia con horizontes de varios años, la agilidad criptográfica a largo plazo, incluida la preparación para la computación cuántica, se ha convertido en una consideración arquitectónica importante. Los esquemas estándar de curva elíptica (secp256k1 y Ed25519) dependen de problemas matemáticos que eventualmente podrían ser vulnerables a computadoras cuánticas suficientemente potentes y tolerantes a fallos.
Mientras que la implementación inicial de MPC de Google Cloud se centra en resolver amenazas operativas inmediatas, como el robo de credenciales, puntos únicos de fallo y colusión interna, la plataforma está diseñada con modularidad criptográfica en mente. Al separar las capas de orquestación de políticas y API de los primitivos de firma subyacentes, la arquitectura está estructurada para adaptarse a futuras criptografías resistentes a la computación cuántica (PQC) y estándares de transporte seguros frente a la computación cuántica a medida que las redes de cadena de bloques y organismos internacionales de normalización (como el NIST) finalicen las especificaciones de firmas resistentes a la computación cuántica.
Conclusión
La implementación de la infraestructura de Cómputo Multi-Parte Institucional de Google Cloud destaca la maduración continua de la seguridad empresarial de activos digitales. Al combinar el protocolo de firma umbral DKLs23 con enclaves Confidential Space atestados por hardware y una distribución heterogénea de claves 2-de-3, la plataforma ayuda a las instituciones financieras a mitigar vulnerabilidades de clave de punto único sin sacrificar la velocidad de firma ni la flexibilidad multi-cadena. A medida que el servicio avanza hacia su disponibilidad comercial en 2027, el MPC integrado en la nube está preparado para desempeñar un papel creciente en cómo los bancos y gestores de activos aseguran activos tokenizados a gran escala.
Preguntas frecuentes
¿Qué es Google Cloud Multi-Party Compute?
Google Cloud Multi-Party Compute (MPC) es una plataforma de infraestructura para la gestión y firma de claves de activos digitales institucionales, actualmente en previsualización privada antes de un lanzamiento comercial previsto para principios de 2027. Utiliza criptografía de umbral para dividir el control de la clave privada entre entornos separados, eliminando puntos únicos de fallo durante la firma de transacciones en la cadena de bloques.
¿Por qué Google está enfocándose en la disponibilidad comercial para 2027?
Ejecutar una previsualización privada exclusiva por invitación a finales de 2026 permite a los bancos socios y gestores institucionales de activos realizar auditorías de seguridad, integración de políticas y pruebas de cumplimiento. El objetivo de disponibilidad general a principios de 2027 se alinea con la creciente adopción institucional dentro de marcos regulatorios maduros, como el régimen MiCA de la UE y las normas evolutivas del Comité de Basilea sobre exposiciones bancarias a activos criptográficos.
¿Cómo difiere el MPC de Google de la multi-firma en cadena?
Los contratos inteligentes de multi-firma en cadena verifican múltiples firmas separadas directamente en una cadena de bloques, lo que aumenta los costos de gas, expone públicamente las estructuras de aprobación y requiere soporte de contrato inteligente específico de la cadena. El MPC de Google realiza la aprobación multipartita y los cálculos de umbral fuera de cadena utilizando el protocolo DKLs23 fortalecido, generando una única firma estándar que funciona en diferentes cadenas de bloques con tarifas más bajas y reglas de gobernanza privadas.
¿Elimina la tecnología MPC todos los riesgos de custodia de criptoactivos?
Ninguna arquitectura de seguridad puede eliminar todos los riesgos. Si bien MPC elimina el punto único de fallo asociado con el almacenamiento de una clave privada completa en un solo lugar, las instituciones deben seguir protegiéndose contra el phishing, la compromisión de puntos finales y la gobernanza interna defectuosa. El diseño de Google ayuda a reducir estos riesgos operativos al combinar fragmentos de clave heterogéneamente divididos con enclaves Confidential Space aislados en hardware y verificaciones de políticas previas a la firma.
Descargo de responsabilidad
Esta información general del mercado, posiblemente proveniente de fuentes de terceros, comerciales o patrocinadas, se proporciona únicamente con fines de referencia y educativos y no constituye asesoramiento financiero ni de inversión, una oferta, solicitud o garantía. Renunciamos a toda responsabilidad por su precisión, integridad, confiabilidad y cualquier pérdida resultante. Las inversiones/opciones de trading son arriesgadas; el desempeño pasado no garantiza resultados futuros. Los usuarios deben investigar, juzgar con prudencia y asumir toda la responsabilidad. Para más detalles, consulte las Condiciones de uso y Divulgación de riesgos de KuCoin.
Aviso: Esta página fue traducida utilizando tecnología de IA para tu conveniencia. Para obtener la información más precisa, consulta la versión original en inglés.