rpcpool.solana_rpc

Rôle RPC de Solana

Un rôle Ansible pour déployer un nœud RPC Solana. Cela configure le logiciel de validation en mode RPC fonctionnant sous l'utilisateur solana. Le service RPC est installé comme un service utilisateur qui fonctionne sous ce même utilisateur.

Mises à jour

16/02 - À partir de Solana 1.8.15 (mainnet) et 1.9.6 (testnet), vous devrez spécifier solana_full_rpc_api: true pour que ce rôle crée réellement un nœud API RPC complètement exposé.

Exigences matérielles

Un serveur RPC nécessite au moins les mêmes spécifications qu'un validateur Solana, mais a généralement des exigences plus élevées. En particulier, nous recommandons d'utiliser 256 Go de RAM pour stocker les index. Pour plus d'informations sur les exigences matérielles, veuillez consulter https://docs.solana.com/running-validator/validator-reqs. Nous recommandons fortement d'utiliser un fournisseur baremetal (pas Hetzner) plutôt qu'un fournisseur cloud, sauf si vous savez ce que vous faites (et si c'est le cas, pourquoi lisez-vous cette page ?).

Avant de déployer, vous devez préparer l'hôte afin que le répertoire que vous utilisez pour votre base de données de comptes et votre emplacement de grand livre soient correctement configurés. Cela peut inclure la configuration d'un dossier tmpfs pour les comptes et d'un système de fichiers séparé (idéalement sur un disque NVME) pour le grand livre. Une façon courante de configurer cela pourrait être :

/solana/tmpfs - une partition tmpfs de 100 Go pour contenir l'état des comptes
/solana/ledger - un disque NVME de 2 To pour contenir le grand livre

Pourquoi bare metal et pas cloud ?

Les serveurs cloud (AWS, GCP, etc.) ne conviennent généralement pas à Solana pour plusieurs raisons :

Les frais de sortie sont très élevés et Solana utilisera beaucoup de sortie.
La performance d'un seul cœur est généralement trop faible et ne peut pas augmenter comme le fait le bare metal.
De nombreux fournisseurs cloud ne souhaitent pas avoir ce type de charge de travail sur leurs instances low-cost, vous poussant à utiliser des instances baremetal très coûteuses.

Pourquoi pas Hetzner ?

Hetzner a décidé qu'il ne voulait pas de services RPC Solana sur son réseau. Il bloque activement les connexions aux points d'entrée de Solana et limite tout trafic Solana. Non seulement votre nœud Solana aura du mal à suivre le réseau (sur mainnet, il ne pourra probablement jamais rattraper), mais Hetzner est également très susceptible de fermer votre compte.

Exigences logicielles

Ansible >= 2.7 (testé principalement sur Ansible 2.8)
Ubuntu 18.04+ sur la machine de déploiement cible

Ce rôle suppose une certaine familiarité avec le processus de déploiement du logiciel de validation Solana.

Variables de rôle

Le déploiement garantit que la somme de contrôle pour la version de solana-installer que vous téléchargez correspond à celle donnée dans vars/main.yml. Si vous souhaitez installer une version de Solana non répertoriée, il est bon de d'abord télécharger et vérifier la somme de contrôle sha256 du script solana-installer (https://raw.githubusercontent.com/solana-labs/solana/master/install/solana-install-init.sh).

Il existe un grand nombre de paramètres configurables pour Solana. Beaucoup d'entre eux ont des valeurs par défaut fonctionnelles, et vous pouvez utiliser ce rôle pour déployer un nœud RPC Solana sans changer aucune des valeurs par défaut, et vous devriez avoir une expérience décente. Si vous exécutez ce rôle sans spécifier de paramètres, il configurera un nœud RPC mainnet standard.

Variables de base

Voici les variables de base qui configurent la mise en place des validateurs. Elles ont des valeurs par défaut mais vous voudrez probablement les personnaliser en fonction de votre configuration.

Nom	Valeur par défaut	Description
`solana_version`	stable	La version de Solana à installer.
`solana_full_rpc_api`	`true`	Si oui ou non activer l'API RPC complète. C'est généralement ce que vous voulez.
`solana_root`	/solana	Répertoire principal pour le grand livre et les comptes Solana
`solana_ledger_location`	/solana/ledger	Stockage pour le grand livre Solana (devrait être sur NVME)
`solana_accounts_location`	/solana/ledger/accounts	Stockage pour les informations de comptes Solana. Si vous utilisez tmpfs pour les comptes, cela devrait être un sous-répertoire de votre point de montage tmpfs (par exemple, `/solana/tmpfs/accounts` si tmpfs est monté sur `/solana/tmpfs`)
`solana_snapshots_location`		Stockage pour les instantanés Solana. Peut être utile de le garder sur un NVME séparé de votre grand livre.
`solana_keypairs`	`[]`	Liste des paires de clés à copier sur le nœud valideur. Chaque entrée de la liste doit avoir une entrée `key` et `name`. Cela créera `/home/solana/<name>.json` contenant la valeur de `key`.
`solana_generate_keypair`	true	Si oui ou non générer une paire de clés. Si vous n'avez pas spécifié `solana_keypairs` et que vous mettez cela à vrai, une nouvelle clé sera générée et placée dans /home/solana/identity.json.
`solana_public_key`	`/home/solana/identity.json`	Emplacement de l'identité du nœud valideur.
`solana_network`	mainnet	Le réseau Solana dont ce nœud est censé faire partie
`solana_environment`	voir defaults/main.yml	Variables d'environnement à spécifier pour le nœud valideur, surtout `RUST_LOG`
`solana_enabled_services`	`[ solana-rpc ]`	Liste des services à démarrer automatiquement au démarrage
`solana_disabled_services`	`[ ]`	Liste des services à définir comme désactivés

Ports

Les ports suivants doivent être configurés pour votre serveur RPC.

Nom	Valeur par défaut	Description
`solana_gossip_port`	8001	Port pour le trafic de gossip (doit être ouvert publiquement dans le pare-feu pour TCP et UDP)
`solana_rpc_port`	8899 (+8900)	Ports pour RPC entrants (et websocket). Cela est généralement ouvert uniquement sur localhost. Placez un proxy comme `haproxy` devant ces ports et ne les exposez pas publiquement.
`solana_rpc_bind_address`	127.0.0.1	Adresse à lier RPC. Cela devrait généralement être localhost. Placez un proxy comme `haproxy` devant cela pour accepter le trafic public.
`solana_dynamic_port_range`	8002-8020	Port pour le trafic Solana entrant. Peut nécessiter d'être ouvert publiquement dans le pare-feu pour UDP.

À partir de cette liste, vous pouvez voir que vous devez ouvrir au moins 8001-8020 dans votre pare-feu pour le trafic entrant dans le cas par défaut.

Pour les nœuds RPC purs, il peut être possible de fermer les ports TPU et TPU forward. Ces ports sont attribués dynamiquement et vous pouvez les voir en consultant votre nœud dans solana gossip. Si vous souhaitez les configurer dans le pare-feu, vous pouvez utiliser cet outil : https://github.com/rpcpool/tpu-traffic-classifier. En utilisant cet outil, vous pouvez bloquer le trafic TPU et TPU forward entrant sur un nœud local en exécutant :

./tpu-traffic-classifier -config-file config.yml -our-localhost -tpu-policy DROP -fwd-policy DROP -update=false

Mettez ceci dans un service SystemD et vous pourrez le démarrer au démarrage du nœud et le garder en cours d'exécution en continu.

Variables spécifiques au réseau

Les valeurs par défaut pour ces variables sont spécifiées dans vars/{{ solana_network }}-default.yml (par exemple, vars/mainnet-default.yml). Vous pouvez également spécifier les vôtres en fournissant le fichier {{ solana_network }}.yml. Vous devrez spécifier toutes ces variables à moins que vous n'utilisiez les valeurs par défaut.

Nom	Valeur par défaut	Description
`solana_network`	mainnet	Le réseau Solana auquel ce nœud doit se joindre
`solana_metrics_config`	voir vars/mainnet-default.yml	Le point de terminaison des métriques
`solana_genesis_hash`	voir vars/mainnet-default.yml	Le hachage de la genèse pour ce réseau
`solana_entrypoints`	voir vars/mainnet-default.yml	Hôtes de point d'entrée
`solana_known_validators`	voir vars/mainnet-default.yml	Validateurs connus à partir desquels récupérer des instantanés et le binaire de genèse au démarrage
`solana_expected_bank_hash`	voir vars/mainnet-default.yml	Hachage de banque attendu
`solana_expected_shred_version`	voir vars/mainnet-default.yml	Version de shred attendue
`solana_index_exclude_keys`	voir vars/mainnet-default.yml	Clés à exclure des index pour des raisons de performance

Variables spécifiques au RPC

Nom	Valeur par défaut	Description
`solana_rpc_faucet_address`		Spécifiez une fontaine RPC
`solana_rpc_history`	true	Si oui ou non fournir des valeurs historiques via RPC
`solana_account_index`	program-id spl-token-owner spl-token-mint	Quels index activer. Ceux-ci améliorent considérablement la performance, mais ralentissent le temps de démarrage et peuvent augmenter les exigences en mémoire.

Variables de performance

Ce sont des variables que vous pouvez ajuster pour améliorer la performance

Nom	Valeur par défaut	Description
`solana_snapshot_compression`		Si oui ou non compresser les instantanés. Spécifiez aucune pour améliorer la performance.
`solana_snapshot_interval_slots`		À quelle fréquence prendre des instantanés. Augmentez pour améliorer la performance. La valeur suggérée est 500.
`solana_pubsub_max_connections`	1000	Nombre maximum de connexions pubsub autorisées.
`solana_bpf_jit`		Si oui ou non activer BPF JIT. Par défaut activé pour devnet.
`solana_banking_threads`	16	Nombre de threads bancaires.
`solana_rpc_threads`		Nombre de threads RPC (nombre maximum de threads/cœurs sur le système)
`solana_limit_ledger_size`	`solana default, 250 mio`	Taille du grand livre local à stocker. Pour un plein cycle, définissez une valeur entre 350 mio et 500 mio. Pour de meilleures performances, définissez 50 (valeur minimale).
`solana_accounts_db_caching`		Si oui ou non activer la mise en cache des bases de données de comptes
`solana_accounts_shrink_path`		Vous voudrez peut-être spécifier un autre emplacement pour le processus de réduction des comptes

Bigtable

Vous pouvez spécifier les identifiants de compte Google Bigtable pour interroger des blocs non présents dans le grand livre local.

Nom	Valeur par défaut	Description
`solana_bigtable_enabled`	false	Activer l'accès à Bigtable
`solana_bigtable_upload_enabled`	false	Activer le téléversement vers Bigtable (les identifiants que vous fournissez ci-dessous doivent avoir un accès en écriture)
`solana_bigtable_project_id`		Identifiant du projet Bigtable
`solana_bigtable_private_key_id`		Identifiant de la clé privée Bigtable
`solana_bigtable_private_key`		Clé privée Bigtable
`solana_bigtable_client_email`		Email du client Bigtable
`solana_bigtable_client_id`		Identifiant du client Bigtable
`solana_bigtable_client_x509_cert_url`		URL du certificat Bigtable

Pour plus d'informations sur BigTable, consultez https://github.com/solana-labs/solana-bigtable.

Gestion des forks

Parfois, devnet/testnet connaîtra des forks. Dans ces cas, utilisez les paramètres suivants comme indiqué dans Discord :

Nom	Valeur par défaut	Description
`solana_hard_fork`		Fork majeur
`solana_wait_for_supermajority`		Si le nœud doit attendre la supermajorité ou non

Réglages du processeur et des paramètres Sysctl

Il y a certaines configurations que vous devez faire pour que votre nœud RPC fonctionne correctement. Ce rôle peut vous aider à effectuer certains de ces changements standard de configuration. Cependant, l'optimisation complète dépend beaucoup de votre matériel, donc vous devez prendre le temps de vous familiariser avec la manière de configurer votre matériel correctement.

Cependant, l'élément le plus important de l’optimisation est le gouverneur de performance du processeur. Cela contrôle le comportement d'augmentation et l'utilisation de l'énergie. Sur de nombreux hôtes dans des centres de données, ils sont configurés pour équilibrer performance et consommation d'énergie. Dans le cas de Solana, nous avons vraiment besoin qu'ils fonctionnent à leur vitesse maximale. Pour régler le gouverneur du CPU des serveurs, il y a trois options :

Vous avez accès au BIOS et vous réglez le paramètre de CPU du BIOS sur max performance. Cela semble bien fonctionner pour les systèmes HPE. Dans ce cas, spécifiez la variable cpu_governor: bios. Cela est parfois nécessaire pour les systèmes AMD EPYC également.
Vous avez accès au BIOS et vous réglez le paramètre de CPU du BIOS sur os control. Cela devrait être le défaut typique. Dans ce cas, vous pouvez laisser la variable cpu_governor par défaut ou la spécifier explicitement sur cpu_governor: performance.
Vous n'avez pas accès au BIOS ou aux réglages du gouverneur du CPU. Si possible, essayez de définir cpu_governor: performance. Sinon, espérons que votre fournisseur l'a configuré pour de bonnes performances !

La deuxième configuration que vous devez faire est d'éditer divers paramètres du noyau pour s'adapter au cas d'utilisation RPC de Solana.

Une option est de déployer solana-sys-tuner avec cette configuration pour régler automatiquement certaines variables pour vous.

Une deuxième option, surtout si vous êtes novice en matière de réglage de performance, est tuned et tune-adm de RedHat, où le profil throughput-performance est adapté.

Enfin, si vous déployez via ce rôle, vous pouvez également spécifier une liste de valeurs sysctl pour que ce livre de jeu les configure automatiquement sur votre hôte. Cela permet un contrôle complet et les configure pour qu'elles soient configurées de manière permanente. Voici une liste de valeurs sysctl que nous avons utilisées sur rpcpool :

sysctl_optimisations:
  vm.max_map_count: 700000
  kernel.nmi_watchdog: 0
  kernel.sched_min_granularity_ns: '10000000'
  kernel.sched_wakeup_granularity_ns:  '15000000' 
  vm.swappiness: '30'
  kernel.hung_task_timeout_secs: 600
  vm.stat_interval: 10
  vm.dirty_ratio: 40
  vm.dirty_background_ratio: 10
  vm.dirty_expire_centisecs: 36000
  vm.dirty_writeback_centisecs: 3000
  vm.dirtytime_expire_seconds: 43200
  kernel.timer_migration: 0
  kernel.pid_max: 65536
  net.ipv4.tcp_fastopen: 3
  net.core.rmem_max: 134217728
  net.core.rmem_default: 134217728
  net.core.wmem_max: 134217728
  net.core.wmem_default: 134217728

Exemples de livres de jeu

Nœud mainnet :

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: mainnet }

Nœud testnet :

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: testnet }

Nœud devnet :

    - hosts: rpc_nodes
      become: true
      become_method: sudo
      roles:
         - { role: rpcpool.solana-rpc, solana_network: devnet }

Démarrer le nœud RPC

Après le déploiement, vous pouvez vous connecter à la machine et exécuter su -l solana pour devenir l'utilisateur solana.

Pour voir la ligne de commande du valideur Solana générée pour vous pendant le déploiement, vous pouvez consulter /home/solana/bin/solana-rpc.sh. N'oubliez pas que toute modification apportée à ce fichier sera remplacée la prochaine fois que vous exécuterez cet Ansible.

Pour le premier démarrage, vous devez commenter --no-genesis-fetch et --no-snapshot-fetch dans le fichier /home/solana/bin/solana-rpc.sh. Cela permettra à Solana de télécharger les fichiers de base dont il a besoin pour le premier démarrage. N'oubliez pas d'activer à nouveau ces lignes après avoir démarré le valideur pour la première fois.

Ensuite, démarrez le processus RPC de Solana en exécutant systemctl --user start solana-rpc. Vous pouvez voir l'état du processus en exécutant systemctl --user status solana-rpc. Le premier démarrage prendra un certain temps. Vous pouvez surveiller le démarrage en exécutant solana catchup --our-localhost.

Enfin, pour voir les journaux de votre nœud RPC Solana, exécutez journalctl --user -u solana-rpc -f.

Si c'est votre première fois en train d'exécuter un nœud Solana, vous pouvez trouver plus de détails sur la manière de faire fonctionner le nœud sur https://docs.solana.com/running-validator/validator-start et https://github.com/agjell/sol-tutorials/.

Vérifier le nœud RPC

La vérification de base après avoir confirmé que le nœud a démarré est de suivre le rattrapage :

solana catchup --our-localhost

Après cela, vous pouvez continuer à vérifier qu'il sert correctement les appels RPC.

Tester l'accès RPC

Vous pouvez également essayer quelques commandes de validation simples (merci buffalu : https://gist.github.com/buffalu/db6458d4f6a0b70ac303027b61a636af) :

curl http://localhost:8899 -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc":"2.0","id":1, "method":"getSlot", "params": [
      {
        "commitment": "processed"
      }
    ]}
'

curl http://localhost:8899  -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc":"2.0","id":1, "method":"getSlot"}
'

Tester l'accès websocket

Le moyen le plus simple de tester les websockets est d'installer l'utilitaire wscat. Pour ce faire, vous devrez installer NodeJS et NPM, puis exécuter npm install wscat.

Vous pouvez ensuite vous connecter à votre websocket de la manière suivante :

wscat -c localhost:8900

À partir de là, vous obtiendrez un invite de commande où vous pourrez entrer manuellement vos demandes d'abonnement websocket :

> {"jsonrpc":"2.0", "id":1, "method":"slotSubscribe"}

Vous devriez maintenant commencer à recevoir des mises à jour régulières sur les slots au fur et à mesure qu'ils sont confirmés par votre nœud RPC.

Nœud RPC à la traîne / ne parvenant pas à rattraper

Le problème de performance le plus typique auquel un nœud RPC peut être confronté est qu'il continue à être en retard par rapport au réseau et n'est pas capable de rattraper.

S'il ne peut pas rattraper lors du premier démarrage, cela serait généralement dû à une mauvaise configuration. Le problème le plus courant est vos fréquences boost du CPU (pour plus de détails sur la configuration du CPU, voir ci-dessus) :

Vérifiez que votre CPU est suffisamment récent (tout moins d'un EPYC de 2ème génération chez AMD ou moins d'un Cascade Lake chez Intel aura des difficultés).
Vérifiez que votre gouverneur de CPU n'est pas réglé sur le mode d'économie d'énergie dans le BIOS et dans vos paramètres de noyau.
Observez les fréquences du CPU lors de l'exécution de solana avec watch -n 1 grep MHz /proc/cpuinfo, vous aurez typiquement besoin qu'elles soient > 3ghz sur tous les cœurs (règle générale). Vous ne voulez pas voir un cœur descendre à 1,4-1,8.

Si ça a déjà pu rattraper, mais que ce n'est plus le cas (ou si fixer le CPU ne l'a pas résolu) :

Vérifiez la mémoire/cpu/réseau - avez-vous de bonnes fréquences CPU, est-ce que vous plongez dans l'échange (pas assez de mémoire) ou votre fournisseur régule-t-il les paquets UDP ?
- CPU: Réparez le réglage du gouverneur/performance boost, obtenez un CPU de génération plus récente ou un CPU avec un meilleur turbo tous cœurs (vérifiez wikichip pour des détails). N'oubliez pas que MHz n'est pas le même parmi les générations différentes. Un Broadwell 3.0 GHz n'est pas identique à un Cascade Lake 3.0 GHz ou EPYC de 3ème génération à 3.0 GHz.
- Réseau: Vérifiez la régulation des paquets UDP et la connectivité. Vous avez besoin d'au moins 500 mbps sans aucune régulation sur l'UDP. Certains fournisseurs aiment bloquer l'UDP ou le réguler pour la protection contre les DDoS. Cela s'applique aux paquets entrants et sortants. Si vous êtes régulé sur les entrants, votre nœud ne recevra pas les shards du réseau à temps. Vérifiez vos pare-feu pour vous assurer que vous ne l'êtes pas.
- Mémoire: Téléchargez plus de RAM. Solana n'aime pas fonctionner avec l'échange, donc si vous plongez régulièrement dans l'échange, vous devez corriger cela. Une solution temporaire peut être de désactiver les index spl-token-owner / spl-token-mint. Ils ont considérablement augmenté en taille.
- Disque: Vérifiez que votre NVME pour maintenir le grand livre et/ou les comptes ne soit pas mort ou en train de mourir. Un simple dmesg ou une requête SMART devrait pouvoir vous le dire.
Il y a un bug qui, après un appel lourd de getBlocks via RPC, le nœud reste définitivement en retard, essayez un redémarrage du nœud et si ça aide, cela pourrait être votre problème.
Avez-vous essayé de le débrancher et de le rebrancher ? Parfois, ça peut aider à nettoyer votre grand livre et redémarrer.
Vérifiez vos modèles de trafic. Certains modèles de trafic RPC peuvent facilement retarder votre nœud. Peut-être que vous devez ajouter un autre nœud et diviser votre trafic RPC ou vous devez réguler vos appels vers des requêtes problématiques comme getProgramAccounts.

Accès aux données historiques

Par défaut, lorsque vous démarrez le nœud RPC, il commence à construire son grand livre local à partir des blocs qu'il reçoit via le réseau Solana. Ce grand livre local commence à partir du point de l'instantané des comptes que vous avez téléchargé lorsque votre nœud a démarré. Si vous n'ajoutez pas --no-snapshot-fetch à votre ligne de commande solana-validator, le valideur tirera souvent un instantané du réseau lorsqu'il démarre. Cela laissera des trous ou des lacunes dans votre grand livre entre le point où vous avez arrêté votre nœud RPC et le point auquel il a téléchargé l'instantané des comptes. Pour éviter cela, spécifiez toujours --no-snapshot-fetch après la première fois que vous démarrez le nœud. N'oubliez pas que chaque fois que vous tirez un instantané, vous créerez un trou dans le grand livre local.

La taille du grand livre local est déterminée par le paramètre --limit-ledger-size, qui est mesuré en shreds. Un shred est une unité de données fixe. La conversion entre shreds et blocs n'est pas fixe, car les blocs peuvent varier en taille. Par conséquent, il est très difficile de dire combien d'historique mesuré en temps ou en nombre de blocs votre nœud stockera. Vous devrez le régler selon vos besoins. Un bon point de départ peut être de 250 à 350 millions de shreds, ce qui devrait couvrir environ un cycle, ce qui devrait en retour signifier environ 3 jours.

La quantité exacte de données que le nœud RPC stockera dépend également des paramètres --enable-cpi-and-log-storage et --enable-rpc-transaction-history. Ceux-ci sont nécessaires pour que le nœud conserve et fournisse les données complètes des blocs et des transactions.

Votre nœud ne peut fournir que les données qu'il a stockées dans son grand livre local. Cela signifie que votre historique commencera toujours à partir du point où vous avez démarré le nœud (en fait : le slot de l'instantané à partir duquel vous avez démarré le nœud). Si le réseau est actuellement au slot N et que vous avez tiré un instantané au slot M, alors votre nœud commencera à reconstruire son histoire entre le slot M et le slot N. C'est ce qui se passe lors du catchup, le nœud traite (rejoue) tout ce qui s'est produit entre M et N jusqu'à ce qu'il rattrape le réseau et puisse traiter toutes les données entrantes actuelles.

Le nœud peut (en théorie) stocker autant d'historique que vous pouvez faire tenir sur un stockage à haute vitesse (par exemple si vous ne spécifiez pas --limit-ledger-size ou que vous lui donnez une énorme valeur). Cependant, cela ne remonte pas jusqu'à la genèse. Pour obtenir tout l'historique, vous pouvez utiliser le support intégré de Google BigTable. Vous pouvez configurer votre nœud pour téléverser des données vers une instance Google BigTable, où elles peuvent être disponibles de manière permanente pour des requêtes historiques. Vous pouvez également configurer votre nœud pour prendre en charge les requêtes vers une instance BigTable. Dans ce cas, pour toute requête que le nœud n'a pas dans son grand livre local, il fera une demande à Google BigTable et s'il la trouve, il pourra récupérer les données à partir de là.

Certains fournisseurs RPC et la fondation Solana ont des copies de BigTable qui remontent jusqu'à la genèse. Pour plus d'informations à ce sujet, consultez https://github.com/solana-labs/solana-bigtable.

Index et performance : ou, pourquoi mon RPC est-il si lent ?

Il y a trois index que le valideur Solana génère : program-id, spl-token-mint, spl-token-owner. Les deux derniers sont utilisés pour prendre en charge des requêtes soit via getTokensByOwner, getTokenLargestAccounts, soit via getTokensByDelegate. Ils sont également utilisés pour soutenir les requêtes de getProgramAccounts qui appliquent des filtres spécifiques.

Ces index ont commencé à devenir énormes. Si vous n'avez pas besoin que ces requêtes soient rapides pour votre nœud RPC, vous devriez les supprimer car vous réduirez considérablement l'utilisation de la mémoire de votre nœud ainsi que le temps de démarrage.

Si vous avez BESOIN de ces appels RPC, alors vous DEVEZ activer les index via le drapeau d'index des comptes, sinon ces appels fonctionneront de manière intolérablement lente. Cela nécessitera beaucoup de RAM - en général, nous ne recommandons pas de déployer cela avec moins de 512 Go de RAM disponibles.

Une alternative à ceux-ci pourrait être d'utiliser des plugins Geyser, comme le plugin postgres, qui peuvent aider à accélérer les requêtes sans dépendre d'index en mémoire : https://github.com/rpcpool/solana-geyser-park.

Préoccupations de sécurité

La sécurité est un sujet vaste et vous ne pouvez pas compter sur un petit guide dans un dépôt GitHub. En général, au minimum, vous devez vous assurer que votre serveur RPC n'expose pas les ports 8899 et 8900 directement sans aucun type de proxy et de contrôle d'accès en face. Un moyen simple de le faire est d'utiliser nginx ou HAproxy comme proxy inverse. Vous pouvez ajouter un support SSL et de l'authentification de cette manière grâce aux outils intégrés de chacun.

Pour être en sécurité, vous pouvez vous assurer que votre adresse de liaison rpc est réglée sur 127.0.0.1 (la valeur par défaut pour ce rôle) afin qu'elle ne réponde qu'aux requêtes locales.

Autres livres de jeu

Vous souhaiterez généralement déployer un proxy inverse devant le Solana RPC. HAproxy est une excellente option et nous avons un livre de jeu pour configurer HAproxy pour un serveur rpc Solana ici.

Autres guides et documents

Voici quelques autres guides, ressources et documents rédigés sur Solana RPC :

Nous ne faisons aucune déclaration sur l'exactitude ou la qualité de ces documents. Veuillez les revoir et faites votre propre opinion sur quels documents suivre !