Посты
--
Eman098
·
--
#dusk $DUSK @Dusk
Что привлекло мое внимание при изучении документации Dusk: существует только два контракта. На этапе genesis — контракт stake и контракт transfer. Всё остальное, включая DuskVM и DuskEVM, находится поверх них.
Странная концентрация для сети, предназначенной для расчетов регулируемых активов. Поэтому мне хотелось проверить, что именно делают эти два контракта, и можно ли их изменить позже.
Контракт stake отслеживает поставщиков провижинингов (provisioners): насколько они заcтечены, когда вознаграждения созревают, и как применяется слэшинг. Контракт transfer обрабатывает и публичные (Moonlight), и защищённые (Phoenix) балансы, и это единственное место, где реально происходит перевод средств между контрактами. В каждой среде выполнения всё маршрутизируется через него для расчетов и доступности данных согласно текущей документации.
Почему это важно: если вы строите поверх DuskEVM или выпускаете активы через Dusk Trade, вы доверяете не только логике собственного контракта. Вы доверяете тому, что эти два genesis-контракта будут работать корректно в долгосрочной перспективе, потому что они — слой расчетов (settlement substrate) под всем остальным.
Вот что мне не удалось прояснить. В документации говорится, что эти контракты со временем подвергались рефакторингу: контракт stake был пересобран, чтобы исправить проблему со storage, а позже инженерные обновления изменили его структуру событий (Event structure). То есть, ясно, что они не «заморожены» в смысле неизменности с момента genesis.
Непонятно, какой реальный путь обновлений: обновления носят произвольный характер (команда протокола выпускает сетевое обновление) или существует формальный шаг on-chain-управления, при котором provisioners голосуют до того, как изменится логика genesis-контрактов? Та документация, которую я нашёл, описывает то, что делают контракты, но не то, как их модификации получают авторизацию.
Для сети, позиционирующей себя как платформа для институциональных расчетов, различие между авторизованным обновлением команды и обновлением, одобренным provisioners, кажется тем, что должно быть явно где-то задокументировано.
Кто-нибудь видел, где @Dusk указывает фактический процесс Authorization для изменений genesis-контрактов?
$DUSK #dusk
Что привлекло мое внимание при изучении документации Dusk: существует только два контракта. На этапе genesis — контракт stake и контракт transfer. Всё остальное, включая DuskVM и DuskEVM, находится поверх них.
Странная концентрация для сети, предназначенной для расчетов регулируемых активов. Поэтому мне хотелось проверить, что именно делают эти два контракта, и можно ли их изменить позже.
Контракт stake отслеживает поставщиков провижинингов (provisioners): насколько они заcтечены, когда вознаграждения созревают, и как применяется слэшинг. Контракт transfer обрабатывает и публичные (Moonlight), и защищённые (Phoenix) балансы, и это единственное место, где реально происходит перевод средств между контрактами. В каждой среде выполнения всё маршрутизируется через него для расчетов и доступности данных согласно текущей документации.
Почему это важно: если вы строите поверх DuskEVM или выпускаете активы через Dusk Trade, вы доверяете не только логике собственного контракта. Вы доверяете тому, что эти два genesis-контракта будут работать корректно в долгосрочной перспективе, потому что они — слой расчетов (settlement substrate) под всем остальным.
Вот что мне не удалось прояснить. В документации говорится, что эти контракты со временем подвергались рефакторингу: контракт stake был пересобран, чтобы исправить проблему со storage, а позже инженерные обновления изменили его структуру событий (Event structure). То есть, ясно, что они не «заморожены» в смысле неизменности с момента genesis.
Непонятно, какой реальный путь обновлений: обновления носят произвольный характер (команда протокола выпускает сетевое обновление) или существует формальный шаг on-chain-управления, при котором provisioners голосуют до того, как изменится логика genesis-контрактов? Та документация, которую я нашёл, описывает то, что делают контракты, но не то, как их модификации получают авторизацию.
Для сети, позиционирующей себя как платформа для институциональных расчетов, различие между авторизованным обновлением команды и обновлением, одобренным provisioners, кажется тем, что должно быть явно где-то задокументировано.
Кто-нибудь видел, где @Dusk указывает фактический процесс Authorization для изменений genesis-контрактов?
$DUSK #dusk
Отказ от ответственности. Содержит мнения третьих сторон. Не является рекомендацией. Binance AI не предоставляет гарантий. См. Правила и условия.