Explicación de las carteras multisig: cómo la aprobación M-de-N realmente mueve fondos

Carteras multisig explicadas: una cartera de firma múltiple solo envía fondos cuando al menos M de N claves autorizadas aprueban la misma transacción, en lugar de depender de una clave privada. Ese diseño convierte la custodia en un modelo operativo, con un flujo de propuesta y revisión, logística de tarifas y elecciones de implementación específicas de la cadena que pueden mantener los fondos seguros o dejarlos atascados.

Puntos clave

• Una cartera multisig requiere dos o más claves privadas para autorizar una transacción, utilizando típicamente un umbral de m de n como 2 de 3 o 3 de 5.
• El flujo de trabajo central es un pipeline de aprobación: un firmante propone una transacción, otros firmantes añaden firmas, la cartera verifica el umbral y luego la transacción se transmite.
• El multisig en cadena integrado en un protocolo (como Bitcoin P2SH) se comporta de manera diferente a un multisig de cartera de contrato inteligente en Ethereum (como Safe wallet), incluyendo riesgo de contrato y compatibilidad con dapp a través de ERC-1271.
• Multisig y mpc resuelven el “control compartido” de manera diferente: multisig deja un rastro de aprobación en cadena vinculado a claves distintas, mientras que MPC produce firmas a través de computación fuera de la cadena sin ensamblar nunca una clave completa.

Cómo las carteras multisig cambian el control de claves

Una cartera de firma única concentra la autoridad en una clave privada, lo que significa que un compromiso o una clave perdida pueden ser terminales. Multisig cambia esa superficie de control al dividir la autoridad entre múltiples claves y requerir un umbral de aprobaciones antes de que los fondos se muevan.

Por eso, multisig aparece tan a menudo en discusiones de seguridad de carteras y en conversaciones más amplias sobre tipos de carteras de criptomonedas explicadas. No es solo “más claves”. Es un conjunto de reglas sobre quién puede autorizar qué.

El modelo mental importante es la gobernanza, no la criptografía. Una configuración multisig codifica una política de aprobación que coincide con cómo un equipo, familia o DAO ya se comporta. Si el proceso real es “dos personas deben firmar”, un 2 de 2 coincide con la intención pero crea un riesgo de inactividad dura si alguno de los firmantes desaparece.

Si el proceso real es “dos personas firman, pero debe haber un camino de recuperación”, un 2 de 3 es el valor predeterminado común porque tolera una clave faltante mientras sigue previniendo el control unilateral.

Multisig también ocupa un lugar específico en el espectro de custodia. Sigue siendo un modelo de cartera no custodial cuando los firmantes controlan las claves y ninguna tercera parte puede mover fondos unilateralmente. La diferencia es que el “propietario” ahora es una política grupal en lugar de una sola persona.

Esa política puede ser implementada de manera nativa por una cadena, o aplicada por un contrato en cadenas de contratos inteligentes. Esa elección de implementación es de donde provienen muchas sorpresas operativas.

El modelo M-de-N y los flujos de trabajo

La regla del umbral es todo el juego: N es el número total de claves autorizadas, y M es el número mínimo de firmas requeridas para aprobar una transacción. Las configuraciones comunes se mapean claramente a procesos de aprobación reales: 2 de 2 para socios iguales, 2 de 3 para equipos pequeños con una clave de respaldo, y 3 de 5 para control estilo comité que puede sobrevivir a ausencias.

El flujo de trabajo importa porque multisig es un pipeline de aprobación que se ejecuta cada vez que se mueven fondos. Un flujo típico sigue una secuencia ordenada:

1. Crear una propuesta de transacción. Un firmante autorizado redacta la dirección, cantidad y cualquier dato de llamada. 2. Recoger firmas. Otros firmantes autorizados revisan la propuesta y la firman con sus claves privadas. 3. Verificar el umbral. La cartera verifica que al menos M aprobaciones de firmantes válidas estén presentes. 4. Transmitir y ejecutar. La transacción completamente aprobada se envía a la red para su confirmación.

Dos detalles operativos tienden a decidir si multisig se siente “seguro” o “atascado”. El primero es la disponibilidad de los firmantes: si M firmantes no pueden responder dentro de la ventana que la organización necesita, la cartera se convierte en un cuello de botella. El segundo es la financiación de tarifas.

EIP-86 destacó un punto de dolor concreto al principio de la historia de Ethereum: las operaciones multisig pueden requerir múltiples transacciones de ratificación, y los participantes pueden necesitar ETH para tarifas para enviar esas aprobaciones. Eso no es una nota teórica. Es el tipo de fricción que aparece cuando un equipo intenta mover fondos bajo presión de tiempo y descubre que los firmantes ni siquiera pueden pagar para aprobar.

Multisig en cadena y contratos inteligentes

El multisig estilo Bitcoin y el multisig estilo Ethereum pueden parecer similares desde afuera, pero fallan de manera diferente porque están construidos de manera diferente. El multisig en cadena es soporte nativo del protocolo, con Bitcoin P2SH como el ejemplo canónico. Las condiciones de gasto viven en las reglas de scripting de la cadena.

La ventaja es un área de superficie más pequeña porque no hay código de contrato separado en el que confiar. La desventaja es que el conjunto de características está limitado por lo que el protocolo base soporta.

El multisig de contrato inteligente es un animal diferente. En Ethereum y cadenas similares, un multisig es a menudo una cartera de contrato inteligente, con Safe wallet como la implementación de referencia ampliamente utilizada. El contrato mantiene activos y aplica las reglas de aprobación en código. Eso desbloquea flexibilidad, pero introduce riesgo de contrato y trabajo de compatibilidad.

La compatibilidad es donde el multisig de Ethereum se vuelve menos sobre firmas y más sobre estándares. Muchas aplicaciones esperan un mensaje firmado de una cuenta de propiedad externa. Un contrato no puede producir una firma ECDSA normal porque no tiene clave privada.

ERC-1271 es el apretón de manos que soluciona esto: define un método isValidSignature(hash, signature) que las aplicaciones pueden llamar cuando el “firmante” es un contrato, y requiere devolver el valor mágico 0x1626ba7e cuando la validación pasa. Cuando una dapp soporta ERC-1271, puede tratar las aprobaciones de una cartera de contrato como una autorización real.

Cuando no lo hace, el multisig puede ser bloqueado de flujos de trabajo que dependen de mensajes firmados, como sistemas de órdenes fuera de la cadena.

Dónde se usa multisig

Multisig aparece donde el requisito real es el control compartido con un rastro de auditoría. Las tesorerías corporativas y de proyectos utilizan multisig para forzar aprobaciones explícitas para transferencias, de modo que ningún operador único pueda mover fondos unilateralmente.

Los DAOs y fondos comunitarios utilizan multisig como una capa de control pragmática, especialmente cuando el grupo quiere responsabilidad visible sobre quién aprobó qué.

Los arreglos similares a un depósito en garantía son otra adaptación natural. Un patrón de 2 de 3 puede asignar una clave a un comprador, una a un vendedor y una a un árbitro neutral. Los fondos solo se mueven cuando dos partes están de acuerdo, lo que reduce la necesidad de confiar en un único intermediario.

La misma estructura puede usarse para fondos de asociación donde ninguna de las partes quiere que la otra tenga derechos de retiro unilaterales.

Las configuraciones de seguridad personal son el caso de uso más silencioso, y a menudo se malinterpretan. Un 2 de 3 puede dividir claves entre dispositivos y ubicaciones, o agregar un respaldo de parte de confianza para recuperación. El punto no es crear un ritual de firma complicado. El punto es separar dominios de falla.

Si todas las claves viven en el mismo ecosistema de dispositivos, o todas las claves son sostenidas por la misma persona “por conveniencia”, la etiqueta multisig está haciendo trabajo de marketing, no de riesgo.

Aquí es donde la tesis del modelo operativo también tiene impacto. El m de n correcto es el que coincide con el proceso de aprobación y el tiempo de inactividad aceptable si un firmante desaparece. Un 2 de 2 puede ser perfecto para una cuenta conjunta hasta que se pierde una clave. Un 3 de 5 puede ser perfecto para la continuidad hasta que el grupo se da cuenta de que las aprobaciones ahora requieren programación.

Beneficios de seguridad y compensaciones operativas

El beneficio de seguridad de multisig es directo: comprometer una clave no es suficiente para mover fondos. Eso reduce el radio de explosión de phishing, malware en un solo dispositivo, o un solo interno que se vuelve rebelde. También crea una responsabilidad más clara porque las aprobaciones están vinculadas a claves de firmantes distintas y pueden ser auditadas como parte del historial de ejecución de la cartera.

Las compensaciones son principalmente operativas, y se presentan como modos de falla. La coordinación es la obvia, pero los problemas más costosos suelen ser procedimentales. La revisión informal conduce a firmar la carga incorrecta, enviar al destino incorrecto o aprobar el nonce incorrecto. Multisig facilita construir una cultura de listas de verificación, pero no impone una por defecto.

La logística de tarifas es la otra trampa recurrente. EIP-86 destacó explícitamente que multisig puede requerir múltiples transacciones de ratificación y que los participantes pueden necesitar ETH para tarifas. Eso crea una pregunta de política que cada grupo multisig debe responder: quién es responsable de mantener a los firmantes financiados para las aprobaciones, y qué sucede cuando no lo están.

Los enfoques de contrato de cuenta fueron motivados en parte por el deseo de que el contrato mantuviera ETH y pagara tarifas, precisamente porque “cada firmante necesita gas” es una suposición operativa frágil.

La elección del umbral es la última compensación, y no se resuelve agregando más firmantes. Un 2 de 2 maximiza el control mutuo pero puede congelar permanentemente los fondos si se pierde una clave. Un 2 de 3 es popular porque incorpora redundancia a través de una clave de respaldo. Un 3 de 5 es de grado de gobernanza cuando la continuidad a través de ausencias importa más que la velocidad.

Un N más alto puede aumentar el fallo de coordinación, lo que significa que “más firmantes” puede reducir la probabilidad de que la cartera pueda actuar cuando necesita hacerlo.

Cómo se compara multisig con MPC

Multisig y MPC ambos buscan reducir el riesgo de clave única, pero lo hacen con diferentes propiedades de responsabilidad y operativas. Multisig utiliza múltiples claves completas mantenidas por diferentes firmantes, y la billetera combina aprobaciones en cadena para autorizar una transacción.

La pista de aprobación es explícita y está vinculada a identidades de firmantes distintas, razón por la cual multisig a menudo se prefiere cuando la transparencia y la auditabilidad son requisitos.

MPC divide una clave de firma en fragmentos y genera firmas a través de computación fuera de la cadena, sin que ninguna parte tenga jamás la clave completa. Esa arquitectura puede soportar una automatización más fluida y puede ser más agnóstica a la blockchain, lo que es importante para operaciones en múltiples cadenas.

El intercambio es que el proceso de aprobación no es inherentemente una pista de auditoría en cadena, firmante por firmante, como lo es multisig.

El marco de decisión no es 'cuál es más seguro' como una afirmación universal. Es 'qué necesita ser comprobable en cadena, y qué necesita ser rápido y operativamente fluido.' Si el requisito es gobernanza y responsabilidad clara para las aprobaciones, multisig encaja naturalmente. Si el requisito es rendimiento operativo a través de muchas cadenas con automatización impulsada por políticas, MPC a menudo encaja mejor.

Aquí es también donde los detalles de implementación importan. Un multisig en una cadena con soporte nativo se comporta de manera diferente a un multisig basado en contrato que depende de la compatibilidad con ERC-1271 para flujos de trabajo de mensajes firmados. Esa diferencia es parte de los tipos de billetera explicados, y es por eso que dos productos pueden ser llamados 'multisig' mientras fallan de maneras completamente diferentes.

La Toma

He visto equipos tratar multisig como una casilla de verificación, y luego descubrir que construyeron un pipeline de aprobación frágil. El momento costoso no es el día en que se crea la billetera. Es el día en que un firmante está de viaje, un dispositivo está muerto, y el grupo se da cuenta de que el umbral que eligieron implica un presupuesto de tiempo de inactividad muy real.

La postura limpia es diseñar multisig como un sistema de control de escritorio: propuesta, revisión, firmas, verificación de umbral, difusión, con propiedad para la financiación de tarifas y un plan para la desaparición de firmantes. 2 de 2 es control máximo y propenso a congelarse, 2 de 3 es el predeterminado práctico porque tiene un camino de recuperación, y 3 de 5 es lo que se utiliza cuando la continuidad importa más que la velocidad. El número de firmantes no es la característica. El modelo operativo lo es.

Fuentes

• Cobo
• Propuestas de Mejora de Ethereum
• Propuestas de Mejora de Ethereum
• Medium