Errores de transacciones de Solana: blockhash vencido y transacciones no incluidas

2026-08-24

Una transacción de Solana puede describirse a la vez en varias capas. Un mensaje describe las instrucciones propuestas y su contexto, una transacción firmada lleva la autorización para ese mensaje, una respuesta RPC informa lo que un servicio aceptó u observó y un registro del clúster es evidencia en un nivel de commitment indicado. Estas capas pueden producir frases de estado diferentes sin contradecirse. Por ello, leer un mensaje de vencimiento o de una transacción no incluida comienza por identificar la capa que lo produjo. Un tiempo de espera local, un error RPC, una respuesta de estado y un registro finalizado describen puntos distintos de una ruta de envío, no una conclusión universal sobre el estado resultante.

Diagrama de estados de una transacción de Solana desde el mensaje hasta el resultado registrado

Estado de la transacción y ruta de envío

Una transacción de Solana contiene instrucciones, firmas de cuentas que autorizan cambios y un recent blockhash. Cuando la red procesa la transacción, trata sus instrucciones como una unidad atómica: el fallo de una instrucción impide que los cambios de estado previstos queden registrados en conjunto. Antes de que exista ese resultado, la transacción puede pasar por etapas distintas de formación del mensaje, firma, relevo a un nodo RPC, recepción por participantes de la red, procesamiento y observación en un nivel de commitment. Una etiqueta de estado solo tiene significado cuando su etapa está clara.

El método RPC sendTransaction informa la primera firma de la transacción cuando el servicio RPC acepta la carga firmada para relevarla. La documentación oficial separa expresamente esa aceptación inmediata del procesamiento o la confirmación por el clúster. En la conversación habitual, dropped transaction suele nombrar la ausencia de un registro posterior del clúster tras un evento anterior relacionado con el envío. No es un único estado de consenso con una causa fija. La frase puede usarla un cliente, un servicio RPC o un observador, y cada uno puede referirse a una transición ausente diferente en la ruta.

El papel de un blockhash

El recent blockhash de un mensaje de transacción es una referencia de actualidad proporcionada por la red. El método getLatestBlockhash devuelve tanto un blockhash como lastValidBlockHeight, y conecta esa referencia con un límite de altura en vez de con una duración de reloj garantizada. Esto permite al protocolo evaluar si una transacción que lleva esa referencia sigue dentro de la ventana de procesamiento. El blockhash forma parte del mensaje evaluado, por lo que pertenece a la identidad y al contexto de validación de la transacción, no a una presentación posterior en un explorador.

La altura de bloque, el avance de los slots y el tiempo transcurrido están relacionados, pero no deben tratarse como relojes intercambiables. El parámetro exacto de edad de procesamiento, el número de slots descrito por la documentación y el tiempo que representan esos slots dependen de la versión pertinente del protocolo y del software, además de las condiciones de red. Por esa razón, un recent blockhash se entiende mejor como una ventana de validez dependiente de la versión. El hecho duradero es la existencia de un límite; una duración exacta no es una promesa universal.

Vencido y no encontrado son diferentes

Vencido describe un resultado de validez: el recent blockhash ya no se puede usar para que una transacción sea procesada bajo las reglas aplicables. Se refiere a la referencia limitada en el tiempo de la transacción, no a una etiqueta general para cada relevo fallido o registro ausente. Cuando las personas usan la frase de búsqueda solana transaction expired, a menudo nombran un resultado visible en el cliente que se corresponde con ese límite del ciclo de vida. La frase por sí sola no identifica qué recibió un nodo RPC concreto ni describe un resultado de transferencia independiente.

Blockhash not found solana es una frase de búsqueda que a menudo combina una cadena de pantalla con el nombre de la red. Un mensaje real de blockhash-not-found puede expresar que un nodo, en su vista actual y nivel de commitment, no puede resolver el hash referido para el contexto de validación correspondiente. Esa observación no equivale automáticamente a demostrar que la última altura válida haya pasado en todas partes. El estado del nodo, el commitment, la versión de API, el momento y el texto del cliente pueden cambiar cómo se presenta la misma condición amplia, por lo que las dos frases no deben reducirse a un diagnóstico invariable.

Firmada pero no incluida en un bloque

La firma es una autorización para un mensaje concreto; no es un registro de que el mensaje llegó a un bloque. Del mismo modo, que un servicio RPC acepte una carga para relevarla no es un registro de que el clúster la procesó. Por tanto, una transacción firmada puede describirse como firmada y aun así carecer de una observación procesada, confirmada o finalizada. Esa brecha por sí sola no revela si una carga nunca fue recibida por un participante relevante, no se conservó en un ámbito de estado visible o se volvió inválida antes de poder procesarse.

Los métodos de estado JSON-RPC hacen explícitos los límites de una observación. getSignatureStatuses devuelve los estados actuales de las firmas proporcionadas, y su búsqueda predeterminada se limita a una caché de estados reciente salvo que se incluya la búsqueda del historial de transacciones. getTransaction devuelve una transacción confirmada por firma o null cuando no se encuentra o no se confirma en el commitment solicitado. Por consiguiente, una respuesta null tiene un alcance delimitado, no es una declaración universal de que ningún evento existió jamás en la vista conservada de cada nodo.

Diferencias entre observaciones de RPC, cliente y red

Una interfaz de cliente suele convertir varias señales técnicas en una frase breve para que la lea una persona. Una respuesta RPC es, en cambio, el informe de un nodo particular, con un slot de contexto, versión de API, configuración y commitment solicitado. Una observación de red se refiere al estado que el commitment pertinente hace visible. Estas observaciones están relacionadas, pero no son el mismo objeto y no tienen por qué hacerse visibles en el mismo momento.

La dependencia de versión importa en cada capa. El software de nodo de Solana, las bibliotecas de cliente, la configuración RPC, el soporte de versiones de transacción, los valores predeterminados de commitment, la retención de estados y el texto de la interfaz pueden evolucionar. Una interpretación sólida identifica por eso al observador y al alcance de la observación antes de atribuir significado a una etiqueta de error. No presupone que una frase de una interfaz sea una descripción transportable de cada nodo, cada commitment o cada versión de software.

Por qué el reenvío repetido no es una respuesta universal

El reenvío repetido no es un único evento técnico. Puede significar relevar otra vez los mismos bytes firmados, presentar un mensaje diferente o crear un mensaje posterior con un contexto de validación distinto. Esos casos tienen identificadores, momentos y posibles efectos de estado diferentes. Una transacción que la red ya está considerando y una transacción posterior independiente con una intención similar no se vuelven intercambiables solo por expresar intenciones parecidas. La repetición puede, por tanto, dificultar la interpretación de la relación entre una firma visible, un registro de estado y un cambio de estado previsto.

Por la misma razón, una prescripción genérica de reintento mezclaría recepción, propagación, validación, ejecución y commitment en una sola idea. El lenguaje de vencimiento no establece por sí mismo que un mensaje posterior tenga la misma identidad o efecto que uno anterior. En términos analíticos, la distinción importante es si la evidencia disponible se refiere al mismo mensaje de transacción, a un mensaje separado o solo a un intento local de relevar datos. El tema del artículo es esa distinción, no un procedimiento para enviar otra transacción.

Vocabulario estable de diagnóstico y límites de riesgo

Un vocabulario estable ayuda a mantener separadas las capas. Mensaje nombra las instrucciones, cuentas, recent blockhash y otros datos que se autorizan. Firma identifica una transacción firmada para API orientadas al estado. Envío nombra un evento de relevo RPC, mientras que procesamiento, confirmación y finalización nombran distintos niveles de observación de red. Commitment es el umbral de visibilidad solicitado que usan los métodos RPC. El vencimiento se refiere a la referencia de actualidad y dropped suele describir una ruta observada incompleta, no un veredicto de protocolo con un significado estandarizado.

El límite de estos términos es tan importante como sus definiciones. Un estado técnico no establece la propiedad de una cuenta, la intención de un remitente, un saldo de activos, la conducta de un servicio ni un remedio para un registro ausente. Tampoco convierte un mensaje de cliente en prueba de lo que observó cada validador o cada sistema de retención de datos. El lenguaje de estado es evidencia sobre una ruta de procesamiento limitada, interpretada mediante una versión, un observador, un commitment y un momento. Mantener claro ese límite evita convertir una señal de red estrecha en una afirmación más amplia.

Lecturas relacionadas

Otros artículos de Bitbase sobre este tema:

- MEV en Solana y ataques on-chain

- Kamino en Solana explicado

- Comisiones y rendimiento de Solana

Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en agosto de 2026; consulta la información oficial más reciente.