La propuesta de firma fuera de línea de Solana mantendría las aprobaciones válidas después de transacciones fallidas

El plan de Solana para retirar los nonces duraderos, que permiten que las transacciones sean firmadas fuera de línea y transmitidas más tarde, preservaría la aprobación de claves frías mientras cambia qué direcciones controlan los activos afectados. Para intercambios, custodios y operadores de tesorería que utilizan ese método de firma, el reemplazo propuesto agrega un programa entre la aprobación de la clave fría y la ejecución.

El plan de desuso de octubre de la Fundación Solana apunta a programas de firmantes en cadena que verifican una firma fuera de línea y ejecutan sus instrucciones aprobadas. Una dirección derivada de programa, o PDA, controlaría las cuentas afectadas. La clave original seguiría autorizando acciones, mientras que un operador en línea separado las envía y paga la tarifa de la red.

El reemplazo crea una arquitectura de custodia diferente: los operadores deben migrar los activos o permisos relevantes, las aplicaciones deben aceptar acciones que lleguen a través de otro programa, y los equipos de riesgo deben aprobar el nuevo camino de firma.

Los nonces duraderos siguen siendo utilizables. La Fundación no ha establecido una fecha de eliminación ni ha tomado una decisión final entre el Firmante Programático de Anza y el Vector de Blueshift. Su ventana de migración de aproximadamente seis meses es condicional a que un reemplazo adecuado esté listo, auditado y en vivo en la mainnet.

La clave sigue aprobando, pero la cuenta cambia

Los nonces duraderos resuelven un problema de tiempo. En lugar de firmar una transacción vinculada a un blockhash reciente que pronto expira, un firmante fuera de línea puede aprobar uno utilizando un nonce almacenado. Eso permite que la aprobación y la transmisión ocurran en diferentes momentos.

La actualización de slot separada de 200 ms de Solana alcanzó su etapa final en mainnet el 9 de octubre. La producción de bloques más rápida deja menos tiempo de reloj para las aprobaciones basadas en blockhash ordinarias, aunque la expiración depende de la producción de bloques en lugar de un temporizador garantizado. La cobertura anterior de CryptoSlate examinó ese cambio de tiempo; la propuesta de nonce concierne a la arquitectura utilizada para evitar la corta ventana de aprobación.

Bajo el Firmante Programático, la clave fría firma un mensaje de autorización en lugar de la transacción enviada a la red. Un relayer coloca esa aprobación en una transacción de blockhash fresco. El programa firmante verifica la autorización y ejecuta las instrucciones aprobadas con la dirección derivada de la clave como firmante.

La PDA no tiene una clave privada propia. Su capacidad para actuar proviene del programa firmante que verifica la aprobación de la clave original. Derivar la dirección no mueve ningún activo o permiso: estos deben ser transferidos por separado.

La guía de migración describe mover SOL nativo a la dirección derivada, transferir saldos de tokens a cuentas controladas por ella, y mover permisos de acuñación o congelación a ella. Las cuentas de participación pueden mover la autoridad del staker, la autoridad de retiro o ambas, dependiendo del permiso que se esté migrando. Estos son controles separados, en lugar de un único interruptor de billetera universal.

La Fundación propone completar esas transferencias mientras los nonces duraderos heredados aún funcionan. Para una tesorería afectada, aprobar el nuevo software de firma es, por lo tanto, solo parte del trabajo. Su inventario de cuentas y los permisos que cada clave posee actualmente determinan qué debe cambiar.

Los dos diseños candidatos también manejan SOL nativo de manera diferente. La cuenta SOL derivada del Firmante Programático es de propiedad del Sistema y puede enviar SOL a través de una transferencia ordinaria aprobada. Vector inicializa una cuenta de propiedad del programa y libera SOL a través de su propia operación de retiro o cierre autorizada.

Lo que la firma fría permite a un relayer hacer

La elección de implementación afecta cuán estrictamente una aprobación restringe la transacción a su alrededor.

La documentación del mensaje del Firmante Programático dice que las firmas en frío vinculan al ejecutor, la cuenta nonce y el mensaje de ejecución embebido. Un relayer no puede alterar esos bytes autorizados mientras retiene firmas válidas. Sin embargo, puede elegir el pagador de tarifas externo y el blockhash, y agregar instrucciones antes o después de la presentación.

Vector se compromete al búfer de instrucciones de nivel superior, incluyendo los datos y cuentas utilizados para pasar acciones aprobadas a otros programas. Las instrucciones que rodean esas acciones deben estar ya incluidas cuando la clave fría firma. Un relayer no puede insertar, eliminar o reordenarlas después sin invalidar la aprobación.

El Firmante Programático permite que un contexto de ejecución se ensamble alrededor de una acción aprobada; Vector requiere que la secuencia de instrucciones circundantes sea aprobada de antemano. En ambos casos, pagar por la difusión no otorga permiso para reescribir la acción firmada.

Un intento de ejecución fallido puede dejar una aprobación en frío ejecutable más tarde. Una transacción de nonce duradero actual que pasa la validación pero falla durante la ejecución aún consume su nonce. La arquitectura del Firmante Programático compromete el avance del nonce y los cambios de aplicación juntos, o los revierte juntos. Vector documenta la misma capacidad de reintentar una acción fallida.

Para los operadores, la reintentabilidad significa que una presentación fallida no ha invalidado necesariamente la aprobación. Sin una fecha límite impuesta, puede permanecer disponible para una ejecución posterior mientras su nonce no cambie.

Vector advierte explícitamente que un relayer podría retener una transacción hasta que cambien las condiciones, o que una firma expuesta por un intento fallido podría ejecutarse más tarde. Un tiempo de espera incluido en las instrucciones firmadas puede rechazar la ejecución después de una fecha límite. La revocación requiere un avance de nonce autorizado por separado para aterrizar. Un rechazo por fecha límite en sí mismo no consume un nonce cuyos cambios se revierten con la transacción fallida.

El acceso a la aplicación es una prueba de custodia separada

La razón de la Fundación es simplificar el manejo de los validadores. Los nonces duraderos requieren reglas especiales de prevención de repetición, complican la ejecución asíncrona y hacen que las transacciones inválidas sean más difíciles de filtrar. Mover la aprobación y el estado de repetición a programas ordinarios deja a los validadores procesando transacciones normales de blockhash.

Las aplicaciones luego reciben acciones aprobadas a través de la invocación entre programas, o CPI: un programa llama a otro. Eso puede entrar en conflicto con la regla de una aplicación de que una acción debe llegar directamente como una instrucción de nivel superior. Las verificaciones que solo inspeccionan instrucciones de reembolso de nivel superior o de verificación de firma también pueden perder una acción anidada dentro del programa firmante.

Una mayor profundidad de llamada disponible no resuelve una regla que rechaza la posición de la llamada o no puede inspeccionar las instrucciones anidadas. La Fundación sugiere apoyar programas firmantes conocidos u ofrecer otro camino de ejecución. Si una aplicación acepta la firma de un PDA es, en consecuencia, una pregunta diferente de si la aprobación fuera de línea es criptográficamente válida.

El CPI Guard de Token-2022 muestra por qué la compatibilidad necesita una evaluación precisa a nivel de cuenta. Con el guardia habilitado, las transferencias y quemas de CPI requieren autoridad delegada; las aprobaciones a través de CPI están prohibidas, y cambiar el propietario está prohibido incluso fuera de CPI. Los delegados permanentes tienen excepciones de transferencia y quema.

Esas reglas son más específicas que una prohibición general sobre cada acción de PDA. Puede existir una ruta de transferencia basada en delegados, pero establecer o usar esa autoridad introduce su propia decisión de permiso y política de custodia.

Las preocupaciones institucionales planteadas en marzo se centraron en el acceso a la aplicación y los controles bajo los cuales pueden moverse los fondos. En la discusión del 4 de marzo, un participante que se identificó como Michael de Fireblocks apoyó la deprecación de nonce mientras objetaba a la migración de CPI Passthrough, la dependencia del contrato y las cargas de compatibilidad de DeFi. Favoreció los sobres de transacción, con Sudo como alternativa, en lugar de la propuesta ruta de firma basada en CPI.

Grant, quien se identificó como de la Unidad 410, dijo el mismo día que un pequeño programa de firmante auditable podría hacer que la migración de autoridad fuera aceptable. Rechazó una solución alternativa que mueve temporalmente activos a un firmante caliente, incluso para una operación atómica, porque los fondos deben permanecer asociados con el almacenamiento en frío en su modelo no custodial.

Un diseño comprobable aún necesita un camino de migración a producción

La documentación actual del Programmatic Signer informa sobre el despliegue de devnet y auditorías en progreso, con remediación requerida antes de su lanzamiento v1 y cualquier despliegue en mainnet. Sus interfaces pueden cambiar. La documentación de uso aún marca la simulación y la presentación de relés como "próximamente", mientras que varias operaciones de migración están igualmente sin terminar en la guía.

Vector publica código de implementación e IDs de programas; su README no indica un estado de auditoría o despliegue en mainnet.

Mientras tanto, el kit de incorporación de protocolo actual de Fireblocks aún describe la inyección automática de nonce duradero para integraciones seleccionadas de WalletConnect, incluyendo Jupiter y Kamino, con una ventana de validez gestionada por el proveedor de 15 minutos por defecto. Eso describe un flujo de trabajo de aprobación existente que un reemplazo debe acomodar.

Una migración operativa necesita un reemplazo en mainnet auditado, herramientas utilizables y caminos de aplicación que mantengan los controles de aprobación de cada operador.