Por Canuto  

Solana activó en testnet un nuevo formato de transacción que eleva el límite de 1.232 a 4.096 bytes, una ampliación diseñada para facilitar pruebas de conocimiento cero, multisigs grandes, transferencias confidenciales y firmas BLS antes de su llegada prevista a mainnet el 9 de septiembre de 2026.
***

  • Transaction V1 aumenta de 1.232 a 4.096 bytes el tamaño máximo de una transacción serializada en Solana.
  • El formato busca incorporar pruebas ZK, multisigs grandes, transferencias confidenciales y firmas BLS en una sola operación.
  • La activación en mainnet está prevista para el 9 de septiembre, mientras wallets, SDK, RPC e indexadores deben prepararse.

 

Solana activó en testnet su nuevo formato de transacción V1, una actualización que triplica el tamaño máximo de las operaciones serializadas de 1.232 a 4.096 bytes. El cambio busca resolver una limitación que durante años obligó a los desarrolladores a dividir operaciones complejas o crear mecanismos de compresión personalizados.

La ampliación tiene implicaciones directas para aplicaciones que necesitan transportar pruebas criptográficas voluminosas, múltiples firmas o datos asociados con funciones de privacidad. De acuerdo con la información publicada por Cryptobriefing, la activación en mainnet está prevista para el 9 de septiembre de 2026, después de un periodo de pruebas destinado a detectar problemas de compatibilidad.

Qué modifica Transaction V1

El formato heredado de Solana fija en 1.232 bytes el espacio disponible para una transacción, un límite suficiente para operaciones sencillas como ciertos intercambios de tokens, pero estrecho para procesos que incorporan pruebas criptográficas. Cuando los datos superan esa capacidad, los equipos deben repartir una acción entre varias transacciones, con más pasos, mayor complejidad y una experiencia menos directa para el usuario.

Transaction V1 eleva ese máximo hasta 4.096 bytes, es decir, aproximadamente 3,3 veces el tamaño anterior. El objetivo no consiste únicamente en permitir mensajes más extensos, sino en que determinadas operaciones avanzadas puedan ejecutarse de manera atómica, dentro de una sola transacción, sin depender de soluciones diseñadas específicamente para sortear el límite.

La actualización está definida por dos propuestas de protocolo identificadas como SIMD-0296 y SIMD-0385. La primera aborda el aumento del tamaño máximo, mientras la segunda establece el nuevo formato de mensaje V1, que utiliza un byte de versión 0x81 junto con una máscara de configuración.

El nuevo diseño también incorpora una compensación técnica relevante: el soporte para Address Lookup Table, conocido como ALT, fue eliminado del formato V1. Las transacciones heredadas continuarán siendo compatibles, por lo que las aplicaciones existentes no quedan obligadas a migrar de inmediato ni deberían romperse por la activación del nuevo esquema.

Pruebas y preparación del ecosistema

Los desarrolladores pudieron comenzar las pruebas locales desde el 24 de agosto de 2026 mediante Solana CLI v4.2 o versiones posteriores y Surfpool v1.5 o superiores. La activación en testnet llegó a finales de agosto, lo que dejó un periodo aproximado de dos semanas antes de la fecha prevista para mainnet.

Ese calendario ofrece una ventana para revisar la forma en que distintos componentes construyen, transmiten, almacenan y muestran las nuevas transacciones. El periodo de prueba resulta especialmente importante porque el cambio afecta tanto a la capa de protocolo como a las herramientas que interactúan con ella desde aplicaciones y servicios externos.

Las llamadas RPC, los indexadores y los SDK tendrán que actualizarse para reconocer y procesar correctamente el formato V1. Si esos componentes no incorporan los cambios a tiempo, podrían rechazar transacciones válidas, interpretar datos de manera incompleta o dificultar el diagnóstico de errores para los equipos que desarrollen sobre Solana.

Wallets, exploradores de bloques y plataformas de análisis también forman parte de la cadena de preparación. Aunque la red pueda procesar el formato sin inconvenientes, los usuarios podrían encontrar saldos, firmas o detalles de operaciones mal representados si los proveedores de infraestructura no actualizan sus sistemas de lectura.

Casos de uso que ganan espacio

Las pruebas de conocimiento cero aparecen entre los principales beneficiarios del aumento, porque suelen generar cargas de datos que no cabían en el límite heredado. Al incluir una prueba ZK completa en una sola transacción, los desarrolladores pueden reducir la necesidad de flujos de verificación divididos en varios pasos, con potencial para disminuir latencia y complejidad operativa.

Las transferencias confidenciales también podrían aprovechar el espacio adicional. En ese modelo, los montos transferidos permanecen cifrados, pero la red conserva mecanismos para verificar que la operación cumple las reglas correspondientes; con 4.096 bytes disponibles, estas acciones pueden empaquetarse de forma atómica cuando los datos criptográficos lo requieran.

Los monederos multisig utilizados por organizaciones autónomas descentralizadas y tesorerías institucionales enfrentan un problema similar. Una operación que exige las firmas de 20 o 30 participantes puede tener dificultades para acomodar todos los datos necesarios dentro de 1.232 bytes, mientras que el formato ampliado ofrece mayor margen para esos esquemas de autorización.

Las firmas BLS, que permiten agregar múltiples firmas en una prueba compacta, también se vuelven más prácticas dentro de transacciones únicas de Solana. Ese cambio podría facilitar diseños relacionados con puentes entre cadenas y atestaciones de conjuntos de validadores, aunque su utilidad final dependerá de la implementación concreta de cada aplicación y de la actualización coordinada de sus herramientas.

Alcance y riesgos de la activación

La ampliación del tamaño no convierte por sí sola a todas las aplicaciones de Solana en sistemas compatibles con pruebas ZK, privacidad o multisigs de gran escala. Lo que ofrece es más espacio nativo dentro del formato de transacción, de modo que los equipos pueden evaluar arquitecturas que antes exigían dividir operaciones o crear mecanismos alternativos.

La activación ocurre además mientras Solana trabaja en otras mejoras de protocolo, entre ellas reducciones del tiempo de slot y ajustes relacionados con rent. El formato V1 debe entenderse, por tanto, como una pieza de una agenda técnica más amplia, no como una solución aislada para todos los retos de capacidad, experiencia de usuario o infraestructura.

La pregunta inmediata para los desarrolladores será si el formato funciona sin problemas en testnet y si las actualizaciones de SDK, RPC e indexadores llegan antes del 9 de septiembre. Un desfase entre la capa de protocolo y los servicios que la rodean podría crear una experiencia accidentada para los primeros usuarios, incluso si la red procesa correctamente las operaciones.

El desempeño de la prueba también servirá para medir la disposición del ecosistema a adoptar transacciones V1 sin abandonar la compatibilidad heredada. Si los proveedores de infraestructura resuelven el procesamiento y la visualización de los nuevos mensajes, Solana llegará a mainnet con una base más sólida para ampliar sus casos de uso criptográfico.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados