Anatomie einer Wallet

EN-Quellmaster · P09-L01 · 45 Minuten geschätzt · needs_review

Eine Wallet-Seite kann eine Adresse, mehrere Tokenkonten, Vertragsaufrufe und Anbieterbezeichnungen auf einem Bildschirm zusammenführen. Diese Bequemlichkeit macht sie weder zu einem Ledgerobjekt noch zu einer Person. Vor dem Lesen des Verlaufs definieren, was die Seite tatsächlich darstellt.

Sie ordnen Kontorollen zu und stimmen bereitgestellte Bestände ab, ohne Identitäten zuzuordnen. Dies ist die Einstiegskompetenz des Programms: Jede spätere Aussage zu Finanzierung, Alter und Beziehungen hängt von der richtigen Beobachtungseinheit ab.

Die Oberfläche vom Objekt trennen

Eine Wallet-Anwendung ist eine Oberfläche, ein Konto dagegen ein Ledgerobjekt; die Ethereum-Dokumentation unterscheidet dies ausdrücklich [S09-ETHACCOUNTS]. Eine Oberfläche kann mehrere Konten und Netzwerke anzeigen. Ein Konto kann über mehrere Oberflächen zugänglich sein. Keine dieser Beziehungen identifiziert einen einzelnen Menschen.

Als Ausgangskennung Netzwerk und vollständige Adresse verwenden. Eine verkürzte Bezeichnung kann keine Gleichheit belegen. Derselbe angezeigte Text auf verschiedenen Chains bezeichnet kein gemeinsames Buchungsobjekt. Die „Wallet“-Gruppierung eines Anbieters kann abgeleitete Beziehungen enthalten; ihre Definition prüfen, bevor sie als Eigentümersumme behandelt wird.

Bei realer Arbeit die Adresskodierung validieren und das ausgewählte Netzwerk dokumentieren. Die Übung verwendet absichtlich ungültige Bezeichnungen; Vergleiche dienen daher nur der Bildung, und keine Transaktion kann diese Kennungen als Ziel verwenden.

Die Rolle des Kontos identifizieren

Solana-Konten speichern Zustand unter Adressen und besitzen ein Feld für den Programmeigentümer [S09-ACCOUNTS]. Dieses Feld ist keine menschliche Identität. Ein Tokenkonto erfasst separat seine Mint und Eigentümerautorität [S09-TOKENS]. Die Basiseigentümerschaft des Token Program bedeutet nicht, dass dieses Programm Begünstigter jedes Tokenbestands ist.

Eine Autorität kann mehrere Tokenkonten für eine Mint besitzen. Nur bei exakter Mint, übereinstimmendem Kontext und belegten Autoritätsfeldern aggregieren. Ein nativer Saldo und ein Tokensaldo haben verschiedene Einheiten. Sie niemals wie einen einzigen Vermögenswert addieren oder ohne ausdrückliche Bewertungsquelle in Dollar umrechnen.

Festhalten, ob eine Adresse ein Programm, Tokenkonto, eine Mint oder ein anderes Zustandskonto bezeichnet. Derselbe Beziehungsgraph kann alle diese Knotentypen enthalten. Ein Graph mit fünf Knoten zeigt nicht fünf Wallets und erst recht nicht fünf Menschen.

Programmgesteuerte Aktivität verstehen

Programmabgeleitete Solana-Adressen (PDAs) werden aus einer Programm-ID und Seeds abgeleitet und besitzen keinen privaten Schlüssel; das ableitende Programm kann über den Laufzeitmechanismus für sie signieren [S09-PDA]. Die Ableitung allein behauptet nicht, dass an dieser Adresse bereits ein Konto angelegt ist. Sowohl die Adressbeziehung als auch den relevanten Kontozustand prüfen.

Programmsignaturen und menschliche Signaturen dürfen nicht in einem Feld zusammenfallen. Eine programmvermittelte Autorität kann vielen Nutzern dienen. Ihre Anwendungsregeln bestimmen, welche Anfragen sie zum Handeln veranlassen; eine PDA-Bezeichnung belegt weder einen einzelnen Nutzer noch uneingeschränkte Kontrolle.

Auf EVM-Netzwerken gewöhnliche Schlüsselkontrolle, Vertragslogik und unterstützte Delegationsmechanismen unterscheiden. Ein extern verwaltetes Konto (EOA) wird durch einen privaten Schlüssel kontrolliert; unterstützte Delegation kann den ausgeführten Code bestimmen. EIP-7702 erlaubt Codedelegation für EOAs auf unterstützenden Netzwerken [S09-DELEGATION]. Vorhandener Code allein ist daher keine universelle Regel „Dies kann kein EOA sein“. Netzwerkregeln und Kontozustand im angefragten Kontext prüfen.

Ein Konto mit Code kann Anweisungen ausführen, ohne zu belegen, welcher Mensch profitiert. Ein Multisig-Vertrag kann mehrere signierende Konten repräsentieren; das Zählen von Signierenden belegt jedoch keine unabhängigen Menschen. Kontrollmechanismus und menschliche Zuordnung getrennt halten.

Vor der Eigentumskarte eine Rollenkarte erstellen

Knotentyp, genaue Kennung, Netzwerk, Kontext und Evidenzverweis verwenden. Kanten wie Tokenkonto-Eigentümer, Mint-Referenz, Programmableitung und Codedelegation verwenden. Sie haben konkrete Bedeutungen. Eine allgemeine Kante „verbunden mit“ verschleiert den Grund der Verknüpfung.

Nicht jede Kante in gemeinsame Eigentümerschaft umdeuten. Eine Mint-Referenz verbindet alle Inhaber eines Vermögenswerts, ohne sie zu einem gemeinsamen Kontrolleur zu machen. Programmableitung verbindet eine Adresse mit einem Mechanismus, nicht zwingend mit dem persönlichen Bestand des Programmbetreibers.

Anbieterbezeichnungen gehören in eine separate Anmerkung mit Herkunft und Prüfstatus. „Verwahrdienst“ kann ein nützlicher Ansatz sein; Herausgeber, Aktualisierungsdatum und Grundlage der Bezeichnung müssen jedoch geprüft werden. Bis zur ausreichenden Bestätigung als Anbieterbehauptung dokumentieren.

Die bereitgestellten Bestände abstimmen

Die Fixture enthält bei S0 eine vollständige Menge von Tokenkonten für Autorität W und eine Ziel-Mint. Diese Vollständigkeit ist eine Übungsannahme, keine behauptete Fähigkeit von Wallet Intelligence. Die zwei gültigen Kontosalden erst nach Bestätigung ihres Eigentümers und ihrer Mint summieren.

Ein drittes Konto mit derselben Mint unter einer programmabgeleiteten Autorität gehört nicht allein deshalb zum Bestand von W, weil es auf derselben Anwendungsseite erscheint. Ein Bestand einer anderen Mint darf nicht in die Zielsumme eingehen. Native Einheiten bleiben getrennt.

Bei unvollständigen realen Datensätzen die zurückgegebene Saldosumme und die Abdeckungsgrenze angeben. Nicht stillschweigend zu „allen Beständen“ aufwerten. Eine fehlgeschlagene Abfrage ist nicht verfügbare Evidenz, kein Nullbestand. Ein bereitgestellter Nullbetrag ist eine Messung in ihrem angegebenen Umfang.

Grenzen konstruktiv formulieren

Eine gute Anatomie-Feststellung kann lauten: „W ist die bereitgestellte Autorität für T1/T2 mit MINT-A; P1 ist eine separate programmvermittelte Autorität. Menschliche Kontrolle ist unbekannt.“ Sie beantwortet die Kontofrage, ohne eine unbelegte Identitätsfrage zu lösen.

Die nächste Evidenzanforderung muss zur Lücke passen: vollständige Eigentümer-/Mint-Auflistung für fehlende Bestände, Ableitungs-/Zustandsdatensätze für eine PDA-Klassifizierung und Anwendungsautorisierung für vermittelte Kontrolle. Die Frage nach dem Namen einer Person ersetzt diese technischen Prüfungen nicht.

Keine Kontorolle erzeugt ein BUY/SELL-Signal. Ein Vertrag, PDA oder Tokenkonto erklärt die Organisation von Beobachtungen. Dies belegt weder Legitimität noch Absicht oder zukünftiges Marktverhalten.

• Adresse: netzwerkbezogene Kennung.
• Konto: Zustandsobjekt unter einer Adresse.
• Wallet-Oberfläche: Anwendung zum Anzeigen von oder Interagieren mit Konten.
• Eigentümerautorität: Feld, das ein bestimmtes Tokenkonto regelt.
• PDA: programmabgeleitete Adresse mit Laufzeitsignatur.
• Delegation: Beziehung zur Kontoausführung, keine persönliche Zugehörigkeit.

ILLUSTRATIVE — FIX-P09-01. SIM-SOL-A bei fiktivem S0; Salden bereits normalisiert. Zielautorität W, Ziel-Mint MINT-A. T1/T2 gelten für W/MINT-A als vollständig.

A 7 ist ein separates Netzwerkbeispiel. Es werden keine Datensätze zu Identität, Bewertung, Signaturschwelle oder Anwendungsautorisierung bereitgestellt.

OBSERVED in der Fixture: W ist Eigentümerautorität für T1/T2; P1 ist eine eigene programmabgeleitete Autorität für T4. Der Anbieter veröffentlicht A 8.

INFERRED: Die bereitgestellten MINT-A-Bestände von W betragen insgesamt 200 Token. Seine nativen 2 und MINT-B50 sind separate Mengen.

UNKNOWN: Menschliche Identität hinter W/P1/E1, Anwendungskontrollregeln und wirtschaftliche Eigentümerschaft.

INSUFFICIENT EVIDENCE: A 8 kann Alices Identität nicht belegen. Die gemeinsame Mint kann W und P1 nicht zusammenführen. Codedelegation belegt keine Zugehörigkeit zum Herausgeber von LOGIC-D.

Eine Wallet-Oberfläche als eine Person behandeln; Basisprogrammeigentümer mit Token-Eigentümerautorität verwechseln; verschiedene Einheiten addieren; Inhaber derselben Mint zusammenführen; und veraltete Code-/Kein-Code-Klassifizierung ohne Netzwerkkontext anwenden.

Aus A 1–A 7 eine typisierte Rollenkarte zeichnen. Die Zielbestände von W berechnen. A 8 klassifizieren und erklären, warum T4 außerhalb der Summe von W bleiben muss. Zwei fehlende Prüfungen für programmgesteuerte Aktivität identifizieren.

• Exaktes Netzwerk und Beobachtungseinheit auswählen.
• Jeden Knoten und jede Beziehung typisieren.
• Native Salden und Mint-Salden getrennt halten.
• Nur belegte Eigentümerfelder aggregieren.
• Programm-, Schlüssel- und delegierte Kontrolle unterscheiden.
• Bezeichnungen bis zur Bestätigung als Behauptungen erhalten.

Wallet-Anatomie ist eine Karte von Ledgerobjekten und Kontrollmechanismen. Sie legt fest, was geprüft wird, ohne Adressen mit Menschen gleichzusetzen.

Eine Oberfläche ist weder ein Konto noch eine Person. Typisierte Beziehungen verhindern falsche Aggregation. Anbieterbezeichnungen und Codeverhalten belegen keine Identität.

Typisierte W,T1,T2,T3,P1,T4- und Mint-Knoten mit beschrifteten Autoritäts-/Mint-/Ableitungskanten zeichnen. Nur Ziel200 hervorheben. Native Einheiten und MINT-B-Einheiten sowie separate EVM-Delegation abtrennen. A 8 in eine Anmerkung für unverifizierte Bezeichnungen setzen.

Illustrative Kontoanatomie; Graphknoten sind keine Menschen.

Deterministisches SVG/HTML oder Diagramme mit Einheiten, Evidenzverweisen und Textalternativen verwenden. Marineblau/Schwarz mit zurückhaltendem Cyan, elektrischem Blau und Violett; keine dekorativen oder erfundenen Explorer-Screenshots. Bei 390px Anmerkungen stapeln; bei Umsetzung der Assets 768px, Desktop und arabisches RTL prüfen. Kennungen LTR und sachliche Zeit-, Kanten- und Achsenrichtungen unverändert lassen. Nur das offiziell bereitgestellte BlockAssay-Zeichen verwenden. Beide visuellen Datensätze bleiben Spezifikationen.

WALLET_INTELLIGENCE entspricht der ausschließlich lesenden Prüfung öffentlicher Adressdatensätze, Beziehungen und Herkunft. Unterstütztes Netzwerk, genaue Kennungen, Felder und Abdeckung vor jeder Laufzeitintegration prüfen; hier wird keine Live-Fähigkeit eines Anbieters behauptet. Bei fehlenden Daten oder kostenpflichtigem Zugang die eingebettete Offline-Übung verwenden. Wallet-Verbindung, Zugangsdaten, privater Schlüssel, Signatur oder Live-Handel sind nicht erforderlich. Fehlende Daten bleiben unbekannt. Academy-Fortschritt, Creator-Status, Zahlungen und Empfehlungen ändern niemals die Radar-Evidenz.

• Solana-Konten — Adressierter Zustand und Feld für den Programmeigentümer. Geprüft am 2026-09-30.
• Solana-Vermögenswerte — Unterscheidung zwischen Mint, Tokenkonto und Eigentümerautorität. Geprüft am 2026-09-30.
• Programmabgeleitete Solana-Adressen — Programmabgeleitete Adressen und Programmsignaturen; kein privater PDA-Schlüssel. Geprüft am 2026-09-30.
• Ethereum-Konten — Unterscheidung zwischen Konto und Oberfläche sowie Kontotypen. Geprüft am 2026-09-30.
• EIP-7702: Code für EOAs festlegen — Codedelegation bei EOAs; das Vorhandensein von Code allein ist keine universelle Regel zur EOA-Klassifizierung. Geprüft am 2026-09-30.

Alle Beispieldatensätze sind originale ILLUSTRATIVE Fixtures, keine historischen oder aktuellen Chain-Messungen. Die Dokumentation erklärt Mechanismen, keine erfundenen Beträge oder Bezeichnungen. Die synthetische Chronologie ist ausdrücklich begrenzt; observedAt=null ist beabsichtigt. OBSERVED bezeichnet in einer Übung einen bereitgestellten Fixture-Datensatz. Dokumentation und eingesetzte Dekodierung vor Veröffentlichung erneut prüfen. Anbieterbezeichnungen belegen keine Identität; Adresskontrolle und menschliche Zuordnung erfordern getrennte Evidenz.

P09-L02 nach der ausgearbeiteten Übung und der Fragenprüfung.