Le contexte du modèle de compte
Passez cette section si vous êtes familier avec les comptes Solana et leur structure.
- Données : Les octets réels stockant l’état du programme, les soldes des jetons ou d’autres informations
- Propriétaire : Le programme qui contrôle ce compte et peut modifier ses données
- Lamports : Le solde SOL du compte pour l’exonération de loyer
- Exécutable : Si ce compte contient du code de programme
Abonnement de compte de base
Commençons par un exemple simple qui s’abonne aux changements dans les comptes de jetons. Ce script vous notifiera chaque fois que les soldes des jetons changent :BKMHWYLAX4un3HUbR7a3u9jPmzCiLNa4mSj1RiX11eWF.
Ce compte a :
- 2,039,280 lamports (~0.002 SOL de solde - c’est la somme exonérée de loyer pour ce compte de jeton)
- Programme propriétaire
TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA(c’est le programme SPL Token) - Signature de transaction
5C9Hr5nG2j8eQz6inxPmfyjbYdmXddzUDyR1iQgEnjYQ3RNvuP4Zzc8t1enLNy7Rk8KNCtQPEQztENYWxkt9GaVDmontrant quelle transaction spécifique a provoqué le changement de ce compte - Slot 352366983 indiquant quand cette mise à jour s’est produite sur la blockchain
- Champ de données contenant 165 octets de données de compte encodées en base58
Comprendre le filtrage des comptes avec datasize
Le champ de données est crucial - il contient la structure réelle du compte de jetons. Utilisons cette compréhension pour le filtrage intelligent des comptes.Pourquoi utiliser le filtrage par datasize ?
Pour comprendre pourquoi nous avons besoin de filtrage, comprenons d’abord ce que sont réellement les comptes de jetons. Pour chaque jeton qu’un portefeuille détient, il y a un compte séparé sur la chaîne. Si votre portefeuille détient 3 jetons différents (USDC, BONK, et SOL), vous avez en fait 1 compte de portefeuille (votre compte principal SOL) plus 3 comptes de jetons (un pour chaque type de jeton). Chaque compte de jeton fait exactement 165 octets et stocke : quel jeton il détient (adresse de frappe), qui le possède (adresse de votre portefeuille), et combien de ce jeton il contient (montant). Le programme Token possède des millions de comptes sur Solana, mais tous ne sont pas ce que nous considérons comme des “comptes de jetons” détenant des soldes utilisateur. Voici ce qui se passe avec et sans filtrage : Sans filtrage - L’inondation :- Comptes de jetons (165 octets) - Soldes utilisateurs : millions de comptes
- Comptes de frappe (82 octets) - Définitions des jetons : centaines de milliers de comptes
- Comptes multisig (355 octets) - Contrôles de portefeuille partagés : dizaines de milliers de comptes
- Comptes du programme de jetons associés (tailles variées) - millions de comptes
- Sans filtrage : Millions de mises à jour de comptes (créations de frappe, changements multisig, etc.)
- Avec filtrage par datasize : Uniquement les changements de solde de jetons
D’où viennent les 165 octets ?
Ce n’est pas de la magie - cela provient de la structure de compte du programme SPL Token. En regardant le code source, nous pouvons voir que la structAccount définit exactement 165 octets :
- Comptes de frappe (82 octets)
- Comptes multisig (355 octets)
- Comptes de programme de compte de jeton associé
- Autres comptes liés aux jetons de tailles différentes
Décoder la structure du compte
Maintenant que nous comprenons pourquoi nous avons filtré 165 octets, décodons ce qui se trouve dans notre compte d’exemple :- Octets 0-31 : Adresse de frappe (quel jeton ce compte détient)
- Octets 32-63 : Adresse du propriétaire (qui possède ce compte de jeton)
- Octets 64-71 : Montant du jeton (combien de jetons sont dans le compte)
- Octets 72-164 : Métadonnées supplémentaires (délégué, état, autorité de fermeture, etc.)
Combiner les filtres : datasize + memcmp pour une précision laser
Maintenant que nous savons que l’adresse de frappe se situe aux octets 0-31, nous pouvons être encore plus spécifiques. Supposons que nous voulons seulement surveiller les comptes de jetons USDC. Nous pouvons combiner notre filtredatasize avec un filtre memcmp pour cibler l’adresse de frappe exacte :
- Filtre de propriétaire : “Donne-moi les comptes gérés par le programme Token” (millions de comptes)
- Filtre de datasize : “Mais seulement les comptes de jetons standard de 165 octets” (centaines de milliers)
- Filtre memcmp : “Et seulement ceux détenant de l’USDC” (milliers)
Lire les mises à jour de comptes USDC : Qui, Combien, Où ?
Voyons maintenant ce que ces mises à jour filtrées contiennent réellement. Créons un moniteur spécifique à l’USDC qui répond aux questions clés lorsqu’un compte de jeton change :- Qui possède ce compte de jeton ?
- Combien d’USDC contient-il maintenant ?
- Où (quel compte spécifique) a changé ?
- Quand ce changement s’est-il produit ?
- Quelle transaction a causé le changement ?
bs58.encode() pour convertir les objets Buffer binaires en chaînes lisibles.
Référence complète de filtrage
Au-delà des filtres de baseowner, datasize, et memcmp que nous avons utilisés, les abonnements de compte prennent en charge des options de filtrage supplémentaires pour affiner encore vos résultats :
Filtrage de comptes spécifiques
Surveillez des comptes exacts par leurs clés publiques :Stratégies de filtrage combinées
La puissance vient de la combinaison de plusieurs types de filtres. Voici le modèle mental :- Lancer un large filet avec
owner- “Donne-moi tous les comptes gérés par ce programme” - Filtrer par structure avec
datasize- “Mais seulement les comptes de ce type spécifique” - Cibler des données spécifiques avec
memcmp- “Et seulement ceux contenant ces informations spécifiques” - Surveiller des comptes connus avec
account- “Ou regardez simplement ces comptes exacts qui m’intéressent”
Comprendre le tableau d’ensemble
Considérez les abonnements de compte comme la surveillance d’un flux en direct de changements de base de données. L’état de Solana est essentiellement un vaste magasin de valeurs clés où chaque compte est une entrée. Lorsque les programmes s’exécutent, ils modifient ces comptes. Votre abonnement vous permet de surveiller en temps réel les entrées spécifiques qui changent. Le système de filtrage fonctionne comme les index de base de données - vous ne regardez pas juste “tous les changements” mais plutôt “les changements des comptes qui correspondent à ces critères”. Cela rend possible la création d’applications réactives qui réagissent immédiatement aux événements pertinents sur la chaîne sans submerger votre système avec des données non pertinentes.Appliquer ce modèle à d’autres programmes
L’approche que nous avons apprise fonctionne pour n’importe quel programme Solana. Voici le modèle général :- Recherchez la structure du compte - Consultez le code source ou la documentation du programme
- Commencez par le filtrage de propriétaire - Ciblez le programme qui gère les comptes
- Appliquez des filtres structurels - Utilisez la taille du compte, les motifs de données ou d’autres caractéristiques pour réduire à des types de comptes spécifiques
- Ajoutez des filtres ciblés - Concentrez-vous sur des comptes spécifiques, des états ou des valeurs de données qui comptent pour votre application