17 minutes de lecture
Aperçu
La surveillance des transactions de certains programmes Solana peut fournir des informations précieuses à des fins de développement, d’analyse ou d’exploitation. L’accès aux données des programmes pour une surveillance en temps réel peut s’avérer complexe, et l’interprétation de ces données codées peut s’avérer encore plus difficile. Dans ce guide, nous allons créer un outil de surveillance des transactions pour Pump.fun en utilisant Solana gRPC (Geyser gRPC compatible avec Yellowstone) et Carbon, un framework d’indexation léger, pour analyser les données.
Ce que vous ferez
À la fin de ce guide, vous disposerez d'une application Rust qui :
- Utilise Solana gRPC et le framework d'indexation Carbon
- Se connecte à un point de terminaison gRPC Solana
- Filtres et flux Pump.fun pour suivre en temps réel les nouvelles émissions de jetons et les migrations de jetons vers des AMM
- Traite et consigne les informations clés relatives aux événements ciblés
Ce dont vous aurez besoin
- Rust et Cargo sont installés sur votre système
- Un compte Quicknode avec accès à Solana gRPC (inclus dans les formules « Scale » et « Business », ou disponible via le module complémentaire Solana gRPC dans les formules « Build » et « Accelerate »)
- Connaissances de base sur Solana et la programmation en Rust
- Maîtrise des interfaces en ligne de commande
| Dépendance | Version |
|---|---|
| rustc | 1.85.0 |
| fret | 1.85.0 |
| Tokyo | 1.43.0 |
| yellowstone-grpc-proto | 5.0.0 |
| journal | 0.4.25 |
| env_logger | 0.11.5 |
| à âme en carbone | 0.8.0 |
| carbon-yellowstone-grpc-datasource | 0.8.0 |
| carbon-pumpfun-decoder | 0.8.0 |
| trait asynchrone | 0.1.86 |
| dotenv | 0.15.0 |
Comprendre les outils
Qu'est-ce que Solana gRPC ?
Solana gRPC est une solution de streaming de données haute performance pour Solana, reposant sur le système de plugins Geyser. Elle offre :
- Diffusion en temps réel des mises à jour de compte, des transactions et des notifications relatives aux machines à sous
- Une latence réduite par rapport aux implémentations WebSocket traditionnelles
- Une sécurité de type rigoureuse grâce à gRPC
- Fonctionnalités de filtrage efficaces pour les abonnements
Qu'est-ce que Pump.fun ?
Pump.fun est une plateforme populaire de création de tokens sur Solana qui permet à tout un chacun de créer rapidement et facilement des tokens « meme ». Le suivi des transactions sur Pump.fun peut fournir des informations sur les lancements de nouveaux tokens, les tendances du marché et l'activité des utilisateurs.
Qu'est-ce que le carbone ?
Carbon est un framework d'indexation léger pour Solana qui simplifie le processus de collecte et de traitement des données sur la chaîne. Il offre une architecture de pipeline modulaire comprenant les composants clés suivants :
- Pipeline: l'orchestrateur central qui gère le flux de données
- Sources de données: éléments fournissant des mises à jour de données (transactions, comptes)
- Pipes: mise à jour des données spécifiques au processus via des décodeurs et des processeurs
- Décodeurs: convertissent les données brutes de la blockchain en types structurés
- Processeurs: implémenter une logique personnalisée pour les données décodées
Carbon gère les aspects complexes liés à la diffusion en continu, au décodage et au traitement des données de la blockchain, ce qui vous permet de vous concentrer sur le développement de la logique de votre application. À la date de rédaction de cet article, Carbon propose les décodeurs de programme suivants :
Décodeurs de programmes disponibles
Vérifiez le Documentation relative au carbone pour les dernières mises à jour et les décodeurs supplémentaires. Dans ce guide, nous utiliserons carbon-pumpfun-decoder pour décoder les instructions du programme Pump.fun — une fois ce guide terminé, vous devriez être en mesure d'utiliser n'importe quel autre décodeur de la même manière.
Configuration du projet
Commençons par mettre en place la structure de notre projet Rust.
1. Créer un nouveau projet
cargo new pump-fun-carbon
cd pump-fun-carbon
2. Configurer les dépendances
Remplacez le contenu de votre Cargo.toml fichier avec :
[package]
nom = « pump-fun-carbon »
version = « 0.1.0 »
édition = « 2024 »
[dépendances]
# Yellowstone & Carbon dépendances
carbon-cœur = « 0.8.0 »
carbone-pumpfun-décodeur = « 0.8.0 »
carbon-Yellowstone-grpc-source de données = « 0.8.0 »
yellowstone-grpc-proto = « 5.0.0 »
# Async et utilitaires
async-trait = « 0.1.86 »
tokio = { version = « 1.43.0 », fonctionnalités = [« complet »] }
dotenv = "0.15.0"
env_logger = "0.11.5"
log = « 0.4.25 »
3. Créer une configuration d'environnement
Créer un .env fichier situé à la racine de votre projet pour stocker les informations relatives à votre point de terminaison gRPC Solana :
GEYSER_URL=votre-point-de-terminaison-grpc-quicknode
X_TOKEN=votre-jeton-x-quicknode
Remplacez les valeurs par défaut par votre point de terminaison gRPC Quicknode Solana et votre jeton d'authentification réels. Vous trouverez des informations sur la configuration de votre point de terminaison dans notre documentation, ici.
Mise en œuvre
Passons maintenant à la création de notre moniteur de transactions Pump.fun. Lorsque vous avez initialisé le projet, vous devriez avoir obtenu un src répertoire contenant un main.rs fichier. C'est dans ce fichier que nous allons ajouter notre code. Si vous ne l'avez pas, n'hésitez pas à le créer.
1. Créer des constantes et des importations
Commençons par importer les bibliothèques nécessaires et par définir quelques constantes pour notre application :
use {
async_trait::async_trait,
carbon_core::{
deserialize::ArrangeAccounts,
error::CarbonResult,
instruction::{DecodedInstruction, InstructionMetadata, NestedInstructions},
metrics::MetricsCollection,
processor::Processor,
},
carbon_pumpfun_decoder::{
PROGRAM_ID as PUMP_FUN_PROGRAM_ID, PumpfunDecoder,
instructions::{PumpfunInstruction, create::Create, migrate::Migrate},
},
carbon_yellowstone_grpc_datasource::YellowstoneGrpcGeyserClient,
std::{
collections::{HashMap, HashSet},
env,
sync::Arc,
},
tokio::sync::RwLock,
yellowstone_grpc_proto::geyser::{
CommitmentLevel, SubscribeRequestFilterAccounts, SubscribeRequestFilterTransactions,
},
};
// Pump.fun authority addresses to monitor
const PUMP_FUN_MINT_AUTHORITY: &str = "TSLvdd1pWpHVjahSpsvCXUbgwsL3JAcvokwaKt1eokM";
const PUMP_FUN_MIGRATION_AUTHORITY: &str = "39azUYFWPz3VHgKCf3VChUwbpURdCHRxjWVowf5jUJjg";
Dans ce code, nous importons les modules nécessaires de Carbon et du décodeur Pump.fun. Nous définissons également des constantes pour les autorités de création et de migration de Pump.fun, que nous utiliserons pour filtrer les transactions ; cela nous permettra de réduire le volume de données à traiter et de nous concentrer sur les transactions pertinentes (nous y reviendrons un peu plus tard).
2. Implémenter la fonction principale
Passons maintenant à la mise en œuvre de la principal fonction qui sert de point d'entrée à notre application. Ajoutez le code suivant à votre main.rs fichier (nous analyserons le code par la suite) :
#[tokio::main]
pub async fn main() -> CarbonResult<()> {
// 1 - Initialize logging
unsafe {
std::env::set_var("RUST_LOG", "info");
}
env_logger::init();
log::info!("Starting Pumpfun Transaction Processor Using Carbon");
// 2 - Check environment variables
dotenv::dotenv().ok();
let geyser_url = match env::var("GEYSER_URL") {
Ok(url) if !url.is_empty() => url,
_ => {
log::error!("GEYSER_URL environment variable not set or empty");
return Err(carbon_core::error::Error::Custom(
"GEYSER_URL not set".into(),
));
}
};
log::info!("Using GEYSER_URL: {}", geyser_url);
let x_token = env::var("X_TOKEN").ok();
log::info!(
"X_TOKEN is {}",
if x_token.is_some() { "set" } else { "not set" }
);
// 3 - Initialize account filters
let account_filters: HashMap<String, SubscribeRequestFilterAccounts> = HashMap::new();
// 4 - Initialize transaction filter
let transaction_filter = SubscribeRequestFilterTransactions {
vote: Some(false),
failed: Some(false),
account_include: vec![
PUMP_FUN_MINT_AUTHORITY.to_string(),
PUMP_FUN_MIGRATION_AUTHORITY.to_string(),
],
account_exclude: vec![],
account_required: vec![PUMP_FUN_PROGRAM_ID.to_string()],
signature: None,
};
let mut transaction_filters: HashMap<String, SubscribeRequestFilterTransactions> =
HashMap::new();
transaction_filters.insert(
"raydium_launchpad_transaction_filter".to_string(),
transaction_filter,
);
// 5 - Initialize Yellowstone Geyser gRPC Client
let yellowstone_grpc = YellowstoneGrpcGeyserClient::new(
env::var("GEYSER_URL").unwrap_or_default(),
env::var("X_TOKEN").ok(),
Some(CommitmentLevel::Processed),
account_filters,
transaction_filters,
Arc::new(RwLock::new(HashSet::new())),
);
// 6 - Build and run the Carbon pipeline
carbon_core::pipeline::Pipeline::builder()
.datasource(yellowstone_grpc)
.instruction(PumpfunDecoder, PumpfunInstructionProcessor)
//.account(PumpfunDecoder, PumpfunAccountProcessor)
.shutdown_strategy(carbon_core::pipeline::ShutdownStrategy::Immediate)
.build()?
.run()
.await?;
Ok(())
}
Voyons en détail ce que fait ce code :
-
Initialisation de la journalisation - Nous définissons le niveau de journalisation sur « info » et initialisons le module de journalisation afin de voir s'afficher les messages d'information dans la sortie de notre console.
-
Vérifier les variables d'environnement - Nous chargeons les variables à partir du
.envenregistrer et vérifier que les éléments requisGEYSER_URLest défini. Nous vérifions également si unX_TOKENest disponible pour l'authentification. -
Initialisation des filtres de compte — Nous créons un HashMap vide pour les filtres de compte. Dans cette implémentation, nous n'effectuons pas de filtrage par compte spécifique, mais la structure est prévue pour une extension future (par exemple, si vous souhaitiez surveiller les modifications apportées à un compte LP spécifique plutôt que les événements de transaction).
-
Initialisation du filtre de transactions — Nous créons un filtre pour cibler spécifiquement les transactions Pump.fun :
- Exclure les transactions de vote et les transactions ayant échoué
- Incluez les transactions impliquant soit l'autorité de création (mint authority), soit l'autorité de migration (migration authority). Sans ce filtre, nous recevrions toutes les transactions relatives au programme Pump.fun, y compris les achats et les ventes, ce qui générerait beaucoup de « bruit » sans rapport avec notre objectif de surveillance et, au final, entraînerait une consommation accrue de crédits. Comme nous savons que l'autorité de création sert uniquement à créer de nouveaux jetons et que l'autorité de migration sert uniquement à migrer des jetons, nous nous assurons désormais que notre outil de surveillance ne reçoive que les transactions contenant les instructions qui nous intéressent.
- Exiger que l'identifiant du programme « Pump.fun » soit présent
- Aucun compte spécifique à exclure ni aucune signature à faire correspondre (même si vous pourriez envisager d'utiliser ce champ pour filtrer les créateurs malveillants ou d'autres comptes indésirables)
-
Initialisation du client gRPC Solana - Nous créons le client qui se connectera au point de terminaison gRPC de Solana avec les filtres que nous avons configurés. Nous utilisons
Traiténiveau d'engagement afin de garantir que nous recevions les données les plus récentes. Nous avons mis en commentaire un processeur de compte, car nous ne l'utilisons pas dans cet exemple, mais vous pouvez le réactiver si vous souhaitez également surveiller les modifications apportées aux comptes. -
Création et exécution du pipeline Carbon - Enfin, nous créons le pipeline Carbon qui :
- Utilise le client gRPC Solana comme source de données
- Permet de connecter le décodeur Pump.fun à notre processeur
- Définit une stratégie d'arrêt immédiat
- Crée et exécute le pipeline
Super ! Il ne nous reste plus qu'à définir et à implémenter le Processeur d'instructions Pumpfun qui gérera les instructions Pump.fun décodées.
3. Mettre en œuvre le processeur d'instructions
Sous votre principal fonction, implémentons la Processeur d'instructions Pumpfun qui traitera les instructions Pump.fun décodées :
pub struct PumpfunInstructionProcessor;
#[async_trait]
impl Processor for PumpfunInstructionProcessor {
type InputType = (
InstructionMetadata,
DecodedInstruction<PumpfunInstruction>,
NestedInstructions,
);
async fn process(
&mut self,
(metadata, instruction, _nested_instructions): Self::InputType,
_metrics: Arc<MetricsCollection>,
) -> CarbonResult<()> {
let signature = metadata.transaction_metadata.signature;
let accounts = instruction.accounts;
match instruction.data {
PumpfunInstruction::Sell(_params) => {
log::info!("❌ - EXPECT TO NEVER SEE SELL INSTRUCTION");
log::info!("TxId: {}", signature);
}
PumpfunInstruction::Create(params) => {
log::info!("💊 NEW PUMPFUN TOKEN CREATED");
log::info!(
"━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
);
log::info!("TxId: {}", signature);
log::info!("Token Details:");
log::info!(" • Name: {}", params.name);
log::info!(" • Symbol: {}", params.symbol);
match Create::arrange_accounts(&accounts) {
Some(arranged_accounts) => {
log::info!(" • Mint: {}", arranged_accounts.mint);
log::info!(
"━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
);
}
None => {
log::warn!(
"Failed to arrange accounts for Create instruction. Create instruction: signature: {signature}"
);
}
}
}
PumpfunInstruction::Migrate(_params) => {
log::info!("🔄 MIGRATE INSTRUCTION DETECTED");
log::info!(
"━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
);
log::info!("TxId: {}", signature);
match Migrate::arrange_accounts(&accounts) {
Some(arranged_accounts) => {
log::info!(" • Mint: {}", arranged_accounts.mint);
log::info!(
"━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
);
}
None => {
log::warn!(
"Failed to arrange accounts for Migrate instruction. Migrate instruction: signature: {signature}"
);
}
}
}
_ => {
// Ignore non-target instructions
}
}
Ok(())
}
}
Analysons ce processeur d'instructions :
- Implémentation des structures et des traits - Nous définissons un
Processeur d'instructions Pumpfunstructure qui implémente CarbonProcesseurtrait, qui est chargé de gérer les instructions décodées. D'après la documentation de Carbon, « LeProcesseurCe trait fournit une seule méthode asynchrone,processus, qui est chargé de traiter les données d'un type spécifique (Type d'entrée). Cette fonctionnalité est conçue pour être mise en œuvre par les types qui doivent traiter des données au sein du pipeline, ce qui permet une gestion personnalisée des différents types de données. »:
#[async_trait]
pub trait Processor {
type InputType;
async fn process(
&mut self,
data: Self::InputType,
metrics: Arc<MetricsCollection>,
) -> CarbonResult<()>;
}
-
Définition du type d'entrée - Le
Type d'entréeest un tuple contenant trois éléments :Métadonnées d'instruction: Contient des informations sur le contexte de la transactionDecodedInstruction<PumpfunInstruction>: L'instruction Pump.fun décodéeInstructions imbriquées: Toute instruction interne imbriquée, comme les appels CPI
-
Méthode de traitement - C'est ici que se déroule la logique de traitement proprement dite :
- Nous extrayons la signature de la transaction et la liste des comptes
- Nous comparons les différents types d'instructions afin de traiter chacun d'entre eux de manière appropriée
-
Gestionnaires d'instructions:
-
Instructions de vente - Cet élément est inclus uniquement à titre de démonstration, afin d'illustrer comment notre
account_includeLe filtre fonctionne. Nos filtres de transaction spécifient que les transactions cibles doivent inclure les comptes de l'autorité de frappe ou de migration, qui ne figurent dans aucune instruction de vente. Par conséquent, ce chemin d'exécution ne devrait jamais être exécuté. Le message de journal « EXPECT TO NEVER SEE SELL INSTRUCTION » (ON NE DOIT JAMAIS VOIR D'INSTRUCTION DE VENTE) le confirme. Si vous le souhaitez, vous pouvez supprimer entièrement ce code, ou modifier les filtres pour inclure les instructions de vente si vous souhaitez également les surveiller. -
Instruction « Create » - Lorsqu'un nouveau jeton Pump.fun est créé :
- Nous enregistrons la transaction et la mettons en forme pour en faciliter la lecture
- Nous extrayons les détails du jeton à partir des paramètres, tels que
nometsymbole - Nous utilisons
gérer_les_comptespour obtenir un accès structuré aux comptes concernés, afin de pouvoir consigner lesmentheadresse
-
Instructions relatives à la migration - Lorsqu'une migration de jeton a lieu, nous enregistrons des informations similaires à celles de la commande « Create »
-
Autres instructions - Toutes les autres instructions Pump.fun sont ignorées
-
-
Configuration du compte - Tant pour les instructions de création que pour celles de migration, nous utilisons le
gérer_les_comptesméthode d'aide. Cette fonction Carbon :- Reçoit la liste brute des comptes
- Les renvoie sous la forme d'un objet structuré qui facilite l'accès à des comptes spécifiques par leur nom
- Renvoie
Aucunsi les comptes ne correspondent pas au schéma attendu
La conception de ce processeur met en évidence l'un des principaux atouts de Carbon : sa capacité à traiter des données d'instructions décodées selon un typage strict, plutôt que de manipuler des octets bruts. Le PumpfunDecoder (qui est fourni par le carbon-pumpfun-decoder crate) se charge de la tâche complexe consistant à désérialiser les données d'instructions brutes, ce qui permet à notre processeur de se concentrer sur la logique métier. Vous pouvez utiliser les fonctionnalités IntelliSense de votre IDE pour explorer le Mode d'emploi de la pompe enum et découvrez toutes les instructions possibles pouvant être décodées.
Exécution de l'application
Pour lancer votre moniteur de transactions Pump.fun :
- Assurez-vous que votre
.envle fichier contient des identifiants gRPC Solana valides - Compiler l'application :
cargo build
- Lancez l'application :
cargo run
Vous devriez obtenir un résultat similaire à celui-ci :
[INFO] Démarrage du processeur de transactions Pumpfun à l'aide de Carbon
[INFO] Utilisation de GEYSER_URL : votre-geyser-url
[INFO] X_TOKEN est défini
Lorsqu'un nouveau jeton Pump.fun est créé, vous verrez s'afficher un résultat similaire à celui-ci :
[INFO] 💊 CRÉATION D'UN NOUVEAU TOKEN PUMPFUN
[INFO] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[INFO] TxId : 5QrTR9...tronqué...
[INFO] Détails du jeton :
[INFO] • Nom : Awesome Token
[INFO] • Symbole : AWSM
[INFO] • Émission : AWsM4rKh...tronqué...
[INFO] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Bravo !
Agrandir votre écran
Voici quelques pistes pour étendre les fonctionnalités de ce moniteur de base :
- Intégration à une base de données: enregistrer les données de transaction dans une base de données à des fins d'analyse
- Développer les filtres: ajoutez d'autres filtres pour cibler d'autres types d'instructions
- Surveillance de plusieurs programmes: Définir et
insérerdes filtres de transaction supplémentaires permettant de surveiller plusieurs programmes et d'utiliser plusieurs décodeurs - Automatisation du trading: tirez parti de l'API Metis Swap, avec le soutien de Pump.fun, pour créer et mettre en œuvre des stratégies de trading automatisées
Conclusion
Dans ce guide, nous avons développé un outil de surveillance des transactions Pump.fun à l'aide de Carbon et de Solana gRPC. Cette approche permet une surveillance en temps réel et hautement performante avec un minimum de code. Le framework Carbon masque une grande partie de la complexité liée à l'analyse des données de transactions et de comptes Solana, ce qui vous permet de vous concentrer sur la logique de votre application.
Si vous avez des questions ou besoin d'aide pour vos projets de développement Solana, rejoignez-nous sur le Discord de Quicknode ou suivez-nous sur Twitter.
Nous ❤️ les commentaires !
Faites-nous savoir si vous avez des commentaires ou des suggestions de nouveaux sujets. Nous serions ravis de vous entendre.