Ich habe den Abschnitt in den technischen Dokumenten zu den beiden Ausführungsumgebungen noch einmal gründlich durchgearbeitet und dabei ein tieferes Design entdeckt.
Auf der einen Seite betont das Offizielle einerseits die native Privatsphäre auf Basis des Phoenix-Modells (Zedger): Durch das Abschirmen von UTXOs und Zero-Knowledge-Beweisen wird der Datenschutz auf Protokollebene erreicht. Auf der anderen Seite will man die Entwickler-Ökosystem-Chancen von Ethereum nutzen und bringt DuskEVM heraus, das mit Solidity kompatibel ist (Hedger).
Doch auch das Offizielle hat in seiner technischen Offenlegung selbst eingeräumt: Die strukturellen Grenzen des Kontomodells bedeuten, dass es im EVM-Umfeld sehr schwer ist, eine so umfassende Anonymität und Privatsphäre wie im nativen UTXO-Modell zu erreichen.
Damit geraten Entwickler in einen unangenehmen Richtungswechsel. Wenn man es sich einfach machen und eine ausgereifte EVM-Toolchain verwenden will, muss man bei Privatsphäre und Tiefe der Compliance-Abdeckung Abstriche machen. Wenn man hingegen eine originalgetreue, auditierbare Privatsphäre möchte, muss man sich an die höhere Hürde des nativen DuskVM wagen. Fisch und Bär – beides zieht in der darunterliegenden Architektur direkt an einem Strang.
Schauen wir uns außerdem die Logik von Node-Staking und Netzwerk-Governance an, wird dieses Gefühl der Zerrissenheit noch deutlicher. Derzeit läuft das Netzwerk auf Succinct Attestation Konsens: Normale Nodes können als Validator (Provisioner) am Blockproduktionsprozess teilnehmen, indem sie 1.000 Token staken. Die dezentrale Blockproduktions-Schwelle wirkt zwar wie ein bürgernaher Einstieg, doch die wirklich wertvollen RWA-Asset-Kanäle, der NPEX-Lizenzzugang und die Verifizierung von Compliance-Identitäten liegen vollständig in den Händen von Institutionen.
So entsteht eine äußerst merkwürdige Konstellation: Retailer staken die Token unten brav und tragen die Netzwerksicherheitskosten, aber die Schicht der Compliance-Transaktionen, die tatsächlich Cashflow und hohe Aufschläge erzeugt, folgt bei den Eintrittsregeln und der Gewinnverteilung komplett dem Muster klassischer Investmentbanken. Unten: permissionless PoS. Oben: stark permissioniertes Club-Finanzwesen. Wie sollen diese beiden Logiken in Zukunft einen geschlossenen Kreis beim Erfassen von Token-Wert bilden?
Die Compliance-Erzählung ist zweifellos sexy, und das europäische MiCA-Rahmenwerk eröffnet der Compliance-Kette tatsächlich große Fantasie. Aber meiner Ansicht nach reicht es nicht, wenn die Schicht unten nur ein paar ZK-Beweise ausführt. Wenn Entwickler im Ökosystem nicht zwischen EVM-Kompatibilität und nativer Privatsphäre eine Balance finden können, und wenn gewöhnliche Token-Inhaber am Kettenrand nur dabei zusehen, wie Institutionen exklusive Kanäle spielen, dann lassen sich diese technischen Vorteile nur schwer von selbst in anhaltende Lebendigkeit auf der Kette umwandeln.
Ich werde weiter die technischen Fortschritte verfolgen, aber bevor ich echtes Geld darauf setze, müssen erst die Widerhaken in der Logik sauber entfernt werden.
#dusk $DUSK @Dusk $ETH
Auf der einen Seite betont das Offizielle einerseits die native Privatsphäre auf Basis des Phoenix-Modells (Zedger): Durch das Abschirmen von UTXOs und Zero-Knowledge-Beweisen wird der Datenschutz auf Protokollebene erreicht. Auf der anderen Seite will man die Entwickler-Ökosystem-Chancen von Ethereum nutzen und bringt DuskEVM heraus, das mit Solidity kompatibel ist (Hedger).
Doch auch das Offizielle hat in seiner technischen Offenlegung selbst eingeräumt: Die strukturellen Grenzen des Kontomodells bedeuten, dass es im EVM-Umfeld sehr schwer ist, eine so umfassende Anonymität und Privatsphäre wie im nativen UTXO-Modell zu erreichen.
Damit geraten Entwickler in einen unangenehmen Richtungswechsel. Wenn man es sich einfach machen und eine ausgereifte EVM-Toolchain verwenden will, muss man bei Privatsphäre und Tiefe der Compliance-Abdeckung Abstriche machen. Wenn man hingegen eine originalgetreue, auditierbare Privatsphäre möchte, muss man sich an die höhere Hürde des nativen DuskVM wagen. Fisch und Bär – beides zieht in der darunterliegenden Architektur direkt an einem Strang.
Schauen wir uns außerdem die Logik von Node-Staking und Netzwerk-Governance an, wird dieses Gefühl der Zerrissenheit noch deutlicher. Derzeit läuft das Netzwerk auf Succinct Attestation Konsens: Normale Nodes können als Validator (Provisioner) am Blockproduktionsprozess teilnehmen, indem sie 1.000 Token staken. Die dezentrale Blockproduktions-Schwelle wirkt zwar wie ein bürgernaher Einstieg, doch die wirklich wertvollen RWA-Asset-Kanäle, der NPEX-Lizenzzugang und die Verifizierung von Compliance-Identitäten liegen vollständig in den Händen von Institutionen.
So entsteht eine äußerst merkwürdige Konstellation: Retailer staken die Token unten brav und tragen die Netzwerksicherheitskosten, aber die Schicht der Compliance-Transaktionen, die tatsächlich Cashflow und hohe Aufschläge erzeugt, folgt bei den Eintrittsregeln und der Gewinnverteilung komplett dem Muster klassischer Investmentbanken. Unten: permissionless PoS. Oben: stark permissioniertes Club-Finanzwesen. Wie sollen diese beiden Logiken in Zukunft einen geschlossenen Kreis beim Erfassen von Token-Wert bilden?
Die Compliance-Erzählung ist zweifellos sexy, und das europäische MiCA-Rahmenwerk eröffnet der Compliance-Kette tatsächlich große Fantasie. Aber meiner Ansicht nach reicht es nicht, wenn die Schicht unten nur ein paar ZK-Beweise ausführt. Wenn Entwickler im Ökosystem nicht zwischen EVM-Kompatibilität und nativer Privatsphäre eine Balance finden können, und wenn gewöhnliche Token-Inhaber am Kettenrand nur dabei zusehen, wie Institutionen exklusive Kanäle spielen, dann lassen sich diese technischen Vorteile nur schwer von selbst in anhaltende Lebendigkeit auf der Kette umwandeln.
Ich werde weiter die technischen Fortschritte verfolgen, aber bevor ich echtes Geld darauf setze, müssen erst die Widerhaken in der Logik sauber entfernt werden.
#dusk $DUSK @Dusk $ETH