Multisig en EVM a la manera de la abstracción de cuentas

El multisig es fácil de describir —exigir más de una firma para mover fondos— pero la forma en que se construye difiere notablemente entre cadenas. En Bitcoin, el multisig está integrado en el propio protocolo. En Ethereum y otras cadenas EVM, no lo está, y ese único hecho determina cómo funciona toda cartera multisig seria en Ethereum, incluida SSP. Este artículo explica por qué el multisig en EVM es diferente, ofrece un recorrido en lenguaje sencillo por las herramientas de account abstraction que lo hacen posible, y muestra exactamente cómo SSP logra un verdadero 2-de-2 en Ethereum.

Si llegas aquí desde el inicio de la serie EVM, Ethereum en SSP sienta las bases; este artículo es la inmersión profunda en la mecánica de seguridad que hay debajo. El nivel de lectura aquí sube un peldaño —intermedio— porque hacerle justicia al tema implica tratar ERC-4337 y la agregación de firmas con honestidad, sin rodeos.

Por qué el multisig en EVM difiere del multisig en Bitcoin

La forma más clara de entender SSP en Ethereum es ver primero por qué el enfoque de Bitcoin no puede simplemente copiarse.

Bitcoin tiene multisig de script nativo. El protocolo incluye un opcode que te permite bloquear fondos detrás de una regla como "dos cualesquiera de estas tres claves públicas deben firmar". Una dirección multisig en Bitcoin es simplemente una dirección con esa regla de gasto adjunta, y la red la aplica directamente. SSP usa esto en Bitcoin y las demás cadenas UTXO mediante el multisig de script BIP-48: dos claves, un script, ambas firmas requeridas. Si este modelo base es nuevo para ti, qué es el multisig 2-de-2 es el punto de partida.

Ethereum no tiene un equivalente. En una cadena EVM solo existen dos tipos de cuentas. La primera es una EOA —una cuenta de propiedad externa, controlada por exactamente una clave privada—. Una clave, un firmante, sin más; no hay ningún opcode nativo para exigir dos firmas en una EOA. La segunda es una cuenta de contrato inteligente, que tiene código en lugar de una única clave de control y hace lo que ese código diga.

Así que en Ethereum, "multisig" siempre ha significado una cartera de contrato inteligente: un contrato programado para liberar fondos solo cuando se satisface su regla de múltiples firmas. Este es el modelo que carteras como Gnosis Safe / Safe popularizaron, y funciona bien. La contrapartida es que los contratos multisig clásicos en cadena suelen almacenar la firma de cada propietario y verificarlas una por una en cadena, lo que cuesta gas y crece con el número de firmantes. La account abstraction ofrece un camino más limpio, y ese es el camino que toma SSP.

Un breve y honesto resumen de ERC-4337

La account abstraction es la idea de que tu cartera debería ser un contrato inteligente —una cuenta programable— en lugar de un simple par de claves. ERC-4337 es el estándar que lo hace realidad en Ethereum sin cambiar el protocolo base. No necesitas dominarlo para usar SSP, pero algunos términos hacen que el resto de este artículo cobre sentido. Para el tratamiento completo, lee qué es la account abstraction (ERC-4337); aquí tienes el mapa a nivel de usuario.

• Smart account. Tus fondos viven en un smart account cuyo código define qué cuenta como una transacción válida. Al ser código, la cuenta puede aplicar reglas personalizadas, incluida "exigir una firma 2-de-2 válida".
• UserOperation. En lugar de enviar una transacción normal, un smart account expresa su intención como una UserOperation: una solicitud estructurada que indica qué quiere hacer y lleva los datos de firma que lo autorizan.
• Bundler. Un bundler es un servicio que recopila UserOperations, las envuelve en una transacción real en cadena y las envía. Paga el gas por adelantado y se le reembolsa; nunca obtiene la capacidad de mover tus fondos.
• EntryPoint. Un único contrato EntryPoint auditado es el coordinador de confianza en cadena. Recibe las UserOperations agrupadas y llama a cada smart account para validar y luego ejecutar su operación.
• Paymaster. Un contrato paymaster opcional puede patrocinar el gas o permitir que las comisiones se paguen en un token en lugar de la moneda nativa. Es opcional e independiente del propio multisig.

La idea clave: con un smart account, la regla de "quién puede autorizar una transacción" es software que tú controlas, no un comportamiento fijo del protocolo. Esa es exactamente la libertad que el multisig necesita en una cadena que no tiene multisig nativo.

Cómo SSP logra el 2-de-2 en EVM

SSP mantiene la misma promesa en cada cadena que admite: dos claves en dos dispositivos, y ninguno por sí solo puede mover tu dinero. La clave 1 vive en la extensión de navegador SSP Wallet; la clave 2 vive en la app móvil SSP Key. Construyes y firmas una transacción en la extensión y luego la apruebas en tu teléfono mediante un aviso push: se requieren ambas firmas.

En Bitcoin esa garantía proviene del multisig de script BIP-48. En las cadenas EVM, SSP la recrea como un smart account ERC-4337 que verifica una firma 2-de-2 agregada de Schnorr. Aquí está la idea a alto nivel, manteniéndola general donde los detalles internos exactos del contrato no son lo relevante.

Cada una de tus dos claves produce una firma parcial sobre la transacción. En lugar de enviar ambas firmas a la cadena por separado, los dos dispositivos las combinan —usando agregación de firmas al estilo MuSig2— en una única firma compacta. El smart account está programado para aceptar una UserOperation solo cuando esa firma agregada se verifica frente a la clave esperada de la cartera. La cadena, por tanto, ve una firma de aspecto corriente, y sin embargo esa firma es matemáticamente imposible de producir sin la participación de ambas claves.

Este diseño tiene ventajas reales frente a almacenar y comprobar N firmas separadas en cadena:

• Menor huella en cadena. Una firma agregada es más barata de verificar y almacenar que dos independientes, lo que tiende a significar menos gas por la seguridad que obtienes.
• UX idéntica a la de una cartera de un solo firmante. Como la cadena valida una sola firma, tu smart account se comporta como cualquier cuenta normal desde el punto de vista de la red. Enviar ETH, mover tokens ERC-20 o interactuar con DeFi se sienten igual: la segunda firma ocurre discretamente entre tus dos dispositivos.
• El mismo modelo en todas partes. Schnorr y este enfoque de agregación se basan en criptografía bien estudiada sobre secp256k1, y el mismo diseño de smart account se traslada a las cadenas EVM que SSP admite, incluidas Ethereum, Polygon, Base, BNB Smart Chain y Avalanche.

Los contratos inteligentes de SSP detrás de esto fueron auditados por Halborn en 2025. Para la mecánica más profunda de la account abstraction —cómo encajan el EntryPoint, el bundler y el paso de validación— remítete al artículo sobre account abstraction (ERC-4337) en lugar de tomar como canónico cualquier detalle aislado de contrato aquí.

Qué significa esto para ti como usuario

La criptografía es interesante, pero lo que importa en el día a día es la protección que aporta.

• Se requieren ambos dispositivos para mover fondos. Una transacción solo es válida una vez que la extensión y la SSP Key han aportado cada una su parte. Poseer un dispositivo —o una clave— no es suficiente.
• Perder un dispositivo no es perder tu dinero. Como ningún dispositivo puede firmar solo, un teléfono perdido o borrado o un navegador reinstalado no entregan a nadie el control de tus fondos. Restaurar el acceso es un tema aparte con sus propias salvaguardas; la recuperación se cubre en sus propias guías, no aquí.
• Una sola clave comprometida no es un único punto de fallo. Si malware o phishing captura lo que hay en un dispositivo, aun así no puede producir la firma 2-de-2 agregada que el smart account exige. Un atacante tendría que comprometer ambos dispositivos a la vez, un listón mucho más alto que vaciar una cartera de una sola clave.

Estas son protecciones generales, no garantías absolutas; una buena higiene de la frase semilla y la seguridad del dispositivo siguen importando. Pero el punto estructural se mantiene: dos factores independientes deben coincidir antes de que el valor se mueva.

Un contraste neutral con las carteras EOA de clave única

La mayoría de las carteras de Ethereum son EOA de clave única. Son simples y ampliamente compatibles, y para muchos usuarios están bien. La contrapartida es que una clave privada es toda la historia: quien la posea puede moverlo todo, así que una sola frase semilla filtrada o una máquina comprometida pueden ser fatales.

Un multisig de contrato inteligente cambia ese perfil de riesgo al exigir el acuerdo entre dos claves en lugar de confiar en una. Existen otras carteras multisig de contrato inteligente —Safe es un ejemplo bien conocido— y resuelven el mismo problema central a su manera. La elección particular de SSP es ofrecer el 2-de-2 mediante ERC-4337 con una firma de Schnorr agregada, de modo que obtienes la seguridad del multisig con la huella en cadena y la sensación cotidiana de una cuenta de un solo firmante.

Adónde ir después

Si quieres la base conceptual, lee qué es la account abstraction (ERC-4337) y la fundamental qué es el multisig 2-de-2. Para ver cómo encaja esto en el panorama más amplio de Ethereum en SSP, vuelve a Ethereum en SSP. Y para el estándar en sí, las fuentes canónicas son la especificación de ERC-4337 y la visión general de la account abstraction de la Ethereum Foundation. El hilo conductor es el mismo que recorre cada cadena que SSP admite: dos claves, dos dispositivos, una firma —y tú al mando—.