Исследуя техническую архитектуру Dusk, я обнаружил противоречие, которое легко упустить: он тратит много усилий на соблюдение требований на уровне транзакций, но распределение полномочий на уровне исполнения EVM почти не обсуждается.
В документации говорится, что слой EVM обслуживается единым секвенатором для упаковки транзакций — это та же логика, что и у централизованного секвенатора в сети L2 Ethereum. На первый взгляд это повышает эффективность и снижает затраты, но при due diligence со стороны институций первый вопрос звучит так: кто управляет этим секвенатором? Кто отвечает, если он остановится? Кто первым будет авансировать, если активы клиента «застрянут» в очереди?
Какими бы изощрёнными ни были Phoenix и Zedger, они могут обеспечить лишь конфиденциальность содержимого транзакций и корректность логики верификации. Но если «выключатель» всего слоя исполнения находится в руках единственной организации, то заявленная позиция «децентрализованная инфраструктура для финансов» выглядит уже не так убедительно. Правила ESMA по кастодиальным операциям как раз поднимают такие вопросы: кто контролирует активы клиентов и кто несёт ответственность при сбоях системы.
Ещё более несостыковочно то, что консенсусный слой мейннета Dusk действительно даёт гарантии окончательности, но полномочия секвенирования на стороне исполнения остаются централизованными. Это похоже на то, как вы построили бронированный сейф, но у пропускного устройства только одна карточка — и она хранится в кармане у команды проекта.
Я не говорю, что централизация секвенатора обязательно плоха; скорее, в этом дизайне есть напряжение между техническими решениями и нарративом про «институциональную комплаенс»-совместимость. Традиционным финансовым институтам нужны гарантии, которые можно прописать в контракте, а не «поверьте, что мы будем отвечать и нести ответственность». Если Dusk действительно хочет обслуживать крупные объёмы институциональных активов, проблема прозрачности распределения контроля рано или поздно потребует прямого ответа.
Когда-нибудь я увижу, что будут чётко раскрыты механизмы управления секвенатором, планы на случай сбоев и децентрализованная дорожная карта — и тогда смогу оценить, насколько велика привлекательность этой архитектуры для институций. Пока же могу сказать лишь следующее: технические возможности там есть, но зрелость операционной архитектуры всё ещё нужно подтверждать временем.
#dusk $DUSK @Dusk
В документации говорится, что слой EVM обслуживается единым секвенатором для упаковки транзакций — это та же логика, что и у централизованного секвенатора в сети L2 Ethereum. На первый взгляд это повышает эффективность и снижает затраты, но при due diligence со стороны институций первый вопрос звучит так: кто управляет этим секвенатором? Кто отвечает, если он остановится? Кто первым будет авансировать, если активы клиента «застрянут» в очереди?
Какими бы изощрёнными ни были Phoenix и Zedger, они могут обеспечить лишь конфиденциальность содержимого транзакций и корректность логики верификации. Но если «выключатель» всего слоя исполнения находится в руках единственной организации, то заявленная позиция «децентрализованная инфраструктура для финансов» выглядит уже не так убедительно. Правила ESMA по кастодиальным операциям как раз поднимают такие вопросы: кто контролирует активы клиентов и кто несёт ответственность при сбоях системы.
Ещё более несостыковочно то, что консенсусный слой мейннета Dusk действительно даёт гарантии окончательности, но полномочия секвенирования на стороне исполнения остаются централизованными. Это похоже на то, как вы построили бронированный сейф, но у пропускного устройства только одна карточка — и она хранится в кармане у команды проекта.
Я не говорю, что централизация секвенатора обязательно плоха; скорее, в этом дизайне есть напряжение между техническими решениями и нарративом про «институциональную комплаенс»-совместимость. Традиционным финансовым институтам нужны гарантии, которые можно прописать в контракте, а не «поверьте, что мы будем отвечать и нести ответственность». Если Dusk действительно хочет обслуживать крупные объёмы институциональных активов, проблема прозрачности распределения контроля рано или поздно потребует прямого ответа.
Когда-нибудь я увижу, что будут чётко раскрыты механизмы управления секвенатором, планы на случай сбоев и децентрализованная дорожная карта — и тогда смогу оценить, насколько велика привлекательность этой архитектуры для институций. Пока же могу сказать лишь следующее: технические возможности там есть, но зрелость операционной архитектуры всё ещё нужно подтверждать временем.
#dusk $DUSK @Dusk