Bin durch Jahre der eigenen Materialien von @Dusk zurückgegangen und habe begonnen, jeden internen Komponentennamen aufzulisten: Rusk, Piecrust, DuskDS, DuskEVM, Lightspeed L2, Superbridge, Dusk Pay, Dusk Vault. Das ist ziemlich viel Namenswechsel für die Kernarchitektur einer einzigen Kette über ungefähr sechs Jahre Entwicklung.
hmmm .Ein Teil davon ist normal — Projekte benennen Dinge um, branden VMs neu, fügen neue Module hinzu, wenn der Umfang wächst. Aber das Muster hier ist es wert, hervorgehoben zu werden: Einige davon sind keine Ergänzungen, sondern Ersetzungen oder Neuverortungen früherer Komponenten. Das datenschutzorientierte VM ist mindestens einmal umbenannt worden, bevor DuskEVM als parallele, EVM-kompatible Ausführungsschicht auftauchte. „DuskDS“ erscheint in der Roadmap-Sprache von 2026 als die datenschutzorientierte Schicht, mit der DuskEVM zusammengeführt werden soll — bedeutet: Sogar jetzt, nach dem Mainnet, wird die Architektur weiterhin als im Zusammenwachsen begriffen beschrieben, statt als abgeschlossen.
Für institutionelle Prüfer, die technische Due Diligence durchführen, ist Namenschaos kein bloßes kosmetisches Detail. Es spiegelt meist tatsächliches Design-Churn wider — Komponenten werden umgescoopt, neu gebaut oder währenddessen neu gedacht. Das ist im Pre-Mainnet-Forschung & Entwicklung normal. Es ist ein anderes Signal sechs Monate nach dem Mainnet-Launch, wenn die „Core Infrastructure“ der stabile Teil sein soll, gegen den Institutionen Custody- und Compliance-Tools aufbauen.
Nichts davon bedeutet, dass die aktuelle Architektur falsch ist. Es bedeutet, dass die sechsjährige Historie zeigt, dass das Projekt auch nach dem Launch weiterhin aktiv auf sein eigenes Design hin konvergiert.
Ab wann hört das architektonische Namens-Churn auf, eine Iteration zu sein, und wird zu einem Signal, dass sich das Kerndesign tatsächlich nicht stabilisiert hat?$DUSK #dusk
hmmm .Ein Teil davon ist normal — Projekte benennen Dinge um, branden VMs neu, fügen neue Module hinzu, wenn der Umfang wächst. Aber das Muster hier ist es wert, hervorgehoben zu werden: Einige davon sind keine Ergänzungen, sondern Ersetzungen oder Neuverortungen früherer Komponenten. Das datenschutzorientierte VM ist mindestens einmal umbenannt worden, bevor DuskEVM als parallele, EVM-kompatible Ausführungsschicht auftauchte. „DuskDS“ erscheint in der Roadmap-Sprache von 2026 als die datenschutzorientierte Schicht, mit der DuskEVM zusammengeführt werden soll — bedeutet: Sogar jetzt, nach dem Mainnet, wird die Architektur weiterhin als im Zusammenwachsen begriffen beschrieben, statt als abgeschlossen.
Für institutionelle Prüfer, die technische Due Diligence durchführen, ist Namenschaos kein bloßes kosmetisches Detail. Es spiegelt meist tatsächliches Design-Churn wider — Komponenten werden umgescoopt, neu gebaut oder währenddessen neu gedacht. Das ist im Pre-Mainnet-Forschung & Entwicklung normal. Es ist ein anderes Signal sechs Monate nach dem Mainnet-Launch, wenn die „Core Infrastructure“ der stabile Teil sein soll, gegen den Institutionen Custody- und Compliance-Tools aufbauen.
Nichts davon bedeutet, dass die aktuelle Architektur falsch ist. Es bedeutet, dass die sechsjährige Historie zeigt, dass das Projekt auch nach dem Launch weiterhin aktiv auf sein eigenes Design hin konvergiert.
Ab wann hört das architektonische Namens-Churn auf, eine Iteration zu sein, und wird zu einem Signal, dass sich das Kerndesign tatsächlich nicht stabilisiert hat?$DUSK #dusk
