#dusk $DUSK @Dusk
Просматривая базовые компоненты Dusk, я заметил кое-что, что легко проскочить: существуют два отдельных протокола для выпуска и управления токенизированными регулируемыми активами — а не один. Zedger работает нативно в DuskDS, базовом слое расчетов. Hedger работает в DuskEVM, среде исполнения, совместимой с Ethereum, которая находится поверх него. Оба построены вокруг одной и той же идеи — ограничения по соблюдению требований и конфиденциальности «вшиты» в сам механизм выпуска и управления активом — просто реализованы в двух разных средах.
Моя первая реакция была — подумать, почему поддерживаются две версии по сути одной и той же логики регулирования вместо того, чтобы выбрать одну и заставить всех на нее опираться. Но если задуматься о том, кто именно выпускает регулируемые ценные бумаги, становится понятнее. Инструменты существующей организации, ее процессы аудита и команды разработчиков не «сбрасываются» только потому, что где-то более эффективно устроен слой расчетов. Одни эмитенты и их юридические/комплаенс-стэки уже глубоко завязаны на инструментарий EVM; другие же начинают с более чистого листа и могут строить нативно. Предоставление одного и того же набора ограничений через два входа позволяет обеим группам оказаться примерно там, где они уже находятся, вместо того чтобы навязывать всем единственный сценарий миграции.
Однако эта гибкость не бесплатна. Две реализации протокола, чувствительного к требованиям соответствия, означают две независимые вещи: его нужно независимо аудитировать, независимо синхронизировать по мере того, как меняются нормативные требования, и независимо доверять тому, что со временем реализации не начнут незаметно расходиться. Ошибка или несоответствие, которые проявятся в одном варианте, но не проявятся в другом, — это реальная категория риска, которую не пришлось бы отдельно управлять при единой унифицированной реализации.
Поэтому практический вопрос не в том, является ли сама по себе опциональность «native vs EVM» хорошей идеей — она очевидно снижает порог входа для разных типов эмитентов. Вопрос в том, сможет ли Dusk удерживать оба протокола ведущими себя идентично на уровне гарантий, которые действительно необходимы для выпуска регулируемых активов, особенно учитывая то, что каждый из них развивается со временем в своей собственной среде исполнения.
$DUSK
Просматривая базовые компоненты Dusk, я заметил кое-что, что легко проскочить: существуют два отдельных протокола для выпуска и управления токенизированными регулируемыми активами — а не один. Zedger работает нативно в DuskDS, базовом слое расчетов. Hedger работает в DuskEVM, среде исполнения, совместимой с Ethereum, которая находится поверх него. Оба построены вокруг одной и той же идеи — ограничения по соблюдению требований и конфиденциальности «вшиты» в сам механизм выпуска и управления активом — просто реализованы в двух разных средах.
Моя первая реакция была — подумать, почему поддерживаются две версии по сути одной и той же логики регулирования вместо того, чтобы выбрать одну и заставить всех на нее опираться. Но если задуматься о том, кто именно выпускает регулируемые ценные бумаги, становится понятнее. Инструменты существующей организации, ее процессы аудита и команды разработчиков не «сбрасываются» только потому, что где-то более эффективно устроен слой расчетов. Одни эмитенты и их юридические/комплаенс-стэки уже глубоко завязаны на инструментарий EVM; другие же начинают с более чистого листа и могут строить нативно. Предоставление одного и того же набора ограничений через два входа позволяет обеим группам оказаться примерно там, где они уже находятся, вместо того чтобы навязывать всем единственный сценарий миграции.
Однако эта гибкость не бесплатна. Две реализации протокола, чувствительного к требованиям соответствия, означают две независимые вещи: его нужно независимо аудитировать, независимо синхронизировать по мере того, как меняются нормативные требования, и независимо доверять тому, что со временем реализации не начнут незаметно расходиться. Ошибка или несоответствие, которые проявятся в одном варианте, но не проявятся в другом, — это реальная категория риска, которую не пришлось бы отдельно управлять при единой унифицированной реализации.
Поэтому практический вопрос не в том, является ли сама по себе опциональность «native vs EVM» хорошей идеей — она очевидно снижает порог входа для разных типов эмитентов. Вопрос в том, сможет ли Dusk удерживать оба протокола ведущими себя идентично на уровне гарантий, которые действительно необходимы для выпуска регулируемых активов, особенно учитывая то, что каждый из них развивается со временем в своей собственной среде исполнения.
$DUSK