Руководство по реализации смарт-контрактов для эмитентов стейблкоинов в Гонконге
Первая часть Инфраструктура и стратегии соблюдения
1. Выбор базового распределенного реестра
Руководство по реализации
Предпочитайте зрелые публичные цепочки: рекомендуется в первую очередь использовать такие зрелые и безопасные публичные блокчейны, как Ethereum, Arbitrum.
Строгая оценка альтернативных решений: если рассматривается возможность использования консорциума или других типов распределенных реестров, необходимо провести тщательный и количественно измеряемый сравнительный анализ, чтобы доказать, что их стандарты безопасности не ниже, а даже лучше, чем у основных публичных цепочек.
Документ оценки рисков: отчет об оценке должен всесторонне охватывать способность противостоять распространенным атакам, типы алгоритмов консенсуса, а также риски, связанные с кодовыми дефектами, уязвимостями, эксплуатацией уязвимостей и другими угрозами, и подробно анализировать, как эти риски могут повлиять на выпуск, выкуп и повседневную работу стейблкоина.
2. Стандарты основных токенов и расширение регулирующих функций
Руководство по внедрению
Базовый стандарт: использование ERC-20 в качестве базового стандарта для обеспечения однородности токенов и их совместимости в более широких экосистемах.
Расширение функционала: необходимо интегрировать следующие функциональные модули для выполнения требований регулирования:
Приостановка: используется для реализации глобальной функции приостановки и восстановления всех токенов, что является основным инструментом для реагирования на серьезные проблемы с безопасностью.
Mintable: используется для реализации лицензированными эмитентами процесса контроля, позволяющего выпускать новые токены и обеспечивать строгое соответствие объема выпускаемых токенов достаточным резервам фиатной валюты.
Сжигаемый: предоставляет функцию уничтожения токенов. В конкретной реализации эта функция будет строго контролироваться, а не разрешать любому пользователю уничтожать токены по своему усмотрению.
Замораживаемый: используется для приостановки функции перевода токенов на конкретные счета, если это связано с подозрительными сделками (.
Whitelist: используется для внедрения дополнительных мер безопасности, разрешающих участие в основных операциях ) только адресам, прошедшим должную проверку и одобренным, таким как получение новых токенов (.
Черный список: используется для реализации запрета на транзакции адресов, связанных с незаконной деятельностью ), такой как отмывание денег, мошенничество (, запрещая им отправлять/получать токены. Управление черным списком должно быть связано с системой AML/CFT, обеспечивая мониторинг подозрительных транзакций в реальном времени.
AccessControl: это основа для реализации детализированной, основанной на ролях системы управления правами. Все функции управления должны проходить контроль прав через этот модуль, чтобы соответствовать требованиям разделения обязанностей.
) 3. Основные модели соблюдения: выбор черного и белого списков
Руководство по внедрению
Чёрный список режим ### по умолчанию рекомендованное решение (:
Преимущества: обладает более высокой практичностью, может бесшовно взаимодействовать с обширной экосистемой децентрализованных финансов )DeFi(, предоставляя пользователям более низкий порог входа и более плавный опыт.
Недостатки: соответствие требованиям в значительной степени зависит от мощной, актуальной аналитики оффлайн-мониторинга, чтобы своевременно выявлять и блокировать незаконные адреса.
Способ реализации: в функции перевода смарт-контрактов добавить логическую проверку, чтобы убедиться, что адреса отправителя )from( и получателя )to( не занесены в черный список.
Режим белого списка
Преимущества: предоставляет самый высокий уровень контроля AML/CFT, реализует предварительные меры, а не последующую корректировку.
Недостатки: значительно ограничивает универсальность и уровень принятия стейблкоинов, приводит к огромным операционным затратам на управление белыми списками, что может затруднить их становление широко принимаемым средством обмена.
Способ реализации: в функции перевода смарт-контрактов добавить логическую проверку, требующую, чтобы адреса отправителя )from( и получателя )to( были в белом списке. Рекомендуется разработать специальную веб-систему для пользователей для удобства операций.
![Техническое руководство: руководство по внедрению смарт-контрактов для эмитентов стейблкоинов в Гонконге])https://img-cdn.gateio.im/webp-social/moments-007110f49de3004ac74dc51b5ef9801f.webp(
Вторая часть Смарт-контракты реализации
) 1. Проектирование детализированной системы контроля доступа
Руководство по внедрению
Необходимо определить ряд четких ролей и распределить их между различными субъектами или сотрудниками, контролируемыми мультиподписными кошельками, чтобы обеспечить разделение обязанностей и минимизировать риск единой точки отказа или сговора. Каждая роль должна быть ограничена определенной функцией, все операции требуют мультиподписного разрешения, и необходимо обеспечить, чтобы ни один сотрудник не занимал одновременно несколько высокорисковых ролей. Все операции должны быть зарегистрированы в журналах и подвергаться ежегодному стороннему аудиту, распределение прав должно контролироваться администратором или советом директоров.
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( смарт-контракты, например, обновление кода контракта для исправления уязвимостей или добавления функций.
) 2. выпуск ### токен ( механизм
)# Руководство по реализации
Предварительная проверка: перед выполнением выпуска токенов функция должна проверить, находится ли целевой адрес to в черном списке или в замороженном состоянии.
Операционный процесс:
Оффлайн-дью дилижанс: Клиент завершает все необходимые процедуры оффлайн-идентификации клиента ###KYC( и дью-дилижанс клиента )CDD(. Кроме того, в соответствии с правилами AML/CFT, для клиентов, которые устанавливают деловые отношения или проводят разовые сделки свыше определенного порога ), например 8,000 гонконгских долларов (, необходимо выполнить CDD.
Получение средств: Клиент переводит эквивалентные средства в фиатной валюте на банковский счет, указанный эмитентом.
Внутренняя проверка: внутренние системы эмитента подтверждают получение средств и соответствующим образом обновляют бухгалтерские записи резервных активов.
Исполнение в сети: Команда по операциям создает и подписывает многостороннюю транзакцию, вызывая функцию выпуска токенов смарт-контракта, чтобы отправить новосозданный стейблкоин на заранее зарегистрированный и проверенный адрес кошелька клиента.
) 3. Выкуп ### механизм уничтожения (
)# Руководство по реализации
Выкуп подготовка: пользователю сначала необходимо перевести токен, который он хочет выкупить, на указанный адрес, контролируемый эмитентом.
Операционный процесс:
Оффлайн-запрос: пользователь подает оффлайн-запрос на выкуп через платформу эмитента. Перед обработкой запроса эмитент должен провести надлежащую проверку клиента ###CDD(.
Система проверки: проверяет действительность запроса на проверку системы эмитента и проверяет, завершил ли пользователь соответствующие операции по переводу токенов в блокчейне.
Фиатные платежи: эмитент переводит эквивалентную сумму фиатной валюты на предварительно зарегистрированный и проверенный банковский счет пользователя.
Уничтожение на блокчейне: после подтверждения успешного перевода фиатных валют, многоподписной кошелек с ролью BURNER_ROLE вызывает функцию уничтожения, чтобы уничтожить соответствующее количество токенов из указанного адреса.
) 4. Принять экстренные меры: приостановить и заморозить
Руководство по реализации
Приостановка функции: может быть вызвана только мультиподписным кошельком, обладающим PAUSER_ROLE, для глобальной приостановки функций контракта. Условия срабатывания включают обнаружение аномальных событий ###, таких как кибератака или несоответствие резервных активов (, требуется одобрение совета директоров или высшего руководства. Функция восстановления обрабатывается независимым RESUME_ROLE для обеспечения разделения обязанностей.
Функция заморозки: вызывается мультиподписным кошельком, обладающим FREEZER_ROLE, для ограничения переводов по определённым адресам. Условия срабатывания включают подозрительную активность ), такую как предупреждение AML или судебный приказ (, которые должны быть выполнены после проверки вне сети. Размораживание обрабатывается той же ролью, но требует дополнительной аудиторской проверки, публикации соответствующего объявления, чтобы предотвратить злоупотребления.
) 5. Механизм фильтрации адресов и черного списка
Руководство по внедрению
Реализация функции: функция для добавления и удаления из черного списка, которая может вызываться только мультиподписным кошельком, обладающим BLACKLISTER_ROLE.
Ограничение на перевод: запрещено передавать/принимать токены с адресов, внесенных в черный список.
Процесс операций: инструмент анализа отправляет уведомление, инициирует внутреннюю проверку соответствия, после подтверждения командой по соблюдению правил, транзакция на добавление в черный список инициируется мультиподписным кошельком BLACKLISTER_ROLE.
6. Возможности обновления смарт-контрактов
Руководство по реализации
Модель прокси: для смарт-контрактов типа EVM можно использовать зрелую модель прокси ERC-1967 для достижения возможности обновления.
Контроль доступа: функция обновления должна вызываться только многофункциональным кошельком, обладающим ролью UPGRADER_ROLE.
Процесс управления изменениями: в соответствии с требованиями регуляторов, перед предложением любых обновлений необходимо завершить строгий процесс управления изменениями, который включает в себя всесторонний, независимый сторонний аудит безопасности новых логических смарт-контрактов.
7. Журнал событий в цепочке для анализа и отчетности
Руководство по внедрению
Кроме требований стандарта ERC-20 по передаче ###Transfer(, авторизации )Approval(, контракт должен определить и выпустить пользовательские события для всех управленческих действий и изменений состояния:
Выпуск/Сжигание ) Minted/Burned ( событие
Приостановка/возобновление)Paused/Resume(событие
Добавление/удаление в черный список ) BlacklistAdded/BlacklistRemoved ( событие
Добавление/удаление из белого списка )WhitelistAdded/WhitelistRemoved( событие
Изменение привилегий ) RoleGranted/RoleRevoked ( событие
Обновление смарт-контрактов)Обновлено(событие
Третья часть Операционная безопасность и управление жизненным циклом
) 1. Архитектура управления безопасными ключами
Руководство по реализации
Генерация ключей: должна осуществляться через "ритуал ключей" ###key ceremony(, выполненный в физически безопасной среде с полной изоляцией от внешних сетей.
Хранение ключей: все управленческие роли должны контролироваться мультиподписными кошельками. Закрытые ключи подписантов этих мультиподписных кошельков должны храниться в HSM или других безопасных аппаратных кошельках. Для наиболее критически важных ролей соответствующие ключи должны храниться в изолированной системе, физически отделенной от любых онлайн-сред.
Использование ключей: необходимо строго выполнять политику многофакторной подписи. Для подписания транзакций, связанных с "важными приватными ключами", может потребоваться личное присутствие соответствующих лиц.
Резервное копирование и восстановление: резервное копирование ключевых шардов или мнемонических фраз должно храниться в нескольких безопасных и географически распределенных местах на территории Гонконга ) или в местах, одобренных регуляторами (, с использованием защиты от подделки.
) 2. Полный процесс развертывания и мониторинг в реальном времени
Руководство по реализации
Перед официальным развертыванием необходимо разработать и строго соблюдать "контрольный список перед развертыванием":
Полное тестирование: обеспечить покрытие модульных тестов более 95%, покрытие основного кода 100%, обеспечить вывод отчетов о покрытии модульных тестов.
Независимый аудит: получить независимый отчет о безопасности от как минимум одной, а лучше двух заслуживающих доверия аудиторских компаний.
Заморозка кода: после завершения аудита заморозить код до выхода на рынок, больше никаких изменений в коде не вносить.
Регрессионное тестирование: перед официальным развертыванием выполните модульное тестирование и проведите регрессионное тестирование.
Соответствие: получение официального утверждения от внутренней команды по соблюдению норм, подтверждающее, что логика контракта соответствует всем соответствующим требованиям регулирования.
Деплоймент: подготовьте подробный скрипт для развертывания и проведите полную репетицию развертывания на тестовой сети, полностью совпадающей с основной сетью.
Авторизованное развертывание: окончательная операция развертывания выполняется авторизованным кошельком.
После завершения развертывания необходимо принять соответствующие меры мониторинга, чтобы вовремя реализовать меры по смягчению для использования привилегированных ролей и новых угроз.
Мониторинг событий в сети: мониторинг управленческих ролей
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
4
Поделиться
комментарий
0/400
LiquidityNinja
· 5ч назад
Так быстро бежать, что ты хочешь сделать, подожди немного с hksb.
Руководство по реализации смарт-контрактов эмитентов стейблкоинов Гонконга: архитектура, Соответствие и безопасность
Руководство по реализации смарт-контрактов для эмитентов стейблкоинов в Гонконге
Первая часть Инфраструктура и стратегии соблюдения
1. Выбор базового распределенного реестра
Руководство по реализации
2. Стандарты основных токенов и расширение регулирующих функций
Руководство по внедрению
Базовый стандарт: использование ERC-20 в качестве базового стандарта для обеспечения однородности токенов и их совместимости в более широких экосистемах.
Расширение функционала: необходимо интегрировать следующие функциональные модули для выполнения требований регулирования:
Приостановка: используется для реализации глобальной функции приостановки и восстановления всех токенов, что является основным инструментом для реагирования на серьезные проблемы с безопасностью.
Mintable: используется для реализации лицензированными эмитентами процесса контроля, позволяющего выпускать новые токены и обеспечивать строгое соответствие объема выпускаемых токенов достаточным резервам фиатной валюты.
Сжигаемый: предоставляет функцию уничтожения токенов. В конкретной реализации эта функция будет строго контролироваться, а не разрешать любому пользователю уничтожать токены по своему усмотрению.
Замораживаемый: используется для приостановки функции перевода токенов на конкретные счета, если это связано с подозрительными сделками (.
Whitelist: используется для внедрения дополнительных мер безопасности, разрешающих участие в основных операциях ) только адресам, прошедшим должную проверку и одобренным, таким как получение новых токенов (.
Черный список: используется для реализации запрета на транзакции адресов, связанных с незаконной деятельностью ), такой как отмывание денег, мошенничество (, запрещая им отправлять/получать токены. Управление черным списком должно быть связано с системой AML/CFT, обеспечивая мониторинг подозрительных транзакций в реальном времени.
AccessControl: это основа для реализации детализированной, основанной на ролях системы управления правами. Все функции управления должны проходить контроль прав через этот модуль, чтобы соответствовать требованиям разделения обязанностей.
) 3. Основные модели соблюдения: выбор черного и белого списков
Руководство по внедрению
Чёрный список режим ### по умолчанию рекомендованное решение (:
Преимущества: обладает более высокой практичностью, может бесшовно взаимодействовать с обширной экосистемой децентрализованных финансов )DeFi(, предоставляя пользователям более низкий порог входа и более плавный опыт.
Недостатки: соответствие требованиям в значительной степени зависит от мощной, актуальной аналитики оффлайн-мониторинга, чтобы своевременно выявлять и блокировать незаконные адреса.
Способ реализации: в функции перевода смарт-контрактов добавить логическую проверку, чтобы убедиться, что адреса отправителя )from( и получателя )to( не занесены в черный список.
Режим белого списка
Преимущества: предоставляет самый высокий уровень контроля AML/CFT, реализует предварительные меры, а не последующую корректировку.
Недостатки: значительно ограничивает универсальность и уровень принятия стейблкоинов, приводит к огромным операционным затратам на управление белыми списками, что может затруднить их становление широко принимаемым средством обмена.
Способ реализации: в функции перевода смарт-контрактов добавить логическую проверку, требующую, чтобы адреса отправителя )from( и получателя )to( были в белом списке. Рекомендуется разработать специальную веб-систему для пользователей для удобства операций.
![Техническое руководство: руководство по внедрению смарт-контрактов для эмитентов стейблкоинов в Гонконге])https://img-cdn.gateio.im/webp-social/moments-007110f49de3004ac74dc51b5ef9801f.webp(
Вторая часть Смарт-контракты реализации
) 1. Проектирование детализированной системы контроля доступа
Руководство по внедрению
Необходимо определить ряд четких ролей и распределить их между различными субъектами или сотрудниками, контролируемыми мультиподписными кошельками, чтобы обеспечить разделение обязанностей и минимизировать риск единой точки отказа или сговора. Каждая роль должна быть ограничена определенной функцией, все операции требуют мультиподписного разрешения, и необходимо обеспечить, чтобы ни один сотрудник не занимал одновременно несколько высокорисковых ролей. Все операции должны быть зарегистрированы в журналах и подвергаться ежегодному стороннему аудиту, распределение прав должно контролироваться администратором или советом директоров.
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( смарт-контракты, например, обновление кода контракта для исправления уязвимостей или добавления функций.
) 2. выпуск ### токен ( механизм
)# Руководство по реализации
Предварительная проверка: перед выполнением выпуска токенов функция должна проверить, находится ли целевой адрес to в черном списке или в замороженном состоянии.
Операционный процесс:
) 3. Выкуп ### механизм уничтожения (
)# Руководство по реализации
Выкуп подготовка: пользователю сначала необходимо перевести токен, который он хочет выкупить, на указанный адрес, контролируемый эмитентом.
Операционный процесс:
) 4. Принять экстренные меры: приостановить и заморозить
Руководство по реализации
Приостановка функции: может быть вызвана только мультиподписным кошельком, обладающим PAUSER_ROLE, для глобальной приостановки функций контракта. Условия срабатывания включают обнаружение аномальных событий ###, таких как кибератака или несоответствие резервных активов (, требуется одобрение совета директоров или высшего руководства. Функция восстановления обрабатывается независимым RESUME_ROLE для обеспечения разделения обязанностей.
Функция заморозки: вызывается мультиподписным кошельком, обладающим FREEZER_ROLE, для ограничения переводов по определённым адресам. Условия срабатывания включают подозрительную активность ), такую как предупреждение AML или судебный приказ (, которые должны быть выполнены после проверки вне сети. Размораживание обрабатывается той же ролью, но требует дополнительной аудиторской проверки, публикации соответствующего объявления, чтобы предотвратить злоупотребления.
) 5. Механизм фильтрации адресов и черного списка
Руководство по внедрению
6. Возможности обновления смарт-контрактов
Руководство по реализации
7. Журнал событий в цепочке для анализа и отчетности
Руководство по внедрению
Кроме требований стандарта ERC-20 по передаче ###Transfer(, авторизации )Approval(, контракт должен определить и выпустить пользовательские события для всех управленческих действий и изменений состояния:
Третья часть Операционная безопасность и управление жизненным циклом
) 1. Архитектура управления безопасными ключами
Руководство по реализации
) 2. Полный процесс развертывания и мониторинг в реальном времени
Руководство по реализации
Перед официальным развертыванием необходимо разработать и строго соблюдать "контрольный список перед развертыванием":
После завершения развертывания необходимо принять соответствующие меры мониторинга, чтобы вовремя реализовать меры по смягчению для использования привилегированных ролей и новых угроз.