Transacciones Solana V1 llegan a testnet, con el objetivo de consolidar operaciones multi-paso en una sola

El 1 de septiembre, Anza inició la transacción V1 en la testnet de Solana, permitiendo el ensayo final de esta actualización antes de su lanzamiento el 9 de septiembre.

El cambio tiene como objetivo permitir que las cargas de trabajo criptográficas y DeFi, que inicialmente debían fragmentarse en diferentes transacciones, se procesen ahora en una única transacción atómica, tal como indica Solana Compass.

Las operaciones que antes se dividían ahora caben en una sola llamada

La alteración más notable es el aumento del espacio. El tamaño máximo de una transacción serializada de Solana ha aumentado de 1.232 bytes a 4.096 bytes, lo que representa un incremento de 3,3 veces y entró en vigor en la época 1025 de la testnet.

Según el sitio web dedicado a la actualización de grandes transacciones de la Fundación Solana, dicho tamaño de transacción permitirá implementar pruebas de conocimiento cero, transacciones multisig grandes junto con varios esquemas de firma que no eran posibles dentro de una sola transacción.

En consecuencia, se deben procesar menos transacciones, se requiere menos dinero para pagar las firmas y no es necesario esperar una cadena de confirmaciones. Los esquemas de firma BLS, así como las transacciones confidenciales y las configuraciones multisig se beneficiarán de esta actualización.

Existen dos propuestas principales esenciales para la mejora. SIMD-0296 aumenta el tamaño de la transacción de 1.232 bytes a 4.096 bytes, mientras que SIMD-0385 define el formato de mensaje V1 y traslada la configuración de la transacción al propio mensaje.

Menos de un día después de activarse la actualización, Brennan Watt, CEO de Anza publicó en X mencionando una gran transacción en el explorador de testnet con el mensaje: “ATENCIÓN: las grandes transacciones han llegado a la testnet.”

Por qué una transacción supera a un paquete

La importancia de la atomicidad radica en que, en ocasiones, los desarrolladores eludieron el antiguo límite de tamaño de Solana mediante paquetes Jito. De hecho, SIMD-0296 explica este workaround y también menciona que los paquetes carecen de atomicidad a nivel de protocolo, al igual que ocurre con una transacción nativa.

Según la documentación de Jito, los bundles pueden incluir hasta cinco transacciones procesadas secuencialmente bajo una base de todo o nada. Sin embargo, los bundles operan dentro del block-engine de Jito y compiten entre propinas a validadores. Por otro lado, la transacción V1 se refiere a una única transacción nativa de Solana, que cuenta con la garantía de atomicidad a nivel de transacción de Solana.

Para los desarrolladores de DeFi, esto puede ayudar a simplificar la creación de rutas de intercambio, pruebas y otros tipos de transacciones multietapa. Si la operación está completamente cubierta por la transacción V1, ya sea tiene éxito o se devuelve como una única transacción nativa en lugar de depender de un paquete de transacciones.

Qué obtiene DeFi más allá de los bytes extra

V1 también modifica la estructura de la transacción. Mientras que Legacy y V0 gestionan las tarifas por prioridad y las solicitudes de recursos mediante instrucciones ComputeBudget, SIMD-0385 incorpora estas configuraciones en las configuraciones de transacción de V1, simplificando así la tarea de los validadores al identificar las necesidades de recursos sin tener que buscar activamente en la lista de instrucciones.

V1 elimina además las Tablas de Búsqueda de Direcciones (ALT), utilizadas por V0 para acortar las direcciones de las cuentas. Según el análisis de la Fundación sobre el equilibrio de ALT en V1 , V1 realiza la colocación de direcciones directamente en línea. Esto facilita la entrada del validador en comparación con el método utilizado en aplicaciones intensivas de cuentas en V0, que consumen más bytes al convertirse.

El beneficio práctico para los routers y agregadores DEX es que ahora hay más espacio para rutas atómicas complejas. Sin embargo, esta mejora no está exenta de limitaciones. De hecho, la capacidad máxima de Solana de 64 cuentas distintas sigue sin cambios, por lo que las aplicaciones que requieren un uso intensivo de cuentas aún pueden verse afectadas por esta limitación, incluso si el límite de capacidad en bytes ya no es un problema.

La actualización se introduce mientras Solana da un salto hacia las finanzas on-chain. El informe sobre Solana correspondiente al segundo trimestre de 2026 proporcionado por Galaxy muestra un aumento en la actividad de stablecoins, acciones tokenizadas y activos del mundo real.

Según Galaxy, en el futuro, el potencial de Solana dependerá en gran medida de la capacidad de utilizar activos en préstamos, colateralización, margen y rendimiento, en lugar de solo emisión o comercio. Basado en los datos de DeFiLlama sobre Solana, la plataforma parece tener una fuerte presencia en DeFi.

Además, el momento de la actualización coincide con la fase de actualización Agave 4.2. Informativamente, Cryptopolitan declaró que se esperaba que el plan para la implementación gradual de la reducción de costos generara ahorros de aproximadamente el 90%, junto con una disminución del tiempo necesario para el procesamiento de 500 a 200 milisegundos, lo que traería beneficios a los emisores de stablecoins, proveedores de billeteras y sistemas de pago.

Los operadores de RPC tienen una semana para actualizar

V1 es opcional, por lo que las transacciones Legacy y V0 siguen funcionando. El problema radica en si la infraestructura que lee el tráfico V1 está preparada.

Anza ha obligado a los proveedores de RPC a migrar a Agave v4.2.2 o v4.3.0-beta.3. La lista de verificación de migración de Helius Agave 4.2 también enfatiza que los consumidores de RPC que no declaren cumplimiento V1 pueden experimentar fallos en llamadas como getBlock cuando se utiliza una transacción V1.

El proceso comenzó con pruebas locales de V1 el 24 de agosto, poco después de lo cual se confirmó la fecha de mainnet como el 9 de septiembre el 29 de agosto. V1 habilitó Testnet el 1 de septiembre en el epoch 1025, con una activación programada en mainnet el 9 de septiembre.

Esta última ejecución en testnet sirve como el último paso preparatorio para proveedores de RPC, indexadores, billeteras, SDKs y plataformas analíticas antes del lanzamiento en mainnet.