Вхід у цифрові активи: базова інфраструктура даних у ланцюжку

Автор: Jay Jo Джерело: Tiger Research Переклад: 善欧巴，金色财经

I. Дані в ланцюжку ще не відповідають умовам для комерційного використання інституціями

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

Ключові проблеми, на які звертають увагу інституції, уже змінилися: більше не йдеться про те, чи можна впровадити технологію блокчейну, а про те, як вбудувати її в наявні процеси бухгалтерського обліку, оподаткування, аудиту та комплаєнсу. Хоча блокчейн є новою базовою інфраструктурою, інституційні фінанси все одно вимагають, щоб він дотримувався уніфікованих бізнес-процесів, механізмів внутрішнього контролю та галузевих стандартів.

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

Тому інституції потрібен власний канал даних: зчитувати транзакційні дані з розподіленого реєстру, виконувати очищення та обробку на бізнес-рівні, а потім за потреби зберігати й здійснювати пошук даних у масштабі десятків TB. Дані в ланцюжку, хоч і є відкритими для читання, не означають, що вони автоматично відповідають вимогам для бізнесового впровадження інституціями.

II. Інфраструктура даних в ланцюжку: поточний стан і обмеження

На ранніх етапах розвитку цифрових активів проблема отримання даних не викликала особливої уваги. Тоді відповідні бізнеси здебільшого були орієнтовані на вузьке коло учасників і проводили невеликі пілотні проєкти. Наприклад, проєкт токенізації депозитів JPMorgan: він надавав обмежений інструмент для платежів лише невеликій кількості інституційних клієнтів. Межі між суб’єктами участі та застосовними сценаріями були чіткими, типи транзакцій прості, а вимоги до точності даних у реальному часі були не високими.

На ранніх етапах поріг для даних в ланцюжку був відносно низьким: бізнесу не обов’язково було синхронізувати весь стан бухгалтерського реєстру в режимі реального часу; короткочасна затримка, після якої дані досягають остаточної узгодженості (final consistency), загалом могла задовольнити потреби. Невелика кількість власних нод, сторонні RPC-інтерфейси або базові API даних з ланцюжка — цього було достатньо для підтримки більшості операційних сценаріїв.

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

III. Три ключові стандарти інституційного рівня для інфраструктури даних в ланцюжку

Вищий поріг бізнесу означає, що потрібно створити нову систему оцінювання інфраструктури. Tiger Research вважає, що інфраструктура даних в ланцюжку, яку можна стабільно використовувати інституційним фінансам, має одночасно відповідати трьом показникам: повноті, узгодженості та стабільності. Жоден з них не можна пропускати.

3.1 Повнота: повне охоплення всіх транзакцій

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

Розриви даних насамперед найчастіше виникають на етапі збору. Блокчейн пакує транзакції за певний період у блоки та записує їх у реєстр, а інфраструктура збирає дані блоків у порядку черги. Як тільки станеться збій ноди або мережеве переривання спричинить зупинку збору блоків, усі транзакції в цьому проміжку синхронно втрачаються. Такі розриви відносно легко відновити: можна виконати backfill і заповнити відсутні блоки даними, яких не вистачало.

Друга прогалина з’являється після завершення збору первинних даних блоку. Індекcатор витягує транзакційні записи з первинних даних і перетворює їх на формат, придатний для запитів; якщо логіка парсингу неповна, це також спричиняє втрату записів. Наприклад, у разі індексації даних Solana: у ланцюжку одночасно існують нативний стандарт токенів і розширений стандарт токенів. Якщо індексатор підтримує лише нативний стандарт, записи про перекази токенів, випущених за розширеним стандартом, буде повністю пропущено.

Високопродуктивні публічні мережі ще більше ускладнюють реалізацію повноти. Коротші інтервали між блоками та вищий пропуск транзакцій вимагають, щоб канал даних завершував обробку величезних обсягів даних за дуже короткий час. Навіть якщо логіка збору та парсингу коректна, якщо швидкість обробки у реальному часі не встигає за темпом генерації блоків у ланцюжку, це спричинить затримку потрапляння нових даних транзакцій до сховища. Коротко: повнота — це не лише збір усіх транзакцій, а й постійне узгодження швидкості роботи публічної мережі з ітеративними змінами протоколу.

3.2 Узгодженість: дані повністю відповідають стану реєстру в ланцюжку

Повнота перевіряє, чи відсутні дані; узгодженість перевіряє, чи зібрані дані однакові зі станом реєстру в ланцюжку. Обидва аспекти однаково критичні. Будь-який один неправильний запис призведе до спотворення всіх результатів обліку, що базуються на його похідних розрахунках.

До остаточного підтвердження впровадження дані в ланцюжку мають імовірнісні характеристики. У традиційних фінансових системах дані централізовано записує сервер; у блокчейні кілька сторін незалежно верифікують блоки та досягають консенсусу для оновлення реєстру. Затримки в мережі та відмінності у часових послідовностях верифікації можуть спричинити появу кількох блоків, які на короткому горизонті виглядають дійсними.

Блок, який на певному етапі вважається валідним, згодом може бути вилучений з реєстру або перекритий блоком-заміною, тобто відбувається реорганізація блоків (Reorg). Транзакції в вилучених блоках або повністю зникають із фінального реєстру, або переходять в інші блоки. Дані, зібрані в певний момент часу, розійдуться з фінально зафіксованою бухгалтерською книгою — це і є ризик узгодженості.

Проблеми узгодженості також можуть виникати через клієнт ноди — базове програмне забезпечення, яке фактично є «операційною системою» блокчейну. Баг у клієнтській програмі може спричинити помилки в парсингу та розрахунках даних реєстру. У Ethereum основні клієнти неодноразово демонстрували аномалії обробки транзакцій і розрахунку комісій; це рівнозначно тому, як фінансова установа неправильно повідомляє клієнтам їхні активи та помилково клірить комісійні.

Самого лише збору даних недостатньо для гарантування узгодженості. Дані, зібрані snapshot-захопленням, можуть відрізнятися від фінальної бухгалтерської книги, а баги клієнта також спричиняють відхилення у прочитанні реєстру. Щоб використовувати дані в ланцюжку як довірене джерело для інституційних фінансів, необхідно постійно виконувати перехресну верифікацію із реєстром у ланцюжку.

3.3 Стабільність: безперервна робота в масштабних сценаріях

Повнота та узгодженість характеризують якість статичних даних. Стабільність оцінює, чи можуть процеси збору, обробки та запитів безперервно працювати без збоїв у великому навантаженні. У фінансовій галузі навіть одна зупинка сервісу або затримка даних можуть спричинити значні втрати; властивість блокчейну працювати 7×24 безперервно ще більше підвищує вимоги до стабільності.

Великий бізнес означає масивні паралельні запити. Традиційні сервери покращують пропускну здатність через балансування навантаження та розподіл запитів, але інфраструктуру блокчейну неможливо просто скопіювати цю модель: різні ноди мають різні прогреси синхронізації блоків, і однакові запити на різних нодах можуть повертати різні результати. Наприклад: користувач ініціює переказ і одразу запитує статус транзакції. Нода, яка першою отримала транзакцію, показує підтвердження завершення, тоді як інша нода ще не встигла синхронізуватися. Результати, які повертає інфраструктура в двох місцях, самі по собі можуть бути правильними, але користувач побачить дві різні «версії» статусу однієї й тієї ж транзакції.

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

Постійне ітеративне обслуговування також є ключовим для стабільності. Публічні мережі безперервно проходять через hard fork, мережеві оновлення та ітерації версій клієнтів. Якщо канал даних не може синхронно супроводжувати ці зміни, інфраструктура, яка раніше працювала нормально, може раптово й без попереджень вийти з ладу. Стабільність — це не лише досягти заданого рівня при запуску: потрібно постійно адаптуватися до змін у середовищі блокчейну та тривало підтримувати динамічне обслуговування.

IV. Lambda256: інфраструктура даних в ланцюжку для інституційних фінансів

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

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

Вибираючи постачальника зрілої інфраструктурної послуги, компанії можуть фокусуватися на ключовому бізнесі. Це більш практично й реалістично, ніж розробляти власноруч. Ось чому Lambda256 стала технічним партнером для багатьох провідних цифрово-активних компаній у Кореї. Lambda256 входить до складу групи Dunamu. Вона надає інфраструктуру блокчейну для бірж, фінансових установ і Web3-компаній, накопичивши глибокий досвід операцій у корейському ринку.

Спираючись на галузевий досвід, Lambda256 у 2024 році запустила Web3-розробницьку платформу Nodit. Платформа нещодавно випустила продукт для інфраструктури даних в ланцюжку Datashare, створений повністю навколо стандартів якості даних і операційних вимог для інституційних фінансів. Перед офіційним комерційним використанням Datashare в режимі версії сховища даних вже два роки проходив пілотну експлуатацію для партнерських клієнтів і був повністю підтверджений у реальних бізнес-сценаріях.

4.1 Технічні переваги: власний індексувальний рушій та високопродуктивний канал даних

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

Підґрунтям для стабільної роботи всієї системи є надійність сервісів первинних нод. Datashare використовує архітектуру вузла Nodit Hyper Node, гнучко обробляє великі обсяги запитів і спокійно справляється з відмовами однієї ноди. Hyper Node підтримує мінімальний поріг доступної кількості нод, керує показниками затримки та відновлення після збоїв. Відхилення на одній ноді не передається на весь ланцюжок збору даних, а також дозволяє безперервно підтримувати сервіс під час оновлень основної мережі та заміни версій клієнта.

Інша відмінна можливість: усі зібрані дані проходять незалежно додані процеси валідації. Datashare постійно звіряє стан реєстру в ланцюжку з крос-валідацією, виявляє відхилення даних, спричинені reorg блоків, аномаліями клієнта та змінами через оновлення ланцюга, щоб забезпечити взаємну відповідність результатів виконання кожної транзакції, журналів подій і змін залишків. Багаторівневі перевірки в ланцюжку ефективно знижують ризик втрати даних і помилок парсингу, завдяки чому Datashare може бути вбудований у наявні бізнес-процеси інституцій як довірене джерело даних.

Лише точність недостатня для розкриття цінності даних у ланцюжку: інституціям також потрібне широке покриття багатьох публічних мереж і типів даних. Datashare за замовчуванням підтримує 13 провідних ринкових публічних мереж; спираючись на ресурси понад 50 публічних мереж, які вже охоплені Nodit, можна швидко розширювати кастомізовані набори даних. У подальших планах Lambda256 має намір запустити тегований сервіс даних, який об’єднає адреси гаманців бірж, DeFi-контракти та інформацію про ринкові котирування. Це розширить застосовні сценарії від бухгалтерського обліку та податків до сфер управління ризиками та моніторингу аномальних транзакцій.

4.2 Операційні переваги: комплаєнс-можливості та глибока інтеграція з бізнес-системами

Для впровадження даних в ланцюжку в інституційному фінансі комплаєнс і якість даних мають однакову важливість. Особливо коли корейські фінансові установи залучають зовнішню інфраструктуру, вони висувають суворі вимоги щодо ізоляції мережі, контролю доступу та правил експлуатації у внутрішній мережі. Datashare підтримує локальне розгортання в місцевих IDC-ЦОД, щоб відповідати вимогам регуляторів, а також має сертифікацію SOC 2, удосконалюючи систему управління безпекою, що спрощує використання даних у ланцюжку фінансовими установами в межах їхніх власних рамок контролю ризиків і комплаєнсу.

Самостійне керування належністю даних і правами доступу є критично важливим для фінансових установ. Datashare підтримує архітектурний режим прямого передавання (direct-to), коли дані в ланцюжку напряму пушаться в власне хмарне сховище компанії, наприклад AWS S3. Коли компанія обирає сторонню інфраструктуру, вона водночас зберігає повний контроль над керуванням даними та правами на доступ.

Продукт постійно посилює можливості інтеграції з популярними інструментами аналітики даних: нативно сумісний зі сховищами та аналітичними платформами даних Snowflake, BigQuery, Databricks тощо, забезпечуючи безшовне вбудування даних з ланцюжка у наявні бізнес-процеси.

Операційна підтримка, яка йде разом із Lambda256, також є конкурентною перевагою. Блокчейн-мережа працює безперервно цілий рік, а швидке виявлення та усунення перерв і затримок є критично важливими. Datashare оснащений локальною командою моніторингу та спеціальною технічною підтримкою 7×24, що значно зменшує навантаження на створення власної команди блокчейн-експлуатації у фінансовій установі, і дозволяє стабільно використовувати дані в ланцюжку за низької вартості.

V. Ключові сценарії впровадження інфраструктури даних в ланцюжку

Сценарій 1: відстеження бухгалтерської книги власників токенізованих акцій на ланцюжку

Все більше інституцій, окрім паралельного розміщення акцій на традиційних біржах, також випускають акції, токенізуючи їх і записуючи на блокчейн. Глобальна група цифрових активів Galaxy Digital випускає токени звичайних акцій (GLXY випущено у Solana; постачальник токенізації активів Securitize у день, коли акції були допущені до лістингу на NYSE, одночасно випустив токенізовані акції у Solana) SECZ. Низька вартість і висока швидкість Solana роблять її найкращим базовим рівнем для токенізації комплаєнс-секюриті.

Водночас інституції, які одночасно керують традиційними цінними паперами та токенізованими цінними паперами в ланцюжку, стикаються з новими операційними викликами: брокерам потрібно точно відстежувати власників токенізованих активів у ланцюжку, а також кінцевих вигодоотримувачів (UBO), і подавати регуляторам та аудиторам повну бухгалтерську книгу. Реєстрація прав власності відбувається не лише на момент закриття торгів під час лістингу: дати для дивідендів та уточнення прав (dividend ex-date/record date), а також дати реєстрації для голосування акціонерів — усі потребують повних даних. Втрата даних на будь-якій ноді або помилка в розрахунку залишків можуть спричинити серйозні ризики, як-от помилкова виплата дивідендів, порушення правил розкриття інформації та провал аудиту.

Складність полягає в унікальній архітектурі даних Solana. Хоча комісії за транзакції низькі, а швидкість підтвердження висока, транзакційні записи зберігаються розрізнено в масиві незалежних акаунтів. Навіть одна звичайна взаємодія DeFi розподіляє дані між токен-акаунтами, грошовими пулами та акаунтами комісій у кількох місцях. Обсяг архівних даних нод Solana може сягати сотень TB, тож інституціям важко самостійно відстежувати списки власників на довільні моменти часу та повну історію транзакцій.

Щоб включити Solana токенізовані активи в інституційні системи, потрібна інфраструктура даних, здатна робити аналіз одразу й без потреби в додатковій повторній обробці. Datashare очищає фрагментовані первинні дані до стандартизованого формату, який можна напряму підключати до запитів у власному сховищі даних інституції. Канал продукту оптимізовано для Solana з періодом генерації блоку нижче 0.4 секунди: можливість обробки в реальному часі для одного ланцюга — близько 20 тисяч TPS, що максимально скорочує затримку індексації.

Сценарій 2: AI ризик-менеджмент для автономних платежів і клірингу

Траєкторія автономних платежів, де AI-агенти ініціюють платежі від імені користувачів, набирає популярності. Після того як Coinbase представила протокол ончейн-платежів x402, запуск прискорився завдяки автоматизованій інфраструктурі платежів на основі стейблкоїнів.

Щоб автономні платежі були комерційно життєздатними, якість даних у ланцюжку за рішеннями, що стоять за автоматизацією, є «лінією життя». Коли етап ручного аудиту зникає, система може покладатися лише на дані, щоб визначити доступний баланс, фінальність транзакції та ризик шахрайства. Якщо дані відсутні або спотворені, це напряму призведе до помилкового рішення щодо схвалення платежів.

У реальному ончейн-середовищі багатофакторні умови часто спричиняють аномалії даних. Найбільш критичний випадок — це невдача виконання транзакції. Через перевантаження мережі загальний рівень невдалих транзакцій у блокчейні зазвичай перевищує 20%, а в Solana для не-голосувальних транзакцій рівень невдач іноді ще вищий за 40%.

Якщо платіжна система класифікує невдалі транзакції як успішні перекази, вона помилково списуватиме баланс на бухгалтерських рахунках; у подальших нормальних платежах це призведе до блокування через аномалії валідації балансу. Інша велика загроза — блокова реорганізація (reorg): транзакція, яка була одного разу підтверджена, може бути згодом скасована й вилучена з реєстру, що легко спричиняє плутанину під час звірки коштів.

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

Продукт також постійно розширює покриття на базі GIWA, Kaia та інших провідних локальних публічних мереж як на внутрішньому, так і на зовнішніх ринках, підвищуючи універсальність рішення. Інфраструктура автономних платежів завдяки цьому отримує стабільну багатоманітну «базу даних» і не обмежується однією публічною мережею: вона може гнучко адаптуватися до сценаріїв бізнесу в різних регіонах і регуляторних вимог.

VI. Висновок

Успіх або провал бізнесу з цифровими активами дуже сильно залежить від точності обробки даних. Дані в ланцюжку проходять через весь фінансовий ланцюг — від випуску до платежів і клірингу. Втрата або спотворення даних не тільки шкодить довірі до бізнесу, а й створює серйозні ризики комплаєнсу. Datashare як інфраструктура ефективно знижує такі операційні ризики та усуває бар’єри між інституційними фінансами та доступними даними в ланцюжку.

Окрім Datashare, фінансові установи можуть обрати інші продукти фінтеху Lambda256: цифрову клірингово-операційну платформу SCOPE та інструмент комплаєнс/регуляторного нагляду CLAIR. Під час розвитку бізнесу компанія може поступово нарощувати функції без потреби повністю перебудовувати інфраструктуру з нуля.

Таким чином фінансові установи можуть делегувати важкі роботи зі створення та експлуатації інфраструктури «на аутсорс», фокусуючись на основному бізнесі, інноваціях сервісу та відмінності продуктів. Знижуючи поріг входу, вони також можуть поступово нарощувати технологічні можливості в міру масштабування бізнесу та змін регуляторних вимог.