Гонконгское управление денежного обращения опубликовало руководство по реализации смарт-контрактов стейблкоинов, сосредоточив внимание на Соответствии и безопасности
С принятием «Регламента о стабильных монетах» Управление финансовых услуг Гонконга 26 мая 2025 года опубликовало «Руководство по регулированию лицензированных эмитентов стабильных монет (черновик)», целью которого является обеспечение стабильной, безопасной и соответствующей нормативным требованиям работы местной экосистемы стабильных монет. В данном руководстве подробно изложены нормативные требования и операционные стандарты, которые лицензированные эмитенты стабильных монет должны постоянно соблюдать.
В последнее время все большее количество учреждений обращается к команде безопасности за консультациями по вопросам соблюдения нормативных требований к смарт-контрактам. Чтобы помочь эмитентам лучше понять и внедрить соответствующую систему смарт-контрактов, мы специально выпустили «Руководство по реализации смарт-контрактов для эмитентов стейблкоинов Гонконга», чтобы предоставить четкие технические пути и практические рекомендации, поддерживающие здоровое развитие экосистемы стейблкоинов Гонконга.
Первая часть Инфраструктура и стратегии соблюдения
Эта часть предназначена для закладки фундамента высокоуровневой архитектуры системы стабильных монет, где архитектурные решения полностью определяются основными требованиями рамок Гонконгского управления финансовыми услугами. Выбор, сделанный здесь, определит весь путь реализации, обеспечивая глубокую интеграцию соблюдения нормативных требований в технологический стек с самого начала проектирования.
1. Выбор базового распределенного реестра
Регуляторное указание
Лицензированный пользователь должен оценить надежность используемой им базовой технологии распределенного реестра (DLT). Эта оценка охватывает безопасность инфраструктуры, устойчивость к распространенным атакам (таким как атака 51%), гарантии окончательности транзакций и надежность алгоритма согласования.
Технический анализ
Это не просто выбор технических предпочтений, а важная задача по соблюдению норм. Выбор базового блокчейна должен проходить через формальную проверку должной осмотрительности, и весь процесс оценки должен быть тщательно задокументирован, чтобы предоставить достаточные доказательства во время проверки регуляторами. Процесс выбора базового реестра фактически задает тон для безопасности и стабильности всей системы стейблкоинов.
Подчёркивание стабильности книги счетов со стороны Управления валютных дел Гонконга на самом деле является предостережением для эмитентов избегать использования новых блокчейнов, которые не прошли рыночную проверку, имеют слишком высокую степень централизации или безопасность которых вызывает сомнения. Ответственность за доказательство их безопасности и стабильности полностью лежит на эмитенте. Если эмитент выбирает цепочку, безопасность которой ещё не была широко проверена, он должен разработать и внедрить дополнительные компенсирующие контрольные меры.
Руководство по внедрению
Предпочтение зрелым публичным цепям: рекомендуется отдавать предпочтение таким зрелым и высокобезопасным публичным блокчейнам, как Ethereum, Arbitrum и другим. Эти сети обладают естественными преимуществами благодаря своей проверенной устойчивости, обширной сети валидаторов и постоянному общественному контролю. Их высокая стоимость атаки (экономическая безопасность) может напрямую ответить на озабоченность регулирующих органов по поводу защиты от атак 51% и обеспечения окончательности транзакций.
Строгая оценка альтернативных решений: если рассматривается использование консорциума или других типов распределённых реестров, необходимо провести тщательный и количественно измеримый сравнительный анализ, например, аудит безопасности, чтобы доказать, что его стандарты безопасности не ниже, а даже выше, чем у основных публичных цепей.
Документ по оценке рисков: Оценочный отчет должен всесторонне охватывать способность противостоять распространенным атакам, типы алгоритмов консенсуса, а также риски, связанные с дефектами кода, уязвимостями, эксплуатацией уязвимостей и другими угрозами, и подробно анализировать, как эти риски могут потенциально повлиять на выпуск, выкуп и повседневную деятельность стабильных монет. Этот документ является ключевым документом для доказательства разумности выбора технологий перед регулирующими органами.
2. Расширение стандартов токенов и функций регулирования
Регуляторная директива
Регуляторные документы не указывают на какую-либо конкретную стандартную токенизацию (например, ERC-20). Тем не менее, документы требуют реализации ряда основных функций управления, включая создание монет (mint), уничтожение (burn), обновление (upgrade), приостановка (pause), восстановление (resume), заморозка (freeze), черный список (blacklist), белый список (whitelist) и другие операции.
Технический анализ
Гонконгский управляемый финансовый орган фактически определил стандарт токенов "с усиленной регуляцией", который функционально превосходит стандарт ERC-20. Этот стандарт не только требует наличия базовых функций обращения токенов, но и подчеркивает важность безопасности операций, контролируемости прав и возможность отслеживания рисков. Для максимального обеспечения безопасности при соблюдении нормативных требований наиболее эффективным и надежным путем разработки является использование стандартной библиотеки, прошедшей широкое аудирование и признанной сообществом (например, OpenZeppelin), с последующим расширением функциональности.
Руководство по реализации
Базовый стандарт: использование ERC-20 в качестве базового стандарта для обеспечения однородности токенов и их взаимодействия в более широком экосистеме.
Расширение функционала: необходимо интегрировать следующие функциональные модули для соблюдения требований регулирования:
Приостанавливаемый: используется для реализации глобальной функции приостановки и восстановления всех токенов, что является основным инструментом для реагирования на серьезные инциденты безопасности.
Mintable: используется для реализации лицензированными эмитентами процесса контроля, необходимого для выпуска новых токенов, и обеспечивает строгую соответствие объема выпуска токенов достаточным резервным активам в фиатной валюте.
Сжигаемые: предоставляет функцию уничтожения токенов. В конкретной реализации эта функция будет строго контролироваться, а не разрешать любому пользователю самостоятельно уничтожать.
Freezable: используется для приостановки функции перевода токенов для определенных аккаунтов (например, в случае подозрительных транзакций).
Белый список: используется для реализации дополнительных мер безопасности, позволяя участвовать в основных операциях (таких как получение новых токенов), только проверенным и одобренным адресам.
Черный список: используется для реализации торгового запрета на адреса, связанные с незаконной деятельностью (например, отмыванием денег, мошенничеством), запрещая им отправлять/получать токены. Управление черным списком должно быть связано с системой AML/CFT для мониторинга подозрительных транзакций в реальном времени.
AccessControl: Это основа для реализации детализированной, основанной на ролях системы управления правами. Все функции управления должны проходить контроль прав через этот модуль для соблюдения требований разделения ответственности.
3. Основные модели соответствия: выбор черного и белого списков
Регуляторные указания
Документ консультации по вопросам постоянного мониторинга, борьбы с отмыванием денег/финансированием терроризма ( AML/CFT ) предлагает несколько мер, включая "внесение в черный список адресов кошельков, которые были идентифицированы как санкционные или связанные с незаконной деятельностью", или внедрение более строгих мер, таких как "введение системы белого списка для адресов кошельков, принадлежащих держателям стейблкоинов, или использование замкнутой системы".
Технический анализ
Это ключевая точка принятия решений в архитектуре всей системы, которая напрямую определяет открытость, практичность и сложность соблюдения нормативных требований стейблкоина.
Режим черного списка: режим "по умолчанию открыт". Все адреса по умолчанию могут свободно торговать, ограничение будет наложено только на те адреса, которые явно идентифицированы и добавлены в черный список на блокчейне.
Режим белого списка: это "по умолчанию закрытый" замкнутый режим. Любой адрес, если он не прошел явное должное расследование и одобрение со стороны эмитента и не был добавлен в белый список на блокчейне, не может владеть или получать токены.
Несмотря на то, что режим белого списка предоставляет возможности контроля AML (противодействие отмыванию денег), строгая система белого списка для стабильной монеты, предназначенной для широкого использования, означает, что стабильная монета может циркулировать только между предварительно проверенными участниками, что делает ее более похожей на закрытую банковскую книгу, а не на гибкую цифровую валюту.
Таким образом, упомянутая в регуляции модель черного списка, в сочетании с мощными инструментами анализа вне блокчейна, которые требуют регуляторы, образует более сбалансированное решение. Это удовлетворяет требованиям регуляторов и сохраняет полезность активов.
В дизайне система может быть построена как масштабируемая, или одновременно реализовать два режима, чтобы в будущем при ужесточении регулирования или изменении бизнес-модели можно было плавно перейти или переключиться в режим белого списка.
Руководство по внедрению
Режим черного списка (рекомендуемая схема по умолчанию):
Преимущества: более высокая практичность, возможность бесшовной интероперации с обширной экосистемой децентрализованных финансов ( DeFi ), предоставляя пользователям более низкий порог входа и более плавный опыт.
Недостатки: соответствие требованиям в значительной степени зависит от мощных,实时分析 возможностей off-chain мониторинга, чтобы своевременно выявлять и блокировать незаконные адреса.
Способ реализации: в функции перевода смарт-контракта добавить логическую проверку, чтобы убедиться, что адреса отправителя (from) и получателя (to) не занесены в черный список.
Режим белого списка
Преимущества: обеспечивает высший уровень контроля AML/CFT, реализует превентивные меры, а не реагирование после факта.
Недостатки: существенно ограничивает универсальность и уровень принятия стейблкоинов, создает большие операционные расходы на управление белым списком, что может затруднить его становление широко принимаемым средством обмена.
Реализация: в функции перевода смарт-контракта добавить логическую проверку, требующую, чтобы адреса отправителя (from) и получателя (to) были в белом списке. Рекомендуется разработать специальную веб-систему для пользователей, чтобы упростить выполнение операций.
Вторая часть Реализация смарт-контрактов
Эта часть предоставляет подробный план для основных функций смарт-контрактов, превращая сложные требования регулирования в конкретную кодовую логику, модели безопасности и операционные протоколы.
1. Разработка детализированной системы контроля доступа
Регуляторные указания
Дизайн высокорисковых операций должен "предотвращать возможность одностороннего выполнения соответствующих операций любой одной стороной (например, через протоколы многоподписей)". Ответственности за различные операции должны быть полностью изолированы.
Технический анализ
Это означает, что мощная система управления доступом на основе ролей (RBAC) является обязательной. Любая форма единственного "владельца" или "администратора" закрытого ключа является ненадлежащей.
Руководство по внедрению
Необходимо определить ряд четких ролей и назначить эти роли различным сущностям или сотрудникам, контролируемым мультиподписными кошельками, чтобы реализовать разделение обязанностей и минимизировать риск единой точки сбоя или сговора. Каждая роль должна быть ограничена определенной функцией, все операции должны получать мультиподписное разрешение, и необходимо обеспечить, чтобы ни один сотрудник одновременно не занимал несколько высокорисковых ролей. Все операции должны быть задокументированы, и должны подлежать ежегодному стороннему аудиту, распределение прав должно контролироваться администрацией или советом директоров.
MINTER_ROLE: отвечает за операции по выпуску стабильной валюты (mint), включая создание единиц токенов после получения действительного запроса на выпуск и обеспечение соответствия увеличения выпуска с резервным активом.
BURNER_ROLE: отвечает за обработку уничтожения стейблкоинов (burn), включая уничтожение единиц токенов после получения действительного запроса на выкуп.
PAUSER_ROLE: отвечает за приостановку операций с (pause) стабильной монетой, например, временно останавливая переводы, выпуск или выкуп в случае обнаружения аномальных событий (таких как угроза безопасности).
RESUME_ROLE：Отвечает за восстановление операций с (resume) стабильной валютой, например, повторное включение переводов, эмиссии или выкупа после разрешения события приостановки.
FREEZER_ROLE: отвечает за замораживание (freeze) и снятие заморозки (remove freeze) определенных кошельков или токенов, например, временную заморозку активов при обнаружении подозрительной активности (например, риск отмывания денег).
WHITELISTER_ROLE: отвечает за управление белым списком (whitelist), включая добавление или удаление разрешенных адресов кошельков, например, ограничение выпуска токенов только для адресов в белом списке.
BLACKLISTER_ROLE: отвечает за управление черным списком (blacklist) и удаление из черного списка (remove blacklist), например, добавление подозрительных кошельков в черный список для предотвращения переводов.
UPGRADER_ROLE: Если используется可升级模型, отвечает за обновление (upgrade) смарт-контракта, например, обновление кода контракта для исправления уязвимостей или добавления функций.
Таблица 1: Матрица контроля доступа на основе ролей ( RBAC Matrix )
В таблице представлена ясная и интуитивно понятная спецификация для разработчиков и аудиторов, четко отображающая каждую привилегированную операцию с ее необходимыми ролями и типами контроля.
| Операция | Необходимая роль | Тип управления |
|------|----------|----------|
| Чеканка (Mint) | РОЛЬ_ЧЕКАНЩИКА | Мультиподпись |
| Сжечь (Burn) | РОЛЬ_СЖИГАТЕЛЯ | Мультиподпись |
| Пауза (Pause) | PAUSER_ROLE | Мультиподпись |
| Восстановить (Resume) | RESUME_ROLE | Мультиподпись |
| Заморозка (Freeze) | FREEZER_ROLE | Мультиподпись |
| Разблокировать (Unfreeze) | FREEZER_ROLE | Многофакторная подпись |
| Добавить в белый список (Whitelist) | WHITELISTER_ROLE | Мультиподпись |
| Удалить из белого списка (Remove from Whitelist) | WHITELISTER_
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Гонконгское управление денежного обращения опубликовало руководство по реализации смарт-контрактов стейблкоинов, сосредоточив внимание на Соответствии и безопасности
Текст
С принятием «Регламента о стабильных монетах» Управление финансовых услуг Гонконга 26 мая 2025 года опубликовало «Руководство по регулированию лицензированных эмитентов стабильных монет (черновик)», целью которого является обеспечение стабильной, безопасной и соответствующей нормативным требованиям работы местной экосистемы стабильных монет. В данном руководстве подробно изложены нормативные требования и операционные стандарты, которые лицензированные эмитенты стабильных монет должны постоянно соблюдать.
В последнее время все большее количество учреждений обращается к команде безопасности за консультациями по вопросам соблюдения нормативных требований к смарт-контрактам. Чтобы помочь эмитентам лучше понять и внедрить соответствующую систему смарт-контрактов, мы специально выпустили «Руководство по реализации смарт-контрактов для эмитентов стейблкоинов Гонконга», чтобы предоставить четкие технические пути и практические рекомендации, поддерживающие здоровое развитие экосистемы стейблкоинов Гонконга.
Первая часть Инфраструктура и стратегии соблюдения
Эта часть предназначена для закладки фундамента высокоуровневой архитектуры системы стабильных монет, где архитектурные решения полностью определяются основными требованиями рамок Гонконгского управления финансовыми услугами. Выбор, сделанный здесь, определит весь путь реализации, обеспечивая глубокую интеграцию соблюдения нормативных требований в технологический стек с самого начала проектирования.
1. Выбор базового распределенного реестра
Регуляторное указание
Лицензированный пользователь должен оценить надежность используемой им базовой технологии распределенного реестра (DLT). Эта оценка охватывает безопасность инфраструктуры, устойчивость к распространенным атакам (таким как атака 51%), гарантии окончательности транзакций и надежность алгоритма согласования.
Технический анализ
Это не просто выбор технических предпочтений, а важная задача по соблюдению норм. Выбор базового блокчейна должен проходить через формальную проверку должной осмотрительности, и весь процесс оценки должен быть тщательно задокументирован, чтобы предоставить достаточные доказательства во время проверки регуляторами. Процесс выбора базового реестра фактически задает тон для безопасности и стабильности всей системы стейблкоинов.
Подчёркивание стабильности книги счетов со стороны Управления валютных дел Гонконга на самом деле является предостережением для эмитентов избегать использования новых блокчейнов, которые не прошли рыночную проверку, имеют слишком высокую степень централизации или безопасность которых вызывает сомнения. Ответственность за доказательство их безопасности и стабильности полностью лежит на эмитенте. Если эмитент выбирает цепочку, безопасность которой ещё не была широко проверена, он должен разработать и внедрить дополнительные компенсирующие контрольные меры.
Руководство по внедрению
Предпочтение зрелым публичным цепям: рекомендуется отдавать предпочтение таким зрелым и высокобезопасным публичным блокчейнам, как Ethereum, Arbitrum и другим. Эти сети обладают естественными преимуществами благодаря своей проверенной устойчивости, обширной сети валидаторов и постоянному общественному контролю. Их высокая стоимость атаки (экономическая безопасность) может напрямую ответить на озабоченность регулирующих органов по поводу защиты от атак 51% и обеспечения окончательности транзакций.
Строгая оценка альтернативных решений: если рассматривается использование консорциума или других типов распределённых реестров, необходимо провести тщательный и количественно измеримый сравнительный анализ, например, аудит безопасности, чтобы доказать, что его стандарты безопасности не ниже, а даже выше, чем у основных публичных цепей.
Документ по оценке рисков: Оценочный отчет должен всесторонне охватывать способность противостоять распространенным атакам, типы алгоритмов консенсуса, а также риски, связанные с дефектами кода, уязвимостями, эксплуатацией уязвимостей и другими угрозами, и подробно анализировать, как эти риски могут потенциально повлиять на выпуск, выкуп и повседневную деятельность стабильных монет. Этот документ является ключевым документом для доказательства разумности выбора технологий перед регулирующими органами.
2. Расширение стандартов токенов и функций регулирования
Регуляторная директива
Регуляторные документы не указывают на какую-либо конкретную стандартную токенизацию (например, ERC-20). Тем не менее, документы требуют реализации ряда основных функций управления, включая создание монет (mint), уничтожение (burn), обновление (upgrade), приостановка (pause), восстановление (resume), заморозка (freeze), черный список (blacklist), белый список (whitelist) и другие операции.
Технический анализ
Гонконгский управляемый финансовый орган фактически определил стандарт токенов "с усиленной регуляцией", который функционально превосходит стандарт ERC-20. Этот стандарт не только требует наличия базовых функций обращения токенов, но и подчеркивает важность безопасности операций, контролируемости прав и возможность отслеживания рисков. Для максимального обеспечения безопасности при соблюдении нормативных требований наиболее эффективным и надежным путем разработки является использование стандартной библиотеки, прошедшей широкое аудирование и признанной сообществом (например, OpenZeppelin), с последующим расширением функциональности.
Руководство по реализации
Базовый стандарт: использование ERC-20 в качестве базового стандарта для обеспечения однородности токенов и их взаимодействия в более широком экосистеме.
Расширение функционала: необходимо интегрировать следующие функциональные модули для соблюдения требований регулирования:
Приостанавливаемый: используется для реализации глобальной функции приостановки и восстановления всех токенов, что является основным инструментом для реагирования на серьезные инциденты безопасности.
Mintable: используется для реализации лицензированными эмитентами процесса контроля, необходимого для выпуска новых токенов, и обеспечивает строгую соответствие объема выпуска токенов достаточным резервным активам в фиатной валюте.
Сжигаемые: предоставляет функцию уничтожения токенов. В конкретной реализации эта функция будет строго контролироваться, а не разрешать любому пользователю самостоятельно уничтожать.
Freezable: используется для приостановки функции перевода токенов для определенных аккаунтов (например, в случае подозрительных транзакций).
Белый список: используется для реализации дополнительных мер безопасности, позволяя участвовать в основных операциях (таких как получение новых токенов), только проверенным и одобренным адресам.
Черный список: используется для реализации торгового запрета на адреса, связанные с незаконной деятельностью (например, отмыванием денег, мошенничеством), запрещая им отправлять/получать токены. Управление черным списком должно быть связано с системой AML/CFT для мониторинга подозрительных транзакций в реальном времени.
AccessControl: Это основа для реализации детализированной, основанной на ролях системы управления правами. Все функции управления должны проходить контроль прав через этот модуль для соблюдения требований разделения ответственности.
3. Основные модели соответствия: выбор черного и белого списков
Регуляторные указания
Документ консультации по вопросам постоянного мониторинга, борьбы с отмыванием денег/финансированием терроризма ( AML/CFT ) предлагает несколько мер, включая "внесение в черный список адресов кошельков, которые были идентифицированы как санкционные или связанные с незаконной деятельностью", или внедрение более строгих мер, таких как "введение системы белого списка для адресов кошельков, принадлежащих держателям стейблкоинов, или использование замкнутой системы".
Технический анализ
Это ключевая точка принятия решений в архитектуре всей системы, которая напрямую определяет открытость, практичность и сложность соблюдения нормативных требований стейблкоина.
Режим черного списка: режим "по умолчанию открыт". Все адреса по умолчанию могут свободно торговать, ограничение будет наложено только на те адреса, которые явно идентифицированы и добавлены в черный список на блокчейне.
Режим белого списка: это "по умолчанию закрытый" замкнутый режим. Любой адрес, если он не прошел явное должное расследование и одобрение со стороны эмитента и не был добавлен в белый список на блокчейне, не может владеть или получать токены.
Несмотря на то, что режим белого списка предоставляет возможности контроля AML (противодействие отмыванию денег), строгая система белого списка для стабильной монеты, предназначенной для широкого использования, означает, что стабильная монета может циркулировать только между предварительно проверенными участниками, что делает ее более похожей на закрытую банковскую книгу, а не на гибкую цифровую валюту.
Таким образом, упомянутая в регуляции модель черного списка, в сочетании с мощными инструментами анализа вне блокчейна, которые требуют регуляторы, образует более сбалансированное решение. Это удовлетворяет требованиям регуляторов и сохраняет полезность активов.
В дизайне система может быть построена как масштабируемая, или одновременно реализовать два режима, чтобы в будущем при ужесточении регулирования или изменении бизнес-модели можно было плавно перейти или переключиться в режим белого списка.
Руководство по внедрению
Режим черного списка (рекомендуемая схема по умолчанию):
Преимущества: более высокая практичность, возможность бесшовной интероперации с обширной экосистемой децентрализованных финансов ( DeFi ), предоставляя пользователям более низкий порог входа и более плавный опыт.
Недостатки: соответствие требованиям в значительной степени зависит от мощных,实时分析 возможностей off-chain мониторинга, чтобы своевременно выявлять и блокировать незаконные адреса.
Способ реализации: в функции перевода смарт-контракта добавить логическую проверку, чтобы убедиться, что адреса отправителя (from) и получателя (to) не занесены в черный список.
Режим белого списка
Преимущества: обеспечивает высший уровень контроля AML/CFT, реализует превентивные меры, а не реагирование после факта.
Недостатки: существенно ограничивает универсальность и уровень принятия стейблкоинов, создает большие операционные расходы на управление белым списком, что может затруднить его становление широко принимаемым средством обмена.
Реализация: в функции перевода смарт-контракта добавить логическую проверку, требующую, чтобы адреса отправителя (from) и получателя (to) были в белом списке. Рекомендуется разработать специальную веб-систему для пользователей, чтобы упростить выполнение операций.
Вторая часть Реализация смарт-контрактов
Эта часть предоставляет подробный план для основных функций смарт-контрактов, превращая сложные требования регулирования в конкретную кодовую логику, модели безопасности и операционные протоколы.
1. Разработка детализированной системы контроля доступа
Регуляторные указания
Дизайн высокорисковых операций должен "предотвращать возможность одностороннего выполнения соответствующих операций любой одной стороной (например, через протоколы многоподписей)". Ответственности за различные операции должны быть полностью изолированы.
Технический анализ
Это означает, что мощная система управления доступом на основе ролей (RBAC) является обязательной. Любая форма единственного "владельца" или "администратора" закрытого ключа является ненадлежащей.
Руководство по внедрению
Необходимо определить ряд четких ролей и назначить эти роли различным сущностям или сотрудникам, контролируемым мультиподписными кошельками, чтобы реализовать разделение обязанностей и минимизировать риск единой точки сбоя или сговора. Каждая роль должна быть ограничена определенной функцией, все операции должны получать мультиподписное разрешение, и необходимо обеспечить, чтобы ни один сотрудник одновременно не занимал несколько высокорисковых ролей. Все операции должны быть задокументированы, и должны подлежать ежегодному стороннему аудиту, распределение прав должно контролироваться администрацией или советом директоров.
MINTER_ROLE: отвечает за операции по выпуску стабильной валюты (mint), включая создание единиц токенов после получения действительного запроса на выпуск и обеспечение соответствия увеличения выпуска с резервным активом.
BURNER_ROLE: отвечает за обработку уничтожения стейблкоинов (burn), включая уничтожение единиц токенов после получения действительного запроса на выкуп.
PAUSER_ROLE: отвечает за приостановку операций с (pause) стабильной монетой, например, временно останавливая переводы, выпуск или выкуп в случае обнаружения аномальных событий (таких как угроза безопасности).
RESUME_ROLE：Отвечает за восстановление операций с (resume) стабильной валютой, например, повторное включение переводов, эмиссии или выкупа после разрешения события приостановки.
FREEZER_ROLE: отвечает за замораживание (freeze) и снятие заморозки (remove freeze) определенных кошельков или токенов, например, временную заморозку активов при обнаружении подозрительной активности (например, риск отмывания денег).
WHITELISTER_ROLE: отвечает за управление белым списком (whitelist), включая добавление или удаление разрешенных адресов кошельков, например, ограничение выпуска токенов только для адресов в белом списке.
BLACKLISTER_ROLE: отвечает за управление черным списком (blacklist) и удаление из черного списка (remove blacklist), например, добавление подозрительных кошельков в черный список для предотвращения переводов.
UPGRADER_ROLE: Если используется可升级模型, отвечает за обновление (upgrade) смарт-контракта, например, обновление кода контракта для исправления уязвимостей или добавления функций.
Таблица 1: Матрица контроля доступа на основе ролей ( RBAC Matrix )
В таблице представлена ясная и интуитивно понятная спецификация для разработчиков и аудиторов, четко отображающая каждую привилегированную операцию с ее необходимыми ролями и типами контроля.
| Операция | Необходимая роль | Тип управления | |------|----------|----------| | Чеканка (Mint) | РОЛЬ_ЧЕКАНЩИКА | Мультиподпись | | Сжечь (Burn) | РОЛЬ_СЖИГАТЕЛЯ | Мультиподпись | | Пауза (Pause) | PAUSER_ROLE | Мультиподпись | | Восстановить (Resume) | RESUME_ROLE | Мультиподпись | | Заморозка (Freeze) | FREEZER_ROLE | Мультиподпись | | Разблокировать (Unfreeze) | FREEZER_ROLE | Многофакторная подпись | | Добавить в белый список (Whitelist) | WHITELISTER_ROLE | Мультиподпись | | Удалить из белого списка (Remove from Whitelist) | WHITELISTER_