Pearl 1.5.7 додає моніторинг вузла й усуває збій синхронізації тестової мережі
Публікація джерела: 2026-11-12 · Редакційний аналіз опубліковано: 2026-11-13
Реліз від 12 листопада додає необов’язкові метрики вузла й посилює обробку мережевих повідомлень. Зміна перевірки доказів стосується тестової мережі.
Оновлення для власників вузлів і пулів
12 листопада Pearl Research Labs випустила v1.5.7. У версії з’явився моніторинг вузла, покращено обробку повідомлень від інших вузлів і виправлено збій початкової синхронізації тестової мережі. Вузол перевіряє й передає блоки, а програма майнінгу виконує обчислення для їх пошуку. Якщо пул готує завдання на власному вузлі, його стан важливий навіть тоді, коли всі майнери показують звичну швидкість.
Нотатки релізу описують зміни вузла й тестової мережі. Запропонований перехід на FP8 в основній мережі тут не ввімкнули й нових вимог до відеокарт не оголосили. Якщо ви майните через пул, стежте за його окремими інструкціями про сумісність. Якщо ж запускаєте вузол, який дає пулу роботу, оновлення змінює способи спостереження за ним і його обслуговування.
Записуйте дві версії. Версія pearld показує, яка програма перевіряла блоки, а версія майнера — яка створювала доказ. Обидва записи потрібні для діагностики пулу. Оновлення вузла може спростити спостереження або зменшити збої без змін в обчисленнях відеокарти.
Що можна побачити в показниках
Програма вузла pearld тепер може передавати показники до Prometheus — системи, що регулярно збирає вимірювання. Серед них висота й час останнього блока, з’єднання з іншими вузлами, час обробки блоків і запити до вузла. Ці дані можна порівнювати за часом. Якщо майнери працюють зі звичною швидкістю, а вузол відстає від незалежного джерела, спочатку перевірте сам вузол і його з’єднання.
Інтерфейс показників вимкнений, доки його явно не ввімкнуть, і не має власної автентифікації. Залиште його на самому сервері або в приватній мережі моніторингу, доступній лише збирачу. Налаштовувати сповіщення простіше, коли ви вже знаєте, як показники поводяться зазвичай. Мала кількість сусідів чи один повільний запит — зачіпка. Самі по собі вони не показують, що пул перестав видавати актуальні завдання.
Наприклад, порівняйте час, коли вузол отримав останній блок, із часом, коли пул видав наступне завдання. Якщо незалежний вузол уже просунувся, а ваш бачить стару висоту, почніть із цього. Якщо ваш вузол бачить новий блок, а майнери отримують старі завдання, перевірте зв’язок між вузлом і пулом. Для кожної події потрібен свій запис.
Є також показник часу обробки блока. Вузол може повільно обробити один блок, але потім наздогнати мережу. Сповіщення про тривале відставання разом з іншими ознаками дасть більше, ніж повідомлення про один повільний блок. Обирайте ознаки, які справді заважають роботі пулу.
Чому зупинялася синхронізація тестової мережі
Розробники описали блоки 36 761 і 36 762, у яких сертифікати майнінгу мали ранг 64. Ранг — параметр у правилах перевірки доказу. Старий розклад тестової мережі вимагав щонайменше 128 уже з першого з цих блоків. Новий вузол відхиляв блок 36 761, а тоді знову його запитував. У v1.5.7 вимога починає діяти з блока 36 763. Тепер синхронізація може пройти два попередні блоки, а далі мінімум зберігається.
Виправлення стосується відповідної тестової мережі й не змінює правил доказу в основному ланцюгу. Пул, який перевіряє нову збірку, може запустити тестовий вузол з нуля і подивитися, чи той проходить обидва блоки. Така перевірка покаже, чи виправлено синхронізацію. Про дохід відеокарти в основній мережі вона нічого не каже.
Розробники також повідомили, що перевірили історичні заголовки блоків із новими параметрами тестової мережі. Це доказ щодо конкретної помилки перевірки. Якщо тестова установка далі зупиняється в іншому місці, запишіть останню прийняту висоту й версію. Інша зупинка може мати іншу причину, а зміна тестового правила не вимагає міняти обладнання в основній мережі.
Що перевірити після оновлення
Реліз також обмежує обсяг пам’яті, який окремі повідомлення можуть змусити вузол виділити до отримання даних. Він стримує частину запитів від ненадійних сусідів і більше не використовує їхні позначки часу для зміщення часу вузла. Ці зміни стосуються зовнішнього трафіку. Після оновлення перевірте обидва боки: чи вузол далі отримує блоки і чи пул дає свіжі завдання та приймає роботу.
Перед змінами запишіть попередню версію й налаштування. Звірте джерело релізу та версію, яка справді запущена. Панель допоможе знайти, де почалася зупинка. Незалежне джерело висоти блока й дані про прийняту роботу покажуть, чи збій дійшов до майнерів.
Для перевірки розгортання зніміть показники до й після зміни за схожих умов. Звірте, чи росте висота блока, чи є з’єднання з іншими вузлами і чи пул далі приймає роботу. Якщо один етап зупиниться першим, збережіть його журнал за цей час. Так буде легше відтворити збій, не приймаючи короткі коливання за відмову.
Джерело: Pearl Research Labs ↗ · Pearl — metrics implementation ↗ · Pearl — testnet sync fix ↗ · Pearl — network security changes ↗
Калькулятор майнінгу ↗
