Solana lanzará Transaction v1 esta semana: el tamaño máximo de las transacciones aumentará a 4096 bytes

Solana activará oficialmente la función Transaction v1 en la mainnet el miércoles 9 de septiembre, ampliando el tamaño máximo de las transacciones de 1.232 bytes a 4.096 bytes, más del triple; esta actualización está definida por dos propuestas de mejora de Solana: SIMD-0296 (transacciones más grandes) y SIMD-0385 (formato Transaction v1).

Especificaciones técnicas de Transaction v1

Transaction v1 está definida conjuntamente por dos propuestas de mejora de Solana: SIMD-0296 establece un límite de transacción mayor y SIMD-0385 define el formato de Transaction v1. Ambas propuestas fueron redactadas conjuntamente por Jacob Creech y Andrew Fitzgerald. La nueva función ha funcionado de forma estable durante cierto tiempo en la testnet y la devnet, y se activó oficialmente en la mainnet el 9 de septiembre de 2026.

Transaction v1 está diseñada para ser compatible con versiones anteriores, por lo que el formato v0 existente seguirá siendo válido; los monederos y las aplicaciones solo adoptarán el formato v1 cuando necesiten más espacio para las transacciones, sin que sea necesaria ninguna migración.

Los tres tipos de transacciones que más se benefician directamente de Transaction v1

Tras ampliar el tamaño máximo de 1.232 bytes a 4.096 bytes, los siguientes tres tipos de transacciones obtendrán los beneficios más directos:

Pruebas criptográficas de gran tamaño: los datos de verificación, como las pruebas ZK, a menudo tenían que dividirse en varias transacciones debido al límite de 1.232 bytes; Transaction v1 permite enviar todos los datos de verificación ZK en una sola transacción.

Procesos de aprobación multifirma: las transferencias de fondos que requieren la aprobación de varios firmantes, como las de tesorerías empresariales o propuestas de DAO, consumen espacio con cada firma; v1 permite completar el proceso de aprobación multifirma dentro de una sola transacción.

Transferencias confidenciales: algunos mecanismos de transacciones privadas requieren capas adicionales de cifrado, y la capacidad anterior provocaba fallos o reducía la eficiencia de las transacciones; los 4.096 bytes proporcionan espacio suficiente para este tipo de operaciones.

Por qué se estableció el límite de 4.096 bytes

El límite de 4.096 bytes (4 KB) responde a consideraciones de hardware: ese es el tamaño estándar de las páginas de memoria utilizadas por los nodos validadores; si una sola transacción ocupa varias páginas de memoria, el coste de procesamiento aumenta considerablemente, lo que perjudica el mantenimiento del alto TPS (transacciones por segundo) de Solana; por tanto, 4 KB representa el punto de equilibrio entre ampliar la capacidad y mantener el rendimiento de la red.

El antiguo límite de 1.232 bytes procedía del diseño de red inicial de Solana: cada transacción debía caber en un paquete IP de aproximadamente 1.280 bytes; en 2022, Solana ajustó la forma de transmitir el tráfico de transacciones, por lo que ese límite estricto dejó de ser necesario, y el lanzamiento de Transaction v1 elimina oficialmente esta limitación histórica de diseño.

Actualizaciones necesarias para los nodos RPC y los servicios de lectura

Transaction v1 afecta más a los servicios que leen datos on-chain que a los que escriben transacciones. Todos los servicios que obtienen datos de bloques y transacciones —nodos RPC, proveedores de datos on-chain y backends de monederos— deben actualizar su código; de lo contrario, devolverán directamente un error al encontrarse con transacciones en formato v1.

Otro efecto concreto se produce en la ubicación del campo de la comisión prioritaria (priority fee): v1 almacena la información de la comisión prioritaria en un campo diferente al de v0, por lo que el software antiguo mostrará «comisión cero» al leer transacciones v1, aunque el usuario haya pagado realmente una comisión prioritaria; si las interfaces de los monederos, los exploradores de blockchain y las aplicaciones de transacciones no se actualizan, los usuarios verán información inexacta sobre las comisiones.

Comparación de capacidad con Ethereum

Desde la perspectiva del diseño del protocolo, Ethereum no tiene un límite de tamaño de transacción en la capa del protocolo; los desarrolladores pueden ejecutar operaciones con un uso intensivo de datos dentro de una sola transacción siempre que paguen una comisión de gas más alta; en el pasado, Solana tenía limitaciones evidentes en cuanto a cuántas instrucciones podía contener una sola transacción. Tras elevar el límite a 4.096 bytes, Transaction v1 reduce la diferencia entre ambas cadenas, pero 4.096 bytes sigue sin ser una cifra grande para Ethereum L1: una transacción compleja de combinación DeFi en Ethereum, como un arbitraje entre varios pools o préstamos y devoluciones de varios activos, suele superar esa cifra.

La importancia técnica práctica para el ecosistema de Solana reside en que elimina los workarounds para desarrolladores: cuando antes era necesario dividir las operaciones en varias transacciones, había que gestionar las dependencias de estado entre transacciones y las reversiones en caso de fallo; Transaction v1 permite completar lógicas complejas en una única operación atómica, acercándose más a los modelos tradicionales de programación.

Preguntas frecuentes

¿Cuál es la fecha de lanzamiento de Solana Transaction v1, cómo cambia la capacidad máxima y qué propuestas la definen?

Solana Transaction v1 se lanzó en la mainnet el miércoles 9 de septiembre de 2026, ampliando el tamaño máximo de las transacciones de 1.232 bytes a 4.096 bytes (más del triple); la actualización está definida por SIMD-0296 y SIMD-0385, redactadas conjuntamente por Jacob Creech y Andrew Fitzgerald, y anteriormente ya funcionaba de forma estable en la testnet y la devnet.

¿Por qué se estableció el límite de 4.096 bytes en esta cifra y no en una superior?

4.096 bytes es el tamaño estándar de las páginas de memoria utilizadas por los nodos validadores; si una sola transacción ocupa varias páginas de memoria, el coste de procesamiento aumenta considerablemente, lo que perjudica el mantenimiento del alto TPS de Solana; 4 KB representa el punto de equilibrio entre ampliar la capacidad y mantener el rendimiento de la red.

¿Cómo deben actualizarse los nodos RPC y los servicios de lectura, y cuál es el efecto concreto del cambio en el campo de la comisión prioritaria?

Todos los servicios que obtienen datos de bloques y transacciones deben actualizar su código; de lo contrario, devolverán directamente un error al encontrarse con transacciones v1; la ubicación del campo de la comisión prioritaria de v1 es diferente a la de v0, por lo que el software antiguo mostrará «comisión cero» al leerlas, aunque el usuario haya pagado una comisión prioritaria, y los monederos y exploradores de blockchain que no se actualicen mostrarán información inexacta sobre las comisiones.