Freeze, Eigentümerschaft und Befugnisse

EN-Quellmaster · P08-L04 · 45 Minuten geschätzt · needs_review

Ein Abzeichen „Eigentümerschaft aufgegeben“ kann neben einer aktiven Pause-Rolle oder einem Upgrade-Controller bestehen. Eine entfernte Mint-Berechtigung kann neben einer Freeze-Berechtigung bestehen. Jede dieser Aussagen kann wahr sein, während die breite Schlussfolgerung „niemand hat Kontrolle“ falsch ist.

Diese Lektion vermittelt eine mehrschichtige Kontrollkarte. Du verbindest jedes Privileg mit Objekt, aktuellem Inhaber, Bedingung und möglichem Verwaltungspfad. Das Ergebnis ist ein Belegdatensatz, kein Sicherheitswert oder Vorwurf.

Das kontrollierte Objekt definieren

Verwende Eigentümer nicht ohne Bezugsobjekt. Der Programmeigentümer eines Solana-Datenkontos, eine Tokenkonto-Berechtigung, ein EVM-Ownable-Eigentümer und ein NFT-Positionseigentümer sind unterschiedliche Felder. Ihre Namen ähneln sich, steuern aber unterschiedliche Mechanismen. Schreibe Feld und Objekt neben den Wert.

Trenne Tokensaldenkontrolle, Einschränkungen auf Mint-Ebene, Anwendungsrollen und codeverändernde Befugnisse. Ein Befund auf einer Ebene kann keine Berechtigung auf einer anderen auslöschen. Beispielsweise kann einer Token-Mint die Mint-Berechtigung fehlen, während eine mit dem Token interagierende Anwendung upgradefähig bleibt. Prüfe die Anwendungsrolle getrennt, statt anzunehmen, dass sie das Standard-Token-Program selbst steuert.

Eine Kontrollkarte ist ein Fähigkeitsgraph, kein Graph menschlicher Identitäten. Eine aufgeführte berechtigte Stelle kann ein Nutzerkonto oder eine programmvermittelte Adresse sein. Öffentliche Kontolabels stellen nicht fest, wer die Schlüssel besitzt oder ob mehrere Konten einen Controller teilen.

Freeze als Zustandseinschränkung verstehen

Solanas Freeze-Mechanismus bewahrt Tokenkonto-Eigentümer, Mint und Saldo, verhindert aber die dokumentierten Empfangs-, Transfer- und Burn-Vorgänge bis zur Freigabe durch Thaw [S08-FREEZE]. Er löscht keinen Saldo und überträgt nichts an die Freeze-berechtigte Stelle.

Zustand und Befugnis müssen getrennt dokumentiert werden. Eine Freeze-Berechtigung kann bestehen, während ein Konto aktuell nicht eingefroren ist. Umgekehrt sagt die Beobachtung eines eingefrorenen Zustands nicht, dass ein bestimmter Mensch ihn verursacht hat. Fordere den erfolgreichen Vorgang und dessen Autorisierung an, wenn Zuordnung wichtig ist.

Widerruf entfernt eine ausgewählte Berechtigungsrolle, nicht eine universelle Sammlung von Befugnissen [S08-SET]. Unterstelle nicht, dass ein Mint-Rollenwiderruf den Freeze-Zustand änderte. Bereits eingefrorene Konten und mögliche Wiederherstellungs-/Thaw-Pfade benötigen eigene Untersuchung; beschreibe einen engen Widerruf nicht als Beweis, dass jedes Konto übertragbar ist.

Anwendungsrollen jenseits von Ownable prüfen

OpenZeppelin-Ownable-Verzicht deaktiviert Funktionen, die durch seine Eigentümerprüfung geschützt sind, während rollenbasierte Berechtigungen ein getrenntes Muster sind [S08-ACCESS]. Ob ein bereitgestellter Token diese Muster kombiniert, ist eine Frage von Code und Zustand. Bleibt eine Pauser-Rolle, kann Eigentümerverzicht allein sie nicht entfernen.

Erstelle eine Tabelle für Eigentümerschaft, Pause, Rollenvergabe/-widerruf und Upgrades. Dokumentiere je Zeile tatsächliche Prüfung, aktuelle berechtigte Stelle, Verwaltungspfad und Unsicherheit. Ein Rollenname ist nur beschreibend, bis er mit einem erreichbaren Vorgang verbunden wird. „PAUSER“ in Metadaten belegt keine Pause-Funktion.

Eine Kontrolle kann von Timelock oder Multisig abhängen. Verifiziere relevanten Vertrag, Schwelle, Verzögerung und Umgehungsbedingungen, statt ein Abzeichen zu akzeptieren. Eine Verzögerung ist eine Zeitbedingung, kein Verschwinden der Kontrolle. Eine Multisig-Schwelle beschreibt Unterschriften, nicht notwendigerweise unabhängige Menschen.

Proxy- und Implementierungskontrolle nachverfolgen

Unterscheide bei Proxys im ERC-1967-Stil die Implementierungs- oder Beacon-Verknüpfung vom optionalen Admin-Slot. Ein Beacon löst Logik für zugehörige Proxys auf; Autorisierung im UUPS-Stil kann in Implementierungslogik liegen, sodass ein leerer Admin-Slot allein keine vollständige Schlussfolgerung ist [S08-PROXY; S08-UUPS].

Die nutzerseitige Proxyadresse kann gleich bleiben, wenn sich ihre Regeln ändern. Verankere die Implementierung im geprüften Kontext und prüfe dann den Pfad, der sie ändern kann. Prüfe nicht eine verifizierte Implementierungsseite und lasse die Proxyverknüpfung ungeprüft. Eine spätere Implementierung kann frühere Verhaltensannahmen ungültig machen.

Diese Lektion vermittelt keine Upgrade-Ausführung. Sie vermittelt, wie der vorgegebene Autorisierungspfad rein lesend beschrieben wird. Sind die internen Controller-Regeln nicht verfügbar, kennzeichne sie als unbekannt, auch wenn die externe berechtigte Adresse bekannt ist.

Solana-Programmupgrades von Mint-Rollen unterscheiden

Unter Solana loader-v3 hängen Programmupgrades von der Programm-Upgrade-Berechtigung ab; deren Entfernung macht dieses Programm unveränderlich [S08-DEPLOY]. Dies ist nicht das Mint-Authority-Feld der Mint. Es gilt für das geprüfte Programm und den Loader-Mechanismus, nicht jeden verbundenen Vertrag oder Off-Chain-Dienst.

Eine Mint unter einem Standard-Token-Program sollte nicht leichtfertig als unabhängig upgradefähig beschrieben werden, nur weil eine benutzerdefinierte Anwendung sie verwendet. Benenne das benutzerdefinierte Programm und erkläre seine Relevanz. Im Übungsdatensatz ist PROGRAM-X eine Hilfsanwendung, nicht das Token Program, dem MINT-F gehört.

Unveränderlichkeit ist auf das Codeobjekt begrenzt. Sie belegt weder ehrliche Nutzer noch unveränderliche Metadaten, ausreichende Liquidität oder sichere umgebende Systeme. Ebenso belegt aktive Upgrade-Befugnis eine Fähigkeit unter Bedingungen, nicht eine künftige bösartige Codeänderung.

Ein mehrschichtiges Ergebnis berichten

Ein vertretbarer Satz benennt Kontext und Grenzen: „Bei S0 ist das Eigentümerfeld aufgegeben, während PAUSER zugewiesen bleibt und der Proxy-Upgrade-Controller vorgegeben ist, seine interne Schwelle aber unbekannt ist.“ Dies ist informativer als ein kategorisches Label „dezentral“.

Frage, ob eine Aussage durch eine einzige verbleibende Zeile widerlegt werden kann. „Keine privilegierten Kontrollen“ widerspricht einer einzigen nachgewiesenen aktiven Fähigkeit. Eine enge Aussage wie „die Ownable-Eigentümerrolle fehlt“ kann gestützt bleiben, auch wenn die breite Aussage scheitert. Bewahre beide.

• Freeze-Zustand: Vorgangseinschränkung auf einem Tokenkonto.
• Ownable-Eigentümer: Befugnis unter einem bestimmten Eigentümerprüfmuster.
• Rolleninhaber: Konto, das eine bestimmte Mitgliedschaftsprüfung erfüllt.
• Upgrade-Controller: Befugnis, die einen Codeänderungspfad steuert.
• Beacon: Mechanismus zur Proxy-Logikverknüpfung.
• Timelock: Bedingung, die bestimmte Vorgänge verzögert.

ILLUSTRATIVE — FIX-P08-04. Getrennte fiktive Objekte bei S0.

PROGRAM-X ist nicht das Token Program, das MINT-F steuert. Der Übungsdatensatz liefert nicht die Codeeffekte, die diese Hilfsanwendung mit der Mint verbinden.

OBSERVED im Übungsdatensatz: F bleibt, V ist eingefroren, P/G bleiben und C/U sind vorgegebene Upgrade-berechtigte Stellen.

INFERRED: „Alle Kontrollen entfernt“ widerspricht diesen getrennten Fähigkeiten. Aufgegebene Eigentümerschaft ist eine engere gestützte Aussage über P2.

UNKNOWN: Interne Regeln von C, menschliche Controller, wer V einfror und die genauen Anwendungseffekte von PROGRAM-X.

INSUFFICIENT EVIDENCE: Freeze bedeutet nicht, dass der Saldo von V vernichtet wurde. Ein fehlender Eigentümer belegt keine Abwesenheit von Rollen oder Upgrades. U belegt nicht, dass U das Standard-Token-Program kontrolliert.

Eigentümer ohne sein Objekt verwenden; eingefrorenen Saldo mit Null verwechseln; annehmen, dass ein leerer Proxy-Admin-Slot alle Upgrades ausschließt; ein Multisig-Label als verifizierte unabhängige Kontrolle deuten; und Hilfsprogramm-Befugnis mit Mint-Befugnis vermischen.

Erstelle vier Kontrollebenen: Kontozustand, Mint-Rollen, EVM-Anwendungsrollen und Implementierungsänderungspfade. Formuliere „alle Eigentümerschaft ist aufgegeben, daher ist alles unveränderlich“ um. Nenne die nächsten für C und V benötigten Belege.

• Das Objekt jedes Eigentümerfelds nennen.
• Befugnis vom aktuellen Zustand trennen.
• Rollen nach Eigentümerverzicht prüfen.
• Logik und Upgrade-Pfade im selben Kontext auflösen.
• Schwellen/Verzögerungen statt Labels verifizieren.
• Unveränderlichkeit auf das geprüfte Objekt begrenzen.

Kontrolle ist mehrschichtig. Eine entfernte Rolle stellt einen engen Fakt fest; aktive Rollen und Codeänderungspfade brauchen getrennte Prüfung.

Freeze ist eine Einschränkung, keine Löschung. Eigentümerverzicht ist kein Verzicht auf alle Kontrollen. Proxy-, Programm- und Mint-Befugnisse sind getrennt.

Berechtigungskarte mit vier Bahnen und F1–F3,P1–P3,X1-Verweisen; unveränderten eingefrorenen Saldo 50 zeigen. PROXY-Q→LOGIC-Q und separaten Controller C zeichnen; PROGRAM-X/U von MINT-F isolieren. C-Konfiguration als unbekannt markieren.

Illustrative mehrschichtige Kontrollen; fehlender Eigentümer ist eine enge Aussage.

Deterministische SVG/HTML oder Diagramme mit Textalternativen, dunklem Marineblau/Schwarz und zurückhaltendem Cyan, leuchtendem Blau und Violett verwenden. Jede Menge und Unsicherheit beschriften. Bei 390px Panels untereinander anordnen; 768px/Desktop- und arabische RTL-Verifizierung bleiben künftige Asset-Arbeit. Kennungen LTR und faktische Achsen-/Kantenrichtungen unverändert halten. Falls Branding ergänzt wird, nur das offiziell vorgegebene BlockAssay-Zeichen verwenden. Beide Datensätze sind Spezifikationen, keine gelieferten Assets.

RADAR für den begrenzten didaktischen Zweck dieser Lektion nur verwenden, wenn Netzwerkunterstützung, genaue Identität, Felder und Herkunft verifiziert sind. Dieser Inhalt behauptet keinen Laufzeitendpunkt und keine Anbieterfähigkeit. Den eingebetteten Offline-Übungsdatensatz ohne kostenpflichtigen Zugang verwenden. Fehlende Daten bleiben unbekannt; weder Wallet-Verbindung noch Transaktionssignatur, Tokenstart oder Live-Handel sind erforderlich. Academy-Fortschritt, Zahlungen und Empfehlungen verändern Radar-Belege niemals. Ein Diagnostic Passport bewahrt Beobachtungen und Grenzen, keine Preisprognose und kein Sicherheitszertifikat.

• OpenZeppelin 5.x Proxy — Transparente, Beacon- und implementierungsbasierte UUPS-Upgrade-Mechanismen; tatsächliche Autorisierung muss geprüft werden. Geprüft 2026-09-30.
• Solana-Konto einfrieren — Kontozustandseinschränkungen getrennt von Betrag oder Eigentümerschaft. Geprüft 2026-09-30.
• Solana-Berechtigung setzen — Rollenspezifische Änderungen und Widerruf; kein globales Sicherheitsurteil. Geprüft 2026-09-30.
• OpenZeppelin 5.x Zugriffskontrolle — Ownable- und rollenbasierte Privilegienmuster; tatsächliche bereitgestellte Autorisierung prüfen. Geprüft 2026-09-30.
• ERC-1967-Proxy-Speicherslots — Implementierungs-, Beacon- und optionale Admin-Slots; mechanismusspezifische Prüfung. Geprüft 2026-09-30.
• Solana-Programmbereitstellung — loader-v3-Programm-Upgrade-Berechtigung; keine Token-Mint-Rolle. Geprüft 2026-09-30.

Dokumentation stützt Mechanismen, nicht fiktive Datensatzwerte. Alle Beispiele und Übungsdatensätze sind eigenes ILLUSTRATIVE Material, in dieser Datei fixiert. S0/S1 sind synthetische Kontextlabels; observedAt ist null, weil keine Live- oder historische Ledger-Messung erhoben wurde. Dokumentation und tatsächlich bereitgestelltes Verhalten vor jeder Veröffentlichung oder Integration erneut prüfen.

P08-L05 nach der ausgearbeiteten Übung und Quizprüfung.