_Lisa

Ich habe erwartet, dass eine für regulierte Märkte gebaute Chain mit einer langen Liste nativer Verträge ausgeliefert wird. Compliance, Identität, Registry, das Ganze – alles in Genesis mit eingebaut.
Dusk liefert zwei. Stake und Transfer.
Stake erfasst Provisioner, Stakes, Rewards und das Management des Validator-Sets. Transfer bewegt DUSK und dient als Einstiegspunkt für die Ausführung von Transaktionen und die Gaszahlung.
Das ist das gesamte Genesis-Set.
Alles Regulierte sitzt darüber. Zedger auf DuskVM, Hedger auf DuskEVM, Citadel für Identität, Dusk Trade als Produkt-Oberfläche. Nichts davon ist mit der Basis verschweißt.
Die Begründung wäre: Anforderungen ändern sich. Eignungsregeln, Offenlegungspflichten und Meldeformate passen sich an Regulierung an, und alles, was in Genesis liegt, ändert sich nur mit einem Hard Fork. Compliance-Logik in die Basisschicht zu legen würde bedeuten, dass eine Chain bei jeder Aktualisierung einer Direktive einen Fork braucht.
Der Gegenpunkt ist allerdings real. Eine dünne Basis bedeutet, dass die Garantien, um die es den Menschen wirklich geht, in Verträgen leben, die aktualisiert werden können – und Upgrade-Fähigkeit ist ein anderes Sicherheitsversprechen als Unveränderlichkeit.
Sollten die Teile, die am wahrscheinlichsten geändert werden, am weitesten vom Konsens entfernt sein – oder verlagert das nur das Risiko an einen Ort, der weniger geprüft wird?
Dünne Basis oder dünne Garantien?
#dusk @Dusk $DUSK

#dusk $DUSK @Dusk

da zwei trades heute endlich meinen Weg gingen, fühl ich mich wieder richtig gut. jetzt wollte ich mir ansehen, was @dusk eigentlich jenseits des Marktlärms aufbaut.

der Datenschutz-Teil hat mich dann auch dazu gebracht, nicht mehr weiterzuscrollen.

dusk behandelt Datenschutz nicht einfach so, dass man alles versteckt. die Idee ist viel nützlicher für regulierte finanzen: sensible informationen privat halten, wo es nötig ist, und gleichzeitig Transparenz dort ermöglichen, wo sie sinnvoll ist.

dann gibt es auch selektive Offenlegung, sodass autorisierte Parteien Informationen prüfen können, ohne dass alles für alle öffentlich gemacht werden muss.

das ist viel eine praktischere Sichtweise darauf, wie man Datenschutz für finanzmärkte denken kann.

und ganz ehrlich: nachdem ich mir das angesehen habe, fange ich an zu verstehen, warum programmierbarer Datenschutz für Onchain-Finance so viel bedeuten könnte?
#dusk

#dusk $DUSK
Ich habe Binance geöffnet, um über @Dusk zu posten, aber der Markt hat mir stattdessen eine Comedy-Show serviert. 😂

Die gestrigen Gewinner sitzen jetzt im Tab „Verlierer“ – $APR hat eine komplette Runde gedreht, ohne die Koffer zu packen, während $COW und CYS Richtung Mond gehen. 🚀

Wie auch immer… zurück zu DuskVM, wo fehlgeschlagene Transaktionen zurückgerollt werden können – im Gegensatz zu meinen schlechten Trades. 👇

Eigentlich dachte ich, der Smart-Contract-Status auf @Dusk würde als Sammlung separater Key-Value-Einträge gespeichert.

DuskVM nimmt einen anderen Weg.

Ein nativer Dusk-Contract hält seinen Status im WASM-linearen Speicher. Wenn jemand den Contract aufruft, lädt die Laufzeit diesen persistierten Speicher, lässt den Contract sein statisches State-Objekt aktualisieren und schreibt den geänderten Speicher nur dann zurück, wenn der Aufruf erfolgreich war.

Wenn der Aufruf panikt oder fehlschlägt, kehrt der Status zu seiner vorherigen Version zurück.

Das ist sauberer, als ich erwartet hatte, weil ein teilweise abgeschlossener Update nicht zurückbleiben sollte und halbfertigen Contract-Status hinterlässt. Entwickler können den Status außerdem mit gewöhnlichen Rust-Strukturen modellieren, wie z. B. Enums, Sets und Maps, statt jeden Wert manuell als isolierten Storage-Slot zu behandeln.

Aber Rollback macht die Contract-Logik noch nicht korrekt.

Der Contract selbst bleibt dafür verantwortlich, seine Eingaben zu validieren und zu entscheiden, was als Erfolg gilt. Wenn fehlerhafte Logik eine Aktion akzeptiert und normal zurückkehrt, gibt es für die Laufzeit keinen Grund, diese Statusänderung rückgängig zu machen.

Das verschiebt die Grenze auf interessante Weise.

DuskVM kann den Status vor einer fehlgeschlagenen Ausführung schützen, aber es kann eine Anwendung nicht vor einem Fehler schützen, den ihr eigener Code als gültig betrachtet.

Bietet automatisches State-Rollback die wichtige Sicherheitsgrenze – oder liegt das eigentliche Contract-Risiko immer noch größtenteils in der Input-Validierung??

Wo sitzt die echte Sicherheit von Dusk-Contracts? 👀

#dusk







Eine Bildunterschrift für diesen

Ich habe viel zu lange in der letzten Nacht an diesem Teil des Whitepapers gearbeitet.
Die meisten Proof-of-Stake-Ketten, die ich mir angesehen habe, lassen Validatoren im Grunde alles machen…

Einen Block vorschlagen, darüber abstimmen, fertig. Dusk teilt diese Aufgabe in zwei Teile.

Generatoren schlagen Blöcke vor. Provisioner validieren und finalisieren sie. Unterschiedliche Rollen, unterschiedliche Extraktionsmethoden sogar.

Generatoren werden durch einen Bietprozess „herangezogen“, Provisioner durch Komitee-Sortition. Und nein, ganz so ist es nicht. Der wirklich spannende Teil ist, dass Generatoren

privat extrahiert werden: Niemand weiß, wer den nächsten Block vorschlägt, bis er es tut. Das ist eine echte Antwort auf das Front-Running-Problem, das du bekommst, wenn die Leader-Auswahl öffentlich ist.

Ich bin immer noch nicht sicher, wie die beiden Rollen..

unter Last zusammenwirken: Verbessert das Aufteilen der Aufgabe die Resilienz oder schafft es nur mehr Stellen, an denen etwas kaputtgehen kann?

#dusk @Dusk $DUSK

#dusk $DUSK @Dusk

Jede Blockchain hat einen versteckten Interessenkonflikt.

Öffentliche Ketten wie Bitcoin oder Ethereum zeigen alles. Jede Wallet, jeder Betrag, jede Transaktion ist für alle offen. Das ist gut für das Vertrauen, aber ein Problem für echtes Geld. Würde Ihre Bank Ihr Gehalt dem ganzen Internet zeigen? Nein. Deshalb halten sich Banken und Fonds von offenen Ketten fern.

Private Ketten gehen den anderen Weg und verstecken zu viel. Wenn niemand nachvollziehen kann, was passiert, werden Regulierer es ebenfalls nicht absegnen. So entscheiden sich die meisten Projekte für eine Seite: offen und vertrauenswürdig oder privat, aber geschlossen.

Dusk versucht, sich nicht festzulegen. Transaktionen bleiben standardmäßig privat, aber Regulierer können weiterhin prüfen, was sie prüfen müssen, wenn sie es müssen. Genau diese Lücke ist es, die Dusk schließen soll.

@Dusk #Dusk $DUSK

Ich habe letzte Nacht nochmal Abschnitt 7 des Dusk-Whitepapers gelesen und bin bei etwas hängen geblieben, das ich zuvor nicht gecheckt hatte.

Die meisten Leute reden über Proof of Stake, als gäbe es nur eine Rolle: man setzt, man validiert, fertig. Dusk teilt das aber in zwei getrennte Aufgaben auf.

Generatoren schlagen den nächsten Block vor, Provisioner validieren und finalisieren ihn. Unterschiedliche Verantwortlichkeiten, unterschiedliche Extraktionsmethoden… sogar unterschiedliche Anforderungen an den Einsatz.

Was daran interessant ist: Generatoren werden über eine Art Privacy ausgewählt.

Ein Verfahren wird so aufrechterhalten, dass der/die Leader für eine bestimmte Runde nicht im Voraus bekannt ist. Provisioner werden in Komitees über einen komplett separaten Prozess hineingezogen. Zwei Rollen bedeuten: Ein Angreifer müsste den Einsatz an zwei Stellen kontrollieren, nicht nur an einer.

Ich hatte das noch nie als Rollen-Trennungsproblem beim Konsensdesign betrachtet—meistens dachte ich einfach: Mehr Einsatz heißt, man wird eher ausgewählt.

Das Aufteilen von Proposer- und Validator-Rollen.

Erhöht das tatsächlich die Kosten, um eine Kette anzugreifen, oder ist es größtenteils eine organisatorische Entscheidung??

#dusk @Dusk $DUSK

Jeder kündigt Partnerschaften an. Weniger kaufen zuerst Eigenkapital bei der Gegenpartei.
Dusk wurde 2020 Aktionär bei NPEX. Die kommerzielle Vereinbarung zum Bau einer blockchainbasierten Sicherheitsbörse kam 2024.
Vier Jahre zwischen den beiden.
Ich bemerkte, dass ich die Partnerschaft als den Anfang der Beziehung gelesen hatte. Sie war eher die Mitte.
Ankündigungen sind billig und sofort. Beteiligungen sind langsam, teuer und werden gemeldet.
Macht eine vierjährige Startbahn vor der Ankündigung die Partnerschaft glaubwürdiger oder einfach besser vorbereitet?
#dusk @Dusk $DUSK

Eine öffentliche Blockchain schafft eine für die Finanzmärkte unangenehme Situation: Transparenz ist hilfreich, aber zu viel Transparenz kann die Handelsstrategie der jeweiligen Person offenlegen.

Betrachten wir ein Orderbuch.

Wenn jede Order, jede Position und jeder Kontostand offen sichtbar ist, können Marktteilnehmer möglicherweise Rückschlüsse auf die Handelsabsichten ziehen, bevor eine Transaktion abgeschlossen ist. Für manche Finanzprodukte ist das keine kleine Unannehmlichkeit. Es kann die Ausführungsqualität direkt beeinträchtigen.

Darum finde ich DUSKs Ansatz für vertrauliche EVM-Workflows interessanter als die generische Sprache von „privaten Blockchains“.

Hedger ist darauf ausgelegt, Privatsphäre innerhalb der EVM-Umgebung mit homomorpher Verschlüsselung und Zero-Knowledge-Beweisen zu unterstützen. Eine mögliche Anwendung ist vertrauliche Orderbuch-Aktivität, bei der sensible Informationen nicht vollständig öffentlich werden müssen, nur weil sich der Markt onchain bewegt hat.

Die wirtschaftliche Frage lautet, was sich dadurch für das Marktdesign ändert.

Wenn Finanzanwendungen sensible Informationen bewahren können und gleichzeitig nachweisen, dass Transaktionen die erforderlichen Regeln einhalten, erhalten Entwickler eine weitere Designoption. Sie sind dann nicht mehr gezwungen, in der binären Wahl gefangen zu sein, entweder alles öffentlich zu zeigen oder den gesamten Workflow aus der Kette auszulagern.

Ich würde den Fortschritt an konkreten Marktmechanismen messen:

• Anzahl der verarbeiteten vertraulichen Transaktionen.
• Anzahl der Anwendungen, die datenschutzfreundliche Ausführung nutzen.
• Wachstum bei Aktivitäten mit finanziellen Assets statt mit Testtransaktionen.

Das ist nützlicher, als Erwähnungen zu zählen.

Es gibt außerdem eine offensichtliche Einschränkung. Kryptografische Privatsphäre schafft nicht automatisch einen funktionierenden Markt. Liquidität, rechtliche Struktur, Gegenparteien, Verwahrung (Custody) und Produktdesign spielen weiterhin eine Rolle.

Aber das Problem mit dem Orderbuch ist real.

Wenn Dusk sensible finanzielle Aktivitäten programmierbar machen kann, ohne sie für autorisierte Aufsicht unsichtbar zu machen, ist das eine viel konkretere Aussage als nur zu sagen, dass Blockchain Privatsphäre braucht.
#dusk $DUSK @Dusk

#dusk $DUSK @Dusk

Zwei völlig unterschiedliche Datenschutzmodelle, eine Kette. Also: welches verwendet eine Transaktion wirklich?
Ich meine… das hat mich eine Weile verwirrt, weil Moonlight konto-basiert und öffentlich ist, während Phoenix UTXO-basiert und geschützt ist. Das sind keine kleinen Unterschiede – das sind verschiedene Buchungsformen.
Die Antwort ist der Transfer-Contract. Er akzeptiert unterschiedliche Transaktionsdatenpakete – Phoenix-Stil oder Moonlight-Stil –, routet jedes an die richtige Verifizierungslogik und hält den globalen Zustand konsistent, sodass keine doppelten Ausgaben durchrutschen und Gebühren in jedem Fall korrekt behandelt werden.
Uhm, also ist es eine Tür mit zwei Gängen dahinter. Beide führen an denselben Ort.
Das Gute an diesem Design: Du wählst beim Öffnen einer Wallet nicht für immer eine feste Datenschutzeinstellung. Du wählst pro Transaktion, je nachdem, was die Situation erfordert.
Gehalt-Zahlungen solltest du lieber still halten. Bewegungen aus dem Treasury willst du vielleicht absichtlich sichtbar machen. Gleiches Konto, gleiche Kette..
Die meisten Menschen berühren diesen Contract nie direkt. Er ist die Settlement-Engine unter der Wallet. Aber zu wissen, dass er da ist, erklärt, warum die Wahl überhaupt existiert 🚀
#dusk @Dusk $DUSK

#dusk $DUSK vergangene Nacht die Dusk-Whitepaper-Section über Plonk nochmal gelesen und es hat etwas klick gemacht, das ich übersehen hatte...

die ersten beiden Male durch.
das Beweisschema versteckt nicht nur Werte, es trennt auch das, was bewiesen wird, von dem, was offengelegt wird. öffentliche Inputs gehen eine Richtung, private bleiben.

gesperrt und der Verifier erfährt nur, ob die Aussage wahr ist.
drei Eigenschaften müssen erfüllt sein, damit das überhaupt etwas bedeutet: Vollständigkeit. Korrektheit. Null.

Wissensbehaftetheit. Lass eine weg und der ganze Privacy-Anspruch fällt auseinander.
was interessant ist: das ist nicht nachträglich an die State-Transition-Funktion angebaut.

es ist naturnativ zum Rusk-VM. jeder Ausführungspfad kann einen

Korrektheitsbeweis mittragen, ohne die Berechnung selbst offenzulegen.
ich kann nicht vollständig auflösen, wie sich die Kosten der Beweiserstellung skalieren, wenn die Contract-Logik komplexer wird.

kompliziert. aber das ist der Teil, auf den ich immer wieder zurückkomme.
mal neugierig, ob jemand anders hier in das Setup für den Verifier-Key eingestiegen ist??

#dusk @Dusk $DUSK

Zwei Anwendungsfälle liegen nebeneinander in den Dusk-Dokumenten, und ich denke, sie gehören zusammen, mehr als die Liste vermuten lässt.
Vertrauliche Zahlungen zwischen Institutionen. Lieferung versus Zahlungsausgleich tokenisierter Vermögenswerte.
DvP ist die einfache Idee, dass sich das Asset und das Geld gemeinsam bewegen – oder dass sich keines bewegt. Es existiert, weil die Alternative darin besteht, dass eine Seite einen Wert übergibt und wartet.
Jetzt setz die Vertraulichkeit daneben.... zwei Institutionen, die einen Handel abwickeln, bei dem beide Seiten gleichzeitig und als Ganzes (atomar) abgewickelt werden, und bei dem Größe, Gegenpartei und Konditionen nicht zu öffentlicher Information werden, sobald es passiert.
„Atomar und unsichtbar sind normalerweise Gegensätze. Atomar bedeutet, dass jeder es als gelöst sehen kann. Unsichtbar bedeutet, dass es niemand kann.“
Ähm, und genau da liegt der Trick. Beweisen, dass beide Beine abgeschlossen wurden, ohne zu veröffentlichen, was abgeschlossen wurde.
Auf einer transparenten Kette erhältst du Atomarität und verlierst Vertraulichkeit. In einer traditionellen Abwicklung erhältst du Vertraulichkeit und verlierst Atomarität – weshalb die Clearing-Schicht überhaupt existiert.
Ich bin mir nicht sicher, wie viel Volumen tatsächlich beides gleichzeitig braucht. Aber die Institutionen, die es brauchen, brauchen es unbedingt, und bis jetzt hatten sie keinen Ort, es unterzubringen....
#dusk @Dusk $DUSK

wallet binding ist in der Dusk-Trade-Workflowliste und ich wäre fast drüber hinweg gescrollt 🤔
dann dachte ich darüber nach, wofür es eigentlich da ist.
in normalem DeFi kann jede Adresse beliebige Tokens halten. Das ist die Funktion. Und genau deshalb können regulierte Assets nicht dort leben, weil es bei einem Wertpapier Regeln gibt, wer es halten darf – und eine Adresse ohne zugeordnete Identität kann keine dieser Bedingungen erfüllen.
das Binden eines Wallets an einen verifizierten Investor macht erst kontrollierte Transfers überhaupt möglich. Die Berechtigungsprüfung passiert einmal beim Onboarding, danach trägt das Wallet diesen Status in jede nachfolgende Aktion hinein.
so liest sich die Liste: Investor-Onboarding, Wallet-Binding, kontrollierte Transfers, Payment-Koordination, konformes Settlement. Das ist eine Abfolge, kein Menü – jedes Element hängt vom vorherigen ab.
was ich immer wieder gedanklich wende, ist, dass das der Teil ist, bei dem Krypto in den letzten fünfzehn Jahren am härtesten Widerstand geleistet hat, und dass das für die Assets, die jetzt alle versu chen, onchain zu bringen, nicht verhandelbar ist.
separater Punkt: Citadel macht mit selektiver Offenlegung, dass das Binding nicht deine gesamte Identität für alle offenlegen muss. Berechtigung nachzuweisen ist nicht dasselbe wie zu veröffentlichen, wer du bist.
fühlt sich identitätsgebundenes Wallet an wie Fortschritt – oder wie genau das, was wir vermeiden wollten??
#dusk @Dusk $DUSK