Розгортання Blockscout для мережі: де губляться дані
Публічний оглядач зручний, поки ви дивитеся на чужу мережу збоку.
Щойно мова заходить про власні транзакції, з'ясовується: за адресою віддаються лише останні кілька тисяч операцій, внутрішні перекази між контрактами не індексуються, а виклики через проксі взагалі не видно в інтерфейсі.
Баланс на сторінці сходиться, а звірка з обліковою системою — ні, і розбіжності доводиться розбирати вручну за хешами.
Другий шар проблеми — доступ до даних. Публічні сервіси обрізають частоту запитів і глибину вибірки логів, тому повнота історії транзакцій недосяжна в принципі: частина подій через їхній інтерфейс просто не віддається.
Пошук по мережі обмежений тим, що проіндексував власник сервісу, — додати туди свої контракти, кастомні події чи внутрішню розмітку адрес не можна. Вивантаження під звітність, аудит або розбір інциденту впирається в те, що дані не забрати цілком і в потрібному вигляді.
Власний оглядач блоків на своїх серверах знімає обидва обмеження. Розгортання Blockscout починається з індексатора, який проходить мережу з першого блоку і складає логи, трейси та перекази у власну базу — історія не обрізається ні за глибиною, ні за кількістю звернень. Як це влаштовано і що ламається по дорозі — розбираємо, як це закривається.
Ефект: швидкість пошуку, повнота історії, контроль доступу
Зібраний під конкретну EVM-мережу оглядач дає ефект, який вимірюється, а не обговорюється. Нижче — що саме змінюється після розгортання кастомного оглядача блоків на базі Blockscout і за якими метриками це приймається.
- Швидкість пошуку по мережі. Відповідь за адресою, хешем транзакції чи номером блоку — частки секунди на прогрітому кеші, без черги до публічного сервісу й залежності від чужого навантаження.
- Повнота індексації переказів. Внутрішні перекази, виклики контрактів і події токенів потрапляють у базу цілком — історія та баланси сходяться зі станом мережі, а не обмежуються зовнішніми транзакціями.
- Розвантаження вузлів мережі. Важкі вибірки історії йдуть в окрему базу оглядача, і точки доступу перестають тримати пікове навантаження від аналітики та вивантажень.
- Контроль доступу до оглядача. Ролі налаштовуються під задачу: публічний перегляд, закритий контур для аудиту, окремі права на вивантаження даних і експорт.
- Кастомний оглядач блоків. Свої фільтри, поля та підписи для внутрішньої логіки мережі — те, чого в публічному сервісі не покажеш.
Приймання йде за метриками: заміряємо час відгуку на типові запити, звіряємо індекс зі станом мережі на контрольних блоках і фіксуємо, які вузли звільнилися від аналітичного навантаження.
Як розмістити оглядач: хмара, власні сервери, гібрид
Оглядач — це пошуковик по вашій мережі: він збирає блоки та транзакції, розкладає їх у базу, віддає програмний інтерфейс і вебсторінки.
Рішення про розміщення визначає три речі одразу: хто володіє індексом, де впреться продуктивність під навантаженням і що взагалі можна доналаштувати.
Ми розгортаємо Blockscout та його форки в трьох режимах — від повністю керованого до повністю свого. Різниця між ними не в «зручності», а в тому, які обмеження ви приймаєте усвідомлено.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Оглядач у хмарі | Швидкий старт, немає власної команди експлуатації, мережа стандартна | Готовий оглядач: фіксований набір методів інтерфейсу, не можна правити схему індексації та додавати свої метрики; індекс фізично у провайдера |
| Самостійний хостинг | Потрібен контроль над даними, нестандартні контракти, свої модулі аналітики | Відмовостійкість, реплікацію та оновлення берете на себе; простій індексатора зупиняє пошук по мережі |
| Гібридна схема індексації | Індекс та архів мають лежати всередині контуру, а віддача — назовні | Між контурами потрібен стабільний канал; маршрутизація запитів складніша, частина видачі йде із затримкою |
| Публічний оглядач вендора | Тестова мережа, демонстрація, раннє прототипування | Немає приватності, немає своїх токенів і метаданих, є ліміти на частоту запитів |
Вибір режиму — не смаківщина, а наслідок вимог до даних і навантаження. Далі показуємо, як переносимо індекс між контурами без втрати історії.
Як проходить розгортання Blockscout: етапи впровадження
Порядок робіт вибудувано так, щоб помилки у схемі даних не спливали на етапі синхронізації, коли перезбирання індексів коштує днів простою. Спочатку розбираємося з мережею та тим, що вона віддає вузлу, потім піднімаємо оточення, і лише після цього вмикаємо індексатор. Нижче — етапи розгортання оглядача в тому вигляді, в якому ми їх проходимо.
-
Аудит мережі перед запуском. Перевіряємо, які стандарти контрактів у ходу, чи є внутрішні перекази через трейси, скільки подій на добу і якої глибини потрібна історія.
Рахуємо, чи вкладається вона у звичайний вузол чи потрібен архівний режим — від цього залежить час первинної синхронізації.
-
Підготовка оточення. Піднімаємо вузли потрібного режиму, базу під дані індексатора, проксі-шар із шифруванням трафіку, розмежування доступу за мережами. Заздалегідь описуємо схему відмовостійкості: що переживе перезапуск, а що доведеться досинхронізувати.
-
Налаштування індексатора. Задаємо стартову висоту, набір оброблюваних модулів, стратегію обходу трейсів, розміри черг і повтори при збоях. Невірний старт дає розбіжність балансів на сотні блоків, тому висоту звіряємо з вузлом двічі.
-
Синхронізація та звірка даних. Вибірково порівнюємо блоки, баланси адрес і внутрішні перекази з даними вузла, шукаємо пропуски та дублі. Окремо дивимося, як поводиться індексатор після перезапуску — чи підхоплює він хвіст без ручного втручання.
-
Перевірка під навантаженням. Проганяємо пошук за адресами, фільтри подій і вивантаження на потоці запитів, вимірюючи відставання індексатора від голови мережі. Якщо на піку відставання зростає, додаємо ресурси до приймання, а не після.
-
Приймання оглядача. Проходимо за сценаріями: пошук за хешем, верифікація контракту, історія токенів, коректність внутрішніх переказів. Замовник отримує чек-лист із результатами за кожним пунктом.
-
Передача доступів. Віддаємо ролі та ключі, доступ до бази й моніторингу, метрики щодо відставання та помилок індексації, інструкцію з відновлення після збою.
Кожен етап закривається артефактом — конфігурацією, звітом звірки або записом у чек-листі. Тому питання «чому оглядач показує не те» вирішується за документами, а не пошуком наосліп.
Комплект постачання: конфігурації, схеми, регламенти
Комплект постачання — не архів із короткою інструкцією, а набір артефактів, за якими оглядач Blockscout піднімається заново на чистій інфраструктурі, передається іншій команді та проходить перевірку доступів.
Усе, що робиться під час розгортання, фіксується в репозиторії: конфігурації, міграції схеми бази, описи сервісів, регламенти. Нижче — що саме йде замовнику.
- Робочі конфігурації вузла: файли оглядача, змінні оточення, параметри підключення до ноди та бази, окремі набори значень для тестового й продуктивного контурів.
- Схема розгортання: склад сервісів і зв'язки між ними, точки входу, балансування, місце кешу та черги індексації, розділення контурів.
- Політики доступу та ролі: матриця «роль — дія», сервісні облікові записи, розмежування прав на адмін-панель, ключі для зовнішніх інтеграцій і порядок їх заміни.
- Регламент резервного копіювання: що і з якою періодичністю зберігається, де лежать копії, як перевіряється відновлення і за який час оглядач повертається в робочий стан.
- Регламент оновлення: порядок викочування нової версії, перевірка сумісності схеми бази, точка відкату та критерії, за яких оновлення зупиняють.
- Інструкції для супроводу: типові операції, діагностика відсталого індексатора, читання логів, порядок дій при розбіжності даних із нодою.
- Комплект документації оглядача: опис архітектури, карта сервісів, перелік зовнішніх залежностей, чек-лист приймання та передачі в експлуатацію.
Кейс: оглядач для зростаючої мережі, метрики до і після
Мережа зі щільним потоком операцій впиралася в чужий оглядач: історія обмежувалася глибиною сторонньої індексації, а на піках активності сторінка адреси відкривалася десятками секунд.
Кожен перегляд блоку тягнув чергу викликів до наших вузлів — вони конкурували з гаманцями та внутрішніми сервісами. Відмов індексації після перебудов ланцюга доводилося чекати, поки їх усуне провайдер.
Розгорнули власний Blockscout поруч із мережею: індексатор читає блоки напряму і пише в нашу базу від генезис-блоку, інтерфейс відповідає з локального кешу, важкі вибірки не доходять до вузлів.
Метрики до і після
| Що вимірюємо | До | Після |
|---|---|---|
| Відкриття сторінки адреси | понад 20 секунд на піках | 1–2 секунди |
| Викликів до вузла на один перегляд | десятки | одиниці, решта — з бази індексатора |
| Глибина історії | обмежена чужою індексацією | повна, від першого блоку |
| Відмови індексації | регулярно при перебудовах ланцюга | усунені, відновлення автоматичне |
Що це дало
Вузли перестали бути вузьким місцем: навантаження від публічного оглядача пішло в окремий контур читання, і гаманці знову відповідають без черги.
Додали метрики стану індексатора — відставання від голови ланцюга, глибину черги, час відповіді, — за ними видно деградацію раніше, ніж її помітять користувачі.
Чим відрізняється власний оглядач від готового у вендора
Готовий оглядач у вендора — це чужий індексатор із публічним інтерфейсом поверх нього. Ви бачите рівно ті дані, які платформа вирішила зібрати: глибину індексації, набір підтримуваних викликів і затримку оновлення визначає не ваша мережа, а власник платформи.
Власний оглядач починається з того, що індексатор, його база та правила обробки належать вам.
У Blockscout відкритий доступ до конфігурації індексу: власні системні контракти, внутрішні перекази, нестандартні події та метадані зі своїх сервісів — те, що вендорська збірка зазвичай не пропускає.
Доступ до вихідних даних мережі — друга відмінність. Вендорський варіант віддає зріз через чужий API з лімітами на частоту запитів і вивантаження, нерідко без сирих логів і внутрішніх транзакцій. Власний екземпляр відкриває повний набір — для аналітики, розбору спірних операцій і звітності.
Кастомізація оглядача теж різного масштабу. У вендора це логотип і колірна схема; у свого — додаткові вкладки та поля, посилання на внутрішні системи, закриті розділи під ролі та різний склад даних для команди й для зовнішніх користувачів.
Третє — залежність від чужої політики: вендор сам вирішує, коли перезбирати індексатор під оновлення правил мережі, як змінювати умови і в якому вигляді віддавати дані.
Розширення оглядача під задачу — від аудиту внутрішніх переказів до моніторингу мостів — тут питання доопрацювання, а не переговорів із платформою.
Технічні сумніви: навантаження, доступи, оновлення
Blockscout при розгортанні — це окремий сервіс зі своєю базою та чергою індексації, він не живе всередині вузла.
Якщо вузол відстає або перезапускається, індексувальний процес просто наздоганяє пропущене за номерами блоків, а на сторінках видно поточну висоту та величину відставання — за цим порогом ми налаштовуємо оповіщення.
Ролі теж розділені: у вузла, бази та веб-частини свої права, ключі та мережеві доступи. Адміністратор не ходить у базу з браузера, а оновлення викочуються по одному компоненту з перевіркою після кожного кроку. Нижче — відповіді на те, що запитують найчастіше до старту.
Що буде, якщо вузол відстане або випаде з мережі?
Індексація зупиниться на досягнутій висоті, але дані не загубляться: після відновлення зв'язку процес продовжить з того самого місця. Поки вузол наздоганяє, сторінки віддають уже зібрані дані, а розбіжність видно в панелі моніторингу.
Як розділяються доступи?
Читач лише дивиться, оператор бачить метрики та журнали без прав на запис у базу, адміністратор працює через окремий контур доступу. Облікові записи видаються поіменно, ключі ротуються, спільний логін не використовується.
Як оновлюється оглядач без втрати даних?
Компоненти оновлюються по черзі: спочатку веб-частина, потім індексатор. Зміни схеми бази застосовуються покроково, а попередній образ залишається доступним для відкату. Простій у момент перемикання вимірюється хвилинами.
Хто відповідає за резервні копії та безпеку?
Копії бази знімаються за розкладом і зберігаються окремо від робочого контуру, відновлення ми перевіряємо на порожньому стенді. Назовні відкрито лише веб-доступ через захищене з'єднання з обмеженням частоти запитів, панель адміністратора закрита списком адрес.
Що надіслати, щоб ми повернулися з планом та оцінкою
Щоб повернутися з планом та оцінкою, а не з уточнювальними питаннями, достатньо одного повідомлення з ввідними щодо мережі та інфраструктури. Нижче — мінімум, з якого ми збираємо схему розгортання та оцінку термінів щодо запуску оглядача на Blockscout під задачу.
- Параметри мережі: chain id, тип — власна EVM-мережа, rollup або sidechain, режим консенсусу, адреси системних контрактів.
- Доступ до вузлів: RPC- та WebSocket-ендпоінти архівного вузла, облікові дані, майданчик під оглядач та його обмеження.
- Навантаження та історія: кількість транзакцій на добу, глибина індексації — з нульового блоку чи з певної висоти, чи потрібні внутрішні транзакції та логи.
- Функціональність під задачу: верифікація контрактів, сторінки токенів і адрес, відкритий API, кастомний інтерфейс, ролі модератора — від цього залежить обсяг робіт.
- Поточний стан: чи працює оглядач зараз, чи потрібно переносити проіндексовану базу та зберігати старі адреси й посилання.
- Команда та доступи: хто передає вузли й доступи з вашого боку, хто приймає результат, у які вікна можна проводити роботи.
- Супровід: які події критичні, чи потрібні алерти та регламент оновлень для супроводу оглядача.
Із цього збирається план робіт з оглядача: етапи, схема розгортання, зона відповідальності кожної сторони та оцінка термінів із запасом на нестабільність мережі. Опишіть задачу в такому обсязі — повернемося з оцінкою та планом.
