Сейчас у архитектуры Dusk есть очень отчетливая особенность — она намеренно «разбирает» систему.
В отличие от большинства публичных сетей, которые складывают консенсус, выполнение и расчет в один монолитный стек, Dusk отделяет эти три вещи друг от друга. Самый нижний слой — DuskDS: там находятся консенсус, доступность данных и расчеты; посередине висит DuskEVM, полностью совместимый с Solidity — разработчики, переходящие из Ethereum, почти не нуждаются в изменении кода; а сверху есть еще слой DuskVM, который предназначен специально для запуска нативных приватных приложений. Три слоя отвечают каждый за «свою» часть, а сквозное взаимодействие обеспечивается одним токеном DUSK.
Мотивацию этого решения понять несложно. Самая большая цена за создание самодостаточной цепочки — то, что разработчикам придется заново учить инструментарий, из-за чего экосистема будет разрастаться очень медленно. Если повесить EVM-слой, то такие уже готовые вещи, как Solidity, Hardhat и MetaMask, можно использовать напрямую — трение при привлечении разработчиков заметно снижается.
Но цена этого решения тоже вполне очевидна — растет сложность, и рост происходит в самом уязвимом месте.
Сквозное течение между слоями означает появление новых предположений о доверии и новой поверхности атак. Перевод активов между DuskDS и DuskEVM требует нативного межслойного моста: хотя это не требует обертывания активов или кастодиана, сам межслойный перенос добавляет дополнительные этапы проверки. За последние годы инцидентов, вызванных межслойным дизайном, было больше, чем аварий, возникших «по вине» самой виртуальной машины.
Есть и еще один вопрос, который легко упустить из виду — распределение узлов. Dusk использует консенсус SBA, и значит узлы должны постоянно быть в сети и быть корректно настроенными. Эти пороги повышают безопасность сети, но при этом делают аппаратные и эксплуатационные расходы для обычных участников довольно высокими при длительном запуске узла. Как только узлы постепенно начнут концентрироваться в руках немногих крупных игроков, даже самая удачная архитектура неизбежно начнет искажаться.
Поэтому, когда я сейчас смотрю на Dusk, я уделяю внимание не тому, сколько у него слоев и какие у него TPS. Я смотрю на две вещи: во‑первых, насколько ясно описаны межслойные состояния активов и границы приватности; во‑вторых, какие типы приложений появляются на EVM-слое — если там будут только перенесенные универсальные протоколы, то модульность просто сменит способ привлечения клиентов; а если приложения действительно вызывают встроенные возможности по работе с конфиденциальными данными (например, используют криптографическую книгу ордеров Hedger или конфиденциальные ценные бумаги по стандарту XSC), тогда становится ясно, что различие этой архитектуры реально используется.
Архитектуру собрали — теперь посмотрим, что сможет вырасти сверху.
#dusk $DUSK @Dusk
В отличие от большинства публичных сетей, которые складывают консенсус, выполнение и расчет в один монолитный стек, Dusk отделяет эти три вещи друг от друга. Самый нижний слой — DuskDS: там находятся консенсус, доступность данных и расчеты; посередине висит DuskEVM, полностью совместимый с Solidity — разработчики, переходящие из Ethereum, почти не нуждаются в изменении кода; а сверху есть еще слой DuskVM, который предназначен специально для запуска нативных приватных приложений. Три слоя отвечают каждый за «свою» часть, а сквозное взаимодействие обеспечивается одним токеном DUSK.
Мотивацию этого решения понять несложно. Самая большая цена за создание самодостаточной цепочки — то, что разработчикам придется заново учить инструментарий, из-за чего экосистема будет разрастаться очень медленно. Если повесить EVM-слой, то такие уже готовые вещи, как Solidity, Hardhat и MetaMask, можно использовать напрямую — трение при привлечении разработчиков заметно снижается.
Но цена этого решения тоже вполне очевидна — растет сложность, и рост происходит в самом уязвимом месте.
Сквозное течение между слоями означает появление новых предположений о доверии и новой поверхности атак. Перевод активов между DuskDS и DuskEVM требует нативного межслойного моста: хотя это не требует обертывания активов или кастодиана, сам межслойный перенос добавляет дополнительные этапы проверки. За последние годы инцидентов, вызванных межслойным дизайном, было больше, чем аварий, возникших «по вине» самой виртуальной машины.
Есть и еще один вопрос, который легко упустить из виду — распределение узлов. Dusk использует консенсус SBA, и значит узлы должны постоянно быть в сети и быть корректно настроенными. Эти пороги повышают безопасность сети, но при этом делают аппаратные и эксплуатационные расходы для обычных участников довольно высокими при длительном запуске узла. Как только узлы постепенно начнут концентрироваться в руках немногих крупных игроков, даже самая удачная архитектура неизбежно начнет искажаться.
Поэтому, когда я сейчас смотрю на Dusk, я уделяю внимание не тому, сколько у него слоев и какие у него TPS. Я смотрю на две вещи: во‑первых, насколько ясно описаны межслойные состояния активов и границы приватности; во‑вторых, какие типы приложений появляются на EVM-слое — если там будут только перенесенные универсальные протоколы, то модульность просто сменит способ привлечения клиентов; а если приложения действительно вызывают встроенные возможности по работе с конфиденциальными данными (например, используют криптографическую книгу ордеров Hedger или конфиденциальные ценные бумаги по стандарту XSC), тогда становится ясно, что различие этой архитектуры реально используется.
Архитектуру собрали — теперь посмотрим, что сможет вырасти сверху.
#dusk $DUSK @Dusk
