- Usar conexiones con stake (opción predeterminada)
- Usar servicios especializados de inclusión como Sender (recomendado)
Resumen
Las conexiones con stake de Helius garantizan una entrega de transacciones del 100 % con tiempos de confirmación mínimos. Para optimizar las tasas de inclusión de tus transacciones con conexiones con stake, recomendamos las siguientes prácticas:- Usa el commitment “confirmed” para obtener el blockhash más reciente
- Agrega comisiones de prioridad y calcúlalas dinámicamente
- Optimiza el uso de unidades de cómputo (CU)
- Establece
maxRetriesen 0 e implementa una lógica sólida de reintentos - Envía con
skipPreflightestablecido entrue(opcional)
Optimizaciones recomendadas para traders
Para casos de uso de trading sensibles a la latencia, recomendamos usar Sender. Sin embargo, si usas conexiones con stake y quieres optimizar tu configuración para obtener las latencias más bajas posibles, recomendamos las siguientes optimizaciones, además de aplicar las prácticas mencionadas anteriormente:- Tu servidor cliente (la máquina desde la que envías las transacciones) debe estar ubicado en el este de EE. UU. o en Europa occidental.
- Elige FRA o PIT si quieres ubicarte junto a los servidores de envío de transacciones de Helius.
- Evita realizar envíos desde regiones alejadas de la red de validadores (por ejemplo, Latinoamérica o Sudáfrica).
- Precalienta las cachés regionales de Helius para minimizar la latencia de cola.
- Solo se requiere un hilo de precalentamiento por región; agregar más no aportará ningún beneficio.
- Envía una llamada RPC
getHealthcada segundo con el mismo endpoint y la misma clave de API que usas para enviar transacciones.
Envío de transacciones inteligentes
Los SDK de Helius para TypeScript y Rust pueden enviar transacciones inteligentes. Este nuevo método crea y envía una transacción optimizada mientras gestiona su estado de confirmación. Los usuarios pueden configurar las opciones de envío de la transacción, como omitir o no las verificaciones previas. En el nivel más básico, los usuarios deben proporcionar su par de claves y las instrucciones que quieren ejecutar; nosotros nos encargamos del resto. Nosotros:- Obtenemos el blockhash más reciente
- Creamos la transacción inicial
- Simulamos la transacción inicial para obtener las unidades de cómputo (CU) consumidas
- Establecemos el límite de CU en las CU consumidas en el paso anterior, con cierto margen
- Obtenemos la comisión de prioridad recomendada por Helius mediante nuestra API de comisiones de prioridad
- Establecemos la comisión de prioridad (microlamports por CU) en el valor recomendado por Helius
- Agregamos una pequeña comisión de reserva por si la comisión recomendada cambia durante los próximos segundos
- Creamos y enviamos la transacción optimizada
- Devolvemos la firma de la transacción si se completa correctamente
Exigir el valor recomendado (o uno superior) para nuestras conexiones con stake garantiza que Helius envíe transacciones de alta calidad y que los validadores no nos apliquen límites de frecuencia.
SDK de TypeScript
El métodosendSmartTransaction está disponible en nuestro SDK de Helius para TypeScript en las versiones >= 1.3.2. Para actualizar a una versión más reciente del SDK, ejecuta npm update helius-sdk.
Este ejemplo transfiere SOL a una cuenta de tu elección. Usa sendSmartTransaction para enviar una transacción optimizada que no omite las verificaciones previas:
SDK de Rust
El métodosend_smart_transaction está disponible en nuestro SDK de Rust en las versiones >= 0.1.5. Para actualizar a una versión más reciente del SDK, ejecuta cargo update helius.
El siguiente ejemplo transfiere 0.01 SOL a una cuenta de tu elección.
Utiliza send_smart_transaction para enviar una transacción optimizada que omite las verificaciones previas y realiza hasta dos reintentos si es necesario:
Envío de transacciones sin el SDK
Recomendamos enviar transacciones inteligentes con uno de nuestros SDK, pero puedes obtener la misma funcionalidad sin usar uno. Tanto el SDK de TypeScript como el SDK de Rust son de código abierto, por lo que puedes consultar en cualquier momento el código subyacente de la funcionalidad de envío de transacciones inteligentes.Preparar y crear la transacción inicial
Primero, prepara y crea la transacción inicial. Esto incluye crear una nueva transacción con un conjunto de instrucciones, agregar el blockhash reciente y asignar un pagador de comisiones. Para las transacciones con versión, crea unTransactionMessage y compílalo con tablas de consulta si existe alguna.
Luego, crea una nueva transacción con versión y fírmala. Esto es necesario para el siguiente paso, en el que simularemos la transacción, ya que debe estar firmada.
Por ejemplo, si quisiéramos preparar una transacción con versión:
Optimizar el uso de unidades de cómputo (CU) de la transacción
Para optimizar el uso de unidades de cómputo (CU) de la transacción, podemos usar el método RPCsimulateTransaction para simularla.
La simulación de la transacción devolverá la cantidad de CU utilizadas, por lo que podemos usar este valor para establecer el límite de cómputo correspondiente.
Se recomienda usar primero una transacción de prueba con las instrucciones deseadas, además de una instrucción que establezca el límite de cómputo en 1.4 millones de CU.
Esto permite garantizar que la simulación de la transacción se complete correctamente.
Por ejemplo:
Serializar y codificar la transacción
Esto es relativamente sencillo. Primero, para serializar la transacción, tanto el tipo Transaction como VersionedTransaction tienen un método.serialize(). Luego, usa el paquete bs58 para codificar la transacción.
Tu código debería verse como bs58.encode(txt.serialize());
Establecer la comisión de prioridad correcta
Primero, usa la API de comisiones de prioridad para obtener la estimación de la comisión de prioridad. Queremos proporcionar nuestra transacción y obtener la comisión recomendada por Helius mediante el parámetro recommended:Crear y enviar la transacción optimizada
Este paso es casi una repetición del primero. Sin embargo, el arreglo de instrucciones iniciales se modificó para agregar dos instrucciones que establecen de forma óptima el límite y el precio de las unidades de cómputo. Ahora, envía la transacción. No importa si la envías con o sin verificaciones previas, ni si cambias otras opciones de envío: en todos los planes de pago, la transacción se enrutará a través de nuestras conexiones con stake.Consultar el estado de la transacción y retransmitirla
El método RPCsendTransaction tiene un parámetro maxRetries que puedes establecer para reemplazar la lógica de reintentos predeterminada del RPC, lo que da a los desarrolladores más control sobre el proceso de reintento.
Un patrón común consiste en obtener el blockhash actual mediante getLatestBlockhash, almacenar lastValidBlockHeight y reintentar la transacción hasta que venza el blockhash.
Es fundamental volver a firmar una transacción solo cuando el blockhash ya no sea válido. De lo contrario, la red podría aceptar ambas transacciones.
Después de enviar una transacción, es importante consultar su estado de confirmación para comprobar si la red la procesó y confirmó antes de reintentarla. Usa el método RPC getSignatureStatuses para consultar el estado de confirmación de una lista de transacciones.
El SDK @solana/web3.js también tiene un método getSignatureStatuses en su clase Connection para obtener el estado actual de varias firmas.
Cómo gestiona sendSmartTransaction las consultas y retransmisiones
El métodosendSmartTransaction tiene un tiempo de espera de 60 segundos. Como un blockhash es válido durante 150 slots y suponiendo slots perfectos de 400 ms, podemos asumir razonablemente que el blockhash de una transacción dejará de ser válido después de un minuto.
El método envía la transacción y consulta su firma durante este periodo de espera:
txtSig se establece en la firma de la transacción que se acaba de enviar.
Luego, el método usa pollTransactionConfirmation() para consultar el estado de confirmación de la transacción. Este método comprueba el estado de una transacción cada cinco segundos, hasta un máximo de tres veces.
Si la transacción no se confirma durante este periodo, se devuelve un error: