Carteras MPC frente a multisig
Tanto las carteras MPC como las multisig prometen el mismo titular: ningún punto único de compromiso. Ambas lo cumplen. Pero llegan ahí por caminos distintos, y los caminos tienen consecuencias distintas cuando las cosas salen mal, que es el único momento en el que un modelo de seguridad importa de verdad.
Este artículo es el cara a cara técnico. Si prefieres primero el panorama general de opciones de autocustodia, comparativa de opciones de autocustodia cubre todo el campo, incluidas las carteras hardware y las frases semilla a secas.
Dos respuestas distintas al mismo problema
El problema se enuncia igual en ambos casos: un solo secreto que lo controla todo es inaceptable, así que hay que repartir la autoridad.
MPC divide la clave. Conceptualmente hay una clave privada, pero nunca se ensambla en ningún sitio. En su lugar, fragmentos de ella viven en lugares distintos, y un protocolo criptográfico permite que esos fragmentos cooperen para producir una firma sin que ninguna parte aprenda la clave entera.
El multisig exige varias claves. Hay genuinamente varias claves privadas independientes. La dirección codifica una regla —tantas de estas claves deben firmar— y la cadena de bloques impone la regla al validar la transacción.
La distinción suena académica. No lo es. Una es un hecho sobre criptografía; la otra es un hecho sobre la cadena de bloques. Lo que la cadena sabe determina qué ocurre cuando una pieza del sistema falla.
Cómo funciona realmente MPC
MPC —computación multiparte, en este contexto normalmente esquemas de firma de umbral— permite que varias partes calculen conjuntamente una firma sobre un mensaje mientras cada una guarda solo un fragmento de la clave de firma. El NIST mantiene un proyecto de criptografía de umbral si quieres el tratamiento formal.
El resultado es una firma única y corriente. En la cadena, la transacción de una cartera MPC es indistinguible de una firmada por una persona con una clave. Eso tiene ventajas reales: funciona en todas las cadenas, cuesta lo mismo que una transacción de firma única y no revela nada sobre tu configuración de seguridad a quien observe la cadena.
La consecuencia de esa misma propiedad es donde hace falta cuidado. Como la cadena ve una firma normal, la cadena tampoco impone nada sobre tu política. Cuántos fragmentos existen, quién los guarda y cuántos deben cooperar son hechos sobre el software y los servidores, no sobre el libro mayor. Cambia el software y cambias la política.
Lo segundo que mirar es la custodia de los fragmentos. Muchas carteras MPC de consumo guardan un fragmento en la infraestructura del proveedor. Eso a menudo es lo que hace posible la experiencia fluida de recuperación, y también significa que la existencia y la cooperación continuadas del proveedor son piezas portantes de tu montaje. Algunos diseños mitigan esto bien, con fragmentos exportables o vías de respaldo independientes. La pregunta no es si el MPC puede hacerse bien; es si el producto concreto que estás valorando lo ha hecho de una forma que puedas verificar.
Cómo funciona realmente el multisig
En el multisig, la política forma parte de la dirección. En Bitcoin y otras cadenas UTXO, la dirección se deriva de un script que nombra las claves públicas y el umbral; un gasto que no lleve suficientes firmas válidas es sencillamente inválido, y todos los nodos de la red lo rechazan. En cadenas con contratos inteligentes, el equivalente es una cuenta cuyo código no actúa sin las aprobaciones requeridas.
No hay que confiar en nadie para que aplique la regla, porque aplicar la regla es lo que hace la red. Si mañana desapareciera todo el software de cartera implicado, la regla seguiría en pie, y cualquiera con las claves y una herramienta compatible podría seguir gastando.
Los costes también son reales. Gestionas varias claves en lugar de una, las copias de seguridad se complican y la transacción es más grande: en Bitcoin, más firmas significan más bytes y una comisión algo mayor. Tu política también es visible on-chain, lo que es una consideración de privacidad: un observador puede ver que una dirección es 2-de-3 aunque no vea quién guarda qué.
Qué es el multisig y por qué importa cubre el modelo con más profundidad.
Dónde encaja SSP, con precisión
SSP es un multisig 2-de-2, pero la honestidad exige un detalle aquí, porque la implementación no es idéntica en todas las cadenas.
En Bitcoin y las demás cadenas UTXO es multisig nativo a nivel de script vía BIP-48. Dos claves, un script, impuesto por consenso.
En Ethereum y otras cadenas EVM no existe un script nativo equivalente, así que SSP usa una cuenta inteligente que verifica una firma Schnorr agregada producida a partir de ambas claves. Tus dos dispositivos ejecutan un protocolo estilo MuSig2 y la cadena ve una sola firma: mecánicamente, eso se parece más en su forma al MPC que a un script multisig de Bitcoin.
La distinción que importa no es «agregada o no». Son estos dos hechos, que se cumplen en todas las cadenas que SSP admite:
- Ambas claves se generan en tus dispositivos y solo tú las guardas. SSP no guarda ningún fragmento, ninguna clave y ningún secreto parcial. No hay fragmento alguno en nuestros servidores que perder, requisar o retener como rehén.
- El requisito está on-chain. En EVM, el código de la cuenta inteligente no autoriza una transacción sin una firma que solo tus dos claves pueden producir. Ese código está desplegado, es público y ha sido auditado: no es una política que nuestro software decida aplicar.
En Solana es un programa on-chain sin creador y sin clave de administrador, donde la dirección de la bóveda es en sí misma una huella del conjunto de miembros y del umbral. Mecanismo distinto, misma garantía.
Si te interesa la criptografía de la agregación, firmas Schnorr y agregación multisig explica cómo una firma puede exigir dos claves.
Modos de fallo, uno al lado del otro
Los modelos de seguridad se comparan mejor preguntando qué se rompe.
Un dispositivo queda comprometido. Ambos modelos sobreviven. El atacante tiene un fragmento o una clave y no puede firmar solo.
El proveedor desaparece. El multisig sobrevive: las claves y la regla on-chain son todo lo necesario. El MPC sobrevive solo si puedes obtener y usar tus fragmentos sin el software del proveedor, lo cual depende enteramente del diseño.
Se obliga al proveedor a actuar. Si un proveedor guarda un fragmento, ese fragmento puede potencialmente entregarse bajo obligación legal, y según el esquema eso podría bastar para mover fondos junto con otro fragmento. Si el proveedor no guarda nada —como en SSP, donde ambas claves son tuyas— no hay nada a lo que obligar.
Pierdes una clave o un fragmento. Esto depende del umbral, no de la tecnología. Un montaje 2-de-3 de cualquiera de los dos tipos tolera una pérdida; uno 2-de-2 de cualquiera de los dos, no. Qué pasa si una de tus claves se ve comprometida recorre el caso de SSP en concreto.
El software de la cartera te miente sobre lo que estás firmando. Aquí ningún modelo ayuda, y conviene decirlo con claridad. Repartir la autoridad protege frente a una clave robada; no protege frente a aprobar la transacción equivocada. Por eso la pregunta interesante para ambos modelos es qué verifican tus dispositivos de forma independiente antes de firmar: decodificar la transacción en crudo en lugar de fiarse de la descripción que da un servidor.
Dónde gana cada uno
El MPC gana en cadenas sin buenas primitivas de multisig, en tamaño de transacción y comisiones, en privacidad del montaje y a menudo en experiencia de uso, en particular en la recuperación, donde un producto MPC bien diseñado puede ser muchísimo más amable que hacer malabares con varias copias de semilla.
El multisig gana en verificabilidad. La regla está en el libro mayor. No tienes que confiar en la descripción del modelo de seguridad; puedes leer la dirección o el contrato y ver la política. También gana en independencia: un montaje multisig con claves que guardas tú no tiene ninguna empresa en su modelo de confianza.
No hay contradicción en preferir respuestas distintas para propósitos distintos. Un saldo pequeño de uso diario en una cartera MPC bien construida y una tenencia a largo plazo en un multisig con claves guardadas por separado es una combinación perfectamente coherente.
Qué preguntar antes de comprometerte
Te inclines hacia donde te inclines, estas cuatro preguntas separan una buena implementación de una mala.
- ¿Quién guarda cada clave o fragmento, y puedo obtenerlos todos? Si la respuesta honesta incluye «el proveedor, y no», has elegido un modelo con contraparte.
- ¿Qué pasa si el proveedor desaparece mañana? Debería existir una vía documentada que no pase por él. Pruébala antes de necesitarla.
- ¿Dónde vive la política? ¿En un script o contrato on-chain, o en software? Ambas pueden estar bien, pero solo una sobrevive a que el software cambie.
- ¿Qué verifica cada dispositivo antes de firmar? Una segunda clave no aporta nada si ambos dispositivos firman a ciegas lo que les manda un servidor. Modos de fallo del multisig y cómo los mitiga SSP repasa esto y las demás formas en que un montaje de varias claves puede quedar socavado en la práctica.
Si quieres el modelo sobre el que está construido SSP explicado desde el principio, empieza por qué es el multisig 2-de-2. Y si la preocupación que te trajo aquí es perder una clave y no perder el control de una, recuperación social frente a multisig cubre la otra familia de respuestas.
