Pi Network повідомила операторам вузлів про необхідність встановити програмне забезпечення Protocol 28 до 13 жовтня напередодні запланованого оновлення Mainnet 16 жовтня. Дедлайн залишився позаду мережі; активація ще попереду. Нагальне питання полягає в тому, чи готові вузли-учасники та що користувачі й розробники фактично зможуть робити після зміни, адже ні дедлайн, ні номер протоколу не є мірою використання застосунків.
Summary
- Pi повідомила всім операторам вузлів Mainnet про необхідність оновитися до Protocol 28 до 13 жовтня 2026 року.
- Мережа запланувала активацію Protocol 28 на 16 жовтня за умови завершення розгортання.
- Pi заявляє, що випуск покращує обробку відкладених транзакцій та групові оновлення смарт-контрактів.
- Protocol 27 вже працює в Mainnet, тоді як Protocol 28 тестувався в Testnet перед дедлайном для вузлів.
- Pi не опублікувала кількість відповідних вимогам вузлів або результат використання застосунків для Protocol 28.
Інструкції Pi Node вказують кожному вузлу Mainnet перейти на версію 28. Публічне оголошення Pi повідомляє, що зміна покращує те, як мережа обробляє затримки в даних транзакцій, і дозволяє розробникам безпечніше оновлювати групи смарт-контрактів і збережених даних. Обидва твердження стосуються інфраструктури. Жодне з них не говорить про те, що запущено конкретний застосунок, що платіж користувача зріс або що стейблкоїн запрацює в п’ятницю.
Crypto.news вже розглядала ціну PI напередодні оновлення та запропонований зв’язок з OUSD. Корисніше питання сьогодні стосується самого ланцюга: які докази показали б, що встановлене програмне забезпечення активувалося як задумано, і що залишається залежним від розробників і користувачів після цього моменту?
Дедлайн для вузла — це не дата активації
Дедлайн для оператора вузла вимагає від комп’ютерів, що беруть участь у мережі, встановити сумісне програмне забезпечення. Активація протоколу змінює те, яких правил дотримується Mainnet. Це окремі події, навіть якщо обидві відбуваються в межах однієї послідовності оновлення. Оголошення Pi встановило 13 жовтня для оновлень вузлів і 16 жовтня для зміни протоколу Mainnet. Пропущений дедлайн оператора сам по собі не означає, що вся мережа зазнала невдачі; результат залежить від участі валідаторів і від того, як мережа поводиться з несумісними серверами.
Проєкт повідомив про успішне оновлення Protocol 27 у Mainnet перед тим, як перевести Protocol 28 у Testnet. Оновлення в Testnet показує, що запропоноване програмне забезпечення можна випробувати в тестовому середовищі. Активація в Mainnet включає живий реєстр, живі транзакції та операторів, які підтримують консенсус із сумісними версіями. Подія 16 жовтня потребує незалежного підтвердження після її настання. Писати сьогодні так, ніби вона вже відбулася, означало б змішувати розклад із розгортанням.
Публічна сторінка вузлів Pi не наводить датованої, перевірюваної цифри щодо частки валідаторів Mainnet, які працюють на v28, на момент підготовки цієї статті. Це унеможливлює обґрунтоване твердження у відсотках про відповідність вимогам. Оператор може завантажити програмне забезпечення, не запускаючи його, а публічна кількість завантажень для настільних комп’ютерів не довела б участі валідаторів. Корисними доказами були б розподіл версій серед активних консенсусних вузлів, голосування за оновлення або стан активації, а також продовження виробництва реєстру після перемикання.
Оновлення вузла може вимагати дій від людей, які не створюють застосунків. Валідатор на застарілому протоколі може втратити здатність залишатися синхронізованим із мережею після активації нових правил транзакцій. Масштаб будь-яких збоїв доведеться спостерігати, а не припускати. Сторінки статусу, поточні версії реєстру, повідомлення операторів вузлів і тестові транзакції розробників можуть надати різні частини відповіді.
Що Protocol 28 заявляє про зміни
Pi описує три покращення у своєму публічному оголошенні: обробка затримок у даних транзакцій, оновлення груп смарт-контрактів разом і безпечніша зміна збережених даних контрактів у міру розвитку застосунків. Оголошення не публікує еталон продуктивності, відсоток зниження комісій чи список продакшн-контрактів, що використовують нові функції. Тому опис випуску як автоматичного стрибка в транзакціях за секунду вигадав би результат продуктивності.
Затримка даних транзакцій може створити проблему координації для реєстру, якщо сервери мають різні уявлення про інформацію, потрібну для обробки набору операцій. Програмне забезпечення, яке надійніше обробляє такі затримки, може зменшити уникненні збої та підвищити стійкість. Щоб показати фактичне покращення в Mainnet, розробнику знадобилися б датовані вимірювання до і після: невдалі транзакції відповідного типу, час їх включення або відтворюваний тест, який перевіряє нову поведінку. Лише журнал змін описує передбачувану можливість.
Групові оновлення корисні для застосунків, що складаються з кількох взаємозалежних контрактів. Розглянемо платіжний застосунок, де один контракт записує баланси, а інший забезпечує дозволи. Оновлення лише одного за раз може створити період, коли версії не узгоджуються. Операція, яка оновлює групу разом, могла б зменшити цю невідповідність. Вона не робить жоден окремий контракт безпечним сама по собі; розробники все ще повинні вказати правильну логіку, перевірити шляхи міграції та протестувати, що станеться, якщо виконання зазнає невдачі.
Збережені дані порушують окреме питання міграції. Коли застосунок змінює свою структуру, існуючі баланси користувачів, дозволи та інші записи повинні залишатися інтерпретованими за новим кодом. Безпечніший механізм оновлення може допомогти координувати цю зміну. Помилка в новому контракті розробника або помилка в тому, як перетворюються записи, все ще може пошкодити застосунок. Підтримка на рівні протоколу — це інструмент, а не аудит кожного проєкту, який його використовує.
Історія смарт-контрактів почалася до версії 28
Висвітлення Protocol 27 від Pi описувало можливості розробників попереднього оновлення та відстань між великою заявленою базою користувачів і спостережуваним використанням децентралізованих фінансів. Protocol 28 є продовженням шляху програмного забезпечення, а не першим моментом, коли смарт-контракти стають можливими в мережі. Його конкретні доповнення слід вимірювати відносно Protocol 27, а не відносно вигаданої мережі без попередніх інструментів для розробників.
Випуск RPC для розробників надав спосіб для застосунків взаємодіяти з інфраструктурою Testnet Pi. Документація, кінцеві точки та оновлення протоколу знижують бар'єри для розробників, але вони не доводять розгортання чи використання в Mainnet. Застосунок може бути вказаний без значущих транзакцій. Контракт може бути розгорнутий без активних користувачів. Лічильник транзакцій може зростати через автоматизовані тести. Кожне число відповідає на інше питання.
Корисний реєстр впровадження фіксував би активні контракти Mainnet, створені з використанням нової можливості, транзакції, які їх викликали, унікальні гаманці-учасники та економічну цінність або надану послугу. Навіть ці показники потребують обережності. Одна людина може контролювати багато гаманців; один популярний застосунок може становити більшість активності; показник вартості може включати перекази між рахунками, що належать одному розробнику. Незалежні назви застосунків і відтворювані адреси в блокчейні зробили б докази переконливішими.
Дорожня карта на 2026 рік містить інші етапи. KYC і міграція визначають, які Піонери можуть використовувати баланси Mainnet. Виявлення застосунків визначає, чи знаходять користувачі чим зайнятися. Прийняття продавцями або корисний споживчий застосунок визначає, чи мають користувачі причину витрачати. Протокол 28 може покращити основу, тоді як усі три залишаються вузькими місцями. Оновлення слід оцінювати спочатку за його технічними заявами, а потім окремо за будь-яким подальшим попитом.
Партнерство щодо стейблкоїна не є частиною переходу 16 жовтня
Заява Pi щодо стейблкоїнів від 8 жовтня описує роботу з Open Standard, групою, що стоїть за OUSD, і зазначає, що проєкт досліджуватиме винагороди та інші екосистемні застосування. Компанія не надала підтвердженої дати запуску OUSD на Pi і не заявила, що активація Протоколу 28 зробить продукт OUSD доступним. Об’єднання цих оголошень в єдиний запуск 16 жовтня було б необґрунтованим.
Стейблкоїни можуть полегшити ціноутворення платежу, коли продавці та споживачі не хочуть, щоб сума рахунку змінювалася разом із ринковою вартістю PI. Pi заявляє, що PI залишається нативною криптовалютою екосистеми. Чи генерують витрати в доларах попит на PI, залежить від остаточної реалізації: комісій за транзакції, стимулів для застосунків, маршрутів ліквідності, фінансування винагород і будь-якої вимоги утримувати PI. Жодна опублікована специфікація продукту не визначає ці потоки.
Розробник міг би створити застосунок після Протоколу 28, який використовує PI безпосередньо, стейблкоїн або обидва. Саме оновлення мережі не обирає бізнес-модель. Застосунок із ціноутворенням у доларах і розрахунками у стейблкоїнах міг би використовувати PI для невеликої мережевої комісії, тоді як застосунок, що винагороджує користувачів у PI, міг би створити більшу пряму активність. Це умовні приклади, а не описи розгорнутих сервісів.
Ця відмінність важлива для звітності про ціну. Успішне перемикання протоколу є позитивним доказом координації операторів і розгортання коду. Це не те саме, що виміряне зростання покупок токенів, стійких користувачів або продавців, які приймають PI. Нещодавня звітність про ціну вже пов’язувала обговорення OUSD і графік оновлення з слабким ринком. Повторення цього зіставлення без нових даних про попит додало б мало.
Що довела б успішна п’ятниця
Якщо Pi підтвердить активацію 16 жовтня і оглядачі блоків покажуть подальші реєстри Mainnet, що використовують новий протокол, це встановило б запланований перехід програмного забезпечення. Продовження роботи мережі та сумісність вузлів підтвердили б висновок, що оновлення не порушило помітно консенсус. Опублікований тест конкретної затримки транзакцій або згрупованих функцій оновлення показав би більше, ніж сама лише мітка версії.
Жоден окремий скриншот не доводить усього цього. Оглядач блоків може відображати версії реєстру, але не обов’язково те, чи є складні міграції контрактів безпечними. Демонстрація розробника може показати один застосунок, що працює правильно, не доводячи широкого впровадження. Оголошення команди може повідомити про завершення, не надаючи незалежних підрахунків вузлів або невдалих транзакцій. Найкращий звіт поєднує ці джерела та визначає, де твердження залишається самозвітним.
Протилежний аргумент прямолінійний. Покращення інфраструктури можуть бути цінними навіть до того, як користувачі їх помітять. Команди, що створюють платежі або ігри, часто потребують передбачуваних інструментів оновлення, перш ніж зобов’язувати реальні баланси, і публічне використання може з’явитися через тижні або місяці. Оцінювання технічного релізу лише за ціною токена того ж дня або вартістю DeFi пропустило б його призначену роль. Цей аргумент виправдовує терпіння, але він також вимагає майбутньої віхи, яку можна перевірити.
Функція зворотногожурналу KYC документувала окремі шлюзи доступу та використання. Pi роками просувала велику спільноту. Її оновлення щодо KYC та міграції показують, що доступ до Mainnet все ще є процесом для деяких користувачів. Заявлена аудиторія не є списком активних користувачів смарт-контрактів. Практичний тест після активації полягає в тому, чи можуть додатки працювати надійно для користувачів з перенесеними балансами і чи повертаються ці користувачі після початкового просування.
Що залишається невідомим сьогодні
Кінцевий термін оператора не супроводжується публічною таблицею відповідності, активація залишається запланованою, і жоден ідентифікований додаток Mainnet ще не продемонстрував покращення до і після, яке можна було б віднести до версії 28 у розглянутих матеріалах. Це обмеження на те, що можна повідомити 14 жовтня. Вони не означають, що оновлення не вдалося; вони означають, що виміряний результат ще очікується.
Потенційний додаток може використовувати групові оновлення контрактів, не роблячи цей факт легко видимим із звичайного потоку транзакцій. Розробники можуть публікувати адреси контрактів, код та записи про міграцію. Проєкт може публікувати статистику впровадження версій та журнали інцидентів. Без таких розкриттів сторонні можуть перевірити деяку поведінку реєстру, але деталі реалізації залишаються невизначеними.
Ціна та корисність залишаються окремими. Торгові desks можуть передбачати заплановане оновлення та рухатися до активації, тоді як користувачам може знадобитися набагато більше часу, щоб впровадити додаток. Ні ринкова реакція, ні анонс оновлення не відповідають на питання, чи створили нові інструменти економічно корисну послугу. Стаття про Протокол 28 повинна залишати це питання відкритим, поки не з'являться дані.
План відкату виявив би операційні ставки
Запланована зміна протоколу повинна мати процедуру для операторів, які залишаються на старому програмному забезпеченні, та для розробників, чиї транзакції поводяться по-іншому після активації. Pi встановила кінцевий термін оновлення, але публічне оголошення не роз'яснює поріг живої мережі для продовження, правило відстрочки або процедуру відкату. Висвітлення цих деталей вимагало б поточного технічного повідомлення або відповідей від команди. Спекулятивне твердження, що один пізній оператор міг би зупинити Mainnet, не було б виправданим.
Операторів можна розділити на кілька груп. Машина може запускати правильний бінарний файл, але не бути активним учасником консенсусу. Інша може бути активною, але не мати недавньої історії реєстру, оскільки втратила зв'язок. Третя може обробляти реєстри, обслуговуючи застарілу інформацію через кінцеву точку додатка. Один відсоток, позначений як «вузли оновлено», може приховати ці відмінності. Підрахунки версій потребують визначення, які машини та функції вони охоплюють.
Після активації розробники повинні перевірити повний шлях транзакції: подання виклику, отримання результату, перевірку остаточності реєстру та читання оновленого стану контракту через свій додаток. Якщо групове оновлення змінює кілька контрактів, тест повинен перевіряти як успішне виконання, так і обробку помилок. Додаток, який відображає правильний номер версії, але показує застарілий баланс, все одно матиме проблему для користувача.
Тимчасова пауза для виправлення проблеми була б свідченням операційного рішення, а не автоматичним доказом того, що початковий дизайн не вдався. І навпаки, оголошення про те, що мережа залишалася онлайн, не встановило б, що кожна міграція зберегла правильні дані додатка. Публічний журнал інцидентів із зазначенням постраждалих версій, реєстрів та засобів виправлення дозволив би користувачам відрізнити звичайну проблему оновлення вузла від дефекту в новій функції.
Кінцевий термін і запланована активація забезпечують вузьке вікно звітності для цих перевірок. Результат 16 жовтня слід описати зі статусом на той час, і будь-які заяви додатків повинні ідентифікувати конкретні транзакції Mainnet, які їх підтверджують.
За чим стежити
- Активація 16 жовтня: Підтвердьте версію протоколу Mainnet через датоване повідомлення проєкту та незалежні спостереження за реєстром.
- Активні версії вузлів: Шукайте підтверджуваний розподіл консенсусних вузлів на протоколі 28 після оновлення.
- Демонстрації функцій: Перевіряйте адреси контрактів і відтворювані транзакції з використанням групових оновлень або змін збережених даних.
- Безперервність мережі: Відстежуйте зупинені реєстри, невдалі транзакції або екстрені виправлення під час активації.
- Використання застосунків: Порівнюйте названі застосунки, активні гаманці та економічно значущі транзакції після розгортання.
Часті запитання
Коли був крайній термін для вузлів Pi на протоколі 28?
Pi повідомила операторам вузлів Mainnet про необхідність оновлення до 13 жовтня 2026 року. Окрему активацію Mainnet було заплановано на 16 жовтня.
Чи вже працює протокол 28 у Mainnet?
Станом на дату написання 14 жовтня активація Mainnet залишається запланованою на 16 жовтня. Раніше Pi перенесла протокол 28 на Testnet.
Що змінює протокол 28?
Pi заявляє, що він покращує обробку даних відкладених транзакцій і надає розробникам безпечніші способи оновлювати групи контрактів і змінювати збережені дані. В оголошенні не було опубліковано кількісного покращення швидкості чи комісій.
Чи всі вузли Pi дотрималися крайнього терміну?
У розглянутих матеріалах не було доступного публічного, перевіряемого відсотка відповідності. Сама лише загальна кількість завантажень програмного забезпечення не довела б, що активні вузли працюють на новій версії.
Чи запускає оновлення OUSD на Pi?
Такий запуск не підтверджено. Партнерство Pi з OUSD є дослідницьким, і в публічній заяві немає дати запуску продукту, пов’язаної з протоколом 28.
Чи підвищить оновлення ціну PI?
Випуск протоколу не визначає ціну токена. Докази сталого використання застосунків і фактичного попиту вимагали б окремих даних після активації.
Що довело б, що нові інструменти для контрактів працюють?
Названий застосунок Mainnet міг би опублікувати адреси контрактів і відтворювані транзакції, що демонструють скоординоване оновлення та збережений стан. Незалежний огляд посилив би це твердження.
Чому важлива участь вузлів?
Сумісні вузли потрібні для дотримання оновлених правил реєстру. Спостережуване впровадження версій і безперебійне виробництво реєстру будуть більш інформативними, ніж сам крайній термін. Це освітній аналіз, а не інвестиційна порада.
