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

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

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

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

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

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 ) подія
• Зміна привілейованих ролей ( РольНадано/РольВилучено ) подія
• Оновлення смартконтрактів ( Upgraded ) подія

Третя частина Операційна безпека та управління життєвим циклом

1. Архітектура управління безпечними ключами

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

• Генерація ключів: повинна бути завершена через "церемонію ключів"(key ceremony), яка документується детально, в фізично безпечному середовищі, повністю ізольованому від зовнішніх мереж.
• Зберігання ключів: всі управлінські ролі повинні контролюватися гаманцем з багатопідписом. Приватні ключі, що використовуються підписантами цих багатопідписних гаманців, повинні зберігатися в HSM або інших безпечних апаратних гаманцях. Для найбільш критичних ролей відповідні ключі повинні зберігатися в ізольованій системі, фізично відокремленій від будь-якого онлайн-середовища.
• Використання ключів: необхідно обов'язково впроваджувати політику мультипідпису. Для підписання транзакцій, що стосуються "важливих приватних ключів", може знадобитися особиста присутність відповідних осіб.
• Резервне копіювання та відновлення: резервне копіювання фрагментів ключа або мнемонічних фраз повинно зберігатися в кількох безпечних та географічно розподілених місцях на території Гонконгу ( або в місцях, затверджених регуляторами ), і бути упакованим у захист від несанкціонованого доступу.

2. Повний процес розгортання та моніторинг в реальному часі

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

Перед офіційним розгортанням необхідно скласти та суворо дотримуватись "переліку перевірок перед розгортанням":

• Повне тестування: забезпечте покриття юніт-тестів більше ніж 95%, покриття основного коду 100%, забезпечте вивід звіту про покриття юніт-тестів.
• Незалежний аудит: завершити принаймні один, краще два, незалежні звіти про безпеку від авторитетних аудиторських компаній.
• Замороження коду: після завершення аудиту код заморожується до виходу в ефір, жодних змін до коду більше не вноситься.
• Тестування на регресію: перед офіційним розгортанням виконуйте модульні тести та проводьте тестування на регресію.
• Узгодження відповідності: отримання офіційного затвердження від внутрішньої команди з питань відповідності, підтверджуючи, що логіка контракту відповідає всім відповідним регуляторним вимогам.
• Деплойментна репетиція: підготуйте детальний сценарій деплойменту та проведіть повну репетицію деплойменту на тестовій мережі, що повністю відповідає середовищу основної мережі.
• Авторизоване розгортання: остаточна операція розгортання виконується авторизованим гаманцем.

Після завершення розгортання слід вжити відповідних заходів моніторингу, щоб своєчасно впроваджувати заходи пом'якшення щодо використання привілейованих ролей та нових загроз:

• Моніторинг активностей в мережі: моніторинг управлінських ролей