Ворота до послуг цифрових активів: інфраструктура даних на блокчейні - Tyger Research

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

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

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

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

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

2. Реальність та обмеження створення інфраструктури даних на блокчейні {#rps-2}

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

У той час вимоги до даних на блокчейні були відносно м'якими. Навіть якщо всі стани не збігалися в реальному часі, якщо через певний час в результаті все ж таки була досягнута узгодженість, це не викликало великих проблем в експлуатації. Тобто, обробка на основі остаточної узгодженості (Eventual Consistency) була цілком прийнятною. У такому середовищі можна було без проблем управляти обмеженими вузлами або інтегрувати зовнішні RPC кінцеві точки або прості API даних на блокчейні.

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

3. Вимоги до інфраструктури даних на блокчейні для регульованих фінансів {#rps-3}

Щоб відповідати підвищеним вимогам, критерії оцінки інфраструктури також повинні змінитися. Tyger Research пропонує три основні критерії для інфраструктури даних на блокчейні, яким можуть довіряти та використовувати регульовані фінанси: повнота (Completeness), узгодженість (Consistency) та стабільність (Stability). Це є обов'язковими вимогами, які повинні бути виконані, щоб дані на блокчейні могли функціонувати як основний реєстр для реальних послуг.

3.1. Повнота (Completeness): Чи включені всі записи угод? {#rps-4}

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

Пропуски даних можуть виникнути на етапі збору. Блокчейн об'єднує угоди, що відбулися протягом певного часу, в блоки для запису в реєстр. Інфраструктура даних обробляє ці блоки по порядку. Однак, якщо через збої вузлів або проблеми з мережею збір блоків у певному інтервалі зупиняється, записи угод, що містяться в цьому інтервалі, також можуть бути пропущені. Проте пропуски на етапі збору можна відносно чітко виявити та вирішити. Дані можна заповнити за допомогою роботи з повторним збором (Backfill) пропущених блоків.

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

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

3.2. Узгодженість (Consistency): Чи є зібрані дані точними? {#rps-5}

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

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

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

Проблеми з узгодженістю можуть виникнути також на стороні клієнта вузла. Клієнт вузла є основним програмним забезпеченням, яке запускає вузли блокчейну, і, простіше кажучи, є близьким до операційної системи (OS) блокчейну. Якщо в цьому програмному забезпеченні виникає дефект, можуть виникнути помилки в процесі інтерпретації та обчислення даних реєстру. Насправді в основних клієнтах вузлів Ethereum вже були випадки помилок під час обробки транзакцій або розрахунку комісій. Це схоже на ситуації у фінансових послугах, коли активи клієнтів неправильно відображаються або комісії неправильно розраховуються.

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

3.3. Стабільність: Чи є стабільними в умовах масштабної експлуатації {#rps-6}

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

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

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

Чим більший обсяг даних, тим складніше забезпечити стабільність. У традиційній фінансовій системі недостатньо просто перевірити останній стан. Необхідно оцінити стан активів у певний момент часу та перевірити, через які історії транзакцій цей стан був сформований. Для цього потрібен архівний вузол (Archive Node), що зберігає минулі записи, але в залежності від ланцюга його обсяг може досягати десятків терабайт. У такій обстановці, де потрібно зберігати та запитувати величезні обсяги даних, ймовірність затримок запитів та вузьких місць у системі також зростає.

Постійне обслуговування також є важливою вимогою для стабільності. Блокчейн продовжує змінюватися навіть під час експлуатації через хардфорки (Hard Fork), оновлення ланцюга, оновлення клієнтів вузлів тощо. Якщо в цей час трубопровід збору та обробки даних не може впоратися з цими змінами, навіть інфраструктура, яка раніше працювала нормально, може раптово зупинитися. Врешті-решт, стабільність не може бути забезпечена лише на етапі початкового будівництва, вона повинна постійно відповідати змінам в середовищі ланцюга.

4. Lambda256: Інфраструктура даних на ланцюгу для традиційних фінансів {#rps-7}

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

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

Тому з точки зору компаній більш реалістичним є вибір перевіреного партнера з інфраструктури та зосередження на своїй основній діяльності, ніж розробка всієї інфраструктури самостійно. Саме тому 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), де AI-агенти приймають рішення про платежі та виконують їх від імені користувачів. Після запуску ончейн-протоколу x402 компанією Coinbase, активно розвивається інфраструктура автономних платежів на основі стейблкоїнів.

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

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

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

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

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

6. На завершення {#rps-13}

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

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

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

Ця стаття є експертом дослідження глобальної веб3 організації Tiger Research, партнера Block Media, під назвою 'Шлях до послуг цифрових активів, ончейн-інфраструктура даних' . Цей звіт також доступний на офіційному сайті .