Однажды вечером я обнаружил, что читаю архитектуру транзакций Dusk, особенно то проектное решение, которое позволяет одновременно запускать две полностью раздельные модели транзакций поверх одного и того же базового слоя. В большинстве протоколов, которые мне доводилось изучать, приватность рассматривается как дополнительный слой, «прикручиваемый» постфактум — где-то в интерфейсе есть переключатель. То, что создал Dusk, ощущается структурно иначе. Phoenix работает как UTXO-ориентированная защищённая модель: с криптографическими коммитментами и нуллификаторами, скрывающими суммы, связи отправителей и изменения балансов. А Moonlight соседствует с ней как полностью прозрачная аккаунтная система — знакомая любому, кто работал с Ethereum. Иногда мне кажется, что наличие обеих моделей нативно — это подлинная архитектурная глубина, или же оно незаметно вносит проблему фрагментации, которая проявляется только при реальной нагрузке.
Самое интересное здесь — конкретная деталь, зарытая в том, как разрабатывали Phoenix. Похоже, он прошёл полноценные формальные доказательства безопасности — математическую демонстрацию того, что протокол выполняет свои криптографические требования и способен противостоять известным атакам. Это не типичная для такого рода решений формулировка, и я не до конца уверен, что в более широком пространстве достаточно людей заметили, насколько это необычно. Большинство реализаций приватности поставляются без такого уровня криптографической верификации и просто надеются, что сделанные допущения окажутся верными.
Вопрос, который приходит на ум: будет ли элегантное переключение между защищёнными и прозрачными режимами ощущаться естественным для институциональных пользователей, или же команды по комплаенсу просто потребуют одну модель исключительно и никогда не будут взаимодействовать с другой. Со стороны свобода выбора кажется привлекательной — пока юридический отдел института не решит, что именно этот выбор сам по себе создаёт юридическую ответственность.
Это заставляет меня думать, что реальная проверка этой двойной модели заключается не в технике — а в том, смогут ли регулируемые контрагенты вообще когда-нибудь доверить себе право автономно принять такое решение. Впрочем, время покажет👍
#dusk $DUSK @Dusk
$CLO $RED
Самое интересное здесь — конкретная деталь, зарытая в том, как разрабатывали Phoenix. Похоже, он прошёл полноценные формальные доказательства безопасности — математическую демонстрацию того, что протокол выполняет свои криптографические требования и способен противостоять известным атакам. Это не типичная для такого рода решений формулировка, и я не до конца уверен, что в более широком пространстве достаточно людей заметили, насколько это необычно. Большинство реализаций приватности поставляются без такого уровня криптографической верификации и просто надеются, что сделанные допущения окажутся верными.
Вопрос, который приходит на ум: будет ли элегантное переключение между защищёнными и прозрачными режимами ощущаться естественным для институциональных пользователей, или же команды по комплаенсу просто потребуют одну модель исключительно и никогда не будут взаимодействовать с другой. Со стороны свобода выбора кажется привлекательной — пока юридический отдел института не решит, что именно этот выбор сам по себе создаёт юридическую ответственность.
Это заставляет меня думать, что реальная проверка этой двойной модели заключается не в технике — а в том, смогут ли регулируемые контрагенты вообще когда-нибудь доверить себе право автономно принять такое решение. Впрочем, время покажет👍
#dusk $DUSK @Dusk
$CLO $RED