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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Режим чорного списку ( стандартна рекомендована схема ):

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

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

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

• Режим білого списку

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

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

  • Спосіб реалізації: у функції переказу смартконтрактів додати логічну перевірку, що вимагає, щоб адреси відправника (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 в чорному списку або в замороженому стані.

Операційний процес:

• Офлайн-дослідження: клієнт завершує всі необхідні офлайн-ідентифікаційні процедури (KYC) та процедури клієнтської перевірки (CDD). Крім того, вимоги AML/CFT вимагають, щоб для встановлення ділових відносин або здійснення разових транзакцій, що перевищують певний поріг (, наприклад, 8 000 гонконгських доларів ), необхідно провести CDD.
• Отримання коштів: Клієнт переводить еквівалентні грошові кошти в банк, вказаний емітентом.
• Внутрішня перевірка: внутрішня система емітента підтверджує отримання коштів та відповідно оновлює бухгалтерські записи резервних активів.
• Виконання в ланцюгу: команда операцій створює та підписує багатопідписну транзакцію, викликає функцію випуску токенів смартконтракту, відправляючи нововипущений стейблкоїн на попередньо зареєстровану та перевірену адресу гаманця клієнта.

3. Викуп ( механізм знищення )

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

Підготовка до викупу: користувач спочатку повинен перевести токени, які він хоче викупити, на адресу, що контролюється емітентом.

Операційний процес:

• Офлайн запит: Користувач подає офлайн запит на викуп через платформу емітента. Перед обробкою запиту емітент повинен провести належну перевірку клієнтів (CDD).
• Системна перевірка: система перевіряє дійсність запиту на перевірку від емітента та перевіряє, чи завершив користувач відповідні операції з монетою в мережі.
• Фіатні платежі: Емітент переведе еквівалентну суму фіатної монети на банківський рахунок користувача, попередньо зареєстрований та верифікований.
• Знищення на ланцюгу: після підтвердження успішного переказу фіатних грошей багатопідписний гаманець з роллю 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%, забезпечити вивід звіту про покриття юніт-тестів.
• Незалежний аудит: завершити принаймні один, а краще два незалежних звіти про безпеку, видані надійними аудиторськими компаніями.
• Заморожування коду: після завершення аудиту, код заморожується до запуску, без внесення будь-яких змін у код.
• Регресійне тестування: перед офіційним розгортанням виконати модульне тестування та провести регресійне тестування.
• Комплаєнс-підпис: отримання офіційного підпису від внутрішньої команди комплаєнсу, підтверджуючи, що логіка контракту відповідає всім відповідним регуляторним вимогам.
• Деплоймент: підготувати детальний скрипт деплойменту та провести його на тестовій мережі, що повністю відповідає середовищу основної мережі.