Solana apunta al 9 de septiembre para Transaction v1, un nuevo formato que eleva el tamaño máximo de transacción serializada de 1,232 bytes a 4,096 bytes.
Resumen
- Solana planea elevar el tamaño máximo de transacción de 1,232 bytes a 4,096 bytes el miércoles en la red principal.
- Transaction v1 sigue siendo opcional, mientras que los formatos legacy y v0 continúan operando bajo los límites de tamaño existentes.
- Las aplicaciones que leen bloques deben soportar la versión uno o correr el riesgo de errores al encontrar el nuevo formato.
- V1 elimina las tablas de búsqueda de direcciones y almacena los límites de recursos directamente dentro de los metadatos de configuración de cada transacción.
- La hoja de ruta oficial de Solana etiqueta la activación de la red principal como pendiente, por lo que el cronograma del 9 de septiembre aún podría cambiar.
El aumento brinda a los desarrolladores aproximadamente 3.3 veces más espacio para transacciones. La hoja de ruta oficial de Solana dice que la capacidad adicional puede acomodar pruebas de conocimiento cero, operaciones de múltiples firmas grandes, lotes y algunos esquemas de firma en cadena.
Las operaciones grandes anteriormente tenían que dividirse en varias transacciones cuando sus instrucciones, firmas e información de cuentas excedían el límite de 1,232 bytes. Ese proceso agregaba complejidad porque una transacción podía tener éxito mientras otro paso fallaba.
Transaction v1 podría permitir a los desarrolladores combinar más de esas instrucciones en una sola operación atómica. O todas las instrucciones tienen éxito o toda la transacción falla. El modelo podría beneficiar rutas de comercio, transferencias confidenciales, operaciones entre cadenas y aplicaciones que procesan pruebas criptográficas complejas.
La actualización no eleva el límite de Solana de 64 cuentas referenciadas por transacción. Las aplicaciones pueden incluir más datos e instrucciones, pero no pueden interactuar automáticamente con más cuentas.
Las transacciones existentes de Solana seguirán siendo válidas
Transaction v1 es opcional. Las billeteras y aplicaciones pueden continuar enviando transacciones legacy y v0 bajo el límite existente de 1,232 bytes. Los usuarios no necesitan migrar tokens, intercambiar SOL o completar un reclamo antes de la activación.
Los desarrolladores deben adoptar deliberadamente el nuevo formato para acceder a su mayor capacidad. La documentación de Solana identifica tres formatos soportados: legacy, v0 y v1. Cada formato organiza las direcciones de cuentas y los límites de recursos de manera diferente.
El formato v0 utiliza Tablas de Búsqueda de Direcciones, o ALTs, para representar direcciones de cuentas a través de índices comprimidos de un byte. V1 elimina las ALTs y coloca direcciones de cuentas completas de 32 bytes directamente dentro de la transacción.
Esto crea una compensación. V1 proporciona un sobre general más grande, pero las aplicaciones que dependen en gran medida de las tablas de búsqueda pueden gastar más bytes para representar las mismas cuentas. El análisis técnico de Solana encontró que el 90% de las transacciones muestreadas agregarían menos de 1,400 bytes al convertirse de v0 a v1.
Los proveedores de infraestructura deben actualizar su software
El principal riesgo de compatibilidad se aplica a los servicios que leen bloques y transacciones. Los proveedores de llamadas a procedimientos remotos deben establecer su versión máxima de transacción soportada en uno. De lo contrario, las solicitudes podrían fallar cuando encuentren una transacción v1.
Los indexadores, exploradores y servicios de análisis también deben cambiar la forma en que recuperan los límites de recursos. Las transacciones legacy y v0 colocan los límites de cómputo y la configuración de tarifas prioritarias dentro de las instrucciones ComputeBudget. V1 los almacena en una configuración de transacción dedicada.
Los servicios desactualizados podrían, por lo tanto, mostrar información incorrecta. Por ejemplo, un explorador podría mostrar una tarifa de prioridad cero incluso si el usuario pagó una. Los patrocinadores de tarifas y las aplicaciones que verifican los límites de transacciones deben leer la nueva configuración en lugar de escanear instrucciones de estilo antiguo.
Las aplicaciones que envían transacciones v1 deben establecer explícitamente los límites de unidades de cómputo y datos cargados porque ambos tienen un valor predeterminado de cero. Los desarrolladores deben probar la construcción, firma y decodificación de transacciones antes de mover el tráfico de producción al formato.
El 9 de septiembre sigue siendo una fecha de activación prevista
El vicepresidente de tecnología de la Fundación Solana, Jacob Creech, identificó el 9 de septiembre como la fecha prevista para la red principal. Como informó anteriormente crypto.news, la actualización está incluida en el lanzamiento de Agave 4.2 de Anza.
Sin embargo, la hoja de ruta oficial todavía etiqueta la característica de la red principal como "no activada". También dice que el cronograma de lanzamiento de Anza es "tentativo y sujeto a cambios". Testnet y devnet ya han activado la característica, según la última página de estado de la Fundación.
El aumento de tamaño proviene de SIMD-0296, mientras que SIMD-0385 define el formato v1. Jacob Creech y Andrew Fitzgerald coescribieron ambas propuestas.
El límite de 4,096 bytes se seleccionó en parte porque cuatro kilobytes coinciden con un tamaño común de página de memoria utilizado por el hardware del validador. Las transacciones más grandes también consumirán ancho de banda adicional, aunque la actualización no introduce una tarifa separada por byte.
La transacción v1 sigue siendo independiente de las reducciones de alquiler de Solana, los objetivos de ranura más cortos y el rediseño de consenso Alpenglow. En cobertura relacionada, crypto.news informó que Alpenglow apunta a una finalidad de aproximadamente 150 milisegundos, con octubre como objetivo de desarrollo en lugar de una fecha de activación garantizada.
