小饼的撸毛日记

朋友跑 Dusk 验证者，问我他节点连续错过出块被罚了，这算不算恶意。我一开始觉得罚没就是罚没，Cosmos 那套双签直接关小黑屋，没什么好辩的。

后来翻 Dusk 的罚没机制，发现它分两种。Soft Slashing，软惩罚，专门管非恶意过失，比如节点该出块时掉线、没在窗口期内广播，不涉及作恶，就是运维出问题。惩罚是每次连续违规扣 N 乘 10% 的质押权益，N 是连续违规次数，同时把节点从共识里踢出去 N 个 epoch，epoch 是 Dusk 的共识周期，每轮结束验证者集合轮换一次。罚掉的 DUSK 不销毁，从活跃质押里划走，节点能自己取回。

Hard Slashing，硬惩罚，管恶意行为。生成无效区块扣 10% 质押并销毁，双重投票或双重出块扣 20% 并销毁。销毁是真的没了，不是锁一阵再还。

我没想通为什么要分两种。后来看文档里关于可追责性的部分才明白。节点只是网络波动错过出块，你就重罚，验证者会把节点放最贵的云上，运维成本高，去中心化反而变差。Soft Slashing 的作用是把不靠谱的节点从活跃集合里挤出去，给机会恢复，每次罚一点，不会让诚实运维的人破产

真正让我改变判断的是 N 的设定。连续违规越多，扣的越多，踢出去时间越长。第一次掉线扣 10% 移除 1 个 epoch，第二次 20% 移除 2 个 epoch，指数级压力，节点要么恢复稳定，要么自动离场。Hard Slashing 留给明确作恶，一次销毁，没有恢复窗口

拿 Polkadot 比。Polkadot 的 Slashing 也分级，但惩罚比例更细，从 0.1% 到 100% 都有，罚款分给举报者。Dusk 这套更简单，要么过失要么恶意，比例固定，销毁不奖励举报。好处是验证者能预测犯错代价，不会因复杂规则不敢跑节点

朋友听完说这次 Soft Slashing 认了，家里网络掉了半小时。我也明白 Dusk 为什么把机制分这么清。没有分级惩罚，诚实节点和作恶节点一视同仁#dusk $DUSK @Dusk

Ich habe an dem Tag die Node-Dokumentation von Dusk durchgesehen. In den offiziellen Mindestanforderungen für Provisioner-Nodes steht: 2 CPU-Kerne, 4 GB RAM und 50 GB Speicher. Sieht nach nicht viel aus, oder? Das könnte doch auch eine normale Cloud-Serverinstanz schaffen.

Aber ich habe zufällig auch die Archive-Node nachgeschlagen: 4 CPU-Kerne, 8 GB RAM und 500 GB Speicher. Die Prover-Node ist noch drastischer: Für einen einzelnen Worker braucht man 1 Kern plus 1 GB RAM, die Mindestkonfiguration liegt bei 4 Kernen und 8 GB.

Ich frage mich: Dasselbe Netzwerk – warum unterscheiden sich die Hardwareanforderungen zwischen den Nodes so stark?

Bei der Konsens-Designanalyse von Dusk habe ich dann verstanden, was dahintersteckt. SBA teilt die Teilnehmer in zwei Typen ein. Eine Art ist Block Generator: Über Proof-of-Blind-Bid wird per Lotterie ausgewählt, sodass Blöcke anonym erzeugt werden. Die andere Art ist Provisioner: Sie sind für die Abstimmungsvalidierung und das endgültige Festlegen der Blöcke zuständig. Für jeden erfolgreich erzeugten Block erhalten 1 Generator und 192 Provisioner eine Belohnung. Das Abstimmungskomitee der Provisioner wird in jeder Runde deterministisch neu ausgelost.

Provisioner müssen die Gültigkeit der Blöcke prüfen, ZK-Proofs kontrollieren, BLS-Signatur-Abstimmungen broadcasten – und das in jeder Runde. Der Generator ist dran, wenn er ausgewählt ist, dann arbeitet er; die Provisioner müssen jederzeit bereit sein. Archive-Nodes müssen nicht nur den Konsens laufen lassen, sondern auch die komplette Kette mitsamt Historie speichern. Prover-Nodes sind spezialisiert darauf, ZK-Proofs zu generieren – das ist rechenintensiv und läuft im Wesentlichen single-threaded.

Ich hatte vorher gedacht, dass PoS-Netzwerke alle ähnlich funktionieren: Viel staken, dann kann man Nodes betreiben. Später habe ich gemerkt, dass Dusk ganz und gar nicht so ist. Die Hardwareanforderungen unterscheiden sich bei den einzelnen Node-Typen massiv. Generatoren arbeiten anonym per Losverfahren, Provisioner stimmen im Komitee ab, Prover tragen die ZK-Berechnung, Archive speichern die vollständige Historie – jede Schicht frisst andere Hardware-Ressourcen.

Aber noch mehr beschäftigt mich Folgendes: Dusk hat jetzt 206 aktive Provisioner. Die ersten 20 kontrollierten bereits über 35 % des gesamten Stakes. Nachdem die Hardwareanforderungen in Schichten aufgeteilt sind, können Archive- und Prover-Tasks von vornherein nur wenige Leute ausführen – und sehr wahrscheinlich sind das auch diejenigen mit den meisten Einsatzmitteln. Es liegt nicht nur an der Verteilung der Tokens; die Hardware-Hürde selbst ist bereits das erste Filter. Normale Kleinanleger kommen nicht mal bis zur Tür durch – sie müssen ihre Coins höchstens in den Hyperstaking-Pool geben, damit andere sie für sie übernehmen.

Jetzt, wo ich Dusk hinsichtlich Dezentralisierung anschaue, wird mir klar: erst die Node-Dokumente prüfen, dann die tatsächliche Anzahl der drei Node-Typen im Betrieb betrachten, und schließlich die Verteilung des Stakes der Validatoren ansehen. Wenn diese drei Daten nicht zusammenpassen, ist „Dezentralisierung“ eher eine Worthülse. #dusk $DUSK @Dusk

Als ich zum ersten Mal Dusk untersuchte, war ich gegenüber „Private Finance“ ein wenig skeptisch. Früher bedeuteten viele Projekte mit Privatsphäre im Grunde nur „verstecken“. Aber wenn es um Institutionen und regulierte Märkte geht, ist das nicht so einfach. Das Finanzsystem braucht nicht etwas Unsichtbares, sondern etwas, das sich bei Bedarf nachweisen lässt.

Später habe ich die Dusk-Citadel-Unterlagen erneut durchgesehen und gemerkt, dass ich es zuvor falsch verstanden hatte. Citadel zerlegt die Identitätsprüfung in zwei Schritte. Im ersten Schritt sendet der Nutzer eine On-Chain-Transaktion und fügt eine Stealth-Adresse hinzu, die nur er selbst kontrollieren kann. Der Lizenzgeber scannt die Kette fortlaufend: Sobald er die an ihn gerichtete Anfrage sieht, gilt die Verifizierung als erfolgreich. Dann prägt er die Lizenz in genau diese Adresse, und der Nutzer scannt den Link, um sie abzuholen. Im zweiten Schritt nutzt der Nutzer die Lizenz, um einen Dienst zu beantragen: Er sendet erneut eine On-Chain-Transaktion, die einen Zero-Knowledge-Beweis enthält – als Nachweis, dass er über eine gültige Lizenz verfügt. Gleichzeitig berechnet er ein Session-Cookie: ein Wert, der mit On-Chain-Daten verifizierbar ist und dessen Bedeutung nur Nutzer und Dienstanbieter kennen. Das Cookie wird über einen verschlüsselten Kanal an den Dienstanbieter gesendet. Der Dienstanbieter prüft dann auf der Kette die Session-ID; passt sie, wird freigegeben. Alles geschieht durchgehend on-chain – aber außer Nutzer und Dienstanbieter weiß niemand, wer welche Anfrage stellt.

Die Anzahl der Constraint des Zero-Knowledge-Beweis-Systems liegt bei etwa 35.000. Die Generierung des Beweises dauert ungefähr ein paar Dutzend Sekunden, während die on-chain-Verifizierung nur 0,007 Sekunden in Anspruch nimmt. Für Nutzer bedeutet das: einmalig beim Antrag ein paar zusätzliche Sekunden warten. Danach liegt die Validierung im Millisekundenbereich. Außerdem kann die Lizenz im Voraus widerrufen werden, sodass man nicht auf das Ablaufdatum warten muss. Daher hat diese Generierungszeit keinen großen Einfluss auf die Gesamtleistung des Protokolls.

Citadel muss fünf Dinge sicherstellen: Dass der Beweis belegt, dass du tatsächlich eine Lizenz hast, ohne zusätzliche Informationen offenzulegen; dass der Dienstanbieter widerrufen kann, aber die Gültigkeit erhalten bleibt, bis die Lizenz tatsächlich widerrufen wird; dass deine Aktivitäten nicht zurückverfolgbar sind; dass der Beweis nicht doppelt verwendet werden kann; und dass nur die nötigen Informationen offengelegt werden. Diese fünf Eigenschaften – zusammen mit den Moat-Entwicklertools, die bereits als SDK verpackt sind – bilden den Kern der Dusk-Identity-Schicht: Sie steht auf einer Ebene mit DuskDS und DuskVM. Sie ist keine eigenständige Privatsphäre-Lösung, sondern entscheidet darüber, wer berechtigt ist, die öffentlichen Transaktionen von Moonlight und die privaten Transaktionen von Phoenix durchzuführen.

Als ich das gelesen hatte, blieb ich kurz stehen und dachte an etwas. Ein wirklich ausgereiftes Privatsphärensystem bedeutet nicht, dass alles unsichtbar ist, sondern dass unterschiedliche Rollen nur das sehen, was sie sehen sollen. Wenn Assets in Zukunft on-chain gehen, liegt der Wettbewerb nicht darin, wer am meisten verbirgt #dusk $DUSK @Dusk

Beim Forschen über Dusk war es DuskEVM, auf das ich beim ersten Blick zuerst starrte. Als ich früher Projekte angeschaut habe, war ich daran gewöhnt: Man schaut zuerst auf die Ausführungsumgebung – ob Entwickler hereinkommen, entscheidet darüber, ob eine Kette eine Zukunft hat.

Nachdem ich die Unterlagen durchgegangen war, schaute ich noch einmal zurück. Diesmal war es wirklich DuskDS, das mich zum Stehen brachte.

Ich dachte früher immer, die größte Hürde beim On-Chain-Gehen von Finanzen seien Geschwindigkeit und Kosten. Aber als ich das Design von Dusk auseinanderlegte, merkte ich: Das eigentlich Schwierige ist etwas anderes. Wenn eine Transaktion ausgeführt ist – wer bestätigt dann, dass sie wirklich im endgültigen Zustand angekommen ist?

Dusk trennt Ausführung und Abrechnung in zwei Ebenen. DuskEVM führt die Anwendungen aus, basiert auf OP Stack; Solidity-Entwickler können mit Hardhat und MetaMask direkt deployen. Der Sequencer verarbeitet Transaktionen, der Batcher verpackt die Daten zu einem EIP-4844-Blob und lädt sie auf DuskDS hoch. DuskDS kümmert sich nicht darum, welche Anwendungen oben laufen. Es geht ihm nur um Konsens, Datenverfügbarkeit und die Bestätigung des endgültigen Zustands.

Ich habe lange auf den Teil rund um DuskDS gestarrt, bis ich wirklich verstanden habe, was es tut. Es läuft Succinct Attestation, ein auf einem Komitee basierendes PoS-Protokoll. In jeder Runde schlägt ein Provisioner einen Block vor, ein Komitee verifiziert ihn, und ein weiteres Komitee bestätigt ihn. Sobald bestätigt, liegt eine deterministische Finalität vor – anders als bei Bitcoin, wo es nur probabilistische Finalität gibt. Im Normalfall gibt es keine Reorganisationen, die Nutzer spüren können. Um Provisioner zu werden, ist eine Mindest-Stake von 1000 DUSK erforderlich, der Knoten muss 7×24 online sein; wenn man zu lange offline ist oder böswilliges Verhalten zeigt, wird man bestraft.

Erst bis zu diesem Punkt wurde mir klar, was ich vorher übersehen hatte: Ich hatte geglaubt, der größte Wert einer Blockchain sei, Transaktionen schneller zu machen. Aber der Finanzmarkt hat vor allem Angst vor etwas, das noch schlimmer ist als Langsamkeit – vor Unsicherheit. Bei einer Börsentransaktion ist das Vermögen zwar übertragen, aber die Zahlung läuft nicht synchron an, oder die verschiedenen Beteiligten sehen nicht denselben Zustand. Selbst wenn die Effizienz hoch ist, wird es niemand wagen, es zu nutzen.

Die deterministische Abrechnung von Dusk löst im Kern genau dieses Problem. Wenn die Finalität auf zwei bis drei Sekunden gedrückt wird und dazu die Auslieferung als native Workflows für die Zahlung integriert ist, entsteht in Abrechnungsszenarien im Finanzbereich ein echter praktischer Nutzen.

Natürlich muss dieses Design am Ende noch durch die Ökosystem-Praxis bestätigt werden. Der Ausbau der Infrastruktur ist nur der erste Schritt – der eigentliche Wert hängt davon ab, ob Assets und Anwendungen auch wirklich einsteigen wollen.

Aber nach dem Studium von Dusk hat sich meine größte Veränderung so angefühlt: Ich schaue nicht mehr nur darauf, wie viele Transaktionen eine Kette verarbeiten kann, sondern darauf, ob sie den Finanzteilnehmern Sicherheit geben kann
#dusk $DUSK @Dusk

Nachdem Dusk den Mainnet-Betrieb angekündigt hatte, habe ich nicht sofort weitergeleitet. In den letzten Jahren habe ich viele Projekte gesehen: Wenn sie live gehen, ist dort viel los, doch nach ein paar Monaten wächst der Block-Count kaum noch und die Knoten bleiben unverändert. Also habe ich dieses Mal nicht eilig geschrieben, sondern mehrere Tage lang kontinuierlich die On-Chain-Daten beobachtet.

Zuerst habe ich geschaut, ob die Blockhöhe dauerhaft steigt, ob der Block-Takt stabil ist und ob die Teilnahme wirklich mitgekommen ist. Früher habe ich den Wert einer Kette meist anhand von Werbung und Handelsvolumen beurteilt. Aber bei dieser Beobachtung ist klar geworden, was wirklich nicht lügt: Ob das Netzwerk einen Zustand kontinuierlichen Betriebs aufgebaut hat. Das ist eine eher nüchterne Einschätzung, doch je mehr ich schaue, desto mehr kann ich ihr zustimmen.

Was mich wirklich zum Stillstand gebracht hat, ist Dusk’s Succinct Attestation. Sie basiert auf DuskDS, dem zugrunde liegenden, komis­si­onsbasierten PoS-Konsensprotokoll. Dabei schlagen, validieren und bestätigen ausgewählte Provisioner die Blöcke, die per Zufall ausgelost werden. Jede Konsensrunde läuft in drei Schritten ab: Im Proposal-Phase erstellt und broadcastet ein ausgewählter Provisioner den Kandidatenblock; in der Validation-Phase prüft ein Komitee die Gültigkeit des Blocks – mindestens zwei Drittel der absoluten Mehrheit müssen zustimmen; in der Ratification-Phase bestätigt ein weiteres Komitee den Block abschließend und „besiegelt“ ihn endgültig. Sobald er die Ratification durchlaufen hat, befindet sich der Block in einem deterministischen Endzustand und wird nicht mehr zurückgerollt.

Diese Details habe ich mir zweimal durchgelesen, weil es nicht um „wahrscheinlich sichere“ Abläufe geht, sondern um: „Wenn bestätigt, dann ist es wirklich vorbei“.

Das ist für Finanzszenarien entscheidend. Viele Ketten funktionieren so, dass man etwas wartet – und es wird mit hoher Wahrscheinlichkeit nicht zurückgerollt. Aber Wertpapiere, Clearing und Abwicklung sowie konforme Vermögenswerte akzeptieren kein „mit hoher Wahrscheinlichkeit“. Sie brauchen ein eindeutiges Ergebnis: Was gestern bestätigt wurde, sollte nicht heute wieder umgestoßen werden. Früher dachte ich, Finalität sei nur ein technischer Kennwert – jetzt begreife ich, dass sie die Eintrittsschwelle dafür ist, ob Institutionen echte Vermögenswerte überhaupt darauf platzieren wollen.

Provisioner zu werden ist nicht kompliziert: Mindestens 1000 DUSK staken, und dann reicht ein Knoten. Der Knoten muss 24/7 online sein – mindestens 2 CPU-Kerne, 4 GB RAM und 50 GB Speicher. Nach dem Staking reift das Ganze nach etwa 12 Stunden; danach kann man am Konsens teilnehmen. Die Komitees werden anhand des Staking-Gewichts per Losverfahren zufällig ausgewählt – jedes Mal anders.

In diesen Tagen hat sich bei mir nicht nur das Gefühl verändert, dass ich Dusk noch mehr vertraue, sondern vor allem, dass ich viel klarer weiß, worauf ich achten muss. Für eine Infrastruktur, die Privatsphäre und konforme Finanzprozesse in den Fokus nimmt, ist das Onboarding im Mainnet nur der Startpunkt – wirklich entscheidend ist, ob das Netzwerk dauerhaft einen vertrauenswürdigen Zustand erzeugen kann #dusk $DUSK @Dusk

Als ich gerade anfing, den Dusk-Konsensmechanismus zu erforschen, starrte ich eine Weile auf das Whitepaper und verstand nicht, was mit „deterministischer Endgültigkeit“ gemeint ist. Also musste ich mir anders behelfen: Ich malte mir drei Spalten mit Zeitachsen-Vergleichen auf Papier und kämpfte mich so durch.

Ethereum nutzt Gasper für probabilistische Finalität: Blöcke müssen erst mehrere Epochs „aufstapeln“, bevor sie im Wesentlichen als sicher gelten. Solanas Tower BFT braucht ebenfalls mehrere Dutzend Sekunden, um etwas als bestätigt zu betrachten. Und wie ist es bei Dusk mit der „Succinct Attestation“? Sobald ein Block genehmigt ist, ist die Finalität hart und deterministisch – sie kommt nicht zurück.

Damals habe ich mir diese drei Linien lange angeschaut. Der Unterschied von ein paar Sekunden mag in kryptografischen Transaktionen für dich vielleicht kaum spürbar sein. Aber im Szenario von Wertpapier-Settlement sind diese Sekunden die endgültige Sicherheits-Sperre für Assets im Milliardenbereich. Du verkaufst eine Aktie an einer Börse – das Settlement (T+2) erfolgt erst nach zwei Tagen. In dieser Zeit: Wem gehören die Assets denn tatsächlich? Wenn der Blockchain-Moment des Settlements noch rückgängig gemacht werden könnte, wer würde dann echte Vermögenswerte darauf platzieren? Für Privatanleger reicht vielleicht der Satz „eher nicht rückgängig machbar“. Für institutionelle Settlements reicht das nicht – „nicht sehr wahrscheinlich“ bedeutet rechtlich und Compliance-seitig eben nicht „garantiert“.

Später habe ich erst die offiziellen Dokumente durchgesehen und verstanden, wie die Succinct Attestation genau abläuft. Nachdem ich die entsprechende Passage gelesen hatte, konnte ich endlich aufatmen – die vorherige Verwirrung hatte endlich eine Antwort. Sie ist ein permissionlesses, komiteebasiertes PoS-Konsensprotokoll. Das System wählt zufällig eine Reihe von Knoten, die „Provisioner“ heißen, um Blöcke vorzuschlagen; eine andere Gruppe von Knoten übernimmt die Verifikation. Am Ende bestätigt ein Komitee das Verifizierungsergebnis und genehmigt den Block offiziell. Sobald ein Block den Schritt „ratification“ durchlaufen hat, ist die Finalität deterministisch – im normalen Betrieb kommt es nicht zu Reorganisationen mit Blick auf Nutzer.

Das Dusk-Mainnet startet am 7. Januar 2026 offiziell. Es kann pro Sekunde mehr als 20000 Transaktionen verarbeiten. Nach sechs Jahren Entwicklungszeit ist man endlich von den Testnetzen zu dem Stadium gekommen, in dem echte Vermögenswerte laufen können. Früher war mein Verständnis von Konsensmechanismen ziemlich simpel: Wer einen Block ausgibt, bekommt die Belohnung – das schien für normale Nutzer kaum relevant. Aber Dusk hat mich gezwungen, es aus einem anderen Blickwinkel zu sehen: Die Auswahl des Konsensmechanismus beantwortet im Kern eine grundlegende Frage – kann man deinem Geld, sobald du es einzahlst, wirklich vertrauen? Die Succinct Attestation gibt darauf die Antwort: Ja, und zwar ohne dass man die drei Worte „mit gewisser Wahrscheinlichkeit“ braucht. #dusk $DUSK @Dusk

Letzte Woche habe ich im TermMax-Testnetz eine ETH-Kreditaufnahme mit Krypto-Pfand abgeschlossen. Danach habe ich in der Wallet kurz den Kontostand gecheckt. Da war plötzlich etwas Neues: ein NFT. Ich konnte mich nicht erinnern, dass ich das Ding jemals abgeholt hätte. Damals war mein Kopf total durcheinander. Mein erster Gedanke war: Ist die Wallet von irgendeinem Virus befallen oder hat mir das Testnetz irgendeinen Müll einfach per Airdrop geschickt? Ich habe es dreimal aktualisiert – es war immer noch da. Ehrlich gesagt, wurde ich ein bisschen nervös, dass mir das verpfändete ETH am Ende vielleicht doch abhandenkommt.

Dann bin ich in die offiziellen Dokumente gegangen, und ich habe fast eine halbe Stunde darin gelesen. Sogar die frühen Diskussionsbeiträge in der Community habe ich durchforstet, bis ich verstanden habe, dass das genau das GT ist, auf das ich vorher nicht so geachtet hatte. Weißt du, was die Kernlogik dahinter ist? Du nimmst einen Kredit auf, und das Protokoll mint dir direkt ein NFT. Darin wird festgehalten, wie viel Vermögen du verpfändet hast, wie viel FT du geliehen hast und welche MLTV-Parameter zu welcher Laufzeit gehören. Jede einzelne Kreditaufnahme ist ein eigenständiges NFT.

Ich habe so etwas schon mal bei einem anderen festen Zinssatz-Protokoll erlebt: Ich hatte zwar einen Teil bereits zurückgezahlt, aber das System hat weiterhin die ursprüngliche Beleihungsquote angezeigt. Das hat mich so verunsichert, dass ich dachte, ich würde schon wieder einmal ein zweites Mal etwas schulden. Später habe ich stundenlang den Support kontaktiert und geprüft – am Ende stellte sich heraus, dass es nur eine Verzögerung bei der Synchronisation des Frontends war. Aber diese Art von Angst „Hab ich das wirklich schon komplett beglichen oder nicht?“ will ich wirklich nicht noch ein zweites Mal durchleben.

Irgendwann habe ich mir dann genauer Gedanken gemacht, was an GT wirklich interessant ist. GT ist nicht nur irgendein Token. Du kannst dir GT so vorstellen, dass deine gehebelte Position zu einem handelbaren Objekt verpackt wird. Wenn du nicht bis zum Laufzeitende warten willst, kannst du es einfach verkaufen – und falls es einen Käufer gibt, werden die Schulden in der Position und die Sicherheiten zusammen an die neue Person übertragen. Das ist komplett anders als klassisches Kreditwesen: Bei traditionellem Leihen ist deine Position nur eine Abfolge von Zuständen im Vertrag. Wenn du sie an jemand anderen übertragen willst, geht das nicht einfach – du musst selbst schließen, die Sicherheiten herausnehmen, und die andere Seite muss danach wieder neu eröffnen. Das ist ein ziemliches Hin und Her. Bei GT ist die komplette Position direkt als NFT verpackt: Du kannst sie übertragen, wenn du willst, und du kannst sie verkaufen, wenn du willst. Eine Position – ein NFT. Ganz klar, ohne dass sich die Dinge gegenseitig in die Quere kommen.

Ich dachte lange, GT wäre nur eine normale Bescheinigung für Rechte. Aber jetzt verstehe ich seinen eigentlichen Wert: Es überträgt dir die vollständige Eigentümerschaft an deinem Kredit auf den Nutzer selbst – sauber und vollständig. Nach dem geplanten Go-Live im Mainnet will ich nach dem Start mehrere Positionen mit unterschiedlichen Laufzeiten eröffnen und jede einzelne Stück für Stück beobachten, wie GT den gesamten Prozess bei der Fälligkeit und Auszahlung abbildet. #termmax @TermMax

Ich dachte früher, als ich mir Privacy-Blockchains ansah: Zero-Knowledge-Beweise reichen aus, um die meisten kryptografischen Anforderungen abzudecken—solange man die Transaktionsparameter in den Beweis schreibt und die Ausführung dann einer ZK-Virtual-Machine überlässt. Doch nachdem ich das Phoenix-Transaktionsmodell von Dusk untersucht habe, habe ich diese Sicht geändert. Das wirklich Schwierige ist nicht, eine anonyme Transaktion zu erzeugen, sondern in einer komplexen Umgebung die fortlaufend wechselnden Regeln für die Privatsphäre-Rechte dauerhaft zu pflegen.

Ich finde, das Phoenix-Transaktionsmodell ist eher wie ein mehrstufiges Zutrittskontrollsystem für Bürogebäude. Normale Privacy-Contracts sind wie ein fester Schlüssel: Wenn man einen gültigen Beweis erzeugt, kann man ihn entsperren. Das Phoenix-System hingegen ist wie ein dynamischer Berechtigungsmanager: Es prüft nicht nur, ob du einen gültigen Beweis hast, sondern bewertet auch, ob die Transaktionsumgebung, die Offenlegungsberechtigungen, der Audit-Bedarf und die Compliance-Stufe den Anforderungen entsprechen. Für On-Chain-Privacy-Apps ist diese dynamische Berechtigungsprüfung wichtiger als das reine Erzeugen eines anonymen Beweises.

Dusk trennt die Privacy-Schicht und die transparente EVM-Schicht bewusst, im Grunde um ein langfristiges Problem zu lösen. Viele frühere Privacy-Chains schrieben sämtliche Privacy-Regeln direkt in die Basisschicht-Contracts, was die Änderungskosten hoch und das Upgrade-Risiko ebenfalls groß machte. Wenn die Anwendungsszenarien immer komplexer werden und die Privatsphäre-Bedürfnisse der Nutzer immer vielfältiger, lässt sich ein einzelnes anonymes Modus-Modell kaum noch für häufig wechselnde Business-Anforderungen tragen. Nach der Trennung der Konten in zwei Modi können Entwickler den Privacy-Grad viel flexibler anpassen—Privatsphäre in Transaktionen ist dann keine einzige, permanent anonyme Erlaubnis mehr.

Aber dieses Design bringt auch neue technische Herausforderungen mit sich. Wenn die Anzahl der Cross-Layer-Transaktionen steigt, nehmen die Kosten für die Zustands-Synchronisierung zu; außerdem wird die Versionskompatibilität komplizierter. Entwickler müssen mehr Zeit investieren, um die Logik der Interaktion zwischen den beiden Modi zu verstehen. Zusätzlich beeinflussen die Geschwindigkeit der ZK-Beweisgenerierung, die Integrationserfahrung mit dem Rusk SDK sowie ob institutionelle Nutzer bereit sind, zu migrieren, die reale Umsetzbarkeit.

Meiner Ansicht nach muss Dusk nicht nur prüfen, ob das Konzept der ZK-Privacy grundsätzlich funktioniert, sondern ob dieses Dual-Mode-Privacy-System von vielen Entwicklern langfristig genutzt werden kann. In Zukunft werde ich fortlaufend die Cross-Layer-Transaktionsdaten im Testnet beobachten, den Grad der Entwicklerintegration sowie die Häufigkeit, mit der sich die Privatsphäre-Rechte in echten Anwendungen ändern. Eine Frage lohnt sich zu bedenken: Wenn es in Zukunft immer mehr On-Chain-Privacy-Szenarien gibt, brauchen wir dann letztlich stärkere Kryptofähigkeiten—oder eher bessere Methoden zur Verwaltung von Privatsphäre-Berechtigungen.
#dusk $DUSK @Dusk

@TermMaxFi 之前在Aave存30天固定利率碰上参数硬编码改不动亏了小几百收益，所以我对固定利率产品的底层假设特别敏感，翻TermMax白皮书时看到有句话团队一直拿来当核心叙事，我越看越觉得是藏在暗处的阿喀琉斯之踵：“分档到期AMM，是当前链上实现固定利率的最优路径。”逻辑起点很直白——浮动利率做不了长期定价，所以用分档资金池锁死到期收益。

但有个要命的沉默：TermMax团队从没讨论过，按我个人的推演万一未来主流借贷协议原生支持固定利率分片，这套分档AMM体系是什么下场。原生分片能让浮动利率池直接划出独立的固定利率子池，不用额外部署一套独立的到期资金池。这玩意儿是DeFi借贷派眼里的长期定价圣杯。一旦主流借贷协议完成升级，那些现在绕不开独立固定利率协议的方案立马满血复活。一个能在现有借贷池里直接开固定利率仓位、不用跨协议迁移流动性的产品，和一个得单独做市、每笔成交都要匹配到期对手方的独立资金池，你选哪个？

就像当年功能机把按键交互做到极致，全触屏一来直接降维打击。分档到期AMM现在就是功能机——链上原生利率能力受限时最优雅的妥协。原生固定利率分片这根稻草落下，现有叙事可能一夜翻转。
$TMX 呢？TermMax说它价值捕获靠固定利率交易持续使用——做市锁仓靠TMX抵押，手续费分润靠TMX质押，协议收入持续销毁TMX。可原生分片催生真正的原生固定利率能力之后，谁还绕道独立的分档资金池？TMX的经济模型建在“通用借贷协议做不了固定利率”这个前提上，前提被推翻，通缩叙事

我的态度：分档AMM是当前约束下的局部最优解，别当永恒真理。底层借贷协议在进化，今天卡住长期固定利率的坎，明天一次版本迭代就跨过去。TermMax能不能从“固定利率产品商”转型成“链上利率基础设施层#termmax @TermMax

Ich habe kürzlich mehrere Gruppen von Transaktions-Streams parallel mit mehreren Konten gegen Dusk getestet. Ursprünglich dachte ich, dass Privacy-Chains vor allem Verschlüsselung und Anonymität behandeln. Als ich dann jedoch die Transaktionen von transparenten EVM-Konten und privaten ZK-Konten gemeinsam laufen ließ, merkte ich: Das eigentliche Problem ist nicht, wie man verschlüsselt, sondern wie das System die Validierung durchführt, wenn beide Arten von Transaktionen „legal“ gleichzeitig auf die Kette kommen, und zwar ohne dabei Klartext offenzulegen. Früher dachte ich, eine Privacy-Chain müsse lediglich einen bestandenen Beweis vorweisen; inzwischen glaube ich immer mehr, dass das Konfliktmanagement bei parallelen Transaktionen die zentrale Langzeit-Herausforderung für eine echte Umsetzung ist.

Das ist ein bisschen wie zwei parallele Fahrspuren in einem Einkaufsviertel. Jede Spur hat für sich betrachtet klare Verkehrsregeln und funktioniert. Aber wenn die Regeln zum Spurwechsel zwischen benachbarten Spuren nicht übereinstimmen, steht die ganze Straße irgendwann still oder es kommt sogar zu Unfällen. Genauso ist es bei Netzwerken für Privacy-Transaktionen: Dass eine einzelne ZK-Transaktion mit einem gültigen Beweis versehen ist, bedeutet nicht, dass nach dem parallelen Einreichen mehrerer Transaktionen der Zustand auf der Kette weiterhin konsistent bleibt.

Dusk kombiniert im Kern das Phoenix-Privacy-UTXO-Modell, die Moonlight-transparente EVM-Schicht, das Citadel-Abrechnungsbeweis-Modul sowie die VEP gezielte-Offenlegungs-Mechanik. Im Grunde erlaubt das Nutzern, das gewünschte Datenschutzniveau einer Transaktion selbst auszuwählen. Der Vorteil ist offensichtlich: Normale Nutzer können mit Privacy-Konten die Asset-Transaktionshistorie schützen, Institutionen können mit transparenten Konten eine regelkonforme Abwicklung durchführen, ohne durch einen einzelnen Privacy-Modus eingeschränkt zu sein. Gleichzeitig treten neue Probleme auf: Wenn eine private Transaktion einen transparenten Vertrags-Adressbereich aufrufen muss und eine andere transparente Transaktion den Kontostand eines Privacy-Kontos auslesen will—wie synchronisiert ein Node den Zustand, ohne dabei Klartext offenzulegen? In der Vergangenheit hatten viele Privacy-Chains dieses Problem nicht, weil entweder alles anonym oder alles transparent war; ein Dual-Mode-Parallelbetrieb existierte schlicht nicht.

Der Trade-off, den ich nun sehe, ist klar. Mit steigender Privacy-Flexibilität steigt auch die Komplexität der Zustandsvalidierung; je mehr Konten im Dual-Mode, desto höher sind die Kosten für die Generierung von ZK-Beweisen. Wenn Cross-Layer-Transaktionen häufiger werden, verschwimmen zudem die Grenzen dessen, wie Gas bemessen wird und wo die Audit-/Rückverfolgbarkeit beginnt oder endet. Kennzahlen wie Cross-Layer-Transaktionslatenz, die Quote fehlgeschlagener Beweisvalidierungen und die für gezielte Offenlegungen benötigte Prüfzeit könnten die Reife der Umsetzung einer Privacy-Blockchain sogar besser widerspiegeln als TPS.

In Zukunft werde ich weiterhin die Cross-Layer-Transaktionsdaten im Testnetz, die offiziellen Updates zu Konfliktbehebungen sowie die Art und Weise, wie Nodes Dual-Mode-Paralleltransaktionen handhaben, kontinuierlich beobachten.#dusk $DUSK @Dusk

Ich habe gerade die Test-Interaktionen nach 7 Tagen TermMax im Liquiditätsbecken abgeschlossen. Die meisten Gespräche auf dem On-Chain-Weg drehen sich um festverzinsliche, fixe Zinssätze auf der Kette – man fragt vor allem: Ist die Rendite hoch genug? Kaum jemand spricht offen an: Was passiert, wenn das Order-Matching falsch läuft oder es Probleme bei der Auszahlung der Gelder gibt? Wer steht dafür ein? Welche Konsequenzen trägt derjenige, der einen Fehler verursacht hat? Dieses Thema sieht man in traditionellen Fixed-Income-Märkten häufig, auf der Kette jedoch selten, weil Protokolle selten direkt darauf antworten. Als ich bis zu dieser Ebene ans Mainnet- und Testnet-Testing von @TermMaxFi gelangt bin, wurde mir klar, dass das die Stelle ist, an der es wirklich Können zeigt. Und nebenbei habe ich auch eine zuvor erwähnte Stelle, die nicht ganz präzise genug formuliert war, nachgebessert.

Für eine einzelne Fixed-Rate-Order müssen zur Absicherung sowohl das On-Chain Fixed-Term TimeLock Module als auch eine unabhängige Oracle-Instanz doppelt prüfen. Erst wenn das Matching abgeschlossen ist, wird es on-chain zur Beweis-/Nachweisverwaltung gespeichert. In den offiziellen Originaltexten steht, dass dieses End-to-End-Validierungs-Setup erst dann vollständig „ausgestattet“ ist, wenn die öffentliche Testphase komplett beendet ist. In dieser Phase wird gerade erst Schritt für Schritt die Abdeckung über alle Laufzeit-Pools hinweg erweitert; es bedeutet nicht, dass am ersten Tag nach dem Mainnet-Go-Live alles in vollem Umfang sofort freigeschaltet war. Die Sicherheitsleistung (Margin) der Market Maker liegt in einem isolierten Sicherheitenpool innerhalb des Protokolls. Ich habe das getestet: In der 24-Stunden-„Disput-Zone“ wird die Sicherheitsleistung direkt konfisziert, wenn nach erfolgtem Order-Fill böswillig storniert wird oder wenn absichtlich falsche Zinsen gemeldet werden, um den Markt zu stören, und ein On-Chain-Schlichtung-/Arbitrage-Knoten das erfolgreich herausfordert. Das nennt man Vertragsverletzungs-Konfiskation („违约罚没“) – die Kosten für böswilliges Verhalten sind echtes, greifbares Geld, das man nicht zurückbekommt.

Beim letzten Mal habe ich $TMX und dieses Sicherheitssystem zu allgemein beschrieben, sodass es leicht so wirken konnte, als wäre die Sicherheit, die die Market Maker hinterlegen, einfach „TMX“. Das ist jedoch nicht dasselbe. In der offiziellen Token-Offenlegungsunterlage (ich schaue auf Seite 17 im Kapitel zur Token-Verteilung) steht, dass die Rolle von TMX derzeit vier Bereiche umfasst: (1) Mining-/Ausstiegsbelohnungen für Liquiditätsanbieter, (2) Protokollgebühren bei der Erstellung und beim Einstellen von Orders, (3) TMX-Sicherheiten, die Market Maker beim Erbringen von Services selbst hinterlegen, und (4) die Governance-Stimmrechte für Zinsparameter, die nach dem Staking erhalten werden. Erst wenn TMX zu einem netzweit nativen Standard für Gebühren und Staking wird, soll das Ganze vollständig in dieser Funktion ankommen. Die offiziellen Angaben dazu lauten, dass dies erst dann als vollständig umgesetzt gilt, wenn die V2-Version der Cross-Chain-Laufzeit-Pools offiziell „läuft“ – aktuell ist man noch nicht auf diesem Stand.

Wenn man beide Zeitachsen zusammen betrachtet, wird der komplette Closed Loop für feste Zinssätze dieses Projekts gerade in einzelnen Phasen zusammengesetzt. $TMX ist derzeit eher auf Governance und frühe Anreize ausgerichtet; die eigentliche Last, die die Sicherheit der gesamten On-Chain-Geldauszahlung für das ganze Netzwerk trägt, liegt aktuell bei den Isolations-/Time-Lock-Verträgen. #termmax @TermMax

Ich habe einen ganzen Nachmittag lang die Knoten-Logdaten des Dusk-Testnetzes durchforstet. Der Eiswürfel in meinem Eistee ist auf dem Tisch komplett geschmolzen, und das Kondenswasser, das sich an der Tasse sammelte, hat einen nassen Kreis auf die Mausunterlage gezogen. Ich lege die Maus einfach auf die kabellose Ladehalterung – sitze dann fünf Minuten lang nur da und bin wie erstarrt. Plötzlich begreife ich eine Frage, die mich schon immer festgehalten hat: Es gibt inzwischen ziemlich viele Projekte für Privacy-öffentliche Blockchains. Warum hat Dusk am Ende Rusk als nativen Privacy-Virtual-Machine gewählt – statt auf EVM einfach noch eine ZK-Privacy-Erweiterung draufzusatteln? Anfangs dachte ich, es sei rein eine Entscheidung für eine technische Route. Später habe ich mir aber die offiziellen Unterlagen zu Phoenix-Transaktionsmodellen und End-to-End-Privacy immer und immer wieder durchgelesen, und da wurde mir klar: Ich habe es mir zu simpel gemacht.

Am dringendsten ist bei Privacy-Anwendungen nicht eigentlich der Zero-Knowledge-Proof selbst das Engste, sondern das Risiko von Status-Leaks über die gesamte Kette hinweg. Wenn man nur in der EVM-Transaktionsebene eine Privacy-Hülle anbringt, bleiben in den Bereichen wie Kontrakt-Speicher, Ausführungs-Stack und Event-Logs überall Klartext-Spuren. Und wenn irgendwo auch nur ein Teil davon ausläuft, ist der vorherige Privacy-Schutz praktisch umsonst gewesen. Dusk setzt deshalb schon im Kern auf ein natives Privacy-Design ab der untersten Rusk-Virtual-Machine. Gleichzeitig nutzt es PLONK-Rekursion für Status-Anker. Eine einzelne Node braucht nur 1,2 Sekunden, um die Verifizierung einer Privacy-Transaktion abzuschließen – fast viermal so schnell wie ein EVM-Ansatz mit ZK-Plugin. Kurz gesagt: Dusk trifft eine klare, nüchterne Abwägung zwischen Privacy-Tiefe, Entwicklungseffizienz und Sicherheit – statt blind dem kurzfristigen Ziel „schneller ein Ökosystem mit EVM-Kompatibilität starten“ hinterherzulaufen.

Wirklich mein Umdenken ausgelöst hat dann noch eine andere Detailstelle. Offiziell wird immer wieder betont: Die Knoten kümmern sich um die Transaktionsvalidierung – nicht darum, dass sie die Klartextdaten der Nutzer verwahren. Die Ausführung kann über den verschlüsselten Zustandsraum laufen, aber die Kontrolle über die Assets und die Schlüssel für gezielte Ansichten liegen stets bei den Nutzern selbst. Genau das hat mir klar gemacht: Dusk verändert nicht nur die Art, wie Privacy umgesetzt wird, sondern die allergrundlegendste Vertrauensbeziehung in einer öffentlichen Chain. Nämlich den Teil, der dem „müssen wir dem Knoten vertrauen?“ unterliegt, auf ein Minimum zu drücken und die Teile, die möglichst nur per Kryptographie verifiziert werden können, so weit wie möglich auszudehnen.

End-to-End-Privacy ist am Ende nur die Darstellung als Produktfeature. Dieses Vertrauensmodell – „Knoten unbemerkt, Nutzer behalten die Kontrolle“ – ist es, was @dusk_foundation wirklich zum Nachdenken wert ist und das am schwersten zu kopieren ist #dusk $DUSK @Dusk

Kürzlich habe ich mir die Fixed-Rate-AMM-Mechanik von @TermMaxFi wieder genauer vorgenommen. Ein paar Tage hat mich eine ziemlich dumme Frage ausgebremst: Wenn DeFi-Kredite in noch mainstreamigere Finanzszenarien vordringen sollen, fehlt dann eigentlich mehr nachfrage- bzw. angebotsseitige Kreditvarianz – oder braucht es eine Preisfindung, bei der Nutzer kein Risiko für Zinsvolatilität tragen müssen. Ich habe mir die vierte Sektion des Whitepapers und die echten Transaktionsdaten von der offiziellen Website einige Male nebeneinander angesehen. Ich neige zu der Annahme, dass TermMax nicht primär das Problem der „zu hohen oder zu niedrigen Zinsen“ an der Oberfläche lösen will, sondern vor allem, wie man die Kapitalkosten für On-Chain-Kredite vorhersehbar macht. #TermMax

Früher hat DeFi bei Krediten im Grunde immer den Weg über Floating-Rate-Modelle genommen. Wenn man sich geliehen hat, konnte man nur den aktuellen APY sehen und wusste schlicht nicht, ob der Zins in drei Tagen durch eine große Order auf absurd hoch gezogen wird. Ob Compound, Aave oder Morpho: Die Kapital-Effizienz wurde zwar tatsächlich verbessert, aber der Preis dafür ist, dass jeder Teilnehmer die Unsicherheit der Zinsvolatilität mittragen muss. Mehr Kredit-Tools hin oder her – aber die Stabilität der ursprünglichen, wichtigsten Kapitalkosten ist dadurch zu einem variablen Faktor geworden, der sich jederzeit ändern kann. TermMax wirkt auf mich an einer Stelle nicht so, wie man es erwarten würde: Es „poliert“ nicht einfach am Floating-Rate-Modell herum. Laut offizieller Darstellung entspricht für jeden Fälligkeitstermin ein eigener Kassenpool mit einer fest zugeordneten Zinskurve. Mithilfe von Mechanismen wie gestaffeltem Fälligkeitstrading per AMM-Market-Making und Liquiditätsschichtung wird die Kreditkostenspreizung für unterschiedliche Laufzeiten von vornherein festgezurrt. Die Logik der Zinsbepreisung bleibt von Grund auf unverändert – verändert wird stattdessen, wie vorhersehbar die zukünftigen Kapitalkosten für Nutzer werden.

Ich finde, an dieser Stelle sollte man eigentlich vor allem an der Bepreisungsschicht „herumklemmen“. Nutzer müssen nicht mehr raten, ob der nächste Block große Kreditvolumina mit sich bringt, die den Zinssatz in die Höhe schießen lassen. Und sie müssen nicht darauf wetten, dass das Protokoll plötzlich Parameter anpasst und damit das Zinsmodell verändert. TermMax nutzt gestaffeltes Fälligkeitstrading als automatisches Market-Making und legt darüber noch eine Schicht an: einen Protokoll-Reservefonds aus angesammelten Liquidationsstrafen. So werden die Zinsen für verschiedene Laufzeiten in feste Kosten übersetzt, die Nutzer direkt einkalkulieren bzw. festschließen können. $TMX Liquiditätstiefe, Zinsabweichungsrate und Risikovorsorgefonds – diese paar Parameter müssen sich ehrlich gesagt noch über die Zeit beweisen; man kann nicht jetzt schon abschließend urteilen. Aber TermMax hat mir zumindest eine Warnung ins Bewusstsein gerufen: Wenn DeFi-Kredite künftig mit Mainstream-Finanzmitteln zusammengehen, muss man nicht zwangsläufig das Floating-Rate-Playbook 1:1 übernehmen. Man kann stattdessen – unter der Prämisse, dass man die On-Chain-Dezentralitäts- und Sicherheitsmodelle schützt – versuchen, dass Nutzer zuerst zu einer feststehenden Kapitalkostenstruktur kommen.#termmax @TermMax

Ich habe früher DeFi-Protokolle nach einem einfachen, brutalen Kriterium bewertet: Je größer das TVL, desto sicherer.

Diese Logik hat mich jahrelang getragen. Aave, Morpho – bei den führenden Protokollen lagen die TVLs schnell bei mehreren Dutzend oder sogar mehreren hundert Milliarden. Das Geld war drin. Was sollte da schon passieren? Deshalb habe ich TermMax TVL „nur“ 90 Millionen tatsächlich nicht eines Blickes gewürdigt.

Was meine Meinung geändert hat, war ein lockeres Gespräch.

Ein Freund fragte mich: „Wie lange willst du dein USDC parken?“ Ich sagte: „Ich warte auf eine Gelegenheit, aber ich weiß es nicht genau.“ „Und wie hoch sind deine Finanzierungskosten in der Zwischenzeit?“ Da blieb ich kurz stehen – wenn man bei Aave Geld für variable Zinsen liegen lässt, kann der Satz heute 4 % sein und morgen 3 %, ich kann doch gar nicht beantworten, „wie hoch die Kosten sind“.

Ich legte das Handy auf den Tisch, sagte nichts mehr, und in der zweiten Hälfte des Essens war ich ein wenig abgelenkt.

Als ich dann später TermMax ernsthaft recherchierte, stellte ich fest: Es löst ein ganz anderes Problem als Aave.

Der Kern von TermMax ist die Tokenisierung von Festzinsen. Schuldverschreibungen werden in FT und XT zerlegt: FT sind zinslose Anleihen, die man vor Fälligkeit mit einem Abschlag verkauft; XT sind Token, die Anspruch auf die Erträge darstellen und sich dem Wert bis zum Verfallszeitpunkt annähern, bevor sie bei Fälligkeit auf null fallen. Zu jedem Zeitpunkt gilt: 1 FT + 1 XT = 1 Schuldverschreibung – diese Identität stellt eine transparente Preisbildung im Markt für Festzinsen sicher.

GT ist ein Leverage-Token nach dem ERC-721-Standard und repräsentiert eine eigenständige Kreditposition. Der Kreditnehmer sperrt Sicherheiten in GT und prägt die entsprechende Anzahl an FT anhand der vom Markt festgelegten maximalen Loan-to-Value-Quote (MLTV). Wenn der Wert der Sicherheiten fällt und dadurch die Loan-to-Value-Quote (LTV) die MLTV übersteigt, wird die Position liquidiert.

Beim ersten Durchlesen der Beziehung zwischen FT und XT habe ich nichts Auffälliges gesehen. Beim zweiten Mal ist mir dann der Satz aufgefallen – und nachdem es einmal „klick“ gemacht hatte, war die gesamte Logik plötzlich stimmig.

Dieses Mechanismus-Design löst ein Problem, das Aave dauerhaft nicht lösen kann: die Planbarkeit der Finanzierungskosten.

Aave ist eher wie eine On-Chain-Bank, die auf Effizienz der Kapitalflüsse schaut. TermMax ermöglicht es, dass Kreditnehmer und Kreditgeber bereits bei Beginn der Transaktion einen festen Zinssatz und eine feste Laufzeit vereinbaren. Dann fing ich an zu rechnen: Wenn ich einen Teil des zuvor brachliegenden Kapitals schon vor einem guten halben Jahr mit TermMax zu einem festen Zinssatz gebunden hätte, wüsste ich nicht nur im Voraus, wie viel ich bis zur Fälligkeit zurückbekomme – während die Limit-Order auf Erfüllung wartet, würde das Kapital auch nicht untätig herumliegen. Es würde automatisch in den Morpho-Tresor gehen, um variable Erträge zu erwirtschaften, und nach erfolgreicher Matching-Phase nahtlos in einen Festzins wechseln.

TVL ist ein Kennwert für die Größe, Festzinsen sind ein Kennwert für die Bestimmtheit.#termmax @TermMax

Ich habe die Ankündigung zur Mainnet-Einführung des Citadel-konformen Moduls von Dusk gelesen und dabei eigentlich nach den Details der Sicherheitsbegutachtung für Zero-Knowledge-Proof-Schaltkreise gesucht. Dann bin ich über die ersten offiziell namentlich genannten Kooperationspartner gestolpert und war kurz perplex – es sind keine Sicherheitsfirmen, die auf Krypto-Audits spezialisiert sind, sondern die in den Niederlanden lizenzierte digitale Wertpapierbörse NPEX und die EU-Compliance-Beratungsstelle DAC8.
Mein erster Gedanke war: Das wirkt komisch. Dusk baut eine End-to-End-Privacy-Blockchain – warum steht bei der Vorstellung des Compliance-Moduls als Erstaufgebot ausgerechnet ein Duo aus zwei lizenzierten Finanzdienstleistern und nicht ein Security-Team, das auf Kryptoangriffe und -abwehr fokussiert ist?
Als ich ein paar offizielle technische Blogposts durchgegangen bin, habe ich endlich den Sinn dahinter verstanden. Das zkUT-Compliance-Modul von Dusk ist im Kern ein Privacy-Transaktionsausführungs-„Executor“. So streng und korrekt auch die ZK-Schaltungen formuliert sind: Ob die Transaktion rechtlich sauber und regulatorisch überhaupt zulassungsfähig „landen“ kann, hängt letztlich davon ab, ob die von ihm ausgegebenen Beweise die Compliance-Anforderungen der Aufsichtsbehörden erfüllen.
Zum Beispiel: Bei einer tokenisierten Aktien-Transaktion kann Anonymität noch so perfekt sein – wenn die auf MiCA zugeschnittenen, zielgerichtet prüfbaren Anforderungen zur Nachvollziehbarkeit nicht erfüllt sind, bekommt man keine Emissionslizenz, und institutionelles Kapital traut sich nicht einzusteigen. Ebenso gilt: Bei einer institutionellen Überweisung nach Whitelist kann die Anonymität noch so gut sein – ohne Identitäts-„Whitelist“-Backing durch eine entsprechend lizenzierte Institution fehlt die Grundlage, damit sich die Transaktion im Compliance-Brokerage-System überhaupt sinnvoll weitervermitteln lässt.
Dass das Mainnet diese beiden Firmen als Erst-Partner für den Launch festlegt, bedeutet faktisch, dass die offizielle Seite eine Sache zugibt: Ob diese Compliance-Modul-Lösung am ersten Tag „verlässlich“ funktioniert, hängt nicht zur Hälfte nur an Dusk selbst – also an dessen eigenem ZK-Schaltkreis und der Logik für anonymes, aber compliancefähiges Staking – sondern die andere Hälfte liegt direkt auf den beiden lizenzierten Kooperationspartnern. Diese Erkenntnis hat mich dazu gebracht, das von ihm beworbene „End-to-End-Privacy“-Versprechen neu zu betrachten. PLONK-Rekursion zusammen mit dem Phoenix-Privacy-Transaktionsmodell sorgt dafür, dass beim Transaktionsausführungsprozess nichts unbemerkt manipuliert wird und dass der Ausführungs- und Privacy-Teil rechnerisch vertrauenswürdig ist. Aber ob die Transaktion von der Regulierung akzeptiert wird und ob sie in das traditionelle Finanzsystem eingebunden werden kann, ist eine völlig andere, unabhängige Hürde. Die technischen Codezeilen von Dusk kontrollieren diese Ebene nicht; man kann sie nur über die Anbindung an lizenzierte, compliancefähige Partner sicherstellen – indem man jede compliancefähige Transaktion so autorisiert, dass die Autorisierungsaufzeichnungen als zeitstempelbasierte, zielgerichtet verifizierbare Beweise signiert und on-chain für die spätere Prüfung durch Aufsichtsbehörden verfügbar gemacht werden.
Ich dachte ursprünglich, die Vertrauenswürdigkeit dieses Privacy-Systems sei ein Ganzes. Jetzt erst sehe ich: Es sind zwei Vertrauensebenen, die übereinander gestapelt werden. Technische Privacy-Vertrauenswürdigkeit ist nicht automatisch auch Vertrauenswürdigkeit für den regulatorischen Zugang – man muss beides getrennt betrachten. Nachdem ich diese Ebene verstanden habe, ist meine Einschätzung zum Launch dieses Compliance-Moduls
#dusk $DUSK @Dusk

Ich habe fast einen ganzen Nachmittag in die Testnet-Logs gestarrt, bis mir der Kopf rauchte. Das Eis in meinem Ice Americano auf dem Tisch war komplett durchgeschmolzen, und das Wasser, das am Becherrand kondensiert hatte, hatte sich auf meiner Mausunterlage zu einem nassen Ring ausgebreitet. Ich stellte die Maus dann einfach auf die Wireless-Ladestation und starrte fünf Minuten lang nur herum, bis mir plötzlich ein auffälliger Punkt klar wurde: Bei der PoS-Chain sind die Verifizierer-—Staking—Datensätze komplett öffentlich auf der Kette. Ein Angreifer muss nur der Staking-Adresse folgen, um die Knoten-IP herauszufinden. Bei einer Privacy-Chain sind selbst die Transaktionsbeträge verschlüsselt—aber wie könnte man den Verifizierer identitätsmäßig „nackt“ herumlaufen lassen?

Früher habe ich die Staking-Logik der Privacy-Chain einfach für ähnlich wie bei normalem PoS gehalten. Erst als ich auf Dusk stieß und das „Citadel“-Anonym-Staking-Modul fand, merkte ich: Selbst die Blockausgabe-Identität wird dort Ende-zu-Ende anonymisiert.

Anfangs dachte ich noch, es gehe einfach darum, die Staking-Adresse irgendwie zu „verstecken“ oder zu mischen. Doch als ich mir dann die ZK-Schaltkreise im Staking-Vertrag genauer ansah, wurde mir klar: Das ist nicht nur „Adressen verschleiern“. Es geht darum, dass du nicht deine Staking-Adresse und auch nicht den konkreten Staking-Betrag offenlegen musst, um dem gesamten Netzwerk beweisen zu können, dass du die Mindestanforderungen erfüllst und berechtigt bist, am Konsens teilzunehmen.

Das Citadel-Konzept mit rekursiven PLONK-Beweisen löst im Kern genau den Knackpunkt, den alle PoS-Chains nicht wirklich umgehen können: Bei Dusk, wenn Nutzer DUSK stakingen, sperren sie die Tokens in einen einheitlichen anonymen Staking-Pool. Staking-Betrag, Sperrfrist und die Adresszuordnung werden vollständig verblindet. Andere Knoten brauchen dann nur 8 Sekunden, um zu verifizieren—sie sehen weder die Zuordnung der Staking-Adresse noch können sie die Signatur der Blockausgabe mit einer konkreten Adresse in Verbindung bringen.

Aber ich muss auch ehrlich sein: Dieses Design stellt extrem hohe Anforderungen an die Genauigkeit der ZK-Schaltkreise. Wenn irgendwo eine Bedingung nicht korrekt spezifiziert oder „aus Versehen“ zu wenig eingeschränkt wird, kann das ein Risiko für gefälschte Beweise mit sich bringen. Außerdem ist der Engineering-Aufwand, um bösartige Knoten präzise zu bestrafen bzw. zu entwerten, deutlich höher als bei öffentlich einsehbaren Staking-Daten. Das wird in diesem Bereich noch laufend getestet. Ob diese Strecke wirklich durchgehend stabil läuft, muss die Zeit zeigen—aber zumindest macht es deutlich, dass Dusk mit Privatsphäre es ernst meint, und zwar schon auf der Ebene des Konsens-Basissystems. Findest du, ob die Identität von PoS-Validatoren öffentlich sein sollte—oder nicht? Schreib es in die Kommentare.
#dusk $DUSK @Dusk

Gestern Abend Überstunden gemacht und mich beim Durchscrollen des Dusk-Neuauftritts ertappt – eigentlich war ich mit der Einstellung reingegangen: „Projekt umgebaut, nur die Haut gewechselt“. Die alte Seite wollte für technische Doku immer erst durch drei, vier Links und gab gelegentlich 404 aus. Dann habe ich mich aber vor dem neuen Tech-Stack-Overlay/Layer-Stack der neuen Seite ganze 20 Minuten lang festgelesen und meine vorher nur lose zusammenhangenden Projektkenntnisse endlich alles in eine Linie gebracht.

Der neue Auftritt stapelt nicht groß Marketing – er legt den Tech-Stack von der untersten bis zur obersten Ebene offen. Ganz unten ist DuskDS: es trägt Konsens, Abrechnung und Datenverfügbarkeit. Die Konsensschicht nutzt SBA, eine committee-basierte PoS-Mechanik. Dabei werden Blockproduzenten anonym per „Proof-of-Blind-Bid“ über ein Gremium ausgewählt; die Liste der Validatoren ändert sich in jeder Runde. So ist das gestaltet, um zu verhindern, dass Validatoren im Voraus festgenagelt oder angegriffen werden, und um die Blockerstellung nicht wie in klassischem PoS von Großhaltern monopolisieren zu lassen. Die Transaktionsschicht verwendet Phoenix: basiert auf dem UTXO-Notizenmodell. Die Gelder existieren als kryptografische „notes“, kombiniert mit Pedersen-Kommitments, um Beträge zu verbergen, und einem Invalidator-Mechanismus, um Double-Spends abzuwehren. Die Knoten kümmern sich nur darum, ob die Zero-Knowledge-Beweise gültig sind. In meinem eigenen Test hatte ich zuvor Klartext in die Transaktionen gepackt – und wurde damit direkt abgewiesen. Erst da wurde mir klar: Diese Regel ist von der Konsensschicht an fest in „Hardware“ gegossen.

Als ich weiter nach oben schaute, dachte ich zuerst, Dusk Trade wäre nur ein gewöhnlicher, gekapselter Privacy-DEX. In der Demo des offiziellen Ablaufs merkte ich jedoch: Es greift direkt auf die darunterliegende Abrechnungs-Channel-Struktur zu. Das Orderbuch ist standardmäßig verschlüsselt und verwendet ElGamal-homomorphe Verschlüsselung. Orderpreis und -menge liegen on-chain komplett als Chiffre vor; die Matching-Engine rechnet mit den Chiffren, um Preis und Menge des Treffers zu bestimmen. Erst danach wird entschlüsselt, um die Transaktion abzuschließen – so werden während des ganzen Prozesses keine Order-Details offengelegt. Darüber gibt es noch eine Schicht: DuskEVM. Das ist eine Ausführungsschicht, die auf OP Stack aufgesetzt und für Dusk umgebaut wurde. Sie macht die Abrechnung direkt auf DuskDS. Wenn Sol darauf aufsetzt, kann es die Privacy-Fähigkeiten der darunterliegenden Ebene übernehmen, ohne alles neu zu erfinden. Ganz oben liegt ein Compliance-Marktworkflow: Citadel ist als native aufrufbare Modulstruktur umgesetzt. Nutzer müssen keine Passkopien übermitteln; sie weisen dem System allein über Zero-Knowledge-Beweise nach, dass sie „die Compliance-Prüfung abgeschlossen“ haben.

Früher hatte ich immer das Gefühl, der Tech-Weg von Dusk sei ein bisschen „hier ein Stück, dort ein Stück“. Erst mit dem neuen Offiziellen Auftritt, der den Full-Stack komplett ausbreitet, wurde mir klar: Das ist von Anfang an nicht nur ein Anonymitäts-Transfer-Spielzeug, sondern der Aufbau einer vollständigen, compliance-fähigen Privacy-Finanzbodenebene. Nachdem ich das durch hatte, habe ich direkt etwas DUSK nachgelegt – denn Projekte, die ihre technische Architektur so klar und offen auf den Tisch legen, sind heutzutage wirklich nicht mehr viele. #dusk $DUSK @Dusk

Ganz ehrlich, ganz am Anfang dachte ich auch, dass Dusk nur ein weiteres Plattitüden-Spiel mit „anonymem“ Storytelling ist. Bis vorletzte Woche, als ich mit der Discord-Community beim RC2-Test aufs Mainnet gestarrt habe: um drei Uhr nachts war der Iced Americano längst warm, der Gaspreis war zu niedrig und hat mich 20 Minuten lang blockiert, also hab ich sogar beim Admin rumgemotzt. Erst beim Testen habe ich gemerkt: Das ist überhaupt nicht dasselbe wie die Privacy-Chains, die ich vorher gespielt habe.

Bei den meisten Privacy-Chains steckt die Verschlüsselung auf der Ebene von Smart Contracts – als hättest du das Türschloss in dein Wohnzimmer montiert. Wenn ein Dieb ein Fenster aufbricht, sieht man im Hausinneren alles. Letztes Jahr habe ich eine beliebte Privacy-Chain getestet: Wegen einer Schwachstelle in den Contract-Berechtigungen wurden alle Transfer-Transaktionen im Testnetz als Klartext im Block-Explorer angezeigt. Die Testadresse, die ich damals hinterlassen habe, wurde zwei Monate lang von Müll-Airdrops belästigt. Dusk „verschweißt“ die Pedersen-Commitment-Verschlüsselung direkt in die SBA-Konsensschicht: Assets sind ab dem Eintritt ins Mempool im verschlüsselten Zustand. Selbst wenn ein Knoten vollständige Blockdaten bekommt, kann er nur den Zero-Knowledge-Beweis lesen, dass „die Transaktion gültig ist“ – keinen einzigen Cent Klartextbetrag, keine Adresse. Ich habe absichtlich Klartext-Transaktionsdaten in die Node-Interfaces geschoben und bekam sie direkt von der Konsensschicht zurückgewiesen, nicht mal bis zum Verifikationsschritt vorgelassen.

Früher hat mich bei Privacy-Chains am meisten das KYC-Thema genervt. Letztes Jahr habe ich eine angeblich konforme Privacy-Chain genutzt: Ich habe ein Foto des Ausweises in ein Drittanbieter-Plugin hochgeladen – und kurz darauf bekam ich Auslandstrash in Form von Finanzwerbe-SMS. Dusk’s ZkKYC ist direkt in die Rusk-Virtual-Machine eingebettet: Deine KYC-Nachweise bleiben bei dir lokal. Bei der Transaktion wird nur ein Beweis erzeugt, dass „ich die regulatorischen Anforderungen erfülle“. Selbst das Projektteam kann keine Identitätsinformationen von dir abgreifen. Und wenn der Regulator eine Audit-Ansicht anfordert, sieht er nur die vorgesehenen Transaktionen. Jetzt haben sie gerade auch die PR zusammengeführt, in der FRI+PLONK als Hybrid-Proof gemischt werden: Die Verifikation pro Einzeltransaktion liegt bei 1,4 Millisekunden. Das Gas für geheime Contracts ist sogar 67% niedriger als wenn man im EVM eine ZK-Layer drüberstülpt. Ich habe einen Test-Contract für „Bills“ deployed – weniger als 20 Zeilen Code, und das Gas hat nur 0,28 $DUSK gekostet.

Ich bin zuvor in einer alten Privacy-Chain richtig reingelaufen und habe mir ein kleines Sümmchen von knapp 2000 U vermasselt. Ich war immer der Meinung, Privatsphäre und Compliance seien natürliche Todfeinde: Entweder du baust eine komplette Anonymitäts-„Grauzone“ als Nährboden, oder du machst eine „Compliance-Chain“, die den Nutzer komplett auszieht. Nachdem ich Dusk durchgetestet habe, habe ich erst verstanden: Privatsphäre sollte nie das Feigenblatt für Grauprodukte sein. Die Vermögens- und Identitätsdaten der Nutzer müssen von Anfang an in ihrer eigenen Hand liegen. Und Compliance darf nicht auf Kosten der Privatsphäre gehen. Dusk hat den knorrigen, über fast zehn Jahre festgefahrenen Knoten schon auf der Basisschicht aufgeschnitten @Dusk
#dusk $DUSK

Der Krypto-Markt hat bereits keine Liquidität mehr, wie der A-Aktienmarkt一样#闪迪股价涨幅扩大至11%

Am Wochenende bin ich unten in dem Café am Klimagerät rumgeschlendert und habe beim Dusk-Testnet versucht, Tests zu fahren: dreimal hintereinander das Passwort falsch eingegeben und gebraucht habe ich dann knapp eine halbe Stunde, bis die 21. Transaktion durchlief. Ich habe lange auf die Ausführungsprotokolle der Rusk-VM gestarrt—vorher hatte ich ein paar alte Privacy-Chains ausprobiert. Entweder sie hingen sich tagelang auf, bevor ein Block kam, oder die Anonymisierung war so „voll“ gemacht, dass man für den Prüfzirkus der Regulatoren schlicht keine Audit-Berechtigungen mehr bekommt. Eigentlich hatte ich an diese angeblichen „Privacy-Blockchains“ schon keinen Glauben mehr—bis ich es selbst aus erster Hand probiert habe. Das ist wirklich nichts, was man nur als hübsche Schale um ein Marketing-Concept herum baut.

Ganz am Anfang war ich bei SBA-Konsens noch bei der Annahme, es sei nur ein gebrandetes PoS: Ich hab die Regeln für die Knoten durchgearbeitet und selbst zehntausendmal Double-Spend-Simulationen laufen lassen, bis es klickte. SBA (Segregated Byzantine Agreement, separiertes byzantinisches Abkommen) teilt die Knoten in zwei Ebenen: Eine Ebene ist das Blockproduktionskomitee, das Transaktionen bündelt; die andere Ebene sind stichprobenartig prüfende Validatoren, die zufällige Audits durchführen. Der Zufallscheck wird über VDF (verifizierbare Verzögerungsfunktionen) erzeugt—niemand kann im Voraus vorhersagen, wen sie als Nächstes prüfen. Der Testnetz-Browser zeigt, dass es wegen ungültiger Blöcke bei 3 Knoten zu Strafen kam, bei denen Sicherheiten einbehalten wurden. Zwei davon sind Soft Penalties: ein paar Blöcke verpasst, vorübergehend aus der Konsens-Queue rausgenommen, die effektive gestakte Menge wurde gekürzt. Der dritte ist eine Hard Penalty: erwischt mit Doppelsignatur—die zugesicherten Token wurden direkt um 20% abgezogen und verbrannt. Solche Sanktionsmechanismen setzen die Kosten für Fehlverhalten so hoch, dass der Preis für Trial-and-Error extrem groß ist.

Bei den Transaktionstests habe ich aus Versehen noch eine Null zu viel getippt—die Summe ist sofort außerhalb des Range-Proof-Bereichs gelandet, die Transaktion wurde im selben Moment zurückgeworfen. Nicht mal die Spur einer „leeren“ Transaktion blieb on-chain. Der Range Proof im Phoenix-Protokoll härtet den zulässigen Geldbereich hart ab. Zusammen mit Pedersen-Verpflichtungen, die die Gesamtmenge jedes einzelnen Postens fest einschließen, gibt es kein „aus dem Nichts“ erzeugtes Minting. Dazu kommt noch pro Transaktion eine einmalige Stealth Address, die automatisch bei jeder Überweisung gewechselt wird: Ich habe fünf Test-Coin-Transfers hintereinander gemacht—und auf der Kette lässt sich diese Folge nicht einmal auf dasselbe Konto zurückführen. Die rekursiv aggregierten PLONK-Beweise komprimieren auf 287 Byte; die Einzelprüfung dauert nur 1,8 Millisekunden. Beim Laufen war alles richtig flüssig, selbst in der Peak-Phase des Testnetzes gab’s keine Anzeichen von Stau.

Die Rusk-VM wurde komplett in Rust von Grund auf neu geschrieben und unterstützt den Standard für vertrauliche Assets nativen. Ich musste für die Bereitstellung meines TestTokens nicht mal 200 Zeilen Privacy-Code schreiben. Beim Contract-Gas lag sie um 63% niedriger als EVM plus ZK-Schicht—und sie lässt außerdem einen Einstiegspunkt für Audit-Berechtigungen für die Compliance-Seite offen. Privacy und Compliance müssen also nicht gegeneinander ausgespielt werden—man kann beides gleichzeitig abdecken. Als das Testnetz an jenem Abend durchlief, fühlte ich mich viel sicherer als bei jedem Projekt, in das ich zuvor investiert habe.
#dusk $DUSK @Dusk