"Я Сравнил Деплой на DuskEVM со своим воркфлоу OP Stack. Шаги почти не отличались. Тогда в голову пришёл главный вопрос."
Раньше я пролистывал новости формата «цепочка X запускает EVM-слой», не особо вчитываясь. Очередная совместимость, ещё один бридж для настройки, ещё несколько дней, чтобы привыкнуть. Это было моё стандартное допущение.
Когда я изучал документацию Dusk по DuskEVM, я попытался сопоставить каждый шаг деплоя с тем воркфлоу OP Stack, который уже использую. Та же конфигурация Hardhat. Та же JSON-RPC-интерфейс. Те же команды Foundry, то же Blockscout для верификации контрактов. DuskEVM работает на OP Stack / op-geth как секвенсер — точная связка стека под Optimism и Base.
Сначала я думал, что «совместимость с EVM» означает базовую совместимость, а трение проявляется только когда начинаешь реально деплоить. Это было неверное направление. Вопрос не в том, приходится ли разработчикам учиться чему-то новому. Вопрос — что именно отличается от Base или OP Mainnet и почему это имеет значение.
Отличие — в батчере. Вместо того чтобы публиковать данные транзакций в Ethereum L1, DuskEVM отправляет их в DuskDS — собственный слой урегулирования и доступности данных Dusk. Тот же Solidity-воркфлоу. Но якорь финальности — в консенсусе Dusk: детерминированное урегулирование, уровень комплаенса (контракты Zedger, XSC). Не в Ethereum. Именно поэтому регулируемое финансовое приложение может работать здесь так, как оно не может на Base или OP Mainnet.
Dusk выбрал OP Stack не только ради удобства. Любое существующее EVM-приложение становится потенциальным приложением на Dusk — без необходимости переписывать что-либо. Почти нулевое трение при онбординге, при этом всё «под капотом» сохраняет свойства, которые Dusk шесть лет выстраивал.
С чем я всё ещё остаюсь: когда технический барьер почти исчезает, что на самом деле решает, будет ли разработчик строить на DuskEVM? Пользовательская экосистема, институциональное лицензирование или газовая экономика?
#dusk $DUSK @Dusk $BTC $BNB
#dusk @Dusk
Раньше я пролистывал новости формата «цепочка X запускает EVM-слой», не особо вчитываясь. Очередная совместимость, ещё один бридж для настройки, ещё несколько дней, чтобы привыкнуть. Это было моё стандартное допущение.
Когда я изучал документацию Dusk по DuskEVM, я попытался сопоставить каждый шаг деплоя с тем воркфлоу OP Stack, который уже использую. Та же конфигурация Hardhat. Та же JSON-RPC-интерфейс. Те же команды Foundry, то же Blockscout для верификации контрактов. DuskEVM работает на OP Stack / op-geth как секвенсер — точная связка стека под Optimism и Base.
Сначала я думал, что «совместимость с EVM» означает базовую совместимость, а трение проявляется только когда начинаешь реально деплоить. Это было неверное направление. Вопрос не в том, приходится ли разработчикам учиться чему-то новому. Вопрос — что именно отличается от Base или OP Mainnet и почему это имеет значение.
Отличие — в батчере. Вместо того чтобы публиковать данные транзакций в Ethereum L1, DuskEVM отправляет их в DuskDS — собственный слой урегулирования и доступности данных Dusk. Тот же Solidity-воркфлоу. Но якорь финальности — в консенсусе Dusk: детерминированное урегулирование, уровень комплаенса (контракты Zedger, XSC). Не в Ethereum. Именно поэтому регулируемое финансовое приложение может работать здесь так, как оно не может на Base или OP Mainnet.
Dusk выбрал OP Stack не только ради удобства. Любое существующее EVM-приложение становится потенциальным приложением на Dusk — без необходимости переписывать что-либо. Почти нулевое трение при онбординге, при этом всё «под капотом» сохраняет свойства, которые Dusk шесть лет выстраивал.
С чем я всё ещё остаюсь: когда технический барьер почти исчезает, что на самом деле решает, будет ли разработчик строить на DuskEVM? Пользовательская экосистема, институциональное лицензирование или газовая экономика?
#dusk $DUSK @Dusk $BTC $BNB
#dusk @Dusk