Solana supuestamente se prepara para triplicar el tamaño máximo de una transacción de red individual, un cambio en el límite de transacciones de la blockchain que daría a las aplicaciones más espacio para agrupar operaciones complejas en una sola transacción. Según reportes sobre la actualización planificada, la medida apunta a la cantidad de datos que puede transportar una sola transacción. Los límites exactos en bytes, el estado de la propuesta y el cronograma de activación no han sido confirmados.

Qué cambiaría el aumento del tamaño de transacción

El cambio se refiere a qué tan grande puede ser una transacción individual de Solana, medida en bytes, no a cuántas transacciones procesa la red por segundo. Triplicar ese techo aumentaría la cantidad de datos de instrucciones y cuentas que una sola transacción puede transportar.

Los reportes disponibles no proporcionan el límite actual en bytes, el nuevo valor propuesto ni un identificador de propuesta, por lo que no se pueden precisar cifras exactas de antes y después. Los parámetros de red de Solana normalmente se modifican a través del proceso de Solana Improvement Documents, cuyas propuestas abiertas se rastrean públicamente.

Es importante distinguir un sobre de transacción más grande de un mayor rendimiento. Triplicar el tamaño de la transacción es distinto de aumentar el rendimiento, la capacidad de ejecución o la capacidad de bloque. Un sobre más grande por sí solo no incrementa las transacciones por segundo ni los presupuestos de unidades de cómputo; solo cambia cuántos datos pueden codificarse en una sola transacción. Para los lectores que siguen cambios de protocolo entre ecosistemas, este tipo de ajuste de parámetros se suma a otros trabajos de capacidad de red en cadenas de contratos inteligentes; por ejemplo, el uso histórico que Ethereum ha hecho de los límites de gas por bloque y la tarificación de calldata para gestionar cuántos datos consumen las transacciones, aunque cada cadena define y gobierna dichos parámetros de manera diferente.

Cómo las transacciones más grandes podrían respaldar operaciones más complejas

Un sobre de transacción más grande podría, en principio, permitir que una aplicación incluya más instrucciones relacionadas con operaciones o referencias de cuentas en una sola transacción, sujeto al diseño final del cambio. Este es el beneficio práctico que los reportes asocian al aumento de tamaño, aunque no se ha proporcionado ninguna aplicación específica, benchmark ni declaración de desarrolladores.

Como hipótesis, un swap de varios pasos o un conjunto de operaciones combinadas que hoy deben dividirse entre transacciones podría caber en una sola. Esto importa para la componibilidad: cuando las operaciones relacionadas deben dividirse en transacciones separadas, pueden fallar de forma independiente, un problema de larga data en los flujos de trabajo on-chain complejos. Esto sigue siendo solo ilustrativo; no se ha demostrado ningún flujo de trabajo confirmado. Solana ya concentra una intensa actividad de enrutamiento de operaciones en plataformas como Raydium y Jupiter, el tipo de aplicaciones que un sobre más grande afectaría de manera más directa.

Otros límites sobre la complejidad de las transacciones

El tamaño de la transacción es solo una restricción sobre lo que una transacción puede hacer. Los límites de ejecución, como los presupuestos de unidades de cómputo y las reglas de acceso a cuentas, también restringen la complejidad de una transacción, y los reportes no especifican si esos límites cambiarían junto con el aumento de tamaño.

El cambio no debe interpretarse como una promesa de comisiones más bajas, mejores precios o menor slippage; ninguno de esos efectos está respaldado por la evidencia disponible.

Qué queda por confirmar sobre el despliegue

No se ha proporcionado cronograma, condiciones de activación, versión de cliente ni confirmación en mainnet para el cambio. La especificación técnica, el estado de la propuesta, el alcance de la implementación y la fecha de activación siguen sin verificar.

Tampoco está confirmado si las herramientas de las aplicaciones o el código de construcción de transacciones necesitarían actualizaciones para usar un sobre más grande, y no hay mediciones de rendimiento ni contrapartidas de recursos disponibles. Hasta que se identifiquen una propuesta específica y una versión de cliente, el titular describe un plan reportado y no una actualización implementada.