¿Por qué las transacciones no llegan?
Las transacciones no llegan cuando los blockhashes expiran, los presupuestos de cómputo se agotan, las tarifas de prioridad son demasiado bajas o el envío de RPC nunca llega a un líder.
Receta
Tarjeta de receta de referencia rápida - lista para copiar y pegar.
solana confirm -v <SIGNATURE>
solana transaction <SIGNATURE> --output json-compact | jq '.meta.err, .meta.logMessages'const sim = await rpc.simulateTransaction(wireTx, { sigVerify: false }).send();
console.log(sim.value.err, sim.value.unitsConsumed);Cuándo usar esto:
- Los usuarios informan transacciones pendientes "atascadas".
- La simulación tiene éxito pero el envío en mainnet nunca se confirma.
- Fallos intermitentes durante acuñaciones de NFT o airdrops.
- Análisis post-mortem después de picos de incidentes.
Ejemplo de trabajo
import { createSolanaRpc } from "@solana/kit";
const rpc = createSolanaRpc(process.env.RPC_URL!);
const status = await rpc.getSignatureStatuses([signature]).send();
const value = status.value[0];
console.log({
confirmationStatus: value?.confirmationStatus,
err: value?.err,
slot: value?.slot,
});
const tx = await rpc
.getTransaction(signature, { encoding: "json", maxSupportedTransactionVersion: 0 })
.send();
console.log("error al aterrizar:", tx?.value?.meta?.err);
console.log("cola de logs:", tx?.value?.meta?.logMessages?.slice(-5));Lo que esto demuestra:
getSignatureStatusesmuestra si la firma es desconocida (descartada) vs fallida vs confirmada.- Las transacciones fallidas aterrizadas incluyen errores de programa en meta.
- Una firma desconocida a menudo significa que nunca se incluyó antes de la expiración del blockhash.
Inmersión Profunda
Cómo funciona
- Los líderes priorizan las transacciones por tarifa y precio de cómputo durante la congestión.
- El blockhash reciente en la transacción expira después de ~150 slots (~60-90s de reloj).
- El medidor de CU detiene la ejecución cuando se excede el límite - la transacción falla en la cadena.
- RPC puede aceptar
sendTransactionpero el validador descarta la tx si tiene un precio bajo.
Categorías de Fallo
| Síntoma | Causa probable | Dirección de la solución |
|---|---|---|
| Firma no encontrada | Descartada / blockhash expirado | Reconstruir tx, tarifa de prioridad más alta |
| Error de programa en meta | Error de lógica | Corregir programa o cuentas |
| CU excedido | Límite demasiado bajo | Aumentar el presupuesto de cómputo |
| Blockhash no encontrado | Demasiado antiguo | Blockhash fresco + reintentar |
Notas de bash
# Comprobar si la antigüedad del blockhash sigue siendo válida en el momento del envío - comparar el slot actual con el slot de la tx en los logs
solana slotTrampas
- Asumir que RPC OK significa aterrizado -
sendTransactiondevuelve la firma antes de la inclusión. Solución: rastrear el estado de confirmación por separado. - Tarifa de prioridad cero en mainnet congestionada - la tx se queda sin cola. Solución: tarifas dinámicas (Establecer Tarifas de Prioridad).
- CU predeterminado de 200k demasiado bajo - las tx complejas fallan la simulación. Solución: estimar CU (Estimar Unidades de Cómputo).
- Envío RPC único - pérdida de paquetes o par malo. Solución: retransmitir con reintentos (Reintentos y Gestión de Blockhash).
- Transacción heredada demasiado grande - excede el tamaño del paquete. Solución: v0 + ALTs (Tablas de Búsqueda de Direcciones en la Práctica).
Alternativas
| Alternativa | Usar cuándo | No usar cuándo |
|---|---|---|
| Paquetes Jito | Aterrizaje de alta contención | Pruebas simples en devnet |
| Nonce duradero | Flujo de firma de larga duración | Transacciones normales con blockhash fresco |
| Envío RPC privado | Mejor propagación | MVP sensible al costo |
| Ventana de menor tráfico | Mitigación de operaciones | UX en tiempo real orientada al usuario |
Preguntas Frecuentes
¿El fallo de simulación garantiza que no aterrizará?
Generalmente, pero las condiciones de carrera son raras; trata la simulación como una señal fuerte.
¿Por qué éxito en devnet pero no en mainnet?
Congestión de mainnet y mayor contención de bloqueo de cuentas - las tarifas y CU difieren.
¿Qué es la expiración del blockhash?
El blockhash reciente de la transacción debe estar en la cola de blockhashes recientes conocida por los validadores - los hashes obsoletos rechazan la inclusión.
¿Puede una tx aterrizar y luego fallar?
Sí - incluida en el bloque con error de programa meta.err; aún pagas la tarifa base.
¿Cómo detecto transacciones descartadas?
getSignatureStatuses devuelve null para una firma desconocida después del período de espera.
¿Las tarifas de prioridad garantizan el aterrizaje?
No - mejoran la probabilidad bajo contención; los errores de programa y CU aún fallan.
¿Rol de skipPreflight?
false detecta errores temprano; true envío más rápido pero más txs malas descartadas.
¿Relevancia de la transacción versionada?
v0 habilita ALTs para ajustar listas grandes de cuentas - los límites de tamaño heredados causan descartes silenciosos.
¿Jito vs tarifa de prioridad?
Jito da propinas a los validadores en la ruta del paquete; las tarifas de prioridad son el precio nativo de la unidad de cómputo - complementarias.
¿Dónde está el pipeline de aterrizaje completo?
Relacionado
- Estimar Unidades de Cómputo - fallos de CU
- Establecer Tarifas de Prioridad - estrategia de tarifas
- Reintentos y Gestión de Blockhash - manejo de expiración
- APIs de Tarifa de Prioridad y Simulación - herramientas RPC
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.