Comment transformer votre idée en programme Solana (smart contract)

Exemple de programme Solana — Créer un marché prédictif

Le programme que nous allons concevoir aujourd’hui est un marché prédictif semblable à Polymarket, Hedgehog ou Drift BET. Si vous ne connaissez pas les marchés prédictifs, ils permettent de parier sur différents résultats possibles d’un événement. Il peut s’agir de l’équipe qui remportera le Super Bowl, de la personne qui gagnera l’Oscar du meilleur réalisateur, de la publication éventuelle d’une annonce gouvernementale avant une date précise ou de tout autre événement réel ayant un résultat déterminé. Les personnes qui parient sur le résultat gagnant reçoivent une part de la cagnotte des paris.

Architecture d’un marché prédictif

Voici l’architecture centrale d’un marché prédictif et les relations entre ses différents éléments :

• Il existe plusieurs événements.
• Chaque événement comporte plusieurs résultats. À terme, l’un d’eux sera désigné comme résultat gagnant.
• Les utilisateurs placent plusieurs paris sur chaque résultat. Lorsqu’un utilisateur place un pari, ses fonds sont ajoutés à la cagnotte des gains de cet événement.

Lorsque l’événement est « résolu » (c’est-à-dire lorsque le résultat gagnant est connu) :

• Les utilisateurs ayant parié sur le résultat gagnant peuvent réclamer leurs gains
• Les gagnants reçoivent une part de la cagnotte des gains (minorée d’une commission pour la plateforme)
• La part de chaque gagnant dans la cagnotte dépend de la proportion que représente son pari parmi tous les paris placés sur le résultat gagnant.

1. Concevoir notre application sous forme de comptes Solana

Si nous concevions ce programme pour utiliser une base de données relationnelle, nous réfléchirions aux éléments suivants :

• Les éléments de données similaires sont stockés sous forme de lignes dans une table 
• Des clés primaires permettent d’identifier chaque donnée de façon unique
• Les colonnes de la table définissent les attributs attendus de chaque donnée et leurs types

Dans Solana, ces concepts correspondent approximativement aux éléments suivants :

• Les éléments de données similaires sont stockés avec le même type de compte 
• Des adresses permettent d’identifier chaque donnée de façon unique
• La struct (clés et types de données) définit les attributs de chaque élément

Voici les mêmes données, présentées à la fois dans une table de base de données traditionnelle et sous forme de comptes Solana :

2. Modéliser les relations entre les données

Les relations entre les éléments de données fonctionnent très différemment dans Solana. Les bases de données traditionnelles utilisent des relations (c’est-à-dire des connexions logiques entre les tables). Solana gère les relations un-à-plusieurs sous forme de vecteur d’adresses, chaque adresse contenant un compte avec l’élément concerné. 

Par exemple, les événements comportent des « résultats » représentés par un vecteur d’adresses de résultats. Anchor représente cela par Vec<Pubkey>, bien que les adresses PDA (comme celle de notre résultat) ne soient pas réellement des clés publiques.

3. Stocker des tokens

Contrairement aux bases de données traditionnelles, les programmes Solana peuvent également stocker des fonds dans un compte, et pas seulement des soldes numériques.

Dans notre exemple, l’événement nécessite un compte de tokens pour sa cagnotte des gains. Le PDA de l’événement sera propriétaire du compte de la cagnotte. Lorsque les utilisateurs placent des paris, ils envoient des tokens vers ce compte. Plus important encore, lorsqu’ils réclament leurs gains, notre programme signe la transaction en tant que compte de l’événement afin de transférer les tokens hors de la cagnotte.

4. Réduire le coût des lectures

Notre programme doit offrir aux utilisateurs la meilleure réactivité possible. En tant que développeurs, nous voulons également éviter de payer inutilement pour des lectures de comptes superflues. Les totaux cumulés et les index peuvent rendre notre programme à la fois plus réactif et plus efficace.

Calculer des totaux cumulés

Lorsque les utilisateurs réclament leurs gains, nous devons connaître précisément le montant parié sur chaque résultat. Les marchés prédictifs calculent le paiement d’un utilisateur gagnant avec la formule cagnotte des gains × montant du pari ÷ total des paris sur le résultat gagnant.

Pour le moment, nous stockons uniquement le montant de chaque pari dans le compte correspondant. Pour obtenir le montant total parié sur un résultat donné, nous devrions lire chaque compte de pari et additionner les montants.

Ajoutons plutôt un champ à chaque résultat — total_amount — et incrémentons-le lorsque les utilisateurs placent des paris. Ainsi, lorsqu’ils gagnent, nous pouvons facilement déterminer le montant du paiement sans devoir lire chaque pari placé sur ce résultat.

Utiliser des index

Nous devons également trouver tous les paris provenant d’un compte utilisateur donné. Nous pourrions récupérer chaque compte de pari avec getProgramAccounts(), puis filtrer ceux dont le parieur correspond à l’adresse de cet utilisateur. Bien que la rapidité de getProgramAccounts() de Helius rende cette opération beaucoup plus rapide que chez d’autres fournisseurs RPC, les index constituent une alternative courante. 

Créons donc un index pour stocker les paris de chaque utilisateur. Lorsqu’un utilisateur place un nouveau pari, nous créons cet élément s’il n’existe pas, puis ajoutons le pari à la liste de ses paris :

Nous ajoutons également des tags à chaque événement afin de pouvoir trouver facilement tous ceux portant les tags « sports », « politics », « europe », « usa », « politics », etc. Nous créons un autre index à cet effet :

Nous pouvons désormais récupérer facilement tous les événements pertinents en consultant le compte associé au tag de l’événement.

5. Réduire la contention en écriture

Vous vous souvenez que chaque événement dispose d’un seul compte de tokens qui stocke les paris correspondants ? Chaque fois qu’un utilisateur ajoute un nouveau pari, des tokens sont transférés vers ce compte. Autrement dit, une écriture est effectuée sur ce compte.

Solana est rapide parce qu’elle parallélise les opérations. Cependant, la mise à jour du solde d’un compte unique ne peut pas être effectuée en parallèle : elle doit être séquentielle, car chaque compte ne peut avoir qu’un seul solde à un instant donné. 

Si un nouvel événement est annoncé et reçoit un grand nombre de paris, de nombreuses écritures sont effectuées simultanément sur le compte de tokens de l’événement, et les transactions de notre programme peuvent sembler lentes. C’est ce que l’on appelle la contention en écriture : plusieurs transactions se disputent l’accès au compte.

Le sharding permet de paralléliser les opérations dans ce type de situation. Une ressource est divisée en plusieurs parties, appelées shards, auxquelles il est possible d’accéder en parallèle.

Fonctionnement du sharding

Les paiements entrants sont envoyés vers des shards win_pool distincts en fonction de la valeur du dernier octet de la clé publique du parieur, à l’aide de la macro shard_num(). Cela garantit la rapidité des paiements entrants.

Une instruction d’administration peut ensuite les regrouper dans un seul compte de cagnotte, afin que nous disposions des liquidités nécessaires sur le même compte pour payer les gagnants.

Nous devons également tenir compte de la contention en écriture si un événement populaire est finalisé et que tous les gagnants réclament leurs gains en même temps. Nous devons aussi transférer les fonds depuis la cagnotte aussi rapidement que possible.

La meilleure solution consiste ici à éviter tout processus de réclamation. Si nous envoyons plutôt les fonds de façon séquentielle dès que l’événement est finalisé, les utilisateurs n’ont pas à subir la lenteur des réclamations : leurs gains sont déjà déposés sur leur compte.

Toutefois, vous devez avoir de vrais utilisateurs avant de vous préoccuper d’une foule de personnes qui parient ou réclament leurs gains. Si vous planifiez votre programme Solana sans l’avoir encore lancé, les optimisations destinées à gérer un volume d’utilisateurs que vous n’avez pas sont inutiles. Si ces optimisations plus importantes ne sont pas nécessaires au lancement, tenez compte de la complexité supplémentaire qu’elles entraînent, tout en gardant à l’esprit que vous devrez peut-être les mettre en œuvre lorsque votre programme gagnera en popularité.

Conclusion

Dans cet article, nous avons exploré en détail la création d’une application réelle sur Solana. Vous disposez désormais de connaissances pratiques pour définir des comptes Solana, établir des relations entre les données, stocker des tokens et optimiser les performances grâce aux index et au sharding. 

Si vous avez d’autres questions, n’hésitez pas à contacter @helius sur X ou à rejoindre le Discord de Helius. Nous approfondirons cet exemple de marché prédictif à l’avenir. Pensez donc à suivre ces comptes pour ne manquer aucune actualité.

Grâce à ces nouvelles compétences, il est temps de transformer vos idées en programmes Solana et de leur donner vie au sein de l’écosystème Solana. Bon développement ! Merci à Ichigo pour sa relecture de cet article et à r0bre pour avoir signalé la technique de sharding des comptes utilisée.

Ressources supplémentaires

• Documentation officielle d’Anchor
• Macro de sharding de Tensor
• Utilisation de la macro de sharding de Tensor