Solana підвищила швидкість фіналізації: що це означає для користувачів

Solana працює з Alpenglow у головній мережі з 21 жовтня, замінивши систему голосування, якій могло знадобитися кілька секунд для фіналізації блоку, на систему, розроблену для завершення за частку секунди. Фонд Solana фіксує перехід в епосі 1064, після того як 446 із 654 валідаторів засвідчили початковий блок.

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

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

Перехід відбувся, але 150 мілісекунд — це ціль

Alpenglow замінив TowerBFT, старий процес консенсусу Solana, 21 жовтня. У старій системі валідатори розміщували транзакції голосування в ланцюжку, і блок збирав достатньо голосів у наступних слотах, щоб стати фінальним. Votor, робоча частина Alpenglow, передає голоси безпосередньо між валідаторами та об'єднує їх у сертифікати. Блок може бути фіналізований за один або два раунди голосування.

Фонд використовує 12,8 секунди як орієнтир для старої фінальності та приблизно 150 мілісекунд як нову ціль. Ці цифри описують порівняння протоколів, а не два вимірювання, зроблені з одного гаманця за ідентичних умов. Підготовчий звіт від 21 жовтня попереджав, що RPC-вузли без стейкінгу могли дізнаватися про фінальність пізніше, ніж валідатори-учасники, іноді після створення іншого блоку. Затримка інтернету та обраний застосунком вузол додаються до того, що бачить користувач.

Зовнішнє вимірювання, опубліковане 23 жовтня, показало медіанну фінальність на рівні 404 мілісекунд за попередні 24 години, з 90-м перцентилем 579 мілісекунд і 99-м перцентилем 765 мілісекунд. Його попередній орієнтир становив близько семи секунд за TowerBFT. За цими показниками медіана покращилася приблизно в 17 разів, обчислено шляхом ділення семи секунд на 0,404 секунди. Методологія та точка спостереження відрізняються від базового показника Фонду в 12,8 секунди та проектної цілі в 150 мілісекунд.

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

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

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

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

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

Гаманець має більше одного відліку

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

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

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

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

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

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

Фінансові застосунки мають інші причини відрізняти швидкість від політики. Кредитний застосунок може записувати заставу, коли переказ обробляється, але дозволяти позичання лише після фіналізації. Централізований майданчик може відстежувати фіналізовані баланси, застосовуючи власне утримання на виведення. Міст повинен обробляти ризик ланцюга-одержувача на додаток до ризику Solana. Швидший сертифікат створює можливість скоротити залежну від ланцюга частину кожного робочого процесу. Публікація часу обслуговування до і після показала б, де провайдери використовують цю можливість.

Менше транзакцій на графіку може означати той самий обсяг використання

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

Співзасновник Solana Анатолій Яковенко обговорював видалення транзакцій голосування незадовго до активації, коли зміна в показнику TPS привертала увагу. Аналітики, які порівнюють трафік 20 жовтня з трафіком після 21 жовтня, повинні відокремити транзакції, не пов'язані з голосуванням, з обох боків. Інакше зміна в обліку виглядатиме як втрачений попит. Зворотна помилка полягала б у твердженні, що нижчий трафік голосування сам по собі створює рівну кількість додаткових корисних користувацьких транзакцій; вільна потужність і фактичне використання — це різні речі.

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

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

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

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

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

Сервіси даних повинні слідувати за переможним блоком

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

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

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

У нотатках про міграцію мейннету Фонду зазначено, що рівні зобов'язань confirmed і finalized тепер описують один і той самий стан, хоча перший наразі ще доступний і буде видалений у пізнішому випуску. Розробникам рекомендують спрямовувати нову роботу на finalized і переглянути налаштування тайм-аутів або повторних спроб, налаштовані на старе очікування. Сервіс, який за звичкою чекає 12 секунд, може залишатися повільним, незважаючи на значно швидший ланцюжок.

Потоки даних мають інші зміни. Proof of History більше не задає темп виробництва блоків так само, тому записи tick залишають потік shred. Програма, яка зчитує мітку часу Clock, може бачити інше джерело, ніж раніше. Ці деталі не є ознаками того, що формат користувацьких транзакцій змінився. Це місця, де програмне забезпечення, побудоване навколо старого таймінгу реєстру, може потребувати доопрацювання, перш ніж нова швидкість мережі дійде до екрана.

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

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

Валідатори мають новий регулярний рахунок

Видалення ончейн-транзакцій голосування змінює витрати валідаторів. Фонд Solana каже, що голосування раніше коштувало близько 1 SOL за епоху в комісіях за транзакції, сплачуваних з акаунта ідентичності валідатора. Новий Validator Admission Ticket спалює 0,8 SOL за епоху з його акаунта голосування, понад мінімум, що звільняє від оренди. Квиток, придбаний на початку однієї епохи, допускає валідатора на наступну.

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

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

Запуск вимагав Agave 4.3.2 або сумісних клієнтів Jito-Solana чи Harmonic Salsa. Firedancer і Frankendancer не підтримувалися для міграції, згідно зі сторінкою оператора Фонду. Активація Alpenglow доводить, що мережа могла переключитися з валідаторами-учасниками; це не показує, що кожен альтернативний клієнт валідатора був готовий до того самого дня. Різноманітність клієнтів залишається окремим питанням стійкості.

Схвалення врядування відбулося перед міграцією.Раніший план розгортання описував код в Agave 4.2 під час тестування, але саме лише встановлення ніколи не було перемиканням мейннету. Сертифікат генезису та початок консенсусу на слоті 459 653 000 є свідченням активації. 446 підписантів першого сертифіката представляли конкретну подію координації, а не обіцянку щодо відвідуваності чи продуктивності всіх 654 валідаторів щогодини після цього.

Фіксований квиток змінює економіку валідаторів по-різному залежно від розміру. Великий оператор і малий платять однакові 0,8 SOL за вхід, тому ця плата споживає більшу частку валових винагород малого оператора. Чи це когось відштовхне, залежить від делегованого стейку, комісії, операційних витрат та іншого доходу. Настанови для операторів встановлюють механіку платежів; вони не прогнозують, скільки валідаторів піде. Корисним подальшим кроком було б порівняння активних незалежних операторів і концентрації стейку протягом кількох епох.

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

Оновлення вирішує вужчу проблему, ніж платіжні застосунки

Аргумент Solana на користь Alpenglow є потужним: якщо остаточність настає набагато швидше, сервіси, яким потрібен незворотний розрахунок, можуть перестати чекати кілька секунд невизначеності. Зовнішні вимірювання від 23 жовтня підтверджують суттєве покращення в mainnet, хоча їхня медіана 404 мілісекунди була повільнішою за цільовий показник дизайну. Продавці та біржі можуть вирішити покладатися на цей сильніший, швидший статус.

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

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

Друга частина Alpenglow, Rotor, все ще запланована для пізнішого випуску без дати активації. Votor змінив голосування та остаточність; розподіл блоків все ще використовує старий підхід Turbine. Назва пакета може створити враження, що всі запропоновані компоненти з'явилися разом. Поточна таблиця статусу Фонду чітко показує розділення. Будь-який приріст продуктивності, приписаний Rotor у поточних даних mainnet, отримав би неправильну хронологію.

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

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

Що ще потрібно виміряти

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

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

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

На що звернути увагу

• Спостережувана фінальність: Порівнюйте ковзну медіану та показники найповільнішого процентиля на панелі Foundation та незалежних вузлах, із зазначенням точок спостереження.
• Час гаманців і бірж: Вимірюйте інтервал від схвалення клієнтом до видимого підтвердження або зарахованого балансу, а не лише сертифікат валідатора.
• Порівнянний трафік: Відстежуйте транзакції користувачів, що не є голосуваннями, до та після 21 жовтня, щоб вилучені транзакції голосування не спотворювали тенденцію.
• Помилки потокової передачі: Перевірте, чи підтримують провайдери RPC та індексаторів реконструкцію блоків з урахуванням банків і своєчасний фіналізований статус.
• Допуск валідаторів: Стежте за фінансуванням рахунків голосування, активними валідаторами та підтримуваним різноманіттям клієнтів, оскільки комісія 0.8 SOL повторюється кожну епоху.

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