Puntos Clave de Transacciones de Aterrizaje
Aterrizar una transacción significa que un líder la incluye en un bloque mientras su blockhash reciente aún es válido, de modo que la firma pasa de "desconocida" a un estado confirmado que puedes mostrar en la UX del producto.
Esta página es el mapa conceptual de Tarifas de Prioridad y Optimización de Transacciones: por qué las transacciones se detienen, cómo interactúan el precio y los límites de CU, cómo los clientes reintentan de forma segura, cuándo ayudan las ALTs y Jito, y cómo las elecciones de ensamblaje dan forma a los mercados de tarifas locales en Agave 4.1.1.
Resumen
- La inclusión es una carrera contra la expiración del blockhash bajo la capacidad del líder y la competencia de tarifas; los clientes la ganan ofertando inteligentemente (tarifas de prioridad / propinas), solicitando el presupuesto de cómputo correcto, ajustándose al paquete (v0 + ALTs) y retransmitiendo o reconstruyendo con reintentos disciplinados.
- Por Qué Importa: La simulación puede tener éxito mientras que mainnet aún descarta el paquete; los usuarios ven "pendiente para siempre" y los lanzamientos fallan cuando el aterrizaje es una ocurrencia tardía en lugar de una métrica del producto.
- Conceptos Clave: tasa de aterrizaje, blockhash reciente / lastValidBlockHeight, límite de unidad de cómputo (CU), precio de unidad de cómputo (microLamports), tarifa de prioridad, mercado de tarifas local, tabla de búsqueda de direcciones (ALT), transacción versionada (v0), paquete Jito / propina, preflight vs confirmación.
- Cuándo Usar Este Modelo: Diseño de pipelines de envío para billeteras, retransmisores, acuñaciones o rutas DeFi; depuración de caídas intermitentes; establecimiento de políticas de tarifas y reintentos antes de un tráfico alto.
- Limitaciones / Compensaciones: Las ofertas y propinas más altas aumentan el costo del usuario; la simulación no reserva capacidad del líder; Jito y RPC privados mejoran la probabilidad, no la corrección del programa; reintentar en exceso sin idempotencia arriesga la doble ejecución.
- Temas Relacionados: Por Qué Fallan las Transacciones al Aterrizar, Estimación de Unidades de Cómputo, Establecimiento de Tarifas de Prioridad, Reintentos y Gestión de Blockhash, Tablas de Búsqueda de Direcciones en la Práctica, Paquetes Jito, Ensamblaje de Transacciones.
Fundamentos
Un cliente construye un mensaje (instrucciones, metadatos de cuenta, pagador de tarifas, blockhash reciente), lo firma y envía la transacción serializada a través de RPC o un motor de bloques. El nodo puede ejecutar una simulación de preflight, luego reenviar el paquete hacia los próximos líderes.
Aterrizar es la inclusión en un bloque producido. Confirmación es qué tan avanzado está ese bloque a través de votos (processed → confirmed → finalized). El éxito del producto casi siempre significa "aterrizado y exitoso bajo el compromiso que elegiste", no "RPC aceptó el envío".
sendTransaction devolviendo una firma solo prueba que el nodo aceptó la ruta de envío. La firma puede permanecer desconocida para siempre si el paquete nunca gana un espacio antes de que expire el blockhash (~150 ranuras, a menudo un minuto de tiempo real).
| Resultado | Lo que observas | Causa Típica |
|---|---|---|
| Nunca incluido | Estado desconocido / nulo después de esperar | Subvalorado, descartado, blockhash expirado, paquete sobredimensionado, par incorrecto |
| Incluido, programa falló | Firma encontrada, meta.err establecido | Lógica, cuentas, CU excedido durante la ejecución |
| Incluido, exitoso | Estado en el compromiso elegido, sin error | Ruta saludable |
Solo la primera fila es un problema puro de aterrizaje. El presupuesto de CU todavía importa tanto para la economía del aterrizaje (precio × límite) como para la segunda fila (fallo de ejecución después de la inclusión).
Las tarifas tienen dos capas. Una tarifa base cubre las firmas. Una tarifa de prioridad se establece con instrucciones de Presupuesto de Cómputo: establecer límite de unidad de cómputo y establecer precio de unidad de cómputo (microLamports por CU). Los lamports de prioridad escalan aproximadamente con precio × límite / 1_000_000. Los líderes usan señales de tarifas cuando muchas transacciones compiten por la capacidad del bloque y los bloqueos de cuentas.
Esa competencia es a menudo local: las cuentas activas (una bóveda de acuñación, un pool popular, configuración compartida) crean un mercado de tarifas local para las transacciones que escriben esas claves, incluso cuando el resto de la red está tranquila.
Mecánicas e Interacciones
Por qué las transacciones fallan al aterrizar
Los líderes tienen capacidad finita por ranura. Bajo carga, prefieren trabajo de mayor valor. Tu transacción también compite contra la validez del blockhash: después de lastValidBlockHeight, los validadores rechazan el mensaje.
Caminos de descarte comunes:
- Prioridad subvalorada en relación con los pares que bloquean las mismas cuentas activas.
- Serialización sobredimensionada (mensajes heredados con demasiadas claves públicas completas).
- Problemas de RPC / ruta: puntos finales públicos, pérdida de paquetes o pares que nunca llegan al líder actual.
- Blockhash obsoleto en el momento de la firma o un bucle de reintento que mantiene un hash expirado.
- Falsa confianza de preflight: la simulación OK en una instantánea del banco no reserva capacidad del líder.
Trata la tasa de aterrizaje (envíos que llegan a confirmed sin agotar reconstrucciones) y el tiempo p95 hasta confirmado como métricas del producto.
Tarifas de prioridad y precio de CU
Usa getRecentPrioritizationFees (opcionalmente limitado a las cuentas que tu transacción bloquea) o una API de tarifas del proveedor. Apunta a un percentil: p50 tranquilo, p75 UX predeterminado, p90 acuñaciones y otras contenciones. Aplica un pequeño factor de seguridad y un límite estricto para que los picos de tarifas no agoten a los usuarios.
priority_fee_lamports ≈ (microLamports_por_CU × compute_unit_limit) / 1_000_000
total_user_fee ≈ base_signature_fee + priority_fee_lamports (+ propina opcional)
El precio y el límite se multiplican. Un límite de CU inflado con un precio agresivo paga de más; un límite ajustado con un precio alto aún falla si la ejecución excede el límite después de la inclusión. Fija el límite a partir de mediciones primero, luego oferta el precio para la inclusión.
Estimación de unidades de cómputo
Los presupuestos predeterminados no están ajustados para tu ruta. Simula la transacción completamente ensamblada, lee unitsConsumed y establece SetComputeUnitLimit a aproximadamente consumido × 1.1–1.2 de margen para varianza de estado.
En pilas de la era Agave 4.1.1, los techos de CU por transacción son finitos. La simulación que falla es un problema de corrección; la simulación que tiene éxito con un alto consumo es una señal de tarifa y riesgo. Las pruebas locales (Anchor 0.32.1, LiteSVM, Surfpool) perfilan la CU en el desarrollo; los percentiles de tarifas de mainnet aún necesitan muestras de RPC en vivo.
Reintentos y gestión de blockhash
Dos operaciones diferentes:
- Retransmitir los mismos bytes firmados mientras el blockhash aún es válido (misma firma, más propagación).
- Reconstruir con un nuevo
getLatestBlockhash, nuevo mensaje y nuevas firmas (identidad de transacción diferente).
Prefiere el control de la aplicación: a menudo bajo o cero RPC maxRetries, luego tu bucle espera la confirmación, retransmite la misma forma serializada hasta la expiración de la altura, y solo entonces reconstruye con un blockhash y muestra de tarifas frescas. Rastrea lastValidBlockHeight y deja de retransmitir después de que pase. Las nonces duraderas reemplazan los blockhashes recientes de corta duración para flujos de múltiples firmantes lentos.
La idempotencia importa: si el primer intento aún puede aterrizar tarde, una segunda reconstrucción puede ejecutarse dos veces a menos que la ruta del programa sea segura para reintentar.
Tablas de búsqueda de direcciones
Las transacciones v0 versionadas más las tablas de búsqueda de direcciones reemplazan muchas claves de 32 bytes con índices de 1 byte en una tabla en cadena. Eso reduce los paquetes para que los intercambios de múltiples saltos y los ensamblajes de múltiples instrucciones permanezcan dentro de los límites de tamaño que los líderes propagarán.
Ciclo de vida: crear → extender con claves públicas estables → esperar activación (~1 ranura) → compilar v0 con tablas de búsqueda → opcionalmente congelar. Los clientes que usan @solana/kit 7.0.0 obtienen la ALT antes de compilar para que los índices coincidan con el orden en cadena. Las ALTs no aumentan la prioridad por sí solas; eliminan una razón de descarte estructural y liberan espacio para instrucciones de presupuesto y propina.
Paquetes Jito
Los motores de bloques Jito aceptan paquetes: transacciones ordenadas que aterrizan juntas atómicamente, típicamente con una transferencia de propina. Úsalos cuando el orden y la atomicidad importen (acuñación + propina, rutas de múltiples tramos) o cuando la exposición pública del mempool sea inaceptable para flujos de alto valor.
Los paquetes complementan las tarifas de prioridad nativas; no reemplazan los límites de CU correctos ni los blockhashes válidos. Los mercados de propinas tienen su propia curva de costos; resérvalos para ventanas de contención y rutas de alto valor.
Estrategias de ensamblaje
El orden de las instrucciones es parte de la confiabilidad del aterrizaje y la eficiencia de las tarifas:
- Presupuesto de cómputo: límite, luego precio.
- Configuración que debe preceder a la lógica de negocio (crear ATA idempotente, abrir cuentas).
- Instrucciones del programa principal.
- Propina / limpieza opcional por paquete o política del producto.
Compila con la versión de mensaje correcta, el conjunto completo de firmantes y el conjunto mínimo de cuentas escribibles. Marcar en exceso las cuentas escribibles aumenta la contención de bloqueo y puede empeorar el mercado de tarifas local en el que ofertas. Simula la forma serializada final antes del envío a mainnet.
obtener blockhash + muestras de tarifas (+ cuentas ALT)
→ anteponer límite de CU + precio → ixs principales (+ propina opcional)
→ compilar v0 con ALTs → firmar → simular
→ enviar (RPC y/o Jito) → esperar compromiso
desconocido & hash válido → retransmitir mismos bytes
expirado / tiempo agotado → reconstruir (nuevo hash, tarifas, firmar)
aterrizado + error → arreglar programa/cuentas (no reintentar ciegamente)
aterrizado + ok → hecho
Consideraciones y Aplicaciones Avanzadas
Los mercados de tarifas locales se forman alrededor de cuentas escribibles disputadas. Muestrear tarifas de priorización con las cuentas que tu ruta bloquea a menudo supera las muestras globales vacías cuando la congestión es específica de la ruta. Mantén perfiles de tarifas por plantilla (transferencia vs swap vs acuñación) con pisos, percentiles y límites separados.
SWQoS y RPC privado mejoran la probabilidad de que los paquetes lleguen a los líderes. Se emparejan con la política de tarifas; no la reemplazan. Las rutas de envío de producción generalmente desean un nivel de pago y envío de doble ruta para rutas críticas (RPC más motor de bloques).
UX de costos: muestra la SOL de prioridad estimada de precio × límite, más la tarifa base y la propina opcional. Limita los multiplicadores durante los picos. Las funciones de bandera (feature flags) para percentiles agresivos te permiten reducir fuera de horas pico sin una crisis de implementación.
Medición: registra la firma, el ID de ruta, los microLamports, el límite de CU, las unidades consumidas (simulación y metadatos aterrizados), los lamports de propina, los intentos y el tiempo hasta confirmado. La tasa de aterrizaje y la tarifa por confirmación exitosa dirigen la elección del percentil.
| Situación | Preferir |
|---|---|
| Mainnet tranquilo, ix simple | Precio de CU modesto, reintento estándar |
| Cuentas activas compartidas | Muestras de tarifas con ámbito de cuenta, percentil más alto |
| Listas grandes de cuentas | Trabajo de mantenimiento de v0 + ALT |
| Multi-tx atómico o día de acuñación | Política de paquete Jito + propina |
| Multisig / firma lenta | Nonce duradera |
| Simulación falla | Arreglar programa o cuentas antes de aumentar tarifas |
Advertencia sobre Devnet: los mercados de tarifas y las tasas de descarte no coinciden con mainnet. Valida el ensamblaje, la activación de ALT y las máquinas de estado de reintento en devnet; valida los percentiles de tarifas y los SLOs de aterrizaje con pequeñas sondas en mainnet.
Conceptos Erróneos Comunes
- "RPC devolvió una firma, así que la transacción aterrizó." La aceptación no es inclusión; espera el estado o la suscripción hasta que las reglas de expiración lo indiquen.
- "Tarifa de prioridad cero está bien si la simulación pasó." La simulación no compra prioridad del líder; bajo congestión, el trabajo con oferta cero se muere primero.
- "Límite de CU máximo más precio máximo siempre gana barato." Multiplicas el costo; ajusta el límite a partir de la simulación, luego oferta el precio con un límite.
- "Aumentar el límite de CU soluciona las caídas de aterrizaje." El límite previene fallos de cómputo excedido después de la inclusión; las caídas necesitan tarifas, tamaño, ruta y disciplina de blockhash.
- "RPC maxRetries solo es una estrategia de reintento." Sin blockhashes frescos y esperas de confirmación, inundas trabajo expirado; controla el bucle.
- "Las transacciones heredadas son más simples, por lo que aterrizan más a menudo." Las listas de cuentas heredadas sobredimensionadas se descartan; v0 + ALTs son la ruta confiable para rutas grandes.
- "Las propinas Jito reemplazan el precio de unidad de cómputo." Las propinas incentivan la inclusión de paquetes; las tarifas de prioridad nativas aún importan para envíos que no son de paquetes y pueden coexistir.
- "Cualquier reintento es seguro." Las reconstrucciones con nuevas firmas pueden aplicarse dos veces si la primera transacción aún aterriza; diseña instrucciones idempotentes o rastrea el estado en tránsito.
- "El percentil de tarifas global equivale al mercado de mi ruta." La contención local en tus cuentas escribibles puede divergir de las muestras a nivel de red.
- "El aterrizaje en Devnet prueba la política de Mainnet." Las mecánicas se transfieren; los niveles de tarifas y la contención no.
Preguntas Frecuentes
¿Qué significa "aterrizar" en una oración?
Un líder incluyó tu transacción en un bloque antes de que su blockhash reciente se volviera inválido, de modo que la firma sea descubrible en cadena (éxito o error del programa).
¿En qué se diferencia el aterrizaje de la confirmación?
Aterrizar es inclusión. La confirmación es cuántos validadores han votado sobre ese bloque (processed, confirmed, finalized). La UX generalmente espera al menos confirmed.
¿Por qué las transacciones fallan al aterrizar si la simulación tiene éxito?
La simulación verifica la ejecución contra una instantánea del banco. No reserva capacidad del líder, gana una subasta de tarifas, ni garantiza la propagación del paquete antes de la expiración del blockhash.
¿Cómo se relacionan las tarifas de prioridad con el precio de la unidad de cómputo?
El precio de la unidad de cómputo son microLamports por CU. La tarifa de prioridad pagada escala con ese precio multiplicado por el límite de unidad de cómputo que solicitas (las tarifas base de firma son separadas).
¿Cómo debo estimar las unidades de cómputo antes del envío?
Ensambla la transacción real, simúlala, lee unitsConsumed, agrega aproximadamente un 10-20% de margen, y establece SetComputeUnitLimit. Detalles en Estimación de Unidades de Cómputo.
¿Qué percentil debo usar para las tarifas de priorización?
Comienza alrededor de p75 con un pequeño multiplicador y un límite estricto para la UX normal; aumenta hacia p90 para acuñaciones y ventanas activas; mide la tasa de aterrizaje y ajusta. Ver Establecimiento de Tarifas de Prioridad.
¿Cuándo debo retransmitir vs. reconstruir con un nuevo blockhash?
Retransmite la misma transacción firmada mientras lastValidBlockHeight aún esté por delante. Reconstruye y vuelve a firmar cuando el hash expire o debas cambiar tarifas o instrucciones. Ver Reintentos y Gestión de Blockhash.
¿Las transacciones fallidas en cadena aún pagan tarifas de prioridad?
Si la transacción se incluye y falla durante la ejecución, las tarifas de inclusión aún se aplican. Las transacciones descartadas que nunca aterrizan no pagan nada en cadena.
¿Cuándo debo usar tablas de búsqueda de direcciones?
Cuando las listas de cuentas hacen que los mensajes heredados sean demasiado grandes o no dejan espacio para instrucciones de presupuesto y propina. Usa compilación v0 con ALTs mantenidas. Ver Tablas de Búsqueda de Direcciones en la Práctica.
¿Cuándo debo usar paquetes Jito en lugar de un envío normal?
Cuando necesites orden atómico de múltiples transacciones, incentivos de inclusión más fuertes a través de propinas, o menor exposición al mempool público para flujos de alto valor. Ver Paquetes Jito.
¿Qué es un mercado de tarifas local?
Presión de tarifas concentrada en transacciones que bloquean las mismas cuentas escribibles activas (pools, acuñaciones, bóvedas compartidas), que pueden superar los promedios globales tranquilos. Muestra tarifas con esas cuentas cuando sea posible.
¿En qué orden debo ensamblar las instrucciones?
Presupuesto de cómputo primero, luego configuración de cuentas, luego instrucciones de negocio principales, luego propinas opcionales o limpieza. Los patrones completos se encuentran en Ensamblaje de Transacciones.
¿Ayuda skipPreflight al aterrizaje?
skipPreflight: true puede reducir la latencia pero envía más transacciones condenadas. Prefiere preflight activado para billeteras de usuario; el salto selectivo es para rutas de baja latencia especializadas que ya simularon sin conexión.
¿Pueden las tarifas de prioridad garantizar el aterrizaje?
No. Aumentan la probabilidad de inclusión bajo contención. Errores de programa, agotamiento de CU, cuentas incorrectas, blockhashes expirados y fallos de ruta aún impiden el éxito.
¿Cómo encajan @solana/kit y Anchor en este modelo?
Anchor 0.32.1 da forma a programas en cadena y clientes impulsados por IDL; @solana/kit 7.0.0 construye, firma, simula y envía transacciones versionadas. Ninguno elimina la necesidad de una política de tarifas, CU, blockhash y confirmación.
Relacionado
- Por Qué Fallan las Transacciones al Aterrizar - categorías de fallos y señales de triaje
- Estimación de Unidades de Cómputo - límites de CU basados en simulación y margen
- Establecimiento de Tarifas de Prioridad - percentiles, límites y estrategia de precio de CU
- Reintentos y Gestión de Blockhash - retransmisión, reconstrucción y nonces duraderas
- Tablas de Búsqueda de Direcciones en la Práctica - reducción de tamaño v0 para grandes conjuntos de cuentas
- Paquetes Jito - rutas de aterrizaje atómicas basadas en propinas
- Ensamblaje de Transacciones - orden de instrucciones, empaquetado y lista de verificación de compilación
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0.