Zum ersten Mal sah ich @Dusk und dachte gleichzeitig über zwei Handelssysteme nach: Moonlight und Phoenix. Dabei hatte ich eine sehr direkte Frage:
Wenn du dich auf Privatsphäre fokussierst, warum machst du dann nicht einfach alles zu Privacy-Transaktionen?
Ein Transparenz-Modell, ein Privacy-Modell – ist das nicht umständlich?
Als ich dann jedoch die Whitepaper genauer ansah, wirkte diese Art von „Zweispurigkeit“ eher wie etwas, das der Realität im Finanzwesen am nächsten kommt.
Moonlight ist recht einfach: Es basiert auf einem Kontomodell, ähnlich wie bei Ethereum. Dinge wie Kontostand, Nonce und Transaktionsstatus sind öffentlich, und die Transaktionen werden durch Signaturen verifiziert.
Phoenix folgt hingegen einer völlig anderen Logik.
Es nutzt das UTXO-Modell und führt Stealth Addresses, Nullifier und Zero-Knowledge-Proofs ein. Das Netzwerk muss nicht direkt sehen, für welche konkrete Ausgabe du Geld ausgibst oder wie hoch dein Kontostand ist – es muss lediglich die ZK-Proof prüfen: Du besitzt die Assets tatsächlich, der Kontostand reicht aus, es gibt keinen Double-Spend und die Transaktion wurde nicht verändert.
Auf den ersten Blick wirkt das, als würde man das System unnötig verkomplizieren.
In der Realität ist Finanzwesen aber ohnehin kein einheitlicher „Berechtigungs“-Standard.
Einzahlungen und Auszahlungen an Börsen sind möglicherweise eher für öffentliche Konten geeignet.
Wertpapier-Übertragungen zwischen Institutionen, Asset-Positionen und Kunden-Transaktionen hingegen könnten Privatsphäre erfordern.
Beim Audit wiederum muss man jedoch Offenlegung ermöglichen können.
Wenn man alle Geschäftsarten in ein einziges Transaktionsmodell zwängt, landet man am Ende entweder bei zu wenig Privatsphäre oder bei schlechterer Compliance.
Darum fühlt sich Moonlight + Phoenix für mich eher an wie eine Bank mit gleichzeitig „Flur“ und „Tresor“.
Im Flur muss man nichts verstecken.
Im Tresor muss man nichts für Fremde sichtbar machen.
Der entscheidende Punkt ist nicht, ob alles transparent oder alles privat ist, sondern dass unterschiedliche Gelder mit unterschiedlichen Regeln verarbeitet werden.
Das erklärt auch, warum Dusk jetzt einerseits weiterhin natives L1 betreibt und andererseits DuskEVM und Hedger entwickelt. DuskEVM bietet Solidity-Entwicklern einen vertrauten EVM-Pfad, während Hedger mit Hilfe homomorpher Verschlüsselung und Zero-Knowledge-Proofs Confidential-Transaction-Flows ergänzt.
Ich persönlich finde sogar, dass diese Route realistischer ist als der Ansatz „Alle Entwickler müssen sich noch einmal komplett etwas Neues aneignen“.
Natürlich ist das auch mit klaren Problemen verbunden.
Je mehr Module, desto komplexer wird das System. Ob Native L1, DuskEVM, Hedger und Dusk Trade am Ende wirklich einen geschlossenen Kreislauf bilden – und nicht vier Produkte, die jeweils ihre eigene Geschichte erzählen – das ist der Punkt, auf den ich weiterhin besonders achten werde.
$DUSK #dusk
Wenn du dich auf Privatsphäre fokussierst, warum machst du dann nicht einfach alles zu Privacy-Transaktionen?
Ein Transparenz-Modell, ein Privacy-Modell – ist das nicht umständlich?
Als ich dann jedoch die Whitepaper genauer ansah, wirkte diese Art von „Zweispurigkeit“ eher wie etwas, das der Realität im Finanzwesen am nächsten kommt.
Moonlight ist recht einfach: Es basiert auf einem Kontomodell, ähnlich wie bei Ethereum. Dinge wie Kontostand, Nonce und Transaktionsstatus sind öffentlich, und die Transaktionen werden durch Signaturen verifiziert.
Phoenix folgt hingegen einer völlig anderen Logik.
Es nutzt das UTXO-Modell und führt Stealth Addresses, Nullifier und Zero-Knowledge-Proofs ein. Das Netzwerk muss nicht direkt sehen, für welche konkrete Ausgabe du Geld ausgibst oder wie hoch dein Kontostand ist – es muss lediglich die ZK-Proof prüfen: Du besitzt die Assets tatsächlich, der Kontostand reicht aus, es gibt keinen Double-Spend und die Transaktion wurde nicht verändert.
Auf den ersten Blick wirkt das, als würde man das System unnötig verkomplizieren.
In der Realität ist Finanzwesen aber ohnehin kein einheitlicher „Berechtigungs“-Standard.
Einzahlungen und Auszahlungen an Börsen sind möglicherweise eher für öffentliche Konten geeignet.
Wertpapier-Übertragungen zwischen Institutionen, Asset-Positionen und Kunden-Transaktionen hingegen könnten Privatsphäre erfordern.
Beim Audit wiederum muss man jedoch Offenlegung ermöglichen können.
Wenn man alle Geschäftsarten in ein einziges Transaktionsmodell zwängt, landet man am Ende entweder bei zu wenig Privatsphäre oder bei schlechterer Compliance.
Darum fühlt sich Moonlight + Phoenix für mich eher an wie eine Bank mit gleichzeitig „Flur“ und „Tresor“.
Im Flur muss man nichts verstecken.
Im Tresor muss man nichts für Fremde sichtbar machen.
Der entscheidende Punkt ist nicht, ob alles transparent oder alles privat ist, sondern dass unterschiedliche Gelder mit unterschiedlichen Regeln verarbeitet werden.
Das erklärt auch, warum Dusk jetzt einerseits weiterhin natives L1 betreibt und andererseits DuskEVM und Hedger entwickelt. DuskEVM bietet Solidity-Entwicklern einen vertrauten EVM-Pfad, während Hedger mit Hilfe homomorpher Verschlüsselung und Zero-Knowledge-Proofs Confidential-Transaction-Flows ergänzt.
Ich persönlich finde sogar, dass diese Route realistischer ist als der Ansatz „Alle Entwickler müssen sich noch einmal komplett etwas Neues aneignen“.
Natürlich ist das auch mit klaren Problemen verbunden.
Je mehr Module, desto komplexer wird das System. Ob Native L1, DuskEVM, Hedger und Dusk Trade am Ende wirklich einen geschlossenen Kreislauf bilden – und nicht vier Produkte, die jeweils ihre eigene Geschichte erzählen – das ist der Punkt, auf den ich weiterhin besonders achten werde.
$DUSK #dusk