Ich bin letzte Nacht noch einmal durch die Dämmerungsdokumentation gegangen und kam mit mehr Interesse an den Designfragen als an technischen Behauptungen heraus.

Das Erste, was klickte, war die Aufteilung zwischen Moonlight und Phoenix. Moonlight ist kontobasiert mit öffentlichem Schlüssel, Nonce und Kontostand, während Phoenix UTXOs als „Notizen“ innerhalb eines Merkle-Baums verwendet. Zu den Feldern von Moonlight-Transaktionen gehören from, to, value, nonce, deposit, data, gas_limit, gas_price und signature; das maximale Gas wird als gas_limit × gas_price berechnet.

Bei Phoenix wird es spannend. Es verwendet die Jubjub-Kurve mit öffentlichen Schlüsseln (A,B), geheimen Schlüsseln (a,b) und einem View-Key (a,B). Die Notizstruktur umfasst type, com, enc, npk, R und encsender. Der Einmal-Notizschlüssel wird abgeleitet als npk = H(rA)G + B, während der Ausgabeschlüssel (spending key) nsk = H(aR) + b.

Ich versuche immer noch zu verstehen, wo genau die Vertrauensgrenze bei der Erzeugung von ZK-Beweisen und beim delegierten Scanning verläuft. Die Dokumentation sagt, dass Dritte Beweise generieren oder mit View Keys scannen können, ohne Ausgabebefugnisse zu erhalten, aber wo liegen die Fehlerpunkte?

Und wie verhält es sich bei adversarialen Netzwerkbedingungen – mit Nullifiern, aktuellen Merkle-Wurzeln und Gas, das innerhalb des Beweises gehandhabt wird? Welche Teile sind dezentralisiert, und welche Annahmen sollten Nutzer kritisch prüfen?

#dusk $DUSK @Dusk