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

Основний текст

З ухваленням "Регламенту про стейблкоїни", Гонконгська фінансова адміністрація 26 травня 2025 року опублікувала "Керівництво з регулювання ліцензованих емітентів стейблкоїнів (проект)", що має на меті забезпечити стабільну, безпечну та відповідну роботу місцевої екосистеми стейблкоїнів. Це керівництво детально викладає регуляторні вимоги та стандарти роботи, які ліцензовані емітенти стейблкоїнів повинні постійно дотримуватись.

Нещодавно все більше організацій звертаються до команди безпеки з питаннями про дотримання нормативних вимог до впровадження смарт-контрактів. Щоб допомогти емітентам краще зрозуміти та впровадити відповідну систему смарт-контрактів, ми спеціально випустили «Посібник з впровадження смарт-контрактів для емітентів стабільних монет Гонконгу», щоб надати ясні технічні шляхи та практичні рекомендації, підтримуючи здоровий розвиток екосистеми стабільних монет Гонконгу.

Перша частина Інфраструктура та стратегії відповідності

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

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

Регуляторний наказ

Ліцензіати повинні оцінити надійність використовуваної ними основної технології розподіленого реєстру (DLT). Ця оцінка охоплює безпекову інфраструктуру, здатність протистояти загальним атакам (таким як атака 51%), забезпечення остаточності транзакцій та надійність алгоритму консенсусу.

Технічне тлумачення

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

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

Посібник з реалізації

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

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

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

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

Регуляторні вказівки

Регуляторні документи не вказують на конкретний стандарт токенів (таких як ERC-20). Проте, документи зобов'язують реалізувати ряд основних функцій управління, включаючи карбування (mint), знищення (burn), оновлення (upgrade), призупинення (pause), відновлення (resume), заморожування (freeze), чорний список (blacklist), білий список (whitelist) та інші операції.

Технічний аналіз

Фактично Гонконгська грошово-кредитна установа визначила стандарт "регуляторно посиленого" токена, функції якого значно перевищують стандарт ERC-20. Цей стандарт не лише вимагає наявності базових функцій обігу токенів, але й підкреслює безпеку операцій, контрольованість прав і можливість відстеження ризиків. Для того щоб максимально забезпечити безпеку, дотримуючись вимог комплаєнсу, найефективнішим і найнадійнішим шляхом розробки є використання стандартних бібліотек, що були широко перевірені та визнані спільнотою (наприклад, OpenZeppelin), з подальшим розширенням функціоналу.

Посібник із впровадження

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

• Розширення функцій: необхідно інтегрувати такі функціональні модулі для задоволення вимог регуляторів:

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

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

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

• Freezable: використовується для призупинення функції переказу токенів конкретного рахунку (наприклад, у випадках підозрілих транзакцій).

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

  • Чорний список: використовується для реалізації заборони на транзакції для адрес, пов'язаних з незаконною діяльністю (такою як відмивання грошей, шахрайство), забороняючи їм надсилати/отримувати токени. Управління чорним списком повинно бути взаємопов'язане з системою ПВК/ФТ, щоб в режимі реального часу контролювати підозрілі транзакції.

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

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

Регуляторні вказівки

Щодо безперервного моніторингу, консультаційний документ з питань боротьби з відмиванням грошей/боротьби з фінансуванням тероризму ( AML/CFT ) пропонує кілька заходів, серед яких "внесення до чорного списку адрес гаманців, які визнані такими, що підлягають санкціям або пов'язаними з незаконною діяльністю", або впровадження більш суворого "режиму білого списку для адрес гаманців власників стейблкоїнів або використання замкнутого циклу".

Технічний аналіз

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

• Чорний список: режим "за замовчуванням відкритий". Усі адреси за замовчуванням можуть вільно торгувати, лише ті адреси, які були чітко ідентифіковані та додані до чорного списку на блокчейні, будуть обмежені.

• Режим білого списку: це "за замовчуванням вимкнений" замкнутий режим. Будь-яка адреса не може володіти або отримувати токени, якщо не пройде чітке дью ділідженс та затвердження з боку емітента, і не буде додана до білого списку на ланцюзі.

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

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

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

Посібник із впровадження

• Режим чорного списку (рекомендоване за замовчуванням рішення):

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

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

  • Реалізація: у функції переказу смарт-контракту додати логічну перевірку, щоб переконатися, що адреси відправника (from) та отримувача (to) не записані в чорний список.

• Режим білих списків

  • Переваги: забезпечує найвищий рівень контролю AML/CFT, реалізуючи превентивні заходи, а не заходи після факту.

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

  • Спосіб реалізації: у функції переказу смарт-контракту додати логічну перевірку, що вимагає, щоб адреси відправника (from) та отримувача (to) обидві були в білому списку. Рекомендується розробити спеціальну веб-систему для користувачів для виконання операцій, щоб підвищити зручність операцій.

Друга частина Реалізація смарт-контрактів

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

1. Розробка детальної системи контролю доступу

Регуляторні вказівки

Дизайн високоризикових операцій повинен "запобігти тому, щоб будь-яка одна сторона могла в односторонньому порядку виконувати відповідні операції (наприклад, через протокол багатопідпису)". Обов'язки різних операцій повинні бути достатньо ізольовані.

Технічний аналіз

Це означає, що потужна система контролю доступу на основі ролей (RBAC) є обов'язковою. Будь-яка форма єдиного "власника" або "адміністратора" приватного ключа є несумісною.

Посібник з реалізації

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

• 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) смарт-контракту, наприклад, оновлення коду контракту для виправлення вразливостей або додавання функцій.

Таблиця 1: Матриця контролю доступу на основі ролей (RBAC Matrix)

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

| Операція | Потрібні ролі | Тип управління | |------|----------|----------| | Монета (Mint) | РОЛЬ_МІНТЕРА | Багаторазовий підпис | | Знищити (Burn) | РОЛЬ_ЗНИЩУВАЧА | Мультипідпис | | Призупинити (Pause) | PAUSER_ROLE | Мультипідпис | | Відновлення (Resume) | RESUME_ROLE | Мультипідпис | | Замороження (Freeze) | FREEZER_ROLE | Мультипідпис | | Скасувати замороження (Unfreeze) | FREEZER_ROLE | Мультипідпис | | Додати до білого списку (Whitelist) | WHITELISTER_ROLE | Багатопідпис | | Видалити з білого списку (Remove from Whitelist) | WHITELISTER_