Firmas de umbral
Las firmas de umbral permiten que un número requerido de participantes coopere para producir una firma digital utilizando participaciones de una clave de firma común. En la custodia de criptomonedas, esto puede distribuir la facultad de firmar entre sistemas u organizaciones. Una solución de umbral depende de su protocolo criptográfico y del diseño de la gestión de claves; la denominación MPC wallet no especifica esos detalles.[1]
Umbrales y multifirmas
En un esquema de umbral, un subconjunto suficiente de participantes puede firmar. FROST es un protocolo de firmas Schnorr de umbral de dos rondas, con supuestos de seguridad sobre la generación de participaciones de clave y el número de participantes comprometidos. El RFC 9591 es una publicación informativa del Crypto Forum Research Group, no una especificación de la categoría Internet Standards Track.[1]
La firma por varias partes no siempre implica una firma de umbral. MuSig2, especificado en el BIP 327, agrega las claves públicas de los participantes y produce una firma Schnorr compatible con el BIP 340, pero requiere a todos los firmantes que intervinieron en la agregación de claves. Es un esquema de multifirma n de n, no un esquema de umbral t de n.[2]
Supuestos de seguridad y funcionamiento
Distribuir las participaciones cambia el modelo de confianza; no elimina la necesidad de sistemas seguros. FROST presupone una generación y distribución seguras de las participaciones y límites al número de participantes que un adversario puede comprometer. Sus consideraciones de seguridad tratan la reutilización de nonces, los canales laterales y los fallos del protocolo. La disponibilidad para firmar y la protección frente a falsificaciones son propiedades distintas.[1]
Servicios de custodia
La documentación de Multi-party Compute de Google Cloud, consultada en octubre de 2026, describe una plataforma de custodia que combina firmas de umbral con controles organizativos. La documentación clasifica el servicio como Preview y describe una API v1beta. Enumera ECDSA sobre secp256k1 para Bitcoin y aplicaciones compatibles con EVM; esto no implica compatibilidad con todos los formatos de firma de las cadenas de bloques.[3]
La autorización criptográfica también difiere de la automatización de políticas de transacciones. La documentación de Google indica que un número suficiente de firmantes puede autorizar una transacción rechazada por las políticas automatizadas. Por tanto, una decisión de política debe entenderse dentro del modelo de firmantes y de gobernanza del servicio.[4]
Referencias
- ↑ 1,0 1,1 1,2 RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol, June 2024, introduction and security considerations.
- ↑ BIP 327: MuSig2 for BIP340-compatible Multi-Signatures, motivation and general signing flow, checked 29 October 2026.
- ↑ Google Cloud: Multi-party Compute overview, checked 29 October 2026.
- ↑ Google Cloud: Transaction policy evaluation, checked 29 October 2026.