#dusk $DUSK
В эти пару дней я просматривал документацию DuskEVM по @Dusk , и есть одна деталь, которую раньше я действительно упустил:
То, что транзакцию упаковали в DuskEVM, не означает, что эта транзакция уже завершена.
В текущей архитектуре DuskEVM и DuskDS занимаются не одной и той же задачей.
Solidity-контракт сначала выполняется в DuskEVM, затем транзакция попадает в sequencer и включается в L2 block. Дальше batcher еще должен передать данные транзакции в DuskDS, и подтверждение статуса продолжается с помощью механизмов вроде commitment и fault proof.
И только DuskDS отвечает за settlement и data availability.
Так что теперь я понимаю DuskEVM иначе — я скорее не буду упрощенно воспринимать его как «просто Dusk с добавленным EVM».
Более точно это можно сформулировать так:
DuskEVM управляет выполнением, а DuskDS в итоге решает, считается ли всё действительным.
Это также объясняет, почему официальная документация отдельно проводит различие между transaction inclusion и settlement.
Даже текущий процесс withdrawal на testnet показывает такую же логику: сначала инициирование в DuskEVM, затем доказывание на Dusk L1, и в конце finalize. То есть, если на стороне L2 показано «успешно», это еще не означает, что на этом всё окончательно завершилось.
Для обычных переводов это отличие может быть не таким захватывающим, но в финансовых сценариях, как мне кажется, оно как раз важно.
Если такие вещи, как ценные бумаги или фонды, реально выводить на блокчейн, то всех в итоге будет волновать не только «насколько быстро выполняются транзакции», но и более практичный вопрос:
На каком слое в итоге эта транзакция получает окончательность?
Поэтому далее, когда я посмотрю DuskEVM mainnet, мне интересно не только по производительности и совместимости с Solidity, но и то, как именно эта цепочка от execution до settlement в DuskDS будет выглядеть в реальной работе.
По крайней мере распределение ролей в архитектуре сейчас я, кажется, окончательно понял.
В эти пару дней я просматривал документацию DuskEVM по @Dusk , и есть одна деталь, которую раньше я действительно упустил:
То, что транзакцию упаковали в DuskEVM, не означает, что эта транзакция уже завершена.
В текущей архитектуре DuskEVM и DuskDS занимаются не одной и той же задачей.
Solidity-контракт сначала выполняется в DuskEVM, затем транзакция попадает в sequencer и включается в L2 block. Дальше batcher еще должен передать данные транзакции в DuskDS, и подтверждение статуса продолжается с помощью механизмов вроде commitment и fault proof.
И только DuskDS отвечает за settlement и data availability.
Так что теперь я понимаю DuskEVM иначе — я скорее не буду упрощенно воспринимать его как «просто Dusk с добавленным EVM».
Более точно это можно сформулировать так:
DuskEVM управляет выполнением, а DuskDS в итоге решает, считается ли всё действительным.
Это также объясняет, почему официальная документация отдельно проводит различие между transaction inclusion и settlement.
Даже текущий процесс withdrawal на testnet показывает такую же логику: сначала инициирование в DuskEVM, затем доказывание на Dusk L1, и в конце finalize. То есть, если на стороне L2 показано «успешно», это еще не означает, что на этом всё окончательно завершилось.
Для обычных переводов это отличие может быть не таким захватывающим, но в финансовых сценариях, как мне кажется, оно как раз важно.
Если такие вещи, как ценные бумаги или фонды, реально выводить на блокчейн, то всех в итоге будет волновать не только «насколько быстро выполняются транзакции», но и более практичный вопрос:
На каком слое в итоге эта транзакция получает окончательность?
Поэтому далее, когда я посмотрю DuskEVM mainnet, мне интересно не только по производительности и совместимости с Solidity, но и то, как именно эта цепочка от execution до settlement в DuskDS будет выглядеть в реальной работе.
По крайней мере распределение ролей в архитектуре сейчас я, кажется, окончательно понял.