Solana activará el miércoles Transaction v1, max tx 4,096…
Los formatos heredados siguen siendo válidos, pero los indexadores y exploradores deben actualizarse para evitar lecturas fallidas y visualizaciones de cero tarifas.
Solana tiene como objetivo activar el miércoles la Transacción v1, aumentando el tamaño máximo de transacción de 1,232 bytes a 4,096 bytes. El cambio expande lo que puede caber atómicamente en la cadena, pero también obliga a la infraestructura de lectura de datos a actualizarse o arriesgarse a solicitudes fallidas y a mostrar tarifas de prioridad engañosas.
Puntos Clave
- Solanatiene como objetivo una activación en la mainnet el miércoles que eleva el tamaño máximo de transacción de 1,232 bytes a 4,096 bytes a través de la Transacción v1.
- Los formatos de transacción más antiguos siguen siendo compatibles, por lo que la mayoría de las billeteras y aplicaciones pueden seguir operando sin cambiar a menos que necesiten el espacio adicional.
- Los lectores de bloques y transacciones que alimentan exploradores, billeteras y aplicaciones de trading necesitan soporte para la Transacción v1 o las solicitudes de búsqueda pueden fallar cuando aparece el nuevo formato.
- Los metadatos de tarifas de prioridad se mueven en v1, lo que significa que las herramientas desactualizadas pueden mostrar una tarifa de prioridad de cero incluso cuando un usuario pagó una.
La Transacción v1 se Activa: de 1,232 Bytes a 4,096 Bytes
Solana tiene como objetivo el miércoles aumentar su tamaño máximo de transacción de 1,232 bytes a 4,096 bytes a través de un nuevo formato de Transacción v1. Eso es más de un aumento de 3x en cuánto de instrucción y carga de datos puede caber en una sola transacción.
La victoria práctica es la atomicidad. Los flujos de trabajo que anteriormente tenían que dividirse en múltiples transacciones pueden ejecutarse cada vez más en una sola, reduciendo el número de firmas, transmisiones y puntos de fallo separados requeridos para completar una acción compleja.
El nuevo formato ya está funcionando en las redes de prueba y desarrollo de Solana. El paquete no especifica un tiempo de activación exacto para el miércoles, y no confirma la activación final de la mainnet más allá del objetivo.
El cambio está definido en dos Documentos de Mejora de Solana, SIMD-0296 y SIMD-0385, coescritos por Jacob Creech y Andrew Fitzgerald.
Ejecución y Óptica de Tarifas: Transacciones Más Grandes, Metadatos de Tarifas de Prioridad Diferentes
Las transacciones más grandes amplían el espacio de diseño para las aplicaciones de Solana que son intensivas en instrucciones. Los ejemplos citados de lo que ahora puede caber más cómodamente en una sola transacción incluyen grandes pruebas criptográficas, pagos que requieren muchas aprobaciones (grandesmultifirmaoperaciones), y algunas transferencias confidenciales.
Para los traders, la implicación inmediata es que hay menos secuencias de múltiples transacciones para acciones complejas. Esto es más importante cuando la cadena está ocupada y la ejecución parcial es costosa. Una transacción o se completa o no. Dividir la misma intención en varias transacciones aumenta las probabilidades de que una parte falle, se complete tarde o se procese con un régimen de tarifas diferente.
La situación de las tarifas es más matizada. La actualización no introduce una nueva tarifa por byte, pero las transacciones más grandes consumen más ancho de banda de la red. Los desarrolladores esperan que los usuarios puedan necesitar ofrecer tarifas de mayor prioridad cuando las transacciones más grandes compitan por espacio.
Las tarifas de prioridad son pagos adicionales opcionales que los usuarios pueden hacer para que una transacción se procese más rápido. El inconveniente es que la transacción v1 almacena la información de la tarifa de prioridad en otro lugar, lo que crea un nuevo modo de fallo para cualquier herramienta que asuma el diseño anterior.
Riesgo de Indexador y Explorador: Lecturas Fallidas y Errores de 'Cero Comisiones'
La presión de actualización más inmediata no está en las billeteras. Los formatos de transacción existentes seguirán siendo compatibles, y las billeteras y aplicaciones no necesitan cambiar a v1 a menos que necesiten el espacio adicional.
La presión está en la infraestructura que lee Solana. Los servicios que obtienen bloques y transacciones deben actualizarse para reconocer la Transacción v1. Si no lo hacen, las solicitudes pueden fallar cuando se encuentren con el nuevo formato.
Ese fallo no es solo un dolor de cabeza operativo. Las billeteras, exploradores y aplicaciones de trading a menudo dependen de estos servicios para mostrar lo que sucedió en la cadena. Si el backend no puede analizar v1, el síntoma visible para el usuario puede ser transacciones faltantes, vistas de historial rotas o informes de ejecución inconsistentes entre aplicaciones que obtienen datos de diferentes indexadores.
La óptica de tarifas es el borde más agudo. Debido a que v1 almacena datos de tarifas prioritarias en una ubicación diferente, el software desactualizado puede mostrar una tarifa prioritaria de cero incluso cuando se pagó una. Durante la congestión, ese tipo de informe erróneo puede distorsionar la experiencia del trader al hacer que la ejecución parezca más barata de lo que fue, o al crear 'verdades' conflictivas entre exploradores y terminales.
Lista de verificación posterior a la activación para traders y creadores.
El primer punto de control es la confirmación de la hora exacta de activación del miércoles y si surgen problemas de implementación inmediatamente después del cambio. El paquete no incluye una marca de tiempo finalizada.
El segundo punto de control es el estado de la infraestructura. Los indexadores, exploradores y backends de billetera principales necesitan confirmar el soporte de Transacción v1, incluyendo el análisis correcto de tarifas prioritarias. La preparación mixta es el caso base cuando un cambio de formato se implementa, y es donde los traders ven exhibiciones de tarifas inconsistentes entre herramientas.
El tercer punto de control es la telemetría de errores en el entorno. Informes de solicitudes fallidas de obtención de bloques o transacciones, historial faltante o discrepancias repentinas en las tarifas prioritarias mostradas entre exploradores y aplicaciones de trading serían la señal más clara de que algunos backends aún están leyendo la cadena con suposiciones antiguas.
El último punto de control es conductual, no mecánico. Una vez que las transacciones más grandes comienzan a competir por espacio, el mercado descubrirá lo que 'puede requerir tarifas prioritarias más altas' significa en la práctica durante la congestión. El paquete no proporciona una estimación numérica, solo la expectativa direccional.
Mi lectura: Esta es una actualización de UX y fiabilidad tanto como de rendimiento.
El umbral que importa no es si las carteras "soportan v1". Los formatos heredados siguen siendo válidos, por lo que la mayoría de las interfaces se verán bien.
La verdadera prueba es si los indexadores y exploradores en los que los traders confían implícitamente pueden analizar v1 de manera consistente, porque las lecturas fallidas y los informes erróneos sin comisiones son cómo las actualizaciones de formato se convierten en confusión en la ejecución.
Si las visualizaciones de tarifas prioritarias se mantienen coherentes a través de las principales herramientas después de la activación, la configuración comienza a parecer estructural en lugar de impulsada por narrativas: se pueden realizar acciones más complejas de manera atómica sin romper la visión del trader sobre el costo y la confirmación.
Si la óptica de tarifas se fragmenta, la actualización se sentirá menos como una capacidad extra y más como un impuesto temporal de fiabilidad pagado en datos erróneos.
