Раньше я думал, что хороший блокчейн должен уметь всё.
Смарт-контракты?
Конечно.
Приватность?
Добавим.
EVM?
Разумеется.
Пользовательское выполнение?
Почему бы и нет.
Чем длиннее был бы список функций, тем более впечатляющим выглядел бы проект.
Но я передумал.
Когда я смотрю на Dusk, меня привлекло не очередное новое свойство.
Меня привлекло решение не пытаться пропихнуть всё через одну и ту же среду выполнения.
У Dusk есть DuskVM для контрактов Rust/WASM, которые запускаются напрямую на L1, а DuskEVM обеспечивает выполнение Solidity и Vyper через окружение, совместимое с EVM. Оба пути используют DuskDS внизу для расчетов и доступности данных. (docs.dusk.network)
Сначала я подумал:
Зачем делать всё так сложно?
Разве не было бы проще с одной средой?
Потом я начал думать наоборот.
Возможно, навязывание каждой децентрализованной приложениям единой среды — это и есть сложный выбор.
Разработчику, который делает обычное Solidity-приложение, вероятно, не хочется учить совершенно другой стек.
Тому, кто строит протокол, которому нужен прямой доступ к нативным моделям транзакций Dusk, тоже, вероятно, не хочется, чтобы абстракции EVM мешали.
Итак, Dusk по сути дает им разные «двери».
Это не автоматически делает архитектуру лучше.
Больше компонентов — больше всего, что нужно поддерживать.
Больше интерфейсов.
Больше допущений.
Больше способов, как что-то может сломаться.
Но мне нравится логика.
Вместо того чтобы говорить:
«Вот наша единая среда блокчейна. Пусть все используют её.»
Dusk, похоже, говорит:
«Сначала расскажите, что вы собираетесь строить.»
Это тонкое отличие.
И возможно, я слишком придумываю.
Но после того, как увидел столько цепочек, пытающихся стать «всё для всех», готовность Dusk держать разные пути выполнения кажется неожиданно свежей.
Иногда гибкость — это не про добавление большего количества функций.
Иногда гибкость — это умение понимать, какие функции не стоит заставлять работать вместе.
#dusk $DUSK @Dusk
Смарт-контракты?
Конечно.
Приватность?
Добавим.
EVM?
Разумеется.
Пользовательское выполнение?
Почему бы и нет.
Чем длиннее был бы список функций, тем более впечатляющим выглядел бы проект.
Но я передумал.
Когда я смотрю на Dusk, меня привлекло не очередное новое свойство.
Меня привлекло решение не пытаться пропихнуть всё через одну и ту же среду выполнения.
У Dusk есть DuskVM для контрактов Rust/WASM, которые запускаются напрямую на L1, а DuskEVM обеспечивает выполнение Solidity и Vyper через окружение, совместимое с EVM. Оба пути используют DuskDS внизу для расчетов и доступности данных. (docs.dusk.network)
Сначала я подумал:
Зачем делать всё так сложно?
Разве не было бы проще с одной средой?
Потом я начал думать наоборот.
Возможно, навязывание каждой децентрализованной приложениям единой среды — это и есть сложный выбор.
Разработчику, который делает обычное Solidity-приложение, вероятно, не хочется учить совершенно другой стек.
Тому, кто строит протокол, которому нужен прямой доступ к нативным моделям транзакций Dusk, тоже, вероятно, не хочется, чтобы абстракции EVM мешали.
Итак, Dusk по сути дает им разные «двери».
Это не автоматически делает архитектуру лучше.
Больше компонентов — больше всего, что нужно поддерживать.
Больше интерфейсов.
Больше допущений.
Больше способов, как что-то может сломаться.
Но мне нравится логика.
Вместо того чтобы говорить:
«Вот наша единая среда блокчейна. Пусть все используют её.»
Dusk, похоже, говорит:
«Сначала расскажите, что вы собираетесь строить.»
Это тонкое отличие.
И возможно, я слишком придумываю.
Но после того, как увидел столько цепочек, пытающихся стать «всё для всех», готовность Dusk держать разные пути выполнения кажется неожиданно свежей.
Иногда гибкость — это не про добавление большего количества функций.
Иногда гибкость — это умение понимать, какие функции не стоит заставлять работать вместе.
#dusk $DUSK @Dusk
