Mint- und Burn-Berechtigungen

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

„Mint deaktiviert“ und „Burn aktiviert“ klingen einfach, beschreiben aber bestimmte Vorgänge unter bestimmten Autorisierungsregeln. Ein Tokenhalter, der eigene Einheiten verbrennt, unterscheidet sich von einem Administrator, der den Saldo eines anderen Halters beeinflusst. Eine Obergrenze begrenzt Mengen nur, wenn der relevante Pfad sie tatsächlich durchsetzt.

Deine Aufgabe ist es, angebotsverändernde Fähigkeiten, Bedingungen und Umfang aufzulisten. Du beurteilst Berechtigungen, vermittelst keine Tokenausgabe und prognostizierst nicht, ob eine berechtigte Stelle handeln wird.

Fragen, wer mit welchem Saldo was tun kann

Ein Berechtigungsdatensatz sollte Vorgang, kontrollierendes Konto oder Rolle, Zielumfang, Mengenbeschränkungen und Änderbarkeit nennen. „Admin vorhanden“ lässt die nützlichsten Informationen aus. An einen Empfänger prägen, den eigenen Saldo verbrennen und den Saldo eines Dritten verbrennen sind unterschiedliche Fähigkeiten.

Frage für jeden Pfad, ob die Prüfung Aufrufer, Allowance, Rolle oder eine programmvermittelte Bedingung betrifft. Dokumentiere die Bedingung so wörtlich, dass die Begründung reproduzierbar ist. Ein Funktionsname ist nicht seine Implementierung: Eine Methode namens burn könnte intern Einheiten übertragen, und eine Methode namens distribute könnte sie prägen.

Verwende eine Fähigkeitstabelle mit Belegverweisen. Wurde ein Vorgang historisch beobachtet, stützt dies dieses Ereignis; es beweist nicht allein jede gegenwärtige Berechtigung. Besteht eine Berechtigung in einer Momentaufnahme, stützt dies Verfügbarkeit unter Bedingungen; es beweist nicht ihre Ausübung.

Standard-Burn-Pfade unterscheiden

Solanas Standard-Burn reduziert Kontosaldo und Mint-Angebot. Die Autorisierung kann vom Tokenkonto-Eigentümer oder genehmigten Delegierten kommen; permanente Delegation im Token Extension Program ergänzt einen Pfad auf Mint-Ebene [S08-BURN]. Eine gewöhnliche Genehmigung ist auf das relevante Konto und den Betrag begrenzt; beschreibe sie daher nicht als allgemeine administrative Eigentümerschaft.

Die Erweiterung PermanentDelegate kann Übertragungen und Burns über Konten ihrer Mint hinweg autorisieren; Tokenkonto-Eigentümer können sie lokal nicht widerrufen [S08-DELEGATE]. Dies ist ein konkreter Grund, Erweiterungszustand zu prüfen, statt bei fehlender Mint-Berechtigung zu folgern, dass alle Befugnisse verschwunden sind. Leite die Existenz der Erweiterung nicht allein daraus ab, dass der Token ein erweiterungsfähiges Programm verwendet.

OpenZeppelin ERC20Burnable unterscheidet Vernichtung des eigenen Saldos und Allowance-basiertes burnFrom. Capped-Verhalten begrenzt Prägung unter dieser Implementierung [S08-OZERC20]. Bibliotheksdokumentation stützt diese Muster, nicht den Befund, dass ein bestimmter bereitgestellter Vertrag sie enthält. Prüfe tatsächlichen Code und Zustand.

Angebotsobergrenzen als bedingte Aussagen behandeln

Eine Obergrenze hat Einheit und Kontext. Ein Maximum von 1,200 angezeigten Token mit sechs Dezimalstellen entspricht 1,200,000,000 Roheinheiten. Ein angezeigtes aktuelles Gesamtangebot mit einer Rohobergrenze zu vergleichen kann eine falsche Kapazitätsschätzung ergeben.

Die Obergrenze ist nur für Pfade aussagekräftig, die sie durchsetzen. Umgehen andere Pfade die Prüfung oder kann ein Upgrade die Regel ändern, dokumentiere diese Grenzen. In diesem Übungsdatensatz deckt die vorgegebene Regel alle aufgeführten Mint-Aufrufe unter der aktuellen Implementierung ab. Künftige Implementierungen liegen ausdrücklich außerhalb der Annahme vollständiger Pfade.

Burns können Gesamtangebot verringern und Kapazität unter einer Obergrenze für aktuell ausstehendes Gesamtangebot schaffen. Eine lebenslange Ausgabegrenze ist eine andere Regel. Unterstelle keine davon aus dem Wort „Obergrenze“. Gib an, ob die Regel ausstehendes Angebot, kumulative Ausgabe, ein Epochenbudget oder etwas anderes zählt.

Rollenverwaltung untersuchen

Rollenmitgliedschaft und Rollenverwaltung sind getrennt. Ein Konto, das eine Minter-Rolle vergeben kann, kann indirekt künftige Minter schaffen, auch wenn es unter seiner aktuellen Mitgliedschaft nicht prägen kann. OpenZeppelin AccessControl verwendet rollenspezifische Prüfungen und Verwaltung; Ownable ist ein anderes Muster [S08-ACCESS]. Ein allgemeines Owner-Feld kann nicht jeden Autorisierungspfad zusammenfassen.

Verfolge die Kette weit genug, um zu beschreiben, wer die Berechtigung ändern kann. Ist ein Administrator ein Vertrag, benötigen dessen Unterzeichner, Schwelle und Verzögerung separate Belege. Ein Multisig-Label beweist keine Schwelle. Sind diese Details nicht verfügbar, bewahre die Vertragsrolle und kennzeichne ihre Kontrollanordnung als unbekannt.

Angebotsverändernde Befugnis und Upgrade-Befugnis sind verwandt, aber getrennt. Diese Lektion identifiziert eine vorgegebene Upgrade-Lücke; P08-L04 untersucht sie direkt. „Unter aktuellen Regeln fest“ kann nicht stillschweigend zu „für immer fest“ werden, wenn sich die Logik ändern kann.

Mögliches Verhalten von abgeschlossenen Ereignissen trennen

Ein erfolgreicher angebotsverändernder Vorgang erfordert mehr als eine eingereichte Transaktion oder ein ereignisähnliches Label. Prüfe Ausführungsergebnis, betroffenen Vermögenswert, Buchungsdifferenz und Kontext. Fehlgeschlagene Versuche dürfen nicht zum Angebot addiert werden. Übertragungen an eine unzugängliche Adresse können zugänglichen Bestand reduzieren, ohne das Gesamtangebot des Protokolls zu verringern.

Selbst ein verifizierter Burn sagt nichts über Preissteigerung aus. Menge und Marktausführung sind unterschiedliche Messungen. Ebenso belegt eine verfügbare Mint-Berechtigung keine bösartige Absicht. Ein professioneller Befund nennt Umfang und Bedingungen und fragt dann, welche Belege Lücken klären würden.

Einen begrenzten Berechtigungsbefund schreiben

Bevorzuge „Bei S0 kann M unter der vorgegebenen aktuellen Regel das Angebot bis zur Obergrenze des ausstehenden Gesamtangebots erhöhen; G kann diese Rolle vergeben“ gegenüber „der Token ist inflationär und unsicher“. Ersteres ist reproduzierbar; Letzteres bündelt eine undefinierte ökonomische Klassifikation mit einer ungestützten Empfehlung.

Ist ein Widerruf vorgegeben, benenne die genaue Rolle. Solana-Berechtigungsentfernung ist rollenspezifisch [S08-SET]. Die Entfernung einer Mint-Rolle entfernt logisch weder einen unabhängigen Delegierten noch eine Freeze-Rolle oder einen Implementierungsänderungspfad.

• Mint-Berechtigung: Fähigkeit, das buchhalterische Angebot zu erhöhen.
• Burn-Berechtigung: Fähigkeit, Salden und Angebot nach einer Regel zu verringern.
• Allowance: betragsbegrenzte Berechtigung in Verbindung mit Halter und Spender.
• Permanenter Delegierter: Befugnis des Token Extension Program auf Mint-Ebene.
• Obergrenze ausstehenden Angebots: maximales aktuelles Angebot unter der vorgegebenen Regel.
• Rollenadministrator: Konto, das Mitgliedschaft ändern kann.

ILLUSTRATIVE — FIX-P08-03. Zwei getrennte fiktive Vermögenswerte bei S0; Labels sind ungültig und keine Ausführungsanweisungen.

Der hypothetische Burn von 40 in E3 geht einer hypothetischen Prägung von 220 voraus. H hat genügend Saldo, und beide Vorgänge gelingen unter den vorgegebenen Regeln. Keine anderen Angebotsänderungen treten auf.

OBSERVED im Übungsdatensatz: MINT-P hat keine Mint-Berechtigung, aber D; TOKEN-C hat einen begrenzten Mint-Pfad und Rollenadministrator.

INFERRED: TOKEN-C hat anfangs 200 Kapazität unter der Obergrenze; nach Burn 40 sind es 240, sodass Prägung 220 hineinpasst und ein Gesamtangebot von 1,180 hinterlässt.

UNKNOWN: Der kontrollierende Mensch von D, ausgelassenes Erweiterungsverhalten, Upgrade-Kontrolle von TOKEN-C und künftige Regeländerungen.

INSUFFICIENT EVIDENCE: Fehlende Mint-Berechtigung beweist nicht, dass MINT-P-Salden nicht verbrannt werden können. Eine Obergrenze stellt weder unveränderliche Angebotsregeln noch ein Preisergebnis fest.

Mint-Widerruf mit Entfernung aller Privilegien gleichsetzen; eigenen Burn als beliebigen Drittparteien-Burn behandeln; Rollenvergabepfade ignorieren; Roh-/Anzeigeobergrenzen mischen; und annehmen, dass Burns Wertsteigerung garantieren.

Schreibe eine Fähigkeitstabelle für S1/S2 und E1–E4. Berechne anfängliche Kapazität, Kapazität nach Burn und endgültiges Angebot. Beurteile, ob G künftige Prägung beeinflussen kann und ob J unter der vorgegebenen Allowance 100 von H verbrennen kann.

• Vorgang, Ziel und Bedingung nennen.
• Betragseinheiten und aktuelles Gesamtangebot verifizieren.
• Aktuelle Rolle von Rollenverwaltung unterscheiden.
• Relevante Erweiterungen prüfen.
• Abgeschlossene Angebotsänderungen von verfügbaren Befugnissen trennen.
• Ungeklärte Implementierungsänderungspfade angeben.

Berechtigungen sind bedingte Fähigkeiten. Eine nützliche Prüfung unterscheidet Angebotsschaffung, Saldenvernichtung und die Macht, zu ändern, wer handeln darf.

Keine Mint-Rolle bedeutet nicht keine anderen Kontrollen. Eine Obergrenze braucht Definition und Durchsetzungsumfang. Verfügbare Befugnis ist kein Absichtsbeleg.

Erstelle zwei getrennte Berechtigungsmatrizen für MINT-P und TOKEN-C mit Akteur,Vorgang,Ziel,Bedingung und Belegzeile. Ergänze aktuelle Obergrenzenarithmetik200→240→20 verbleibende Kapazität. Zeige die Upgrade-Lücke als unbekannt, nicht als abwesend.

Illustrativer Berechtigungsumfang und Obergrenze ausstehenden Angebots; kein Befund zu einem bereitgestellten Token.

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.

• Solana-Token verbrennen — Standard-Burn-Autorisierung und Auswirkungen auf Kontosaldo und Mint-Angebot. Geprüft 2026-09-30.
• Solana permanenter Delegierter — Transfer-/Burn-Befugnis des Token Extension Program auf Mint-Ebene. Geprüft 2026-09-30.
• OpenZeppelin 5.x ERC20 — Burnable-, Capped- und Pausable-Erweiterungen; Bibliotheksverhalten belegt keinen bereitgestellten Code. Geprüft 2026-09-30.
• OpenZeppelin 5.x Zugriffskontrolle — Ownable- und rollenbasierte Privilegienmuster; tatsächliche bereitgestellte Autorisierung prüfen. Geprüft 2026-09-30.
• Solana-Berechtigung setzen — Rollenspezifische Änderungen und Widerruf; kein globales Sicherheitsurteil. 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-L04 nach der ausgearbeiteten Übung und Quizprüfung.