Portefeuilles liés et regroupements

Source maître EN · P09-L06 · 45 minutes estimées · needs_review

Un regroupement peut être un ensemble d’observations, un groupe algorithmique ou une hypothèse de propriété. Employer un mot pour les trois invite une attribution non étayée. Financement commun, temps similaires et utilisation d’une application commune peuvent être de véritables relations sans prouver un propriétaire humain commun.

Cette leçon construit un graphe de preuves, compare des explications et garde visibles les arêtes incertaines. Vous évaluerez les hypothèses selon leur étayage et les tests manquants plutôt que d’attribuer une confiance numérique d’identité sans calibration.

Définir ici le sens du regroupement

Commencer par une règle explicite d’appartenance. « Adresses recevant des fonds natifs de HUB dans la fenêtre W » définit un ensemble cofinancé reproductible. « Adresses contrôlées par une personne » est une hypothèse plus forte nécessitant des preuves indépendantes de contrôle.

Nommer l’ensemble selon sa règle. Une cohorte cofinancée peut servir à poursuivre l’inspection sans être un regroupement de propriété. Si la méthode de regroupement d’un fournisseur n’est pas divulguée, conserver son résultat comme affirmation de fournisseur au mécanisme inconnu.

Le graphe doit séparer nœuds du registre et nœuds d’entité. Adresses, programmes et comptes de jetons sont des objets inspectables. Un nœud humain ou organisationnel nécessite un étayage distinct. Ne pas le créer seulement pour simplifier le diagramme.

Utiliser des arêtes typées et sourcées

Chaque arête nécessite réseau, source, cible, type, actif/montant si pertinent, repère d’événement, contexte, résultat et couverture. « Lié » est trop vague. Transfert natif, champ d’autorité partagé, dérivation de programme et appel à une même application répondent à des questions différentes.

Les structures de résultat Solana distinguent instructions, signataires et soldes [S09-STRUCTURES]. Elles fournissent des champs de mécanisme pour inspecter les arêtes, pas une identité humaine intégrée. Une recherche de signatures découvre seulement l’activité référençant l’adresse dans son périmètre [S09-SIGNATURES].

Pour les nœuds médiés par programme, distinguer dérivation et propriété. Les PDA utilisent la signature par programme plutôt qu’une clé privée [S09-PDA]. Un programme partagé peut traiter de nombreux utilisateurs indépendants ; dériver plusieurs adresses d’un programme ne fusionne donc pas leurs bénéficiaires en soi.

Séparer observations et hypothèses

Dessiner les arêtes de mouvement réussies fournies en traits pleins. Dessiner les liens de contrôle hypothétiques en pointillés avec une explication. Une arête possible indisponible doit être marquée inconnue, pas dessinée comme mesurée.

Le cofinancement observé étaye une relation. Il peut être compatible avec contrôle commun, retraits d’une garde partagée, distribution publique, paie ou autre service commun. Toutes ces alternatives ne sont pas prouvées ; elles montrent que l’observation ne détermine pas uniquement la propriété.

Un transfert entre membres peut renforcer une question de coordination sans identifier un contrôleur humain. Paiement commercial, remboursement ou routage de service peuvent aussi relier des adresses indépendantes. Tester le mécanisme au lieu de compter les flèches comme votes d’identité.

Éviter l’inflation de preuves dépendantes

« Même minute », « rapprochés » et « même lot visible » peuvent être trois descriptions d’une caractéristique temporelle. Ne pas les compter comme confirmations indépendantes. Financement commun et temps liés à la même source peuvent aussi partager une opération sous-jacente.

Une étiquette de fournisseur et une étiquette d’interface copiée de ce fournisseur sont dépendantes. Deux affichages ne doublent pas la preuve d’identité. Un rapport doit grouper ces affirmations par source amont.

Ce jeu ne justifie aucun seuil fixe tel que « trois indices signifient même propriétaire ». Un modèle calibré nécessiterait cible définie, vérité de référence représentative et analyse d’erreurs. La leçon utilise plutôt des états qualitatifs explicites et des demandes de preuve falsifiables.

Comparer équitablement les explications concurrentes

Écrire les prédictions de chaque explication et ce qui les distinguerait. Le contrôle commun pourrait prédire des preuves d’autorisation partagée ou une gestion coordonnée, mais une activité publique partagée n’est pas exclusive. La distribution par service pourrait prédire de nombreux destinataires aux comportements ultérieurs différents, mais un graphe partiel n’établit pas cette population élargie.

Chercher des preuves qui pourraient affaiblir l’interprétation préférée, pas seulement des exemples compatibles. L’absence de preuve contraire dans un export incomplet n’est pas une confirmation. Si aucun enregistrement fourni ne distingue les hypothèses, les rapporter comme non résolues.

Un constat valide peut être « le jeu étaye une cohorte cofinancée ; la propriété humaine est insuffisamment étayée ». C’est un résultat d’analyse, pas un échec de la tâche. Il indique précisément où l’investigation pourrait progresser.

Préserver les limites du graphe et des quantités

Un transfert interne à la cohorte déplace l’inventaire entre nœuds sans ajouter de financement externe. Additionner toutes les arêtes mesure le mouvement brut, pas l’entrée externe ou les soldes détenus. Réconcilier dans une frontière déclarée.

Si HUB envoie 10 à chacun des trois membres et qu’un membre envoie ensuite 2 à un autre, le financement externe est 30. Le volume brut des arêtes de transfert incluant le transfert interne est 32. L’inventaire de la cohorte reste30 dans le modèle fermé sans frais. Ces statistiques ont des noms différents et ne sont pas interchangeables.

Ne pas fusionner des vues dupliquées d’un événement. Garder les repères d’événement de P09-L02. Une arête d’appel n’a pas de quantité sauf effet de valeur distinct fourni. Les appels d’application de cet exercice ne portent aucun montant natif supplémentaire.

Rapporter les relations sans attribution publique d’identité

Garder étiquettes de fournisseur, hypothèses de contrôle et transferts observés dans des sections différentes. Employer des identifiants neutres partout. Statut commercial, richesse apparente et popularité ne peuvent élever un état de preuve.

Aucun graphe n’autorise signal de trading ou accusation publique. Ne pas identifier une personne réelle à partir de chemins de financement ni déduire une intention d’une activité paraissant coordonnée. L’objectif pédagogique est un graphe auditable avec alternatives, couverture et prochaines vérifications.

• Cohorte : ensemble sélectionné par une règle d’observation divulguée.
• Hypothèse de propriété : contrôle partagé proposé nécessitant des preuves distinctes.
• Arête typée : relation avec mécanisme explicite.
• Indice dépendant : preuve décrivant la même observation sous-jacente.
• Entrée externe : mouvement entrant à travers la frontière choisie.
• Preuve discriminante : enregistrement distinguant les explications concurrentes.

ILLUSTRATIVE — FIX-P09-06. SIM-CHAIN-A, T1–T5 synthétiques. Soldes natifs initiaux0 pour W1/W2/W3. Effets natifs listés complets ; frais et autres effets sont0. Règle de cohorte : reçoit 10 de HUB pendant T1–T3.

T1–T5 établissent seulement un ordre synthétique, pas des secondes réelles. Aucune signature prouvant une autorité partagée, provenance de paie authentifiée ou identité humaine n’est fournie. H1=contrôleur commun ; H2=service partagé/distributeur public avec destinataires indépendants.

OBSERVED dans le jeu : W1/W2/W3 partagent une source immédiate de financement ; W1/W2 interagissent aussi avec APP ; un mouvement interne de2 unités survient.

INFERRED : les trois satisfont la règle de cofinancement. Entrée externe 30, flux interne2 et solde final de cohorte 30 selon les hypothèses du modèle.

UNKNOWN : propriété humaine, affiliation de paie, ensemble élargi des destinataires de HUB et sémantique d’autorisation de APP.

INSUFFICIENT EVIDENCE : ni H1 ni H2 n’est établi de manière unique. Financement égal et ordre synthétique rapproché ne prouvent pas un contrôle commun ; L1 n’authentifie pas l’identité de paie.

Renommer un ensemble cofinancé comme propriétaire unique ; compter des descriptions temporelles comme indices indépendants ; dessiner des arêtes supposées en plein ; ajouter le mouvement interne au financement externe ; adopter une étiquette de service pour trancher une hypothèse.

Construire le graphe typé et calculer soldes finaux des membres, entrée externe et volume brut des arêtes natives. Comparer H1/H2 avec étayage fourni et une prochaine vérification pour chacun. Dire si un regroupement de propriété humaine peut être présenté comme prouvé.

• Publier une règle d’appartenance.
• Typer et sourcer chaque arête.
• Séparer relations mesurées et hypothèses de contrôle.
• Grouper les indices dépendants par mécanisme.
• Réconcilier flux franchissant la frontière et flux internes.
• Tester les alternatives et préserver l’attribution non résolue.

Un graphe de regroupement utile peut établir des relations en laissant la propriété non résolue. Tester des hypothèses nécessite des preuves distinguant les explications.

Financement commun n’est pas propriété commune. Plusieurs étiquettes temporelles peuvent former un seul indice. Un mouvement interne modifie l’allocation, pas le financement externe de la cohorte.

Graphe HUB→W1/W2/W3 avec quantités10 et W1→W2 avec quantité2 ; arêtes d’appel APP distinctes et valeur0. Arêtes observées pleines, possibilités de contrôle/service H1/H2 en pointillés. Montrer soldes finaux8/12/10, externe30 et brut 32 avec étiquettes séparées ; L1 non vérifié.

Cohorte cofinancée illustrative ; la propriété reste non résolue.

Utiliser du SVG/HTML déterministe ou des graphiques avec unités, repères de preuve et alternatives textuelles. Bleu marine/noir avec touches discrètes de cyan, bleu électrique et violet ; aucune capture d’explorateur décorative ou fabriquée. À 390px, empiler les annotations ; vérifier 768px, l’ordinateur et le RTL arabe lorsque les actifs seront réalisés. Conserver les identifiants LTR et les sens factuels du temps/des arêtes/des axes. Utiliser uniquement la marque officielle BlockAssay fournie. Les deux enregistrements visuels restent des spécifications.

WALLET_INTELLIGENCE correspond à l’inspection en lecture seule des enregistrements d’adresses publiques, des relations et de leur provenance. Vérifier le réseau pris en charge, les identifiants exacts, les champs et la couverture avant toute intégration à l’exécution ; aucune capacité de fournisseur en direct n’est revendiquée ici. Utiliser l’exercice hors ligne intégré si les données ou l’accès payant sont indisponibles. Aucune connexion de portefeuille, aucun identifiant de connexion, aucune clé privée, signature ou transaction de marché réelle n’est requis. Les données manquantes restent inconnues. La progression Academy, le statut de créateur, les paiements et les parrainages ne modifient jamais les preuves Radar.

• Structures JSON du RPC Solana — Métadonnées de résultat, frais, instructions et soldes comme vues distinctes. Vérifié le 2026-09-30.
• Solana getSignaturesForAddress — Historique des signatures référençant l’adresse, ordre du plus récent au plus ancien et pagination. Vérifié le 2026-09-30.
• Adresses Solana dérivées de programme — Adresses dérivées de programme et signature par programme ; aucune clé privée de PDA. Vérifié le 2026-09-30.

Tous les enregistrements d’exemple sont des jeux originaux ILLUSTRATIVE, pas des mesures historiques/en direct de la chaîne. La documentation explique les mécanismes, pas les montants ou étiquettes inventés. La chronologie synthétique est explicitement délimitée ; observedAt=null est intentionnel. OBSERVED dans un exercice désigne un enregistrement du jeu fourni. Réexaminer la documentation et le décodage déployé avant publication. Les étiquettes de fournisseur n’établissent pas l’identité ; le contrôle d’une adresse et l’attribution humaine nécessitent des preuves distinctes.

P09-L07 après l’exercice corrigé et la révision des questions.