Veröffentlichen
--
Eman098
·
--
#dusk $DUSK @Dusk
Was mir beim Durchgehen der Dusk-Dokumentation aufgefallen ist: Es existieren nur zwei Verträge. Beim Genesis-Prozess gibt es den Stake-Vertrag und den Transfer-Vertrag. Alles andere, einschließlich DuskVM und DuskEVM, sitzt auf diesen auf.
Das ist eine merkwürdige Konzentration für eine Kette, die darauf ausgelegt ist, regulierte Assets abzuwickeln. Daher wollte ich prüfen, was diese beiden tatsächlich tun und ob sie später geändert werden können.
Der Stake-Vertrag verfolgt Provisioner: wie viel sie staken, wann Belohnungen reifen und wann Slashing greift. Der Transfer-Vertrag verarbeitet sowohl öffentliche (Moonlight) als auch verschlüsselte (Phoenix) Guthaben und ist der einzige Ort, an dem tatsächlich eine Vertrags-zu-Vertrags-Zahlungsbewegung stattfindet. Jede Ausführungsumgebung wird für die Abwicklung und Datenverfügbarkeit über ihn geleitet, wie es die aktuelle Dokumentation beschreibt.
Warum das wichtig ist: Wenn du auf DuskEVM aufbaust oder Assets über Dusk Trade ausgibst, vertraust du nicht nur auf die Logik deines eigenen Vertrags. Du vertraust darauf, dass diese beiden Genesis-Verträge dauerhaft korrekt funktionieren, da sie die Abwicklungsbasis sind, unter der alles andere liegt.
Das konnte ich nicht eindeutig klären. Die Dokumente beschreiben, dass diese Verträge im Laufe der Zeit refaktorisiert wurden: Der Staking-Vertrag wurde neu gebaut, um ein Speicherproblem zu beheben, und später haben technische Updates seine Event-Struktur verändert. Sie sind also offensichtlich nicht im Sinne von „unveränderlich“ beim Genesis-Zeitpunkt eingefroren.
Unklar für mich ist der tatsächliche Upgrade-Pfad: Ist er diskretionär (das Protokollteam liefert ein Netzwerk-Upgrade) oder gibt es einen formalen On-Chain-Governance-Schritt, bei dem Provisioner vor Änderungen an der Genesis-Vertragslogik abstimmen? Die Dokumente, die ich gefunden habe, beschreiben, was die Verträge tun, aber nicht, wie Änderungen daran autorisiert werden.
Für eine Kette, die sich als Plattform für institutionelle Abwicklung positioniert, sollte diese Unterscheidung zwischen team-autorisertem Upgrade und von Provisionern bestätigtem Upgrade irgendwo explizit dokumentiert sein.
Hat jemand gesehen, wo @Dusk den tatsächlichen Authorization-Prozess für Änderungen an Genesis-Verträgen spezifiziert?
$DUSK #dusk
Was mir beim Durchgehen der Dusk-Dokumentation aufgefallen ist: Es existieren nur zwei Verträge. Beim Genesis-Prozess gibt es den Stake-Vertrag und den Transfer-Vertrag. Alles andere, einschließlich DuskVM und DuskEVM, sitzt auf diesen auf.
Das ist eine merkwürdige Konzentration für eine Kette, die darauf ausgelegt ist, regulierte Assets abzuwickeln. Daher wollte ich prüfen, was diese beiden tatsächlich tun und ob sie später geändert werden können.
Der Stake-Vertrag verfolgt Provisioner: wie viel sie staken, wann Belohnungen reifen und wann Slashing greift. Der Transfer-Vertrag verarbeitet sowohl öffentliche (Moonlight) als auch verschlüsselte (Phoenix) Guthaben und ist der einzige Ort, an dem tatsächlich eine Vertrags-zu-Vertrags-Zahlungsbewegung stattfindet. Jede Ausführungsumgebung wird für die Abwicklung und Datenverfügbarkeit über ihn geleitet, wie es die aktuelle Dokumentation beschreibt.
Warum das wichtig ist: Wenn du auf DuskEVM aufbaust oder Assets über Dusk Trade ausgibst, vertraust du nicht nur auf die Logik deines eigenen Vertrags. Du vertraust darauf, dass diese beiden Genesis-Verträge dauerhaft korrekt funktionieren, da sie die Abwicklungsbasis sind, unter der alles andere liegt.
Das konnte ich nicht eindeutig klären. Die Dokumente beschreiben, dass diese Verträge im Laufe der Zeit refaktorisiert wurden: Der Staking-Vertrag wurde neu gebaut, um ein Speicherproblem zu beheben, und später haben technische Updates seine Event-Struktur verändert. Sie sind also offensichtlich nicht im Sinne von „unveränderlich“ beim Genesis-Zeitpunkt eingefroren.
Unklar für mich ist der tatsächliche Upgrade-Pfad: Ist er diskretionär (das Protokollteam liefert ein Netzwerk-Upgrade) oder gibt es einen formalen On-Chain-Governance-Schritt, bei dem Provisioner vor Änderungen an der Genesis-Vertragslogik abstimmen? Die Dokumente, die ich gefunden habe, beschreiben, was die Verträge tun, aber nicht, wie Änderungen daran autorisiert werden.
Für eine Kette, die sich als Plattform für institutionelle Abwicklung positioniert, sollte diese Unterscheidung zwischen team-autorisertem Upgrade und von Provisionern bestätigtem Upgrade irgendwo explizit dokumentiert sein.
Hat jemand gesehen, wo @Dusk den tatsächlichen Authorization-Prozess für Änderungen an Genesis-Verträgen spezifiziert?
$DUSK #dusk
Haftungsausschluss: Enthält Meinungen von Drittanbietern. Keine Beratung. Binance AI wird ohne Gewähr bereitgestellt. Siehe AGB.