Чому Web3 не вміє читати — ForkLog

# Чому Web3 не вміє читати

Ще кілька років тому індустрія сперечалася про те, як збільшити пропускну здатність блокчейнів. Сьогодні багато мереж уже здатні обробляти десятки тисяч операцій, а деякі заявляють про сотні тисяч. Однак виявилося, що записати дані в блокчейн — лише половина задачі. Їх іще потрібно знайти, проіндексувати, перевірити та доставити застосункам.

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

Чим швидше, тим довше

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

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

• баланси адрес;
• історію транзакцій;
• стан smart-контрактів;
• події та логи;
• ринкову аналітику;
• дані для risk-менеджменту;
• міжмережеві повідомлення.

Чим швидше працює мережа, тим більше подібних даних потрібно обробляти

Серед користувачів існує поширене хибне уявлення: якщо інформацію записано в блокчейн, то її просто отримати. На практиці все рівно навпаки. Зчитувати «сирі» дані напряму з блокчейна в реальному часі — це повільний, дорогий і технічно складний процес. У Web3-екосистемі широко поширений проміжний інфраструктурний шар, який пов’язує гаманці з dapp-застосунками.

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

Процес організований так:

1. Збір даних: Спеціальні програми безперервно «читають» блокчейн у міру появи нових блоків.
2. Індексація (структурування): Вони парсять (розбирають) ці дані й розкладають їх по класичних, дуже швидких базах даних (наприклад, PostgreSQL або ClickHouse). Там вони структуровані у зручному вигляді: «Адреса — Список усіх його токенів».
3. Миттєва відповідь: Гаманець отримує вже готову, відфільтровану відповідь із кешу за мілісекунди.

Фактично більшість популярних Web3-застосунків працюють через додатковий рівень обробки інформації. Уявіть, якщо блокчейн обробив 50 000 операцій за секунду, і мільйони гаманців одночасно надсилають RPC-запити, щоб оновити екрани. Сервери провайдерів не справляються з таким навантаженням. Прочитати, проіндексувати й відсортувати дані для користувача — це складне обчислювальне завдання. Індексатори та сервіси доступу до даних нерідко відстають від актуального стану мережі на кілька блоків, оскільки обробка, структурування та доставка даних потребують додаткового часу. І справа не просто в «застарілій інфраструктурі», хоч таке, звісно, теж буває. А в глибинному конфлікті архітектур Web2 і Web3

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

Блокчейн влаштований інакше, він до такого апаратно не готовий. Ще недавно основною перешкодою швидкості в ньому була математика й криптографія. Треба було змусити тисячі комп’ютерів по всьому світу швидко дійти згоди (консенсусу), що транзакція правильна. Розробники вирішили цю проблему, «навчивши» машини здійснювати паралельне виконання та розділяти консенсус і виконання. Наприклад, Solana, Monad і Aptos підтримують паралельне виконання незалежних транзакцій, на відміну від класичної послідовної моделі Ethereum. При цьому в Monad особливо виразно розділені узгодження порядку транзакцій і їх подальше виконання, тоді як у Solana та Aptos паралелізм реалізований через архітектуру runtime і керування конфліктами за станом.

У підсумку можна схвалювати десятки тисяч транзакцій на секунду (TPS). Але тут і криється пастка.

Історично блокчейн виконував одразу чотири функції:

• виконання транзакцій;
• консенсус;
• зберігання даних;
• надання доступу до даних.

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

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

Аналітики ChainScore Labs називають indexer gap однією з ключових проблем екосистеми Solana. За їх оцінками, традиційні підходи до індексації погано справляються з архітектурою мережі, де висока частота блоків і паралельне виконання транзакцій створюють величезний потік даних.

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

Швидкості Web3 вперлися в банальну фізику (і не тільки)

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

Уявімо мережу з 100 000 TPS. Потрібно не лише записати транзакцію, але й:

• зберегти стан;
• оновити індекси;
• відповісти на запити гаманців;
• обслуговувати ботів;
• обслуговувати аналітиків;
• обслуговувати пошукові системи;
• обслуговувати AI-агентів.

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

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

При цьому Ethereum Foundation у оновленій документації за 2026 рік вказує, що архівні вузли потребують від 3 до 12 ТБ дискового простору, а початкова синхронізація може тривати до місяця навіть на достатньо потужному обладнанні. Обмежувачами виступають швидкість SSD, обсяг пам’яті та продуктивність процесора.

Більше того, розробники Geth окремо описують стару модель архівного зберігання, де розмір бази Ethereum міг перевищувати 20 ТБ, а синхронізація тривала місяці. Саме тому довелося створювати нову path-based архітектуру зберігання станів.

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

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

Формально обробити дані можна, але не вийде зробити це дешево й децентралізовано одночасно. Вартість обробки інформації починає зростати швидше, ніж вартість самих транзакцій.

Як відреагував ринок

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

Якщо перше покоління мереж намагалося виконувати всі задачі одночасно, то нове покоління розділяє обов’язки між спеціалізованими шарами. Замість однієї мережі з’явилися окремі шари:

• execution layer — рівень виконання (або виконання);
• settlement layer — рівень розрахунків (врегулювання);
• consensus layer — рівень консенсусу;
• data availability layer — рівень доступності даних.

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

Одним із найшвидше зростаючих напрямів ринку стали DA-мережі. На перший погляд ідея виглядає дивно: навіщо створювати окремий блокчейн для тимчасового зберігання даних іншого блокчейна? Але саме це й відбувається. У модульній архітектурі виконання транзакцій і зберігання даних можуть існувати окремо. Rollup публікує дані у зовнішньому DA-шарі, а не в основній мережі. Це дозволяє значно знизити вартість масштабування й збільшити пропускну здатність.

Ще кілька років тому RPC вважався технічною деталлю. Сьогодні це один із найважливіших елементів криптоінфраструктури. У травні 2026 року Triton One разом із Solana Foundation випустили оновлений анонс RPC 2.0 — це новий підхід до побудови архітектури читання даних у мережі

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

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

Проєкт спирається на інструменти, які вже впроваджені в екосистемі, — включно з потоковою передачею даних від валідаторів (Geyser, Yellowstone gRPC) та рішеннями для обробки історії. Уся інфраструктура розповсюджується з відкритим вихідним кодом, а її розвиток координується за участі Solana Foundation.

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

Чи вирішує модульність проблему?

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

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

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

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