Nonces duraderos: firma con dos dispositivos en Solana

SSP es una billetera 2 de 2. Cada transacción necesita dos firmas: una de la Wallet, la extensión de navegador en tu computadora, y otra de SSP Key en tu teléfono. Ese diseño es la clave de todo: un ladrón que roba un dispositivo aún no puede mover tus fondos. Pero introduce un problema muy humano. La computadora construye y firma una transacción en una fracción de segundo. El teléfono puede tardar dos o tres minutos más en cofirmar, porque una persona tiene que tomar el teléfono, mirar la solicitud y tocar aprobar.

En Solana, ese intervalo es un problema. Este artículo explica por qué, y cómo lo resuelve SSP sin guardar nada frágil.

El blockhash que caduca

Toda transacción normal de Solana lleva un dato llamado blockhash reciente. Es la huella de un bloque reciente de la cadena, y cumple dos funciones a la vez. Prueba que la transacción se creó hace poco e impide que la misma transacción firmada se reproduzca para siempre.

El truco está en la palabra reciente. Un blockhash solo es válido durante unos 150 bloques. En Solana los bloques llegan rápido, así que 150 bloques son apenas unos 60 a 90 segundos. Pasada esa ventana, la red rechaza la transacción de plano, no porque haya algo mal en las firmas, sino porque el blockhash está caducado.

Ahora pon el flujo de firma de SSP contra ese reloj. La Wallet construye la transacción, fija un blockhash nuevo y firma. Luego se notifica al usuario en su teléfono. Si responde en 90 segundos, perfecto. Si está en una reunión, el teléfono está en otra habitación, o simplemente quiere leer la transacción con calma, el blockhash muere en silencio. La firma de la Wallet sigue siendo criptográficamente válida, pero la transacción a la que iba adjunta ya no vale nada. Hay que reconstruirla y refirmarla desde cero.

Para una billetera de un solo firmante que firma y transmite de un tirón, la ventana de 90 segundos es generosa. Para una billetera 2 de 2 donde un humano se interpone entre las dos firmas, es una carrera que el usuario sigue perdiendo.

Qué es un nonce duradero

Solana tiene una respuesta integrada para esto, y es anterior a SSP: el nonce duradero. La idea es reemplazar el blockhash que caduca por un valor que no caduca.

Un nonce duradero vive en su propia cuenta pequeña en la cadena: una cuenta de nonce. Esta cuenta pertenece al sistema, guarda solo 80 bytes de datos, y uno de esos datos es el valor del nonce en sí: un sustituto de larga vida para un blockhash. Una transacción puede construirse para usar el valor de la cuenta de nonce en lugar de un blockhash reciente. Como ese valor no envejece, la transacción sigue siendo válida todo el tiempo que haga falta: minutos, horas, días.

Sin embargo, nada es gratis, y un nonce necesita una protección contra la repetición. Esa protección es una regla: toda transacción que use un nonce duradero debe llevar una instrucción específica, nonceAdvance, como su primera instrucción. Cuando la transacción finalmente se confirma, nonceAdvance consume el valor actual del nonce y rota la cuenta a uno nuevo. El nonce es de un solo uso. La transacción que firmaste el lunes puede esperar hasta el miércoles, pero una vez que se ejecuta, ese nonce exacto nunca podrá autorizar otra transacción. Si quieres leer la propia descripción de Solana del mecanismo, la documentación de nonces de transacción duraderos es la fuente primaria.

Así, un nonce duradero compra tiempo sin comprar un riesgo de repetición. Esa es exactamente la propiedad que necesita una billetera de dos dispositivos.

El giro de SSP: una cuenta de nonce que nunca tienes que guardar

Una cuenta de nonce duradero sigue siendo una cuenta, y en Solana toda cuenta tiene una dirección. El enfoque ingenuo es crear una cuenta de nonce en alguna dirección aleatoria y luego recordar cuidadosamente esa dirección para siempre: escribirla en el almacenamiento local de la billetera, respaldarla, esperar que sobreviva a un reinicio del dispositivo. Eso es una cosa frágil más que perder.

SSP se niega a guardarla. En cambio, el programa multifirma de SSP para Solana incluye una instrucción llamada provision_nonce, y crea la cuenta de nonce en una dirección derivada. La dirección proviene de una receta determinista: se calcula a partir de la propia cuenta multifirma, la etiqueta de texto fija "nonce" y el Programa del Sistema de Solana. La misma multifirma de entrada, la misma dirección de nonce de salida, siempre.

Esto importa por lo que el resto de esta serie ya ha establecido. La multifirma de SSP para Solana deriva la dirección de la multifirma del conjunto de miembros, y deriva la dirección de la bóveda de la multifirma. (Si esas derivaciones te resultan nuevas, el artículo multisig autoiniciada de Solana las recorre.) La cuenta de nonce ahora se une a la misma familia: también es una derivación pura. Cualquier dispositivo SSP —tu computadora, tu teléfono, una billetera recién reinstalada— puede recalcular la dirección de la cuenta de nonce desde cero. No hay dirección secreta que perder, porque no hay ninguna dirección guardada.

De este diseño se siguen algunas notas prácticas. provision_nonce es permissionless: cualquiera puede pagar la pequeña renta (unos 0,00144 SOL) para hacer existir la cuenta de nonce, y quien paga se convierte en su autoridad inicial; en la práctica, el paymaster del relay de SSP. Esa autoridad puede reasignarse después sin que la dirección de la cuenta cambie nunca, así que la dirección que derivas hoy sigue siendo correcta aunque rote la clave operativa que hay detrás. La ubicación de la cuenta de nonce está anclada a tu multifirma, no a quien la haya financiado.

El flujo de firma tranquilo

Une las piezas y la carrera desaparece. La Wallet construye una transacción que usa la cuenta de nonce derivada en lugar de un blockhash reciente, coloca nonceAdvance como primera instrucción y firma. Una notificación push llega al teléfono. El usuario aprueba cuando esté listo: no hay reloj corriendo en su contra. SSP Key añade la segunda firma, y la transacción completamente firmada se transmite. Como se construyó sobre un nonce duradero, sigue siendo válida, y nonceAdvance rota el nonce para que la transacción no pueda reproducirse.

Hay una restricción más que vale la pena nombrar. Solana limita una sola transacción a 1232 bytes. Una transacción multifirma tiene que encajar la lista de miembros y las instrucciones de gasto dentro de ese límite, por eso SSP usa el formato compacto de transacción versionada de Solana y pasa los datos lo más ajustados posible. El nonce duradero no cambia el presupuesto de tamaño; solo cambia el presupuesto de tiempo.

Derivar todo, no guardar nada

Este es el hilo que recorre toda la serie Multifirma en Solana, a la manera de SSP. La dirección de la multifirma, la bóveda que guarda tus fondos y ahora la cuenta de nonce que da a dos dispositivos tiempo para ponerse de acuerdo: ninguna es un valor que SSP tenga que guardar y proteger. Cada una se recalcula bajo demanda a partir de entradas que la billetera ya conoce. Hay menos que respaldar, menos que filtrar y menos que pueda salir mal en un reinicio de dispositivo. Los diseños de multifirma que se apoyan en esta idea, como el enfoque de multifirma de un solo firmante de SSP, tienden a ser los que tienen menos piezas móviles que se rompan.

Una nota final con el mismo espíritu de honestidad que el resto de la serie: el programa multifirma de SSP para Solana está actualmente desplegado solo en devnet, y está pendiente de una auditoría de seguridad externa antes de cualquier lanzamiento en mainnet. El diseño descrito aquí —incluyendo provision_nonce y su cuenta de nonce derivada— es real y se puede leer en el programa de código abierto, pero todavía no es infraestructura de producción. Si el modelo de dos dispositivos de SSP es nuevo para ti, el artículo introductorio qué es la multifirma 2 de 2 es el lugar para empezar.

El nonce duradero es una pieza pequeña y antigua de la fontanería de Solana. La contribución de SSP es convertir su dirección en una cosa más que nunca tienes que recordar.