54 – Créer un DP sur Songbird/Flare

          Ceux qui me suivent depuis le départ reconnaîtront peut-être l’image, c’était celle d’un de mes premiers articles. Ce sentiment d’avoir un long chemin à parcourir pour s’initier aux cryptomonnaies. Concepts, vocabulaire, investissement… Autant de notions qu’il vaut mieux acquérir avant de cliquer pour la première fois sur le bouton « Buy ».
          Et bien c’est exactement ce que j’ai ressenti quand je me suis décidé début septembre à lancer un Data Provider. Je suis dans l’IT depuis 25 ans, je fais un peu de scripting en Powershell à mes heures, je ne suis donc pas un novice, mais je n’avais jamais utilisé Java, Javascript, Python ni interagi avec une quelconque blockchain auparavant et il me semblait alors y avoir un sacré gap technique entre l’endroit où je me trouvais et celui où je souhaitais me rendre. Sans compter le TDE, prévu alors début novembre, qui approchait à grands pas et donc cette pression temporelle qui n’arrangeait rien.

          3 mois donc. C’est le temps qu’il m’aura fallu en partant de rien, et encore, je ne suis pas listé partout. Car au-delà du défi technique, il y aussi un process à respecter, des bonnes pratiques à mettre en oeuvre, les bonnes personnes à contacter, etc. Heureusement Mouradski, qui s’occupe du DP des Grungies m’a aidé à soumettre mes premiers prix au FTSO grâce au code fourni par Flare et j’ai pu partir d’une solution à la précision certes discutable mais directement fonctionnelle. Merci encore Mourad  Et Tom T bien sûr, le Community Manager de Flare.

          Pour ceux qui se demandent de quoi je parle, je remets rapidement le contexte. Flare souhaite, au travers du FTSO (Flare Time Series Oracle), mettre à disposition de tous, et notamment de toute dApp, une source fiable et décentralisée des prix d’un maximum de tokens. Pour ce faire, des « Data Providers » fournissent un prix pour disons le BTC qu’ils calculent à partir de différentes sources puis soumettent au FTSO.  Sans rentrer dans les détails du calcul, le FTSO retire alors les prix les plus élevés, les plus faibles, fais une moyenne des autres et établit ce que l’on appelle la « reward band ». La médiane, soit le milieu de cette zone est le prix indiqué par le FTSO pour ce token. Le FTSO est donc un tableau d’affichage des prix si vous préférez, un peu comme un tableau d’affichage des horaires des trains dans une gare, à la disposition de tous. Un Data Provider de son côté est donc un programme qui tourne en boucle, et qui va donner toutes les 3 minutes, à chaque « epoch » (rien à voir avec les epochs de délégations qui elles durent une semaine), au FTSO son estimation des prix des tokens listés.

          Ainsi chaque Data Provider dispose de son propre programme, son propre algorithme, sa « secret sauce » pour calculer ses prix. Par exemple, il récupère le prix du BTC en USD, USDT et BUSD sur Binance, Coinbase, Kucoin, convertit de préférence les prix en USD, additionne le tout et divise le résultat par le nombre de prix. Il obtient alors une moyenne qu’il va soumettre au FTSO. Une bête moyenne n’est qu’un exemple et est très loin d’être suffisante pour être efficace.

          Les Data Providers qui auront fourni un prix se situant dans la zone grise, dans la reward band, sont finalement récompensés en SGB. Ici on peut voir par exemple que le Data Provider dont l’adresse commence par 0xf12f09 (CFN ) a soumis le prix de $0.34883 pour XRP lors de l’epoch 76719 sur Flare. Or la borne basse était de 0.3487 et la borne haute de 0.34882. Il est donc au-dessus, perdu! Pas de récompense pour XRP sur cette epoch. A noter qu’il n’y a pas de récompense sur Flare pour le moment dans la mesure où le TDE n’a pas encore eu lieu.
          Est-ce que le prix soumis était objectivement « mauvais » ? Je ne le pense pas mais que voulez-vous, il faut bien une limite.

          Plus le Vote Power (VP) d’un Data Provider est élevé, plus il récupère de récompense lorsque son prix fourni est dans la reward band. Le VP qui était limité à 10% sur Songbird va lors cette semaine être changé à 2.5%, comme ce sera le cas dès le lancement sur Flare. Pour rappel le VP est le pourcentage de WSGB délégué à un Data Provider sur le nombre total de WSGB délégués. Le site le plus connu pour observer ces statistiques reste sans conteste FlareMetrics mais celui d’Ivy Oracle est également excellent, de même que Songbird Monitor ou Flare Monitor.

          Le contexte étant posé, revenons à nos moutons. Monter un Data Provider.
          La première chose à faire va être de créer un « observation » node. Un node est une porte d’entrée permettant d’interagir avec la blockchain. Chaque node dispose d’une adresse RPC que l’on doit renseigner dans nos chers wallets lorsque l’on déclare un réseau, ici Songbird. Il en existe des publics que vous utilisez chaque semaine, le plus connu étant probablement celui de towolabs : https://songbird.towolabs.com/ext/bc/C/rpc

          Si parfois vous trouvez que votre application est lente, que vos transactions sont refusées ou autres, c’est peut-être que le RPC que vous utilisez à un problème ou est surchargé. Il est alors intéressant d’en essayer un autre pour confirmer le diagnostic. En voici quelques-uns que j’ai noté mais il en existe évidemment beaucoup d’autres :
     https://rpc.sgbftso.com/http
     https://sgb.ftso.com.au/ext/bc/C/rpc
     https://songbird.towolabs.com/ext/bc/C/rpc
     https://sgb.lightft.so/rpc

          Un premier obstacle donc lorsque l’on veut créer un Data Provider est que l’utilisation d’un RPC public est à proscrire. Vous devez être en mesure de soumettre vos prix toutes les 3 minutes car ne pas le faire équivaut à faire une croix sur les rewards de l’epoch concernée. D’autre part cela ne respecte pas les bonnes pratiques.

Mais comment on crée un node Songbird ?!

          Il vous faut un serveur avec certaines spécifications en terme de CPU, RAM, Stockage, etc. Y installer Ubuntu 20.04, certains packages bien choisis, cloner le repository de Flare et lancer l’exécution du programme. Tous les prérequis sont disponible sur le github : https://github.com/flare-foundation/go-songbird

Tim Rowley a également publié un tutorial video pour le déploiement d’un node Songbird. Evidemment c’était juste après que j’ai fini le mien
De façon plus globale, sa chaîne Youtube comporte des vidéos très intéressantes pour ceux qui souhaitent se lancer.

https://www.youtube.com/watch?v=SJaIP52W-ns

Facile ! N’importe qui peut le faire alors !

          Oui et non. Effectivement ces étapes sont assez simples même si configurer les clés privées de synchronisation d’un repository Github sur un OS Linux n’est peut-être pas simple pour quelqu’un qui ne l’a jamais fait auparavant haha. Mais dès lors que l’on parle serveur il faut aussi penser sécurité, backup, redondance, monitoring et automatisation d’un maximum de tâches, surtout en environnement de production. Pour le coup nous sommes ici dans mon cœur de métier.

• Sécuriser un environnement consiste entre autres à déployer un firewall, bloquer tout le trafic et n’autoriser que le nécessaire et suffisant. Iptables est efficace mais pas très user friendly. Ubuntu inclut ufw qui fonctionne très bien et est plus simple à utiliser.
• Le backup n’a pas trop de sens ici car le système de fichier évolue très peu contrairement à un serveur de fichiers par exemple. Une fois lancé, hormis la première phase de synchronisation qui est particulièrement longue, le node se synchronise en temps réel. En cas de problème majeur il me semble donc plus sain de repartir de 0, réinstaller le système, les paquets qui doivent l’être et relancer la synchro. Il existe des outils d’automatisation formidables pour cela comme Ansible. 
• La redondance est très importante. En ayant deux nodes vous pouvez faire à la fois du load balancing et du failover, suivant que votre cluster soit en actif/actif ou actif/passif. Chaque node va disposer de sa propre adresse IP et vous allez créer une IP dîte virtuelle qui enverra vos requêtes sur un node suivant la disponibilité de chacun. Cela vous permet également d’avoir beaucoup de souplesse lors de la mise à jour de vos systèmes car vous pouvez en mettre un à jour sans interruption de service. Une fois le premier de nouveau opérationnel il vous suffit de faire la même chose avec le second.
• Le monitoring est indispensable. On y pense pas tant que ça marche. Au départ on a les yeux rivés sur le système pour s’assurer que tout fonctionne et plus le temps passe moins on y va jusqu’au jour ou quelque chose ne fonctionne plus et que l’on ne s’en aperçoive pas. Résultat, vous ne pourrez plus soumettre de prix, vos transactions seront « reverted » ce qui va vous coûter très cher, vous n’êtes plus éligibles aux récompenses, bref, la catastrophe. Il existe donc des outils de monitoring qui vont surveiller vos systèmes de façon à être alerté en cas de problème, par SMS ou par mail, voire même une notification push sur votre smartphone. Taux d’utilisation du CPU, consommation de la RAM, espace disque disponible, disponibilité des services, etc. J’ai un faible pour Centreon avec son interface graphique agréable mais c’est très subjectif. Cela impliquera d’ouvrir des ports sur les serveurs monitorés, d’installer de nouveaux packages, etc.

          Alors admettons que vous en soyez là. Vous avez un cluster de deux nodes Songbird actif/actif fraîchement déployés en suivant les préconisations de Flare, disposant d’une adresse IP publique virtuelle et le tout monitoré par un serveur tiers avec Centreon, bref, au top. Et bien vous devrez encore faire whitelister les adresses IP publiques de vos deux nodes auprès de Tom T avant de pouvoir lancer leur synchronisation avec la blockchain et en parlant de synchronisation vous devrez faire le choix entre des nodes en mode « pruning » ou « full history ». En mode « pruning » votre node aura un historique d’environ une semaine de transactions sur la blockchain mais le stockage nécessaire sera disons raisonnable. En mode full history par contre il vous faudra plus de stockage et le stockage requis ne fera que grandir dans le temps. SSD le stockage, évidemment

          Alors admettons que vos deux nodes soient maintenant synchronisés après une semaine, vous disposez maintenant d’un RPC privé à renseigner dans vos wallets ! Mais toujours pas de Data Provider. Pour cela il vous faudra un serveur supplémentaire. Comme pour les nodes, vous aurez quelques pré-requis à respecter, packages à installer mais ils sont sympa chez Flare et vous fournissent un algorithme fonctionnel en node.js qui va vous permettre de soumettre des prix rapidement. https://github.com/flare-foundation/FTSO-price-provider. Qui dit nouveau serveur dit sécurisation, backup, redondance éventuelle, monitoring, etc. Là encore vous devrez pour le moment faire whitelister votre adresse IP publique. A noter que pour soumettre vous devrez également disposer d’un minimum de délégations. Au démarrage, CFN devait avoir 80 ou 90k et ça n’était pas suffisant, je pense que l’on doit être autour de 200k WSGB délégués aujourd’hui pour être éligible.

          Vient maintenant le temps des listings. Towolabs, FlareMetrics, etc. autant de dApps pour lesquelles vous aurez une action à faire pour que votre Data Provider puisse être listé sans quoi vous ne serez qu’une adresse dans une liste, sans nom ni logo, ou n’apparaîtrez tout simplement pas.

          Autant la première partie n’a pas été si compliquée que ça pour moi étant plus ou moins mon coeur de métier, autant le reste a été un défi. Il m’a fallu un mois environ pour arriver à ce stade. Aucune connaissance en Node.js ou python, ou en programmes en mode « service », peu en language objet de façon générale en dehors de Powershell, beaucoup plus à l’aise sur Windows que Linux, et me voilà à ouvrir le code du DP de Flare dans Visual Studio Code pour commencer à essayer de comprendre comment ça fonctionne là dedans.
          Hors de question de demander de l’aide pour l’algorithme, notamment en raison de la collusion de certains Data Providers et de tous les problèmes que cela avait engendré. Mais il faut bien admettre que jusque-là faire tourner le DP avait plus été un hobby certes enrichissant d’un point de vue connaissances mais surtout coûteux ! Avec mes 150k de WSGB délégués je gagnais environ 50 WSGB par semaine, donc 200 par mois et vu le prix du SGB on était loin de rembourser les coûts de fonctionnement des serveurs

          Lorsque vous atteignez le stade de l’algorithme, vous êtes au cœur de Flare. C’est entre autres votre algorithme qui va contribuer aux prix rendus disponibles par le FTSO. Alors que faire ? Essayer de soumettre des prix les plus « vrais » possibles, ou bien essayer d’atteindre la « reward band » ? Pour être tout à fait honnête j’ai choisi de viser la bande de reward jusqu’à temps de devenir « rentable » car bien souvent, il n’y a pas ou plus de « band ». La borne basse est égale à la bande haute et donc à la médiane. Soit vous soumettez le prix calculé par les autres DPs, soit vous ne gagnez rien. On est là à la 6e décimale.s

          Comment en sommes-nous arrivés là ? Je ne reviendrai pas sur les détails car cela a déjà été adressé à de multiples reprises mais cela vient entre grande partie du fait que plusieurs DP qui concentrent une grande partie du VP utilisent le même algorithme ou presque. Or, plus un Data Provider a de VP, plus les prix qu’il soumet influent sur le calcul des prix du FTSO. Les plus gros Data Providers soumettant à peu près les mêmes prix, la reward band se rétrécit et il devient extrêmement difficile pour ceux qui ne disposent pas de cet algorithme de toucher la reward band et donc d’être rentables. 
          Le risque est important car cela veut aussi dire d’une part qu’une minorité dispose de beaucoup de pouvoir et pourraient manipuler les prix d’une certaine façon mais aussi que les petits Data Providers, comme moi par exemple, peuvent difficilement être rentables et donc peuvent tout simplement décider d’arrêter leurs Data Providers, ce qui va à l’encontre de la décentralisation tant nécessaire à l’écosystème.

          Heureusement ce problème est en train d’être adressé par l’équipe de Flare, la première réponse étant le passage du vote power maximum de 10 à 2.5% mais d’autres mesures qui n’ont pas encore été rendues publiques ont été évoquées et ont de bonnes chances d’être implémentées.

Et comment tu « vises » la reward band ?

          Un secret bien gardé par chacun des Data Providers et c’est très bien ainsi. Si vous vous lancez dans l’aventure, à vous de faire fonctionner vos neurones mais dîtes vous bien que toutes les pratiques, en dehors du partage de l’algorithme bien sûr, sont autorisées et que certains ont des moyens : Machine learning, Deep learning, intelligence artificielle… Alors le défi est rude pour monter dans le classement des DP, gagner en visibilité et commencer à profiter de délégations spontanées des citoyens de Flare. Heureusement certains gros Data Providers jouent le jeu et soutiennent l’écosystème en reversant une partie de leurs fees ou en déléguant eux-mêmes à de plus petits Data Providers. Big up à Flare Oracle et Nortso pour ne citer qu’eux
          Un peu d’auto-promo en passant, CFN reverse 25% des fees du Data Provider aux holders du NFT CFN-King qui ont obtenu leur rôle sur le Discord CFN

          Une fois que vous aurez fait tout ça, vous n’aurez plus qu’à refaire la même chose sur Flare. Facile !

          Notons que les Data Providers qui ont activement soumis sur Songbird et sur Flare pendant les mois de novembre et décembre et qui auront effectué un KYC auprès de Flare vont pouvoir bénéficier d’un « Grant ». Ces informations sont publiques et disponibles à tous sur le Discord de Flare ici et là. Cela consiste en 2 x 140k FLR qui vont être versés au TDE à chaque Data Provider.
          Cela va également leur permettre, s’ils le souhaitent, de lancer un Validator sur Flare, ce que je compte bien faire ! ! https://discord.com/channels/743422808499028049/834719894079275008/1059153237468520579
          Vendre les grant ne sera pas une option à court terme, ou un pari risqué, car les validators basculeront sur un mode de stacking au bout de quelques mois et ceux qui n’auront pas suffisamment de FLR seront tout simplement exclus du cercle des Validators.

          Tout ça pour dire que l’aventure ne fait que commencer sur Flare avec le TDE. Je suis très content aujourd’hui d’avoir sauté le pas. Evidemment pour ceux qui se lanceront maintenant il n’y aura pas de grant ou de whitelist pour un validator mais cela reste très enrichissant tant au niveau des connaissances qu’au niveau de la compréhension de l’écosystème en lui-même. Si vous avez des questions n’hésitez pas à rejoindre le Discord CFN et à venir les poser, je serai ravi de vous renseigner du mieux que je pourrais. Il est certes d’abord destiné aux francophones mais reste ouvert à tous
          En comprenant maintenant les mécaniques du FTSO, la criticité d’avoir beaucoup de Data Providers et de promouvoir la décentralisation, il appartient à chacun de déléguer comme il le souhaite. Je ne me fais pas d’illusions, 99% iront au plus offrant, mais si quelques-un d’entre vous font l’effort de déléguer une partie de leur wallet en dehors du top10, ce sera déjà une petite victoire 💪

          Enfin, je me réjouis que Songbird soit passé par là d’abord. Cela a permis à tout un écosystème de dApps et d’outils de voir le jour et qui seront directement disponibles sur Flare au lancement. Vous pouvez en retrouver une partie sur flare.builders notamment.

Vivement la suite