El 18 de julio de 2024, SSP Wallet v1.6.0 añadió Ethereum — y SSP se convirtió en la primera billetera en lanzar verdaderas cuentas Schnorr-multisig en Ethereum usando Account Abstraction ERC-4337. Otras billeteras se autodenominan "Ethereum multisig" apilando una sola cuenta de propiedad externa detrás de una interfaz. SSP eligió el camino difícil, para que el mismo modelo 2-de-2 que protege a Bitcoin dentro de SSP proteja ahora también a ETH.
TL;DR
- Ethereum (ETH) se une a SSP como cadena de primera clase.
- Las cuentas son contratos inteligentes que siguen ERC-4337, no EOA — así la aplicación 2-de-2 vive en la cadena.
- Dos firmas Schnorr se agregan en una sola antes de llegar a Ethereum, manteniendo el gas predecible.
- La biblioteca de firma es de código abierto en npm:
@runonflux/aa-schnorr-multisig-sdk. - El soporte para tokens ERC-20 es el siguiente paso; esta versión es ETH en sí más los fundamentos de AA por debajo.
Lo que llegó: soporte de Ethereum, por el camino difícil
La mayoría de las billeteras "soportan Ethereum" generando una cuenta de propiedad externa (EOA) — una sola clave privada, una sola firma, un solo punto de fallo. Añadir multisig encima suele significar una política de software del lado de la billetera, no una regla impuesta en la cadena. La cadena sigue viendo una clave, y quien la posee puede mover fondos por sí solo.
SSP rechazó ese atajo. El sentido del modelo 2-de-2 de SSP es que ni SSP Wallet en el escritorio ni SSP Key en el teléfono puedan mover fondos por sí solos — la cofirma es una propiedad de la cuenta, no una convención de la interfaz. Para preservar eso en Ethereum, una EOA nunca iba a ser suficiente. La cuenta Ethereum tenía que ser un contrato inteligente que exija dos firmas por construcción. Eso es exactamente lo que se lanzó en v1.6.0.
Qué significa aquí Schnorr multisig
Los scripts UTXO de Bitcoin pueden expresar 2-de-2 de forma nativa — así es como las cadenas actuales de SSP imponen la cofirma. El modelo de cuentas de Ethereum no puede, no sin ayuda. SSP cierra esa brecha con firmas Schnorr.
Schnorr es un esquema de firma con una propiedad que importa aquí: dos firmantes pueden producir cada uno una firma parcial, y esas parciales pueden combinarse en una única firma válida que se verifica bajo una sola clave pública agregada. Para cualquier observador de la cadena, parece que un único firmante firmó una vez. Para SSP, dos dispositivos tuvieron que estar de acuerdo. La profundidad criptográfica — agregación de claves, coordinación de nonces, rondas estilo MuSig2 — está cubierta en nuestro artículo de la academia sobre firmas Schnorr y agregación multisig si la quieres. El resumen para el usuario es corto: el mismo apretón de manos SSP Wallet + SSP Key que ya usas, ahora expresado como una firma Schnorr agregada en Ethereum.
Account Abstraction ERC-4337
Account Abstraction (AA) es el término paraguas para permitir que las cuentas de Ethereum se comporten como billeteras programables en lugar de meros pares de claves. Bajo el modelo estándar de Ethereum hay dos tipos de cuenta: EOA, controladas por una única clave privada, y contratos, que no pueden iniciar transacciones por sí mismos. AA disuelve esa distinción en la capa de aplicación.
ERC-4337 es el estándar de Ethereum que entrega AA sin cambiar Ethereum en sí. En lugar de un hard fork, define un objeto de transacción de nivel superior llamado UserOperation, un bundler que las convierte en transacciones normales de Ethereum, y un contrato EntryPoint que las valida. Tu "cuenta" es un contrato inteligente que decide cómo quiere autenticar los gastos — para SSP, esa regla de autenticación es: una firma Schnorr agregada de SSP Wallet y SSP Key, o nada. Sin hard fork de L1, sin operadores de nodos especiales, sin supuestos de confianza fuera de lo ya desplegado en mainnet.
La biblioteca de código abierto
La capa de firma Schnorr-multisig no está enterrada dentro de la app SSP. La extrajimos como una biblioteca reutilizable y la publicamos bajo la misma postura de código abierto que el resto de SSP. El SDK de TypeScript vive en npm como @runonflux/aa-schnorr-multisig-sdk; los contratos de Account Abstraction en Solidity con los que se empareja viven en el repositorio @runonflux/account-abstraction en GitHub.
Si eres desarrollador de billeteras, investigador de seguridad o simplemente sientes curiosidad por cómo se compone realmente AA Schnorr-multisig en Ethereum, ambos proyectos están ahí para leer, hacer fork y contribuir de vuelta. Las pull requests y los issues son bienvenidos — preferimos endurecer una biblioteca compartida con más ojos que dejar que cada billetera que quiera esta primitiva la reinvente.
Lo que esto desbloquea
Para v1.6.0 específicamente, la cadena que se ofrece es Ethereum en sí — saldos ETH, transferencias ETH, el mismo interruptor del panel Chains que usas para cualquier otra moneda, ahora con una cuenta AA por detrás. La fontanería que asienta esta versión es la parte más difícil. Una vez que las cuentas Schnorr AA 2-de-2 existen y funcionan, todo saldo con forma de Ethereum se vuelve alcanzable.
El soporte para tokens ERC-20 es el siguiente paso natural, y ya está en la hoja de ruta — lo cubriremos en su propio post de newsroom cuando se lance. Por hoy, el titular es que Ethereum está en SSP, está en SSP de la forma correcta, y los fundamentos criptográficos y de contratos inteligentes que hay debajo son de código abierto en npm y GitHub para que cualquiera los inspeccione.