Solana tiene como objetivo el 9 de septiembre para la Transacción v1, un nuevo formato que eleva el tamaño máximo de transacción serializada de 1,232 bytes a 4,096 bytes.
El aumento brinda a los desarrolladores aproximadamente 3.3 veces más espacio para transacciones. La hoja de ruta oficial de Solana indica que la capacidad adicional puede acomodar pruebas de conocimiento cero (zero-knowledge proofs), grandes operaciones multifirma, lotes y algunos esquemas de firma en cadena.
Anteriormente, las operaciones grandes debían dividirse en varias transacciones cuando sus instrucciones, firmas e información de cuenta excedían el límite de 1,232 bytes. Ese proceso añadía complejidad porque una transacción podía tener éxito mientras otro paso fallaba.
La Transacción v1 podría permitir a los desarrolladores combinar más de esas instrucciones en una operación atómica. O bien todas las instrucciones tienen éxito, o toda la transacción falla. El modelo podría beneficiar las rutas de trading, las transferencias confidenciales, las operaciones entre cadenas y las aplicaciones que procesan pruebas criptográficas complejas.
La actualización no eleva el límite de Solana de 64 cuentas referenciadas por transacción. Las aplicaciones pueden incluir más datos e instrucciones, pero no pueden interactuar automáticamente con más cuentas.
La Transacción v1 es opcional. Las billeteras y aplicaciones pueden continuar enviando transacciones legacy y v0 bajo el límite existente de 1,232 bytes. Los usuarios no necesitan migrar tokens, intercambiar SOL o completar un reclamo antes de la activación.
Los desarrolladores deben adoptar deliberadamente el nuevo formato para acceder a su mayor capacidad. La documentación de Solana identifica tres formatos compatibles: legacy, v0 y v1. Cada formato organiza las direcciones de cuenta y los límites de recursos de manera diferente.
El formato v0 utiliza Tablas de Búsqueda de Direcciones (Address Lookup Tables, o ALTs) para representar las direcciones de cuenta a través de índices comprimidos de un byte. La V1 elimina las ALTs y coloca direcciones de cuenta completas de 32 bytes directamente dentro de la transacción.
Esto crea una compensación. La V1 proporciona un sobre general más grande, pero las aplicaciones que dependen en gran medida de las tablas de búsqueda pueden gastar más bytes representando las mismas cuentas. El análisis técnico de Solana encontró que el 90% de las transacciones muestreadas añadirían menos de 1,400 bytes al convertirse de v0 a v1.
El principal riesgo de compatibilidad se aplica a los servicios que leen bloques y transacciones. Los proveedores de llamadas a procedimiento remoto (Remote procedure call providers) deben establecer su versión máxima de transacción compatible en uno. De lo contrario, las solicitudes podrían fallar al encontrar una transacción v1.
Los indexadores, exploradores y servicios de análisis también deben cambiar la forma en que recuperan los límites de recursos. Las transacciones legacy y v0 colocan los límites de cómputo y la configuración de tarifas de prioridad dentro de las instrucciones ComputeBudget. La V1 los almacena en una configuración de transacción dedicada.
Por lo tanto, los servicios desactualizados podrían mostrar información incorrecta. Por ejemplo, un explorador podría mostrar una tarifa de prioridad de cero aunque el usuario haya pagado una. Los patrocinadores de tarifas y las aplicaciones que verifican los límites de las transacciones deben leer la nueva configuración en lugar de escanear instrucciones antiguas.
Las aplicaciones que envían transacciones v1 deben establecer explícitamente los límites de unidades de cómputo (compute-unit) y datos cargados (loaded-data) porque ambos por defecto son cero. Los desarrolladores deben probar la construcción, firma y decodificación de transacciones antes de mover el tráfico de producción al formato.
El vicepresidente de Tecnología de la Fundación Solana, Jacob Creech, identificó el 9 de septiembre como la fecha prevista para la mainnet. Como informó previamente crypto.news, la actualización está incluida en el lanzamiento de Agave 4.2 de Anza.
Sin embargo, la hoja de ruta oficial todavía etiqueta la función de la mainnet como "no activada". También dice que el cronograma de lanzamiento de Anza es "tentativo y sujeto a cambios". Testnet y devnet ya han activado la función, según la última página de estado de la Fundación.
El aumento de tamaño proviene de SIMD-0296, mientras que SIMD-0385 define el formato v1. Jacob Creech y Andrew Fitzgerald son coautores de ambas propuestas.
El límite de 4,096 bytes se seleccionó en parte porque cuatro kilobytes coinciden con un tamaño de página de memoria común utilizado por el hardware del validador. Las transacciones más grandes también consumirán ancho de banda adicional, aunque la actualización no introduce una tarifa separada cobrada por byte.
La Transacción v1 sigue siendo independiente de las reducciones de alquiler (rent reductions) de Solana, los objetivos de slot más cortos (shorter slot targets) y el rediseño de consenso Alpenglow. En cobertura relacionada, crypto.news informó que Alpenglow apunta a una finalidad de aproximadamente 150 milisegundos, siendo octubre un objetivo de desarrollo en lugar de una fecha de activación garantizada.
SOL