#dusk $DUSK @Dusk Ich habe heute beim kleinen DUSK-Test-Setup auf Positionen geprüft und bin dabei auf eine ziemlich grundlegende Annahme gestoßen: Früher dachte ich, dass Merkle-Bäume und Zero-Knowledge-Proofs ungefähr denselben Job machen.
Wenn man genauer in @Dusk eintaucht, ändert sich das für mich.
Dusk-Merkle und PLONK sind nicht austauschbar. Sie lösen unterschiedliche Probleme, und diese Unterscheidung ist entscheidend, wenn man verstehen will, woher die Privatsphäre tatsächlich kommt.
Dusk-Merkle ist ein benutzerdefinierter, spärlicher Merkle-Baum, der hash-funktionsagnostisch ist. Er kann in verschiedenen Teilen des Netzwerks verwendet werden, einschließlich Stake, Transfer und Citadel.
So denke ich mittlerweile darüber:
Merkle = sich auf einen Zustand festlegen.
PLONK = eine Berechnung beweisen.
Ein Merkle-Baum kann strukturierten Zustand zu einem Root komprimieren. Eine Merkle-Eröffnung kann dann beweisen, dass ein bestimmter Eintrag zu dieser festgeschriebenen Struktur gehört, ohne dass der Verifizierer den gesamten Baum verarbeiten muss.
PLONK geht an eine andere Stelle. Es ermöglicht einem Beweiser zu zeigen, dass eine Aussage oder Berechnung einen Schaltkreis erfüllt, ohne dabei die privaten Informationen offenzulegen, die zur Erstellung dieses Beweises verwendet wurden.
Diese Trennung hat es mir tatsächlich leichter gemacht, die $DUSK Architektur zu verstehen.
Der Baum organisiert und commitet auf den Zustand.
Der Schaltkreis definiert, was wahr sein muss.
Der Beweis zeigt, dass die Regeln eingehalten wurden.
Der Contract kann dann bestimmen, welcher Zustandsübergang folgt.
Aber hier ist der Teil, den ich noch interessanter finde.
Flexibilität ist nicht automatisch Sicherheit.
Ein hash-funktionsagnostisches Merkle-Design hängt weiterhin davon ab, die richtige Hash-Funktion zu wählen und Eröffnungen korrekt zu implementieren. Wiederverwendbare PLONK-Schaltkreise haben einen ähnlichen Tradeoff: Sie reduzieren zwar doppelte Arbeit, aber eine fehlerhafte Annahme kann möglicherweise über mehrere Anwendungen hinweg wiederverwendet werden.
Ich schaue also nicht nur darauf, ob DUSK ZK nutzt.
Ich schaue darauf, ob jede kryptografische Komponente genau die Aufgabe übernimmt, für die sie vorgesehen ist.
#dusk $DUSK
@Dusk
$BTW
$TUT
$CYS
Was ist für die Dusk-Privatsphäre am wichtigsten?
Wenn man genauer in @Dusk eintaucht, ändert sich das für mich.
Dusk-Merkle und PLONK sind nicht austauschbar. Sie lösen unterschiedliche Probleme, und diese Unterscheidung ist entscheidend, wenn man verstehen will, woher die Privatsphäre tatsächlich kommt.
Dusk-Merkle ist ein benutzerdefinierter, spärlicher Merkle-Baum, der hash-funktionsagnostisch ist. Er kann in verschiedenen Teilen des Netzwerks verwendet werden, einschließlich Stake, Transfer und Citadel.
So denke ich mittlerweile darüber:
Merkle = sich auf einen Zustand festlegen.
PLONK = eine Berechnung beweisen.
Ein Merkle-Baum kann strukturierten Zustand zu einem Root komprimieren. Eine Merkle-Eröffnung kann dann beweisen, dass ein bestimmter Eintrag zu dieser festgeschriebenen Struktur gehört, ohne dass der Verifizierer den gesamten Baum verarbeiten muss.
PLONK geht an eine andere Stelle. Es ermöglicht einem Beweiser zu zeigen, dass eine Aussage oder Berechnung einen Schaltkreis erfüllt, ohne dabei die privaten Informationen offenzulegen, die zur Erstellung dieses Beweises verwendet wurden.
Diese Trennung hat es mir tatsächlich leichter gemacht, die $DUSK Architektur zu verstehen.
Der Baum organisiert und commitet auf den Zustand.
Der Schaltkreis definiert, was wahr sein muss.
Der Beweis zeigt, dass die Regeln eingehalten wurden.
Der Contract kann dann bestimmen, welcher Zustandsübergang folgt.
Aber hier ist der Teil, den ich noch interessanter finde.
Flexibilität ist nicht automatisch Sicherheit.
Ein hash-funktionsagnostisches Merkle-Design hängt weiterhin davon ab, die richtige Hash-Funktion zu wählen und Eröffnungen korrekt zu implementieren. Wiederverwendbare PLONK-Schaltkreise haben einen ähnlichen Tradeoff: Sie reduzieren zwar doppelte Arbeit, aber eine fehlerhafte Annahme kann möglicherweise über mehrere Anwendungen hinweg wiederverwendet werden.
Ich schaue also nicht nur darauf, ob DUSK ZK nutzt.
Ich schaue darauf, ob jede kryptografische Komponente genau die Aufgabe übernimmt, für die sie vorgesehen ist.
#dusk $DUSK
@Dusk
$BTW
$TUT
$CYS
Was ist für die Dusk-Privatsphäre am wichtigsten?
Merkle commits state
0%
PLONK proves rules
0%
Both have boundaries
0%
Which matters most?
0%
0 Stimmen • Abstimmung beendet