Ich bin heute in den offiziellen Dokumenten von @Dusk über eine ziemlich peinliche Stelle gestolpert: In demselben Projekt widersprechen sich zwei offizielle Seiten zur Frage „Kann man Privacy Transfers jetzt tatsächlich verwenden?“, und die Aussagen passen offenbar nicht ganz zusammen.
Auf der Website von Dusk steht ganz klar: Native L1 ist im Live-Zustand – einschließlich confidential shielded transfers. Auch das Dokument zum Transaktionsmodell erklärt noch Phoenix: Es sei die native Privacy-Transfer-Variante auf DuskDS. Dabei könne man Beträge, Absender und den konkreten Note verbergen und über einen viewing key selektive Offenlegung ermöglichen.
Die Frage ist:
Die Upgrade-Dokumentation von Boreas schreibt ebenso eindeutig: **Am 10. Juni hat das Mainnet aufgehört, neue Phoenix transactions anzunehmen; auch das Testnet wurde am 7. August geschlossen.** Nach dem Upgrade wird Moonlight das weiterhin unterstützte Transaktionsmodell sein – und Moonlight ist selbst ein öffentliches Konto mit öffentlichem Guthaben und öffentlicher Transfer-Information.
Das lässt mich etwas skeptisch werden.
Wenn Phoenix bereits keine neuen Transaktionen mehr akzeptiert: Welche konkrete Produktions-Umgebungspfade sind dann mit den auf der Website aktuell genannten „Live confidential shielded transfers“ gemeint?
Meint ihr, Phoenix sei nur vorübergehend außer Betrieb und wird später von DuskVM übernommen? Oder sind die Privacy-Fähigkeiten gerade für die Migration zu Hedger vorbereitet – aber aktuell markiert die Website Hedger noch als Testnet?
Ich finde nicht, dass sich technische Roadmaps nicht ändern dürfen. Ganz im Gegenteil: Architektur-Anpassungen sind bei solchen Projekten völlig normal.
Was mich wirklich stört, ist Folgendes: Bei einem Projekt, das „regulated onchain finance“ in den Mittelpunkt stellt, sollten die Funktionsgrenzen klarer abgegrenzt sein als bei einem gewöhnlichen Public Blockchain.
Welche Funktionen sind bereits im Mainnet nutzbar, welche gehören zu einer historischen Architektur, welche werden gerade migriert und welche sind erst Testnet – diese Status dürfen nicht durcheinander beschrieben werden. Denn wenn Institutionen wirklich anbinden, geht es nicht um einen Satz wie „privacy built in“, sondern darum, wem diese Fähigkeit heute konkret bereitgestellt wird, in welcher Schicht sie läuft und wo die Verantwortungsgrenze liegt, wenn etwas schiefgeht.
Noch interessanter: Dusk hat dieses Jahr extra Pituitary gebaut, um „Divergenz zwischen Dokumentation, Spezifikationen und Code“ zu erkennen.
Ich habe deshalb eher den Eindruck, dass auch die eigene, öffentliche Dokumentation von @Dusk zuerst einmal einmal durchlaufen sollte.
#dusk $DUSK @Dusk
Auf der Website von Dusk steht ganz klar: Native L1 ist im Live-Zustand – einschließlich confidential shielded transfers. Auch das Dokument zum Transaktionsmodell erklärt noch Phoenix: Es sei die native Privacy-Transfer-Variante auf DuskDS. Dabei könne man Beträge, Absender und den konkreten Note verbergen und über einen viewing key selektive Offenlegung ermöglichen.
Die Frage ist:
Die Upgrade-Dokumentation von Boreas schreibt ebenso eindeutig: **Am 10. Juni hat das Mainnet aufgehört, neue Phoenix transactions anzunehmen; auch das Testnet wurde am 7. August geschlossen.** Nach dem Upgrade wird Moonlight das weiterhin unterstützte Transaktionsmodell sein – und Moonlight ist selbst ein öffentliches Konto mit öffentlichem Guthaben und öffentlicher Transfer-Information.
Das lässt mich etwas skeptisch werden.
Wenn Phoenix bereits keine neuen Transaktionen mehr akzeptiert: Welche konkrete Produktions-Umgebungspfade sind dann mit den auf der Website aktuell genannten „Live confidential shielded transfers“ gemeint?
Meint ihr, Phoenix sei nur vorübergehend außer Betrieb und wird später von DuskVM übernommen? Oder sind die Privacy-Fähigkeiten gerade für die Migration zu Hedger vorbereitet – aber aktuell markiert die Website Hedger noch als Testnet?
Ich finde nicht, dass sich technische Roadmaps nicht ändern dürfen. Ganz im Gegenteil: Architektur-Anpassungen sind bei solchen Projekten völlig normal.
Was mich wirklich stört, ist Folgendes: Bei einem Projekt, das „regulated onchain finance“ in den Mittelpunkt stellt, sollten die Funktionsgrenzen klarer abgegrenzt sein als bei einem gewöhnlichen Public Blockchain.
Welche Funktionen sind bereits im Mainnet nutzbar, welche gehören zu einer historischen Architektur, welche werden gerade migriert und welche sind erst Testnet – diese Status dürfen nicht durcheinander beschrieben werden. Denn wenn Institutionen wirklich anbinden, geht es nicht um einen Satz wie „privacy built in“, sondern darum, wem diese Fähigkeit heute konkret bereitgestellt wird, in welcher Schicht sie läuft und wo die Verantwortungsgrenze liegt, wenn etwas schiefgeht.
Noch interessanter: Dusk hat dieses Jahr extra Pituitary gebaut, um „Divergenz zwischen Dokumentation, Spezifikationen und Code“ zu erkennen.
Ich habe deshalb eher den Eindruck, dass auch die eigene, öffentliche Dokumentation von @Dusk zuerst einmal einmal durchlaufen sollte.
#dusk $DUSK @Dusk