Я снова и снова возвращался к DuskEVM по причине, отличной от той, которую ожидала. Очевидный тезис — совместимость с Ethereum, но это почему‑то кажется слишком простым, чтобы быть в самой цели.
EVM сегодня — уже огромный слой инфраструктуры: Solidity, Foundry, Hardhat, viem, ethers, кошельки, RPC, индексаторы и привычные разработческие рабочие процессы.
Разработчикам не нужно ещё одно экосистемное «поле», которое нужно учить.
Им нужен повод реально использовать то, что они уже знают, но где‑то ещё.
Поэтому DuskEVM интереснее как мост, а не как «ещё одна EVM‑цепочка».
Идея в том, чтобы сохранить опыт, ориентированный на Ethereum, пока DuskDS обрабатывает расчёты и доступность данных снизу.
@Dusk_Foundation используется для газа, а приложения получают доступ к остальной части стека Dusk.
Часть, о которой я постоянно думал, — это входной порог.
Если разработчик может принести знакомые инструменты вместо того, чтобы учить совершенно новый стек и начинать всё заново с нуля, у $DUSK гораздо больше шансов привлечь реальные приложения.
А регулируемые активы делают это различие ещё более важным.
Логика смарт‑контрактов — лишь один фрагмент, когда важны соблюдение требований, приватность и расчёты.
Но есть один нюанс.
Если Ethereum‑инструментарий — главная причина использовать DuskEVM, то почему бы не просто строить на Ethereum или на L2 и пристегнуть недостающие элементы соблюдения требований и приватности?
Вот где одной лишь совместимости с EVM становится недостаточно.
DuskEVM нужны приложения, которые делают лежащий в основе стек Dusk достаточно ценным, чтобы за него захотелось перейти по мосту.
Иначе это будет просто ещё один знакомый интерфейс на очень перегруженном рынке.
#dusk
EVM сегодня — уже огромный слой инфраструктуры: Solidity, Foundry, Hardhat, viem, ethers, кошельки, RPC, индексаторы и привычные разработческие рабочие процессы.
Разработчикам не нужно ещё одно экосистемное «поле», которое нужно учить.
Им нужен повод реально использовать то, что они уже знают, но где‑то ещё.
Поэтому DuskEVM интереснее как мост, а не как «ещё одна EVM‑цепочка».
Идея в том, чтобы сохранить опыт, ориентированный на Ethereum, пока DuskDS обрабатывает расчёты и доступность данных снизу.
@Dusk_Foundation используется для газа, а приложения получают доступ к остальной части стека Dusk.
Часть, о которой я постоянно думал, — это входной порог.
Если разработчик может принести знакомые инструменты вместо того, чтобы учить совершенно новый стек и начинать всё заново с нуля, у $DUSK гораздо больше шансов привлечь реальные приложения.
А регулируемые активы делают это различие ещё более важным.
Логика смарт‑контрактов — лишь один фрагмент, когда важны соблюдение требований, приватность и расчёты.
Но есть один нюанс.
Если Ethereum‑инструментарий — главная причина использовать DuskEVM, то почему бы не просто строить на Ethereum или на L2 и пристегнуть недостающие элементы соблюдения требований и приватности?
Вот где одной лишь совместимости с EVM становится недостаточно.
DuskEVM нужны приложения, которые делают лежащий в основе стек Dusk достаточно ценным, чтобы за него захотелось перейти по мосту.
Иначе это будет просто ещё один знакомый интерфейс на очень перегруженном рынке.
#dusk