Я изучал угол GDPR у Dusk и в итоге стал больше думать о DORA.
Сначала они выглядят как отдельные проблемы комплаенса. GDPR — про персональные данные и приватность. DORA гораздо больше сосредоточена на цифровой операционной устойчивости. Но когда я прочитал архитектуру Dusk, связь стала понятнее.
Интересная часть в том, что Dusk не рассматривает приватность просто как сокрытие деталей транзакций. В их документации разделяются модели публичных и защищённых (shielded) транзакций, при этом добавляется выборочное раскрытие через Citadel. Это важно, потому что регулируемым финансам нужны доказательства без раскрытия полной финансовой истории каждого участника.
Дальше есть операционная сторона.
Документация Dusk для операторов уделяет значительное внимание мониторингу состояния узлов, устойчивости пиров, восстановлению, обновлениям, защите ключей и обработке отказов. Это совсем другой разговор, чем просто сказать, что блокчейн «безопасен».
Инцидент на мосту сделал это различие ещё более конкретным. Сам мейннет не был затронут, но Dusk всё равно приостановила сервисы моста и переработала жизненные циклы транзакций, подверженность горячего кошелька, механизмы контроля доступа и процедуры восстановления. В постмортеме операционный дизайн явно рассматривается как часть периметра безопасности.
Это изменило то, как я читал утверждения про GDPR и DORA.
Реальная инфраструктурная задача — не сделать данные приватными и не сделать сеть устойчивой независимо. Это согласование приватности, раскрытия, идентичности, расчётов и операционного восстановления без создания нового централизованного зависимости всякий раз, когда появляется новое регуляторное требование.
Архитектура Dusk, похоже, движется к решению этой проблемы — от протокольного уровня вверх.
Менее очевидный вывод в том, что регуляторная готовность — это не одна функция. Это накопление множества небольших технических решений, которые определяют, что происходит, когда сталкиваются приватность, комплаенс и сбои.
#dusk $DUSK @Dusk
Сначала они выглядят как отдельные проблемы комплаенса. GDPR — про персональные данные и приватность. DORA гораздо больше сосредоточена на цифровой операционной устойчивости. Но когда я прочитал архитектуру Dusk, связь стала понятнее.
Интересная часть в том, что Dusk не рассматривает приватность просто как сокрытие деталей транзакций. В их документации разделяются модели публичных и защищённых (shielded) транзакций, при этом добавляется выборочное раскрытие через Citadel. Это важно, потому что регулируемым финансам нужны доказательства без раскрытия полной финансовой истории каждого участника.
Дальше есть операционная сторона.
Документация Dusk для операторов уделяет значительное внимание мониторингу состояния узлов, устойчивости пиров, восстановлению, обновлениям, защите ключей и обработке отказов. Это совсем другой разговор, чем просто сказать, что блокчейн «безопасен».
Инцидент на мосту сделал это различие ещё более конкретным. Сам мейннет не был затронут, но Dusk всё равно приостановила сервисы моста и переработала жизненные циклы транзакций, подверженность горячего кошелька, механизмы контроля доступа и процедуры восстановления. В постмортеме операционный дизайн явно рассматривается как часть периметра безопасности.
Это изменило то, как я читал утверждения про GDPR и DORA.
Реальная инфраструктурная задача — не сделать данные приватными и не сделать сеть устойчивой независимо. Это согласование приватности, раскрытия, идентичности, расчётов и операционного восстановления без создания нового централизованного зависимости всякий раз, когда появляется новое регуляторное требование.
Архитектура Dusk, похоже, движется к решению этой проблемы — от протокольного уровня вверх.
Менее очевидный вывод в том, что регуляторная готовность — это не одна функция. Это накопление множества небольших технических решений, которые определяют, что происходит, когда сталкиваются приватность, комплаенс и сбои.
#dusk $DUSK @Dusk