Оновлення Pi Network v24.1 потрібно завершити до 2 червня; у разі пропуску буде роз’єднання з основною мережею

Pi Network у травні ввімкне оновлення протоколу 24.1, яке вимагає від усіх операторів нод завершити міграцію з v23.0 до v24.1 до дедлайну 2 червня; ноди, що пропустять дедлайн, можуть втратити підключення до Pi основної мережі й вимагатимуть повного повторного синхронізування, щоб знову приєднатися до мережі.

Інструкція з дій для оновлення v24.1: підтверджено три методи

Метод 1 (основний метод): Для користувачів Docker оновіть версію образу в docker-compose.yml на: pinetwork/pi-node-docker:organization_mainnet-v1.0-p24.1.0, а потім запустіть docker-compose up -d

Метод 2: Перезапустіть застосунок Pi Node у Pi Desktop (Windows / macOS); найновіша версія автоматично ініціює оновлення.

Метод 3: Linux Node CLI виконайте pi-node update-protocol, використайте watch pi-node status для моніторингу стану, і коли буде показано «已同步», заверште.

Єдиний надійний спосіб підтвердити завершення міграції: порівняйте значення ingest_latest_ledger у ноді (значення на curl). Коли обидва значення приблизно рівні, це означає, що міграцію завершено. Важливе застереження: під час міграції це значення не оновлюється поступово, а оновлюється один раз — після завершення міграції; значення, що залишається незмінним під час міграції, не означає, що міграція зазнала невдачі.

Чотири підтверджені ключові правила операцій

（来源：Pi Network）

Пакетне (порційне) оновлення: не оновлюйте одночасно всі ноди, виконуйте в кілька етапів; під час оновлення перенаправляйте трафік з нод, які оновлюються, на інші ноди або резервні ноди

Не запускати v25.1 або v26.0 самостійно: ці версії позначено як «請勿啟動», потрібно чекати офіційного сигналу запуску від головної команди Pi

2 червня — жорсткий дедлайн: час міграції не більше 5 хвилин; головна команда Pi радить завершити якнайшвидше, а не чекати останнього моменту

Потрібно підтвердити завершення через endpoint на стороні книги (ledger): не припускайте, що міграцію завершено лише через перезапуск ноди; обов’язково порівняйте ingest_latest_ledger

Поширені запитання

Яка логіка проєктування послідовності оновлення Pi Network від v19 до v26 і чому кожен крок є обов’язковим?

Послідовність оновлення Pi Network — лінійно залежне проєктування: кожна нова версія будується поверх попередньої, тож неможливо пропустити крок. Такий підхід гарантує, що вся мережа на будь-який момент зберігає узгоджену версію протоколу, запобігаючи ситуаціям, коли ноди не можуть ефективно взаємодіяти через відмінності у версіях. Чим більше нод у мережі ще працюють зі старою версією, тим повільніше відбувається повне розгортання нових функцій у всій мережі. Тому примусові дедлайни мають на меті забезпечити швидкий перехід усієї мережі на наступну версію. v23.0 — найскладніший крок у цій послідовності: він одночасно оновлює операційну систему й базу даних; v24.1 рухається далі на цій основі, інтегруючи нові версії Stellar-Core і Horizon.

Після оновлення протоколу головної мережі Pi до v24.1 чи буде активовано функції смартконтрактів і dApp?

Ні. Головна команда Pi чітко підтвердила, що активацію смартконтрактів і децентралізованих застосунків (dApp) у головній мережі Pi офіційно ще не оголошено. Протокол 23.0 узгоджує Pi зі Stellar Core v23, який на технічному рівні закладає базову рамку для цих функцій; v24.1 додатково інтегрує Stellar-Core v24.1.0, продовжуючи цей технічний напрям. Водночас активація смартконтрактів і dApp — це окреме офіційне рішення, яке має ухвалити головна команда Pi, і воно є незалежною подією від оновлення версії протоколу. Наразі послідовність оновлень здебільшого зосереджена на стабільності інфраструктури та оптимізації продуктивності.

Якщо оператори нод зіткнулися з проблемами під час оновлення v23.0, чи буде складність міграції v24.1 такою ж високою?

Згідно з підтвердженням головної команди Pi, v24.1 є стандартною внутрішньою міграцією даних, яка має принципові відмінності від v23.0: v23.0 потребує одночасного виконання оновлення операційної системи (Ubuntu 20→24), оновлення бази даних (PostgreSQL 12→16) і міграції протоколу; через те, що це пов’язано з переписуванням файлів бази даних, потрібно завчасно зробити резервні копії для профілактики, а час запуску довший; v24.1 — це лише внутрішня міграція даних без переписування файлів бази даних, тому спеціальні кроки з резервним копіюванням не потрібні. У більшості випадків міграція триває не довше 5 хвилин, а швидкість перезапуску значно вища, ніж у v23.0. Складність оновлення v23.0 головно пов’язана з багаторівневістю синхронізованих оновлень, тоді як v24.1 не має такої ж складності.