Solana v1 se prepara para la transición a 4096 bytes con revisión de compatibilidad

El nuevo formato de transacción v1 de Solana (SOL) ha sido sometido a una revisión de compatibilidad de infraestructura antes de su activación en la mainnet. Aunque se incrementa el tamaño máximo de una transacción de 1,232 bytes a 4,096 bytes, el enfoque principal está en si el RPC, el indexador, gRPC y los patrocinadores de tarifas pueden leer correctamente el nuevo formato, más que en los problemas de consenso de la cadena.

La Fundación Solana ha anunciado en la página de actualización de la red que Agave 4.2 ha sido implementado en la mainnet, pero la función de 'Tamaños de Transacción Más Grandes' está en estado de espera para su activación a partir del 4 de septiembre de 2026. Esta función tiene como objetivo aumentar aproximadamente 3.3 veces el límite de transacción existente a través del formato de transacción v1.

Este cambio no es solo un aumento de tamaño. SIMD-0296 y SIMD-0385 han sido propuestos en el contexto de usos como firmas múltiples grandes, pruebas de conocimiento cero (ZK proof) y transferencias por lotes. En v1, se reduce la dependencia de la tabla de búsqueda de direcciones utilizada en las transacciones anteriores, y la información sobre tarifas y límites de recursos se trasladará a un valor de configuración separado llamado transactionConfig.

El método de lectura del sistema existente puede presentar problemas en este punto. Si el indexador y el patrocinador de tarifas solo revisan la instrucción ComputeBudget, pueden perder el límite de tarifas de la transacción v1 o leerlo como 0. El repositorio de ejemplos de la Fundación Solana explica que el mensaje v1 contiene TransactionConfig en lugar de la instrucción ComputeBudget.

La documentación de Solana RPC indica que se debe incluir maxSupportedTransactionVersion: 1 en las llamadas getTransaction, getBlock y blockSubscribe. Si se omite este valor o se deja en 0, getTransaction puede generar un error cuando se recibe una transacción v1, y getBlock puede fallar al leer todo el bloque.

La suscripción a WebSocket no es una excepción. Si blockSubscribe no está configurado correctamente, puede devolver block: null. La documentación de desarrollo de Solana indica que esto debe ser tratado como un fallo, no como un bloque vacío. Las transacciones v1 se identifican por el primer byte 129 de la transacción serializada, es decir, 0x81.

En las rutas gRPC y Geyser, pueden ocurrir errores más silenciosos. La documentación de desarrollo de Solana advierte que gRPC no tiene valores opcionales como maxSupportedTransactionVersion, y los stubs de protobuf antiguos pueden descartar el campo Message.config. En este caso, el sistema no se detiene, pero puede tratar las transacciones v1 como v0 y omitir la configuración de tarifas.

El repositorio de ejemplos de la Fundación Solana sugiere versiones mínimas como @solana/kit 8.0.0, yellowstone-grpc-proto 12.6.0 y yellowstone-grpc geyser 15.1.1. También se proporcionan ejemplos separados para lectura, envío, indexación de bloques y gRPC.

La validación en las herramientas centrales también está en curso. El problema #831 del solana-sdk de anza-xyz plantea que el tamaño máximo de v1 de 4,096 bytes no se está aplicando correctamente en el deserializador y el sanitizador. Sin embargo, la página de estado de Solana indica que, a partir del 4 de septiembre de 2026, los nodos RPC de Mainnet Beta están en funcionamiento y no se han reportado incidentes ese día.

Este asunto tiene un fuerte carácter de revisión de compatibilidad de infraestructura relacionada con la expansión del límite de transacciones v1 de Solana. Si los problemas anteriores eran sobre el límite de 4,096 bytes y la activación de funciones por clúster, ahora la clave es si el sistema backend puede leer la nueva estructura cuando realmente lleguen las transacciones v1.

La página de actualización de Solana indica que, a partir del 4 de septiembre de 2026, la función de 'Tamaños de Transacción Más Grandes' está en estado de espera para su activación. Esta fecha se asemeja más a una hoja de ruta técnica que a un evento único que cambia la estructura de procesamiento de Solana de una vez, ya que la billetera, el RPC, el indexador y las herramientas de desarrollo deben prepararse secuencialmente.

Técnicamente, las transacciones v1 no reemplazan a las v0 y a las transacciones heredadas. El formato existente seguirá funcionando, pero las aplicaciones que utilicen tamaños de transacción más grandes y transactionConfig deben estar preparadas para el nuevo formato. En general, en las actualizaciones de infraestructura de blockchain, la compatibilidad de los sistemas periféricos que leen y almacenan datos, así como las reglas de consenso, influyen en los riesgos operativos reales.

Los patrocinadores de tarifas y los indexadores pueden verse particularmente afectados. Si leen incorrectamente el límite de tarifas o el límite de unidades de cómputo, los servicios que asumen costos en lugar de los usuarios pueden verse expuestos a una estructura de costos diferente a la esperada, y los sistemas de análisis de transacciones también pueden registrar incorrectamente la configuración de recursos de las transacciones v1. Esto no es lo mismo que una interrupción que detiene la cadena, pero es un área que requiere revisión adicional por parte de los operadores de servicios.

Los intercambios y proveedores de billeteras nacionales que operan depósitos y retiros de Solana y monitoreo en cadena no están exentos de estos problemas. Deben verificar si las rutas de consulta de bloques, transacciones, indexación, monitoreo de riesgos y cálculo de tarifas manejan correctamente la estructura de mensajes v1. Especialmente si utilizan proveedores de nodos externos o datos basados en Geyser, es necesario verificar la reproducibilidad de protobuf y las versiones de la biblioteca.

Hasta que las transacciones v1 de Solana lleguen realmente, los puntos de verificación clave son: △ configuración de la opción de llamada RPC maxSupportedTransactionVersion: 1 △ reflejo de la ruta de almacenamiento de transactionConfig △ regeneración de stubs de gRPC protobuf △ reconocimiento del prefijo de versión 0x81. Según la página de actualización de Solana, 'Tamaños de Transacción Más Grandes' está en estado de espera para su activación a partir del 4 de septiembre de 2026.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.