Solana amplía el tamaño de las transacciones hasta 4.096 bytes
La actualización a Transaction v1 debe dar a Solana más margen para pagos complejos, multisig y pruebas de conocimiento cero. Sin embargo, las wallets y los exploradores tendrán que adaptar su software para leer correctamente las nuevas transacciones.
Puntos clave
- Solana elevará el miércoles el tamaño máximo de las transacciones de 1.232 a 4.096 bytes.
- Transaction v1 permite realizar operaciones más complejas en una sola transacción, como pruebas grandes y pagos con múltiples aprobaciones.
- El software que lee transacciones de Solana debe reconocer v1 para evitar errores y una visualización incorrecta de las comisiones.
Solana quiere elevar el miércoles el tamaño máximo de las transacciones de 1.232 bytes a 4.096 bytes. Con ello, la red obtiene más de tres veces más espacio por transacción, lo que da a los desarrolladores más margen para realizar operaciones más complejas de una sola vez.
Más espacio por transacción
Con la nueva Transaction v1, las tareas que antes debían repartirse entre varias transacciones podrán gestionarse con mayor frecuencia en una sola operación. Esto se aplica, por ejemplo, a grandes pruebas criptográficas, pagos con muchas aprobaciones y algunas transferencias confidenciales.
La nueva forma ya funciona en las redes de prueba y desarrollo de Solana. Las transacciones existentes seguirán funcionando con normalidad, por lo que las wallets y las aplicaciones no tienen que adoptar v1 de inmediato si no necesitan ese espacio adicional.
Este paso elimina una limitación antigua que Solana arrastraba desde hace tiempo. La red era rápida y barata, pero las transacciones estaban sujetas a un límite fijo de 1.232 bytes. Ethereum no tiene una frontera fija de protocolo de ese tipo y, por ello, puede procesar aplicaciones más grandes e intensivas en datos en una sola transacción, siempre que el usuario pague suficientes comisiones.
Qué debe ajustar el software
El mayor impacto no está solo en la red en sí, sino también en el software que lee Solana. Los servicios que recuperan bloques y transacciones deben reconocer v1. Si no lo hacen, las solicitudes pueden fallar en cuanto encuentren una nueva transacción.
También cambia para algunos sistemas el lugar donde se muestra la información de la priority fee. Una priority fee es un pago adicional para que una transacción se procese más rápido. Como resultado, el software antiguo puede mostrar una comisión de cero, aunque sí se haya pagado.
Las wallets, los exploradores y las aplicaciones de trading suelen obtener la información que muestran en pantalla de este tipo de servicios. Si los datos subyacentes no son correctos, el usuario también verá errores. Por tanto, la actualización exige sobre todo ajustes técnicos en segundo plano, no una migración obligatoria para todos.
Por qué esto es relevante
Para los usuarios europeos de cripto, esto es relevante sobre todo porque las transacciones más grandes dan más espacio a aplicaciones con muchos datos, como las pruebas de conocimiento cero y las grandes estructuras multisig. Además, el límite de 4.096 bytes coincide con la página de memoria estándar del hardware de validadores, lo que ayuda a mantener un procesamiento eficiente. Esto hace que el cambio sea especialmente interesante para los desarrolladores y los servicios que construyen sobre Solana, no solo para los operadores que siguen la cotización.
El cambio es independiente de las recientes votaciones de gobernanza en torno a SOL y de la distribución de nuevos tokens. Según la documentación, la actualización forma parte de la fase Agave 4.2, que comienza en la semana del 17 de agosto de 2026, pero la transición a v1 seguirá siendo opcional para las aplicaciones y wallets existentes.
