- Produits et Plateforme Helius
- Fondamentaux de Solana
- Mécanique des Transactions
- Tokens et Actifs
- Connectivité et Streaming
- Ecosystème
Produits et Plateforme Helius
Autoscaling
Mécanisme d’approvisionnement automatique de crédits de Helius pour les plans fiat. Lorsque l’allocation mensuelle de crédits est épuisée, l’autoscaling achète des crédits supplémentaires jusqu’à un plafond défini par l’utilisateur, évitant les erreurs429 d’interrompre le trafic de production. Les plans crypto n’ont pas d’autoscaling. Au lieu de cela, ils utilisent des crédits prépayés, achetés manuellement.
Voir Autoscaling.
Crédit
L’unité dans laquelle Helius facture l’utilisation de l’API et du streaming. Les méthodes RPC, les appels DAS et le débit de streaming ont chacun un coût en crédits spécifique. Chaque plan inclut une allocation mensuelle de crédits qui se réinitialise à chaque cycle de facturation (les crédits non utilisés ne se reportent pas). Voir Crédits pour le tableau des coûts complet.DAS API
Digital Asset Standard — une spécification ouverte pour une interface unifiée pour les actifs numériques Solana (NFTs, NFTs compressés, tokens fongibles). L’implémentation de l’API DAS de Helius renvoie des métadonnées enrichies, la propriété et les prix dans une réponse structurée unique, éliminant le besoin de parseurs personnalisés pour les données sur les actifs onchain. Voir DAS API.Nœuds Dédiés
Nœuds RPC privés Helius sans limites de débit ou de crédits, facturés à un taux mensuel fixe. Ils conviennent aux cas d’utilisation étroits nécessitant un débit illimité ; la plupart des applications sont mieux servies par le RPC régulier de Helius en raison de meilleures performances, de la tolérance aux pannes et de la couverture fonctionnelle. Voir Nœuds Dédiés.Transactions Améliorées
L’API de transaction analysée de Helius qui décode les transactions brutes Solana en événements lisibles par l’homme — transferts de tokens, ventes de NFT, swaps, opérations de staking, et plus — sans nécessiter de parseurs d’instruction par programme. Voir Transactions Améliorées.Codes d’Erreur
Codes de statut HTTP standard renvoyés par les API Helius, avec un contexte spécifique à Helius :400 Bad Request— paramètres invalides ou demande mal formée (par exemple, format d’adresse invalide, champs requis manquants, JSON mal formé)401 Unauthorized— clé API manquante ou invalide403 Forbidden— accès refusé, généralement à cause de restrictions IP, d’un abonnement qui n’inclut pas le point de terminaison, ou d’autorisations de clé API insuffisantes404 Not Found— aucune donnée disponible pour la ressource demandée (normal pour les recherches d’identité sur des portefeuilles inconnus)429 Too Many Requests— allocation de crédits épuisée, limite de débit dépassée, ou limite de requêtes simultanées atteinte5xx— problèmes côté Helius ; réessayer avec un backoff exponentiel
Gatekeeper
Passerelle edge de Helius qui offre une latence significativement plus basse que les appels RPC standards en routant les requêtes à travers une flotte de proxies distribuée mondialement. Accessible en remplaçantmainnet.helius-rpc.com par beta.helius-rpc.com dans l’URL RPC.
Voir Gatekeeper et l’article de blog Introducing Gatekeeper pour le contexte architectural.
LaserStream
Service de streaming gRPC haute performance de Helius pour les données onchain Solana, avec relecture historique, basculement multi-région, et le plus riche ensemble de fonctionnalités parmi les produits de streaming de Helius. Les SDK officiels sont disponibles pour JavaScript/TypeScript, Rust et Go. LaserStream WebSocket fonctionne sur la même infrastructure. Voir LaserStream et l’article de blog LaserStream SDK performance pour une analyse approfondie des benchmarks des SDK.LaserStream WebSocket
Service de streaming WebSocket persistant de Helius. Il sert à la fois les méthodes WebSocket standard de Solana et les extensions spécifiques à Helius (transactionSubscribe et un accountSubscribe amélioré avec un filtrage plus riche) sur un point de terminaison unifié. LaserStream WebSocket partage son backend avec LaserStream gRPC.
Voir LaserStream WebSocket.
Pré-confirmations
Signal de transaction à la latence la plus basse de Helius. Streams transactions avant qu’elles ne soient collectées en entrées et déchiquetées : les pré-confirmations de Helius dès que le leader les exécute, avec leur statut d’exécution, et les pré-confirmations BAM lorsque le validateur s’engage à les exécuter, avant qu’elles ne soient exécutées. Plus tôt que Livraison Shred et plus tôt que les streams d’engagement traités. Livré sur une souscription WebSocketpreconfSubscribe. Requiert un plan Professionnel ou supérieur ; mesuré à 10 crédits par message. La couverture dépend de quels validateurs transmettent leur flux à Helius, donc le flux n’est pas continu.
Voir Pré-confirmations et preconfSubscribe.
Priority Fee API
Endpoint d’estimation des frais de Helius qui renvoie les valeurs de frais prioritaires recommandées basées sur les marchés de frais onchain en temps réel. Permet une tarification compétitive des frais sans conjectures ni surpaiement en cas de congestion. Voir Priority Fee API.Limite de Débit
Le nombre maximal de requêtes par seconde autorisées sous un plan Helius donné. Les limites de débit varient selon le niveau de plan et par famille d’API (RPC standard, APIs améliorées, streaming). Les dépasser renvoie429 Too Many Requests.
Voir Limites de Débit.
Sender
Service d’atterrissage de transactions spécialisé de Helius conçu pour les traders à faible latence, combinant frais prioritaires, astuces Jito, et routage de connexion stakée pour maximiser les taux d’atterrissage. Disponible àhttps://sender.helius-rpc.com/fast.
Voir Sender.
Livraison Shred
Service de Helius pour diffuser des shreds brut de Solana sur UDP, livrés avant l’assemblage final des blocs. Helius agrège les shreds d’un réseau distribué de validateurs à travers les régions pour minimiser la variance de latence géographique d’un seul validateur. Utile pour le trading haute fréquence, l’arbitrage, et d’autres applications à faible latence. Les shreds bruts sont disponibles en libre-service depuis le Tableau de Bord Helius - 800/mois par IP sur les plans Pro). Voir Livraison Shred et l’article de blog Winning the Millisecond Game: Shreds, LaserStream, and the Edge of Solana pour une analyse approfondie sur le fonctionnement des shreds.Connexions Stakées
Le chemin de soumission de transactions par défaut pour les plans payants de Helius. Les connexions stakées acheminent les transactions vers les prochains leaders de bloc via la Qualité de Service Pondérée par le Stake (SWQoS) au niveau du protocole de Solana, qui accorde des créneaux de connexion préférentiels basés sur le stake du validateur et réduit les pertes de paquets en cas de congestion. Les plans payants de Helius héritent de cet avantage de taux d’atterrissage sans que les appelants aient besoin de faire fonctionner un validateur fortement staké directement. Voir Optimiser les Transactions et l’article de blog Stake-Weighted Quality of Service: Everything You Need to Know.API Portefeuille
API REST de Helius pour interroger les soldes d’un portefeuille Solana, l’historique des transactions, les transferts, l’identité, et la source de financement — réponses structurées et évaluées en USD au lieu de la sortie brute RPC. Elle accepte les noms de domaines SNS.sol et ANS en plus des adresses.
Voir API Portefeuille.
Fondamentaux de Solana
Compte
Un conteneur qui détient des données de manière persistante sur Solana, identifié par une clé publique de 32 octets. Tout état onchain — soldes utilisateur, code de programme, métadonnées de token — réside dans des comptes, y compris les programmes eux-mêmes. Chaque compte a un propriétaire, qui est un programme autorisé à modifier ses données ou retirer des lamports, et doit maintenir un solde minimum de SOL (exempt de location) pour persister. Voir l’article de blog The Solana Programming Model: An Introduction to Developing on Solana pour une analyse approfondie.Agave
Le client validateur Solana canonique actuel, maintenu par Anza — le successeur rebrandé du client original de Solana Labs. Les références à des versions spécifiques d’Agave (par exemple, le seuil minimal de stake SWQoS de la v1.17.31) fixent généralement le comportement à une version spécifique du client. Jito-Solana est un fork d’Agave avec leur moteur de blocs intégré ; Firedancer est une alternative indépendante en C développée par Jump Crypto. Voir l’article de blog Solana Virtual Machine pour le modèle SVM qu’Agave implémente.Airdrop
Un don de SOL ou de tokens SPL à une adresse. Sur Devnet et Testnet, un airdrop désigne généralement une petite quantité de SOL de test provenant d’un robinet utilisé pour financer des portefeuilles de développement ; sur le Mainnet, il désigne des distributions massives de tokens aux détenteurs existants. Les airdrops Devnet sont disponibles via le Robinet Devnet.Compte de Token Associé (ATA)
Un compte de token dérivé de manière déterministe détenant un token SPL spécifique pour une adresse de portefeuille donnée. Chaque portefeuille a au plus un ATA par jeton mint, faisant des ATAs le lieu canonique pour vérifier le solde de tokens d’un utilisateur. Il est dérivé en utilisant l’adresse du portefeuille et le jeton mint comme graines.Bloc
Une structure de données contenant un ensemble de transactions ainsi que des métadonnées essentielles — y compris le hachage du bloc et le hachage du bloc précédent, formant une chaîne immuable. Les blocs sont produits pendant les slots : le leader assigné pour un slot valide les transactions entrantes, les regroupe dans un bloc et diffuse le bloc au réseau via Turbine. Chaque slot ne produit pas nécessairement un bloc — si le leader échoue à en produire un à temps, le slot est passé outre et le réseau passe au suivant. Une fois qu’un bloc a reçu une supermajorité de votes de validateurs pondérés par le stake, il est considéré comme confirmé (voir Niveau d’Engagement). Voir l’article de blog Understanding Slots, Blocks, and Epochs on Solana pour une analyse approfondie.Niveau d’Engagement
Le degré de confiance qu’une transaction a été incluse onchain :processed— vu par le leader actuel mais pas encore voté ; peut encore être abandonné si le bloc perd le consensus (~0,4 s)confirmed— ≥66% des votes pondérés par le stake des validateurs sur le bloc ; historiquement, aucun bloc confirmé n’a été annulé (~0,6 s)finalized— le bloc a ≥66% de votes plus 31 blocs subséquents construits sur lui (c’est-à-dire le verrouillage maximal du Tower BFT), le rendant pratiquement irréversible (~13 s)
confirmed est la valeur par défaut recommandée. Utiliser processed pour les retours UI, finalized pour les opérations de haute valeur comme les dépôts d’échange ou les ponts trans-chaînes. Les hachages de bloc récupérés à finalized expirent plus tôt que ceux de confirmed, réduisant la fenêtre avant l’expiration des transactions.
Voir l’article de blog What are Solana Commitment Levels? pour une analyse approfondie.
Unités de Calcul (CU)
Mesure de Solana de travail computationnel effectué par une transaction, analogue au gas sur Ethereum. Chaque transaction spécifie une limite d’unités de calcul et un prix par unité de calcul (frais prioritaires en microlamports par CU) ; le produit détermine le coût total des frais prioritaires. Dépasser la limite échoue la transaction.CPI (Cross-Program Invocation)
Mécanisme Solana qui permet à un programme onchain d’en appeler un autre, en passant des comptes et des données d’instruction — la primitive qui permet la composabilité de Solana. Les CPIs sont exposés via la syscallsol_invoke_signed, qui vérifie que l’appelant a les autorisations appropriées pour les comptes transmis ; les PDAs permettent aux programmes de signer pour les comptes qu’ils possèdent.
Un programme appelé fonctionne avec le budget de calcul restant du programme appelant : si ce dernier épuise le budget ou dépasse une limite fixée, toute la chaîne d’appels échoue — y compris la transaction originale.
Voir l’article de blog Solana Virtual Machine pour une analyse approfondie.
Époque
Un groupe d’environ 432,000 slots Solana — l’intervalle organisationnel de niveau supérieur où Solana met à jour son ensemble de validateurs, le programme de leaders, les délégations de stake, et les distributions de récompenses. Chaque époque prend environ 2 jours à la cible de slot actuelle. Voir l’article de blog Understanding Slots, Blocks, and Epochs on Solana pour une analyse approfondie.Firedancer
Un deuxième client de validateur Solana indépendant, écrit from scratch en C par Jump Crypto. Les objectifs déclarés de Firedancer sont (1) documenter et standardiser le protocole Solana via une implémentation indépendante, (2) améliorer la diversité des clients (aucun client unique ne contrôle >33% de stake), et (3) accroître les performances de l’écosystème. L’architecture est modulaire : de nombreux processus Linux à usage unique appelés « tuiles » (tuile QUIC, tuile de vérification, etc.) communiquent via la mémoire partagée, contrairement à la conception à processus unique d’Agave. Frankendancer est leur intermédiaire hybride — le code réseau haute performance en C de Firedancer associé au runtime Rust et au code de consensus d’Agave. Voir l’article de blog What is Firedancer? pour une analyse approfondie.Instruction
La plus petite unité de travail à l’intérieur d’une transaction Solana — une seule invocation de programme avec les comptes et les données pertinentes. Une transaction regroupe une ou plusieurs instructions, exécutées de manière atomique (toutes réussissent ou toutes sont annulées ensemble). Voir l’article de blog The Solana Programming Model: An Introduction to Developing on Solana pour une analyse approfondie.Lamport
La plus petite unité de SOL : 1 SOL = 1,000,000,000 lamports (10⁻⁹ SOL), nommée d’après Leslie Lamport, lauréat du prix Turing pour son travail fondamental dans les systèmes distribués. Les méthodes RPC brutes de Solana retournent des soldes et des frais en lamports ; l’API Portefeuille de Helius gère la conversion automatiquement. Les frais prioritaires sont libellés en microlamports — un millionième de lamport (10⁻¹⁵ SOL).Leader / Programme de Leaders
Le leader est le validateur désigné pour proposer un nouveau bloc pendant un slot donné. Les leaders sont choisis par un programme aléatoire pondéré par stake calculé au début de chaque époque, donc tout validateur peut dériver indépendamment qui dirigera chaque slot dans la fenêtre à venir de ~2-3 jours. Chaque leader se voit attribuer quatre slots consécutifs (~1,6 secondes à ~400 ms par slot), leur donnant une courte fenêtre de production de blocs consécutifs. Si un leader échoue à produire un bloc dans son slot, le slot est sauté — le réseau passe au suivant plutôt que d’attendre le bloc manquant. Les services d’envoi de transactions comme Sender acheminent les transactions signées vers le leader actuel et les deux leaders suivants pour maximiser la probabilité d’atterrissage. Voir l’article de blog Consensus on Solana: Tower BFT and Proof of History pour une analyse approfondie.Arbre de Merkle
Une structure d’arbre cryptographique où chaque nœud non-feuille est un hachage de ses enfants, donc le seul hachage racine engage l’intégralité de l’ensemble de données. Vérifier qu’une donnée appartient à l’arbre nécessite seulement les hachages frères le long du chemin de la feuille à la racine — une preuve de Merkle — qui est O(log n) de données quelle que soit la taille de l’arbre. Pour un arbre de profondeur 26, cette preuve est de 26 hachages frères (~832 octets), ce qui est petit mais toujours par feuille : c’est la forme de preuve utilisée par les NFTs compressés. La Compression ZK la remplace par une preuve de validité de taille constante qui ne grandit pas avec l’ensemble de données. Voir l’article de blog Cryptographic Tools 101: Hash Functions and Merkle Trees Explained.Programme
Un compte exécutable contenant le bytecode compilé sBPF (c’est-à-dire, un smart contract sur Solana). Les programmes sont sans état — ils lisent et écrivent dans des comptes de données qu’ils possèdent et sont identifiés par un ID de programme (leur adresse de 32 octets). Solana est livré avec un ensemble de programmes natifs (System, Stake, Vote, etc.) intégrés au runtime ; tout le reste est un programme déployé par l’utilisateur. Voir l’article de blog The Solana Programming Model: An Introduction to Developing on Solana pour une analyse approfondie.Adresse Dérivée de Programme (PDA)
Une adresse déterministe dérivée d’un ID de programme et d’un ensemble de graines. Les PDAs permettent aux programmes de signer pour les comptes qu’ils contrôlent, les rendant essentiels pour la conception de programmes étatés. Les PDAs sont intentionnellement hors-courbe, donc aucune clé privée n’existe pour eux.Preuve d’Histoire (PoH)
La primitive de synchronisation de Solana — pas un algorithme de consensus. PoH fournit une fonction de marquage temporel cryptographique qui permet aux validateurs de s’accorder sur l’ordre des événements sans communiquer entre eux. Implémentation : une chaîne de hachage SHA-256 séquentielle qui fonctionne en continu sur un seul cœur de CPU par validateur, utilisant la sortie de chaque itération comme entrée de la suivante. La génération est séquentielle et à un seul fil ; la vérification est parallélisable. PoH fournit les « ticks » qui définissent quand un bloc est valide. Les leaders doivent publier des blocs dans une gamme de ticks PoH donnée — un bloc en dehors de cette gamme est considéré comme sauté. PoH fonctionne aux côtés du Tower BFT, qui est le véritable mécanisme de consensus. Voir l’article de blog Proof of History, Proof of Stake, and Proof of Work Explained pour une analyse approfondie.Location / Exemption de Location
Le solde SOL que chaque compte Solana doit détenir pour persister onchain, proportionnel à la taille de stockage du compte. Les comptes doivent être créés exempts de location : les transactions qui laisseraient un compte en dessous du minimum échouent. Une fois exonéré de location, le compte persiste indéfiniment sans paiements supplémentaires.Sealevel
Moteur d’exécution de transactions parallèles de Solana. Contrairement aux VM séquentielles telles que l’EVM, Sealevel exécute plusieurs transactions simultanément sur des cœurs CPU. Cela est possible car chaque transaction Solana déclare explicitement quels comptes elle lira et écrira avant que l’exécution ne commence, pour que le planificateur puisse identifier des lots non-conflictuels sans analyse à l’exécution. Les règles de planification sont simples : les transactions touchant des comptes différents fonctionnent en parallèle ; les transactions qui ne font que lire les mêmes comptes fonctionnent également en parallèle (les lectures ne sont pas conflictuelles) ; les transactions qui écrivent dans les mêmes comptes fonctionnent de manière séquentielle pour éviter les conditions de course. Voir l’article de blog Solana Virtual Machine pour une analyse approfondie.Slot
Unité de temps fondamentale de Solana, pendant laquelle un validateur leader désigné a l’opportunité de produire un bloc. Les slots ciblent actuellement 400 ms, bien que les durées réelles puissent varier selon les conditions du réseau. Si un leader échoue à produire un bloc pendant son slot, le slot est sauté — le réseau passe au slot suivant plutôt que d’attendre, donc chaque slot ne se traduit pas toujours en un bloc. Voir l’article de blog Understanding Slots, Blocks, and Epochs on Solana pour une analyse approfondie.SVM (Solana Virtual Machine)
Pleine pile d’exécution de transactions de Solana — pas un interpréteur de bytecode limité. Le SVM englobe le composant Bank qui orchestre l’exécution, le planificateur de l’étape Banking, les chargeurs BPF, et la machine virtuelle sBPF elle-même (une VM à registre avec 11 registres généraux et ~100 opcodes, JIT-compilée pour la performance). Cela diffère de l’EVM, qui se réfère sans équivoque à un seul exécuteur de bytecode. Les programmes Solana se compilent en sBPF, le fork Solana de Linux eBPF. Tout langage avec un frontend LLVM (C, C++, Rust, Zig) peut cibler sBPF. Exiger des transactions de déclarer l’accès aux comptes à l’avance est ce qui déverrouille l’exécution parallèle de Sealevel et les marchés de frais localisés de Solana. Voir l’article de blog Solana Virtual Machine pour une analyse approfondie.Tower BFT
Mécanisme de consensus de Solana. Le Tower BFT est un algorithme de type pBFT qui profite de la synchronisation Proof of History, éliminant le besoin d’une ronde de consensus synchrone à chaque slot. Les validateurs construisent une « tour de vote » — une pile séquentielle de votes où chaque nouveau vote double la période de verrouillage de tous les votes précédents, augmentant de manière exponentielle le coût de perte de stake pour changer de fourches. Seuils de confirmation : un bloc est confirmé une fois que ≥2/3 des votes pondérés par stake ont atterri dessus (≥4,6% du stake total devrait être coupé pour violer la finalité). Un bloc est finalisé une fois qu’il a des votes plus 31 blocs subséquents construits dessus, le verrouillage maximal du Tower BFT. Voir Niveau d’Engagement pour les conseils d’utilisation. Voir l’article de blog Consensus on Solana: Tower BFT and Proof of History pour une analyse approfondie.Turbine
Protocole de propagation des blocs de Solana. Le leader divise chaque bloc en shreds de taille MTU plus des shreds de récupération codées par effacement de Reed-Solomon — le taux FEC (généralement 32:32) permet au réseau de reconstruire un bloc même avec ~33% de perte de paquets. Le leader transmet ensuite les shreds à travers un arbre déterministe pondéré par le stake de pairs validateurs (semé par groupe de shreds par(leader id, slot, shred index, shred type)) plutôt que de diffuser le bloc entier à chaque validateur directement. L’arbre (DATA_PLANE_FANOUT = 200) maintient la bande passante sortante du leader pratiquement constante quel que soit le nombre de validateurs et permet aux blocs d’atteindre le réseau en 2–3 sauts au lieu de O(n).
Voir l’article de blog Turbine: Block Propagation on Solana.
Validateur
Un nœud sur le réseau Solana qui participe au consensus en produisant des blocs pendant ses slots de leader assignés et en votant sur les blocs d’autres validateurs. Les validateurs sont sélectionnés pour les slots de leader proportionnellement à leur stake actif.Mécanique des Transactions
Table de Recherche d’Adresse (ALT)
Une table onchain d’adresses Solana qu’une transaction versionnée peut référencer en utilisant un index d’un octet au lieu d’une clé publique complète de 32 octets, permettant à une seule transaction de référencer jusqu’à 256 comptes. Les ALTs sont essentielles pour les opérations DeFi complexes qui autrement dépasseraient les limites de taille de transaction.Blockhash
Un hachage de 32 octets identifiant un bloc récent, inclus dans chaque transaction Solana pour prouver sa fraîcheur. Les blockhashes expirent après environ 150 slots (~1 minute) ; les transactions avec des blockhashes expirés sont rejetées. Les clients récupèrent un blockhash récent viagetLatestBlockhash juste avant de signer.
Frais Prioritaires
Un pourboire par unité de calcul payé aux validateurs pour donner à une transaction une priorité sur les autres, améliorant son temps d’inclusion. Les frais prioritaires sont fixés en microlamports par unité de calcul (µLamports/CU). L’API des Frais Prioritaires de Helius retourne des estimations en temps réel basées sur les marchés de frais récents onchain.Shred
La plus petite unité d’un bloc Solana. Les blocs sont divisés (c’est-à-dire déchiquetés) en shreds pour une propagation parallèle à travers le réseau de validateurs via Turbine. L’accès au niveau des shreds donne aux traders des signaux onchain à ultra-basse latence, avant l’assemblage du bloc — bien que les Pré-confirmations arrivent encore plus tôt, avant que les entrées ne soient déchiquetées. Voir Shreds Bruts (UDP) et la vue d’ensemble Livraison Shred.Qualité de Service Pondérée par le Stake (SWQoS)
Mécanisme au niveau du protocole Solana qui priorise les transactions entrantes vers les leaders actuels et futurs en fonction du stake de l’expéditeur. Introduit après la panne de Solana du 30 avril 2022 en tant que mesure de résistance Sybil, SWQoS empêche les pairs à faible stake ou non stakés de monopoliser la bande passante du leader pendant la congestion. Le leader expose deux pools de connexions entrantes : ~500 connexions ouvertes partagées entre tous les pairs non stakés, et ~2,000 connexions pondérées par le stake réparties proportionnellement parmi les validateurs stakés — un validateur détenant X% du stake actif total peut envoyer jusqu’à X% des paquets au leader. Les validateurs sous ~15,000 SOL de stake actif (~1/25,000 du stake total du réseau) sont traités comme non stakés. Le seuil minimum de stake s’est placé dans Agave v1.17.31. Les Connexions Stakées de Helius héritent de cet avantage de taux d’atterrissage en routant les transactions des clients à travers le plus grand validateur de Solana, donc les appelants bénéficient de SWQoS sans exploiter directement un validateur fortement staké. Voir l’article de blog Stake-Weighted Quality of Service: Everything You Need to Know.Transaction Versionnée
Format de transaction Solana identifié par un octet de version au début de la transaction sérialisée. La version 0 (v0) a ajouté les Tables de Recherche d’Adresse, permettant à une transaction de référencer jusqu’à 256 comptes (vs. ~35 dans les transactions héritées). La version 1 (v1, SIMD-0385, Agave 4.2) déplace les signatures à la fin de la transaction et porte le budget de calcul dans un champ d’en-têtetransactionConfig au lieu des instructions ComputeBudget. Définissez maxSupportedTransactionVersion: 1 sur les requêtes RPC pour recevoir chaque version. Voir Support des Transactions v1.
Tokens et Actifs
Compte Compressé
Un compte compressé est un compte Solana dont les données sont engagées dans le registre via des journaux de transactions, avec seulement une empreinte de hachage stockée dans l’état du validateur — plutôt que que les données complètes occupant un emplacement de compte traditionnel sur les disques des validateurs. Les développeurs peuvent traiter les comptes compressés comme des comptes réguliers ; les indexeurs (comme Photon) analysent les journaux de transactions pour reconstruire l’état actuel, et une preuve zéro-knowledge Groth16 de taille constante vérifie l’intégrité lorsque les comptes sont lus ou modifiés via la Compression ZK. Ce modèle est mieux adapté aux comptes de petites données — les données plus grandes (au-dessus de ~100 octets) rendent la compression impraticable.NFT Compressé (cNFT)
Un NFT Solana représenté comme une feuille dans un arbre de Merkle concurrent onchain plutôt que son propre compte. L’arbre vit dans un compte Solana et ses transitions d’état sont sécurisées par le registre ; l’état actuel du NFT est dérivé de l’historique des transactions par des indexeurs, qui produisent des preuves de Merkle vérifiables contre la racine onchain de l’arbre. Lire un cNFT nécessite donc un indexeur comme l’API DAS — le RPC Solana standard ne peut pas retourner directement des données cNFT. Ce modèle réduit les coûts de mint jusqu’à 99% par rapport aux NFTs standards.Arbre de Merkle Concurrent
Une variante spécifique à Solana d’un Arbre de Merkle conçue pour permettre à plusieurs écrivains de mettre à jour l’arbre dans le même slot sans invalider les preuves des autres. Le compte onchain stocke non seulement la racine actuelle mais aussi un tampon de journal des modifications des racines valides récentes et un auvent (un sous-ensemble mis en cache des nœuds de l’arbre supérieur), permettant aux validateurs de vérifier les preuves générées contre toute racine encore dans la fenêtre de tampon. Trois paramètres définissent un arbre : profondeur maximum (limite le nombre de feuilles à 2^profondeur), taille du tampon (profondeur du journal — combien d’écritures peuvent se produire avant que les preuves en cours deviennent invalides), et profondeur de l’auvent (qui échange la location onchain pour des preuves plus petites en transaction). Paires valides (profondeur, tampon) variant de (3, 8) jusqu’à (30, 2048); pour compositionnalité pratique, gardezmaxDepth − canopyDepth ≤ 10.
Les arbres de Merkle concurrents sont implémentés par le programme SPL Account Compression et sont le substrat pour les NFTs compressés, qui sont mintés comme des feuilles via Metaplex Bubblegum.
Voir l’article de blog All You Need to Know About Compression on Solana.
Groth16
Un système de preuve zk-SNARK qui produit des preuves de connaissance zéro de taille constante (128 octets sur la courbe BN254, en utilisant la compression de points) quel que soit la complexité de l’énoncé, avec vérification O(1). La Compression ZK utilise Groth16 pour générer des preuves de validité qu’un compte compressé appartenait à un état connu à une racine connue — la petite taille de la preuve est ce qui permet aux transactions de comptes compressés de rester abordables. Voir l’article de blog Solana Builders: ZK Compression.Compte de Mint
Le compte onchain définissant les propriétés d’un token SPL — approvisionnement, décimales, et autorités de mint/congelation. L’adresse du compte de mint est l’identifiant canonique du token (son « adresse de contrat » en termes Ethereum).Token SPL
Un token sur Solana émis via le Programme de Tokens de la Solana Program Library (SPL). Les tokens fongibles (USDC, BONK, JUP, etc.) sont des tokens SPL ; les NFTs standards (non compressés) sont également des tokens SPL, mintés avec un approvisionnement de 1 et 0 décimales. Les tokens SPL sont à peu près l’équivalent Solana des ERC-20 et ERC-721 sur Ethereum. Token-2022 est un programme plus récent qui étend cette interface avec des fonctionnalités optionnelles comme les frais de transfert et les transferts confidentiels.Arbre d’État
L’arbre de Merkle que la Compression ZK utilise pour stocker les hachages des comptes compressés. Le compte onchain ne contient que la racine actuelle plus des métadonnées minimales ; les données compressées réelles vivent dans les journaux de transactions et sont reconstruites par des indexeurs comme Photon. Les programmes lisent ou modifient l’état compressé en passant une preuve de validité que le contenu revendiqué du compte se hache en une feuille sous la racine actuelle. Voir ZK Compression.Compte de Token
Un compte onchain détenant un solde d’un token SPL spécifique pour un propriétaire spécifique. Un portefeuille peut posséder des comptes de tokens arbitraires, mais la convention est d’utiliser un Compte de Token Associé (ATA) — un compte de token dérivé de manière déterministe par paire (portefeuille, mint) créé par le Programme de Compte de Token Associé.Token-2022 (Extensions de Token)
Une variante du Programme de Token SPL prenant en charge des extensions optionnelles (par exemple, frais de transfert, transferts confidentiels, tokens générateurs d’intérêts, tokens non transférables). Token-2022 fonctionne comme un programme onchain distinct, avec son propre ID de programme, mais est conçu comme un successeur compatible du Programme de Token classique, donc les SDKs peuvent généralement gérer les deux. Les mints doivent être créés sous le programme Token-2022 pour utiliser les extensions. Voir l’article de blog What are Token Extensions?.Preuve de Validité
Une preuve de connaissance zéro Groth16 de taille constante que le contenu revendiqué d’un compte compressé existait dans l’Arbre d’État à une racine spécifique. Les programmes de Compression ZK nécessitent une preuve de validité chaque fois que des comptes compressés sont lus ou modifiés ; la preuve permet au programme de vérifier l’état off-chain sans que le validateur ne stocke les données onchain. Photon expose des preuves de validité aux appelants via sa méthode RPCgetValidityProof.
Les preuves de validité sont ce qui distingue la Compression ZK des NFTs compressés : les cNFTs utilisent des preuves de Merkle simples (une liste de hachages frères de la feuille à la racine, qui grandit avec la profondeur de l’arbre), tandis que la preuve ZK de taille constante de la Compression ZK ne révèle pas le chemin ou l’état environnant de l’arbre.
Voir l’article de blog Solana Builders: ZK Compression.
Compression ZK
La Compression ZK est une primitive Solana développée par Helius et Light Protocol qui réduit considérablement les coûts de stockage onchain en engageant les données de compte dans les journaux de transactions du registre et en ne stockant qu’une empreinte de hachage dans l’état du validateur. L’intégrité cryptographique est préservée via des preuves de connaissance zéro Groth16 de taille constante générées à partir des données de transactions indexées. Cette primitive est distincte des NFTs compressés, utilisant des arbres de Merkle concurrents sans preuves de connaissance zéro. Voir ZK Compression et l’article de blog Solana Builders: ZK Compression pour une analyse approfondie.Connectivité et Streaming
Geyser
Système de plugin de Solana pour diffuser les changements d’état du validateur — comptes, transactions, slots, blocs — vers des consommateurs externes en temps réel. Les validateurs chargent les plugins Geyser en tant que bibliothèques dynamiques ; le plugin reçoit les mises à jour d’état à mesure que le validateur les traite, éliminant le besoin de sonder le RPC pour les changements. Yellowstone gRPC — le plugin Geyser dominant — expose ces mises à jour sur gRPC. Le LaserStream de Helius implémente l’interface Yellowstone gRPC avec des fonctionnalités supplémentaires comme la relecture historique (jusqu’à ~216,000 slots / ~24 heures) et le basculement multi-région.gRPC
gRPC est un protocole RPC binaire généraliste et haute performance (un acronyme récursif pour « gRPC Remote Procedure Call »). Dans les contextes Solana, « gRPC » fait généralement référence à Yellowstone gRPC — une interface de streaming construite sur le système de plugin Geyser de Solana qui expose les mises à jour de comptes et de transactions sur gRPC. Le service LaserStream de Helius est construit sur une interface basée sur Yellowstone avec des fonctionnalités supplémentaires comme la relecture historique, le basculement multi-région, et l’infrastructure gérée.RPC
RPC signifie Appel de Procédure Distant, qui est un modèle général pour appeler une méthode serveur comme s’il s’agissait d’une fonction locale. Dans Solana, « RPC » fait le plus souvent référence à un nœud RPC — un nœud qui suit l’état de Solana mais ne participe pas au consensus, se spécialisant dans la réponse aux requêtes de données (c’est-à-dire, état des comptes, historique des transactions, soumission de transactions) sur une interface JSON-RPC. Les validateurs, par contraste, produisent des blocs et votent sur eux. Le service RPC de Helius est une flotte distribuée mondialement de nœuds RPC optimisés pour les charges de travail de production. Voir l’article de blog Solana Nodes — A Primer on Solana RPCs, Validators, and RPC Providers pour une analyse approfondie.Webhook
Un webhook est une requête HTTP POST envoyée par un serveur à une URL de réception lorsqu’un événement souscrit se produit — HTTP « inversé », où le serveur initie l’appel. Les Webhooks de Helius poussent des événements onchain Solana (transferts, ventes de NFT, activité de programme personnalisé) à un point de terminaison enregistré, éliminant le besoin de sondage.WebSocket (WSS)
Un WebSocket est une connexion TCP bidirectionnelle persistante mise à niveau à partir de HTTP, utilisée pour le streaming de données Solana basé sur la poussée sans requêtes HTTP répétées. WSS (WebSocket Secure) est le même protocole fonctionnant sur TLS, et est la variante utilisée pour les connexions Solana en production. LaserStream WebSocket — produit de streaming WebSocket de Helius, incluant les méthodes Solana standard et les extensions Helius commetransactionSubscribe — utilise WSS.
Écosystème
Anchor
Anchor est un framework Rust pour construire rapidement et en toute sécurité des programmes Solana. Il gère des modèles comme la sérialisation des comptes, la validation, et la distribution des instructions via des macros procédurales, permettant aux développeurs de se concentrer sur la logique du programme plutôt que sur les détails de bas niveau. La plupart des développeurs Solana utilisent Anchor plutôt que d’écrire des programmes en Rust natif. Voir l’article de blog An Introduction to Anchor: A Beginner’s Guide to Building Solana Programs pour une analyse approfondie.IDL
IDL signifie Interface Definition Language. Un IDL est un schéma JSON décrivant les instructions, comptes et types de données d’un programme Solana ; les clients l’utilisent pour construire des transactions et décoder des données de programme sans recourir aux mises en page d’instruction manuelles. Anchor génère automatiquement les IDLs et les publie onchain par défaut dans un compte dédié pour la découverte publique.Jito
Une société de l’écosystème Solana qui exploite le moteur de blocs dominant du réseau — une couche d’infrastructure MEV (valeur extractible maximale) qui accepte des lots de transactions (groupes atomiques de transactions qui s’exécutent ensemble ou pas du tout) et permet aux chercheurs de payer des pourboires aux validateurs pour prioriser leur inclusion. Le client validateur Jito-Solana est un fork d’Agave avec le moteur de blocs intégré. L’inclusion d’un lot nécessite un pourboire minimum de 10,000 lamports, et le Jito-Relayer retient le trafic entrant pendant ~200 ms pour permettre l’enchère de lot hors chaîne. Le Sender de Helius soumet des transactions à la fois via des connexions stakées et le moteur de blocs de Jito simultanément, prenant le chemin qui atterrit en premier. Voir l’article de blog Solana MEV: An Introduction.Light Protocol
L’équipe de protocole Solana qui a co-développé la Compression ZK avec Helius. Helius a construit l’indexeur canonique (Photon) et opère le RPC public ; Light Protocol construit les programmes onchain et la pile de preuves sur laquelle l’indexeur dépend. Voir github.com/Lightprotocol/light-protocol.Photon
L’indexeur open-source de la Compression ZK construit par Helius. Les données de compte compressées vivent dans les journaux de transactions Solana plutôt que dans l’état du compte, donc les validateurs ne les exposent pas via le RPC standard — Photon analyse les transactions Solana, reconstruit l’état du compte compressé, et le sert via une interface JSON-RPC qui reflète le RPC natif de Solana plus des méthodes spécifiques à la Compression ZK commegetCompressedAccount et getValidityProof. Les développeurs peuvent auto-héberger depuis github.com/helius-labs/photon ou utiliser le point de terminaison Helius hébergé.
Voir ZK Compression.