Cómo abordar los errores de blockhash en Solana

¿Qué es un blockhash?

Para entender qué es un blockhash, debes comprender qué son los slots y los bloques.

• Un slot es un periodo durante el cual un validador puede producir un bloque 
• Un bloque es un conjunto de transacciones y metadatos que procesa un validador. Los metadatos de cada bloque lo vinculan con el bloque anterior, lo que crea una cadena.

Es importante entender que los slots duran entre 400 y 600 ms y que, en cada slot, un validador puede proponer un bloque nuevo. Si no se crea un bloque, el slot avanza y otro validador intenta crear uno nuevo. Esto significa que no todos los slots tienen bloques asociados, pero todos los bloques tienen asociado el slot en el que se propusieron.

Entonces, ¿qué es un blockhash? Un blockhash es un valor hash único de todas las entradas del registro de la blockchain creadas durante un slot. Se calcula a partir del identificador de la última entrada del bloque. Cada bloque producido genera un blockhash único. Estos blockhashes se utilizan como marcas de tiempo.

¿Cuáles son los niveles de compromiso de Solana?

Otro concepto importante que debes entender son los niveles de compromiso. Estos niveles miden la confirmación de la red para un bloque específico. Las tres opciones son procesado, confirmado y finalizado.

Cuando un validador envía un bloque a la cadena, el bloque se encuentra en estado procesado. Una vez que la cantidad requerida de validadores (el 66 % de los validadores)  vota por incluir el bloque, este se añade a la cadena y el nivel de compromiso cambia a confirmado. Cuando se construyen otros 31 bloques sobre este, el nivel de compromiso cambia a finalizado.

¿Por qué ocurren los errores de blockhash?

Todas las transacciones incluyen un blockhash reciente que funciona como marca de tiempo. La transacción vence cuando el blockhash deja de considerarse suficientemente reciente. Los validadores que procesan transacciones revisan la “BlockhashQueue” (una lista de los últimos 300 blockhashes) para determinar si el blockhash de la transacción es suficientemente reciente. Si el blockhash no está en la lista, la transacción se rechaza. Como los slots suelen durar entre 400 y 600 ms, un blockhash permanece válido durante 60-90 segundos.

Blockhash no encontrado (Error en la simulación de la transacción: blockhash no encontrado)

Los errores de “blockhash no encontrado" ocurren cuando el blockhash incluido en una transacción no se considera válido en el momento en que un validador procesa la transacción. Esto puede deberse a que es demasiado antiguo o, en algunos casos, demasiado reciente. 

La causa más común de este error es que el blockhash incluido en una transacción no está presente en la cola de los últimos 300 blockhashes con la que el validador lo compara. Esto provoca el error de blockhash no encontrado. Las transacciones pueden vencer cuando no se crean y procesan dentro del periodo requerido. Esto puede ocurrir si un usuario tarda demasiado en firmar una transacción. También puede haber situaciones en las que se envía una transacción válida, pero no se incluye en el bloque actual. Cuando puede incluirse en un bloque posterior, el blockhash de la transacción ya es demasiado antiguo.

En situaciones como esta, donde la transacción ha vencido en la práctica, es común ver errores de altura de bloque superada (TransactionExpiredBlock heightExceededError). Para entender mejor este error, debes saber qué significa la altura de bloque. La altura de bloque se refiere a la cantidad de bloques que hay debajo del bloque actual. Si el bloque actual es el bloque 1000, la altura de bloque es 1000. Cuando se crea una transacción, se registra la altura máxima de bloque hasta la que será válida. Si durante el procesamiento de esta transacción se detecta que la altura del bloque actual supera la altura máxima de bloque válida de la transacción, se genera el error.

Otra situación que puede provocar un “error de blockhash no encontrado” ocurre cuando el blockhash de una transacción es más reciente que el blockhash utilizado para comprobar su vencimiento. Esto puede resultar confuso, así que veamos un ejemplo: creas una transacción e incluyes el blockhash de un bloque específico, digamos el bloque 1000, y la envías de inmediato a un RPC. El RPC puede obtener el blockhash del bloque anterior, que en este caso podría ser el bloque 999 (porque el RPC utiliza un nivel de compromiso más alto o porque el nodo RPC está retrasado respecto a la red). Como resultado, no se encuentra el blockhash de la transacción. Es una situación inusual, pero puede ocurrir en dos escenarios:

1. Niveles de compromiso diferentes

Al crear la transacción, se utiliza el nivel de compromiso confirmado, pero cuando el RPC calcula su validez, utiliza de forma predeterminada el nivel finalizado.

Esto puede hacer que el blockhash utilizado para la validación sea más antiguo que el de la transacción, ya que los bloques finalizados están 31 bloques “por detrás” del bloque más reciente.

Si se utiliza el nivel de compromiso procesado para obtener el blockhash de una transacción en una bifurcación minoritaria que finalmente se descarta, el blockhash no será válido ni se encontrará durante el procesamiento.

2. RPC diferentes

Si se utilizan dos RPC diferentes para obtener el blockhash y enviar la transacción, cualquier retraso del RPC que envía la transacción podría hacer que el bloque que utiliza para comprobar la validez sea más antiguo que el bloque utilizado al crear la transacción.

Cómo corregir los errores de blockhash

Puedes seguir algunos pasos para abordar cada una de las situaciones anteriores.

1. Asegúrate de enviar la transacción con un blockhash que no sea demasiado antiguo:

Utiliza el nivel de compromiso confirmed cuando obtengas el blockhash de una transacción. Así te aseguras de incluir un blockhash más reciente que con el nivel de compromiso finalized.

También puedes utilizar el nivel de compromiso processed para obtener un blockhash un poco más reciente, pero aproximadamente el 5 % de los bloques procesados no son finalizados por el clúster. Esto significa que el blockhash de la transacción pertenecería a una bifurcación descartada y dejaría de ser válido.

2. Asegúrate de que el blockhash de la transacción no sea más reciente que el blockhash utilizado para comprobar su validez:

Configura siempre preflightCommitment (incluso cuando utilices skipPreflight) con el mismo nivel de compromiso empleado para obtener el blockhash de la transacción. Esto te ayudará a evitar que el blockhash de la transacción sea más reciente que el blockhash utilizado para comprobar su validez.

Para lidiar con nodos RPC retrasados al enviar transacciones, debes seguir reenviando las transacciones al RPC. Puedes hacerlo a intervalos definidos para que, si un RPC está retrasado, termine por ponerse al día y detectar el vencimiento de la transacción.

Si utilizas la solicitud simulateTransaction, debes configurar el parámetro replaceRecentBlockhash. Esta opción indica al RPC que reemplace el blockhash de la transacción simulada por uno que siempre sea válido para la simulación.

3. Sigue reintentando la transacción mientras el blockhash sea válido:

Cuando crees una transacción y obtengas el blockhash más reciente, debes registrar el valor lastValidBlockHeight de ese blockhash. Luego puedes seguir reintentando la transacción con ese blockhash hasta que la altura del bloque actual supere la altura de bloque válida de la transacción. Puedes utilizar la llamada RPC getBlockHeight para comprobar continuamente si la transacción sigue siendo válida. Cuando la altura del bloque actual supere la altura lastValidBlock de la transacción, debes obtener y utilizar un blockhash nuevo.

Espero que este artículo te ayude a comprender mejor los errores de blockhash y cómo reducir la frecuencia con la que ocurren. Si tienes más preguntas, únete a nuestra comunidad de Discord o envíanos un mensaje directo en X.

Recursos adicionales:

• Documentación de Solana: transacciones 
• Blog de Helius: slots, bloques y épocas

‍