Я ожидал, что цепочка, рассчитанная на регулируемые рынки, будет поставляться со списком нативных контрактов. Комплаенс, идентификация, реестр — всё, включая остальное, будет встроено в genesis.
Dusk поставляется с двумя. Stake и Transfer.
Stake отслеживает провайдеров, стейкинги, награды и управление валидаторским набором. Transfer перемещает DUSK и служит точкой входа для выполнения транзакций и оплаты газа.
Это весь набор genesis.
Всё регулируемое находится поверх него. Zedger на DuskVM, Hedger на DuskEVM, Citadel для идентичности, Dusk Trade как продуктовый интерфейс. Ничего из этого не «сварено» с базой.
Моё рассуждение такое: требования меняются. Правила соответствия, обязанности по раскрытию информации и форматы отчётности меняются вместе с регулированием, и всё, что находится в genesis, меняется только через hard fork. Встраивание логики комплаенса в базовый слой означало бы цепочку, которой нужно делать fork каждый раз при обновлении директивы.
Но есть и другой аргумент — он же реальный. Тонкая база означает, что гарантии, которые людям действительно важны, живут в контрактах, которые можно обновлять, а обновляемость — это другое обещание по безопасности, чем неизменяемость.
Следует ли располагать части, которые с наибольшей вероятностью будут меняться, дальше от консенсуса, или это просто переносит риск туда, где его меньше изучают?
Тонкая база или тонкие гарантии?
#dusk @Dusk $DUSK