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

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

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

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

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

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

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

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

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