P-Token : le prochain grand gain d’efficacité de Solana

Introduction

L’un des facteurs sous-estimés de l’adoption rapide de Solana est son approche sûre, simple et standardisée des tokens. Contrairement à de nombreuses autres blockchains, créer un token sur Solana ne nécessite pas de déployer un contrat personnalisé. Tout passe plutôt par le programme SPL token (aussi appelé Tokenkeg), largement audité, éprouvé en conditions réelles et initialement déployé par Solana Labs. Cette approche simplifie les opérations courantes comme la création, la destruction et le transfert de tokens. Le déploiement d’un token Solana peut, par exemple, s’effectuer avec une seule commande CLI.

Le programme SPL Token est le programme le plus utilisé sur Solana, après le programme System. Au cours des six derniers mois, entre 200 000 et 300 000 nouveaux tokens fongibles ont été créés chaque semaine en moyenne via le programme SPL token. Cela représente une multiplication par 20 par rapport à septembre 2023, deux ans plus tôt, lorsque le nombre hebdomadaire de nouveaux tokens SPL restait régulièrement inférieur à 10 000. Globalement, à l’exception de 2023, chaque année depuis le lancement de Solana a enregistré une hausse significative du nombre de nouveaux tokens émis, comme le montre le graphique ci-dessous.

La croissance des transferts de tokens SPL a été encore plus marquée. Au cours des trois derniers mois, les transferts hebdomadaires ont constamment dépassé 650 millions, avec un pic de 867,8 millions fin juillet. Ce pic représente une multiplication par 17,5 par rapport au creux de 49,4 millions de transferts hebdomadaires enregistré début août 2023.

Présentation de P-Token

P-token est un remplacement direct et optimisé pour le calcul du programme SPL Token actuel. Il a été proposé pour la première fois par l’équipe Anza en mars dans SIMD-0266: Efficient Token Program. Il réduit considérablement l’utilisation des unités de calcul (CU), tout en restant entièrement rétrocompatible avec les tokens SPL existants. 

Comme p-token reproduit exactement le jeu d’instructions et la structure des comptes du programme SPL Token, il peut le remplacer directement. Cela signifie que p-token n’est pas un nouveau standard de token. Le code client continue de fonctionner exactement comme avant, ce qui permet d’obtenir d’importants gains d’efficacité sans demander le moindre ajustement aux applications ni aux utilisateurs.

L’adoption de p-token s’inscrit dans l’effort plus large de Solana visant à améliorer l’efficacité des programmes et des frameworks. Cet effort complète les travaux destinés à accroître la capacité du réseau, notamment l’objectif fixé pour 2025 de doubler l’espace de bloc disponible.

Le succès récent des AMM propriétaires sur Solana illustre l’impact d’un coût de calcul réduit et les avantages de programmes très efficaces. Par exemple, les mises à jour d’oracle sur des plateformes comme HumidiFi ont été hyperoptimisées pour ne consommer que 143 CU. Doppler, un nouveau programme d’oracle open source de BlueShift, réduit encore davantage ce coût, à seulement 21 CU.

Pinocchio

Le « p » de p-token signifie Pinocchio, une bibliothèque optimisée, performante et sans dépendance développée par Anza pour écrire des programmes Solana. Pinocchio remplace le crate solana-program standard et utilise largement des types zero-copy pour traiter les données d’instruction et de compte. Avec le zero-copy, les données ne sont pas dupliquées dans de nouveaux emplacements mémoire lors de leur lecture ou de leur écriture. L’état est directement accessible au moyen de pointeurs. Cette conception permet d’importantes économies de calcul en évitant les opérations mémoire inutiles, tout en réduisant la surcharge à l’exécution.

Pinocchio est également no_std, ce qui signifie qu’il ne dépend ni de la bibliothèque standard de Rust ni des allocations sur le tas, puisque la Solana Virtual Machine (SVM) fournit déjà l’environnement d’exécution. Cela rationalise encore l’exécution et réduit les dépendances, pour des programmes plus légers et plus rapides.

Gains d’efficacité

Les CU mesurent le coût d’exécution dans l’environnement d’exécution de Solana. La plus petite opération, comme l’addition de deux entiers ou une opération bit à bit, consomme 1 CU. Les programmes sont limités à 200 000 CU par instruction et à 1,4 million de CU par transaction.

P-Token apporte des gains d’efficacité spectaculaires en réduisant d’environ 95 % la consommation de CU des transactions SPL token standard, soit une efficacité multipliée par 19. Cette exécution plus rapide améliore la fluidité de l’expérience utilisateur. En libérant des ressources de calcul, elle permet aussi d’intégrer davantage de transactions dans chaque bloc, ce qui augmente directement le débit du réseau.

Aujourd’hui, les instructions du programme Token représentent environ 10 % de l’utilisation des CU à l’échelle d’un bloc. En ramenant leur coût à seulement 5 % de son niveau actuel, p-token peut réduire cette part de 10 % à 0,5 % et libérer 9,5 % supplémentaires de la capacité des blocs pour d’autres transactions. P-token profite également aux programmes en aval et améliore la composabilité en réduisant l’utilisation globale des CU ainsi que le coût des invocations interprogrammes (CPI).

Les données ci-dessous détaillent les gains d’efficacité en CU des instructions p-token par rapport au programme SPL Token actuel, sous forme de graphique et de tableau.

Une autre optimisation notable, rendue possible en grande partie par `no_std`, est la réduction de la taille du binaire du programme, qui passe de 131 Ko à 95 Ko.

Instructions supplémentaires

P-token propose d’ajouter au programme de token trois nouvelles instructions (`withdraw_excess_lamports`, `batch` et `unwrap_lamports`) absentes du programme SPL token d’origine.

Retrait des lamports excédentaires

Comme dans l’implémentation SPL Token-2022 actuelle, `withdraw_excess_lamports` permet de récupérer l’excédent de SOL « bloqué » dans le compte de création. Cela se produit généralement lorsqu’un utilisateur envoie par erreur des lamports au compte de création du token.

Le retrait nécessite l’autorisation de l’autorité de création, qu’il s’agisse du signataire désigné pour les comptes de création standard ou du multisig pour les comptes multisig. Comme l’autorité de création de la plupart des tokens SPL a été révoquée, l’autorisation peut à la place être fournie en utilisant le compte de création lui-même comme autorité de signature, l’instruction étant signée avec la clé privée de ce compte.

Parmi tous les comptes de création de tokens SPL, environ 869 000 détiennent plus de SOL que le seuil minimal d’exemption de loyer, fixé à 0,0014616 SOL. Au total, cela représente 176 961,5 SOL bloqués dans des comptes de création de tokens, soit 36 millions de dollars au cours actuel. Les plus grandes quantités de SOL bloquées dans des comptes de création de tokens sont généralement liées à des memecoins, à d’anciens tokens et à des actifs majeurs de premier plan. La plus grande quantité de SOL bloquée dans le compte de création d’un seul token est celle de BOOK OF MEME ($BOME), un memecoin, avec 6 328 SOL. L’adoption de p-token pourrait permettre de débloquer ces soldes et offrir une manne aux équipes à l’origine de ces tokens.

Traitement par lots

La deuxième nouvelle instruction est `batch`, qui simplifie les interactions CPI avec le programme p-token. Au lieu d’appeler plusieurs fois le programme de token, `batch` permet d’exécuter un nombre variable d’instructions de token en un seul appel. Ainsi, le coût CPI de base de 1 000 unités n’est payé qu’une seule fois, et non pour chaque instruction.

Il en résulte une réduction substantielle de l’utilisation des ressources de calcul pour les protocoles qui s’appuient sur plusieurs CPI de token dans une même instruction, une pratique courante dans la DeFi sur Solana. Par exemple, un AMM peut effectuer deux transferts lors d’un swap, tandis qu’un dépôt dans un pool de liquidité peut impliquer à la fois des transferts et des créations. En utilisant `batch`, les programmes peuvent réaliser d’importantes économies de CU dans ces scénarios.

Déballage des lamports

L’instruction `unwrap_lamports` (récemment ajoutée dans une PR distincte) permet de transférer directement des lamports vers un compte de destination, sans devoir créer de comptes temporaires de tokens natifs.

Auparavant, le déballage de lamports depuis un compte SOL enveloppé nécessitait de créer puis de fermer un compte de token associé (ATA) pour le destinataire. Avec cette mise à jour, les lamports peuvent désormais être transférés directement depuis des comptes SOL natifs, ce qui simplifie le processus.

Chemin rapide pour les instructions de transfert

L’analyse de l’utilisation du programme de token sur le mainnet montre une forte concentration autour des instructions de transfert, qui représentent ensemble près de la moitié de toute l’activité. Les cinq instructions les plus utilisées sont :

• transfer_checked (36.33%)
• transfer (13.22%)
• close_account (12.23%)
• initialize_account3 (9.98%)
• initialize_immutable_owner (9.78%)

Ce profil d’utilisation révèle une possibilité d’optimiser davantage p-token pour les transferts et de réduire la consommation de CU. Cavey de Temporal a largement contribué à ce travail d’optimisation. Pour approfondir cette approche, regardez son livestream sur X.

Pour obtenir ces gains, p-token introduit un point d’entrée personnalisé avec un chemin rapide pour les instructions de transfert et met à jour le processeur afin de donner la priorité à `sync_native` et `initialize_immutable_owner`. Ensemble, ces changements apportent d’importants gains d’efficacité en CU, conformément aux profils d’utilisation observés.

Journalisation

Avec l’introduction de p-token, une question reste ouverte : faut-il conserver le comportement actuel de journalisation ? La dernière version de la proposition recommande de supprimer les logs. Sur Solana, les logs constituent le principal mécanisme d’extraction des données de débogage, de surveillance et d’événement des programmes. Dans le programme de token existant, ils sont minimes et se limitent à afficher le nom de l’instruction en cours d’exécution. Par exemple :

Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [1],
Program log: Instruction: TransferChecked,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 6281 of 7738 compute units,
Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA success

Cependant, cette ligne de log apparemment anodine, `Instruction: <name>`, coûte environ 103 unités de calcul. En pratique, cette surcharge peut consommer presque autant de ressources que l’instruction elle-même. Par exemple, la journalisation représente environ 40 % du calcul total nécessaire à un transfert simple.

En plus de leur coût, ces logs ne sont pas toujours fiables : ils peuvent être tronqués ou manipulés par injection de logs, ce qui risque d’induire en erreur les parseurs en aval. D’un autre côté, leur suppression complète pourrait perturber les workflows des développeurs et des applications qui en dépendent actuellement.

La suppression des logs renforcerait l’importance de la publication des IDL par les équipes afin d’offrir une visibilité sur le comportement des programmes. Anchor l’impose désormais, par exemple, en publiant par défaut les IDL de tous les nouveaux programmes, sauf désactivation explicite.

Audit

L’audit du programme p-token est déjà en cours afin de garantir sa sécurité et sa rétrocompatibilité totale. Pour être adopté, p-token doit respecter strictement les instructions et la structure des comptes du programme Token actuel, et reproduire précisément son comportement. Tout écart présenterait un risque, auquel répondent des tests approfondis et des audits indépendants.

Les auditeurs de Neodyme ont effectué des tests d’équivalence en rejouant deux fois chaque transaction du mainnet des derniers mois : une fois avec le programme de token d’origine et une fois avec p-token. Les résultats ont confirmé des sorties identiques tout en démontrant d’importantes économies de CU.

Selon leur analyse, entre le 3 et le 11 août 2025, p-token aurait réduit la surcharge de 8,9 billions de CU avec la journalisation activée et de 9,14 billions de CU sans journalisation. Ces chiffres représentent respectivement 12,0 % et 12,3 % d’économies sur l’utilisation totale de l’espace de bloc.

P-token fait actuellement l’objet d’un deuxième audit par Zellic et d’une vérification formelle par Runtime Verification.

Déploiement

Le processus de déploiement prévu pour p-token suit une approche progressive. Il commence par l’achèvement de l’audit, des tests par fuzzing et de la vérification formelle. Viennent ensuite un vote de gouvernance des validateurs sur l’adoption de p-token et l’acceptation formelle de SIMD 266. La fonctionnalité p-token sera ensuite déployée sur le cluster et placée derrière un feature gate.

Le programme sera d’abord déployé sur un compte désigné (ptokN…UkkZ2). Une fois le feature gate activé à la limite d’une époque, l’environnement d’exécution de tous les validateurs remplacera le programme de token existant (Tokenkeg…VQ5DA) par la nouvelle implémentation, à l’aide d’Upgradable Loader v3.

Une autre approche consisterait à déployer le programme p-token à une nouvelle adresse, ce qui obligerait les utilisateurs et les applications à migrer manuellement. Cette option n’est toutefois pas privilégiée, car elle freinerait probablement l’adoption et réduirait les bénéfices globaux, de nombreux utilisateurs risquant d’hésiter ou de tarder à effectuer la transition.

Impact économique

L’adoption de p-token s’inscrit dans une série d’améliorations susceptibles d’accroître considérablement la capacité globale de Solana en permettant d’intégrer davantage de transactions dans chaque bloc. Parmi les autres mises à niveau notables figurent le doublement de l’espace de bloc à 100 millions de CU et le relèvement de la limite de CU par compte, d’un plafond fixe de 12 millions à 40 % du bloc.

Actuellement, un même compte est limité à 12 millions de CU par bloc. Comme l’illustre le graphique d’Anza ci-dessous, le compte le plus sollicité de chaque bloc atteint fréquemment ce plafond. À lui seul, P-token rendra cette limite plus difficile à atteindre, réduisant ainsi la fréquence des goulets d’étranglement liés aux états fortement sollicités.

Aujourd’hui, presque toutes les transactions incluent soit des frais de priorité, soit un pourboire Jito afin d’inciter les validateurs à les intégrer dans un bloc. Comme la priorité dépend des frais par CU, une transaction p-token qui consomme moins de CU devrait, toutes choses égales par ailleurs, bénéficier d’une priorité supérieure pour les mêmes frais ou le même pourboire. Cela dit, puisque toutes les transactions SPL token profiteront de la mise à niveau p-token, son impact global sur la priorisation des transactions reste à déterminer.

Conclusion

Sous réserve de son approbation par un vote de gouvernance, l’adoption de p-token représente une avancée majeure pour l’efficacité et la scalabilité de Solana. En réduisant considérablement l’utilisation des ressources de calcul et en simplifiant les interactions CPI, elle renforce les fondations du programme le plus utilisé du réseau tout en augmentant la capacité globale des blocs. En cas de succès, p-token pourrait servir de modèle pour développer des versions optimisées avec Pinocchio d’autres programmes très utilisés, comme le programme Associated Token Account (ATA) et même le programme System, ouvrant ainsi la voie à un environnement d’exécution plus rapide et plus efficace.

Ressources complémentaires

• Dépôt p-token - GitHub
• Dépôt Pinocchio - GitHub
• Solana Program Library (SPL) - GitHub
• Calculateur d’économies en SOL de p-Token - SendAI