Module 3 — Fondations on-chain
Adresse, entité, service et utilisateur
Cent adresses ne signifient pas cent utilisateursSituation réelle
Cent adresses ne signifient pas cent utilisateurs
Une plateforme peut contrôler des millions d’adresses de dépôt, tandis qu’un utilisateur peut créer une nouvelle adresse à chaque paiement. Un smart contract peut recevoir des fonds de milliers de personnes sous une seule adresse. Compter les adresses actives comme des personnes produit donc une mesure sans unité humaine stable.
Le passage d’adresse à entité, service ou utilisateur repose sur des heuristiques, des labels, des sources externes et des choix de périmètre qui doivent être documentés.
Objectifs d’apprentissage
- Ne pas confondre adresses et personnes.
- Comprendre les heuristiques de regroupement.
- Évaluer étiquettes et méthodes entity-adjusted.
- Construire des fourchettes plutôt qu’un faux chiffre précis.
- Limiter la conclusion à ce que les données permettent réellement d’affirmer.
Commencer par la bonne question
Quelle unité est directement observée et quelle unité est estimée par regroupement ou étiquetage, avec quel taux d’erreur connu ?
Une analyse utile commence par cette question avant de chercher une figure, un indicateur ou un paramètre. Elle force à préciser l’unité observée, l’horizon, la chronologie et le type de conclusion attendu. Sans ce cadre, une description a posteriori peut facilement être prise pour une règle prédictive.
Bonnes pratiques
- nommer « adresses actives » et non « utilisateurs actifs » ;
- afficher définition exacte d’actif : envoi, réception ou les deux ;
- distinguer quotidien unique et activité totale ;
- comparer tendance au sein du même fournisseur ;
- utiliser fourchettes et scénarios ;
- dater les labels et signaler leur couverture.
Adresse est une clé ou un identifiant
Elle n’est pas une identité civile et peut être partagée, renouvelée ou contrôlée par un contrat.
Entité est une estimation
Le clustering combine heuristiques de dépense, change, comportement ou labels ; aucune méthode n’est parfaite.
Service et utilisateur diffèrent
Une adresse d’exchange représente une infrastructure et agrège de nombreux clients.
Les labels évoluent
Nouveaux dépôts, migrations, erreurs et corrections rendent les séries révisables.
Méthode pas à pas
- Nommer l’unité brute. Adresse, transaction, output, contrat, événement ou compte.
- Décrire l’heuristique. Règles de regroupement, exclusions et version.
- Attribuer une confiance. Confirmé, probable, possible ou inconnu avec provenance.
- Tester la sensibilité. Comparer adresse brute, entité ajustée et labels conservateurs.
- Versionner. Date des labels, révisions et impact sur l’historique.
Laboratoire guidé
du concept au dossier de preuve
- Écris la fiche avant d’ouvrir le résultat. Reformule la question — « Quelle unité est directement observée et quelle unité est estimée par regroupement ou étiquetage, avec quel taux d’erreur connu ? » — sous forme d’une hypothèse réfutable. Indique la population, l’horizon, l’unité, le benchmark, la date de début et la date de fin. Donne un identifiant à cette version.
- Sépare données et interprétation. Crée une table brute en lecture seule, puis une table de variables dérivées. Pour chaque colonne calculée, conserve formule, paramètres, source, fuseau et premier instant d’utilisation. Une correction de donnée ne doit jamais être confondue avec une amélioration de stratégie.
- Produis un échantillon de contrôle. Utilise une règle plus simple, des dates décalées, une permutation ou un groupe comparable. Le contrôle doit conserver autant que possible fréquence, exposition et régime ; sinon la comparaison attribuerait au signal ce qui vient du marché général.
- Travaille à l’aveugle lorsque c’est possible. Masque la partie future lors de l’annotation et réserve un bloc temporel que tu ne consultes pas pendant la construction. Archive aussi les cas ambigus et les événements qui ne confirment pas le récit.
- Stress les hypothèses, pas seulement les paramètres. Augmente les coûts, retarde l’exécution, réduit la liquidité disponible et change raisonnablement la fenêtre. L’objectif n’est pas de trouver une variante qui réussit, mais de savoir dans quelles conditions la conclusion disparaît.
- Décide avec une règle écrite. Continue seulement si l’effet est mesurable, net de coûts, présent dans plusieurs segments et non concentré sur une valeur isolée. Sinon, classe le résultat « à réviser » ou « à arrêter » et explique précisément pourquoi.
Démonstration chiffrée
Une migration d’exchange qui ressemble à une adoption
Un exchange remplace son architecture de dépôts et crée 500 000 nouvelles adresses en deux semaines. Le nombre d’adresses actives et nouvelles bondit, sans que 500 000 personnes supplémentaires aient nécessairement rejoint le réseau. Un regroupement entity-adjusted peut réduire le saut s’il identifie correctement le service ; une méthode incomplète le laissera dans la série.
La note accompagne donc la hausse d’un indicateur de qualité : part labellisée, révision récente, concentration et comparaison avec transactions économiques estimées.
Interpréter sans surinterpréter
- Faux regroupement. CoinJoin, batching ou comportements communs peuvent fusionner des acteurs distincts.
- Sous-regroupement. Une entité peut répartir ses fonds sur de nombreuses adresses non reliées.
- Label propriétaire. La méthodologie et la couverture peuvent être inaccessibles à l’audit.
- Révision historique. Améliorer un label aujourd’hui peut changer toute la série passée.
La discipline consiste à écrire ces limites avant de consulter le résultat final. Une conclusion négative ou incertaine n’est pas un échec : elle évite de transformer le bruit historique en décision coûteuse.
Lire un résultat qui confirme
ou contredit — l’intuition
Si le résultat paraît confirmer l’idée, commence par rechercher ce qui pourrait l’expliquer autrement : faux regroupement et sous-regroupement constituent ici deux contrôles prioritaires. Vérifie ensuite si l’effet existe encore après coûts, sur des paramètres voisins et sur une période qui n’a guidé aucune décision. Une confirmation qui disparaît dès qu’un détail raisonnable change est une piste d’exploration, pas une base d’action.
Si le résultat contredit l’intuition, ne déplace pas immédiatement le seuil. Vérifie d’abord les données et la chronologie, puis accepte l’hypothèse nulle comme issue possible. Pour « Adresse, entité, service et utilisateur », une absence d’effet peut signifier que le phénomène est descriptif, trop faible face aux coûts, propre à un sous-régime ou simplement absent dans l’échantillon. Chacune de ces explications exige une nouvelle expérience identifiée, jamais une retouche silencieuse.
Exercice
- Choisis une métrique d’adresses et écris précisément son dénominateur.
- Compare version brute et entity-adjusted d’un fournisseur documenté.
- Liste les heuristiques et trois sources de faux positifs/négatifs.
- Mesure l’impact d’une migration fictive d’exchange.
- Crée un registre de labels avec provenance, confiance et date.
Afficher le corrigé détaillé
La correction ne transforme pas une adresse active en utilisateur actif. Elle distingue observation brute, regroupement et attribution. Les différences entre séries sont présentées comme conséquences méthodologiques, pas comme erreur certaine d’un fournisseur. Le registre de labels conserve source, preuve, dernière vérification et niveau de confiance. Une métrique révisée est versionnée afin que l’analyse publiée puisse être reproduite avec la même taxonomie.
Le corrigé décrit une méthode, pas une unique valeur à mémoriser. Si ton résultat diffère, vérifie d’abord les unités, le calendrier, la définition des variables et l’instant où l’information devient disponible ; documente ensuite toute hypothèse alternative.
VÉRIFIER SA COMPRÉHENSION
Quiz corrigé
01Une adresse correspond-elle à une personne ?
Non.
02Qu’est-ce qu’une entité on-chain ?
Un regroupement estimé d’adresses supposées sous contrôle commun.
03Une adresse d’exchange représente-t-elle un utilisateur ?
Souvent non ; elle peut agréger de nombreux clients.
04Pourquoi versionner les labels ?
Parce que corrections et découvertes modifient les séries historiques.
05Une métrique propriétaire est-elle inutilisable ?
Pas nécessairement, mais sa méthodologie et son incertitude doivent être signalées.
À retenir
- Adresse, entité, service et utilisateur sont quatre unités différentes.
- Le clustering est une estimation révisable.
- Les labels ont une provenance et un niveau de confiance.
- Migrations et batching peuvent déformer les comptes bruts.
- Comparer plusieurs méthodologies mesure la sensibilité.
- La version de taxonomie appartient à la donnée.
Sources de référence
Enregistré uniquement dans ce navigateur pour l’aperçu gratuit.