DUSK у DuskDS розробив досить цікаве рішення — одночасна підтримка на одній ланцюжку двох абсолютно різних логік транзакцій. Один — Phoenix, на основі UTXO-моделі з приватністю; інший — Moonlight, на основі облікової моделі з прозорістю. Обидві системи можуть безшовно перемикатися на одній ланцюжку.

Це за своєю суттю досить складне технічне рішення. Але воно вирішує реальну проблему: не всі сценарії транзакцій вимагають приватності. Надмірне примусове забезпечення приватності навпаки знижує ефективність і зручність. Іноді потрібно прозоре розрахункове підтвердження, а іноді — потрібно захищати приватність. Одна система, яка підтримує обидва режими — це і є її розумна особливість.

Розглянемо спершу Phoenix. Вона використовує UTXO-логіку, схожу на Біткоїн, але з додаванням ZK-SNARK для захисту приватності. Кожна транзакція створює note, у якому зберігається сума і публіковий ключ отримувача, але ці дані всі зашифровані. На ланцюжку видно лише два елементи: commitment (зобов’язання) і nullifier (анулювальне значення).

Щоб витратити цей note, потрібно надати доказ нульової знання. Ви маєте довести дві речі: по-перше, що ви знаєте приватний ключ цього note, по-друге, що цей nullifier ще не був використаний. Але цей доказ не розкриває сам зміст note — це дуже розумно.

Переваги такої конструкції? Повна приватність транзакцій. На ланцюжку не видно, хто кому скільки переказав, можна лише побачити, що транзакція відбулася. Сума, відправник, отримувач — все зашифровано. Для організацій, що потребують захисту комерційної таємниці, це критично важливо. Ви не хочете, щоб конкуренти розкрили ваші фінансові потоки і ритм транзакцій, — Phoenix надає цей рівень захисту.

Moonlight — навпаки. Вона використовує облікову модель, транзакції повністю прозорі. Хто кому скільки переказав — все видно на ланцюжку. Така модель має високу ефективність і підходить для високочастотних транзакцій і сценаріїв з розрахунками.

Головне — ці дві моделі можна гнучко перемикати. Ви можете обирати, яку використовувати — Phoenix чи Moonlight — залежно від конкретних потреб: частина коштів йде через приватний канал, частина — через прозорий. Такий підхід відображає розуміння реальних сценаріїв: приватність і ефективність — це часто компроміс, і немає абсолютного оптимального рішення.