#dusk $DUSK Heute habe ich die technischen Dokumente zu @Dusk durchgegangen, und zwar die Passage über das Phoenix-Transaktionsmodell. Ich habe es hin und her drei Mal gelesen, bis ich es ungefähr verstanden hatte. Diese Designentscheidung fällt den meisten nicht auf, wenn sie Dusk betrachten – aber sie bestimmt, was Dusk tun kann, was andere Chains nicht können.
Ganz kurz: Die meisten EVM-Chains nutzen das Kontomodell – wie ein Bankkonto: Der Kontostand ist eine Zahl, und Überweisungen bestehen darin, von der einen Zahl etwas abzuziehen und der anderen etwas hinzuzufügen. Das UTXO-Modell ist wie Bargeld: Jede einzelne Banknote hat einen eigenen Nennwert und eine eigene Nummer, und beim Ausgeben kann man sie kombinieren. Das Kontomodell hat den Vorteil, dass Smart Contracts leicht zu schreiben sind; das UTXO-Modell hat den Vorteil, dass die Privatsphäre von Natur aus besser ist – weil jede Transaktion für sich existiert und kein globaler Zustand offengelegt werden muss.
Dusk geht mit dem Phoenix-Modell einen dritten Weg: Es kombiniert die Privatsphäre-Vorteile von UTXO mit der Smart-Contract-Fähigkeit des Kontomodells. Es nutzt ein Design namens „geheime Assets“ („vertrauliche Assets“): im Kern handelt es sich um UTXO, aber es kann Smart Contracts ausführen. So bekommt ein Mechanismus wie Hedger für vertrauliche Transaktionen einen konkreten Ankerpunkt. Nur unter einer UTXO-Struktur kannst du mit Zero-Knowledge-Proofs sowohl den Betrag als auch die Adresse einer einzelnen Transaktion beweisen; im Kontomodell ist es dagegen sehr schwer, eine ähnlich starke Privatsphäre zu erreichen, ohne die Komponierbarkeit aufzugeben.
Wenn man es so zurückdenkt, zeigt diese technische Auswahl: Dusk war von Anfang an nicht darauf aus, „noch eine weitere EVM-Chain“ zu werden. Es hat die Datenstruktur aus den Datenschutzanforderungen heraus rückwärts gewählt. Diese „anforderungsgetriebene Architektur“-Idee finde ich gut – aber der Preis ist: Die Migrationskosten für Entwickler werden höher sein als bei einer standardmäßigen EVM-Chain. Wie weit Phoenix mit Solidity kompatibel ist, und ob das Ökosystem genug Entwickler anziehen kann, um diese Lücke zu füllen, ist aktuell noch unklar.
Was meint ihr: Ist diese Abwägung „für Privatsphäre Kompatibilität opfern“ in der heutigen Marktlage eher weise oder eher riskant?@Dusk $BTC
兼容性比隐私更重要
0%
差异化才是生存之道
0%
开发者会买账吗
0%
Phoenix模型我看不懂
0%
0 Stimmen • Abstimmung beendet