El plan de nonce de Solana: la aprobación sobrevive al envío
Solana planea retirar los durable nonces sin abandonar la firma sin conexión. Las alternativas separan una autorización duradera de la transacción de vida corta que la transporta.
Ilustración conceptual generada con IA: una cápsula de autorización intacta pasa de un contenedor de envío vencido a otro nuevo. Es una metáfora, no una interfaz de cartera ni evidencia de una migración completada en Solana.
Puntos clave
- El boletín del 16 de octubre presentó el plan de retirada. No hay sustituto definitivo ni fecha fijada; el plazo de unos seis meses depende de que esté lista una alternativa adecuada.
- Una autoridad firma un mensaje sin conexión y un intermediario lo transporta en una transacción normal. Renovar el blockhash externo no exige volver a firmar la autorización.
- Los programas propuestos actúan mediante direcciones derivadas y llamadas internas. La compatibilidad, el alcance de la firma y la cancelación son cuestiones distintas.
Cronología de los hechos
El boletín de Solana Foundation del 16 de octubre enlaza el anuncio sobre durable nonces. Es un plan, no una eliminación completada.
Un calendario que depende de condiciones
Reunir aprobaciones sin conexión puede llevar más tiempo del que una transacción normal de Solana sigue siendo válida. Hoy los durable nonces resuelven esa diferencia. El boletín de Solana Foundation del 16 de octubre de 2026 enlazó un plan para retirarlos, pero la página de la actualización sigue marcada En desarrollo. Describe un programa en cadena que verifica una firma hecha sin conexión, con Programmatic Signer de Anza y Vector de Blueshift como candidatos. No elige un sustituto definitivo ni fija una fecha de retirada.[1][2]
La página prevé la retirada unos seis meses después de que esté listo un sustituto adecuado y dice que los durable nonces seguirán disponibles hasta que una alternativa esté auditada y funcione en la red principal. No es una cuenta atrás desde el anuncio de octubre. La documentación de Anza informa actualmente de un despliegue en Devnet, auditorías en curso y correcciones necesarias antes de v1 y de cualquier despliegue en la red principal; las interfaces pueden cambiar. Publicar el código y las direcciones de Vector no demuestra por sí solo un despliegue auditado en la red principal. Este artículo explica los diseños publicados, no un cambio de red ya completado.[1][4]
Qué conserva el nonce actual
Una transacción normal referencia un blockhash reciente y tiene una ventana limitada de aceptación. Una transacción con durable nonce lo sustituye por un valor guardado en una cuenta de nonce del System Program. Así, alguien puede aprobarla sin conexión y otra persona enviarla después, sin la caducidad habitual del blockhash. El valor almacenado también evita repeticiones: una transacción firmada con un nonce anterior no puede reutilizarse sin más después de que ese nonce avance.[3]
Aquí hay dos tipos de fallo. Según la documentación actual, una transacción rechazada en la validación —por ejemplo, porque el nonce ya se usó— se descarta sin comisiones ni cambios de estado. Si supera la validación pero una instrucción falla durante la ejecución, en cambio, el nonce avanza y se cobra la comisión. La acción de la aplicación puede fallar y, aun así, la transacción firmada previamente queda inutilizable. Decir que todo intento rechazado consume el nonce borraría esta distinción.[3]
La aprobación y su transporte tienen vidas distintas
Programmatic Signer divide la acción en tres capas. El mensaje de ejecución enumera las instrucciones de la aplicación. El mensaje de autorización vincula ese trabajo a un ejecutor y a una cuenta de nonce; las autoridades necesarias firman sus bytes exactos. Una transacción de envío transporta después la autorización y las firmas a la red con un blockhash reciente normal y un pagador de comisiones. Los programas verifican las firmas hechas sin conexión, avanzan su propio nonce e invocan las instrucciones aprobadas. El validador recibe una transacción normal.[4][5]
Puede imaginarse la aprobación firmada como el contenido de un sobre de envío. Si caduca el sobre, el intermediario puede preparar otra transacción y volver a firmar esa capa exterior, sin pedir nuevas firmas para la autorización interior. La analogía tiene un límite preciso: no puede editar las instrucciones aprobadas ni sustituir las cuentas incluidas en la autorización. En el formato documentado por Anza, el campo blockhash del mensaje de ejecución contiene el nonce esperado, mientras que el de la transacción exterior contiene un blockhash reciente. Los campos cumplen funciones distintas.[5]
También cambian la cuenta que actúa y el alcance de la firma
El programa actúa por la autoridad que firma sin conexión mediante una dirección derivada de programa (PDA) y llama a la aplicación mediante invocación entre programas (CPI). La cuenta de un par de claves existente y esa cuenta derivada no son identidades intercambiables. Un programa que exija llamadas de nivel superior puede rechazar esta vía. Un indexador que solo mire los firmantes de la transacción exterior puede ver al intermediario, mientras que la PDA que actúa aparece en las instrucciones internas. Admitir esta autorización exige revisar más que un campo de caducidad.[1][4]
Los candidatos difieren además en lo que fija la firma. Programmatic Signer permite añadir instrucciones antes o después de Submit, pero prohíbe alterar el interior de la autorización firmada. Vector vincula todas las instrucciones de nivel superior al resumen firmado, incluido el contenido de passthrough; el intermediario no puede añadirlas, eliminarlas ni reordenarlas después de firmar. Ambos usan protección contra repeticiones gestionada por programas y CPI, pero establecen límites distintos para el trabajo que rodea a la autorización. Ninguna descripción demuestra que una aplicación ya sea compatible.[1][5][6]
Caducar, cancelar y reintentar son hechos diferentes
Ninguno de los dos diseños publicados incorpora un plazo de caducidad para la autorización. Por tanto, que caduque la transacción de envío no cancela la autorización. Avanzar el nonce correspondiente invalida una autorización vinculada a su valor anterior; un plazo de negocio, en cambio, debe comprobarse mediante una instrucción cubierta por el contenido firmado. Mostrar una fecha en una herramienta de aprobación no basta si las reglas ejecutadas no la verifican.[1][5][6]
Los diseños también permiten conservar la autorización para otro intento si la ejecución falla, la transacción se revierte y el nonce no cambia. Eso difiere del fallo de ejecución de un durable nonce actual. No promete éxito eventual ni intentos gratuitos en la red: siguen aplicándose las comisiones normales. Al evaluar el plan, las preguntas útiles son qué se aprobó, qué cuenta actuará, qué puede invalidar la aprobación y si la aplicación receptora acepta esa vía de llamada. Foundation indica que las transacciones normales no se ven afectadas por la retirada prevista; la migración concierne a los flujos que usan durable nonces.[1][3][6][7]
Historias para seguir leyendo
Explora el tema a través de otros casos y contextos.
