Посібник із впровадження смартконтрактів для емітентів стейблкоїнів Гонконгу

Перша частина Інфраструктура та комплаєнс-стратегія

1. Вибір базового розподіленого реєстру

Рекомендується в першу чергу обирати зрілі та безпечні публічні блокчейни, такі як Ethereum, Arbitrum тощо. Ці мережі мають перевірену стійкість, велику мережу валідаційних вузлів і постійний громадський контроль, що надає їм природну перевагу. Якщо розглядається можливість використання консорціумних ланцюгів або інших типів розподілених реєстрів, необхідно провести ретельний порівняльний аналіз, щоб довести, що їхні стандарти безпеки не нижчі за стандарти провідних публічних ланцюгів.

Оцінювальний звіт має всебічно охоплювати здатність протистояти поширеним атакам, типи алгоритмів консенсусу, а також ризики, пов'язані з кодовими дефектами, вразливостями, експлуатацією вразливостей та іншими загрозами, і детально аналізувати, як ці ризики впливають на випуск, викуп та щоденну діяльність стейблкоїнів. Цей документ є ключовим документом для підтвердження обґрунтованості вибору технологій перед регуляторними органами.

2. Основні стандарти монет та розширення регуляторних функцій

Використання ERC-20 як базового стандарту для забезпечення однорідності токенів та їхньої взаємодії в більш широкій екосистемі. Необхідно інтегрувати такі функціональні модулі:

• Pausable: реалізує глобальну функцію призупинення та відновлення всіх активностей монет.
• Mintable: шляхом контрольованого процесу випуск нової монети
• Burnable: надає можливість знищення монет
• 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. Ланцюговий запит: Користувач подає запит на викуп поза ланцюгом через платформу емітента. Емітент повинен провести належну перевірку клієнта.
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, контракт повинен визначити та випустити власні події для всіх управлінських дій та змін стану, включаючи:

• Випуск/Знищення ( Випущено/Знищено ) подія
• Смартконтракти призупинено/відновлено (Paused/Resume) подія
• Додавання/видалення до чорного списку (BlacklistAdded/BlacklistRemoved) подія
• Додавання/видалення з білого списку (WhitelistAdded/WhitelistRemoved) подія
• Замороження адреси/Розмороження адреси ( AddressFrozen/AddressUnfrozen ) подія
• Зміна привілейованої ролі ( RoleGranted/RoleRevoked ) подія
• оновлення смартконтракту ( Upgraded ) подія

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

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

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

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

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

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

Заходи моніторингу після впровадження:

• Моніторинг активності в мережі: контроль використання ролей управління, своєчасне виявлення випадків несанкціонованого доступу.
• Моніторинг загрозової інформації: своєчасне виявлення нових загроз та аналіз загрозової інформації для своєчасного впровадження заходів пом'якшення.

3. Надати технічну підтримку для безперервності бізнесу та плану виходу

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

Процес виходу з ланцюга:

• Призупинення смартконтрактів для зупинки всіх трансакцій монет, забезпечуючи максимізацію прибутку від реалізації резервних активів та мінімізацію впливу на загальну стабільність ринку.
• Спираючись на функцію викупу та функцію білого списку, допомагайте власникам стейблкоїнів подавати заявки на викуп.