За последние два дня я заново перерисовал Core Components @Dusk , и только тогда смог развести по разным местам три названия — DuskVM, DuskEVM и DuskDS. Сначала я тоже думал, что это просто «одна цепь, совместимая с двумя виртуальными машинами», но на деле разделение ролей больше похоже на три слоя: DuskDS отвечает за консенсус, финальность и доступность данных; DuskVM позволяет контрактам Rust/WASM напрямую работать на L1; а DuskEVM — это EVM-эквивалентная среда исполнения на базе OP Stack, которая передаёт расчёты и публикацию данных в DuskDS.
Это означает, что разработчик не ограничен глупым выбором из двух вариантов. Если уже есть Solidity-контракты и вы зависите от EVM-кошельков и инструментов, то DuskEVM — более дешёвый по входу путь; если же нужно напрямую работать с активами L1, моделью конфиденциальности Phoenix, возможностями zero-knowledge или более низкоуровневым управлением протоколом, то DuskVM — это нативная точка входа. Два пути разделяют одну и ту же базу расчётов, но это не значит, что функциональность и предположения о безопасности полностью совпадают.
Я довольно настороженно отношусь к тезису «EVM compatible = экосистема сама переедет». Совместимость может лишь снизить порог развёртывания, но она не заменяет подключение кошельков, стабильный RPC, индексаторы, ликвидность и реальных пользователей. С другой стороны, одного лишь акцента на нативном Rust/ZK тоже недостаточно: инструменты слишком жёсткие, и разработчики не будут переписывать весь продукт ради технологической чистоты.
Поэтому, когда я смотрю на технический прогресс $DUSK , я разбиваю метрики по отдельности: есть ли у DuskEVM сторонние Solidity-приложения, есть ли у DuskVM неофициальные контракты, насколько стабилен путь их расчёта через DuskDS. Если #dusk действительно обладает защитным рвом, он должен выглядеть так: «знакомые инструменты могут войти, а когда нужна конфиденциальность — можно спуститься ниже», а не как просто три новых термина, сваленных вместе. Вы бы сначала выбрали совместимость или нативные возможности?
Это означает, что разработчик не ограничен глупым выбором из двух вариантов. Если уже есть Solidity-контракты и вы зависите от EVM-кошельков и инструментов, то DuskEVM — более дешёвый по входу путь; если же нужно напрямую работать с активами L1, моделью конфиденциальности Phoenix, возможностями zero-knowledge или более низкоуровневым управлением протоколом, то DuskVM — это нативная точка входа. Два пути разделяют одну и ту же базу расчётов, но это не значит, что функциональность и предположения о безопасности полностью совпадают.
Я довольно настороженно отношусь к тезису «EVM compatible = экосистема сама переедет». Совместимость может лишь снизить порог развёртывания, но она не заменяет подключение кошельков, стабильный RPC, индексаторы, ликвидность и реальных пользователей. С другой стороны, одного лишь акцента на нативном Rust/ZK тоже недостаточно: инструменты слишком жёсткие, и разработчики не будут переписывать весь продукт ради технологической чистоты.
Поэтому, когда я смотрю на технический прогресс $DUSK , я разбиваю метрики по отдельности: есть ли у DuskEVM сторонние Solidity-приложения, есть ли у DuskVM неофициальные контракты, насколько стабилен путь их расчёта через DuskDS. Если #dusk действительно обладает защитным рвом, он должен выглядеть так: «знакомые инструменты могут войти, а когда нужна конфиденциальность — можно спуститься ниже», а не как просто три новых термина, сваленных вместе. Вы бы сначала выбрали совместимость или нативные возможности?
