Перейти к основному содержимому

Хранение цифровых активов для низколатентного, безопасного исполнения сделок в масштабе

· 10 мин. чтения
Dora Noda
Software Engineer

Как разработать стек хранения и исполнения, который работает со скоростью рынка без ущерба для рисков, аудита или соответствия требованиям.


Краткое содержание

Хранение и торговля больше не могут существовать в отдельных мирах. На сегодняшних рынках цифровых активов безопасное хранение клиентских активов — это лишь половина дела. Если вы не можете исполнять сделки за миллисекунды при изменении цен, вы упускаете прибыль и подвергаете клиентов избегаемым рискам, таким как максимальная извлекаемая ценность (MEV), сбои контрагентов и операционные узкие места. Современный стек хранения и исполнения должен сочетать передовую безопасность с высокопроизводительной инженерией. Это означает интеграцию таких технологий, как многосторонние вычисления (MPC) и аппаратные модули безопасности (HSM) для подписания, использование механизмов политик и частной маршрутизации транзакций для снижения рисков опережающей торговли, а также использование активно-активной инфраструктуры с внебиржевым расчетом для снижения рисков площадки и повышения эффективности капитала. Критически важно, что соответствие требованиям не может быть дополнительной функцией; такие функции, как потоки данных Travel Rule, неизменяемые журналы аудита и элементы управления, сопоставленные с фреймворками, такими как SOC 2, должны быть встроены непосредственно в конвейер транзакций.


Почему «скорость хранения» важна сейчас

Исторически, хранители цифровых активов оптимизировали свою работу для одной основной цели: не потерять ключи. Хотя это остается фундаментальным, требования изменились. Сегодня лучшее исполнение и целостность рынка в равной степени не подлежат обсуждению. Когда ваши сделки проходят через публичные мемпулы, искушенные участники могут их видеть, переупорядочивать или "сэндвичить", чтобы извлечь прибыль за ваш счет. Это MEV в действии, и оно напрямую влияет на качество исполнения. Сохранение конфиденциального потока ордеров вне публичного доступа с помощью частных ретрансляторов транзакций — мощный способ снизить этот риск.

В то же время, риск площадки является постоянной проблемой. Концентрация больших балансов на одной бирже создает значительный риск контрагента. Внебиржевые расчетные сети предоставляют решение, позволяя фирмам торговать с кредитом, предоставленным биржей, в то время как их активы остаются на сегрегированном, защищенном от банкротства хранении. Эта модель значительно повышает как безопасность, так и эффективность капитала.

Регуляторы также устраняют пробелы. Применение Правила путешествий (Travel Rule) Группы разработки финансовых мер борьбы с отмыванием денег (FATF) и рекомендации таких органов, как IOSCO и Совет по финансовой стабильности, подталкивают рынки цифровых активов к концепции "одинаковый риск, одинаковые правила". Это означает, что платформы хранения должны быть изначально построены с соблюдением требований к потокам данных и аудируемыми элементами управления.


Цели проектирования (как выглядит «хорошо»)

Высокопроизводительный стек хранения должен быть построен на нескольких ключевых принципах проектирования:

  • Задержка, которую можно планировать: Каждая миллисекунда от намерения клиента до сетевого вещания должна измеряться, управляться и обеспечиваться с помощью строгих Целей Уровня Обслуживания (SLO).
  • Исполнение, устойчивое к MEV: Конфиденциальные ордера по умолчанию должны маршрутизироваться через частные каналы. Доступ к публичному мемпулу должен быть преднамеренным выбором, а не неизбежным по умолчанию.
  • Ключевой материал с реальными гарантиями: Приватные ключи никогда не должны покидать свои защищенные границы, будь то распределение по шардам MPC, хранение в HSM или изоляция в доверенных средах исполнения (TEE). Ротация ключей, обеспечение кворума и надежные процедуры восстановления являются обязательными условиями.
  • Активно-активная надежность: Система должна быть устойчивой к сбоям. Это требует многорегионального и многопровайдерного резервирования как для RPC-узлов, так и для подписантов, дополненного автоматическими выключателями и аварийными выключателями для инцидентов на площадках и в сети.
  • Соответствие требованиям по умолчанию: Соответствие требованиям не может быть второстепенной задачей. Архитектура должна иметь встроенные механизмы для данных Travel Rule, проверок AML/KYT и неизменяемых аудиторских следов, при этом все элементы управления должны быть напрямую сопоставлены с признанными фреймворками, такими как критерии доверительных услуг SOC 2.

Эталонная архитектура

Эта диаграмма иллюстрирует высокоуровневую архитектуру платформы хранения и исполнения, которая соответствует этим целям.

  • Движок политик и рисков является центральным привратником для каждой инструкции. Он оценивает все — полезные данные Travel Rule, лимиты скорости, оценки рисков адресов и требования к кворуму подписантов — прежде чем будет получен доступ к любому ключевому материалу.
  • Оркестратор подписантов интеллектуально маршрутизирует запросы на подписание к наиболее подходящей плоскости управления для актива и политики. Это может быть:
    • MPC (многосторонние вычисления) с использованием схем пороговых подписей (например, t-из-n ECDSA/EdDSA) для распределения доверия между несколькими сторонами или устройствами.
    • HSM (аппаратные модули безопасности) для аппаратного хранения ключей с детерминированными политиками резервного копирования и ротации.
    • Доверенные среды исполнения (например, AWS Nitro Enclaves) для изоляции кода подписания и привязки ключей непосредственно к аттестованному, измеренному программному обеспечению.
  • Маршрутизатор исполнения отправляет транзакции по оптимальному пути. Он предпочитает частную отправку транзакций для крупных или чувствительных к информации ордеров, чтобы избежать опережающей торговли. При необходимости он переключается на публичную отправку, используя многопровайдерное RPC-отказоустойчивость для поддержания высокой доступности даже во время сбоев сети.
  • Уровень наблюдаемости предоставляет представление о состоянии системы в реальном времени. Он отслеживает мемпул и новые блоки через подписки, сверяет исполненные сделки с внутренними записями и фиксирует неизменяемые аудиторские записи для каждого решения, подписи и вещания.

Компоненты безопасности (и почему они важны)

  • Пороговые подписи (MPC): Эта технология распределяет контроль над приватным ключом таким образом, что ни одна машина — или человек — не может в одностороннем порядке перемещать средства. Современные протоколы MPC могут реализовывать быстрое, криптографически безопасное подписание, подходящее для производственных бюджетов задержки.
  • HSM и соответствие FIPS: HSM обеспечивают границы ключей с помощью защищенного от взлома оборудования и документированных политик безопасности. Соответствие стандартам, таким как FIPS 140-3 и NIST SP 800-57, предоставляет аудируемые, широко понятные гарантии безопасности.
  • Аттестованные TEE: Доверенные среды исполнения привязывают ключи к конкретному, измеренному коду, работающему в изолированных анклавах. Используя службу управления ключами (KMS), вы можете создавать политики, которые выдают ключевой материал только этим аттестованным рабочим нагрузкам, гарантируя, что подписывать может только утвержденный код.
  • Частные ретрансляторы для защиты от MEV: Эти службы позволяют отправлять конфиденциальные транзакции непосредственно строителям блоков или валидаторам, минуя публичный мемпул. Это значительно снижает риск опережающей торговли и других форм MEV.
  • Внебиржевой расчет: Эта модель позволяет вам хранить залог на сегрегированном хранении при торговле на централизованных площадках. Она ограничивает риск контрагента, ускоряет чистый расчет и высвобождает капитал.
  • Элементы управления, сопоставленные с SOC 2/ISO: Документирование и тестирование ваших операционных элементов управления в соответствии с признанными фреймворками позволяет клиентам, аудиторам и партнерам доверять — и независимо проверять — вашу позицию в области безопасности и соответствия требованиям.

План действий по снижению задержки: куда уходят миллисекунды

Для достижения низколатентного исполнения необходимо оптимизировать каждый шаг жизненного цикла транзакции:

  • Намерение → Решение по политике: Держите логику оценки политики в горячей памяти. Кэшируйте данные Know-Your-Transaction (KYT) и списки разрешенных адресов с короткими, ограниченными значениями Time-to-Live (TTL) и предварительно вычисляйте кворумы подписантов, где это возможно.
  • Подписание: Используйте постоянные сессии MPC и дескрипторы ключей HSM, чтобы избежать накладных расходов на холодные запуски. Для TEE закрепляйте анклавы, прогревайте их пути аттестации и повторно используйте сессионные ключи там, где это безопасно.
  • Вещание: Предпочитайте постоянные соединения WebSocket с RPC-узлами вместо HTTP. Размещайте свои службы исполнения совместно с регионами ваших основных RPC-провайдеров. При скачках задержки повторяйте операции идемпотентно и хеджируйте вещание через нескольких провайдеров.
  • Подтверждение: Вместо опроса статуса транзакции подписывайтесь на квитанции и события непосредственно из сети. Передавайте эти изменения состояния в конвейер сверки для немедленной обратной связи с пользователем и внутреннего учета.

Установите строгие SLO для каждого этапа (например, проверка политики <20 мс, подписание <50–100 мс, вещание <50 мс при нормальной нагрузке) и обеспечивайте их соблюдение с помощью бюджетов ошибок и автоматического переключения при ухудшении задержек p95 или p99.


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

Современный стек хранения должен рассматривать соответствие требованиям как неотъемлемую часть системы, а не как дополнение.

  • Оркестрация Travel Rule: Генерируйте и проверяйте данные отправителя и получателя в соответствии с каждой инструкцией по переводу. Автоматически блокируйте или перенаправляйте транзакции, связанные с неизвестными поставщиками услуг виртуальных активов (VASP), и регистрируйте криптографические квитанции каждого обмена данными для целей аудита.
  • Риск адресов и списки разрешенных адресов: Интегрируйте ончейн-аналитику и списки проверки на санкции непосредственно в движок политик. Применяйте политику отказа по умолчанию, при которой переводы разрешены только на явно разрешенные адреса или в соответствии с конкретными исключениями из политики.
  • Неизменяемый аудит: Хэшируйте каждый запрос, одобрение, подпись и вещание в журнал только для добавления. Это создает защищенный от подделок аудиторский след, который может быть передан в SIEM для обнаружения угроз в реальном времени и предоставлен аудиторам для тестирования контроля.
  • Фреймворк контроля: Сопоставьте каждый технический и операционный контроль с критериями доверительных услуг SOC 2 (безопасность, доступность, целостность обработки, конфиденциальность и приватность) и реализуйте программу непрерывного тестирования и валидации.

Внебиржевой расчет: более безопасное подключение к площадкам

Стек хранения, созданный для институционального масштаба, должен активно минимизировать подверженность биржам. Внебиржевые расчетные сети являются ключевым фактором, обеспечивающим это. Они позволяют фирме хранить активы на собственном сегрегированном хранении, в то время как биржа зеркалирует этот залог для обеспечения мгновенной торговли. Окончательный расчет происходит с фиксированной периодичностью с гарантиями, подобными Delivery versus Payment (DvP).

Эта конструкция значительно сокращает след "горячего кошелька" и связанный с ним риск контрагента, сохраняя при этом скорость, необходимую для активной торговли. Это также повышает эффективность капитала, поскольку вам больше не нужно перефинансировать неактивные балансы на нескольких площадках, и упрощает управление операционными рисками, сохраняя залог сегрегированным и полностью аудируемым.


Контрольный список (скопируйте/вставьте в свой план действий)

  • Хранение ключей
    • MPC с использованием порога t-из-n в независимых доменах доверия (например, мультиоблако, локально, HSM).
    • Используйте модули, проверенные FIPS, где это возможно; поддерживайте планы ежеквартальной ротации ключей и повторной генерации ключей в случае инцидентов.
  • Политики и одобрения
    • Внедрите динамический движок политик с ограничениями скорости, поведенческими эвристиками и ограничениями по рабочим часам.
    • Требуйте одобрения по принципу "четырех глаз" для операций с высоким риском.
    • Применяйте списки разрешенных адресов и проверки Travel Rule до любой операции подписания.
  • Укрепление исполнения
    • Используйте частные ретрансляторы транзакций по умолчанию для крупных или конфиденциальных ордеров.
    • Используйте двух RPC-провайдеров с хеджированием на основе состояния и надежной защитой от повторного воспроизведения.
  • Мониторинг и реагирование
    • Внедрите обнаружение аномалий в реальном времени по показателям намерений, выбросам цен на газ и неудачному включению транзакций.
    • Поддерживайте аварийный выключатель в один клик для замораживания всех подписантов на основе актива или площадки.
  • Соответствие требованиям и аудит
    • Поддерживайте неизменяемый журнал событий для всех системных действий.
    • Выполняйте непрерывное тестирование контроля, соответствующее SOC 2.
    • Обеспечьте надежное хранение всех доказательств Travel Rule.

Примечания по реализации

  • Люди и процессы в первую очередь: Технология не может исправить неоднозначные политики авторизации или неясное владение дежурством. Четко определите, кто уполномочен изменять политику, продвигать код подписанта, ротировать ключи и утверждать исключения.
  • Минимизируйте сложность там, где это возможно: Каждый новый блокчейн, мост или площадка, которую вы интегрируете, добавляет нелинейный операционный риск. Добавляйте их обдуманно, с четким тестовым покрытием, мониторингом и планами отката.
  • Тестируйте как противник: Регулярно проводите учения по хаос-инженерии. Моделируйте потерю подписантов, сбои аттестации анклавов, зависшие мемпулы, дросселирование API площадок и некорректные данные Travel Rule, чтобы убедиться в устойчивости вашей системы.
  • Докажите это: Отслеживайте ключевые показатели эффективности, которые действительно важны для ваших клиентов:
    • Время до вещания и время до первого подтверждения (p95/p99).
    • Процент транзакций, отправленных через MEV-безопасные маршруты, по сравнению с публичным мемпулом.
    • Использование площадки и повышение эффективности залога за счет использования внебиржевого расчета.
    • Метрики эффективности контроля, такие как процент переводов с полными данными Travel Rule и скорость закрытия аудиторских замечаний.

Итог

Платформа хранения, достойная институционального потока, быстро исполняет, доказывает свои контроли и ограничивает риски контрагента и информации — все одновременно. Это требует глубоко интегрированного стека, построенного на маршрутизации с учетом MEV, аппаратном или MPC-основанном подписании, активно-активной инфраструктуре и внебиржевом расчете, который обеспечивает безопасность активов при доступе к глобальной ликвидности. Встраивая эти компоненты в единый, измеряемый конвейер, вы предоставляете то, что институциональные клиенты ценят больше всего: уверенность на скорости.