Vitalik: Які ще можливості для вдосконалення PoS у Ethereum і які шляхи для їх реалізації?

У цій статті основна увага приділяється питанню "злиття" Ethereum: які аспекти технічного дизайну proof-of-stake ще можна вдосконалити та якими шляхами це можна зробити?

Автор:Vitalik Buterin

Переклад: Deng Tong, Jinse Finance

Особлива подяка Justin Drake, Hsiao-wei Wang, @antonttc та Francesco за відгуки та рецензію.

Спочатку "злиття" означало найважливішу подію в історії протоколу Ethereum з моменту його запуску: довгоочікуваний і складний перехід від proof-of-work до proof-of-stake. Сьогодні Ethereum вже майже два роки є стабільною системою proof-of-stake, яка демонструє чудові результати у стабільності, продуктивності та уникненні ризиків централізації. Однак у proof-of-stake залишаються важливі сфери для вдосконалення.

Моя дорожня карта 2023 року розділяє це на кілька частин: вдосконалення технічних характеристик, таких як стабільність, продуктивність і доступність для дрібних валідаторів, а також економічні зміни для протидії ризикам централізації. Перше отримало назву "злиття", а друге стало частиною "Scourge".

У цій статті основна увага приділяється частині "злиття": які аспекти технічного дизайну proof-of-stake ще можна вдосконалити та якими шляхами це можна зробити?

Це не вичерпний список можливих удосконалень proof-of-stake; натомість це перелік ідей, які активно розглядаються.

Фіналізація за один слот і демократизація стейкінгу

Яку проблему ми вирішуємо?

Сьогодні для фіналізації блоку потрібно 2-3 епохи (близько 15 хвилин), а для того, щоб стати стейкером, потрібно 32 ETH. Це було компромісом для досягнення балансу між трьома цілями:

• Максимізація кількості валідаторів, які можуть брати участь у стейкінгу (це безпосередньо означає мінімізацію мінімальної суми ETH для стейкінгу)
• Мінімізація часу фіналізації
• Мінімізація витрат на запуск вузлів

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

Зверніть увагу, що все це залежить від ключової мети Ethereum: забезпечити, щоб навіть успішна атака коштувала атакуючому дуже дорого. Це і є суть терміну "економічна фіналізація". Якби у нас не було цієї мети, ми могли б фіналізувати кожен слот шляхом випадкового вибору комітету (як це робить Algorand). Але проблема такого підходу в тому, що якщо атакуючий контролює 51% валідаторів, він може атакувати з дуже низькими витратами (відновлення фіналізованого блоку, цензура або затримка фіналізації): лише частина вузлів у комітеті може бути виявлена як учасники атаки і покарана, незалежно від того, чи це через slashing чи minority soft fork. Це означає, що атакуючий може багаторазово атакувати ланцюг. Тому, якщо ми хочемо економічної фіналізації, простий підхід на основі комітетів не працює, і на перший погляд нам дійсно потрібна участь усіх валідаторів.

В ідеалі ми хочемо зберегти економічну фіналізацію, одночасно покращуючи поточний стан у двох аспектах:

• Фіналізувати блок за один слот (ідеально — зберігаючи або навіть скорочуючи поточну довжину у 12 секунд), а не за 15 хвилин
• Дозволити валідаторам стейкати з 1 ETH (знизити мінімум з 32 ETH до 1 ETH)

Перша ціль обґрунтована двома цілями, які можна розглядати як "наблизити властивості Ethereum до властивостей (більш централізованих) L1-ланцюгів, орієнтованих на продуктивність".

По-перше, це гарантує, що всі користувачі Ethereum отримують вигоду від підвищеного рівня безпеки, забезпеченого механізмом фіналізації. Сьогодні більшість користувачів не отримують цієї вигоди, оскільки не хочуть чекати 15 хвилин; а з фіналізацією за один слот користувачі майже одразу після підтвердження транзакції бачать її фіналізацію. По-друге, якщо користувачі та застосунки не повинні турбуватися про можливість reorg ланцюга (за винятком рідкісних випадків неактивності), це спрощує протокол та інфраструктуру навколо нього.

Друга ціль — це бажання підтримати індивідуальних стейкерів. Опитування знову і знову показують, що головною перешкодою для більшої кількості людей стейкати самостійно є мінімум у 32 ETH. Зниження мінімуму до 1 ETH вирішить цю проблему настільки, що інші питання стануть основними обмеженнями для індивідуального стейкінгу.

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

Що це таке і як це працює?

Фіналізація за один слот передбачає використання алгоритму консенсусу, який фіналізує блок протягом одного слоту. Це не така вже й складна ціль: багато алгоритмів (наприклад, Tendermint consensus) вже досягають цього з найкращими властивостями. Унікальною для Ethereum ідеальною властивістю є "inactivity leak", яку Tendermint не підтримує, і яка дозволяє ланцюгу продовжувати працювати і відновлюватися навіть якщо понад 1/3 валідаторів офлайн. На щастя, це бажання вже враховано: вже є пропозиції модифікувати Tendermint-подібний консенсус для підтримки inactivity leak.

Провідні пропозиції щодо фіналізації за один слот

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

Варіант 1: "Брутфорс" — розробити кращі протоколи агрегації підписів, можливо із застосуванням ZK-SNARKs, що дозволить обробляти підписи мільйонів валідаторів у кожному слоті.

Horn — один із дизайнів, запропонованих для кращого протоколу агрегації.

Варіант 2: Orbit committee — новий механізм, який дозволяє випадково обраному середньому комітету відповідати за фіналізацію ланцюга, але так, щоб зберегти бажані властивості щодо вартості атаки.

Один зі способів мислення про Orbit SSF — це те, що він відкриває простір компромісів від x=0 (комітет у стилі Algorand, без економічної фіналізації) до x=1 (поточний стан Ethereum), створюючи проміжні точки, де Ethereum все ще має достатню економічну фіналізацію для надзвичайної безпеки, але ми отримуємо переваги ефективності, коли для кожного слоту бере участь лише середній випадковий зразок валідаторів.

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

Варіант 3: Дворівневий стейкінг — механізм, у якому стейкери поділяються на два рівні: з вищими та нижчими вимогами до депозиту. Лише рівень з вищими вимогами бере безпосередню участь у забезпеченні економічної фіналізації. Щодо прав і обов'язків нижчого рівня існують різні пропозиції (наприклад, див. пост про Rainbow staking). Типові ідеї включають:

• Право делегувати stake власникам stake вищого рівня
• Випадковий відбір стейкерів нижчого рівня для підтвердження кожного блоку
• Право формувати inclusion list

Які є посилання на існуючі дослідження?

• Шляхи досягнення фіналізації за один слот (2022):
• Конкретні пропозиції щодо протоколу фіналізації за один слот для Ethereum (2023):
• Orbit SSF:
• Додатковий аналіз механізмів у стилі Orbit:
• Horn, протокол агрегації підписів (2022):
• Агрегація підписів для масштабного консенсусу (2023):
• Протокол агрегації підписів від Khovratovich та ін.:
• Агрегація підписів на основі STARK (2022):
• Rainbow staking:

Що ще потрібно зробити? Які компроміси?

Є чотири основні можливі шляхи (можна також комбінувати їх):

• Зберегти статус-кво
• Orbit SSF
• Brute-force SSF
• SSF з дворівневим стейкінгом

(1) означає нічого не змінювати, залишити стейкінг як є, але це погіршує досвід безпеки Ethereum і властивості децентралізації стейкінгу.

(2) уникає "високих технологій" і вирішує проблему шляхом переосмислення припущень протоколу: ми послаблюємо вимогу "економічної фіналізації", так що вартість атаки все ще висока, але може бути в 10 разів нижчою, ніж зараз (наприклад, 2.5 billions доларів замість 25 billions доларів). Загалом вважається, що економічна фіналізація Ethereum сьогодні значно перевищує необхідний рівень, а основні ризики безпеки знаходяться в інших місцях, тому це можна вважати прийнятною жертвою.

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

(3) уникає хитрих переосмислень і вирішує проблему "високими технологіями". Для цього потрібно зібрати величезну кількість підписів (понад 1 мільйон) за дуже короткий час (5-10 секунд).

(4) уникає і хитрих переосмислень, і високих технологій, але створює дворівневу систему стейкінгу, яка все ще має ризики централізації. Ризики значною мірою залежать від конкретних прав, які отримує нижчий рівень. Наприклад:

• Якщо стейкери нижчого рівня повинні делегувати право підтвердження стейкерам вищого рівня, делегування може централізуватися, і ми отримаємо два висококонцентровані рівні стейкінгу.
• Якщо потрібно випадковим чином вибирати нижчий рівень для підтвердження кожного блоку, атакуючий може витратити мінімальну кількість ETH, щоб заблокувати фіналізацію.
• Якщо стейкери нижчого рівня можуть лише створювати inclusion list, то шар підтвердження може залишатися централізованим, і 51% атака на нього дозволить цензурувати inclusion list.

Можна комбінувати різні стратегії, наприклад:

• (1 + 2): Додати Orbit без впровадження фіналізації за один слот.
• (1 + 3): Використовувати brute-force для зменшення мінімального депозиту без фіналізації за один слот. Необхідна агрегація у 64 рази менша, ніж у чистому випадку (3), тому проблема легша.
• (2 + 3): Використовувати консервативні параметри для Orbit SSF (наприклад, комітет із 128k валідаторів замість 8k чи 32k) і brute-force для підвищення ефективності.
• (1 + 4): Додати Rainbow staking без фіналізації за один слот.

Як це взаємодіє з іншими частинами дорожньої карти?

Окрім інших переваг, фіналізація за один слот знижує ризик деяких типів багатоблокових MEV-атак. Крім того, у світі з фіналізацією за один слот дизайн розділення prover-proposer та інші внутрішньопротокольні механізми виробництва блоків потрібно проектувати по-іншому.

Слабкість brute-force стратегій у тому, що вони ускладнюють скорочення часу слота.

Вибори єдиного секретного лідера

Яку проблему ми вирішуємо?

Сьогодні заздалегідь відомо, який валідатор запропонує наступний блок. Це створює вразливість: атакуючий може моніторити мережу, ідентифікувати, які валідатори відповідають яким IP-адресам, і здійснювати DoS-атаку на валідатора, коли той має запропонувати блок.

Що це таке? Як це працює?

Найкращий спосіб вирішити проблему DoS — приховати інформацію про те, який валідатор згенерує наступний блок, принаймні до моменту його створення. Зверніть увагу, що якщо ми відмовимося від вимоги "єдиності", це легко: рішення — дозволити будь-кому створити наступний блок, але вимагати, щоб randao reveal був меншим за 2^256 / N. У середньому лише один валідатор відповідатиме цій вимозі — але іноді буде два чи більше, іноді жодного. Поєднання вимог "секретності" та "єдиності" завжди було складною задачею.

Протокол виборів єдиного секретного лідера вирішує це, використовуючи криптографію для створення "сліпого" ID валідатора для кожного валідатора, а потім дозволяє багатьом пропонентам перемішувати та повторно "засліплювати" пул сліпих ID (аналогічно до роботи mixnet). У кожному слоті випадково вибирається один сліпий ID. Лише власник цього сліпого ID може створити дійсний доказ для пропозиції блоку, але ніхто не знає, якому валідатору належить цей сліпий ID.

Протокол Whisk SSLE

Які є посилання на існуючі дослідження?

• Стаття Dan Boneh (2020):
• Whisk (конкретна пропозиція для Ethereum, 2022):
• Тег виборів єдиного секретного лідера на ethresear.ch:
• Спрощений SSLE на основі кільцевих підписів:

Що ще потрібно зробити? Які компроміси?

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

Зрештою може статися так, що лише коли ми з інших причин (наприклад, для state tree, ZK-EVM) впровадимо універсальні zero-knowledge докази на L1 Ethereum, "маржинальна додаткова складність" SSLE стане досить низькою.

Інший варіант — взагалі не впроваджувати SSLE, а вирішувати проблему DoS позапротокольними засобами (наприклад, на p2p-рівні).

Як це взаємодіє з іншими частинами дорожньої карти?

Якщо ми додамо механізм розділення prover-proposer (APS), наприклад, execution tickets, то execution blocks (тобто блоки з транзакціями Ethereum) не потребуватимуть SSLE, оскільки ми можемо покладатися на спеціалізованих блок-білдерів. Однак для блоків консенсусу (тобто блоків із протокольними повідомленнями, наприклад, доказами, inclusion list тощо) ми все ще отримаємо вигоду від SSLE.

Швидше підтвердження транзакцій

Яку проблему ми вирішуємо?

Зменшення часу підтвердження транзакцій у Ethereum до 4 секунд є цінним. Це значно покращить користувацький досвід L1 і rollup, а також зробить defi-протоколи ефективнішими. Це також полегшить децентралізацію L2, оскільки дозволить багатьом L2-додаткам працювати на rollup, зменшуючи потребу L2 створювати власний децентралізований комітетний сортер.

Що це таке? Як це працює?

Тут є дві основні технічні ідеї:

• Скоротити час слота, наприклад, до 8 або 4 секунд. Це не обов'язково означає фіналізацію за 4 секунди: фіналізація по суті потребує трьох раундів комунікації, тому кожен раунд може бути окремим блоком, і через 4 секунди ми отримаємо хоча б попереднє підтвердження.
• Дозволити пропоненту публікувати preconfirmations під час слота. У крайньому випадку пропонент може в реальному часі включати транзакції у свій блок і одразу публікувати preconfirmation для кожної ("Моя перша транзакція — 0×1234...", "Моя друга — 0×5678..."). Якщо пропонент публікує два суперечливих підтвердження, це можна вирішити двома способами: (i) slashing пропонента або (ii) голосуванням валідаторів, яка з них була раніше.

Які є посилання на існуючі дослідження?

• На основі preconfirmation:
• Protocol-enforced proposer commitments (PEPC):
• Interleaved epochs on parallel chains (ідея для низької затримки, 2018):

Що ще потрібно зробити? Які компроміси?

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

Слабкість підходу preconfirmation — він значно покращує середній час включення, але не найгірший випадок: якщо поточний пропонент працює добре, ваша транзакція отримає preconfirmation за 0.5 секунди, а не (в середньому) за 6 секунд, але якщо пропонент офлайн або працює погано, вам все одно доведеться чекати 12 секунд до наступного слота і нового пропонента.

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

З іншого боку, якщо ми не намагатимемося це зробити і залишимо час фіналізації у 12 секунд (або більше), екосистема більше покладатиметься на preconfirmation-механізми L2, а крос-L2-взаємодія займатиме більше часу.

Як це взаємодіє з іншими частинами дорожньої карти?

Preconfirmation на основі пропонента фактично залежить від механізму розділення prover-proposer (APS), наприклад, execution tickets. Інакше тиск на забезпечення реального часу preconfirmation може надмірно централізувати звичайних валідаторів.

Інші напрями досліджень

Відновлення після 51% атаки

Зазвичай вважається, що якщо станеться 51% атака (включаючи атаки, які не можна довести криптографічно, наприклад, цензуру), спільнота об'єднається для minority soft fork, щоб добрі перемогли, а злі втратили stake через неактивність або slashing. Однак така надмірна залежність від соціального рівня, мабуть, є нездоровою. Ми можемо спробувати зменшити цю залежність, зробивши процес відновлення максимально автоматизованим.

Повна автоматизація неможлива, бо інакше це був би консенсус-алгоритм з >50% fault tolerance, а ми вже знаємо (дуже суворі) математичні обмеження таких алгоритмів. Але можна реалізувати часткову автоматизацію: наприклад, якщо клієнт бачить, що транзакція була цензурована досить довго, він може автоматично відмовитися приймати такий ланцюг як фіналізований або навіть як head для вибору форку. Ключова мета — гарантувати, що злі у разі атаки не зможуть швидко перемогти.

Підвищення порогу кворуму

Сьогодні блок фіналізується, якщо його підтримують 67% стейкерів. Дехто вважає це занадто агресивним. За всю історію Ethereum лише раз (дуже коротко) була втрата фіналізації. Якщо підняти цей відсоток до 80%, кількість періодів без фіналізації зросте незначно, але Ethereum отримає додаткову безпеку: зокрема, у багатьох спірних ситуаціях фіналізація тимчасово зупиниться. Це здається здоровішим, ніж "миттєва перемога неправої сторони", незалежно від того, чи це атакуючий, чи клієнт із багом.

Це також відповідає на питання "який сенс індивідуального стейкінгу". Сьогодні більшість стейкерів вже стейкають через пули, і малоймовірно, що індивідуальні стейкери отримають 51% ETH. Однак якщо ми докладемо зусиль, щоб індивідуальні стейкери досягли міноритарного блокуючого пакету, особливо якщо більшість підніметься до 80% (тобто для блокування потрібно лише 21%), це цілком реально. Головне — щоб індивідуальні стейкери не брали участі у 51% атаці (чи то reorg, чи цензура), така атака не отримає "чистої перемоги", і індивідуальні стейкери активно допоможуть організувати minority soft fork.

Квантова стійкість

Metaculus наразі вважає, що, хоча похибка велика, квантові комп'ютери, ймовірно, почнуть ламати криптографію у 2030-х:

Експерти з квантових обчислень, такі як Scott Aaronson, нещодавно також почали серйозніше розглядати можливість реальної роботи квантових комп'ютерів у середньостроковій перспективі. Це впливає на всю дорожню карту Ethereum: це означає, що кожна частина протоколу Ethereum, яка зараз покладається на еліптичні криві, потребує альтернативи на основі хешів або іншої квантово-стійкої криптографії. Зокрема, ми не можемо розраховувати, що завжди зможемо покладатися на чудові властивості BLS-агрегації для обробки підписів великої кількості валідаторів. Це підтверджує доцільність консервативного підходу до припущень щодо продуктивності proof-of-stake і є причиною для активнішої розробки квантово-стійких альтернатив.