Зв'язок із реальними активами: від набору протоколів до безпечних практик

RWA (Real World Asset, активи реального світу) стає важливим напрямком глибокої інтеграції Web3 та традиційних фінансів. У порівнянні з традиційним DeFi, протоколи RWA не лише забезпечують обіг активів у ланцюгу, а й безпосередньо відображають реальні активи, такі як облігації, акції, нерухомість, обладнання, доходні права тощо. Їхні межі безпеки розширюються з «безпеки коду» до «правового підтвердження прав, нормативного управління та офлайн-виконання».

З точки зору аудиту, основне виклик для RWA полягає не лише у запобіганні крадіжкам коштів, а у забезпеченні відповідності логіки коду, бізнес-правил та реальних правових інтересів: одне змінення дозволів може означати замороження активів; одне примусове переказування — впливати на реальні права кредиторів у світі.

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

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

1. Вступ: з точки зору аудиту коду щодо RWA

=================

1.1 Комплексні безпекові виміри та виклики аудиту протоколів RWA

З точки зору аудиту коду, головні відмінності протоколів RWA від звичайного DeFi полягають у трьох аспектах:

1. Саме сутність активів: код — це лише «відображення».

2. Права та ролі — більш щільні та чутливі.

3. Бізнес-процеси — переплітаються між ланцюгом та офлайн.

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

У RWA поширена така схема:

Користувач викликає у ланцюгу redeem() або forcedTransfer() → контракт оновлює стан і фіксує подію → офлайн-система отримує повідомлення, виконує передачу реальних активів, перехід прав або ліквідацію → результат повертається або залишається офлайн

1.2 Основна місія аудиту RWA

У типовому проекті RWA ціль безпеки аудиту вже не лише «запобігти крадіжці коштів хакерами», а має тримати три основні принципи:

• Коректність та безпека: код не має містити помилок.

• Узгодженість: поведінка коду відповідає заявленим правилам проекту.

• Аудитованість: у разі проблем — на ланцюгу має бути достатньо доказів.

1.3 Цілі та межі цієї статті

У цій статті ми розглядаємо RWA з точки зору безпеки аудиту.

• Для розробників: це може слугувати «інструкцією з дизайну, що виведена з аудиту».

• Для аудиторів: це — «гайдлайн та чекліст для аудиту RWA».

На основі досвіду аудиту смарт-контрактів додаємо спеціальні знання щодо структури протоколів RWA та ключових аспектів аудиту.

Мета — допомогти розробникам створювати цілеспрямовані протоколи RWA, а аудиторам — мати системний підхід до перевірки реальних активів у світі, що відображаються у смарт-контрактах.

Ця стаття не намагається:

• Детально розглядати регуляторні норми або судові прецеденти — лише за потреби згадувати про «наявність таких обмежень»;

• Пояснювати з нуля Solidity або базові стандарти ERC — вважаємо, що читач має базовий досвід аудиту DeFi/NFT;

• Оцінювати «якість проекту» з точки зору Tokenomics — увага зосереджена на безпеці та відповідності моделі RWA.

2. Огляд модулів протоколу RWA

===============

2.1 Від бізнесу: визначаємо тип RWA

З точки зору безпеки та бізнес-логіки, можна умовно класифікувати проєкти за чотирма групами:

1. Цінні папери / акції / облігації RWA

2. Нерухомість / нерухомі активи RWA

3. Фізичні предмети / обладнання / товарні партії RWA

4. Доходні права / структуровані / роздільні власності RWA

2.2 Від стандартів до реалізації: знайомство з протоколами RWA

2.2.1 Стандарти для регульованих цінних паперів

Ці стандарти вирішують питання: як у ланцюгу випускати та обертати «регульовані цінні папери / продукти сек’юритизації», дотримуючись KYC, обмежень переказу, примусових операцій тощо.

2.2.2 Стандарти для нерухомості / нерухомих активів

Головна складність — не у «як випустити токен», а у «як структуровано та безпечно закласти інформацію про нерухомість у контракт».

2.2.3 Стандарти для фізичних обладнань / обміну предметами

Зазвичай потрібно вирішити, як прив’язати токен/NFT до реального предмета; і як реалізувати обміни, використання, анулювання.

2.2.4 Стандарти для структурованих активів / універсальні інтерфейси RWA

Більше орієнтовані на «складні структури активів» та «уніфіковані інтерфейси».

2.3 Типова архітектура протоколів RWA

Незалежно від типу проекту, будь-який цілісний протокол RWA у коді зазвичай містить такі модулі:

1. Ядро токену

2. Модуль управління правами та ролями

3. Модуль відповідності / білого списку

4. Модуль викупу / ліквідації

5. Метадані / інформація про активи

6. Модуль оновлень та управління

2.4 Три кроки швидкої локалізації RWA

Крок 1: ознайомитись із бізнес-матеріалами, визначити тип активу та стандарт.

Крок 2: у коді «шукати ключові слова».

Крок 3: створити схему архітектури.

3. Глибока розбірка протоколів: моделі відповідності основних стандартів RWA

========================

Цей розділ глибше аналізує кодові реалізації основних стандартів RWA.

I. Цінні папери: глибокий аналіз ERC-1400 (UniversalToken)

1. Загальна архітектура контракту

ERC-1400 (UniversalToken), розроблений ConsenSys, — платформа для випуску та управління цінними паперами на основі стандарту ERC1400, з управлінням розділами (partition), механізмами володіння, сертифікатами, випуском фондів і обміном токенів. Основне застосування — регульований випуск, торгівля та управління цінними паперами з детальним контролем прав.

Загалом архітектура складається з шести ключових модулів:

• Ядро: реалізація логіки цінних паперів, включаючи емісію, викуп, перекази та розділи (Partition).

• Модуль ролей (Roles): реалізує RBAC (ролевий контроль доступу).

• Модуль валідаторів: «мозок відповідності», що виконує перевірки — білого списку, чорного списку, підписів сертифікатів, паузи транзакцій тощо.

• Розширення: готові рішення для конкретних бізнес-сценаріїв.

• Модуль користувацьких розширень: через хуки відправника та отримувача — забезпечує програмованість токену.

• Інструменти: набір корисних контрактів, таких як DomainAware, ERC1820, масові операції.

2. Глибокий аналіз основного контракту ERC1400 (UniversalToken)

2.1 Детальний розбір структур даних

2.1.1 Основна інформація про цінний папір

Крім стандартних метаданих ERC20, контракт вводить параметри з цінним значенням:

• granularity — мінімальний розмір транзакції (подільність)

• isControllable — дозволяє регулятору або емітенту примусово переказувати або викупляти токени

• isIssuable — контроль можливості додаткового емісії

• migrated — при оновленні контракту, можливість перенаправлення користувачів до нової версії через механізм міграції

2.1.2 Розділи (Partition) — ключова інновація ERC1400

Механізм розділів дозволяє ділити один контракт на кілька незалежних частин, кожна з яких має власний баланс і обсяг.

2.1.3 Права оператора (Operator)

ERC1400 має трирівневу систему прав оператора:

• Глобальні контролери (Global Controllers): зазвичай — регулятори або емітенти, що мають повноваження по всьому контракту.

• Авторизовані оператори (Authorized Operators): мають дозвіл на управління активами від імені користувачів, схоже на approve ERC20, але з ширшими можливостями.

• Оператори розділів (Partition Operators): специфічна для ERC1400 — дозволяє управляти окремими розділами.

2.1.4 Документація та офіційні записи

• ERC1400 інтегрує стандарт ERC1643 для управління документами, що дозволяє зберігати офіційні документи у вигляді URI, хешів та таймстампів.

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

• Можна зберігати важливу юридичну інформацію.

2.2 Основні функціональні модулі

2.2.1 Емісія (Issuance)

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

Можливі режими: простий випуск у дефолтний розділ або розподіл по конкретних розділах.

Це дозволяє відобразити складні фінансові сценарії:

• IPO / STO

• Приватне розміщення

• Опціони для співробітників (ESOP)

• Дивіденди у вигляді акцій

2.2.2 Викуп (Redemption)

Викуп — важливий етап, що зменшує пропозицію активів. ERC1400 підтримує чотири шляхи викупу:

• Стандартний викуп — власник може знищити свої токени.

• Викуп через уповноваженого оператора.

• Викуп у конкретному розділі.

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

Приклади застосування:

• Викуп акцій (buyback)

• Ліквідація компанії

• Договірна викупна опція (Callable bonds)

• Примусове вилучення порушників правил

2.2.3 Механізм переказу та відповідність

Переказ — основна операція торгівлі цінними паперами. ERC1400 реалізує багаторівневий механізм, що забезпечує сумісність з ERC20 і відповідає регуляторним вимогам:

• Стандартний переказ у розділах.

• Можливість явно вказати розділ.

• Перевірки відповідності — на кожному кроці.

Застосування у реальному світі:

• Вторинний ринок

• DVP (Delivery Versus Payment)

• Клієнтські рахунки

• Міжнародна торгівля

2.3 Модуль хуків — плагінна система відповідності

Хуки дозволяють підключати додаткові перевірки у процесі переказу:

• Хук відправника — викликається перед виходом активу з адреси.

• Валідатор — глобальний, через ERC1820.

• Хук отримувача — після отримання.

Застосування:

• Обмеження обсягів

• Автоматичне утримання податків

• Аудит

• Моніторинг внутрішніх операцій

2.4 Інструменти для розширення та управління

• ERC1820 — динамічне відкриття сервісів.

• EIP-712 — структуровані підписи.

• Масові операції — для ефективного управління великими обсягами.

• FundIssuer — для управління фондами.

• Swaps — для безпечних обмінів та DVP.

II. Цінні папери ERC-3643 (T-REX): глибокий аналіз

1. Загальна архітектура

ERC-3643 (T-REX) — це стандарт для цінних паперів із підтримкою проксі-інтерфейсів та модульної системи.

Основні компоненти:

• Токен (Token)
• Registry — реєстр ідентичностей
• Compliance — модуль відповідності

Використовує проксі-інтерфейс для оновлення та розширення.

2. Глибокий аналіз ERC-3643

2.1 Структури даних

• Посилання на модулі відповідності, реєстри та модулі сертифікації.

2.2 Основні функції

• Перекази з додатковими перевірками.

• Примусові операції.

• Верифікація через сертифікати.

2.3 Модулі реєстрів

• TrustedIssuersRegistry — довірені видавці.

• ClaimTopicsRegistry — типи сертифікатів.

2.4 Застарілі модулі

• Legacy Compliance — старі системи відповідності.

2.5 Управління ролями

• Owner — адміністратор.

• Agent — оператори.

• Контроль доступу через Roles.

2.6 Інструменти

• Factory — створення контрактів.

• Upgradability — оновлення через проксі.

4. Спеціалізовані сценарії та стандарти

1. Нерухомість: ERC-6065 (Real Estate Token)

Застосування: інвестиційні фонди, іпотека, міждержавні угоди.

2. IoT та фізичні активи: ERC-4519

Застосування: платформи оренди, логістика, автомобільний транспорт.

3. Універсальні відповідності: ERC-7943 (uRWA)

Застосування: DeFi-лічильники, регульовані випуски, AML/KYC.

5. Практики безпеки коду

=================

3.1 Ролі та права: планування «хто що може»

Важливо не лише мати адміністратора, а й визначити, що саме він може робити. Типові ролі:

• Власник, мульти-підпис, адміністратор оновлень, регулятор, KYC-менеджер, модератор білого списку, менеджер активів, ріелтор, аудит, фіскальний менеджер тощо.

Розробникам:

• Створити матрицю ролей і прав.

• Впровадити чіткий розподіл обов’язків.

Аудиторам:

• Виявити «гарячі» функції.

• Перевірити відповідність ролей.

3.2 Статусні машини та інваріанти

• Визначити стани активів, запровадити правила переходів.

• Забезпечити, щоб ключові інваріанти завжди зберігалися.

• Враховувати сценарії переходів і можливі зловживання.

Для розробників:

• Вивести стан у enum або змінні.

• Документувати передумови та обмеження.

Для аудиторів:

• Аналізувати логіку станів.

• Перевіряти, чи не можна обійти правила.

3.3 Відображення активів і відповідність

• Чітко розмежовувати «записи у коді» та реальні активи.

• Враховувати, що ланцюг — це відображення, а не сам актив.

• Забезпечити цілісність та узгодженість.

При аудиті:

• Перевірити, що кожен актив має відповідний запис.

• Виявити «розбіжності» або «невідповідності».

3.4 Оновлення та проксі-моделі

• Вибрати правильний рівень оновлення.

• Забезпечити контроль доступу до оновлень.

• Враховувати можливі ризики зломів або зловживань.

При аудиті:

• Визначити, хто має право оновлювати.

• Перевірити прозорість процесу.

• Аналізувати можливі «задні двері».

3.5 Логування та події

• Всі важливі дії мають фіксуватися у подіях.

• Це — доказова база для майбутніх аудитів і регуляторів.

• Включати ключові операції: емісія, викуп, переказ, замороження, розмороження, примус.

• Враховувати зміни у білому списку, KYC, ролях.

При аудиті:

• Перевірити, що всі критичні дії логуються.

• Аналізувати, чи не є можливим обходити логування.

6. Висновки

=================

Загалом, безпечна реалізація RWA вимагає системного підходу:

• Визначити чіткі ролі та права.

• Впровадити статусні машини та інваріанти.

• Забезпечити відповідність активів та їхнього відображення.

• Враховувати оновлюваність та контроль доступу.

• Фіксувати всі важливі події.

Застосування сучасних інструментів, таких як AI-підтримка, автоматичні сканери та моніторинг у реальному часі, дозволить створити надійний захист для реальних активів у децентралізованому світі.