Ворота к услугам цифровых активов: инфраструктура данных на блокчейне - Тайгери Ресерч

1. Стена, с которой сталкиваются цифровые активы: недружелюбные данные на блокчейне {#rps-1}

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

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

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

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

2. Реальность и ограничения создания инфраструктуры данных на блокчейне {#rps-2}

Однако на ранних этапах, когда масштаб и область применения рынка цифровых активов были ограничены, проблемы с доступом к данным не были столь заметны. Большинство услуг цифровых активов были близки к небольшим экспериментам с ограниченным числом участников. Например, проект депозитных токенов глобального инвестиционного банка JP Morgan был ограниченным платежным средством, разработанным только для небольшого числа институциональных клиентов. В среде, где участники и цели использования были четко определены, виды транзакций, которые необходимо было обрабатывать, были простыми, а актуальность и точность данных не имели большого значения.

В то время требования к данным на блокчейне были относительно слабыми. Даже если все состояния не совпадали строго в реальном времени, если в конечном итоге согласованность была достигнута через некоторое время, это не создавало больших проблем в операционном плане. То есть, обработка на основе конечной согласованности (Eventual Consistency) была вполне приемлемой. В такой среде можно было без особых проблем управлять ограниченным количеством собственных узлов или интегрировать внешние RPC-эндпоинты или простые API данных на блокчейне.

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

3. Требования к инфраструктуре данных на блокчейне для институциональных финансов {#rps-3}

Чтобы удовлетворить повышенные требования, необходимо изменить критерии оценки инфраструктуры. Тайгери Ресерч предлагает три ключевых критерия для инфраструктуры данных на блокчейне, которым могут доверять и которые могут использовать институциональные финансы: полнота (Completeness), согласованность (Consistency) и стабильность (Stability). Это обязательные условия, которые должны быть выполнены, чтобы данные на блокчейне функционировали как основной реестр для реальных услуг.

3.1. Полнота (Completeness): включены ли все записи транзакций {#rps-4}

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

Пропуски данных могут возникнуть на этапе сбора. Блокчейн группирует транзакции, происходящие в течение определенного времени, в блоки и записывает их в реестр. Инфраструктура данных обрабатывает эти блоки по порядку. Однако если из-за сбоя узла или проблем с сетью сбор блоков в определенном диапазоне прерывается, записи транзакций, включенные в этот диапазон, также могут быть пропущены. Однако пропуски на этапе сбора можно относительно легко обнаружить и устранить. Данные можно заполнить с помощью обратного заполнения (Backfill) пропущенных блоков.

Другая проблема возникает на этапе обработки после того, как все оригинальные блоки данных были собраны. Индексатор (Indexer) извлекает необходимые записи транзакций из оригинальных данных и преобразует их в форму, доступную для запроса. Если данные не были правильно разобраны в этот момент, некоторые записи могут быть потеряны в процессе обработки. Например, предположим, что мы индексируем данные о передаче токенов Solana. В Solana существуют расширенные стандарты, помимо существующих стандартов токенов. Если индексатор спроектирован так, чтобы разбирать только существующий стандарт, то записи о перемещении токенов, выпущенных по расширенному стандарту, могут быть пропущены.

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

3.2. Согласованность (Consistency): точны ли собранные данные {#rps-5}

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

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

В этом процессе блок, который изначально считался действительным, может быть исключен из окончательного реестра и заменен другим блоком, что приводит к перераспределению блоков (Reorg). В этом случае транзакции, включенные в этот блок, могут быть исключены из окончательного реестра или снова включены в другой блок. Это может привести к проблемам согласованности, когда данные, собранные в определенный момент времени, отличаются от окончательного состояния реестра.

Проблемы согласованности могут возникать и на стороне клиентских узлов. Клиент узла — это основное программное обеспечение, управляющее узлами блокчейна, по сути, это операционная система (OS) блокчейна. Если в этом программном обеспечении возникают ошибки, это может привести к сбоям в интерпретации и вычислении данных реестра. На практике в основных клиентских узлах Ethereum были случаи ошибок в процессе обработки транзакций или расчета комиссий. Это похоже на ситуации в финансовых услугах, когда активы клиентов неправильно отображаются или комиссии неправильно рассчитываются.

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

3.3. Стабильность: стабильна ли система в условиях масштабной эксплуатации

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

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

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

С увеличением объема данных становится все сложнее обеспечить стабильность. В традиционных финансах недостаточно просто проверить актуальное состояние. Необходимо оценить состояние активов на определенный момент времени и выяснить, как оно было сформировано через историю транзакций. Для этого необходимы архивные узлы (Archive Node), которые сохраняют прошлые записи, но их объем может достигать десятков терабайт в зависимости от цепочки. В таких условиях, когда необходимо хранить и запрашивать огромные объемы данных, вероятность задержек в запросах и узких мест в системе возрастает.

Постоянное обслуживание также является важным требованием для стабильности. Блокчейн продолжает изменяться даже во время работы, с хардфорками (Hard Fork), обновлениями цепи и обновлениями клиентских узлов. Если в этот момент каналы сбора и обработки данных не могут адаптироваться к этим изменениям, даже нормально функционирующая инфраструктура может внезапно остановиться. В конечном итоге стабильность не может быть обеспечена только на этапе начальной настройки; она должна поддерживаться за счет постоянного реагирования на изменения в среде цепи.

4. Lambda256: инфраструктура данных блокчейна для традиционных финансов

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

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

Таким образом, для компаний более реалистичным подходом будет выбор проверенного партнера по инфраструктуре и сосредоточение на своем основном бизнесе, чем разработка всей инфраструктуры самостоятельно. Именно поэтому Lambda256 стала технологическим партнером основных операторов цифровых активов в стране. Lambda256, дочерняя компания Dunamu, предоставляет инфраструктуру блокчейна для бирж, финансовых учреждений и компаний Web3, накапливая опыт работы на внутреннем рынке.

На основе этого опыта Lambda256 в 2024 году выпустит платформу для разработки Web3 "Nodit". Недавно представленный "DataShare" является продуктом инфраструктуры данных блокчейна Nodit, разработанным с учетом требований к качеству данных и операционной среде традиционных финансов. Перед официальным запуском он уже более двух лет предоставлял услуги в формате хранилища данных для некоторых партнеров, что позволяет считать его инфраструктурой, прошедшей проверку в реальных условиях.

Для стабильной работы этой структуры необходимо также поддерживать инфраструктуру узлов, которая получает исходные данные. DataShare работает на архитектуре Hyper Node от Nodit, что позволяет гибко реагировать на крупные запросы или сбои узлов. Мы управляем минимальными стандартами доступных узлов и контролируем пороговые значения задержки и восстановления, чтобы проблемы с конкретными узлами не распространялись на весь процесс сбора данных. Кроме того, у нас есть структура, которая может реагировать без перерывов на изменения в среде, такие как обновление основной сети или замена программного обеспечения узлов.

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

Однако для использования данных на блокчейне в реальной работе необходимо не только обеспечить точность данных, но и предоставить широкий спектр необходимых цепочек и типов данных. DataShare в настоящее время поддерживает 13 ключевых цепочек, которые пользуются высоким спросом на рынке, и также может поддерживать расширение пользовательских наборов данных на основе более чем 50 мультицепочек, которые управляет Nodit. В будущем мы планируем предоставить данные с метками, объединяющие адреса кошельков бирж, смарт-контракты DeFi и данные о ценах. Это позволит расширить область применения не только в бухгалтерии и налогах, но и в управлении рисками и мониторинге аномальных сделок.

4.2. Операционная дифференциация: соблюдение требований и интеграция с существующими рабочими процессами

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

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

Кроме того, DataShare планирует продолжать усиливать совместимость с существующей средой анализа данных, используемой финансовыми учреждениями. Поддерживая интеграцию с основными платформами для анализа данных и хранилищами данных, такими как Snowflake, BigQuery и Databricks, мы стремимся обеспечить органическую связь данных на блокчейне с существующими рабочими процессами.

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

5. Моменты, когда необходима инфраструктура данных на блокчейне

Сценарий 1: Проблема точного отслеживания владельцев токенизированных акций на блокчейне

В традиционных финансах все чаще встречаются случаи одновременного выпуска акций на бирже в виде токенов на блокчейне. Ярким примером является токенизация обыкновенных акций компании Galaxy Digital ($GLXY), выпущенных на блокчейне Solana. Компания Securitize, занимающаяся токенизацией активов, также выпустила свои акции ($SECZ) на Solana одновременно с листингом на Нью-Йоркской фондовой бирже (NYSE). Solana, обладая высокой скоростью обработки и низкими затратами, стала основным выбором для финансовых учреждений, стремящихся токенизировать акции в соответствии с нормативными требованиями.

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

Проблема заключается в том, что уникальная структура данных Solana усложняет выполнение этих финансовых задач. Хотя Solana выгодна с точки зрения затрат и скорости, ее структура подразумевает, что записи транзакций распределяются по множеству аккаунтов. Даже одна транзакция DeFi может привести к фрагментации данных по токен-аккаунтам, пулу ликвидности и аккаунтам комиссий. Учитывая, что накопленный объем данных на архивных узлах Solana составляет сотни терабайт, восстановление информации о владельцах и истории транзакций за определенный момент времени становится практически невозможным для отдельных учреждений.

Таким образом, для интеграции токенизированных активов на базе Solana в традиционные финансы необходима инфраструктура данных, которая позволяет немедленно анализировать данные без предварительной обработки. DataShare очищает фрагментированные исходные данные и предоставляет их в нормализованной форме, которую можно немедленно запрашивать из существующих хранилищ данных финансовых учреждений. В частности, мы оптимизировали конвейер для высокоскоростной среды с периодом создания блока менее 0,4 секунды, обеспечивая производительность, способную обрабатывать около 20 000 транзакций в секунду на цепочку в реальном времени и минимизируя задержки индексации.

Сценарий 2: Агентские платежи, проблемы управления рисками при ончейн-расчетах {#rps-12}

На рынке агентских платежей (Agentic Payment), где ИИ-агенты принимают решения о платежах и выполняют их от имени пользователей, наблюдается рост. После запуска протокола ончейн-платежей x402 компанией Coinbase началось активное создание инфраструктуры для автономных платежей на основе стейблкоинов.

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

Так какие конкретные факторы вызывают такие пропуски и искажения данных в реальной блокчейн-среде? Одной из самых распространенных причин являются транзакции, которые не были выполнены. В зависимости от загруженности сети более 20% всех транзакций могут завершиться неудачей, особенно в случае Solana, где уровень неудач для транзакций без голосования (Non-vote transaction) может превышать 40%.

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

DataShare решает эти проблемы надежности данных, отбирая только те данные, которые обеспечивают окончательность (Finality) и подтвержденный успех, для поставки в платежную систему. Он проверяет неопределенные транзакции или записи о неудачах, включенные в исходные блокчейн-данные, в реальном времени на этапе обработки и предоставляет только очищенные наборы данных, тем самым устраняя опасения по поводу неправильной работы из-за искажений ончейн-данных.

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

6. В заключение {#rps-13}

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

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

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

Данная статья является специализированной работой исследовательского института Tiger Research, партнера Block Media, под названием 'Цифровые активы: ворота к ончейн-данным' . Данный отчет также доступен на официальном сайте .