Analyse: Vorschlag für BNB Chain verteilt Vermögensbefugnisse auf vier Rollen

Der vorgeschlagene CAS20-Entwurf von BNB Chain verteilt die Befugnisse über Vermögenswerte auf vier Rollen, überträgt einem von der Governance eingesetzten Administrator jedoch die Kontrolle darüber, wann neue Stablecoins und tokenisierte Vermögenswerte erstellt werden können. Das am 16. Oktober veröffentlichte Update v1.8.1 sieht den Start von Jenner im Chapel-Testnetz der BNB Smart Chain am 29. Oktober um 02:30 UTC vor. Eine frühere Ankündigung nennt Ende November als Richtwert für den Mainnet-Start; der genaue Zeitpunkt ist noch nicht bekannt gegeben. Der vorgeschlagene Standard BEP-702 ist weiterhin als Entwurf gekennzeichnet und gilt für CAS20-Token; bestehende BEP-20-Token wären nicht betroffen. CAS20 würde das gemeinsame Token-Verhalten mithilfe zustandsbehafteter Precompiles in der nativen Chain-Logik umsetzen.

Nach BEP-702 setzt die Chain-Governance den Aktivierungsadministrator über GovHub ein, den Governance-Weiterleitungsvertrag von BSC. Die Aktivierungslogik erlaubt ausschließlich GovHub, den Administrator zu ändern, und ausschließlich dem gespeicherten, nicht auf null gesetzten Administrator, Funktionen zu aktivieren oder zu deaktivieren. Separate Schalter steuern die Erstellung von Token der Asset-Variante, die Erstellung von Token der Stablecoin-Variante sowie Schreibvorgänge im gemeinsamen Richtlinienregister. Sobald eine Variante aktiviert ist, enthält der Erstellungsprozess der Factory keine Liste individuell zugelassener Emittenten. Der Ersteller gibt den anfänglichen Token-Administrator und die Initialisierungsanweisungen an. Die Whitelist für den Frühzugang von Emittenten, die BNB Chain anbietet, belegt nicht, dass der Code jeden Emittenten gesondert zulässt.

Würde eine Funktion zur Token-Erstellung deaktiviert, könnten keine neuen CAS20-Token dieser Variante erstellt werden. Bestehende Token könnten weiterhin unter den bestehenden Berechtigungen zusätzliche Einheiten ausgeben, Guthaben übertragen und Rollen verwalten. Die Installation der Jenner-Unterstützung und die Aktivierung der Erstellung für die ausgewählte Variante sind getrennte Meilensteine beim Start. Der Schalter zur Erstellung ist kein direkter Mechanismus, um das Guthaben eines bestehenden Inhabers zu verschieben oder einzufrieren.

Ein Token-Administrator wählt Richtlinien für bestimmte Vorgänge aus; jede Richtlinie hat einen eigenen Administrator, der für die Mitgliedschaft zuständig ist. Die gekennzeichnete Implementierung verlangt eine Aktivierung der Funktion für Schreibvorgänge im Register, darunter Änderungen der Mitgliedschaft und die Übergabe der Administratorrolle. Ein Token kann weiterhin eine bestehende Liste abfragen, wenn Schreibvorgänge im Register deaktiviert sind. Ein Konto, das bereits durch eine Transferrichtlinie gesperrt ist, könnte beschränkt bleiben, weil der Listenadministrator das Konto bei deaktivierten Schreibvorgängen nicht entfernen kann. Der Standardadministrator des Tokens kann jedoch außerhalb des Schalters für Schreibvorgänge im Register eine andere bestehende Richtlinie zuweisen, vorbehaltlich der übrigen Verwaltungsberechtigungen des Tokens. Eine Änderung der Mitgliedschaft in einer gemeinsamen Richtlinie kann die Zulässigkeit eines Kontos für jeden Token und jeden Vorgang verändern, der auf diese Richtlinie verweist. Wird der Aktivierungsadministrator ausgetauscht, erhält der neue Administrator wieder die Kontrolle über den Schalter; ein Listeneintrag wird dadurch jedoch nicht korrigiert. Schreibvorgänge wieder zuzulassen und die erlaubte Mitgliedschaft zu ändern, sind getrennte Schritte.

Ausgabe, eigenständiges Verbrennen, Einziehung, Pausieren und Wiederaufnehmen von Transfers verwenden separate Token-Rollen, die verschiedenen Adressen zugewiesen oder bei einer einzigen Adresse gebündelt werden können. Die Aktivierungsbefugnis auf Netzwerkebene, die Mitgliedschaft in Token-Rollen und die Verwaltung von Richtlinienlisten bleiben getrennte Berechtigungen, selbst wenn eine Organisation mehrere davon innehat. Bei gewöhnlichen Transfers werden Sender und Empfänger anhand ihrer jeweiligen Richtlinien geprüft; bei delegierten Transfers wird zusätzlich der ausführende Akteur geprüft. Für die Ausgabe gilt eine separate Empfängerrichtlinie. Die Berechtigung, neu ausgegebene Einheiten zu empfangen, verleiht daher nicht automatisch das Recht, Token zu senden oder im Auftrag eines anderen Inhabers zu handeln.

Eine Einziehung würde einem autorisierten Akteur erlauben, zulässige Guthaben ohne Zustimmung des Inhabers neu zuzuweisen. Die Standardkonfiguration schützt jedoch jeden Inhaber; die Zuweisung einer Einziehungsrolle allein macht Guthaben daher nicht für eine Einziehung verfügbar. Im Code von v1.8.1 heißt die Regel zum Schutz von Inhabern SEIZE_EXEMPT_POLICY; eine Autorisierung nach dieser Regel schützt das Konto vor einer Einziehung. Für eine gewöhnliche Neuzuweisung nach der Erstellung müssen die Prüfung auf Ausnahme vom Schutz fehlschlagen, die Einziehungsrolle vorliegen, die Einziehungsfunktion nicht pausiert sein, das Guthaben ausreichen und das zulässige Ziel die Empfängerrichtlinie für Einziehungen erfüllen. Sind diese Schutzvorkehrungen erfüllt, umgeht seizeWithMemo die gewöhnlichen Transferrichtlinien; das Gesamtangebot bleibt unverändert. Beim Verbrennen wird das Angebot verringert. Bei gewöhnlichen CAS20-Aufrufen kann ein Akteur unter einer separaten Rolle nur seine eigenen Token verbrennen. Die Zulässigkeit eines gewöhnlichen Transfers bestimmt nicht, ob eine Einziehung zulässig ist. Eine Pause von Transfers pausiert die Einziehung nicht; für sie gilt eine separate Pauseneinstellung, und die übrigen Schutzvorkehrungen bleiben bestehen.

Auch die Cobalt-Kontrollen von Base trennen nach dem B20-Standard Rollen und Zulässigkeit. CAS20 wirft zusätzlich die Frage auf, wie die Zulassung von Funktionen auf Netzwerkebene durch BNB Chain mit den Kontrollen auf Token-Ebene zusammenwirkt. Auf der CAS20-Seite von BNB Chain werden Emittenten für den Frühzugang gesucht; außerdem werden die Stablecoin- und die Asset-Variante beschrieben. Gemeinsamer nativer Code verringert die Notwendigkeit, dasselbe Token-Verhalten jeweils separat zu implementieren. Der Vorschlag warnt jedoch, dass ein Fehler im nativen Client mehrere CAS20-Token betreffen und zu seiner Behebung einen weiteren Hard Fork erforderlich machen könnte. Ein Datum für die Mainnet-Veröffentlichung allein würde nicht klären, welche Adresse die Aktivierungsbefugnis innehat, wie diese Adresse Änderungen signiert oder welche Funktionen aktiviert wurden.