Presupuesto de cómputo en Solana: límites, instrucciones y flujo de trabajo de medición

Qué controla un presupuesto de cómputo

En Solana, cada instrucción consume unidades de cómputo, una unidad medida del trabajo de ejecución. El presupuesto de cómputo de una transacción es el techo de cuántas CU puede usar toda la transacción. Si la ejecución supera el límite declarado, la transacción falla incluso si la lógica subyacente del programa de otro modo tendría éxito. Por lo tanto, el presupuesto es tanto un mecanismo de seguridad como una palanca de costos.

El presupuesto tiene dos partes independientes. El límite de unidades de cómputo limita el trabajo de ejecución. El precio de la unidad de cómputo establece cuántos lamports pagas por CU solicitada como tarifa de prioridad. Estos se configuran a través del programa ComputeBudget, normalmente con las instrucciones SetComputeUnitLimit y SetComputeUnitPrice colocadas al inicio de la transacción. Trata el límite como una declaración de capacidad y el precio como una oferta para la inclusión en el bloque; sirven para propósitos diferentes y deben ajustarse por separado.

Este artículo se centra en el mecanismo y un método de medición reproducible. Para elecciones concretas de endpoint y proveedor, utiliza el Asistente RPC en lugar de codificar suposiciones sobre qué clúster o proveedor usar.

• Límite de unidades de cómputo: CU máximas que la transacción puede consumir.
• Precio de la unidad de cómputo: lamports por CU solicitada, utilizado para las tarifas de prioridad.
• El límite solicitado, no el uso real, impulsa el cálculo de la tarifa de prioridad.
• Los límites y precios se establecen con instrucciones del programa ComputeBudget.

Supuestos y requisitos previos

Los ejemplos asumen un endpoint JSON-RPC de Solana accesible en RPC_URL, un par de claves con fondos para enviar transacciones, y una biblioteca cliente que pueda construir y firmar transacciones. Los ejemplos en JavaScript usan @solana/web3.js; los ejemplos en Python usan solana-py y solders. Las API de las versiones cambian, así que verifica los nombres de los métodos con la versión de la biblioteca que instales.

También debes saber a qué clúster te diriges. Devnet y mainnet tienen diferentes mercados de tarifas y diferente uso de CU observado para el mismo programa, así que mide en el clúster donde pretendes desplegar. Si aún estás eligiendo un endpoint, la guía sobre el mejor proveedor RPC de Solana y la guía de endpoints RPC explican qué evaluar.

npm install @solana/web3.js
# or
pip install solana solders

Cómo interactúan el límite y el precio

El runtime ejecuta las instrucciones en orden y deduce CU a medida que se realiza el trabajo. El límite declarado se compara con el uso acumulado. Si la transacción termina por debajo del límite, tiene éxito y el margen no utilizado simplemente no se usa. Si lo supera, falla. Esto significa que el límite debe ser al menos tan grande como la ruta de peor caso que tu transacción puede tomar, incluidas las ramas condicionales dentro de los programas invocados.

La tarifa de prioridad se calcula a partir del límite solicitado multiplicado por el precio solicitado, no del consumo real. Una transacción que solicita un límite muy alto y usa una fracción de él sigue pagando tarifas de prioridad sobre el monto total solicitado. Por lo tanto, solicitar en exceso es un costo directo, mientras que solicitar por debajo causa fallos. El objetivo práctico es un límite ligeramente superior al uso observado en el peor caso, combinado con un precio que refleje las condiciones actuales de la red.

Debido a que la tarifa depende del límite solicitado, ajustar el límite y ajustar el precio están acoplados en costo pero son independientes en mecanismo. Reduce el límite para disminuir las tarifas por transacción, luego ajusta el precio para competir por la inclusión. Mide ambos por separado para poder atribuir los cambios correctamente.

Establecer el presupuesto de cómputo en JavaScript

El siguiente ejemplo construye una transacción con un límite y un precio explícitos. Reemplaza RPC_URL, PRIVATE_KEY y la instrucción con los tuyos. Las funciones auxiliares crean las instrucciones de ComputeBudget y las anteponen a la transacción.

Ejecuta esto primero contra una transacción de prueba. El objetivo es confirmar que las instrucciones son aceptadas y observar la firma resultante y el comportamiento de confirmación antes de aplicar el patrón al tráfico de producción.

import {
  Connection, Keypair, Transaction, TransactionInstruction,
  ComputeBudgetProgram, sendAndConfirmTransaction, PublicKey
} from '@solana/web3.js';
import bs58 from 'bs58';

const connection = new Connection('RPC_URL', 'confirmed');
const payer = Keypair.fromSecretKey(bs58.decode('PRIVATE_KEY'));

const CU_LIMIT = 200_000;      // requested limit
const MICRO_LAMPORTS_PER_CU = 1_000; // price per CU

const ix = new TransactionInstruction({
  programId: new PublicKey('YourProgram111111111111111111111111111111'),
  keys: [],
  data: Buffer.alloc(0),
});

const tx = new Transaction().add(
  ComputeBudgetProgram.setComputeUnitLimit({ units: CU_LIMIT }),
  ComputeBudgetProgram.setComputeUnitPrice({ microLamports: MICRO_LAMPORTS_PER_CU }),
  ix
);

const sig = await sendAndConfirmTransaction(connection, tx, [payer]);
console.log('confirmed', sig);

Establecer el presupuesto de cómputo en Python

La ruta de Python usa solders para las instrucciones de ComputeBudget y solana-py para el cliente. La estructura refleja el ejemplo de JavaScript: construir las instrucciones, anteponerlas, firmar y enviar. Mantén el límite y el precio como constantes con nombre para poder cambiarlos en un solo lugar durante la medición.

Si tu biblioteca cliente expone un método de simulación, úsalo antes de enviar. La simulación informa las CU consumidas sin confirmar la transacción, lo que es la forma más rápida de recopilar datos de dimensionamiento.

from solana.rpc.api import Client
from solana.rpc.commitment import Confirmed
from solana.transaction import Transaction
from solders.keypair import Keypair
from solders.compute_budget import set_compute_unit_limit, set_compute_unit_price
from solders.instruction import Instruction
from solders.pubkey import Pubkey

client = Client('RPC_URL')
payer = Keypair.from_base58_string('PRIVATE_KEY')

CU_LIMIT = 200_000
MICRO_LAMPORTS_PER_CU = 1_000

ix = Instruction(Pubkey.from_string('YourProgram111111111111111111111111111111'), b'', [])

tx = Transaction().add(
    set_compute_unit_limit(CU_LIMIT),
    set_compute_unit_price(MICRO_LAMPORTS_PER_CU),
    ix,
)
tx.recent_blockhash = client.get_latest_blockhash(Confirmed).value.blockhash
tx.sign(payer)

resp = client.send_transaction(tx)
print(resp.value)

Medir el uso real de cómputo

No dimensiones los límites por intuición. Simula la transacción y lee las unidades consumidas reportadas. La respuesta de simulación incluye el número de CU que usó la transacción, que es la entrada empírica para tu decisión de límite. Ejecuta la simulación con entradas representativas, incluidos casos límite y las cargas útiles más grandes que acepta tu programa.

Un procedimiento defendible es: (1) recopilar una muestra de transacciones reales o realistas; (2) simular cada una y registrar las CU consumidas; (3) calcular el máximo y un percentil alto; (4) establecer el límite por encima del máximo con un pequeño margen de seguridad; (5) volver a simular con el límite elegido para confirmar el éxito. Registra el tamaño de la muestra y el clúster, porque los resultados no son portables entre clústeres o versiones de programa.

La tabla de resultados a continuación es una plantilla. Rellénala con tus propios valores medidos; no trates ningún número aquí como un punto de referencia.

const sim = await connection.simulateTransaction(tx, [payer]);
console.log('err', sim.value.err);
console.log('unitsConsumed', sim.value.unitsConsumed);
console.log('logs', sim.value.logs);

Plantilla de tabla de resultados para dimensionar límites

Usa una tabla como la siguiente para documentar tu ejecución de medición. Las columnas separan el caso de entrada del uso observado y la decisión, para que un revisor pueda reproducir el razonamiento.

La columna de margen es la diferencia entre el límite elegido y el uso máximo observado. Un margen demasiado pequeño arriesga fallos cuando cambia el comportamiento del programa; un margen demasiado grande aumenta las tarifas de prioridad en cada transacción. Elige el margen deliberadamente y revísalo cuando cambie el programa o sus dependencias.

Solución de problemas comunes del presupuesto de cómputo

La mayoría de los problemas de presupuesto de cómputo se ajustan a unos pocos patrones. La transacción falla con un error de presupuesto de cómputo excedido, lo que significa que el límite está por debajo del uso real. La transacción se confirma pero cuesta más de lo esperado, lo que generalmente significa que el límite está muy por encima del uso. O la transacción tarda en confirmarse a pesar de un precio alto, lo que apunta a las condiciones del mercado de tarifas en lugar del límite en sí.

Cuando una transacción falla por presupuesto excedido, simúlala sin anulación de límite para ver el consumo natural, luego eleva el límite por encima de ese valor. Cuando los costos son altos, reduce el límite hacia el uso observado y vuelve a medir. Cuando la confirmación es lenta, ajusta el precio de forma independiente y compara los tiempos de confirmación en una muestra en lugar de una sola transacción.

También verifica el orden de las instrucciones. Las instrucciones de ComputeBudget deben aparecer antes de las instrucciones que configuran. Si se colocan después, la configuración puede no aplicarse como se pretende.

• Presupuesto excedido: eleva el límite por encima del uso simulado.
• Costo inesperado: reduce el límite hacia el uso observado.
• Confirmación lenta: ajusta el precio por separado del límite.
• Configuración mal aplicada: verifica que las instrucciones de ComputeBudget vayan primero.

Limitaciones y compensaciones

El ajuste del presupuesto de cómputo es empírico y específico del entorno. Un límite que funciona en devnet puede ser incorrecto en mainnet, y un límite que funciona hoy puede fallar después de una actualización del programa. Trata los límites medidos como configuración versionada, no como constantes. Vuelve a medir después de cualquier cambio en el programa, sus dependencias o la forma de los datos de instrucción.

También hay una compensación de costos. Un límite generoso protege contra fallos pero aumenta las tarifas de prioridad porque las tarifas se basan en el límite solicitado. Un límite ajustado reduce las tarifas pero aumenta el riesgo de fallo. El equilibrio correcto depende de cuán costosa es una transacción fallida para tu aplicación y cuán predecibles son tus entradas.

Finalmente, el presupuesto de cómputo es solo una parte de la economía de las transacciones. Las condiciones de la red, la contención de cuentas y el espacio de bloque afectan la inclusión. Para una visión más amplia de las opciones de infraestructura, consulta nodos dedicados y precios de RPC.

Próximos pasos para la monitorización en producción

Una vez que tengas un límite medido, instrumenta tu cliente para registrar el uso simulado y real por transacción. Compara ambos a lo largo del tiempo; la divergencia indica un cambio en el programa o un caso de entrada que no muestreaste. Alerta cuando el uso real se acerque al límite elegido, porque esa es la señal para volver a medir.

Para la selección de endpoints y la planificación de la fiabilidad, revisa la descripción general del servicio API y las redes en las que operas. Si estás comparando proveedores para el envío de transacciones de alto volumen, el Asistente RPC puede ayudarte a elegir un endpoint concreto; mantén la metodología de medición aquí como la fuente de verdad para tus límites.

Un siguiente paso práctico es crear un pequeño script que simule un lote de transacciones representativas, escriba los resultados en una tabla e imprima el límite recomendado. Ejecútalo de forma programada y después de cada despliegue de programa para que tu presupuesto de cómputo se mantenga alineado con la realidad.