Руководство по экологической безопасности Pharos: комплексный контроль рисков при интеграции активов RWA

null

Данная статья предназначена для разработчиков экосистемы Pharos и предоставляет более практическое и глубокое руководство по интеграции RWA. Мы постарались с точки зрения бизнес-логики и архитектуры риск-менеджмента восстановить сложные вызовы и пути их решения при выводе реальных активов (RWA) в блокчейн.

Введение

Экосистема Pharos стремится стать инфраструктурой, соединяющей традиционные финансовые активы с миром Web3. В отличие от нативных криптоактивов, реальные активы (RWA) обладают двойственными свойствами: правами на оффчейн-объекты и транзакциями в цепочке. Эта двойственность определяет, что границы их безопасности не могут ограничиваться только смарт-контрактами, а должны распространяться на подтверждение прав, синхронизацию данных и соблюдение нормативных требований.

На основе глубокого анализа ведущих проектов RWA[1], мы рассмотрим архитектурные модели, основные риски и стратегии интеграции, чтобы помочь разработчикам Pharos построить надежные RWA-приложения.

1. Почему Pharos подходит для RWA?

Pharos — это Layer 1, предназначенный для масштабирования уровня интернета. Для разработчиков RWA не нужно углубляться в детали консенсуса — достаточно сосредоточиться на решении вопросов расчетов активов и сложных вычислений.

Параллельное выполнение и подтверждение в субсекунд(Block-STM) Традиционный EVM обрабатывает транзакции последовательно, что при больших выплатах или ребалансировках RWA может приводить к задержкам. Pharos внедряет параллельный движок Block-STM, обеспечивающий завершение транзакций в субсекундном диапазоне.

Это означает, что зачисление средств вне цепи и расчет в цепи могут происходить практически одновременно, устраняя риски колебаний курса и проскальзывания, связанные с T+1.

Архитектура Dual-VM (EVM + WASM) Pharos нативно поддерживает две среды выполнения: EVM и WASM.

Уровень EVM: обеспечивает совместимость. Уже существующие протоколы кредитования на Solidity, DEX-код можно напрямую развернуть, чтобы принимать RWA.

Уровень WASM: предназначен для вычислений. В RWA часто задействованы сложные налоговые и процентные расчеты, многоступенчатый риск-менеджмент и логика белых списков, что при выполнении в EVM вызывает высокие затраты газа и низкую эффективность. Такие вычислительно интенсивные задачи можно переносить в модули WASM для достижения высокой производительности и низких затрат.

2. Два типа логики работы RWA

Перед разработкой протокола RWA на платформе Pharos необходимо четко определить два основных сценария обращения с активами и их денежными потоками:

Модель on-chain — off-chain

Это наиболее распространенная модель, по сути — сбор средств в цепи и управление активами вне цепи. Инвестор вносит стабильные монеты (например, USDC) в цепи → проект собирает их и конвертирует в фиат (USD) → инвестирует в высоколиквидные оффчейн-активы (например, государственные облигации США) → полученная прибыль возвращается в цепь и распределяется держателям токенов.

Пример: $STBT от Matrixdock. Квалифицированные инвесторы создают $STBT (с привязкой 1:1 к краткосрочным облигациям США). Средства идут на покупку облигаций, а держатели токенов получают примерно 4.8% годовых.

Модель токенизации активов

Этот сценарий фокусируется на секьюритизации и дроблении конкретных активов. Проект блокирует оффчейн-активы (например, недвижимость) и оценивает их → выпускает соответствующие ERC-20 токены → инвесторы приобретают их за стабильные монеты → проект занимается обслуживанием и управлением активами → генерируемый денежный поток (например, арендная плата) периодически распределяется в цепи.

Пример: токенизация недвижимости RealT. Например, дом в Детройте стоимостью 65,9 тысяч долларов разбит на 1300 долевых токенов, и покупая их, инвесторы получают право на арендные платежи.

3. Карта рисков и стратегия интеграции с Pharos

Критические риски RWA зачастую кроются не в коде, а в связке цепи и оффчейн. В существующих проектах RWA есть существенные структурные недостатки в вопросах аутентификации, закрепления активов и прозрачности данных. При создании приложений на Pharos разработчикам следует уделять особое внимание следующим «серым носорогам».

Проникновенная проверка личности и соответствие требованиям

Проект заявляет о соответствии, но на деле это формальность. По статистике, менее половины проектов реализуют эффективную KYC-проверку, а некоторые известные проекты (например, RealT) сталкивались с возможностью обмана по видеоверификации с помощью одной фотографии. Некоторые проекты, несмотря на упоминание AML в белой книге, позволяют торговать просто подключив кошелек, что полностью исключает отслеживание источников средств.

Рекомендации для разработки на Pharos:

Не ограничивайтесь проверкой личности только на фронтенде. Необходимо интегрировать whitelist в смарт-контракты, чтобы только адреса, прошедшие DID (децентрализованную идентификацию) или оффчейн KYC, могли вызывать функции mint или transfer. Например, переписать функции transfer и transferFrom ERC-20 так, чтобы их могли вызывать только авторизованные в whitelist.

Для сделок с высокими активами рекомендуется внедрять 2FA, чтобы предотвратить кражу средств при утечке приватных ключей. Исследования показывают, что только немногие проекты реализовали такую защиту.

Зависимость от стабильных монет и механизм «механического» отключения

Стейблкоины — это кровь RWA. Более 90% проектов используют стабильные монеты для расчетов. Но разработчики часто игнорируют риск «отсоединения» стабильных монет, например, из-за событий, подобных SVB, или риски таких механизмов, как USDe$STBT . В случае отсоединения, есть ли у проекта специальные резервы для кризисных ситуаций?

Рекомендации для Pharos:

Опрогнозировать не только цену через оракулы, но и использовать их как триггеры риск-менеджмента. Например, при отклонении курса стабильной монеты (USDC/USDT) от привязки более чем на 5%, контракт должен автоматически приостанавливать эмиссию и выкуп, чтобы избежать арбитражных атак.

При проектировании пула средств стоит поддерживать несколько стабильных монет или корзину валют, чтобы снизить системный риск одного актива. Также избегать сложных алгоритмических стабильных монет, поскольку они наиболее подвержены «отсоединению».

Мосты данных и проверка достоверности

Самая большая «черная яма» RWA — это вопрос, действительно ли активы в цепи соответствуют реальным объектам. Многие проекты ограничиваются публикацией PDF-файлов или даже используют циклическое видео, выдаваемое за реальное наблюдение. Отчет о чистой стоимости активов OpenEden также иногда задерживается на месяц.

Рекомендации для Pharos:

Использовать оракулы, такие как Chainlink, для прямого подключения к API оффчейн-банков или аудиторов. Разработчики должны стремиться к тому, чтобы NAV (чистая стоимость активов) публиковался в цепи с минутной частотой, а не только по ежемесячным или квартальным отчетам.

Оценка активов может иметь погрешности. Следует внедрять мульти-оруклы для получения цен, чтобы максимально точно отражать реальную рыночную стоимость.

Изоляция юридических лиц и прозрачность

Невыполнение обязательств по оффчейн-активам — это важный риск RWA. Например, Goldfinch столкнулся с дефолтом по кредиту на сумму 5,9 млн долларов[2]. Ключ к изоляции — это SPV, но лишь немногие проекты публично заявляют о его использовании, и большинство не раскрывают конкретные названия зарегистрированных юридических лиц. В случае кризиса Goldfinch это привело к падению токена на 20%, что нанесло серьезный ущерб инвесторам.

Рекомендации для Pharos:

Обязательно указывать в метаданных проекта или документации юридические названия и места регистрации SPV, владеющих активами.

Обеспечить, чтобы каждый пул активов имел отдельное SPV. В смарт-контрактах Pharos разные пулы должны быть логически полностью изолированы, чтобы дефолт по одному активу не привел к ликвидности всей системы.

Ликвидность после фиктивного бума

Ликвидность — один из самых уязвимых и легко подделываемых элементов RWA. Многие проекты в начальной стадии сильно зависят от субсидий маркет-мейкеров. После окончания субсидий или их прекращения, глубина рынка резко падает, ордера исчезают. Кроме того, низкочастотная оценка оффчейн-активов (например, NAV раз в месяц или квартал) и высокая частота цепных транзакций (секундные блоки) создают временной дисбаланс. При крупной распродаже на цепи AMM-пулы не смогут быстро восстановить справедливую цену, что приводит к отклонениям и «черным дырам» ликвидности. На примере [4], из-за паники цена токена за несколько часов упала с 1 до 0.5 долларов.

Рекомендации для Pharos:

Не полагайтесь полностью на ликвидность на DEX или CEX. Встроить в смарт-контракт механизмы обратного выкупа/вывода. При значительном снижении цены (например, более чем на 3% от NAV) разрешить держателям обходить рынок и напрямую инициировать выкуп у протокола по стоимости базовых активов через очередь, управляемую смарт-контрактом.

Использовать резервные фонды, аналогичные банковским, — в процессе Mint оставлять определенный процент (например, 5-10%) стабильных монет в качестве буфера ликвидности. Эти средства не предназначены для покупки оффчейн-активов, а служат для автоматического выкупа при кризисных ситуациях, чтобы удержать цену.

Наследие уязвимостей EVM

Pharos полностью совместим с EVM, что дает разработчикам возможность пользоваться всеми преимуществами Solidity, но также и унаследовать его классические уязвимости. В RWA-контрактах из-за требований к соблюдению нормативов часто присутствует множество функций с высокими привилегиями (например, blacklist, forceTransfer, pause), что делает управление правами и обновление прокси более чувствительными и критическими.

Рекомендации для разработки:

Строго придерживаться стандартных библиотек: не изобретать велосипед. Использовать OpenZeppelin AccessControl или Ownable2Step для контроля прав. Потеря приватных ключей администратора из-за уязвимостей в логике может привести к юридическим спорам по владению оффчейн-активами.

Обеспечить безопасное обновление через прокси: при развертывании новых версий проверять конфликты в слотах хранения (Storage Slot), чтобы избежать ошибок в отображении данных.

Защита от повторных вызовов: при обработке дивидендов или выкупных операций, даже для whitelist-пользователей, необходимо добавлять ReentrancyGuard к внешним вызовам, чтобы предотвратить атаки с использованием обратных вызовов.

4. Итог

Обзор развития сектора RWA показывает, что слишком много проектов полагаются на UI для обеспечения соответствия или на маркет-мейкеров для поддержания ликвидности, что создает иллюзию процветания. В экосистеме Pharos мы пропагандируем более устойчивый подход к разработке.

Разработчикам важно ясно осознавать: безопасность RWA — это не только вопрос кода смарт-контрактов, но и подтверждение прав на активы и баланс ликвидности. Быстрая реакция в субсекундном диапазоне дает нам возможность управлять сложными финансовыми операциями, но требует более строгих стратегий интеграции: внедрения KYC/AML в базовые уровни, автоматического исполнения резервных фондов, максимальной прозрачности данных.

Конкуренция в области протоколов RWA в будущем уже не сводится к показателю TVL, а к достоверности активов и устойчивости системы. Обеспечение этой последней мили — обязательный урок для каждого строителя экосистемы Pharos.