En voyant que les nœuds Dusk prennent en charge les instantanés d’état, on se pose facilement une question : si les instantanés permettent au nœud de restaurer rapidement son fonctionnement, pourquoi certains services doivent-ils quand même maintenir un nœud d’archive ? L’essentiel, c’est que ces deux approches ne résolvent pas le même problème : l’instantané sert à restaurer au plus vite « l’état actuel » du nœud, mais il ne reconstitue pas automatiquement l’ensemble des index historiques passés. En temps normal, cette différence est peu visible ; mais dès qu’on doit consulter de vieilles transactions, faire un audit ou vérifier des données historiques, cela a un impact direct sur l’expérience d’utilisation.
Pensez-y comme quand on change de téléphone. Les contacts, les photos en cours et les réglages courants se restaurent d’abord : le téléphone peut alors être utilisé normalement. En revanche, la recherche intégrale dans les discussions sur plusieurs années ne sera pas automatiquement complétée juste parce que le téléphone fonctionne. L’instantané Dusk restaure l’état actuel de la chaîne : il est adapté pour que les nœuds ordinaires redeviennent rapidement opérationnels. Mais pour les nœuds d’archive qui ont besoin d’historiques complets, les index historiques antérieurs à l’instantané ne sont pas comblés automatiquement. À ce stade, faisons une pause : les anciens blocs ne sont pas « supprimés » ; ce qui manque, c’est l’index historique trié et organisé localement par ce nœud. « Ne pas pouvoir retrouver d’anciennes données » ne revient donc pas directement à dire que « les enregistrements n’existent pas sur la chaîne ».
Pour les utilisateurs de BTC, il est généralement acceptable de considérer que « l’état actuel est utilisable » et « combien d’historique est sauvegardé localement » sont deux choses différentes. Transposé à Dusk, cela influence notamment le navigateur, les services d’audit et les fonctions de remonter dans le temps. Les personnes familières avec l’infrastructure ETH ne seraient pas surprises par les nœuds d’archive, car l’usage en temps réel et la recherche historique sont, de toute façon, des tâches distinctes. Les utilisateurs ordinaires ne perçoivent peut-être pas la différence au quotidien, mais les organismes, services de données et explorateurs de blocs qui dépendent des requêtes historiques y sont beaucoup plus sensibles.
L’enjeu pour les $DUSK utilisateurs ordinaires, c’est que si un service n’a pas temporairement un historique complet, il ne faut pas se précipiter pour l’assimiler à un état de l’actif erroné. Il vaut mieux que les outils liés à @Dusk indiquent séparément : « l’état actuel est synchronisé » et « les index historiques sont complets ». Cela occupe un peu plus d’espace à l’écran, mais permet d’éviter bien des malentendus. À l’avenir, si je dois vraiment m’appuyer sur un navigateur pour conserver un justificatif à long terme, je vérifierai d’abord s’il précise la provenance des données historiques, et pas seulement s’il affiche sur la page d’accueil « nœud synchronisé ».
#dusk
Pensez-y comme quand on change de téléphone. Les contacts, les photos en cours et les réglages courants se restaurent d’abord : le téléphone peut alors être utilisé normalement. En revanche, la recherche intégrale dans les discussions sur plusieurs années ne sera pas automatiquement complétée juste parce que le téléphone fonctionne. L’instantané Dusk restaure l’état actuel de la chaîne : il est adapté pour que les nœuds ordinaires redeviennent rapidement opérationnels. Mais pour les nœuds d’archive qui ont besoin d’historiques complets, les index historiques antérieurs à l’instantané ne sont pas comblés automatiquement. À ce stade, faisons une pause : les anciens blocs ne sont pas « supprimés » ; ce qui manque, c’est l’index historique trié et organisé localement par ce nœud. « Ne pas pouvoir retrouver d’anciennes données » ne revient donc pas directement à dire que « les enregistrements n’existent pas sur la chaîne ».
Pour les utilisateurs de BTC, il est généralement acceptable de considérer que « l’état actuel est utilisable » et « combien d’historique est sauvegardé localement » sont deux choses différentes. Transposé à Dusk, cela influence notamment le navigateur, les services d’audit et les fonctions de remonter dans le temps. Les personnes familières avec l’infrastructure ETH ne seraient pas surprises par les nœuds d’archive, car l’usage en temps réel et la recherche historique sont, de toute façon, des tâches distinctes. Les utilisateurs ordinaires ne perçoivent peut-être pas la différence au quotidien, mais les organismes, services de données et explorateurs de blocs qui dépendent des requêtes historiques y sont beaucoup plus sensibles.
L’enjeu pour les $DUSK utilisateurs ordinaires, c’est que si un service n’a pas temporairement un historique complet, il ne faut pas se précipiter pour l’assimiler à un état de l’actif erroné. Il vaut mieux que les outils liés à @Dusk indiquent séparément : « l’état actuel est synchronisé » et « les index historiques sont complets ». Cela occupe un peu plus d’espace à l’écran, mais permet d’éviter bien des malentendus. À l’avenir, si je dois vraiment m’appuyer sur un navigateur pour conserver un justificatif à long terme, je vérifierai d’abord s’il précise la provenance des données historiques, et pas seulement s’il affiche sur la page d’accueil « nœud synchronisé ».
#dusk