#dusk $DUSK @Dusk

‎‎Mein Vater führte über Jahre hinweg zwei getrennte Bücher für seinen kleinen Laden: eines für Barverkäufe und eines für Kreditkonten. Ich habe ihn einmal gefragt, warum man das nicht zusammenlegt. Er sagte, Bargeld müsse einfach und unmittelbar sein, Kredite müssten Laufzeiten und Nachverfolgungen abbilden, und wenn man ein einziges System beides erzwingen würde, wäre es bei beiden Aufgaben schlechter.
‎
‎Ich nahm an, dass Dusk sich irgendwann auf ein einziges Transaktionsmodell einigen würde, so wie die meisten Ketten sich auf einen Ansatz festlegen. Diese Annahme zerbrach, als ich tatsächlich nachvollzogen habe, warum Moonlight und Phoenix beide existieren.
‎
‎Moonlight ist kontenbasiert, öffentlich und unkompliziert — Dusks Dokus beschreiben es als das Modell für Salden und Anwendungslogik, die keine Abschirmung benötigt. Phoenix nutzt den UTXO-Ansatz und existiert ganz konkret, um datenschutzorientierte Abläufe zu unterstützen: abgeschirmte Transfers, selektive Offenlegung und die Bausteine, die regulierte Finanzen tatsächlich braucht, wenn vollständige Transparenz nicht akzeptabel ist.
‎
‎Wenn man diese zu einem Modell verschmelzen würde, müsste man entweder jede Transaktion durch unnötigen Datenschutz-Overhead zwingen oder den Abschirmungsfunktionen für alle, die sie brauchen, berauben.
‎
‎Der echte Test für DUSK ist, ob das Beibehalten beider Modelle tatsächlich Buildern dient, die für unterschiedliche Abläufe unterschiedliche Garantien benötigen — und nicht nur konzeptionellen Ballast hinzufügt, den die meisten Nutzer ohnehin nie anfassen.
‎
‎Was ich nirgendwo dokumentiert gefunden habe, ist, wie oft eine einzelne Anwendung in der Praxis tatsächlich beide Modelle gleichzeitig braucht.
‎
‎