$TUT +45%, $UAI +26%, ZRO +23%, TRUMP +21% 📈😂
Früher dachte ich, dass Merkle-Bäume und Zero-Knowledge-Proofs ungefähr dasselbe in einem Privacy-Netzwerk erledigen.
Beides ermöglicht dem System, etwas zu verifizieren, ohne jedes einzelne zugrunde liegende Datenelement durch den Check zu schleppen.
Je mehr ich mir Dusk-Merkle und PLONK angesehen habe, desto mehr ist diese Annahme auseinandergefallen.
@Dusk beschreibt Dusk-Merkle als einen benutzerdefinierten sparsamen Merkle-Baum, der hash-funktionsagnostisch ist.
Er wird in verschiedenen Teilen des Netzwerks eingesetzt, einschließlich der Stake- und Transfer-Contracts sowie Citadel.
Der Baum kann einen großen strukturierten Zustand in einen Root komprimieren. Eine Merkle-„Öffnung“ kann dann zeigen, dass ein bestimmtes Element zur gebundenen Struktur gehört, ohne dass der Verifizierer den gesamten Baum verarbeiten muss.
PLONK stellt eine andere Frage.
Es ermöglicht einem Prover, nachzuweisen, dass eine Aussage oder Berechnung einen Schaltkreis erfüllt, ohne die privaten Informationen offenzulegen, die zur Erstellung des Proofs verwendet wurden.
Der Merkle-Baum kann also auf das, was an Zustand existiert, festschreiben.
PLONK kann beweisen, dass eine Operation, die geschützte Informationen einbezieht, die erforderlichen Regeln eingehalten hat.
Das hat meine Sicht auf die $DUSK privacy-„Stack“ verändert.
Es gibt nicht eine einzige kryptografische Komponente, die alles verbirgt.
Verschiedene Teile schützen unterschiedliche Grenzen.
Der Baum organisiert und bindet den Zustand fest. Der Schaltkreis definiert, was wahr sein muss. Der Proof zeigt, dass der Schaltkreis erfüllt wurde. Der Smart Contract entscheidet dann, welche Zustandsänderung sich aus dieser Verifikation ergeben soll.
Was mich nicht nur aufmerksam gemacht hat, dass Dusk-Merkle hash-funktionsagnostisch ist.
Sondern was diese Flexibilität macht – und was sie nicht garantiert.
Wenn man verschiedene Hash-Funktionen verwenden kann, ist der Baum wiederverwendbar über Komponenten hinweg, die unterschiedliche Anforderungen haben. Aber es heißt auch, dass Sicherheit und Performance jeder einzelnen Anwendung weiterhin davon abhängen, die richtige Hash-Funktion zu wählen und ihre Öffnungen korrekt zu integrieren.
Gleiches gilt für wiederverwendbare PLONK-Schaltkreise.
Wiederverwendbarkeit reduziert duplizierte Arbeit, aber ein wiederverwendeter Schaltkreis kann die gleiche fehlerhafte Annahme in jeden Contract hineinstreuen, der von ihm abhängt.
#dusk
Früher dachte ich, dass Merkle-Bäume und Zero-Knowledge-Proofs ungefähr dasselbe in einem Privacy-Netzwerk erledigen.
Beides ermöglicht dem System, etwas zu verifizieren, ohne jedes einzelne zugrunde liegende Datenelement durch den Check zu schleppen.
Je mehr ich mir Dusk-Merkle und PLONK angesehen habe, desto mehr ist diese Annahme auseinandergefallen.
@Dusk beschreibt Dusk-Merkle als einen benutzerdefinierten sparsamen Merkle-Baum, der hash-funktionsagnostisch ist.
Er wird in verschiedenen Teilen des Netzwerks eingesetzt, einschließlich der Stake- und Transfer-Contracts sowie Citadel.
Der Baum kann einen großen strukturierten Zustand in einen Root komprimieren. Eine Merkle-„Öffnung“ kann dann zeigen, dass ein bestimmtes Element zur gebundenen Struktur gehört, ohne dass der Verifizierer den gesamten Baum verarbeiten muss.
PLONK stellt eine andere Frage.
Es ermöglicht einem Prover, nachzuweisen, dass eine Aussage oder Berechnung einen Schaltkreis erfüllt, ohne die privaten Informationen offenzulegen, die zur Erstellung des Proofs verwendet wurden.
Der Merkle-Baum kann also auf das, was an Zustand existiert, festschreiben.
PLONK kann beweisen, dass eine Operation, die geschützte Informationen einbezieht, die erforderlichen Regeln eingehalten hat.
Das hat meine Sicht auf die $DUSK privacy-„Stack“ verändert.
Es gibt nicht eine einzige kryptografische Komponente, die alles verbirgt.
Verschiedene Teile schützen unterschiedliche Grenzen.
Der Baum organisiert und bindet den Zustand fest. Der Schaltkreis definiert, was wahr sein muss. Der Proof zeigt, dass der Schaltkreis erfüllt wurde. Der Smart Contract entscheidet dann, welche Zustandsänderung sich aus dieser Verifikation ergeben soll.
Was mich nicht nur aufmerksam gemacht hat, dass Dusk-Merkle hash-funktionsagnostisch ist.
Sondern was diese Flexibilität macht – und was sie nicht garantiert.
Wenn man verschiedene Hash-Funktionen verwenden kann, ist der Baum wiederverwendbar über Komponenten hinweg, die unterschiedliche Anforderungen haben. Aber es heißt auch, dass Sicherheit und Performance jeder einzelnen Anwendung weiterhin davon abhängen, die richtige Hash-Funktion zu wählen und ihre Öffnungen korrekt zu integrieren.
Gleiches gilt für wiederverwendbare PLONK-Schaltkreise.
Wiederverwendbarkeit reduziert duplizierte Arbeit, aber ein wiederverwendeter Schaltkreis kann die gleiche fehlerhafte Annahme in jeden Contract hineinstreuen, der von ihm abhängt.
#dusk
🔘 Flexible foundation
73%
🔘 Too many layers
27%
11 Stimmen • Abstimmung beendet
