Hier, j’observais les données d’un sous-graph d’un projet, et d’un coup ça s’est figé pendant une demi-minute sans mise à jour. Première réaction : « c’est mort, encore un bug ». En creusant un peu, c’était un plafonnement des requêtes côté RPC : le nœud de l’indexeur s’est fait saturer, littéralement submergé. En clair, les données on-chain ont l’air en temps réel, mais en dessous, tout repose sur des « intermédiaires » centralisés qui encaissent la charge ; quand ils ne tiennent plus, ça cale.

Avant, je suivais un compte spécialisé dans le subgraph : il postait tous les jours des messages du style « données sans délai ». Puis j’ai réalisé que ses graphiques soi-disant « temps réel » étaient en fait des rafraîchissements planifiés, avec un temps de cache bien plus long que ce qu’il prétendait. Je l’ai ensuite unfollow : au final, ça m’a soulagé. Parce que bon, au fond, je sais que les données on-chain ont toujours un peu un « filtre » ; si tu ne considères pas le délai comme un délai, tu ne peux pas saisir les opportunités.

Récemment, l’excitation autour des incitations sur le testnet a encore relancé la spéculation : tout le monde se demande si le mainnet va émettre une monnaie. Honnêtement, pourquoi cette scène me paraît aussi familière ? À chaque fois, on dit « d’abord faire tourner les données, on verra après », mais à chaque fois que les données se figent, c’est la fenêtre pour « prendre une longueur d’avance » qui se referme. J’ai envie de tester, mais finalement je me dis qu’il vaut mieux d’abord vérifier s’il y a un plafonnement côté RPC, histoire de ne pas me faire coincer une fois à l’intérieur, en découvrant trop tard que je suis bloqué sur le 1000e requête. Pour l’instant, on verra. Petit à petit.