#dusk $DUSK @Dusk
Ich habe diese Woche die Überprüfung des Phoenix-Guthabens durchgesehen, weil ich verstehen wollte, wie das Netzwerk bestätigt, dass eine Übertragung gültig ist, wenn es die beteiligten Beträge nicht sehen kann.
Die Antwort sind Pedersen-Verpflichtungen, und sie sind eleganter, als ich erwartet hatte.
DuskEVM wurde in Q1 2026 gestartet und fügt neben DuskDS einen zweiten Ausführungspfad hinzu. Das zugrunde liegende DuskDS nutzt weiterhin Phoenix für native Privacy-Transaktionen — das heißt, dieses Mechanismus ist seit dem Mainnet-Launch im Januar 2025 live.
Jeder Phoenix-Note trägt eine Werte-Verpflichtung bei — nicht der Betrag selbst, sondern eine kryptografische Verpflichtung darauf. Pedersen-Verpflichtungen sind homomorph: Man kann sie addieren und subtrahieren. So kann das Netzwerk verifizieren, dass die Summe der Input-Verpflichtungen der Summe der Output-Verpflichtungen entspricht, ohne jemals zu sehen, welche Werte tatsächlich vorliegen.
Moonlight macht das transparent: Das Netzwerk sieht die Beträge und prüft die Rechnung direkt. Phoenix macht es kryptografisch: Die Beträge bleiben verborgen, aber die Verpflichtungsrechnung bleibt gültig.
Der Vergleich, der bei mir klickte: der Unterschied zwischen einer Bank, die dein Kontoguthaben überprüft, indem sie es ausliest, versus dem Nachweis, dass dein Guthaben ausreicht, indem du einen Beleg vorzeigst — ohne die tatsächliche Zahl zu zeigen.
Ehrlicher Hinweis: Pedersen-Verpflichtungen allein beweisen nicht, dass die Werte positiv sind. Zero-Knowledge-Range-Proofs regeln das separat.
Wie breit lässt sich dieses Modell auf andere Kontexte übertragen — wird commitment-basierte Arithmetik irgendwo außerhalb von ZK-nativen Chains verwendet, oder ist es immer noch hauptsächlich ein blockchain-spezifisches Werkzeug? @Dusk
$DUSK #dusk
Ich habe diese Woche die Überprüfung des Phoenix-Guthabens durchgesehen, weil ich verstehen wollte, wie das Netzwerk bestätigt, dass eine Übertragung gültig ist, wenn es die beteiligten Beträge nicht sehen kann.
Die Antwort sind Pedersen-Verpflichtungen, und sie sind eleganter, als ich erwartet hatte.
DuskEVM wurde in Q1 2026 gestartet und fügt neben DuskDS einen zweiten Ausführungspfad hinzu. Das zugrunde liegende DuskDS nutzt weiterhin Phoenix für native Privacy-Transaktionen — das heißt, dieses Mechanismus ist seit dem Mainnet-Launch im Januar 2025 live.
Jeder Phoenix-Note trägt eine Werte-Verpflichtung bei — nicht der Betrag selbst, sondern eine kryptografische Verpflichtung darauf. Pedersen-Verpflichtungen sind homomorph: Man kann sie addieren und subtrahieren. So kann das Netzwerk verifizieren, dass die Summe der Input-Verpflichtungen der Summe der Output-Verpflichtungen entspricht, ohne jemals zu sehen, welche Werte tatsächlich vorliegen.
Moonlight macht das transparent: Das Netzwerk sieht die Beträge und prüft die Rechnung direkt. Phoenix macht es kryptografisch: Die Beträge bleiben verborgen, aber die Verpflichtungsrechnung bleibt gültig.
Der Vergleich, der bei mir klickte: der Unterschied zwischen einer Bank, die dein Kontoguthaben überprüft, indem sie es ausliest, versus dem Nachweis, dass dein Guthaben ausreicht, indem du einen Beleg vorzeigst — ohne die tatsächliche Zahl zu zeigen.
Ehrlicher Hinweis: Pedersen-Verpflichtungen allein beweisen nicht, dass die Werte positiv sind. Zero-Knowledge-Range-Proofs regeln das separat.
Wie breit lässt sich dieses Modell auf andere Kontexte übertragen — wird commitment-basierte Arithmetik irgendwo außerhalb von ZK-nativen Chains verwendet, oder ist es immer noch hauptsächlich ein blockchain-spezifisches Werkzeug? @Dusk
$DUSK #dusk