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

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

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

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

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

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

Использование ERC-20 в качестве базового стандарта для обеспечения однородности токенов и их взаимной совместимости в более широких экосистемах. Необходимо интегрировать следующие функциональные модули:

• Приостановка: реализация глобальной функции приостановки и восстановления всех токенов.
• Mintable: через контролируемый процесс выпуск новых токенов
• Сжигаемый: предоставляет функцию уничтожения токенов
• Freezable: приостановить функцию перевода токенов для определенных аккаунтов
• Whitelist: только адреса, прошедшие должную проверку и одобрение, могут участвовать в основных операциях
• Черный список: введение запрета на транзакции для адресов, вовлеченных в незаконную деятельность
• AccessControl: реализация детализированной, основанной на ролях системы управления доступом

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

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

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

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

1. Разработка детализированной системы контроля доступа

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

• MINTER_ROLE: отвечает за операции по выпуску стейблкоинов
• BURNER_ROLE: отвечает за операции по уничтожению стейблкоинов
• PAUSER_ROLE: отвечает за приостановку операций со стейблкоином
• RESUME_ROLE: отвечает за восстановление стейблкоин операций
• FREEZER_ROLE: отвечает за заморозку и разморозку определенных кошельков или токенов
• WHITELISTER_ROLE: отвечает за управление белым списком
• BLACKLISTER_ROLE: отвечает за управление черным списком
• UPGRADER_ROLE: отвечает за обновление смарт-контрактов

2. выпуск ( токенов ) механизм

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

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

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

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

1. Оффлайн-запрос: Пользователь подает оффлайн-запрос на выкуп через платформу эмитента. Эмитент должен провести соответствующую CDD для клиента.
2. Системная проверка: система эмитента проверяет действительность запроса на проверку и проверяет, завершил ли пользователь операцию по переводу токенов в сети.
3. Фиатные платежи: Эмитент переводит эквивалентную сумму фиатной валюты на заранее зарегистрированный и проверенный банковский счет пользователя.
4. Уничтожение на блокчейне: после подтверждения успешного перевода фиатных денег мультиподписной кошелек с ролью BURNER_ROLE вызывает функцию уничтожения, уничтожая соответствующее количество токенов с указанного адреса.

4. Принять экстренные меры: приостановить и заморозить

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

5. Механизм фильтрации адресов и черного списка

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

6. Устойчивость смарт-контрактов к обновлениям

• Модель прокси: для смарт-контрактов типа EVM можно использовать зрелую модель прокси ERC-1967 для обеспечения возможности обновления.
• Контроль доступа: функция обновления может вызываться только многосторонним кошельком, обладающим UPGRADER_ROLE.
• Процесс управления изменениями: перед предложением любых обновлений необходимо пройти строгий процесс управления изменениями, включая всесторонний, независимый аудит безопасности новых смарт-контрактов.

7. Журнал событий в блокчейне для анализа и отчетности

Помимо событий Transfer и Approval, требуемых стандартом ERC-20, контракт должен определить и выпустить пользовательские события для всех управленческих действий и изменений состояния, включая:

• Выпуск/Сжигание(Minted/Burned)событие
• Приостановка/Возобновление(Paused/Resume)событие
• Добавление/удаление из черного списка ( BlacklistAdded/BlacklistRemoved ) событие
• Добавление/удаление из белого списка (WhitelistAdded/WhitelistRemoved) событие
• Заморозка адреса/разморозка адреса ( AddressFrozen/AddressUnfrozen ) событие
• Изменение привилегий ( RoleGranted/RoleRevoked ) событие
• Обновление смарт-контрактов ( Upgraded ) событие

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

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

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

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

Список проверки перед развертыванием:

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

Меры мониторинга после развертывания:

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

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

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

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

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