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

З моментом офіційного прийняття «Регламенту стейблкоїнів», Гонконгська адміністрація фінансових послуг 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: використовується для призупинення функції передачі токенів на певних рахунках (наприклад, у разі підозрілих транзакцій).

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

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

  • 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)

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

| Операція | Необхідні ролі | Тип управління | |------|----------|----------| | монета | MINTER_ROLE | багаторазовий підпис | | знищення | BURNER_ROLE | багатопідпис | | Призупинити | PAUSER_ROLE | Мультипідпис | | Відновити | RESUME_ROLE | Мультипідпис | | Замороження | FREEZER_ROLE | Мультипідпис | | Розмороження | FREEZER_ROLE | Мультипідпис | | Додати білий список | WHITELISTER_ROLE | Багаторазовий підпис | | Видалити білий список | WHITELISTER_ROLE | Мультипідпис | | Додати чорний список |