#dusk $DUSK @Dusk Beim Lesen des Dusk-Whitepapers ist mir ein leicht zu übersehendes Detail aufgefallen: Die Beschreibungen verschiedener Verträge verwenden unterschiedliche Zeitformen.
In Abschnitt 6.2 werden Genesis-, Transfer- und Stake-Contracts hauptsächlich so beschrieben, wie sie derzeit funktionieren: Übertragungen, Gas-Abzug, Staking usw. Das sind die grundlegenden Infrastrukturen, die für den Betrieb des Dusk-Netzwerks erforderlich sind.
Abschnitt 6.3 hingegen verwendet bei der Einführung von Zedger und Citadel deutlich mehr zukunftsgerichtete Formulierungen, etwa „designed to be deployed“ und „will allow“.
Allein anhand der Zeitform lässt sich natürlich nicht beweisen, dass eine Funktion „noch nicht umgesetzt“ ist. Aber als Signal in einer technischen Dokumentation erinnert es zumindest daran: Das Architekturdesign im Whitepaper, bereits bereitgestellte Protokolle und die aktuell tatsächlich nutzbaren Produktfunktionen sind nicht dasselbe Konzept.
Wenn man nun erneut auf die Dusk-Website schaut, sind die verschiedenen Produktzustände bereits als Live, Building und Testnet gekennzeichnet. Das liefert uns wiederum einen konkreteren Bezugspunkt: Sollten wir bei der Diskussion einer Fähigkeit nicht ebenfalls unterscheiden, ob sie nur entworfen, bereits bereitgestellt oder بالفعل praktisch überprüfbar und nutzbar ist?
Heute konzentriert sich die Diskussion von Dusk über regulierte Finanzanwendungen auf der Blockchain immer stärker auf den vollständigen Ablauf von Investorenzugang, kontrollierter Übertragung, Offenlegung von Privatsphäre und Abwicklung.
Die Frage wird also ganz konkret:
In welchem Stadium von „Design, Deployment, verifizierbarer Nutzung“ befinden sich Zedger, XSC und Citadel derzeit jeweils?
Wenn das Ziel von Dusk darin besteht, echte regulierte Finanzmärkte zu tragen, was ist dann vom Whitepaper-Design bis zur Nutzung im realen Markt der wichtigste Schlüsselschritt, der derzeit von außen noch verifiziert werden muss?#dusk $DUSK @Dusk
In Abschnitt 6.2 werden Genesis-, Transfer- und Stake-Contracts hauptsächlich so beschrieben, wie sie derzeit funktionieren: Übertragungen, Gas-Abzug, Staking usw. Das sind die grundlegenden Infrastrukturen, die für den Betrieb des Dusk-Netzwerks erforderlich sind.
Abschnitt 6.3 hingegen verwendet bei der Einführung von Zedger und Citadel deutlich mehr zukunftsgerichtete Formulierungen, etwa „designed to be deployed“ und „will allow“.
Allein anhand der Zeitform lässt sich natürlich nicht beweisen, dass eine Funktion „noch nicht umgesetzt“ ist. Aber als Signal in einer technischen Dokumentation erinnert es zumindest daran: Das Architekturdesign im Whitepaper, bereits bereitgestellte Protokolle und die aktuell tatsächlich nutzbaren Produktfunktionen sind nicht dasselbe Konzept.
Wenn man nun erneut auf die Dusk-Website schaut, sind die verschiedenen Produktzustände bereits als Live, Building und Testnet gekennzeichnet. Das liefert uns wiederum einen konkreteren Bezugspunkt: Sollten wir bei der Diskussion einer Fähigkeit nicht ebenfalls unterscheiden, ob sie nur entworfen, bereits bereitgestellt oder بالفعل praktisch überprüfbar und nutzbar ist?
Heute konzentriert sich die Diskussion von Dusk über regulierte Finanzanwendungen auf der Blockchain immer stärker auf den vollständigen Ablauf von Investorenzugang, kontrollierter Übertragung, Offenlegung von Privatsphäre und Abwicklung.
Die Frage wird also ganz konkret:
In welchem Stadium von „Design, Deployment, verifizierbarer Nutzung“ befinden sich Zedger, XSC und Citadel derzeit jeweils?
Wenn das Ziel von Dusk darin besteht, echte regulierte Finanzmärkte zu tragen, was ist dann vom Whitepaper-Design bis zur Nutzung im realen Markt der wichtigste Schlüsselschritt, der derzeit von außen noch verifiziert werden muss?#dusk $DUSK @Dusk
