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

Перша частина Інфраструктура та регуляторні стратегії

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

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

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

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

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

Рекомендується використовувати ERC-20 як базовий стандарт, щоб забезпечити однорідність монет та їхню взаємодію в більш широкій екосистемі.

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

• Pausable: використовується для реалізації глобальної функції призупинення та відновлення всіх активностей монет, що є основним інструментом для реагування на серйозні безпекові інциденти.
• Mintable: використовується для реалізації ліцензованими емітентами необхідності створення нових токенів через контрольовані процеси та забезпечення того, щоб обсяг випуску токенів строго відповідав достатнім резервним активам у фіатній валюті.
• Підлягає знищенню: надає функцію знищення монет. У конкретній реалізації ця функція буде під суворим контролем прав, а не дозволятиме будь-яким користувачам самостійно знищувати.
• Freezable: використовується для призупинення функції переказу токенів конкретного рахунку (, якщо це стосується підозрілих транзакцій ).
• 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. Надати технічну підтримку для забезпечення безперервності бізнесу та плану виходу

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

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

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