Services de programme

Certaines choses qu’une plateforme doit savoir d’un compte ne peuvent pas être calculées pendant l’exécution d’un bloc. Un palier de volume dépend de trente jours de trading. Une récompense dépend d’une fenêtre qui n’est pas encore close. Une attribution de parrainage dépend d’une relation établie il y a des mois. Placer ce travail à l’intérieur de l’exécution de bloc serait doublement faux : cela ferait payer à chaque bloc un calcul dont presque aucun bloc n’a besoin, et cela obligerait le noyau à porter un historique qu’il n’a aucune autre raison de détenir. Les services de programme résolvent le problème en inversant le sens. Le calcul s’exécute en dehors du bloc, sur l’historique entériné. Son résultat est ensuite réinscrit sur la chaîne comme état de protocole, où l’exécution peut le lire en temps constant, comme n’importe quelle autre configuration. La chaîne reste l’autorité. Un service ne détient pas d’état dont le réseau dépend — il propose une valeur, et seul ce que la chaîne a accepté est réel.

​

Ce qui tourne aujourd’hui

Paliers de frais par volume. Le service consomme l’historique de trading diffusé par un nœud, accumule le volume par compte et en prend un instantané à intervalles réguliers. À la clôture d’une période, il calcule le volume de chaque compte sur la fenêtre glissante, le fait passer par la configuration des frais lue en direct sur la chaîne, et réinscrit par lots les comptes dont la valeur a changé. Plusieurs détails de cette phrase sont structurants :

• La table des paliers est lue sur la chaîne, jamais codée en dur. Un service qui garderait sa propre copie continuerait d’appliquer la grille d’hier après que le réseau l’a changée.
• La comparaison porte sur les taux, pas sur les indices de palier. Comparer les indices de palier laisse passer deux cas bien réels : un seuil qui bouge, de sorte qu’un compte inchangé se retrouve dans un autre palier, et un palier dont le tarif change alors que son indice reste le même. Les deux modifient ce qu’un compte paie ; ni l’un ni l’autre ne modifie son indice.
• La chaîne résout le taux final. La transaction porte un indice de palier ; l’exécution le résout à partir de la configuration des frais en vigueur. Un indice de palier hors de la plage valide fait échouer le lot entier plutôt que de s’appliquer partiellement.
• Une période n’est enregistrée comme appliquée qu’une fois tous les lots entérinés. Un crash en milieu de période rejoue la période entière, ce qui est sans danger puisque le calcul est idempotent — la même fenêtre produit le même résultat.

​

Le modèle de défaillance

Ces services se situent entre deux systèmes qui seront chacun indisponibles de temps à autre. La conception le suppose plutôt que de le traiter comme exceptionnel. Les défaillances de dépendances — la base de données, le flux du nœud, l’API du nœud — font l’objet de nouvelles tentatives avec temporisation croissante. Elles ne mettent pas fin au processus, parce qu’un redémarrage ne répare pas une dépendance injoignable ; il ajoute simplement un démarrage à froid à la panne. Ce qui reste fatal, c’est ce qu’un redémarrage peut réparer ou ce qu’un opérateur doit voir : une configuration invalide au démarrage, l’impossibilité d’ouvrir l’endpoint de santé, et les panics. Pendant une panne, le processus reste actif, se déclare non prêt et compte les erreurs. Le signal opérationnel est donc « ce service est-il non prêt depuis N minutes » plutôt que « le processus est-il vivant » — ce qui est la question utile, puisque l’incident réel, c’est un processus vivant qui n’ingère plus rien depuis une heure. L’arrêt est gracieux sur les signaux qu’envoie un orchestrateur : le travail s’arrête, les points de reprise sont écrits, et le processus se termine proprement. Sans cela, chaque déploiement de routine coûterait une fenêtre non écrite et un rejeu.

​

Pourquoi le motif se généralise

Le chemin de réinscription est générique. Des transactions de protocole existent pour définir la configuration au niveau d’un compte et pour définir la configuration globale, et un service de programme est n’importe quel processus qui calcule une valeur pour l’une d’elles à partir de l’historique entériné. Les paliers de frais sont le seul service en fonctionnement. Les programmes d’incitation, l’attribution de parrainage et l’éligibilité aux campagnes auraient la même forme : un calcul sur fenêtre au-dessus de l’historique de trading, une comparaison avec ce qui est actuellement appliqué, et une réinscription par lots. Ils auraient leur place ici plutôt que dans le noyau, pour la même raison que les paliers de frais — le calcul est périodique et historique, alors que l’exécution a besoin que la réponse soit une consultation en temps constant. Aucun n’est construit ; ce qui se généralise, c’est le motif, pas l’engagement qu’ils l’utiliseront. Les conditions commerciales de ces programmes se trouvent dans Frais et programmes. Cette page porte sur la façon dont le résultat arrive sur la chaîne.

​

Pour aller plus loin