Solana v1: Explicación de las transacciones: límites de tamaño y cambios que afectan a la compatibilidad

Quicknode

1 de septiembre de 2026 — 10 minutos de lectura

Compartir

Añadir como fuente preferida

Los desarrolladores que crean aplicaciones complejas en Solana llevan años buscando soluciones para sortear el límite de tamaño de las transacciones. La versión v0 introdujo las tablas de búsqueda de direcciones, lo que permitió que una transacción hiciera referencia a más cuentas sin superar los 1.232 bytes. La última actualización introduce las transacciones v1, que multiplican por 3,3 el límite en sí.

La versión v1 de «Transaction» aumenta el tamaño máximo de las transacciones serializadas de 1.232 bytes a 4.096 bytes, y entrará en vigor con Agave v4.2 a principios de septiembre de 2026. Para los equipos que desarrollan aplicaciones de conocimiento cero (ZK), sistemas multisig y primitivas complejas de DeFi, este espacio adicional elimina toda una serie de soluciones provisionales.

No es necesario que nadie adopte la versión 1 para verse afectado por ella. Todo lo que lea datos de Solana se ve afectado, independientemente de si envía o no alguna transacción de la versión 1.

El límite de 1.232 bytes procedía del protocolo UDP. Solana trasladó la recepción de transacciones a QUIC hace años, lo que eliminó esa restricción. Sin embargo, el límite se mantuvo. Los equipos siguieron dividiendo las transacciones, creando tablas de consulta y diseñando sus soluciones en torno a un límite máximo que ya no se correspondía con el protocolo de transporte subyacente.

El nuevo límite no se basa en una restricción de red. Los 4.096 bytes se ajustan a las páginas de memoria de los validadores. Esto deja espacio para pruebas ZK, esquemas de firma BLS, transferencias confidenciales, solicitudes de actualización de precios de oráculos y la posibilidad de incluir más instrucciones en una sola transacción sin necesidad de recurrir a esquemas de agrupación. Además, permite incluir un conjunto completo de 64 cuentas en línea, razón por la cual la v1 prescinde por completo de las tablas de búsqueda de direcciones.

¿Qué es una transacción « Solana » v1?

Una transacción v1 es un nuevo formato de transferencia de « Solana » con un límite máximo de 4.096 bytes. No se trata de una v0 con un límite mayor, y hay cinco diferencias entre ambas:

• Byte de versión 0x81 se encuentra en el desplazamiento cero, por lo que cualquier receptor identifica el formato a partir de un solo byte

• Las firmas pasan a situarse al final de la transacción, en lugar de aparecer antes del mensaje.

• Ancho fijo u8 Los recuentos sustituyen a la codificación compact-u16

• Los encabezados de las instrucciones se agrupan antes que sus contenidos, lo que permite calcular directamente los límites

• Los límites de recursos se trasladan a una máscara de configuración de encabezado

Las tablas de búsqueda de direcciones han desaparecido

En la versión 1 se ha eliminado la compatibilidad con las tablas de búsqueda de direcciones. Ahora, cada cuenta se transmite en línea como una clave pública completa de 32 bytes, y un conjunto máximo de 64 direcciones ocupa 2.048 bytes, la mitad del nuevo sobre antes de añadir una sola instrucción.

Solana Se ha calculado el coste en todo el tráfico de mainnet . Aproximadamente el 62 % de las transacciones v0 hacen referencia al menos a una tabla de consulta. Al convertirlas a v1, la mitad de ellas presentan un exceso inferior a 420 bytes y el 90 % inferior a 1.400. Las transacciones que hacían referencia a varias tablas para obtener unas pocas direcciones cada una se reducen de tamaño, ya que la sobrecarga de las tablas suponía un coste mayor que el ahorro obtenido gracias a la compresión.

La eliminación de las tablas de consulta también simplifica la incorporación de los validadores. La versión v0 obliga a resolver las tablas en función del estado antes incluso de que un validador sepa a qué cuentas afecta una transacción. La versión v1 proporciona el conjunto completo de cuentas en la propia transacción, por lo que el cálculo de las comisiones y la prioridad se realiza antes.

Qué se consigue con los bytes extra

Las aplicaciones con gran volumen de carga útil ganan capacidad, ya que las pruebas y los datos de instrucciones consumen bytes sin ocupar ranuras de cuenta. Las aplicaciones con gran número de cuentas, como el enrutamiento multivía y la composición de protocolos amplios, dedican la mayor parte del nuevo espacio a reinsertar las direcciones que antes se comprimían mediante tablas de búsqueda. Para esos equipos, el límite máximo de 64 cuentas es ahora la restricción determinante, por lo que seguir con la versión v0 es una opción razonable.

Los bytes son el único límite que impone la versión 1. Las cuentas se mantienen en 64, las instrucciones en 64 y las firmas en 12.

¿Qué falla al leer datos de « Solana »?

Las aplicaciones que leen o indexan datos de « Solana » fallan la primera vez que aparece una transacción v1 en un bloque que consultan. El código que lee una transacción desde el principio se encuentra con datos de mensajes donde las versiones heredadas y v0 colocan las firmas, por lo que no es posible corregir el analizador aumentando su comprobación de longitud.

Las funciones `getBlock` y `getTransaction` rechazan las transacciones de la versión 1

Una llamada que no haya declarado compatibilidad con la versión 1 devuelve un error -32015 en cuanto detecta una, y falla la lectura de todo el bloque. Los indexadores y las tareas de rellenado se detienen en lugar de omitir la única transacción que no pueden analizar. Establecer maxSupportedTransactionVersion: 1 en ambas llamadas, como el entero JSON 1. La cadena "1" falla, y lo mismo ocurre con 0, por lo que el código que optó por la compatibilidad con la versión v0 durante su implantación aún no está cubierto. obtenerFirmasParaDirección no se ve afectado, ya que nunca revisa el cuerpo de las transacciones.

La llamada que se corta:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [402184291, { "encoding": "json" }]
}

La misma llamada, corregida. Es necesario utilizar Base64 junto con el parámetro «version», ya que Base58 no puede codificar una transacción de más de 1.232 bytes:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlock",
    "params": [
        402184291,
        {
            "encoding": "base64",
            "maxSupportedTransactionVersion": 1
        }
    ]
}

blockSubscribe deja de avanzar

blockSubscribe emite null y se bloquea cuando llega a una transacción v1, sin que haya ningún error que detectar. La supervisión basada en las tasas de error nunca se activa, por lo que la suscripción se queda atascada en la primera ranura v1 y permanece ahí. Establecer maxSupportedTransactionVersion: 1 en la suscripción, trata bloque: nulo como un error en lugar de como un bloque vacío, y añadir una comprobación de caducidad, ya que de lo contrario no se detectará.

La búsqueda en ComputeBudget devuelve ceros

La versión v1 ha trasladado los límites de computación y las tarifas por prioridad de las instrucciones a una configuración a nivel de mensaje. Los indexadores que buscan instrucciones «ComputeBudget» no encuentran ninguna coincidencia y escriben ceros en todos los conjuntos de datos posteriores sin que se produzca ningún error en ninguna capa. En su lugar, lee los límites en la configuración de la transacción. Esta información se incluye dentro del mensaje en las respuestas en las que se ha activado esta opción, y no aparece en absoluto en las versiones heredadas ni en la v0. Los campos sin definir se devuelven null:

"message": {
    "instructions": ["… no ComputeBudget instruction here …"],
    "recentBlockhash": "GsdgFbNBoZmAB5uPHfk2xUFYyM4Wg2hYZBfBrxrqjxfF",
    "transactionConfig": {
        "computeUnitLimit": 30000,
        "heapSize": null,
        "loadedAccountsDataSizeLimit": 200000,
        "priorityFee": null
    }
}

La agregación de comisiones prioritarias se interrumpe al cambiar de unidad

Las versiones Legacy y v0 expresan la comisión en microlamports por unidad de cálculo. La versión v1 la expresa como un total absoluto en lamports. Para mostrar ambas en un mismo panel de control, multiplica el precio de la versión v0 por el límite de unidades de cálculo que solicita la transacción y, a continuación, divide el resultado entre 1 000 000:

20 000 CU × 250 000 microlamports/CU = 5 000 lamports   // v0
                                        5 000 lamports   // equivalente a v1

Si te saltas la conversión, los totales no significan nada.

Geyser streams no tiene restricciones de versión

Los usuarios de servicios de streaming no tienen nada equivalente a maxSupportedTransactionVersion y no hay forma de desactivarlo. Actualiza el complemento « Yellowstone » de Geyser a la versión 15.1.1 y vuelve a generar los stubs de Protobuf con la versión 12.6.0 o posterior, que añade el Message.config campo. Un consumidor obsoleto no genera un error en v1. Lee la transacción como v0 con un presupuesto de cálculo vacío.

Detectar la versión de forma estructural en Message.config, y comprueba en este orden:

El orden es importante, porque con control de versiones Esto es válido tanto para v0 como para v1. Al probarlo, todas las transacciones de v1 se clasifican como v0, de forma silenciosa, con un presupuesto de cálculo puesto a cero.

function messageVersion(message: Message): "legacy" | "v0" | "v1" {
    if (message.config !== undefined) {
        return "v1";
    }
    return message.versioned ? "v0" : "legacy";
}

config es un submensaje, y los campos de los submensajes siempre tienen presencia explícita en proto3, por lo que esta comprobación se cumple independientemente de cómo gestione el decodificador los valores por defecto.

Las versiones anteriores de « Yellowstone » pasan de la v1 a la v0

Yellowstone Las versiones del complemento Geyser anteriores a la 15.1.1 convierten las transacciones de la versión 1 en una representación de la versión 0 antes de que lleguen a la red. El flujo sigue funcionando, pero lo que transmite ya no coincide con lo que se ha ejecutado en la cadena. Actualiza a la versión 15.1.1 o posterior y ten en cuenta esta discrepancia en cualquier proceso que haya conciliado los datos del flujo con el estado de la cadena mientras se ejecutaba una versión anterior.

Qué falla al enviar transacciones v1

Los fallos mencionados anteriormente se producen independientemente de que un « equipe » adopte la versión v1 o no. Estos no. Nada de lo que se indica a continuación ocurre hasta que una aplicación crea y envía una transacción v1 por sí misma, y cada elemento supone un cambio en la forma en que se construye una transacción, más que en cómo se lee. Las transacciones heredadas y v0 siguen funcionando sin cambios con 1.232 bytes, por lo que enviar una v1 es una decisión basada en la capacidad. Una transacción que necesite más de 1.232 bytes no tiene otra opción.

Los límites de recursos no definidos se establecen por defecto en cero.

Las versiones Legacy y v0 recurren a un valor por defecto de 200 000 unidades de cálculo por instrucción y 64 MiB de datos de cuentas cargados cuando una transacción no especifica nada. La versión v1 recurre a un valor por defecto de cero y da por fallida la transacción. Cada transacción v1 establece explícitamente un límite de unidades de cálculo y un límite de tamaño de los datos de cuentas cargados. En @solana/kit 8.0: se trasladan de las instrucciones de ComputeBudget a la configuración de mensajes:

import { setTransactionMessageConfig } from '@solana/kit';

const message = setTransactionMessageConfig(
    {
        computeUnitLimit: 20_000,
        loadedAccountsDataSizeLimit: 64 * 1024,
        priorityFeeLamports: 5_000n,
    },
    baseMessage,
);

Calcula el tamaño de ambos límites en una sola pasada de simulación, con cada uno de ellos fijado al máximo, y a continuación escribe el valor devuelto unidades consumidas y tamaño de los datos de cuentas cargados Vuelve al archivo de configuración. Redondea el tamaño de los datos al alza hasta la página de 32 KiB siguiente. El modelo de coste por bloque cobra por páginas de 32 KiB, por lo que el margen por debajo del límite siguiente es gratuito.

Deja un margen superior al que indica la simulación. Cargar una cuenta que no existe no cuesta nada, pero una vez creada ocupa 64 bytes más sus datos, por lo que un límite ajustado exactamente según la simulación da error con Se ha superado el tamaño máximo de los datos de las cuentas cargadas si la cuenta aparece antes de que se registre la operación.

Las instrucciones de ComputeBudget se convierten en operaciones nulas

La versión v1 las acepta, cobra 150 unidades de cálculo por cada una y las ignora a la hora de la configuración. Una transacción que contenga instrucciones de ComputeBudget y ninguna configuración de mensaje supera la validación y, a continuación, se ejecuta sin límites. Elimínalas por completo de los generadores de la versión v1. La configuración del mensaje las sustituye, y cada una de las que se dejen sin eliminar ocupa una ranura de instrucción de las 64 disponibles, además de 150 unidades de cálculo, sin realizar ninguna acción.

Tasas de prioridad

La versión v1 establece la tarifa prioritaria como un total absoluto de Lamport. El cálculo de «micro-Lamports por unidad de cálculo» de la versión v0 no se mantiene. El valor es un «bigint», y el método «setter» se rechaza en tiempo de compilación en los mensajes heredados y de la versión v0:

import { setTransactionMessagePriorityFeeLamports } from '@solana/kit';

const message = setTransactionMessagePriorityFeeLamports(5_000n, baseMessage);

La codificación Base58 tiene un límite de 1.232 bytes

Las transacciones que superen ese importe requieren codificación: «base64» al enviarlas. Las solicitudes que utilizan «base58» de forma fija fallan en las transacciones de gran tamaño que permite la versión 1.

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sendTransaction",
    "params": [
        "<base64-encoded transaction>",
        { "encoding": "base64" }
    ]
}

Se rechazan las direcciones duplicadas

Las versiones Legacy y v0 admiten direcciones de cuenta repetidas dentro de una transacción. La versión v1 las rechaza.

¿Qué versiones del cliente son compatibles con la v1?

La compatibilidad con la versión 1 comienza a partir de @solana/kit 8.0.0, los crates de Rust 4.2.x, Solders 0.29.0 y « solana-go» 1.23.0.

El formato v1 ya funciona en un validador local sin que sea necesario activar ninguna función. solana-validador de pruebas- lo admite a partir de la versión 4.2, Surfpool a partir de la versión 1.5 y un Surfnet efímero configurado para SIMD-0296 ofrece una opción alojada.

Quicknode Compatibilidad con la versión 1

Quicknode Los puntos finales RPC y las API admiten transacciones de la versión 1 desde el momento de la activación. No es necesario realizar ninguna migración de « endpoint », cambiar el plan, activar ningún indicador de configuración ni abrir ninguna solicitud de asistencia.

Quicknode Actualmente ya se gestionan transacciones v1 en el clúster Alpenglow, por lo que el formato puede probarse en un entorno de producción endpoint antes de que llegue a testnet. Testnet está a la espera de la activación de la transacción V1 SIMD-0385, prevista para el miércoles 2 de septiembre de 2026 a las 10:30 UTC.

El resto del trabajo se encuentra en el código de la aplicación. Pasar maxSupportedTransactionVersion: 1 en getTransaction y getBlock, actualizar a una de las versiones de cliente indicadas anteriormente, sustituir el análisis de instrucciones de ComputeBudget por la configuración de mensajes, normalizar las unidades de tarifa prioritaria en todos los formatos y pasar a la codificación base64 para las transacciones de más de 1.232 bytes.