#dusk $DUSK @Dusk Сначала я воспринимал совместимость с EVM как простую галочку.
Если цепочка поддерживает Solidity, разработчики придут. Разве не так?
Потом я присмотрелся к DuskEVM — и то предположение начало казаться слишком поверхностным.
Важно на самом деле то, что разработчики смогут сохранить, когда начнут миграцию.
С DuskEVM разработчики могут работать в среде, эквивалентной EVM, используя Solidity и знакомые инструменты EVM. Это значит, что разговор не сводится просто к добавлению очередной среды исполнения. Речь о том, чтобы уменьшить дистанцию между тем, что разработчики уже знают, и тем, что Dusk строит.
Именно это привлекло моё внимание.
Потому что попросить разработчика выучить совершенно новый стек — это одно. А вот позволить им перенести знакомые сценарии работы со smart-контрактами в другую архитектуру блокчейна — это уже другое.
И ещё есть DuskDS.
DuskEVM занимается исполнением, а DuskDS обеспечивает основу для расчетов и доступности данных, лежащую под ним. DuskVM — это ещё один путь исполнения: он запускает Rust/WASM-контракты напрямую в Dusk L1.
Так что я задумался:
Если разные среды исполнения могут опираться на одну и ту же базу расчетов, делает ли это общую архитектуру более гибкой?
Возможно.
Но я не думаю, что одна лишь совместимость с EVM доказывает что-то.
Настоящая проверка — что произойдёт после того, как разработчики придут. Они действительно будут строить продукты? Насколько удобными окажутся инструменты? Получают ли приложения выгоду от разделения между исполнением и расчетами?
Вот за чем мне сейчас интереснее всего наблюдать.
Для развивающегося Layer 1: достаточно ли поддержки Solidity, чтобы привлечь разработчиков, или реальная проверка начинается, когда люди уже начинают создавать?
@Dusk $DUSK
#Dusk #DuskEVM
Если цепочка поддерживает Solidity, разработчики придут. Разве не так?
Потом я присмотрелся к DuskEVM — и то предположение начало казаться слишком поверхностным.
Важно на самом деле то, что разработчики смогут сохранить, когда начнут миграцию.
С DuskEVM разработчики могут работать в среде, эквивалентной EVM, используя Solidity и знакомые инструменты EVM. Это значит, что разговор не сводится просто к добавлению очередной среды исполнения. Речь о том, чтобы уменьшить дистанцию между тем, что разработчики уже знают, и тем, что Dusk строит.
Именно это привлекло моё внимание.
Потому что попросить разработчика выучить совершенно новый стек — это одно. А вот позволить им перенести знакомые сценарии работы со smart-контрактами в другую архитектуру блокчейна — это уже другое.
И ещё есть DuskDS.
DuskEVM занимается исполнением, а DuskDS обеспечивает основу для расчетов и доступности данных, лежащую под ним. DuskVM — это ещё один путь исполнения: он запускает Rust/WASM-контракты напрямую в Dusk L1.
Так что я задумался:
Если разные среды исполнения могут опираться на одну и ту же базу расчетов, делает ли это общую архитектуру более гибкой?
Возможно.
Но я не думаю, что одна лишь совместимость с EVM доказывает что-то.
Настоящая проверка — что произойдёт после того, как разработчики придут. Они действительно будут строить продукты? Насколько удобными окажутся инструменты? Получают ли приложения выгоду от разделения между исполнением и расчетами?
Вот за чем мне сейчас интереснее всего наблюдать.
Для развивающегося Layer 1: достаточно ли поддержки Solidity, чтобы привлечь разработчиков, или реальная проверка начинается, когда люди уже начинают создавать?
@Dusk $DUSK
#Dusk #DuskEVM
