В последнее время я размышляю над одним вопросом: почему большинство публичных блокчейнов делают акцент на совместимости, но почти никто не обсуждает «нужно ли разным типам активов использовать разную логику выполнения»?
Когда я изучал техническую архитектуру Dusk, я обнаружил, что она не пошла по пути «одна виртуальная машина на всё». DuskEVM предоставляет разработчикам Solidity привычную среду, DuskVM позволяет исполнять контракты на Rust прямо в L1, а Transfer Contract в зависимости от типа данных транзакции распределяет вызов по соответствующим маршрутам валидации — и это решение не ради демонстрации, а в ответ на реальность: после того как такие сложные активы, как паевые (private equity) и корпоративные облигации, выводятся в ончейн, правила исполнения для них полностью отличаются от правил для обычных токенов.
Проблема традиционных активов не в выпуске, а в использовании. Может ли доля в частном фонде быть залогом? Если да, кому может быть передан залог при ликвидации? Как подтверждается статус квалифицированного инвестора? Если эти правила остаются только в офчейн-протоколах или на уровне ограничений в интерфейсе, их можно обойти; если же зашить их в смарт-контракты, это неизбежно снизит гибкость.
Подход Dusk — вынести логику валидации в среду выполнения. Phoenix обрабатывает транзакции, требующие сокрытия сумм, Moonlight — сценарии, в которых нужна публичная и прозрачная информация; оба компонента используют общий слой расчётов. Это означает, что атрибуты актива обеспечиваются не самодисциплиной эмитента, а принудительным исполнением на уровне базовой архитектуры.
Но такая многослойность несёт и издержки на понимание. Разработчикам нужно понимать, когда какой виртуальной машине отдавать задачу, а пользователям — разбираться, по какому пути проходит их транзакция. Если большинство людей в течение длительного времени используют только EVM-совместимый слой, то нативные возможности DuskVM и Phoenix будут оставаться лишь теоретическим преимуществом.
Поэтому меня интересует не то, сколько типов активов поддерживает Dusk, а то, будут ли эти активы действительно задействовать те дифференцированные возможности, которые заложены в её дизайн. Ценность технической архитектуры в конечном итоге нужно подтверждать реальными сценариями использования.
#dusk @Dusk $DUSK
Когда я изучал техническую архитектуру Dusk, я обнаружил, что она не пошла по пути «одна виртуальная машина на всё». DuskEVM предоставляет разработчикам Solidity привычную среду, DuskVM позволяет исполнять контракты на Rust прямо в L1, а Transfer Contract в зависимости от типа данных транзакции распределяет вызов по соответствующим маршрутам валидации — и это решение не ради демонстрации, а в ответ на реальность: после того как такие сложные активы, как паевые (private equity) и корпоративные облигации, выводятся в ончейн, правила исполнения для них полностью отличаются от правил для обычных токенов.
Проблема традиционных активов не в выпуске, а в использовании. Может ли доля в частном фонде быть залогом? Если да, кому может быть передан залог при ликвидации? Как подтверждается статус квалифицированного инвестора? Если эти правила остаются только в офчейн-протоколах или на уровне ограничений в интерфейсе, их можно обойти; если же зашить их в смарт-контракты, это неизбежно снизит гибкость.
Подход Dusk — вынести логику валидации в среду выполнения. Phoenix обрабатывает транзакции, требующие сокрытия сумм, Moonlight — сценарии, в которых нужна публичная и прозрачная информация; оба компонента используют общий слой расчётов. Это означает, что атрибуты актива обеспечиваются не самодисциплиной эмитента, а принудительным исполнением на уровне базовой архитектуры.
Но такая многослойность несёт и издержки на понимание. Разработчикам нужно понимать, когда какой виртуальной машине отдавать задачу, а пользователям — разбираться, по какому пути проходит их транзакция. Если большинство людей в течение длительного времени используют только EVM-совместимый слой, то нативные возможности DuskVM и Phoenix будут оставаться лишь теоретическим преимуществом.
Поэтому меня интересует не то, сколько типов активов поддерживает Dusk, а то, будут ли эти активы действительно задействовать те дифференцированные возможности, которые заложены в её дизайн. Ценность технической архитектуры в конечном итоге нужно подтверждать реальными сценариями использования.
#dusk @Dusk $DUSK