Je joue rarement aux contrats, et en ce moment j’apprends petit à petit comment ça marche. Je n’arrive vraiment pas à comprendre ce multiplicateur : j’en ai mis à 50x, et ça a baissé de cinq “niveaux”… pourquoi je n’ai gagné qu’un peu plus d’un dollar ? Je suis vraiment perdu. En revanche, le spot est plus facile à comprendre : j’achète et si ça monte de dix points, alors ça fait dix pour cent. Je sens que SanDisk va remonter ces jours-ci, le marché revient petit à petit ! #TradFi晒单
Abordons le nœud Babylon : beaucoup de gens pensent qu’il faut forcément une instance de nœud Bitcoin full (nœud complet) pour faire tourner un Vigilante (sentinelle), sinon on ne peut pas bien s’en sortir. C’est aussi ce que je pensais au début. Puis j’ai relu la documentation officielle et j’ai découvert que la couche “sentinelle” peut en fait fonctionner en mode client léger : on économise de l’espace disque, mais le pouvoir d’auto-vérification est un peu réduit.
Le module de client léger BTC de Babylon ne stocke pas les blocs complets : il ne synchronise que la chaîne des en-têtes (headers). Le client léger s’appuie sur la vérification SPV (Simplified Payment Verification) pour contrôler les branches Merkle. Il peut ainsi confirmer la hauteur actuelle du réseau principal et vérifier que la chaîne d’en-têtes est continue. La sentinelle fait deux choses : d’une part surveiller s’il existe un bloc avec conflit de double signature de la part d’un Finality Provider ; si une mauvaise conduite est détectée, elle reconstruit les deux signatures d’EOTS, récupère la clé privée, puis diffuse la transaction de pénalité. La récupération de clé privée repose sur un calcul purement cryptographique : elle ne dépend pas de l’historique d’un nœud complet, donc un client léger peut aussi le faire. En revanche, il ne peut pas vérifier de façon autonome qu’un certain UTXO a vraiment été verrouillé dans le script Babylon — pour cela, il faut la coopération d’un nœud complet ou d’un indexeur. Le client léger ne fait confiance qu’à la chaîne d’en-têtes.
Dans la section d’installation de Vigilante, la documentation officielle exige : “un nœud Bitcoin full synchronisé”. Mais en pratique, en faisant tourner le script de la sentinelle avec Bitcoin Core en mode léger (prune=1) et en passant les tests, tout s’est bien déroulé. Après avoir verrouillé 0,05 BTC en testnet, la sentinelle a signalé une fois FP skip de signature, mais n’a pas raté.
Si le réseau principal connaît un profond reorg (>>6 blocs), le client léger peut, temporairement, mal interpréter la position du timestamp ; le nœud complet le détecterait d’abord. Le client léger permet d’économiser le disque (environ 80 Mo/an), mais en échange, si la source des headers est contaminée, il peut être entraîné sur une mauvaise piste. Pour une sentinelle personnelle, le client léger suffit, à condition de faire confiance à la source de headers que l’on choisit. Les profils plus paranoïaques qui lancent un nœud complet avec un indexeur peuvent tout vérifier eux-mêmes.
Les deux approches ne s’excluent pas : c’est un arbitrage entre le coût et le niveau d’auto-hébergement. #baby $BABY @BabylonLabs_io