Por Canuto  

Solana evalúa reemplazar los nonces duraderos por programas firmantes que permitan conservar la aprobación offline. El cambio promete simplificar el trabajo de los validadores, pero también obliga a revisar permisos, compatibilidad de aplicaciones y controles para revocar aprobaciones que sobrevivan a una ejecución fallida.
***

  • La propuesta conserva la aprobación con una clave fría, pero desplaza el control de las cuentas afectadas a una dirección derivada de programa.
  • Programmatic Signer, de Anza, y Vector, de Blueshift, plantean mecanismos diferentes para limitar las instrucciones que puede transmitir un relayer.
  • La migración sigue condicionada a un reemplazo auditado y activo en mainnet; Solana no fijó una fecha definitiva para retirar los nonces.

Solana quiere reemplazar los nonces duraderos sin perder la aprobación offline

Solana analiza retirar los nonces duraderos, un mecanismo que permite aprobar transacciones sin conexión y enviarlas más adelante, pero la alternativa propuesta no elimina la firma en frío. En su lugar, incorpora programas firmantes que verificarían una autorización offline y ejecutarían las instrucciones aprobadas desde una dirección derivada de programa, lo que modifica la arquitectura de custodia de exchanges, custodios y tesorerías.

El cambio también plantea una advertencia operativa: una aprobación vinculada a una transacción que falla podría seguir disponible para un intento posterior. La Solana Foundation no ha fijado una fecha para retirar los nonces ni escogió entre los dos diseños en evaluación; su ventana de migración aproximada de seis meses depende de que exista un reemplazo adecuado, auditado y activo en mainnet, según informó CryptoSlate.

La aprobación permanece, pero cambia quién controla las cuentas

Los nonces duraderos resuelven un problema de sincronización: las transacciones habituales de Solana dependen de un blockhash reciente, cuya vigencia es limitada, mientras que un nonce almacenado permite que la firma y el envío ocurran en momentos distintos. Así, una clave guardada offline puede aprobar una operación que un operador transmite después, sin exigir que ambos pasos coincidan en una ventana breve.

La red ya completó la reducción de tiempos de bloque: los cuatro recortes previstos están activos en mainnet y el tiempo de slot es de 200 milisegundos desde el inicio de la época 1053, el 9 de octubre de 2026, según la documentación de Solana. La menor duración de cada slot puede acortar el tiempo real disponible para enviar transacciones ligadas a un blockhash reciente, cuya vigencia depende de la producción de bloques y no de un temporizador garantizado.

En el diseño llamado Programmatic Signer, la clave fría firmaría un mensaje de autorización, no la transacción que el relayer presenta directamente a la red. El programa verifica esa firma y ejecuta las instrucciones aprobadas usando como firmante una dirección derivada de programa, o PDA, mientras un operador online separado envía la transacción y paga la comisión.

Una PDA no tiene una clave privada propia: puede actuar porque el programa firmante valida la autorización de la clave original. Sin embargo, derivar esa dirección no traslada automáticamente activos ni permisos, por lo que los operadores tendrían que mover SOL, saldos de tokens y autoridades de cuentas a la nueva ruta de control, según corresponda a cada activo y configuración.

Dos diseños delimitan de forma distinta la acción del relayer

Anza propone Programmatic Signer, mientras Blueshift desarrolla Vector. La diferencia entre ambos no se limita a la implementación: determina qué partes de la transacción quedan comprometidas por la firma offline y qué margen conserva el relayer al organizar el envío.

La documentación de Programmatic Signer indica que la firma fría vincula el ejecutor, la cuenta de nonce y el mensaje de ejecución incorporado. El relayer no puede alterar los bytes autorizados y conservar una firma válida, aunque sí puede seleccionar el pagador externo de comisiones y el blockhash, además de añadir instrucciones antes o después del envío.

Vector, en cambio, compromete el búfer de instrucciones de nivel superior, incluidos los datos y las cuentas que se emplean para invocar otros programas. Las instrucciones que rodean las acciones aprobadas deben estar presentes cuando firma la clave fría, de modo que el relayer no puede insertarlas, eliminarlas ni cambiar su orden sin invalidar la aprobación.

En términos prácticos, Programmatic Signer permite ensamblar cierto contexto alrededor de una acción autorizada, mientras Vector exige que la secuencia circundante se apruebe de antemano. En ninguno de los dos casos pagar la comisión concede permiso para reescribir la acción firmada, pero la política de custodia deberá considerar qué instrucciones adicionales admite cada esquema.

Una transacción fallida podría conservar una autorización utilizable

La posibilidad de reintento es uno de los riesgos centrales para los operadores. Una transacción actual con nonce duradero que supera la validación, pero falla durante la ejecución, consume el nonce; eso impide que esa misma autorización siga disponible bajo el estado anterior.

Los diseños nuevos pueden comportarse de otra manera: el avance del nonce y los cambios de la aplicación pueden confirmarse juntos o revertirse juntos. Programmatic Signer contempla esa relación, y Vector también documenta que una acción fallida puede volver a intentarse; por eso, un envío fallido no significa necesariamente que la autorización haya quedado invalidada.

Vector advierte que un relayer podría retener una transacción hasta que cambien las condiciones, o que una firma expuesta durante un intento fallido podría ejecutarse más tarde. La documentación señala que las instrucciones firmadas pueden incluir un plazo para rechazar ejecuciones posteriores, aunque ese rechazo por sí solo no consume un nonce si los cambios de estado se revierten con la transacción fallida.

Para revocar una autorización, el operador necesitaría confirmar por separado un avance del nonce autorizado. Esto convierte los plazos y la revocación en controles de custodia, no en detalles secundarios de implementación: los equipos deben definir cuánto tiempo vale una aprobación, quién puede invalidarla y cómo se verifica que el cambio quedó confirmado.

La compatibilidad de las aplicaciones también forma parte de la custodia

La Solana Foundation presenta el reemplazo como una forma de simplificar el trabajo de los validadores. Los nonces duraderos requieren reglas especiales contra la repetición, complican la ejecución asíncrona y hacen más difícil filtrar transacciones inválidas; trasladar la aprobación y el estado de repetición a programas ordinarios permitiría procesar transacciones convencionales con blockhash.

Pero las acciones aprobadas llegarían a las aplicaciones mediante invocación entre programas, conocida como CPI, en vez de aparecer necesariamente como instrucciones directas de nivel superior. Una aplicación que solo permita ese tipo de instrucción directa podría rechazar la operación, y una verificación que inspeccione únicamente instrucciones de nivel superior quizá no detecte una acción anidada dentro del programa firmante.

La Foundation plantea que las aplicaciones puedan admitir programas firmantes conocidos o habilitar otra ruta de ejecución. La validez criptográfica de una firma de PDA no garantiza, por sí sola, que cada aplicación acepte esa autorización o que sus controles de reembolso y verificación reconozcan correctamente una llamada anidada.

El CPI Guard de Token-2022 ilustra por qué la compatibilidad requiere revisar reglas concretas. Con esa protección habilitada, el programa de extensiones rechaza ciertas instrucciones, como las transferencias, cuando otro programa onchain las invoca mediante CPI. Las reglas específicas para aprobaciones, cambios de propietario y excepciones de delegados también deben revisarse antes de definir la ruta de custodia.

La migración espera auditorías, herramientas y decisiones de los custodios

En una discusión del 4 de marzo, un participante que se identificó como Michael de Fireblocks respaldó retirar los nonces, pero cuestionó la migración mediante CPI Passthrough por su dependencia de contratos y sus exigencias de compatibilidad con DeFi. En lugar de esa ruta, defendió los sobres de transacción y mencionó Sudo como alternativa.

Ese mismo día, Grant, quien se identificó como parte de Unit 410, sostuvo que un programa firmante pequeño y auditable podría hacer aceptable el cambio de autoridad. También rechazó trasladar temporalmente activos a un firmante caliente, incluso en una operación atómica, porque en su modelo no custodial los fondos deben permanecer asociados al almacenamiento en frío.

El estado de los candidatos sigue siendo relevante antes de cualquier migración. La documentación de Programmatic Signer informa que el proyecto está desplegado en devnet y que sus auditorías continúan; requiere corregir hallazgos antes de una versión v1 y de cualquier despliegue en mainnet, mientras algunas funciones de simulación, envío mediante relayer y migración aún figuran como pendientes.

Vector publica código de implementación e identificadores de programa, pero su README no especifica un estado de auditoría ni un despliegue en mainnet. A la vez, el kit de incorporación de protocolos de Fireblocks todavía describe la inyección automática de nonces duraderos para integraciones seleccionadas de WalletConnect, entre ellas Jupiter y Kamino, con una ventana predeterminada de validez de 15 minutos gestionada por el proveedor.

Por ahora, los nonces duraderos siguen utilizables y la Foundation condiciona su eliminación a que haya un reemplazo apropiado, auditado y activo en mainnet; no hay una fecha fija de activación. Para exchanges, custodios y tesorerías, la transición requeriría validar el software, inventariar las cuentas y autoridades afectadas, y comprobar que las aplicaciones acepten la nueva ruta sin debilitar los límites de aprobación existentes.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados