Еще несколько лет назад в світі блокчейнів свиржалися про проблеми зі швидкістю обробки даних. Сьогодні багато мереж вже здатні обробляти десятки тисяч операцій, а деякі навіть стверджують, що здатні обробляти сотні тисяч операцій. Але виникла нова проблема – записувати дані в блокчейн лише половина завдання.
Блокчейн ще потрібно знайти, індексувати, перевірити і надіслати додаткам.
📊💰
Чим швидші мережі, тим довжіші
За останні десять років розвиток блокчейнів відбувався через масштабованість. Світовий світ повинен був знайти компроміс між безпекою, децентралізацією і продуктивністю. Але сьогодні вже зрозуміло, що навіть якщо проблема швидкості частково вирішена, виникає новий виклик.
Сам по собі блокчейн не має користувачів інтерфейсу. Цю роль виконують різні додатки. Вони в свою чергу повинні постійно отримувати дані:
📊👥
Состояние смарт-контрактів;
Дані для управління ризиками;
Чим швидше працює мережа, тим більше подібних даних потрібно обробляти.
Серед користувачів існує поширений міф: якщо інформація записана в блокчейн, її можна просто отримати. На практиці все навпаки. Считувати «сырые» дані прямо з блокчейна в реальному часі – це повільний, дорогий і технічний процес. У світі широко розповсюджений проміжний інфраструктурний рівень, який поєднує кошельки з додатками.
Наприклад, додаток-кошелок, щоб користувач побачив свій баланс за долі секунди, звертається до провайдерів RPC, індексаторів, аналітичних платформ, кеш-серверів, спеціалізованих баз даних тощо.
Процес відбувається наступним чином:
Збір даних: Спеціальні програми неперервно «читають» блокчейн при виникненні нових блоків.
Індексація (структуризація): Вони розбирають дані і розкладають їх за класичними швидкими базами даних (наприклад, PostgreSQL чи ClickHouse). Там вони організовані в сприятливий форматі: «Адрес — Список усіх його токенів».
Мгновений відповідь: Кошелек отримує вже підготовлений, відфільтрований відповідь з кешу за мільсекунди.
Більшість популярних додатків Web3 працюють через додатковий рівень обробки інформації. Представте, якщо блокчейн обробив 50 000 операцій за секунду, а мільйони кошельків одночасно відправляють RPC-запити, щоб оновити екрани. Сервери провайдерів не можуть з цим впоратися. Прочитати, індексувати і відсортовувати дані для користувача – це складна розрахункова задача. Індексатори і служби доступу до даних рідко відстали від актуального стану мережі на декілька блоків, оскільки обробка, структурування та доставка даних вимагають додаткового часу. І це не тільки питання «старої інфраструктури», хоча воно існує.
Працівники ринку вже зрозуміли, що швидкі мережі створюють конкуренцію за ресурси між консенсусом, виконанням операцій і інфраструктурними послугами на поверхні мережі.
💸📈
Вищий рівень швидкості створює більш глибокий конфлікт
Блокчейн повинен виконувати кілька функцій одночасно:
Доступ до даних;
Підвищення швидкості обробки даних створює додаткову навантаження на усі ці функції одночасно. Система створює дані швидко, ніж інфраструктура може їх прочитати, і виникає так званий indexer gap.
У Helius — одного з найбільших інфраструктурних провайдерів екосистеми Solana — прямо вказують, що послідовна структура блокчейна добре підходить для забезпечення цілісності даних і високої пропускної здатності, але робить історичні запитів повільними і неефективними. Тому більшість організацій змушені будувати власні індексатори і окремі бази даних поверх блокчейна.
Аналітики ChainScore Labs indexer gap однією з головних проблем екосистеми Solana. За їх оцінкою, традиційні підходи до індексації погано виконують архітектуру мережі, де висока частота блоків і паралельне виконання операцій створюють величезний потік даних.
Як наслідок, мережа може підтверджувати операції майже миттєво, але додаткам потрібно багато часу для обробки наслідків цих операцій.
Швидкості Web3 зупинилися біля банальної фізики (і не тільки)
💨🔩
Витоки проблеми лежать в пропускній здатності процесорів, жорстких дисків і мережевих кабелів. Виявилося, що масштабованість блокчейна не рівна масштабованістю інфраструктури навколо нього. І з цим потрібно швидко справитися.
Повідомте про мережу з 100 000 TPS. Needed не тільки записати транзакцію, але і:
Отвечати на запитання кошельків;
Обслуговувати пошукові системи;
З огляду на це високоякісна пропускна здатність створює конкуренцію за ресурси між консенсусом, виконанням операцій і інфраструктурними послугами на поверхні мережі.
Паралельне розвитку деяких технологій, які беруть участь у мережі, змушують її розв’язувати цю проблему вже сьогодні. Для людини затримка в секундах або навіть хвилинах може бути цілковито терпимою. Для ІІ-агентів, торгівельних систем і автономних послуг вже ні.
Модульна архітектура – спроба вирішення проблеми
Нове покоління мереж розділяє відповідальність між спеціалізованими шарами:
Execution layer – рівень виконання;
Settlement layer – рівень розрахунків;
Consensus layer – рівень консенсусу;
Data availability layer – рівень доступності даних.
Розробники порівнюють цей процес із еволюцією дата-центрів. Раніше один сервер виконував усі функції одночасно. Сьогодні обчислення, зберігання даних і мережеві послуги масштабуються незалежно одне від одного.
Одним із найшвидше зростаючих напрямків ринку стали DA-сети. На перший погляд ідея виглядає дивно: чому створювати окремий блокчейн для тимчасового зберігання даних іншого блокчейна? Але саме це відбувається. У модульній архітектурі виконання операцій і зберігання даних можуть існувати окремо. Rollup публікує дані у зовнішній DA-шар, а не в основну мережу.
Також декілька років тому RPC вважалося технічним дрібницею. Сьогодні це одне з найважливіших елементів криптоінфраструктури.
Робота над модульною інфраструктурою вже розпочалася
У червні 2026 року Triton One спільно з Solana Foundation оголосила про новий підхід до будівництва архітектури читання даних мережі.
Ключова ідея полягає в розділі доступу до поточного стану мережі і її історії. Для цього вводяться два незалежних модулі: один індексує стан облікових записів у реальному часі, а інший оптимізує роботу з історичними данними.
Нова модель читання масштабується окремо від консенсусу, а доступ до історії стає швидшим завдяки використанню колонкових зберігань і попередньо відсортованих даних.
Проект ґрунтується на вже внедрених інструментах екосистеми, включаючи потокову передачу даних з валідацій (Geyser, Yellowstone gRPC) і рішення для роботи з історією.
Усі інфраструктурні засоби розповсюджуються відкритим кодом, а
За матеріалами ForkLog