Однослотова фіналізація
Фіналізація блоку Ethereum займає близько 15 хвилин. Однак, ми можемо змусити механізм консенсусу Ethereum ефективніше перевіряти блоки та значно скоротити час до завершення. Замість того, щоб чекати п’ятнадцять хвилин, блоки можуть пропонуватися і фіналізуватися в одному слоті. Ця концепція відома як однослотова фіналізація (SSF).
Що таке остаточність?
У механізмі консенсусу Ethereum, основаному на доказі частки володіння, фіналізація означає гарантію того, що блок не можна змінити або видалити з блокчейну, не спаливши щонайменше 33% від загальної кількості ETH у стейкінгу. Це "криптоекономічна" безпека, оскільки джерелом впевненості є надзвичайно високі витрати, пов’язані зі зміною порядку або вмісту ланцюжка, і будь-який раціональний економічний суб’єкт не робитиме цього.
Навіщо потрібна швидша фіналізація?
Поточний час до фіналізації виявився задовгим. Більшість користувачів не хочуть чекати 15 хвилин до фіналізації, і додаткам і біржам, яким потрібна висока пропускна здатність, незручно чекати так довго, щоб переконатися в незмінності транзакцій. Наявність затримки між пропозицією і фіналізацією блоку також створює можливість для коротких перебудов, які зловмисник може використати для цензурування певних блоків або одержання MEV. Механізм поетапного оновлення блоків також досить складний і кілька разів виправлявся для усунення вразливостей, що робить його однією з частин кодової бази Ethereum, де можуть виникати незначні помилки. Усі ці проблеми можна усунути, зменшивши час до фіналізації до одного слоту.
Компроміс між децентралізацією, часом та накладними витратами
Гарантія фіналізації не є властивістю нового блоку відразу; для фіналізації нового блоку потрібен час. Тому що валідатори, які представляють щонайменше 2/3 від загальної кількості ETH в стейкінгу, повинні проголосувати за блок, щоб він вважався фіналізованим. Кожен вузол-валідатор у мережі має обробити підтвердження від інших вузлів, щоб дізнатися, чи було досягнуто порогу 2/3 для блока.
Що менше часу надається на досягнення фіналізації, то більше обчислювальної потужності потрібно в кожному вузлі, оскільки обробка підтверджень має відбуватися швидше. Крім того, що більше вузлів-валідаторів є в мережі, то більше підтверджень потрібно обробити для кожного блока, що також підвищує вимоги до обчислювальної потужності. Що більше обчислювальної потужності потрібно, то менше людей може брати участь, оскільки для роботи кожного вузла-валідатора потрібне дороге обладнання. Збільшення інтервалу між блоками знижує вимоги до обчислювальної потужності кожного вузла, але також збільшує час до фіналізації, оскільки обробка підтверджень відбувається повільніше.
Отже, потрібен знайти баланс між витратами ресурсів (обчислювальною потужністю), децентралізацією (кількістю вузлів, які можуть брати участь у перевірці ланцюжка) і часом до фіналізації. Ідеальна система поєднує мінімальну обчислювальну потужність, максимальну децентралізацію та мінімальний час до фіналізації.
Поточний механізм консенсусу Ethereum забезпечує оптимальне поєднання цих трьох параметрів таким способом:
- Встановлення мінімального розміру стейкінгу — 32 ETH. Встановлюється верхня межа для кількості підтверджень валідаторів, які мають обробити окремі вузли, і, отже, верхня межа вимог до обчислювальної потужності кожного вузла.
- Встановлення часу до фіналізації — приблизно 15 хвилин. Валідатори, які працюють на звичайних домашніх комп’ютерах, мають достатньо часу для безпечної обробки підтверджень для кожного блоку.
У поточному механізмі, щоб зменшити час до фіналізації, необхідно зменшити кількість валідаторів у мережі або підвищити вимоги до обладнання для кожного вузла. Однак спосіб обробки підтверджень можна покращити, щоб підраховувати більше підтверджень, не збільшуючи витрати ресурсів на кожному вузлі. Ефективніша обробка дозволить фіналізувати блоки в межах одного слоту, а не двох епох.
Шляхи до SSF
З моменту проєктування механізму консенсусу Ethereum можливості масштабування схеми агрегації підписів (BLS) виявилися набагато більшими, ніж передбачалося, а також покращилася здатність клієнтів обробляти та перевіряти підписи. Виявляється, що обробка підтверджень від великої кількості валідаторів насправді можлива протягом одного слоту. Наприклад, якщо кожен мільйон валідаторів голосує двічі в кожному слоті, і слот триває 16 секунд, вузлам потрібно буде перевіряти підписи з мінімальною швидкістю 125 000 агрегацій на секунду, щоб обробити 1 мільйон підтверджень у слоті. Насправді звичайному комп’ютеру потрібно приблизно 500 наносекунд для перевірки одного підпису, що означає, що 125 000 перевірок можна виконати приблизно за 62,5 мс, що набагато нижче порогу в одну секунду.
Подальшого підвищення ефективності можна досягти шляхом створення суперкомітетів, наприклад, зі 125 000 випадково вибраних валідаторів на слот. Лише ці валідатори можуть голосувати за блок, і тому лише ця підгрупа валідаторів приймає рішення щодо фіналізації блоку. Наскільки це доцільно залежить від того, наскільки дорогою має бути успішна атака на Ethereum, на думку спільноти. Це тому, що замість 2/3 від загального обсягу ефіру в стейкінгу, зловмисник міг би фіналізувати нечесний блок за допомогою 2/3 ефіру в стейкінгу в цьому суперкомітеті. Це все ще активна сфера досліджень, але здається ймовірним, що для набору валідаторів, достатньо великого, щоб вимагати наявності суперкомітетів, вартість атаки на один із цих підкомітетів буде надзвичайно високою (наприклад, вартість атаки, виражена в ETH, становитиме 2/3 * 125,000 * 32 = ~2,6 мільйона ETH). Вартість атаки можна скоригувати, збільшивши розмір набору валідаторів (наприклад, налаштувати розмір набору валідаторів так, щоб вартість атаки дорівнювала 1 мільйону ефіру, 4 мільйонам ефіру, 10 мільйонам ефіру тощо). Попередні опитуванняopens in a new tab спільноти, схоже, свідчать, що 1–2 мільйони ефіру є прийнятною вартістю атаки, що передбачає приблизно 65 536–97 152 валідаторів на суперкомітет.
Проте перевірка не є основним обмеженням — справжньою проблемою для вузлів-валідаторів є агрегація підписів. Щоб масштабувати агрегацію підписів, імовірно, знадобиться збільшити кількість валідаторів у кожній підмережі, збільшити кількість підмереж або додати додаткові рівні агрегації (тобто реалізувати комітети комітетів). Частково рішення може полягати в дозволі спеціалізованих агрегаторів, аналогічно тому, як створення блоків і зафіксованих значень для даних зведень буде передано спеціалізованим операторам у межах розділення тих, хто створює, і тих, хто пропонує блоки, (PBS) і данкшардінгу.
Яка роль правила вибору розгалуження у SSF? Роль правила вибору форку
Сучасний механізм консенсусу базується на тісному зв’язку між гaджетом фіналізації (алгоритмом, який визначає, чи підтвердили 2/3 валідаторів певний ланцюжок) та правилом вибору розгалуження (алгоритмом, який вирішує, який ланцюжок є правильним, коли є кілька варіантів). Алгоритм вибору форку аналізує лише блоки після останнього фіналізованого блоку. В SSF не буде жодних блоків для аналізу, оскільки фіналізація відбуватиметься в тому ж слоті, у якому пропонується блок. Це означає, що в SSF або алгоритм вибору форку, або гаджет фіналізації буде активним у будь-який момент часу. Гaджет фіналізуватиме блоки, коли 2/3 валідаторів будуть онлайн і надаватимуть чесні підтвердження. Інакше спрацьовуватиме правило вибору розгалуження, щоб визначити потрібний ланцюжок. Це також створює можливість підтримувати механізм витоку через неактивність, який відновлює ланцюжок, де >1/3 валідаторів переходять в офлайн, хоча і з деякими додатковими нюансами.
Невирішені проблеми
Проблема масштабування агрегації шляхом збільшення кількості валідаторів у підмережі полягає в тому, що це призводить до більшого навантаження на однорангову мережу. Проблема з додаванням рівнів агрегації полягає в тому, що це досить складно спроєктувати та додає затримку (тобто тому, хто пропонує блок, може знадобитися більше часу, щоб отримати інформацію від усіх агрегаторів підмереж). Також не зовсім зрозуміло, що робити, коли на мережі активних валідаторів більше, ніж можна реалістично обробити в кожному слоті, навіть з використанням агрегації підписів BLS. Одне з можливих рішень полягає в тому, що оскільки всі валідатори надають підтвердження в кожному слоті й в SSF немає комітетів, обмеження на ефективний баланс у 32 ETH можна повністю зняти. Це означає, що оператори, які керують кількома валідаторами, можуть консолідувати свій стейк і запускати менше валідаторів, зменшуючи кількість повідомлень, які потрібно обробити для врахування всього набору валідаторів. Це рішення передбачає, що великі стейкери погодяться об’єднати свої валідатори. Також можливо встановити фіксоване обмеження на кількість валідаторів або обсяг ETH у стейкінгу в будь-який момент. Проте це вимагає механізму для визначення валідаторів, які можуть брати участь, що може призвести до небажаних побічних ефектів.
Поточний прогрес
SSF перебуває на стадії дослідження. Не очікується, що це буде реалізовано протягом кількох років, імовірно, після інших суттєвих оновлень, як-от дерева Verkle та Danksharding.
Для подальшого читання
- Віталік про SSF на EDCON 2022opens in a new tab
- Нотатки Віталіка: шляхи до однослотової фіналізаціїopens in a new tab
Останні оновлення сторінки: 23 лютого 2026 р.
