#dusk $DUSK @Dusk

‎‎Мой отец годами вёл для своего небольшого магазинчика два отдельных журнала: один — для наличных продаж, второй — для кредитных счетов. Я как-то спросил, почему бы не объединить их. Он сказал, что наличные должны быть простыми и немедленными, а кредит — требовать учета условий и последующих действий. И попытка заставить одну систему делать всё сразу сделает работу хуже в каждом из этих направлений.
‎
‎Я предполагал, что Dusk со временем придёт к единой модели транзакций — как это обычно происходит у большинства сетей, которые в итоге выбирают один подход. Однако это предположение рассыпалось, когда я на самом деле разобрался, почему существуют и Moonlight, и Phoenix.
‎
‎Moonlight — это модель на основе аккаунтов: публичная и понятная. В документации Dusk её описывают как подход для балансов и прикладной логики, которому не нужна дополнительная защита. Phoenix использует подход UTXO и существует специально, чтобы поддерживать ориентированные на приватность сценарии: защищённые переводы, выборочное раскрытие и те элементы, которые финансовому сектору на самом деле нужны, когда полная прозрачность недопустима.
‎
‎Объединение этих моделей означало бы либо принудительно пропускать каждую транзакцию через избыточные накладные расходы на приватность, либо лишать опций сокрытия тех, кому они необходимы.
‎
‎Настоящая проверка DUSK — в том, служат ли обе модели реально разработчикам, которым нужны разные гарантии для разных сценариев, а не просто добавляют концептуальную сложность, с которой большинство пользователей никогда не сталкивается.
‎
‎То, чего я не нашёл ни в каких документах, — это то, как часто на практике одному приложению действительно нужны обе модели одновременно.
‎
‎