@Dusk_Foundation ‎Eine Gründungsverfassung eines Landes existiert genau dann, wenn das Land existiert – niemand „wählt“ sie nachträglich ein; sie ist einfach von Tag eins an da, und alles andere wird unter Bezugnahme darauf aufgebaut.
‎
‎Dusk's Genesis-Contracts funktionieren auf die gleiche Weise. Dusk's eigene Architekturmaterialien beschreiben zwei: den Stake-Contract, der nachverfolgt, welche Provisioner staken, Rewards aufzeichnet und Stake-, Unstake- sowie Reward-Withdrawal-Aktionen ermöglicht; und den Transfer-Contract, der sowohl Moonlight (öffentlich) als auch Phoenix (verschlüsselt) Transfers abwickelt, Gas bezahlt und als Einstiegspunkt für die Transaktionsausführung direkt auf DuskDS dient.
‎
‎
‎Diese fundamentale Rolle geht jedoch über DuskDS allein hinaus, auch wenn sich der genaue Mechanismus je Schicht unterscheidet. DuskEVM verlagert gemäß Dusk's eigener Doku DUSK für Gas über seine eigene Bridge zu Dusk's L1 und lässt es letztlich wieder auf DuskDS zurückfließen – ein verwandter, aber eigener Pfad im Vergleich zur direkten Rolle des Transfer-Contracts in nativen DuskDS-Transaktionen. Beide Wege führen zurück zur gleichen Basisschicht; sie sind keine identischen Mechanismen. #dusk
‎
‎
‎Selbstkritik: Die Verfassungs-Analogie hat eine reale Grenze, die man beim Namen nennen sollte. Eine Verfassung eines Landes kann formell über einen festgelegten Prozess geändert werden. Was ich nicht gefunden habe, ist, ob Dusk's Genesis-Contracts einem äquivalenten, klar spezifizierten Änderungsweg folgen oder ob „Genesis“ hier funktional „dauerhaft per Design“ bedeutet – eine echte Governance-Frage, angesichts dessen, wie viel von Dusk's wachsendem Multilayer-Stack nun von denselben zwei Contracts abhängt, die korrekt bleiben müssen. $DUSK
‎
‎
‎DUSK sollte daran bewertet werden, ob diese Mehrdeutigkeit geklärt wird, bevor diese Contracts jemals unter echtem Druck aktualisiert werden müssen – nicht danach.
‎
‎

#dusk $DUSK @Dusk