Solana activa Transaction V1 y eleva el tamaño máximo de las transacciones a 4,096 bytes
Puntos clave
- •Transaction V1 entró en funcionamiento al inicio de la época 1035, aproximadamente a las 01:00 UTC del 15 de septiembre.
- •El tamaño máximo de las transacciones serializadas ahora es de 4,096 bytes, cerca de 3.3 veces el límite anterior de 1,232 bytes.
- •La actualización permite ejecutar el enrutamiento, la verificación de pruebas y el procesamiento por lotes dentro de una sola transacción atómica a nivel del protocolo.
- •V1 incluye directamente las referencias a cuentas en lugar de utilizar Address Lookup Tables, lo que podría añadir más de 1,500 bytes a las transacciones densas, mientras el límite de cuentas permanece en 64.
- •Los validadores y operadores de RPC deben utilizar Agave v4.2.2 o una versión posterior, mientras que los lectores de RPC, indexadores, emisores y billeteras requieren compatibilidad y configuración específicas para V1.

Solana activó la función Transaction V1 en su mainnet el martes, lo que permite incluir más datos en cada transacción. La actualización brinda a los desarrolladores espacio adicional para ejecutar acciones complejas dentro de un solo proceso atómico y es relevante para desarrolladores de DeFi, proveedores de billeteras, indexadores y operadores de RPC. También puede afectar a proyectos que trabajan con activos tokenizados y soluciones de pago.
Según la página de actualizaciones de Solana, el feature gate txv1 se implementó al inicio de la época 1035, aproximadamente a las 01:00 UTC del 15 de septiembre. Transaction V1 ya está activa en la mainnet, testnet y devnet de Solana.
El tamaño de las transacciones aumenta de 1,232 a 4,096 bytes
El cambio más visible es el aumento del tamaño máximo de una transacción serializada. Solana elevó el límite de 1,232 bytes a 4,096 bytes, lo que proporciona aproximadamente 3.3 veces más espacio para los datos de las transacciones.
El formato de la nueva transacción fue definido en SIMD-0296, mientras que el V1 Message Format se basa en SIMD-0385. Anteriormente, el límite de tamaño de las transacciones de Solana estaba vinculado a restricciones conservadoras de la unidad máxima de transmisión de la red, o MTU. Transaction V1 se aleja del límite estricto sobre el tamaño de los flujos impuesto por QUIC, lo que permite transacciones más grandes.
La capacidad adicional está destinada a soportar cargas de trabajo que requieren grandes cantidades de datos de transacción, incluidas pruebas de conocimiento cero, operaciones multisig de gran tamaño y firmas que utilizan BLS. Como informó anteriormente Cryptopolitan, V1 se lanzó en la testnet en la época 1025, el 1 de septiembre, lo que dio tiempo a los proveedores de infraestructura para prepararse para el lanzamiento en la mainnet.
Por qué importa una sola transacción atómica
Antes de la actualización, los desarrolladores que encontraban el límite de tamaño de las transacciones de Solana podían, en algunos casos, dividir sus operaciones entre varias transacciones o utilizar paquetes de Jito. Sin embargo, la explicación incluida en SIMD-0296 señala que un paquete no equivale a una transacción nativa cuando se considera la atomicidad a nivel del protocolo.
Transaction V1 permite incluir más instrucciones y datos en una sola transacción. Como resultado, el enrutamiento, la verificación de pruebas y el procesamiento por lotes pueden completarse todos correctamente o fallar todos, en lugar de ejecutarse en transacciones separadas. Dependiendo de la operación, esto también podría reducir la cantidad de firmas y confirmaciones necesarias.
Compensación de las Address Lookup Tables
Transaction V1 también cambia la forma en que las transacciones gestionan los recursos y las referencias a cuentas. La configuración del límite de cómputo y de las comisiones prioritarias se trasladó de las instrucciones de ComputeBudget a la configuración de la transacción, lo que facilita el acceso de los proveedores de infraestructura a esos parámetros.
Las transacciones V1 no utilizan Address Lookup Tables porque las cuentas referenciadas se incluyen directamente en la transacción. Esto simplifica la estructura de la transacción, pero puede aumentar su tamaño. Una Address Lookup Table v0 requiere solo un índice de un byte, mientras que una clave pública incluida directamente requiere 32 bytes.
Un análisis de las Address Lookup Tables de Solana encontró que el 62% de las transacciones v0 utilizaba al menos una Address Lookup Table. En consecuencia, las transacciones densas que utilizan más de una tabla podrían aumentar en más de 1,500 bytes cuando las referencias a cuentas se incluyen directamente. El límite de cuentas permanece sin cambios en 64 cuentas.
Papel en la expansión de las finanzas tokenizadas de Solana
La actualización llega mientras Solana amplía su papel en las finanzas on-chain. Según DeFiLlama, el valor total bloqueado en el sector DeFi de Solana se acerca a los $5.95 mil millones, mientras que su volumen de exchanges descentralizados en 24 horas es de aproximadamente $1.79 mil millones.
El resumen de agosto de Solana también indicó que el valor de los activos del mundo real en la red había superado los $4 mil millones y estaba distribuido entre más de 350,000 direcciones. Además, xStocks había acumulado más de $500 millones en activos bajo gestión.
Una mayor capacidad de transacción por sí sola no garantiza un aumento en la adopción. Galaxy Research ha observado que una parte significativa del valor almacenado en los tokens de Solana permanece sin utilizar, mientras que las plataformas competidoras continúan liderando en algunas áreas de rápido crecimiento. Transaction V1 amplía el rango de aplicaciones que los desarrolladores pueden crear en Solana, pero la respuesta posterior de los usuarios, la liquidez y la actividad de transacciones sigue siendo una pregunta abierta.
Cambios requeridos para operadores y desarrolladores
Los lectores de RPC deben configurar maxSupportedTransactionVersion: 1 para getTransaction y getBlock. Los indexadores deben leer los límites de cómputo y las comisiones prioritarias de V1 desde transactionConfig.
Los validadores y operadores de RPC deben ejecutar Agave v4.2.2 o una versión posterior. Los emisores de V1 deben configurar explícitamente los límites de cómputo y de cuentas cargadas, y utilizar base64 para transacciones de más de 1,232 bytes.
Los proveedores de billeteras solo deben anunciar compatibilidad con V1 después de confirmar que su software puede analizar y firmar correctamente el nuevo formato, de acuerdo con las directrices de actualización de Solana. El informe original fue publicado por Cryptopolitan.