#solana
Solana aumenta el tamaño máximo de transacción a 4.096 bytes cuando txv1 entra en funcionamiento
Solana activó la compuerta de funciones de txv1 en mainnet al comienzo del epoch 1035, el 15 de septiembre de 2026, aproximadamente a las 01:00 UTC, elevando el tamaño máximo de transacción de la red de 1.232 bytes a 4.096 bytes, según una nota de actualización oficial publicada por Solana. El cambio se define en SIMD-0296 y se entrega mediante el formato de transacción v1 introducido en SIMD-0385. Solana dijo que el sobre más grande está diseñado para desbloquear cargas de trabajo que antes tenían que dividirse en varias transacciones encadenadas, mientras que los formatos v0 y heredados existentes continúan funcionando sin cambios.
Lo que desbloquea el límite de 4.096 bytes
Solana enmarcó el aumento como una ganancia de margen (headroom) más que como un cambio que rompa compatibilidad. El trabajo que antes tenía que dividirse en varias transacciones encadenadas —pruebas de conocimiento cero como las usadas por Confidential Transfers, operaciones grandes de multisig y programas agrupados— ahora puede ejecutarse como una sola transacción atómica, lo que significa menos firmas por las que pagar y una sola confirmación en lugar de varias. Como las transacciones v0 y heredadas permanecen sin cambios, las carteras y aplicaciones que no necesitan el espacio extra seguirán funcionando exactamente como hoy, y la nota subraya que no cambia nada sobre cómo los usuarios aprueban, firman o envían una transacción.
Los operadores de nodos enfrentan una ventana de migración
La función está activa en mainnet, testnet y devnet, pero Solana indicó que parte de la infraestructura necesita una versión específica. Los nodos RPC deben actualizar a Agave v4.2.2 o una versión posterior; compilaciones anteriores degradan los mensajes v1 a v0 al almacenarlos, lo que anula el presupuesto de cómputo y notifica incorrectamente la versión. Los validadores de Jito-Solana también necesitan v4.2.2 o posterior, porque un líder que ejecute una versión más antigua no ensamblará transacciones v1 en sus bloques. La nota señala una matriz de versiones que registra la primera versión de cada dependencia que maneja transacciones v1, junto con un ejemplo de código ejecutable para enviarlas, decodificarlas e indexarlas.
#Write2Earn #sol $SOL
Solana aumenta el tamaño máximo de transacción a 4.096 bytes cuando txv1 entra en funcionamiento
Solana activó la compuerta de funciones de txv1 en mainnet al comienzo del epoch 1035, el 15 de septiembre de 2026, aproximadamente a las 01:00 UTC, elevando el tamaño máximo de transacción de la red de 1.232 bytes a 4.096 bytes, según una nota de actualización oficial publicada por Solana. El cambio se define en SIMD-0296 y se entrega mediante el formato de transacción v1 introducido en SIMD-0385. Solana dijo que el sobre más grande está diseñado para desbloquear cargas de trabajo que antes tenían que dividirse en varias transacciones encadenadas, mientras que los formatos v0 y heredados existentes continúan funcionando sin cambios.
Lo que desbloquea el límite de 4.096 bytes
Solana enmarcó el aumento como una ganancia de margen (headroom) más que como un cambio que rompa compatibilidad. El trabajo que antes tenía que dividirse en varias transacciones encadenadas —pruebas de conocimiento cero como las usadas por Confidential Transfers, operaciones grandes de multisig y programas agrupados— ahora puede ejecutarse como una sola transacción atómica, lo que significa menos firmas por las que pagar y una sola confirmación en lugar de varias. Como las transacciones v0 y heredadas permanecen sin cambios, las carteras y aplicaciones que no necesitan el espacio extra seguirán funcionando exactamente como hoy, y la nota subraya que no cambia nada sobre cómo los usuarios aprueban, firman o envían una transacción.
Los operadores de nodos enfrentan una ventana de migración
La función está activa en mainnet, testnet y devnet, pero Solana indicó que parte de la infraestructura necesita una versión específica. Los nodos RPC deben actualizar a Agave v4.2.2 o una versión posterior; compilaciones anteriores degradan los mensajes v1 a v0 al almacenarlos, lo que anula el presupuesto de cómputo y notifica incorrectamente la versión. Los validadores de Jito-Solana también necesitan v4.2.2 o posterior, porque un líder que ejecute una versión más antigua no ensamblará transacciones v1 en sus bloques. La nota señala una matriz de versiones que registra la primera versión de cada dependencia que maneja transacciones v1, junto con un ejemplo de código ejecutable para enviarlas, decodificarlas e indexarlas.
#Write2Earn #sol $SOL
