#dusk $DUSK
Drei Phasen bilden einen Konsens für Dusk: Generation erstellt Kandidatenblöcke, Reduction verengt sie, und Agreement beendet die Finalität. Das Agreement läuft asynchron, sodass man nicht warten muss, bis alle Phasen fertig sind. Das Whitepaper sagt, dass ein Fork eine Supermajorität in drei aufeinanderfolgenden Schritten braucht. Aber ich bin immer noch neugierig: Ist die Chance auf „nicht signifikant“ in realen adversarialen Netzwerken bereits getestet worden, oder ist das bisher nur Theorie?
Weiter: Als ich das erste Mal in der Dusk-Dokumentation auf den Begriff Zero-Knowledge Proof gestoßen bin, dachte ich mir: „Was ist das schon wieder?“ Klingt extrem technisch. Aber nachdem ich versucht habe, es aus Sicht von Use Cases zu verstehen, merkte ich: Es ist nicht so kompliziert, wie ich mir vorgestellt habe.
Kurz gesagt: ZK ermöglicht es euch zu beweisen, dass etwas wahr ist, ohne dabei die kompletten Daten dahinter offenzulegen.
Zum Beispiel braucht ein System nur zu wissen, ob das Guthaben einer Person für eine Transaktion ausreicht. Warum müssen alle das Guthaben und den Transaktionsverlauf kennen?
Reicht doch ein Beweis, dass die Bedingung erfüllt ist.
So langsam verstehe ich, warum Konzepte wie dieses zu Dusk und zu Financial Applications passen.
Stellt euch vor: Ein Institut führt einen großen Asset-Settlement durch. Es muss beweisen, dass die Transaktion bestimmte Regeln erfüllt, aber das heißt nicht, dass alle finanziellen Daten öffentlich sichtbar sein müssen.
Meiner Ansicht nach ist Privacy hier nicht nur „Daten verstecken“. Es geht eher darum festzulegen, welche Informationen tatsächlich bewiesen werden müssen und welche nicht offengelegt werden müssen.
Aber ZK ist auch kein Zauberknopf. Die Umsetzung bleibt anspruchsvoll: von den Rechenkosten über das Proof-Design bis hin zur Möglichkeit, dass im System Fehler passieren.
Ich hatte auch kurz den Gedanken: Wenn die Daten nicht öffentlich sind, wie wissen dann andere, dass die Transaktionen gültig sind?
Von da an habe ich den entscheidenden Punkt verstanden. Nicht der Bedarf zu verifizieren ändert sich, sondern wie die Verifikation durchgeführt wird.
Und je mehr ich mir finanzielle Use Cases anschaue, desto plausibler wird, warum so ein Ansatz gebraucht wird.
Next, ich möchte genauer hinschauen: Wie sieht eigentlich eine private Transaktion in Dusk aus, und welche Daten kann man verifizieren, ohne sie der Öffentlichkeit offenzulegen?
@Dusk
Drei Phasen bilden einen Konsens für Dusk: Generation erstellt Kandidatenblöcke, Reduction verengt sie, und Agreement beendet die Finalität. Das Agreement läuft asynchron, sodass man nicht warten muss, bis alle Phasen fertig sind. Das Whitepaper sagt, dass ein Fork eine Supermajorität in drei aufeinanderfolgenden Schritten braucht. Aber ich bin immer noch neugierig: Ist die Chance auf „nicht signifikant“ in realen adversarialen Netzwerken bereits getestet worden, oder ist das bisher nur Theorie?
Weiter: Als ich das erste Mal in der Dusk-Dokumentation auf den Begriff Zero-Knowledge Proof gestoßen bin, dachte ich mir: „Was ist das schon wieder?“ Klingt extrem technisch. Aber nachdem ich versucht habe, es aus Sicht von Use Cases zu verstehen, merkte ich: Es ist nicht so kompliziert, wie ich mir vorgestellt habe.
Kurz gesagt: ZK ermöglicht es euch zu beweisen, dass etwas wahr ist, ohne dabei die kompletten Daten dahinter offenzulegen.
Zum Beispiel braucht ein System nur zu wissen, ob das Guthaben einer Person für eine Transaktion ausreicht. Warum müssen alle das Guthaben und den Transaktionsverlauf kennen?
Reicht doch ein Beweis, dass die Bedingung erfüllt ist.
So langsam verstehe ich, warum Konzepte wie dieses zu Dusk und zu Financial Applications passen.
Stellt euch vor: Ein Institut führt einen großen Asset-Settlement durch. Es muss beweisen, dass die Transaktion bestimmte Regeln erfüllt, aber das heißt nicht, dass alle finanziellen Daten öffentlich sichtbar sein müssen.
Meiner Ansicht nach ist Privacy hier nicht nur „Daten verstecken“. Es geht eher darum festzulegen, welche Informationen tatsächlich bewiesen werden müssen und welche nicht offengelegt werden müssen.
Aber ZK ist auch kein Zauberknopf. Die Umsetzung bleibt anspruchsvoll: von den Rechenkosten über das Proof-Design bis hin zur Möglichkeit, dass im System Fehler passieren.
Ich hatte auch kurz den Gedanken: Wenn die Daten nicht öffentlich sind, wie wissen dann andere, dass die Transaktionen gültig sind?
Von da an habe ich den entscheidenden Punkt verstanden. Nicht der Bedarf zu verifizieren ändert sich, sondern wie die Verifikation durchgeführt wird.
Und je mehr ich mir finanzielle Use Cases anschaue, desto plausibler wird, warum so ein Ansatz gebraucht wird.
Next, ich möchte genauer hinschauen: Wie sieht eigentlich eine private Transaktion in Dusk aus, und welche Daten kann man verifizieren, ohne sie der Öffentlichkeit offenzulegen?
@Dusk
