Por Canuto  

Solana activó Transaction V1 en mainnet con un límite de 4.096 bytes, una ampliación que permite reunir operaciones DeFi, pruebas de conocimiento cero y multisig más grandes en una sola transacción atómica. El cambio también obliga a actualizar infraestructura clave y plantea una pregunta decisiva: ¿más capacidad se convertirá realmente en más uso y liquidez?
***

  • Transaction V1 elevó el tamaño máximo de las transacciones de Solana desde 1.232 hasta 4.096 bytes.
  • La actualización permite concentrar más instrucciones y datos en una sola operación atómica, con utilidad para DeFi, pruebas ZK y multisig.
  • Validadores, operadores RPC, indexadores y wallets deben adaptar su infraestructura para leer, firmar y procesar el nuevo formato.

Solana eleva a más de tres veces el tamaño de sus transacciones con Transaction V1

Solana activó Transaction V1 en su mainnet al comienzo del epoch 1035, alrededor de la 01:00 UTC del 15 de septiembre de 2026, según la información publicada sobre la actualización de la red. La nueva versión amplía el tamaño máximo de una transacción serializada desde 1.232 hasta 4.096 bytes, con lo que los desarrolladores obtienen espacio adicional para agrupar operaciones complejas en un solo proceso atómico.

El cambio interesa especialmente a los equipos que construyen aplicaciones de finanzas descentralizadas, wallets, indexadores y servicios RPC, porque modifica tanto la estructura de los mensajes como la manera de leer determinados parámetros. Transaction V1 también fue activada en testnet y devnet antes de llegar a mainnet, mientras los proveedores de infraestructura terminan de ajustar sus sistemas al formato.

Un límite de tamaño mucho más amplio

Durante años, Solana mantuvo un límite de 1.232 bytes para las transacciones, vinculado a restricciones conservadoras de la unidad máxima de transmisión de la red. Transaction V1 rompe con ese límite estricto dentro del flujo de comunicación basado en QUIC y permite transportar mensajes más grandes, una modificación que eleva el espacio disponible a más de tres veces el anterior.

El nuevo formato quedó definido en SIMD-0296, mientras que la estructura del mensaje V1 se apoya en SIMD-0385. Aunque la ampliación no aumenta por sí misma la cantidad de usuarios ni garantiza mayor actividad económica, sí elimina una barrera técnica que obligaba a ciertos desarrolladores a dividir sus operaciones en varias transacciones.

Las pruebas de conocimiento cero se encuentran entre los casos de uso que pueden beneficiarse del espacio adicional, debido a la cantidad de datos que deben incluir o verificar. También podrían encajar mejor las operaciones multisig de gran tamaño y las transacciones con firmas BLS, que anteriormente podían superar con facilidad el límite disponible.

La implementación llegó después de una fase de preparación en testnet, donde V1 se lanzó durante el epoch 1025, el 1 de septiembre. Ese periodo permitió que operadores de infraestructura y proveedores de servicios comprobaran la compatibilidad antes de la activación en mainnet, reduciendo el riesgo de que wallets o sistemas de análisis recibieran mensajes que no podían interpretar.

Más acciones dentro de una sola transacción

El principal atractivo para los desarrolladores no es solamente enviar más bytes, sino ejecutar más instrucciones y datos dentro de una misma operación atómica. En aplicaciones DeFi, por ejemplo, una ruta de enrutamiento, la comprobación de una prueba y un proceso de agrupación pueden completarse juntos o fallar como una unidad, en lugar de repartirse entre varias transacciones.

Antes de V1, algunos equipos resolvían las limitaciones dividiendo una operación en varias transacciones o recurriendo a bundles de Jito. Sin embargo, la documentación asociada con SIMD-0296 distingue un bundle de una transacción nativa, porque el primero no ofrece la misma atomicidad a nivel del protocolo que una única operación de la red.

La diferencia puede tener consecuencias prácticas para las aplicaciones que dependen de que varios pasos ocurran en un orden inseparable. Cuando una operación se distribuye entre transacciones separadas, una parte puede confirmarse antes de que otra falle; con V1, más componentes pueden quedar dentro del mismo conjunto indivisible, aunque cada aplicación seguirá enfrentando sus propios límites de cómputo y disponibilidad de cuentas.

La actualización también puede reducir, en algunos casos, la cantidad de firmas y confirmaciones necesarias para completar una acción. No obstante, esa ventaja dependerá del diseño de cada protocolo, de la complejidad de sus instrucciones y de la capacidad de los operadores para procesar correctamente el nuevo mensaje, por lo que una mayor capacidad técnica no equivale automáticamente a una experiencia más sencilla para todos los usuarios.

El costo de abandonar las tablas de búsqueda

Transaction V1 cambia la forma en que las transacciones gestionan las referencias a cuentas y recursos. A diferencia del formato anterior, las transacciones V1 prescinden de las Address Lookup Tables y escriben las cuentas referenciadas directamente en el mensaje, mientras el límite máximo de 64 cuentas permanece sin cambios.

Esta decisión simplifica la lectura de las cuentas incluidas, pero aumenta el tamaño de cada referencia: una Address Lookup Table v0 puede representar una cuenta mediante un índice de un byte, mientras una clave pública escrita en línea ocupa 32 bytes. Por ello, una transacción densa que utilice varias tablas puede crecer en más de 1.500 bytes cuando traslada sus referencias al formato directo.

Un análisis citado en la cobertura de Cryptopolitan indicó que el 62% de las transacciones v0 utilizaba al menos una Address Lookup Table. Ese dato muestra que el nuevo espacio disponible no debe interpretarse como capacidad completamente libre, porque determinados tipos de transacción consumirán una parte importante de los 4.096 bytes al incluir sus claves públicas directamente.

V1 también reubica las configuraciones del límite de cómputo y las tarifas de prioridad desde las instrucciones ComputeBudget hacia la configuración de la transacción. Para los proveedores de infraestructura, esa disposición puede facilitar el acceso a los parámetros, pero exige actualizar indexadores y lectores que todavía esperan encontrar esa información en la estructura anterior.

La infraestructura deberá adaptarse

Los lectores RPC deben configurar maxSupportedTransactionVersion: 1 en los métodos getTransaction y getBlock para procesar correctamente las nuevas transacciones. Los indexadores, por su parte, deben leer los límites de cómputo y las tarifas de prioridad desde transactionConfig, una modificación que puede afectar los flujos de análisis y los sistemas que muestran datos de actividad en tiempo real.

Los validadores y operadores RPC necesitan ejecutar Agave v4.2.2 o una versión posterior, de acuerdo con la guía de actualización de Solana. Las versiones RPC anteriores pueden degradar los mensajes V1 a v0 e informar de manera incorrecta los presupuestos de cómputo, lo que produciría datos inconsistentes o fallas al interpretar el comportamiento de una aplicación.

Los remitentes de transacciones V1 deben establecer de forma explícita los límites de cómputo y de cuentas cargadas, además de utilizar codificación base64 para transacciones que superen los 1.232 bytes. El requisito será relevante para los equipos que construyen herramientas de envío automatizado, ya que una aplicación que no ajuste esos campos podría presentar errores aunque el protocolo admita el nuevo tamaño.

Los proveedores de wallets también tendrán que verificar que su software pueda analizar y firmar correctamente el formato antes de anunciar compatibilidad. La transición, por tanto, no termina con la activación del feature gate: requiere coordinación entre validadores, RPC, indexadores, wallets y desarrolladores para evitar que una transacción válida en la red falle en algún punto de la cadena de herramientas.

Capacidad adicional en medio de la expansión tokenizada

La llegada de V1 coincide con un periodo de expansión de Solana en las finanzas on-chain. Según una actualización publicada por Solana, a finales de julio de 2026 la red albergaba USD $3.700 millones en activos del mundo real no vinculados a stablecoins, distribuidos entre aproximadamente 313.000 tenedores.

Una transacción más grande puede facilitar la creación de productos que combinan varias instrucciones, cuentas y verificaciones dentro de un único flujo. Esa posibilidad resulta especialmente importante para protocolos DeFi, sistemas de liquidación, soluciones de pagos y aplicaciones de activos tokenizados, aunque el beneficio final dependerá de la liquidez, la demanda y la disposición de los usuarios a emplear esos productos.

La capacidad, sin embargo, no garantiza adopción. Transaction V1 amplía el abanico de aplicaciones posibles, pero no resuelve por sí sola el desafío de atraer actividad sostenida, liquidez y usuarios. La utilidad efectiva dependerá de que los proyectos conviertan el espacio adicional en productos competitivos y de que el ecosistema pueda actualizarse sin introducir errores.

Qué puede venir después de la activación

El siguiente paso será observar si los desarrolladores convierten el espacio adicional en aplicaciones que antes resultaban difíciles o costosas de implementar. Las pruebas ZK más grandes, las estructuras multisig complejas y las operaciones DeFi con varios pasos ofrecen escenarios concretos para medir si la nueva capacidad produce una mejora visible en costos operativos, coordinación y experiencia de usuario.

También será necesario evaluar cómo responden los servicios que dependen de datos completos y consistentes. Un RPC que no reconoce V1, un indexador que lee mal el presupuesto de cómputo o una wallet que no puede firmar el mensaje pueden convertirse en puntos de fricción, incluso cuando los validadores principales ya estén preparados para procesarlo.

La eliminación de las Address Lookup Tables introduce además un equilibrio que cada desarrollador tendrá que revisar. V1 simplifica la inclusión explícita de cuentas y permite transacciones más grandes, pero el costo de escribir claves públicas de 32 bytes puede consumir rápidamente el espacio disponible en aplicaciones que manejan muchos participantes.

La pregunta central para Solana será si esta mejora de infraestructura se traduce en más usuarios, más liquidez y más transacciones útiles. Transaction V1 resuelve una restricción concreta del formato y abre nuevas posibilidades de diseño, pero la adopción dependerá de que los proyectos construyan productos competitivos y de que el ecosistema pueda actualizarse sin introducir errores en el camino.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


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