Cartera Multisig: Qué es Multisig y cuándo merece la pena

El modelo de gestión de criptoactivos determina muchas cosas, desde la seguridad básica hasta la eficiencia operativa, y los monederos multisig se han convertido en la solución perfecta para muchos. Implementan el modelo en el que las decisiones de gestión de activos dependen de unos pocos participantes y políticas predefinidas, eliminando un único punto de fallo y haciendo que cada paso sea autorizado y verificable. Aquí aprenderá las características de los monederos multisig frente a los monederos single-sig y mpc frente a los monederos multisig, los riesgos de los monederos multisig y mucho más.

Qué es multisig y cómo funciona un monedero multisig

En primer lugar, vamos a desglosar el concepto mismo de una criptocartera de custodia compartida, que ofrece un control colectivo sobre los fondos a nivel de roles y etapas del proceso. El proceso en sí incluye cuatro primitivas: propuesta, atestación, confirmación y finalización. El iniciador forma una propuesta de gasto, el atestador verifica los parámetros y el contexto, el firmante añade una confirmación, y el observador mantiene el registro de auditoría y eventos. Más concretamente:

• Propuesta. El iniciador forma una propuesta de gasto con múltiples atributos: un identificador único, el activo y el importe, la dirección de destino, el propósito de la operación, el periodo de validez y la lista de firmantes permitidos. Cada versión de la propuesta tiene su propio identificador de versión y hash de contenido al que están vinculadas todas las acciones posteriores.
• Atestación. El certificador realiza una comprobación independiente de la versión actual de la propuesta y registra el resultado como aprobación o rechazo. En caso de rechazo, no se permite recoger confirmaciones hasta que se emita una nueva versión.
• Confirmación. El firmante añade una confirmación criptográfica sobre el hash de la versión actual de la propuesta. Sólo se contabilizan las confirmaciones de los participantes incluidos en la lista de firmantes permitidos. Una firma no se transfiere entre versiones ni a otras propuestas.
• Finalización. La finalización registra la finalización de la aprobación de la versión activa dentro de su ventana de validez y mueve la operación al estado de ejecución.

Al mismo tiempo, el registro se mantiene de extremo a extremo para todas las etapas, conteniendo el hash y la versión de la propuesta, el estado de atestación, la lista de confirmaciones válidas por participante con marcas de tiempo, y el hecho de la finalización o expiración.

Esquemas de umbral m-de-n y políticas de acceso

Al mismo tiempo, los esquemas específicos pueden diferir, y esto se basa en varias opciones m-de-n y políticas de acceso. Aquí n denota el número de participantes a los que la política permite firmar operaciones, y m el número mínimo de firmas necesarias para autorizar una única operación. Así, la regla general m-de-n: una operación se ejecuta si hay al menos m firmas del conjunto de n participantes permitidos. La política de acceso fija la composición de los participantes, los valores de m y n, la ventana de validez para una versión específica de la propuesta, la lista de tipos de operación permitidos y las reglas para modificar la propia política.

También existen diferentes invariantes de la política y de los componentes que la definen. Seguridad significa la imposibilidad de gastar con menos de m firmas que hayan pasado la comprobación de pertenecer al conjunto de participantes permitidos. Liveness significa la ejecución de una operación cuando hay m firmas válidas dentro de la ventana de validez especificada. De estos parámetros se derivan características de funcionamiento: la tolerancia a la indisponibilidad u se define como n menos m, es decir, el sistema tolera la indisponibilidad temporal de hasta u firmantes preservando la alcanzabilidad del quórum. La colusión mínima c es igual a m, es decir, el gasto no autorizado requiere el compromiso o la colusión de al menos m claves privadas del conjunto permitido.

Por cierto, una de las mejores prácticas para la seguridad multisig es separar los dominios de la política en pagos cotidianos, grandes operaciones y cambios en la propia política, asignando un umbral m-de-n más estricto para el último caso. Esta formalización vincula el rigor de control requerido a la tolerancia a fallos sin atarse a una implementación específica.

Arquitecturas e implementaciones multisig

Antes de considerar las implementaciones arquitectónicas de multisig, aclaremos la diferencia entre multisig y single-sig. Single-sig se basa en un único par de claves y un único sujeto decisor. Esto proporciona operaciones sencillas, retrasos mínimos en la aprobación y una amplia compatibilidad con la infraestructura. Pero el riesgo también se concentra en un único punto: el compromiso o la pérdida de la clave equivale a la pérdida del control. Además, la rotación de claves requiere una migración cuidadosa de todos los fondos, lo que aumenta la probabilidad de error. Además, la auditoría registra las acciones de un único propietario; no hay separación de funciones y no se dispone de una regla de confirmación independiente a nivel de la red.

Aclaremos también multisig vs monedero hardware, que debe considerarse a través de la interacción de capas. Un monedero hardware refuerza el almacenamiento de claves privadas, las protege del malware y proporciona verificación de parámetros directamente en el dispositivo. Mejora el single-sig pero no cambia la lógica misma del acceso a los fondos: la decisión sigue siendo unilateral. Sin embargo, en una política distribuida, cada participante utiliza su propio dispositivo para firmar, y tal combinación puede formar multisig con monederos de hardware, donde los dispositivos protegen las claves del lado de los firmantes, y la permisibilidad de la operación se determina por quórum. Como resultado, la política de acceso y la clase de soporte trabajan juntas: la primera establece la regla de autorización, la segunda reduce la probabilidad de compromiso de cada clave.

A propósito, conozca una Guía completa de la autocustodia en criptografía: Seguridad, Estrategia y Responsabilidad.

Monederos Smart Contract Multisig

Los monederos multisig de los contratos inteligentes consagran la política m-de-n en el código y el estado del contrato. El contrato almacena la lista de firmantes permitidos, el valor de m, la versión de la política y el registro de propuestas con identificadores, periodos de validez y hashes de parámetros. Acepta una versión específica de una propuesta, verifica las firmas sobre su hash, cuenta las confirmaciones por participante, evita las repeticiones mediante nonces y contadores, y ejecuta la transferencia una vez alcanzado el umbral.

La modificación de la composición de firmantes y del umbral se realiza a través de funciones administrativas independientes con su propia política de confirmación, lo que separa la gestión de activos de la gestión de reglas. El registro de eventos registra la emisión de una propuesta, cada confirmación, finalización y cambios de política, lo que vincula el estado en la cadena a las acciones administrativas.

La privacidad en la cadena para multisig en este modelo está conformada por artefactos de ejecución observables. Por ejemplo, siempre son visibles la dirección del contrato, los importes entrantes y salientes, las direcciones de los destinatarios, el propio ciclo y los eventos del contrato. Los registros registran el identificador de la propuesta, el número de versión de la política y el contador de confirmaciones recogidas; los cambios en el conjunto de firmantes o en el valor de m también se capturan en los eventos. Por tanto, un observador externo puede reconstruir la cadencia de las operaciones, los momentos en que cambia la política y el orden de magnitud de los importes. Incluso con la agrupación o la abstracción de cuentas, las firmas de las funciones y la estructura del registro conservan el patrón "propuesta-confirmaciones-finalización": parte de los pasos simplemente acaban dentro de una transacción agregada. Lo que no ven por defecto: qué personas concretas firmaron, qué ocurrió en tus canales de coordinación y por qué se tomó una decisión concreta; las funciones personales sólo se revelan si las has registrado explícitamente en código o metadatos.

Multisig frente a recuperación social

La multisig y la recuperación social difieren en el momento y la finalidad de la participación colectiva. En multisig, el quórum opera constantemente: cada operación de gasto requiere m de n aprobaciones. El modelo distribuye la responsabilidad entre los participantes, establece reglas de confirmación reproducibles y permite diferentes umbrales para distintas clases de operaciones. En la recuperación social, las transferencias diarias proceden como single-sig, y la participación colectiva se activa cuando se pierde una clave. Los guardianes confirman un cambio de propietario dentro de un procedimiento predefinido con retrasos y ventanas de impugnación.

El panorama operativo también difiere: multisig distribuye la coordinación entre todos los gastos y exige disciplina de confirmación, la recuperación social concentra la coordinación en un evento de recuperación poco frecuente, e impone requisitos sobre la configuración de los activadores, los retrasos y la composición de los participantes de confianza. En el perfil de error, multisig es sensible a las violaciones del reglamento y a la indisponibilidad de parte de los firmantes dentro de la ventana de confirmación; la recuperación social es sensible a los errores de configuración y al comportamiento de los guardianes en el momento de la activación.

Monederos MPC vs Multisig

Los monederos MPC frente a multisig difieren en el control distribuido y en dos fundamentos criptográficos. El multisig clásico utiliza claves de participantes independientes y considera que una transacción es permisible cuando se alcanza el umbral m-de-n. MPC produce una única firma a través de un protocolo distribuido de tal forma que la clave completa no existe en ninguna parte individual. Externamente, una firma MPC parece una firma única ordinaria y pasa la validación estándar, mientras que multisig expone un conjunto de confirmaciones independientes o llamadas a contrato.

Los supuestos de confianza y los requisitos de coordinación difieren: multisig se basa en la independencia de las claves y en un quórum explícito, MPC se basa en la corrección del protocolo de firma conjunta y en la seguridad de los canales durante la sesión interactiva. A nivel operativo, multisig coordina a los participantes en torno a una versión estable de una propuesta, MPC coordina el cálculo de una firma y genera un único artefacto para su presentación a la red.

Casos prácticos de multisig y modelos de gobernanza

Hablando de escenarios prácticos, vamos a ordenar primero la planificación de la herencia multisig. Esto describe cómo cualquier grupo de personas, desde una familia a una organización, transfiere el control bajo condiciones predefinidas. El proceso se construye en torno a un evento desencadenante, confirmaciones del hecho, y una política de transición que opera hasta que se complete el procedimiento. Una vez registrado el suceso, el participante designado detiene las grandes operaciones y pasa a un umbral temporal suficiente para una gestión segura, pero que no permite cambios unilaterales de las normas. A continuación, el ejecutor añade nuevos firmantes según la secuencia acordada, verifica las identidades y los derechos, y anota en el registro los motivos y las marcas de tiempo. Cada cambio se refleja en la versión de la política para que el historial permanezca conectado al estado en la cadena.

Los artefactos y las instrucciones hacen que el procedimiento sea ejecutable. El paquete de documentos incluye una lista de contactos, una breve descripción de las funciones y los umbrales para el periodo de transición, la lista de confirmaciones necesarias, una lista de comprobación de finalización y una operación de prueba para validar la nueva política. Una vez finalizada, el ejecutor registra la versión final de la política, lo notifica a los participantes y vuelve a las clases habituales de operaciones. Este procedimiento reduce el riesgo operativo y elimina la improvisación cuando están en juego los plazos de acceso y decisión.

Multisig para familias

Las finanzas familiares se enfrentan a riesgos simples pero críticos: una persona no está disponible, se pierde un teléfono, se bloquea una tarjeta, alguien tiene prisa y se equivoca en los detalles. También hay tareas de ahorro conjunto, control de grandes transferencias y preparación para transferir el acceso sin que cunda el pánico. Multisig para familias resuelve esto mediante la toma de decisiones distribuida y un registro transparente: la familia no depende de una sola clave, ve la ruta de aprobación y puede acordar de antemano las normas para las reservas.

¿Cómo configurar un monedero Multisig para familias?

• Tipos de operaciones. Separe la rutina y la reserva para que cada categoría tenga su propio umbral y ventana de validez. Para los gastos cotidianos, elija un m pequeño, fije una ventana corta, limite el importe y la frecuencia para que los pagos no se estanquen y no arrastren innecesariamente a todos los participantes. Para grandes transferencias y acceso a ahorros, fije un m más alto, aumente la ventana y exija que se especifiquen las bases y el material de apoyo. Para cambiar la política en sí, establezca el umbral más estricto, separe la aprobación de normas de las operaciones de gasto y fije un intervalo obligatorio entre la propuesta y la aplicación para que los participantes tengan tiempo de hacer una comprobación significativa.
• Roles. Asigne un iniciador que formule la propuesta y sea responsable de que los atributos estén completos y sean correctos; un certificador que coteje la finalidad, el importe y los detalles con la clase de operación y los límites, registre el resultado de la comprobación y el motivo de la denegación en caso necesario; firmantes que lleven las confirmaciones al quórum dentro de la ventana y utilicen un canal independiente para verificar los detalles críticos; un observador que supervise el registro, controle la versión de la política y señale las condiciones límite, como una ventana que expira o una confirmación que falta. Excluir la combinación de atestación y confirmación final en una sola persona para operaciones de la clase de reserva.
• Comunicaciones. Fije el canal de aprobación principal para el trabajo rutinario y uno de reserva en caso de fallo, describa la regla de escalada cuando uno de los participantes no esté disponible y la espera máxima permitida para cada clase. Acuerde la sincronización horaria para que los participantes interpreten de la misma manera el inicio y el final de la ventana de validez; de lo contrario, las confirmaciones atrasadas entrarán en el registro y provocarán falsos conflictos. Establecer la regla de emitir una nueva versión de la propuesta para cualquier edición de parámetros, de forma que las confirmaciones ya recogidas no se transfieran al contenido modificado.
• Descripción de la operación. Utilice un formato único: clase, finalidad, importe, dirección de destino, periodo de validez de la propuesta, identificador de la versión de la política, enlace a los materiales de apoyo. Añada la etiqueta de autor y la hora de publicación para distinguir las propuestas recreadas y excluir la reutilización de confirmaciones antiguas. En el registro, anote las firmas entrantes con el participante y la hora, el resultado de la atestación y el resultado de la finalización. Este formato acelera las comprobaciones, reduce la probabilidad de errores y proporciona una imagen reproducible de los acontecimientos.
• Comprobación de preparación. Antes de pasar a la rutina, realice un simulacro con pequeñas cantidades de todas las clases. Genere escenarios tanto de éxito como de rechazo: un intento de confirmar después de que expire la ventana, el envío de una propuesta con detalles editados sin una nueva versión, y la ausencia de un participante dentro de la indisponibilidad permitida.

Los criterios de disponibilidad son sencillos

• el quórum se alcanza dentro de la ventana;
• el registro contiene la cadena completa desde la emisión hasta la finalización;
• escalada, y el canal de reserva funciona sin arreglos manuales;
• y los escenarios rechazados entran correctamente en el registro con las razones.

Multisig para pequeñas empresas

Para las pequeñas empresas, la multisigencia puede aportar beneficios aún mayores, separando la intención de gastar y el derecho a aprobar, vinculando el pago a los documentos primarios y preservando la continuidad del proceso durante las vacaciones y las sustituciones, entre otras cosas. No se trata sólo de control, sino también de reproducibilidad: cada decisión se basa en atributos uniformes, y la auditoría recibe un vínculo entre el evento de pago y el origen de la obligación.

¿Cómo configurar un monedero Multisig para pequeñas empresas?

• Funciones. Asigne un iniciador con el deber de adjuntar un documento primario y especificar el proyecto o centro de costes, defina un certificador de los parámetros del contrato que compruebe los campos obligatorios y el cumplimiento de las condiciones, y deje la confirmación final al responsable del presupuesto dentro de unos límites. Incluya incompatibilidades de roles en el reglamento para que la misma persona no inicie, atestigüe y apruebe el mismo pago, y describa el orden de sustitución para periodos vacacionales sin cambiar la composición de claves y el umbral base.
• Tipos de pagos. Procese los pagos regulares con un umbral simplificado y una ventana corta si existe una base correcta y no hay desviaciones. Traslade los gastos imprevistos a un tipo independiente con un certificado adicional y un conjunto ampliado de campos obligatorios, y aumente el umbral si el importe supera el límite típico. Procese los tramos grandes con un umbral aumentado y una ventana ampliada, verifique los detalles críticos a través de un canal independiente y registre el resultado de la verificación en el registro para excluir disputas.
• Enlace con la contabilidad. Incluya en la descripción el identificador de la aplicación, un enlace a las etiquetas del contrato o pedido, proyecto o centro de costes, para que la contabilidad y el control interno puedan cotejar el movimiento con la obligación. Registre la versión de la política, el resultado de la certificación, la composición de las confirmaciones con marcas de tiempo y el resultado de la finalización. Muestrear periódicamente las propuestas rechazadas y analizar los motivos: incumplimiento del límite, atributos incompletos, falta de la ventana, etc. Estas revisiones permiten perfeccionar las listas de comprobación y reducir la proporción de errores sin aumentar los umbrales.
• Continuidad. Defina de antemano las ventanas del calendario de aprobación, una lista de contactos de guardia y el procedimiento de reasignación temporal de funciones dentro del umbral establecido para que el proceso no se paralice por la ausencia de un empleado. Sincronice las reglas de huso horario para los equipos distribuidos; de lo contrario, los participantes interpretarán de forma diferente el final de la ventana. Compruebe en un periodo de prueba que la sustitución de un rol no otorga a un participante poderes incompatibles con su función y no viola las restricciones de límites.
• Control. Mantenga una métrica sencilla de la disciplina de pagos: el porcentaje de propuestas rechazadas en la atestación, el porcentaje de confirmaciones atrasadas y el tiempo medio para alcanzar el quórum por clase. Estos indicadores muestran rápidamente dónde es necesario aclarar la normativa y dónde basta con revisar los límites o las ventanas. Cuando el registro y las métricas se alinean, el ciclo de pago deja de depender de una sola persona o dispositivo y soporta fallos normales sin detener las operaciones.

Riesgos de los monederos multisig y buenas prácticas para la seguridad multisig

Por supuesto, ninguna tecnología es perfecta y obliga a hacer concesiones de un modo u otro.

• Los principales riesgos residen en las capas humana y de procesos. Los participantes confirman la propuesta equivocada, se precipitan e ignoran la ventana de validez, confunden la dirección de destino o la clase de operación. La ingeniería social y el compromiso de los canales de comunicación conducen a la sustitución de detalles después de la atestación. La pérdida de un dispositivo o de una frase semilla sin la escalada oportuna da tiempo a un atacante, y la indisponibilidad de un participante en un momento crítico impide alcanzar el quórum. Estos sucesos parecen mundanos, pero son exactamente los que más a menudo se materializan en pérdidas.
• Elección incorrecta del umbral y la composición de los participantes. Un umbral m demasiado bajo reduce la colusión requerida y permite a un pequeño grupo pasar por alto los intereses de los demás, mientras que la colusión requerida es formalmente c = m. Un umbral m demasiado alto crea fragilidad y provoca tiempos muertos operativos en caso de indisponibilidad normal, y la tolerancia a la indisponibilidad es igual a u = n menos m. La ausencia de un umbral separado para cambiar la política abre la posibilidad de relajar discretamente las reglas mediante el mismo procedimiento que los pagos cotidianos. El desajuste de las zonas horarias y una semántica no fija de la hora de inicio de la ventana producen falsos rechazos y la reutilización de confirmaciones caducadas.
• También es posible que se produzcan fallos técnicos y organizativos. Por ejemplo, a nivel de ejecución, pueden manifestarse como desincronización de versiones de propuestas, la reutilización de confirmaciones, la ausencia de vinculación de una firma al hash de la versión actual y la etiqueta de dominio de la política, errores en la validación de firmantes permitidos y derechos excesivos para un único participante. Los mensajes separados en diferentes canales sin un identificador de operación único crean espacio para la sustitución inadvertida; por lo tanto, el identificador debe estar presente tanto en la descripción como en los registros de atestación. Los simulacros no formalizados y la ausencia de un registro de atestación privan a una familia o empresa de una base probatoria, convirtiendo el análisis de incidentes en una disputa sobre los hechos.
• La observabilidad en cadena da lugar a una clase distinta de implicaciones. Los patrones característicos de confirmaciones y finalizaciones permiten a un observador externo reconstruir el ritmo de las operaciones y la importancia relativa de los acontecimientos, especialmente si los participantes publican metadatos en canales abiertos con antelación. Esto por sí mismo no resuelve la privacidad a nivel de implementación, pero las implicaciones afectan a la seguridad: las ventanas y cantidades predecibles aumentan el valor de los ataques dirigidos a roles específicos.

Buenas prácticas para la seguridad multisig

Un funcionamiento eficaz empieza por la disciplina a la hora de describir y comprobar las operaciones. Para cada propuesta, registre la clase, el propósito, la cantidad, la dirección de destino, el periodo de validez, un identificador de operación único y el identificador de la versión de la política. Vincule las firmas al hash de esta versión y a la etiqueta de dominio de la política, e invalide las confirmaciones ya recogidas para cualquier edición de parámetros. El certificador comprueba no sólo los campos formales, sino también la coincidencia de contexto: el origen de la obligación, el límite de clase y la necesidad de verificación independiente de los detalles. Para las transferencias críticas, utilice una regla de dos canales: el iniciador y el certificador confirman los detalles a través de una línea de comunicación independiente antes de recoger las firmas.

La separación de funciones reduce la probabilidad de error y abuso por parte de una sola persona. El iniciador no atestigua sus propias propuestas, el propietario del presupuesto no inicia ni realiza atestaciones para el mismo pago, y el observador no realiza acciones que afecten a la consecución del quórum. Para cambiar la propia política, aplique un umbral independiente más estricto y una ventana ampliada, así como un retraso en la entrada en vigor, para que los participantes tengan tiempo de evaluar las consecuencias. En el trabajo diario, mantenga el ritmo: ventanas cortas y un m pequeño para operaciones rutinarias, mayores requisitos para reservas y grandes cantidades.

La higiene de dispositivos y secretos sigue siendo básica pero obligatoria. Cada firmante utiliza un dispositivo y un contexto distintos, no comparte soportes y no transfiere una frase semilla entre perfiles. La política de actualización prevé comprobaciones periódicas del firmware, y los detalles se verifican en una pantalla de dispositivo de confianza antes de firmar. Los canales de aprobación describen el procedimiento para cambiar a una ruta alternativa y los criterios de escalado, incluido el tiempo de espera máximo permitido para cada clase, mientras que el hecho del escalado y el motivo se registran en el registro. El registro de eventos mantiene un rastro completo: emisión, atestación, confirmaciones por participante, finalización, motivos de rechazo y vencimiento de la ventana, así como la versión de la política y el identificador de la operación.

Por último, la mensurabilidad convierte la normativa en un proceso gestionable. Haga un seguimiento de la proporción de propuestas rechazadas, la proporción de confirmaciones atrasadas, el tiempo medio hasta el quórum por clase y la proporción de propuestas recreadas. Estas métricas muestran dónde las normas son demasiado estrictas y crean fragilidad, y dónde necesitan reforzarse. Los ensayos periódicos sobre pequeñas cantidades incluyen escenarios negativos y confirman que los canales de escalada y reserva funcionan, y que los participantes interpretan la versión de la política y la semántica de la ventana de la misma manera. Este enfoque mantiene los riesgos a nivel operativo y hace que las normas sean reproducibles sin estar vinculadas a productos o proveedores específicos.

Conclusión

Ahora ya sabe lo que es un monedero criptográfico de custodia compartida y una de sus implementaciones, un monedero multisig. Pero aún más importante, no sólo conoce las ventajas, sino también los riesgos y las mejores prácticas para la seguridad multisig. Así, podrá aplicarlo de forma mucho más razonable y eficaz en una amplia gama de escenarios, ya sea multisig para familias, multisig para pequeñas empresas, etc., y hacer que su gestión de criptoactivos sea realmente coordinada, transparente y segura. Permanezca atento a las últimas actualizaciones y oportunidades en la nueva economía, la industria criptográfica y los desarrollos de blockchain.

¿Qué es una Cartera Multisig en Cripto?

Se trata de una política m-de-n: de n participantes permitidos, se requieren al menos m firmas para gastar fondos. El monedero almacena la composición de los participantes y el umbral, formaliza cada operación como una propuesta con parámetros y un periodo de validez, y vincula las firmas al hash de esta versión. El gasto sólo es posible cuando se alcanza el quórum.

¿Cuáles son los riesgos o inconvenientes de los monederos multisig?

Los principales son los errores humanos y de proceso: firmar la versión incorrecta, confirmar después de que expire la ventana, confusión de detalles o canales de comunicación débiles. Una elección incorrecta de m da lugar a una baja colusión requerida o a una fragilidad debida a la falta de disponibilidad de las personas. La coordinación requiere tiempo y disciplina; los registros y las pruebas de funcionamiento son obligatorios; de lo contrario, el análisis de incidentes se convierte en una disputa.

¿Cómo funciona un Multisig 2-de-3?

Tres personas participan en la política; se requieren las firmas de dos de ellas. El sistema tolera la indisponibilidad de un participante: u = n menos m = 1. El gasto no autorizado requerirá la colusión de dos: c = m = 2. El cambio de la política en sí suele pasar por un umbral separado, más estricto, y no se mezcla con las operaciones de gasto.

¿Qué ocurre si un firmante pierde su dispositivo o su clave?

Si el quórum m aún es alcanzable, se inicia la escalada: se limitan temporalmente las operaciones grandes, se emiten propuestas para sustituir la clave, se actualiza la versión de la política, se anotan los pasos en el registro y se utiliza una operación de prueba para verificar. Si m es inalcanzable, se utiliza un modo transitorio predefinido con un umbral temporal hasta que se complete la sustitución.

¿Puedo utilizar monederos hardware en una configuración multisig?

Sí. Los monederos hardware almacenan claves privadas con los firmantes y confirman la firma en el dispositivo, mientras que la permisibilidad de la operación sigue estando determinada por el quórum m-de-n. Las firmas están vinculadas al hash de la versión actual de la propuesta y a la etiqueta de dominio de la política, lo que reduce el riesgo de compromiso sin cambiar el modelo de acceso.

¿Cuál es la diferencia entre Bitcoin Multisig y Smart-Contract Multisig en Ethereum?

En Bitcoin, el multisig se implementa por script en la propia transacción a nivel de protocolo, por lo que las confirmaciones son visibles como una entrada de multisig. En Ethereum, los monederos inteligentes multisig trasladan la lógica al contrato: almacena la política y las propuestas, contabiliza las confirmaciones y, mediante eventos, muestra el ciclo propuesta-confirmación-finalización. La flexibilidad es mayor gracias a la programabilidad, y la observabilidad pasa por los registros de llamadas.