Tipos de firma: multifirma frente a MPC

Un retiro de 250.000 USDC desde la wallet de tesorería necesita dos aprobaciones: la de la tesorera y la del director financiero. Se puede montar de dos maneras. En la primera, la wallet es un contrato en Ethereum que solo ejecuta la transferencia si recibe dos firmas válidas de sus dueños; cualquiera puede ver en la cadena quiénes son los dueños y cuántas firmas hacen falta. En la segunda, la wallet es una dirección común cuya llave está repartida en fragmentos; dos fragmentos colaboran fuera de la cadena y producen una sola firma. La red ve una transferencia como cualquier otra.

Las dos exigen "dos de tres". Lo que cambia es dónde se verifica esa regla, y eso tiene consecuencias en redes soportadas, costo, auditoría y en cómo se cambian los firmantes. Este módulo parte de la llave ya custodiada del capítulo anterior y termina con una matriz de decisión por caso de uso.

Firma simple, multifirma y firma por umbral

Una firma simple es lo que ya conocemos: una llave privada, una firma, una dirección. Si esa llave se compromete, los fondos se van; si se pierde, se quedan bloqueados. Las otras dos familias reparten ese poder entre varias partes.

La multifirma (multisig) exige m firmas válidas de un conjunto de n llaves independientes, y la regla se verifica en la cadena. Bitcoin la tiene de forma nativa: en 2011, BIP-11 definió como transacción estándar el script m {pubkey}...{pubkey} n OP_CHECKMULTISIG, con ejemplos como un 2 de 3 entre comprador, vendedor y árbitro. [1] En Ethereum la multifirma no está en el protocolo: la implementa un contrato. El más usado es Safe, que guarda una lista de dueños y un umbral, y ejecuta una transacción cuando ese número de dueños la confirma. [2]

La firma por umbral (TSS, threshold signature scheme), que los proveedores suelen llamar MPC, reparte una sola llave en fragmentos. Según NIST, en un esquema con umbral k, cualquier grupo de k participantes honestos puede firmar sin reconstruir la llave, y un grupo menor no puede firmar ni aprender nada de ella. [3] El resultado es una firma ordinaria, indistinguible de la de una llave simple. Las firmas por umbral y agregadas, explicadas desde el mecanismo, están en firmas umbral, agregadas y AggQC.

Figura 1

El mismo retiro 2 de 3, firmado de dos maneras

Fuentes:

[2][3]

Cómo leer esta figura

Dos carriles horizontales. Carril superior, multifirma on-chain con contrato tipo Safe: las cajas dueño A y dueño B envían flechas a una caja de dos firmas ECDSA independientes; de ahí una flecha rotulada una transacción llega a la caja contrato verifica umbral y dueños, y luego a una caja verde: la red ve dos firmas, dueños y umbral públicos. Carril inferior, firma por umbral MPC/TSS: fragmento 1 y fragmento 2 envían flechas a protocolo MPC fuera de la cadena; una flecha rotulada combina lleva a una firma ordinaria de una sola llave, y luego a una caja verde: la red ve una firma, el quórum no es visible. Una nota final dice que en ambos casos la política de aprobación vive antes de la firma y que solo en el primero el umbral también se verifica en la cadena.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Un matiz evita una confusión frecuente: "multifirma" no siempre significa "visible". En Bitcoin, el esquema MuSig2 permite que varios firmantes produzcan una sola llave pública agregada y una sola firma Schnorr; para un observador, la salida es indistinguible de una de un solo firmante. [4] Lo que define la familia no es el nombre comercial, sino quién verifica el quórum.

Cuatro criterios: redes, visibilidad, costo y política

Redes soportadas. La multifirma depende de cada cadena: en Bitcoin es nativa; en Ethereum y redes compatibles hace falta desplegar un contrato en cada una; en otras puede no existir. La firma por umbral solo necesita que el protocolo MPC del proveedor soporte el algoritmo de firma de la red (por ejemplo ECDSA o EdDSA), así que una misma infraestructura cubre muchas cadenas. BitGo lo resume en su documentación: la mayoría de las cadenas UTXO soportan multifirma nativa, las cadenas de cuentas como Ethereum soportan MPC, y en algunas de estas ofrece multifirma mediante contratos. [5]

Visibilidad en la cadena. Con multifirma, dueños, umbral y cada cambio de configuración quedan registrados en la cadena: un auditor puede verificarlos sin pedir nada al proveedor. Con MPC, la cadena solo muestra que "esta dirección firmó"; la prueba de qué fragmentos y qué aprobadores participaron vive en los registros del proveedor. Para auditoría, eso significa exigir esos registros por contrato.

Costo. Una transacción multifirma lleva más datos de firma o ejecuta código de verificación, y paga más comisión que una transferencia simple; una firma por umbral cuesta lo mismo que una firma simple. BitGo lo plantea igual: la multifirma puede tener costos mayores porque cada firma se publica, y MPC costos menores porque se publica una sola. [5] Cuánto cuesta verificar distintos esquemas de firma se compara en costes computacionales: BLS frente a Ed25519.

Aplicación de la política. Un contrato como Safe puede añadir reglas propias: los guards revisan cada transacción antes y después de ejecutarla, y los modules permiten límites de gasto o pagos recurrentes. [6] Con MPC, la política vive en la infraestructura del proveedor, antes de que los fragmentos firmen. En ambos casos conviene separar dos quórums: el de aprobación (quién debe decir que sí, según monto y destino) y el de firma (cuántas partes criptográficas deben participar). El de aprobación lo diseña negocio; el de firma, seguridad.

Cambiar firmantes, perder uno y otros riesgos

Escenario: el director financiero deja la empresa. En una multifirma, su llave es uno de los dueños del contrato. Hay que enviar una transacción, aprobada por el umbral vigente, que lo quite y añada a su reemplazo. La dirección de la wallet no cambia, y el cambio queda en la cadena con fecha y firmas. En MPC, su participación es un fragmento o una aprobación en la plataforma del proveedor: se revoca y se emite otro fuera de la cadena, sin costo de comisión, y la evidencia es el registro del proveedor.

Los modules de Safe merecen una regla propia. Un módulo habilitado puede ejecutar transacciones a través de la cuenta sin pasar por el umbral de dueños; se añade o se quita con la confirmación del umbral, y la cuenta emite eventos cuando eso ocurre. [7] Habilitar un módulo equivale a crear un nuevo camino de gasto: debe tratarse como un cambio de política mayor. Con los guards el riesgo es el opuesto: un guard defectuoso puede bloquear todas las transacciones de la cuenta, y Safe pide auditarlo y prever cómo recuperarse. [6]

Las dos familias se pueden combinar. Los dueños de un Safe pueden ser cuentas comunes, otros contratos o incluso passkeys. [2] Nada impide que cada dueño sea una dirección protegida por MPC o por un HSM; si un proveedor concreto lo soporta como flujo operativo es un punto a validar. Y cuando el contrato debe aceptar firmas de otro contrato, entra EIP-1271, que define una función isValidSignature para que un contrato declare si una firma hecha "en su nombre" es válida. [8]

Dos lecturas de la serie de investigación completan el mapa: cuentas inteligentes con ERC-4337, donde las reglas de firma son programables, y EIP-7702, donde una cuenta común delega su código pero la llave original conserva todo el poder. Para multifirma como control de permisos en contratos, ver control de acceso en contratos.

Elegir el umbral m de n

Un umbral m de n tolera dos fallos distintos. Tolera n − m pérdidas: con 2 de 3 se puede perder una llave y seguir firmando. Y tolera m − 1 compromisos: con 2 de 3, un atacante con una llave no firma solo. Subir m protege más contra robo, pero hace más frágil la disponibilidad; subir n sin subir m hace lo contrario. Por qué un quórum protege aunque algunos participantes fallen se explica con detalle en quórums en acción.

La regla que más se olvida es la de independencia: un 2 de 3 donde dos llaves están en el mismo servidor, o en manos de la misma persona, es en la práctica un 1 de 2. Por eso BitGo, en sus wallets de custodia, reparte las tres llaves de modo que nadie controle más de una. [5]

BitGo por dentro: TSS en MPC y contrato en multifirma EVM

Escenario: el equipo del Middleware Blockchain abre una wallet USDC en Ethereum con BitGo y el formulario pregunta "multisig o MPC". La respuesta cambia qué ve la cadena, qué puede hacer BitGo sin nosotros y cómo se audita. Esta sección resume cómo lo implementa BitGo según su propia documentación, para que la elección sea explícita.

MPC en BitGo es firma por umbral

BitGo dice que la implementación concreta que usa para MPC es la firma por umbral (TSS) y que sus wallets MPC firman con 2 de 3 fragmentos de llave (keyshares): usuario, respaldo y BitGo. Cada parte genera su fragmento por separado y la llave privada completa nunca se crea. Añade una advertencia propia: sus fragmentos son distintos de los "shards" de otras plataformas y, aun combinados, no producen una llave privada visible. [5]

Como referencias de su implementación, la misma página enlaza un repositorio de Silence Laboratories titulado "Multi-Party-TSS (ECDSA-DKLs23)" y el artículo de Doerner, Kondi, Lee y shelat sobre ECDSA por umbral de dos partes construido sobre los supuestos de ECDSA. [13] Para el equipo, la consecuencia práctica es que la familia criptográfica es pública y revisable; qué versión exacta corre en producción y con qué auditorías es un punto a validar con el proveedor.

BitGo resume las diferencias con sus propias palabras, que conviene copiar tal cual en la matriz de decisión: la multifirma es "criptografía en la cadena" y MPC "criptografía fuera de la cadena"; en multifirma cada firma se publica y el costo puede ser mayor, en MPC se publica una sola firma; y en multifirma partes de la transacción sin firmar, como el nonce o la comisión, pueden cambiar durante el proceso de firma, mientras que en MPC ninguna parte puede cambiar. [5] Esa última diferencia importa en operación: con MPC, si la comisión de red sube mientras se reúnen las firmas, hay que reiniciar la firma, no ajustarla.

Multifirma EVM: un contrato con reglas por método

En Ethereum la multifirma de BitGo es un contrato que guarda las tres direcciones (usuario, respaldo y BitGo) en un arreglo allowedSigners, y cada método exige su propio número de firmantes. Enviar el activo nativo con SendMultiSig exige 2 de 3. Consolidar tokens ERC-20 desde una dirección forwarder con flushForwarderTokens exige solo 1. BitGo explica que por eso puede consolidar sin nuestra firma y, a la vez, por qué no puede retirar fondos de la wallet. [5]

La seguridad de esa firma única no viene del quórum, sino del destino: el contrato forwarder de cada dirección de recepción solo puede enviar a la dirección base de su wallet. [14] Es el mismo principio de los guards de Safe aplicado al revés: en lugar de exigir más firmas, se restringe a dónde puede ir el dinero. Para la auditoría, la regla "2 de 3" del contrato no es uniforme; hay que leerla por método. El circuito completo de consolidación y gas se trata en el módulo de wallets.

Cómo lo resuelven Fireblocks, BitGo y Kaleido

Fireblocks usa MPC (su protocolo MPC-CMP) para ECDSA y EdDSA, y declara preferirlo frente a multifirma por ser independiente del protocolo, más flexible y más barato al firmar fuera de la cadena; es su posición, no un criterio neutral. Su motor de políticas decide si una transacción se bloquea, se aprueba o pide firmantes adicionales según origen, destino, activo y monto, y un quórum de administradores aprueba cambios como añadir destinos o modificar políticas. [9]

Su documentación del API Co-signer separa bien los dos quórums: la firma usa los fragmentos MPC (uno del cliente y otros en co-firmantes de Fireblocks), mientras que las aprobaciones de transacciones y cambios se firman con una llave de aprobación propia de cada usuario y no pasan por MPC. [10] Si Fireblocks soporta operar una multifirma tipo Safe como flujo propio es un punto a validar con el proveedor.

BitGo ofrece ambas familias, en sus wallets en cadena con un 2 de 3 de llaves de usuario, respaldo y BitGo. Documenta las diferencias: en multifirma cada parte firma de forma asíncrona y en la cadena; en MPC firman de forma síncrona fuera de la cadena y resulta una sola firma; en multifirma algunos campos (nonce, comisión) pueden cambiar durante la firma y en MPC no. En Ethereum, su multifirma es un contrato con una lista allowedSigners. [5] Sus reglas de política filtran por destino, iniciador, porcentaje del saldo, monto, velocidad o respuesta de un webhook propio, pero no aplican a las recuperaciones con llaves de usuario y respaldo. [11]

Kaleido firma con llaves en el HSM o almacén del cliente y aplica la política en la capa de firma, escrita como código en Rego sobre Open Policy Agent. Soporta maker/checker, aprobación de cuatro ojos, cadenas de varios niveles y quórum de aprobadores, condicionados por activo, wallet, red o monto. [12] Es un quórum de aprobación sobre una firma simple en HSM; si ofrece firma por umbral MPC o multifirma en la cadena es un punto a validar.

Decisiones del módulo y entregable

El entregable es la matriz de decisión firma por caso de uso. La plantilla se completa con una fila por wallet; las columnas de costo, auditabilidad y redes son las que el equipo compara antes de elegir.

El próximo módulo, Wallets hot, warm y cold, usa estas piezas para decidir cuánto dinero puede estar expuesto en cada wallet y cuántas aprobaciones exige cada movimiento.