Es gab eine Nacht, in der ich dort saß und den Ein- und Auszahlungsfluss für eine Finanz-App durchgezeichnet habe, ohne überhaupt zu merken, wann der Kaffee kalt wurde … Was mich festhielt, war nicht Zero-Knowledge-Proof, sondern welche Daten sichtbar gemacht werden dürfen und welche Daten niemals offengelegt werden sollen?
Ich habe es in 20 Transaktionsfälle aufgeteilt: 12 Fälle brauchten Nachvollziehbarkeit (Auditability), 8 Fälle brauchten Vertraulichkeit; genau da hörten Moonlight mit Account Model und Phoenix mit UTXO Model auf, wie Namen zu klingen, die fürs Marketing gemacht sind
Moonlight macht Kontostand, Absender, Empfänger, Betrag und Nonce sichtbar; Phoenix steckt die Mittel in eine verschlüsselte Notiz, verwendet Commitment, Nullifier und Zero-Knowledge-Proof, um einen Zustandsübergang nachzuweisen, ohne den Betrag offenzulegen
Als ich den Indexer skizziert habe, habe ich schließlich gesehen, dass das Account Model leichter zu lesen ist, aber die Nonce muss sehr eng verwaltet werden; Phoenix ist deutlich privater, bringt jedoch auch Auswahl von Notizen, verbrauchte Nullifier, Schlüsselverwaltung … Privatsphäre verlagert die Kosten in die Architektur
Um ehrlich zu sein: Es waren die kleinen Details, die mir mehr Vertrauen gegeben haben: Memo auf 512 Bytes begrenzt, native Präzision 9 Dezimalstellen, Moonlight-Adresse nutzt einen komprimierten Schlüssel mit 96 B, während Phoenix 2 × 32 B komprimierte Punkte verwendet; wenn die Kodierung um ein einziges Byte danebenliegt, reicht das, um die ganze Nacht auf Logs starren zu müssen!
fee = gas_used × gas_price; Wenn der Gasvorrat ausgeht, kann das zwar ein Revert auslösen, aber das bereits verbrauchte Gas wird trotzdem berechnet. Daher sind Gas Limit und Gas Price nicht nur Felder, die man zu Showzwecken ausfüllt
Sobald es bei Rusk ankommt, DuskVM, Rust/WebAssembly, Smart Contract, GraphQL, Mempool, Finalität … liegt das eigentliche Problem in den Abläufen (Operations)
Moonlight kollidiert nach Konto + Nonce, Phoenix nach verbrauchtem Nullifier; wenn einmal eine doppelte Gutschrift durchrutscht, ist der Spaß vorbei
Für mich ist entscheidend, worauf man in Dusk genau achten sollte: ob Developer Toolchain, Dokumentation, SDK, API, Custody, Viewing Key, Selective Disclosure und Audit Trail gut genug gestaltet sind, sodass Fehler wirklich schwer passieren
Wenn Architektur Entwickler dazu zwingt, über Sichtbarkeit, Idempotenz und Finalität nachzudenken … ist das nicht der eigentliche ernste Test für eine Finanz-Blockchain?
#dusk $DUSK @Dusk
Ich habe es in 20 Transaktionsfälle aufgeteilt: 12 Fälle brauchten Nachvollziehbarkeit (Auditability), 8 Fälle brauchten Vertraulichkeit; genau da hörten Moonlight mit Account Model und Phoenix mit UTXO Model auf, wie Namen zu klingen, die fürs Marketing gemacht sind
Moonlight macht Kontostand, Absender, Empfänger, Betrag und Nonce sichtbar; Phoenix steckt die Mittel in eine verschlüsselte Notiz, verwendet Commitment, Nullifier und Zero-Knowledge-Proof, um einen Zustandsübergang nachzuweisen, ohne den Betrag offenzulegen
Als ich den Indexer skizziert habe, habe ich schließlich gesehen, dass das Account Model leichter zu lesen ist, aber die Nonce muss sehr eng verwaltet werden; Phoenix ist deutlich privater, bringt jedoch auch Auswahl von Notizen, verbrauchte Nullifier, Schlüsselverwaltung … Privatsphäre verlagert die Kosten in die Architektur
Um ehrlich zu sein: Es waren die kleinen Details, die mir mehr Vertrauen gegeben haben: Memo auf 512 Bytes begrenzt, native Präzision 9 Dezimalstellen, Moonlight-Adresse nutzt einen komprimierten Schlüssel mit 96 B, während Phoenix 2 × 32 B komprimierte Punkte verwendet; wenn die Kodierung um ein einziges Byte danebenliegt, reicht das, um die ganze Nacht auf Logs starren zu müssen!
fee = gas_used × gas_price; Wenn der Gasvorrat ausgeht, kann das zwar ein Revert auslösen, aber das bereits verbrauchte Gas wird trotzdem berechnet. Daher sind Gas Limit und Gas Price nicht nur Felder, die man zu Showzwecken ausfüllt
Sobald es bei Rusk ankommt, DuskVM, Rust/WebAssembly, Smart Contract, GraphQL, Mempool, Finalität … liegt das eigentliche Problem in den Abläufen (Operations)
Moonlight kollidiert nach Konto + Nonce, Phoenix nach verbrauchtem Nullifier; wenn einmal eine doppelte Gutschrift durchrutscht, ist der Spaß vorbei
Für mich ist entscheidend, worauf man in Dusk genau achten sollte: ob Developer Toolchain, Dokumentation, SDK, API, Custody, Viewing Key, Selective Disclosure und Audit Trail gut genug gestaltet sind, sodass Fehler wirklich schwer passieren
Wenn Architektur Entwickler dazu zwingt, über Sichtbarkeit, Idempotenz und Finalität nachzudenken … ist das nicht der eigentliche ernste Test für eine Finanz-Blockchain?
#dusk $DUSK @Dusk
