Руководство по внедрению смарт-контрактов для эмитентов стейблкоинов в Гонконге

Первая часть Инфраструктура и стратегии соблюдения

1. Выбор базового распределенного реестра

Рекомендуется в первую очередь использовать зрелые и высокозащитные публичные блокчейны, такие как Эфириум, Arbitrum и т.д. Эти сети благодаря своей проверенной устойчивости, обширной сети узлов проверки и постоянному общественному контролю имеют природные преимущества. Их высокая стоимость атак может напрямую ответить на регуляторные опасения по поводу защиты от атаки 51% и обеспечения окончательности транзакций.

Если рассматривать возможность использования консорциума или других типов распределенных реестров, необходимо провести строгий и количественно измеримый сравнительный анализ, чтобы доказать, что их стандарты безопасности не ниже, а даже выше, чем у основных публичных цепочек.

Отчет по оценке рисков должен охватывать способность противостоять распространенным атакам, типы алгоритмов консенсуса, а также риски, связанные с кодовыми дефектами, уязвимостями, эксплойтами и другими угрозами, и подробно анализировать, как эти риски могут потенциально повлиять на выпуск, выкуп и повседневную деятельность стейблкоина. Этот документ является ключевым документом для подтверждения обоснованности выбора технологий перед регуляторами.

2. Стандарт токенов и расширение функций регулирования

Рекомендуется использовать ERC-20 в качестве базового стандарта, чтобы обеспечить однородность токенов и их взаимозаменяемость в более широкой экосистеме.

Необходимо интегрировать следующие функциональные модули для выполнения требований регуляторов:

• Приостановка: используется для реализации глобальной функции приостановки и восстановления всех токенов, что является основным инструментом для реагирования на серьезные инциденты безопасности.
• Mintable: предназначен для реализации лицензированными эмитентами процесса контролируемого выпуска новых токенов и обеспечения строгого соответствия объема выпуска токенов достаточным резервным активам в фиатной валюте.
• Сжигаемый: предоставляет функцию уничтожения токенов. В конкретной реализации эта функция будет строго контролироваться правами доступа, а не позволять любым пользователям уничтожать токены по своему усмотрению.
• Замораживаемый: используется для приостановки функции перевода токенов с определенных счетов (, если это связано с подозрительной сделкой ).
• Whitelist: используется для внедрения дополнительных мер безопасности, разрешающих участие в основных операциях ( только адресам, прошедшим проверку и утверждение, таким как получение новых токенов ).
• Черный список: используется для реализации запрета на транзакции адресов, причастных к незаконной деятельности (, такой как отмывание денег, мошенничество ), запрещая им отправлять/получать токены. Управление черным списком должно быть связано с системой AML/CFT, обеспечивая мониторинг подозрительных транзакций в реальном времени.
• AccessControl: это основа для реализации детализированной, основанной на ролях системы управления правами. Все функции управления должны проходить контроль прав через этот модуль, чтобы удовлетворить требования разделения обязанностей.

3. Основные модели соответствия: выбор черного и белого списков

Рекомендуется использовать режим черного списка в качестве рекомендуемого решения по умолчанию:

• Преимущества: обладает высокой практичностью, может бесшовно взаимодействовать с обширной децентрализованной финансовой (DeFi) экосистемой, предоставляя пользователям более низкий порог использования и более плавный опыт.
• Недостатки: соблюдение норм в значительной степени зависит от мощных,实时, аналитических возможностей мониторинга вне цепи, чтобы своевременно выявлять и блокировать незаконные адреса.
• Способ реализации: в функции перевода смарт-контракта добавить логическую проверку, чтобы гарантировать, что адреса отправителя (from) и получателя (to) не занесены в черный список.

Вторая часть Реализация смарт-контрактов

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 в черном списке или в замороженном состоянии.

Операционный процесс:

1. Оффлайн дью-дилидженс: клиент завершает все необходимые процессы по оффлайн идентификации клиента (KYC) и дью-дилидженсу клиента (CDD).
2. Получение средств: Клиент переводит эквивалентные фиатные средства на банковский счет, указанный эмитентом.
3. Внутренняя проверка: внутренние системы эмитента подтверждают получение средств и соответствующим образом обновляют бухгалтерские записи резервных активов.
4. Исполнение на цепочке: команда по эксплуатации создает и подписывает многофункциональную транзакцию, вызывая функцию выпуска токенов смарт-контрактов, отправляя новые выпущенные стейблкоины на кошелек клиента, предварительно зарегистрированный и проверенный.

3. Выкуп ( механизм уничтожения )

Выкуп подготовка: пользователю сначала необходимо перевести токены, которые он хочет выкупить, на указанный адрес, контролируемый эмитентом.

Операционный процесс:

1. Оффлайновый запрос: пользователь подает оффлайновый запрос на выкуп через платформу эмитента. Прежде чем обработать запрос, эмитент должен провести надлежащую проверку клиентов (CDD).
2. Системная проверка: проверка действительности запроса на верификацию системы эмитента и проверка, завершил ли пользователь соответствующую операцию по переводу токенов в сети.
3. Фиатные платежи: Эмитент переводит эквивалентную сумму фиатной валюты на заранее зарегистрированный и подтвержденный банковский счет пользователя.
4. Уничтожение на цепочке: после подтверждения успешного перевода фиатных денег мультиподписной кошелек с ролью 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) событие
• Заморозка/разморозка адреса ( AddressFrozen/AddressUnfrozen ) событие
• Изменение привилегий ( RoleGranted/RoleRevoked ) событие
• Обновление смарт-контрактов ( Upgraded ) событие

Третья часть Операционная безопасность и управление жизненным циклом

1. Архитектура управления безопасными ключами

• Генерация ключей: должна быть выполнена через "церемонию ключей" (key ceremony), в физически безопасной среде с полным изоляцией от внешних сетей.
• Хранение ключей: Все управленческие роли должны контролироваться многофакторными кошельками. Приватные ключи, используемые подписчиками этих многофакторных кошельков, должны храниться в HSM или других безопасных аппаратных кошельках. Для наиболее критических ролей соответствующие ключи должны храниться в изолированной системе, физически отделенной от любой онлайн-среды.
• Использование ключей: необходимо строго соблюдать политику многофакторной подписи. Для подписания транзакций, связанных с "важными частными ключами", может потребоваться личное присутствие соответствующих лиц.
• Резервное копирование и восстановление: резервное копирование ключевых шифров или мнемонических фраз должно храниться в нескольких безопасных и географически распределенных местах в Гонконге ( или в местах, одобренных регулятором ), и должно быть упаковано в антивандальную упаковку.

2. Полный процесс развертывания и мониторинга в реальном времени

Перед официальным развертыванием необходимо разработать и строго выполнить "контрольный список перед развертыванием":

• Полное тестирование: обеспечить покрытие юнит-тестами более 95%, покрытие основного кода 100%, обеспечить вывод отчета о покрытии юнит-тестов.
• Независимый аудит: получение независимого отчета о безопасности от как минимум одной, а лучше от двух авторитетных аудиторских компаний.
• Заморозка кода: после завершения аудита код замораживается до выхода в эфир, никаких изменений в коде больше не вносится.
• Регрессионное тестирование: перед официальным развертыванием выполните модульное тестирование и проведите регрессионное тестирование.
• Соответствие: получение официального одобрения внутренней команды по соблюдению требований, подтверждающее, что логика контракта соответствует всем соответствующим регуляторным требованиям.
• Деплоймент: подготовьте подробный скрипт развертывания и проведите полное развертывание на тестовой сети, полностью соответствующей среде основной сети.
• Авторизованное развертывание: окончательную операцию развертывания выполняет авторизованный кошелек.

После завершения развертывания необходимо принять соответствующие меры мониторинга для своевременного реагирования на использование привилегированных ролей и новые возникающие угрозы.

• Мониторинг активностей в блокчейне: отслеживание использования роли управления, своевременное обнаружение случаев несанкционированного доступа.
• Мониторинг угроз: необходимо своевременно выявлять новые угрозы и анализировать информацию об угрозах, чтобы можно было быстро принимать меры по их смягчению.

3. Обеспечение технической поддержки для непрерывности бизнеса и плана выхода

Разработка плана выхода из бизнеса: план охватывает различные ситуации, которые могут привести к упорядоченному прекращению, и включает меры мониторинга для фактического или потенциального возникновения этих ситуаций.

Процесс выхода из сети:

• Необходимо приостановить смарт-контракты, чтобы остановить все действия по переводу токенов, чтобы максимизировать доход от ликвидации резервных активов и минимизировать влияние на общую стабильность рынка.
• Полагаясь на функции выкупа и белого списка, помогать держателям стейблкоинов подавать заявки на выкуп.