Solana activó su función txv1 en la red principal aproximadamente a las 01:00 UTC del 15 de septiembre, al inicio de la época 1035. La actualización eleva el tamaño máximo de las transacciones de 1,232 bytes a 4,096 bytes, lo que proporciona más de tres veces la capacidad anterior.

El espacio adicional está disponible mediante el formato de transacciones V1. Las aplicaciones deben añadir compatibilidad explícitamente antes de utilizarlo, mientras que las transacciones legacy y V0 siguen siendo totalmente compatibles con sus límites actuales.

Una transacción más grande no implica una transferencia mayor de SOL

El nuevo límite se refiere a la cantidad de información que transporta una transacción, no a la cantidad de SOL que un usuario puede enviar. Por lo general, una transferencia estándar requiere pocos datos porque contiene solo un número reducido de cuentas, instrucciones y firmas.

Las operaciones más avanzadas pueden requerir varias instrucciones, numerosas direcciones de cuentas, múltiples aprobaciones o pruebas criptográficas. Cuando esa información superaba el límite anterior, los desarrolladores tenían que reducir la carga de datos, dividir la operación entre varias transacciones o utilizar alternativas como tablas de búsqueda de direcciones y paquetes de transacciones.

Solana puede procesar transacciones no relacionadas en paralelo, como se explica en esta guía sobre el funcionamiento de Solana. V1 no modifica ese modelo de ejecución. En cambio, proporciona espacio adicional cuando una sola operación debe contener varios componentes conectados.

Cuando esas instrucciones se envían como una única transacción atómica, se procesan como una unidad. La operación completa tiene éxito o sus cambios se revierten, lo que evita que solo algunas instrucciones lleguen al registro contable.

Operaciones que pueden beneficiarse del espacio adicional

• Operaciones agrupadas: Una aplicación de trading puede incluir instrucciones conectadas en una sola transacción en lugar de coordinar varias confirmaciones.
• Aprobaciones multisig grandes: Las billeteras de tesorería y corporativas pueden admitir más firmas e información de cuentas cuando varias personas deben autorizar una operación.
• Pruebas de conocimiento cero: Las aplicaciones pueden demostrar que se cumple una condición sin revelar toda la información subyacente, pero la propia prueba puede requerir un espacio considerable en la transacción.
• Esquemas de firmas on-chain: Algunos formatos de firmas criptográficas generaban anteriormente más datos de los que podía contener una sola transacción de Solana.

La Solana Foundation identifica las transferencias confidenciales, las multisig anidadas, las operaciones agrupadas y ciertos esquemas de firmas on-chain como posibles usos del nuevo formato.

La mayoría de los usuarios de billeteras no necesitan realizar ninguna acción

La activación no exige que los usuarios muevan sus SOL, creen otra dirección o conviertan una cuenta existente. Las aplicaciones que continúen utilizando transacciones legacy o V0 deberían operar como antes de la actualización.

Los usuarios necesitarán una billetera compatible cuando una aplicación decida enviar una transacción V1. Mantener actualizado el software de la billetera permitirá disponer de esa compatibilidad a medida que los proveedores la incorporen, pero las aplicaciones aún deberían comprobar la compatibilidad antes de solicitar a una billetera que firme.

Para los usuarios, el cambio podría manifestarse con el tiempo en un menor número de solicitudes de aprobación para operaciones complejas. Un servicio que antes requería varias transacciones conectadas podría presentar una sola solicitud y esperar una confirmación.

Los desarrolladores y los indexadores deben actualizar su software

Enviar transacciones V1 es opcional, pero leerlas puede generar problemas de compatibilidad para la infraestructura que no haya sido actualizada.

Los servicios RPC que obtienen transacciones o bloques deben establecer maxSupportedTransactionVersion: 1. Sin ese ajuste, una solicitud de una transacción V1 puede devolver un error. Una sola transacción no compatible también puede provocar que falle la solicitud de un bloque completo.

Los indexadores enfrentan un riesgo diferente. V1 almacena su límite de cómputo, el límite de datos de cuentas cargadas y la comisión de prioridad dentro de transactionConfig, en lugar de hacerlo en las instrucciones de Compute Budget. El software que continúe consultando la ubicación anterior puede clasificar incorrectamente la transacción o informar que sus límites de recursos y su comisión de prioridad son cero.

Las aplicaciones que creen transacciones V1 deben establecer explícitamente sus límites de unidades de cómputo y de datos de cuentas cargadas. Ambos valores tienen cero como valor predeterminado en el nuevo formato, por lo que omitirlos puede provocar que la transacción falle antes de su ejecución.

Las transacciones superiores a 1,232 bytes también deben enviarse mediante codificación base64. La vía de envío base58 conserva el límite de tamaño anterior.

V1 añade espacio, pero cambia otros límites

V1 no es simplemente V0 con una carga de datos más grande. Puede incluir directamente hasta 64 direcciones de cuentas en la transacción, pero no admite tablas de búsqueda de direcciones. Las direcciones de cuentas duplicadas también son rechazadas.

Esas reglas crean una decisión de diseño diferente para los equipos de aplicaciones. V0 sigue siendo útil cuando las tablas de búsqueda ofrecen una forma eficiente de referenciar cuentas, mientras que V1 está pensado para operaciones que se benefician más de espacio adicional para instrucciones, firmas o pruebas.

Es poco probable que un pago básico obtenga algún beneficio del nuevo formato. V1 es más adecuado para aplicaciones que pueden reemplazar una secuencia compleja o admitir datos que antes no cabían en una sola transacción.

Las transacciones más grandes pueden implicar comisiones más elevadas

Aumentar el límite de bytes no encarece automáticamente todas las transacciones V1. El costo depende de los recursos solicitados, del número de firmas y de la comisión de prioridad seleccionada por la aplicación.

Los mensajes más grandes sí consumen más ancho de banda de los validadores. La documentación de Solana señala que se espera que el planificador exija una comisión de prioridad más alta para una transacción grande que para una transacción más pequeña que busque una prioridad equivalente, especialmente cuando hay una gran demanda de espacio en los bloques.

V1 expresa la comisión de prioridad como una cantidad total en lamports. V0 utiliza un precio por unidad de cómputo, lo que significa que las plataformas de análisis deben normalizar ambos formatos antes de compararlos.

La demanda de comisiones de prioridad puede cambiar considerablemente con la actividad de la red, como muestran los datos recientes sobre las comisiones de Solana. Por ello, los desarrolladores deberán sopesar la conveniencia de una operación más grande frente al costo de incluirla durante periodos de congestión.

La activación inicia la prueba de adopción

La actualización elimina una limitación que anteriormente condicionaba la forma en que se construían las aplicaciones de Solana, pero la activación en la red principal no garantiza un uso generalizado. Las billeteras, los proveedores RPC, los indexadores y las bibliotecas de aplicaciones deben manejar correctamente el nuevo formato antes de que los desarrolladores puedan confiar en él para productos dirigidos a los usuarios.

Los primeros beneficios podrían aparecer en cargas de trabajo que ya tienen dificultades con el límite anterior, incluidas las transferencias confidenciales, las configuraciones multisig institucionales y las aplicaciones con muchas instrucciones. Para las transferencias ordinarias, los formatos establecidos siguen siendo la opción más sencilla.

La importancia de V1 dependerá de si incluir estas cargas de trabajo en una sola transacción atómica genera suficientes ahorros en coordinación, firmas e intentos fallidos como para justificar las actualizaciones de infraestructura necesarias.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento financiero ni de inversión. La compatibilidad de las billeteras, el soporte de las aplicaciones y las comisiones de las transacciones pueden cambiar.

Fuente: Coindoo