Solana обіцяла швидшу фінальність. Тепер валідатори мають довести, що це працює

Alpenglow проходить через тестові мережі Solana, тоді як mainnet все ще покладається на свій існуючий консенсус. Запропонована зміна змінить те, як валідатори погоджуються, що блок є фінальним. Ціль у 150 мілісекунд є заявою про продуктивність за певних умов, а не обіцянкою, що кожен платіж користувача обробляється за цей час.

Найважливіша зміна консенсусу Solana проходить через послідовність тестів валідаторів. Трекер функціональних шлюзів Anza перелічує SIMD-0326, Alpenglow, серед тих, що очікують активації в mainnet. Він фіксує позиції активації в testnet і devnet та визначає Agave 4.3.0 як версію програмного забезпечення, пов’язану з цією функцією. Нижня межа версії mainnet, показана в тому самому знімку, становила 4.2.2, а 4.3.0 указана як наступна очікувана межа. Запланована нижня межа версії та активна функція консенсусу — це різні етапи.

Раніший звіт про testnet описував перехід до ширшого тестування валідаторами. Пізніший звіт про devnet відзначив обидві тестові мережі, тоді як mainnet продовжував працювати з поточним консенсусом. Це той статус, за яким слід оцінювати будь-яке обіцяне підвищення швидкості.

28 вересня було календарною пасткою

Один запис у розкладі говорив, що активації функцій у mainnet відновляться 28 вересня. У ньому не йшлося, що сам Alpenglow увімкнеться того дня. Трекер окремо називає Alpenglow таким, що очікує. Сприйняття дати відновлення черги функціональних шлюзів як запланованого переходу протоколу перетворило маркер процесу на хибний дедлайн. Виправлення від 29 вересня простежило цю плутанину й зазначило, що Anza відкинула заявлену дату запуску.

Ця різниця є суттєвою. Валідатори можуть прийняти випуск програмного забезпечення, що містить неактивний код, без активації функції. Нижня межа версії може піднятися після проходження порогу частки та епох. Окремий функціональний шлюз може увімкнути нову поведінку. Користувачі, які бачать зміну номера версії на панелі, не обов’язково побачили, що швидший протокол фінальності запрацював.

Правильний новинний привід полягає в тому, що процес тестування й активації все ще відкритий після широко розповсюдженої дати. Остаточне вікно mainnet вимагає явного розкладу, підготовки операторів і доказів із публічного тестування. Жоден із цих кроків не замінюється соціальним постом, який описує оновлення як неминуче.

Votor змінює голосування, тоді як Rotor чекає

Пропозиція SIMD-0326 визначає початковий крок переважно навколо Votor, нового механізму консенсусу. Вона явно залишає Rotor, запропоновану заміну розповсюдження даних, для окремої зміни й початково зберігає існуюче розповсюдження Turbine. Маркетингові описи повного стеку Alpenglow можуть розмивати цю сферу застосування.

Консенсус відповідає на питання, коли достатньо валідаторів погодили блок, щоб його слід було вважати фінальним за протоколом. Розповсюдження даних відповідає на питання, як блок досягає цих валідаторів. Виконання відповідає на питання, чи транзакція успішно виконалася. Застосунок також чекає, поки його постачальник RPC повідомить результат. Швидше голосування не може усунути всі інші затримки на цьому шляху.

Показник у 150 мілісекунд найкраще читати як цільову метрику фінальності за сприятливих мережевих умов, виміряну на рівні консенсусу. Це не наскрізний час оформлення замовлення для користувача, чий гаманець має підписати, надіслати, досягти лідера, бути включеним у блок, виконатися та повернутися через RPC-сервіс. Корисний публічний бенчмарк має називати свої початкову та кінцеву точки. Секундомір, запущений на етапі пропозиції блоку, не можна порівнювати з тим, що запущений, коли клієнт натискає «Надіслати».

Пропозиція замінює схему голосування на інший компроміс між безпекою та живучістю. Вона описує модель «20 плюс 20», яка може витримати ворожу частку та окрему частку, що не відповідає, за заявлених припущень. Автори явно зазначають, що однораундове голосування не забезпечує той самий 33% поріг візантійської стійкості, досяжний за двораундових схем. Це визнання має стояти поруч із заявою про швидкість, а не в виносці.

Двоколонковий тест запобігає оманливому бенчмарку

Одна колонка має вимірювати фінальність протоколу з погляду валідатора: час від запропонованого блоку до сертифіката фіналізації, включно з розподілом повільних результатів. Друга має вимірювати підтверджену транзакцію користувача: подання через виконання, включення, фінальність і відповідь RPC. Різниця між цими колонками — це робота, яку заголовний показник консенсусу не вимірює.

Припустімо, тест повідомляє 150 мілісекунд для фіналізації після пропозиції, але включення транзакції чекає один слот у 350 мілісекунд, а доставка через RPC займає ще 100 мілісекунд. За цих ілюстративних припущень клієнт бачить щонайменше 600 мілісекунд, ще до додавання підписування чи повторних спроб. Розрахунок такий: 350 плюс 150 плюс 100. Це гіпотетичні тайминги, а не вимірювання Alpenglow у продакшені. Вони показують, чому показник консенсусу менше секунди не обов’язково означає досвід платежу менше секунди.

Медіанна затримка може приховувати випадки, які оператори цінують найбільше. Валідатор, застряглий за поганим мережевим маршрутом, тимчасовим розділенням, відсутнім голосом або важкою роботою з відтворення, може бачити довгий хвіст. Біржі та платіжні провайдери зазвичай будують політики фінальності для рідкісних поганих умов, а не лише для медіани бенчмарку. Достовірне впровадження публікувало б результати за перцентилями, поведінку відновлення та наслідки невдалих лідерів.

Пропозиція щодо часу слоту — ще одна змінна. Вона прагне поетапного скорочення з цільових 400 мілісекунд до 200 мілісекунд. Інтервал слоту та фінальність пов’язані, але різні; твердження, що кожен коротший слот доводить роботу Votor, змішує два оновлення. Раніший тестовий акаунт валідатора слідував за тестуванням протоколу перед цим ширшим розгортанням.

Валідатори мають тестувати випадки відмов

Успішний шлях мережі — це найлегше середовище для отримання швидкого показника. Кандидат для мейннету має витримати валідаторів, що приєднуються пізно, повідомлення із затримкою між регіонами, перезапуски програмного забезпечення, відмови лідерів і конфліктні погляди на ланцюг. Пропозиція щодо міграції Alpenglow стосується передачі від старого стану голосування до нового. Коректний протокол у стабільному стані все ще може бути викритий поганим переходом.

Тести мають показати, чи кластер досягає одного узгодженого остаточного рішення після відновлення розділення, як швидко він відновлюється, якщо значна частка стейку виходить офлайн, і чи вузли з різними сумісними версіями повідомляють однаковий результат. Тестнет цінний тим, що валідатори з різною інфраструктурою стикаються з умовами, які контрольована лабораторія може пропустити. Він не може точно відтворити економічні стимули та трафік живої мережі.

Суміш клієнтів має значення. Трекер Anza позначив Firedancer і Frankendancer як непідтримувані для рядка Alpenglow у спостережуваному знімку. Це статус сумісності в конкретному розкладі, а не постійне твердження про будь-який із клієнтів. Продакшн-міграція має враховувати стейк, що працює на кожній реалізації, або вказати, що цим операторам потрібно змінити.

Стимули валідаторів також є частиною тесту. Запуск нового протоколу голосування може змінити пропускну здатність, вимоги до обладнання та витрати на участь. Якщо менші оператори вибувають, бо не можуть виконати вимоги, швидша мережа може отримати менше незалежних учасників. Фактична кількість операторів і розподіл стейку після активації перевірили б цей компроміс.

Швидкий сертифікат і повільний сертифікат обслуговують різні умови

Протокол не залежить від того, що один маршрут завжди завершується за 150 мілісекунд. SIMD-0326 визначає швидку фіналізацію, коли валідатори, які представляють 80% стейку, нотаризують блок за один раунд. Його повільніший маршрут покладається на два раунди за участю 60% стейку та як сертифікатів нотаризації, так і сертифікатів фіналізації. Лідер може не встигнути надати валідний блок вчасно, і в такому разі валідатори можуть проголосувати за пропуск цього слота. Дизайн включає сертифікати для пропущених слотів і резервний шлях. Заголовковий бенчмарк, який вимірює лише швидкий маршрут на 80%, опустив би саме ті ситуації, які роблять фінальність цінною.

Цю відмінність можна перевірити практично. Для кожного запропонованого слота протягом дня підрахуйте частку, фіналізовану швидким сертифікатом, частку, що використовує повільніший шлях, і частку пропущених. Наведіть медіану та 95-й і 99-й процентилі окремо для кожного класу. Швидка медіана корисна, але оператору потрібно знати, як часто мережа залишає швидкий шлях і скільки часу потім потрібно для відновлення. Платіжний сервіс, що обробляє тисячі квитанцій на день, може зазнати події з довгим хвостом, навіть якщо ця подія рідкісна для окремого переказу.

Сертифікат — це компактний, верифікований запис згоди, зваженої за стейком. Це не голосування фіксованої кількості машин. Десять малих валідаторів не можуть замінити одного валідатора, який представляє велику кількість стейку, лише завдяки чисельній перевазі. Тому звітування про кількість валідаторів без розподілу стейку спотворило б перевірку безпеки. Правильні цифри — це стейк, що бере участь у кожному раунді, стейк, що офлайн, і стейк, що не погоджується. Ці цифри потребують часових міток, оскільки призначення стейку та доступність операторів змінюються.

Пропозиція стверджує, що безпосередньо фіналізований блок також вирішує долю своїх предків: попередні блоки в його ланцюгу стають фіналізованими, а пропущені слоти вважаються пропущеними. Це означає, що дашборд може показувати прибуття фінальності групами після повільного періоду. Вимірювання, яке усереднює очевидний час завершення цих предків в одне привабливе число, було б важко порівняти з користувачем, який чекав протягом паузи. Тест має зберігати початковий час пропозиції кожного блоку та час спостереження сертифіката.

Автори протоколу не заявляють про той самий поріг зловмисності, що й кожен конкуруючий дизайн. Їхнє формулювання «20 плюс 20» приймає інший баланс між візантійськими збоями та нечутливим стейком в обмін на коротший нормальний шлях. Чи є цей компроміс прийнятним — це управлінське рішення, поінформоване моделюванням загроз і доказами продуктивності, а не питання, яке вирішується єдиною демонстрацією найшвидшого випадку. Незвично відвертий розділ про безпеку в SIMD-0326 дає змогу повідомити про цей компроміс, не приписуючи мотивів жодній зі сторін.

Перемикання консенсусу вимагає спільного початкового блоку

Документ про міграцію розглядає проблему, яку не може показати графік швидкості. Старий і новий консенсус не можуть безпечно працювати як незалежні історії після переходу. Валідатори повинні погодити останній старий блок, який стає батьківським для першого блоку Alpenglow. Документ називає цю спільну точку генезисним блоком Alpenglow. Якщо оператори не погодяться щодо неї, їхні подальші сертифікати фінальності посилатимуться на несумісні історії.

Запропонована передача починається після слота активації функції, але межа, що використовується для міграції, знаходиться на 5000 слотів пізніше. Додатковий інтервал покликаний уникнути початку епохи. Потім процес чекає на блок, що відповідає умові сильної оптимістичної конфірмації, з голосами, що представляють щонайменше 82% стейку у визначеному пропозицією шаблоні. Валідатори підписують генезисний голос за спільного предка-блок. 82% генезисний сертифікат дає їм докази для перемикання. Арифметика цих порогів є частиною дизайну міграції, окремо від швидкого маршруту фіналізації Votor на 80% після перемикання.

Валідатор, який отримує генезисний сертифікат, перевіряє його підписи за BLS-ключами відповідної епохи та транслює його. План потім ініціалізує Votor від вибраного блоку та зупиняє TowerBFT для пізніших слотів. Він відкочує блоки після вибраної генезисної точки та скидає пов’язаний стан перед обробкою нових блоків. Документ стверджує, що цей відкат безпечний, оскільки користувацькі транзакції не запаковані в ці проміжні блоки. Це твердження заслуговує на перевірку на реальному кластері; це не те, що оператор застосунку може перевірити лише з заголовка про фінальність.

Вузол може бути офлайн під час передачі. Документ описує, як валідатор, що повертається, може дізнатися генезисний сертифікат зі снепшоту або наздогнати після спостереження валідного сертифіката фіналізації Alpenglow. Саме тут інженерія релізів зустрічається з теорією консенсусу. Якщо пізній вузол неправильно інтерпретує перехід, він може подавати застарілі або неузгоджені дані, навіть коли більшість кластера продовжує роботу. Біржі та постачальники RPC повинні відпрацьовувати сценарії перезапуску та відновлення зі снепшотів, а не лише спостерігати за успішним початковим переходом.

Існує явна ціна за живучість. Пропозиція міграції зазначає, що передача може перервати прогрес, оптимістично на один слот за межами. Очікування в один слот не є максимальною гарантією рівня обслуговування. Публічний постмортем після активації має вказати, скільки слотів було пропущено, чи призупинилося пакування користувацьких транзакцій і скільки часу знадобилося зовнішнім сервісам для відновлення нормального звітування про підтвердження. Швидкий стабільний стан не може зробити інтервал переходу невидимим для досвіду користувачів.

Ось чому дату запуску мейннету не можна вивести із загального програмного календаря. Безпечне перемикання потребує сумісної реєстрації ключів BLS, ухваленого функціонального шлюзу, спільного початкового блоку, розповсюдження сертифікатів, поведінки відкату та відновлення для відстаючих вузлів. Це спостережувані завдання для операторів. Специфікація міграції дає їм контрольний список, а фактична мережева вправа покаже, чи достатньо цього списку.

Витрати валідаторів можуть змінити те, хто бере участь

Оновлення має як економічний дизайн, так і цільову затримку. За поточного голосування оператори надсилають транзакції голосування та сплачують пов'язані з ними комісії. SIMD-0326 пропонує вхідний квиток валідатора, або VAT, що стягується замість такої схеми комісій. Документ дає початкову оцінку близько 0,8 SOL на день, або 1,6 SOL на епоху, і зазначає, що весь платіж буде спалено. Ця цифра є початковим параметром у пропозиції, а не живим рахунком для кожного валідатора.

Фіксована вартість входу може спростити одну статтю витрат, але водночас лягати важчим тягарем на малого оператора з невеликою делегованою часткою. Великий валідатор і малий не отримують однакових винагород. Питання в тому, чи покращиться їхня чиста економіка після врахування зекономлених комісій за голосування, витрат на обладнання, пропускної здатності та VAT. Пропозиція зазначає, що оператори мають побачити нижче використання ресурсів після міграції. Це очікуваний ефект, а не виміряний результат по всьому живому набору валідаторів.

Корисне порівняння до і після мало б відстежувати тих самих операторів протягом оновлення. Для кожної категорії частки порівняйте щоденні комісії за голосування до перемикання з VAT та операційними витратами після нього. Порахуйте частку незалежних операторів, які припиняють виробляти голоси або залишають активний набір. Зменшення кількості машин саме по собі не довело б втрати децентралізації, якби валідатори, що виходять, мали незначну частку, але це було б попередженням для розслідування. Концентрація частки та географічна різноманітність додали б необхідний контекст.

Пропозиція зазначає, що недостатньо профінансований валідатор буде вилучений з активного набору. Це робить управління балансом квитка питанням безперебійної роботи. Операторам потрібні попередження до вичерпання коштів, а делегаторам потрібно розуміти, що станеться, якщо їхній обраний валідатор стане неактивним. Різниця між консенсусним протоколом, який працює в лабораторії, і мережею, яка працює день за днем, включає буденне фінансування рахунків. Раніший звіт про управління валідаторами Solana описує формальний шлях ухвалення рішень; подальша участь після впровадження є окремим випробуванням.

Виробниче питання полягає не просто в тому, чи досяжні 150 мілісекунд. Воно в тому, чи достатньо широкий набір валідаторів може забезпечити таку продуктивність без незадекларованого зростання витрат або операційної крихкості. Швидша фінальність із вужчою базою операторів була б іншим результатом, ніж повна обіцянка пропозиції. І затримка, і участь потребують базового показника, взятого до перемикання.

Транзакція може бути фінальною, тоді як сервіс усе ще відстає

Депозит на біржі ілюструє розрив між фінальністю ланцюга та доступним балансом користувача. Спочатку клієнт подає підписану транзакцію. Переказ досягає лідера та включається в блок. Валідатори голосують, і формується сертифікат фіналізації. Сервіс RPC спостерігає сертифікат і звітує про нього. Монітор депозитів біржі ідентифікує адресу та актив, виконує свої перевірки політики та зараховує кошти на рахунок. Зміна консенсусу головним чином скорочує один інтервал у цій послідовності.

Біржа може чекати довше за власним вибором. Вона може вимагати додаткових перевірок для великих депозитів, порівнювати результати від кількох постачальників RPC або затримувати зарахування під час інциденту. Це не означає, що ланцюг не досяг своєї мети фінальності. Це означає, що еталонний показник ланцюга не можна рекламувати як гарантований час зарахування для клієнта. Чесне продуктове твердження має розрізняти фінальність блоку, видимість RPC та власне рішення установи про зарахування.

Можлива й зворотна помилка. Застосунок може відображати очікуваний успіх, щойно його RPC-вузол побачить блок, ще до надходження сертифіката фіналізації. Користувач може побачити швидку зелену позначку, хоча найсильніша гарантія протоколу надходить пізніше. Під час міграції застосунок, який продовжує позначати свій статус зобов’язання до оновлення так само, слід перевірити на відповідність новій семантиці. Візуально незмінений інтерфейс гаманця може приховувати змінену модель ризику.

Для децентралізованих застосунків фінальний блок не гарантує вигідної угоди. Транзакція може виконатися й зазнати невдачі за правилом застосунку, сплатити комісії або розрахуватися за ціною, якої користувач не очікував у межах поданих параметрів. Консенсусна фінальність означає, що реєстр вирішив цей результат. Вона не засвідчує, що смарт-контракт безпечний або що вхідні дані оракула були правильними. Оновлення слід оцінювати за вужчою властивістю, яку воно покликане покращити.

Щоб зробити твердження спростовним, постачальники інфраструктури могли б публікувати парні часові позначки для вибірки транзакцій: надходження до їхньої служби, перше включення, спостереження сертифіката, відповідь RPC і видиме клієнту зарахування. Вони повинні розкривати відсутні спостереження та повторні спроби. Порівняння цих інтервалів до й після активації, за подібних навантажень і умов щодо комісій, показало б, наскільки насправді Alpenglow скоротив загальний шлях. Це було б сильнішим доказом, ніж повторення цільового показника з білої книги.

Найсильніший аргумент — це реальне покращення розрахунків

Прихильники можуть навести вагомий аргумент. Поточний шлях підтвердження Solana давно залишав розрив між швидким виробництвом блоків і сильнішою фінальністю. Якщо Votor надійно зменшить цей розрив, біржа зможе швидше зараховувати депозити, трейдер зможе зменшити невизначеність після виконання, а платіжний провайдер зможе розраховуватися з меншим очікуванням. Пропозиція протоколу є серйозним інженерним проєктом, і валідатори вже витратили час на його тестування поза mainnet.

Попереднє висвітлення управління фіксує рішення валідаторів, що стояло за пропозицією. Шлях управління валідаторів також означає, що зміна не є merely обіцянкою компанії. Оператори повинні впровадити програмне забезпечення та взяти участь в активації. Поетапне керування функціями дає мережі можливість виявити проблеми до впровадження у виробництво. Ці сильні сторони не доводять остаточного рівня обслуговування, але вони роблять фазу тестування значущою.

Протилежний аргумент — це компроміс, який самі автори розкривають: швидший дизайн голосування супроводжується іншими припущеннями щодо відмов. Оператори також повинні керувати міграцією та сумісністю клієнтів. Медіана 150 мілісекунд, отримана на спокійному тестовому кластері, не дасть відповіді на питання, як протокол поводиться, коли значна частка стейку офлайн або мережеві з’єднання нестабільні. Ось чому докази належать до звіту про випадки відмов, а не лише до демонстрації швидкості.

Готовність до mainnet має кілька окремих етапів

Перший — впровадження програмного забезпечення: достатня частка стейку запускає сумісний випуск. Другий — верифікація протоколу на testnet і devnet: голоси та сертифікати залишаються правильними за нормальних і несприятливих умов. Третій — операційна підготовка: біржі, постачальники RPC, оглядачі блоків і гаманці знають, як спостерігати новий сигнал фінальності. Четвертий — сама запланована активація функції.

Трекер Anza вказує, що мінімальна версія для mainnet може підвищитися після того, як 95% стейку впровадять нову мінорну версію і мине дві повні епохи. Це правило регулює мінімальну підтримувану версію; його не слід перефразовувати як автоматичну активацію Alpenglow на 95%. Окремий рядок функції залишається місцем для перевірки фактичної очікуваної зміни.

Жодне з повідомлених тестувань не встановлює, що ціна SOL має реагувати певним чином. Ціни токенів враховують макроекономічні умови, фінансування, пропозицію, попит на застосунки та очікування щодо оновлень до впровадження. Попередній прогноз активації пояснює, чому віха консенсусу є важливою, не роблячи її каталізатором ціни за визначенням.

Чого все ще бракує публічним доказам

Датований, остаточний план активації та порівнюваний публічний ряд вимірювань фінальності за різних навантажень дозволили б читачам оцінити, наскільки мережа близька до заявленої обіцянки. Результати тестів мають вказувати версії програмного забезпечення, задіяну частку стейку, типи клієнтів, умови повідомлень, включення транзакцій та перцентильні затримки. Єдиний найкращий час фіналізації був би неповним.

Найбільш вирішальний звіт з’явиться після перемикання: повторні спостереження фінальності в головній мережі та видимого для застосунків розрахунку, а також розкриття будь-яких подій відновлення. До того часу тестування валідаторів показує, що запропонована система проходить перевірку. Воно не встановлює, що кожен користувач відчує розрахунок за 150 мілісекунд.

За чим стежити

• Функціональний шлюз: Явний статус Alpenglow у головній мережі від Anza та слот активації, відмінний від загальної дати мінімальної версії.
• Прийняття стейку: Частка стейку валідаторів, що працює на випуску, який підтримує цю функцію.
• Сумісність клієнтів: Оновлення для реалізацій валідаторів, зазначених як непідтримувані в поточному рядку трекера.
• Тести на відмови: Опубліковане відновлення та затримки в довгому хвості за розділень, перезапусків і відсутніх голосів.
• Час для користувача: Вимірювання в головній мережі від подання до фінальності та сповіщення RPC, а не лише час сертифіката.

Часті запитання