Останнє дослідження Vitalik: Які зміни потрібні LSDFi-протоколам та ліквідності для підвищення децентралізації та зменшення перевантаження консенсусу?

У цій статті основна увага приділяється поточним ризикам централізації операторів вузлів у протоколах LSDFi та пулах ліквідності, а також зайвому навантаженню на консенсус.

Автор:Vitalik Buterin

Переклад: bayemon.eth, ChainCatcher

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

• Оператор вузла (Node Operator): керує вузлом і закладає певну суму власного капіталу як заставу, підкріплену своєю репутацією
• Делегатор (Delegator): делегатори стейкають певну кількість Ethereum, без мінімального порогу, і без додаткових обмежень щодо інших способів участі, окрім застави

Цей новий двошаровий стейкінг виникає завдяки численним пулам стейкінгу, які надають ліквідні стейкінгові токени (LST). (Rocket Pool і Lido працюють за цією моделлю).

Однак поточний двошаровий стейкінг має два недоліки:

• Ризик централізації операторів вузлів: нинішні механізми відбору операторів вузлів у всіх пулах стейкінгу залишаються надмірно централізованими
• Зайве навантаження на консенсус: Ethereum L1 повинен перевіряти близько 800000 підписів за кожен Epoch, що є величезним навантаженням для одного slot. Крім того, оскільки для пулів ліквідного стейкінгу потрібно більше коштів, а сама мережа не отримує достатньої вигоди від цього навантаження. Тому, якщо мережа Ethereum зможе досягти розумної децентралізації та безпеки без необхідності підпису кожного стейкера у кожному slot, спільнота може прийняти такі рішення, значно скоротивши кількість підписів за період.

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

Як працює поточний двошаровий стейкінг?

Найпопулярніші два пули стейкінгу — це Lido і RocketPool. Для Lido учасники поділяються на:

• Оператор вузла: обирається шляхом голосування Lido DAO, тобто фактично обирається власниками LDO. Коли хтось вносить ETH у смарт-контракт Lido, створюється stETH, оператор вузла може внести його у пул стейкінгу (але через те, що права на виведення прив’язані до смарт-контракту, оператор не може вільно виводити кошти)
• Делегатор: коли хтось вносить ETH у смарт-контракт Lido, створюється stETH, оператор вузла може внести його у стейкінг (але через те, що права на виведення прив’язані до смарт-контракту, оператор не може вільно виводити кошти)

Для Rocket Pool:

• Оператор вузла: будь-хто може стати оператором вузла, достатньо внести 8 ETH і певну кількість токенів RPL.
• Делегатор: коли хтось вносить ETH у смарт-контракт Rocket Pool, створюється rETH, оператор вузла може внести його у стейкінг (також через те, що права на виведення прив’язані до смарт-контракту, оператор не може вільно виводити кошти).

Роль делегатора

У цих системах (або у нових системах, які можуть бути впроваджені завдяки майбутнім змінам протоколу), виникає ключове питання: у чому сенс існування делегатора з точки зору протоколу?

Щоб зрозуміти це питання глибше, спочатку розглянемо, що станеться, якщо у протоколі буде обмежено штрафи за скорочення до 2 ETH, Rocket Pool також знизить суму стейкінгу для операторів вузлів до 2 ETH, а ринкова частка Rocket Pool зросте до 100% (для стейкерів і власників ETH, оскільки rETH стане безризиковим, майже всі власники ETH стануть власниками rETH або операторами вузлів).

Припустимо, дохідність для власників rETH становить 3% (включаючи винагороди протоколу та пріоритетні збори + MEV), а для операторів вузлів — 4%. Також припустимо, що загальна пропозиція ETH становить 100 millions.

Розрахунок виглядає так. Щоб уникнути складних відсотків, розрахунок проводиться у денному вимірі:

Тепер припустимо, що Rocket Pool не існує, мінімальний депозит для кожного стейкера знижується до 2 ETH, загальний ліміт ліквідності становить 6.25 millions ETH, а дохідність операторів вузлів знижується до 1%. Проведемо розрахунок знову:

Розглянемо ці дві ситуації з точки зору вартості атаки. У першому випадку, атакуючий не буде реєструватися як делегатор, оскільки делегатор по суті не має жодних прав на виведення коштів, тому це не має сенсу. Відповідно, він використає весь свій ETH для стейкінгу і стане оператором вузла. Щоб досягти 1/3 від загальної суми стейкінгу, йому потрібно внести 2.08 millions ETH (що, слід визнати, все ще дуже велика сума). У другому випадку, атакуючий також повинен внести кошти, щоб досягти 1/3 від загальної суми стейкінгу, і йому також потрібно внести 2.08 millions ETH.

З точки зору економіки стейкінгу та вартості атаки, кінцевий результат у обох випадках ідентичний. Частка ETH у загальній пропозиції, що належить операторам вузлів, зростає на 0.00256% щодня, а частка ETH у загальній пропозиції, що належить не-операторам вузлів, зменшується на 0.00017% щодня. Вартість атаки становить 2.08 millions ETH. Тому у цій моделі делегатор виглядає як абсолютно непотрібна машина Руба Голдберга, і раціональна спільнота навіть схильна позбутися посередника, значно зменшити винагороди за стейкінг і обмежити загальну суму стейкінгу 6.25 millions ETH.

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

Відповідальність делегатора

Якщо делегатор може відігравати значущу роль у системі стейкінгу, то якою може бути ця роль?

Я вважаю, що є два типи відповідей:

• Вибір делегатора: делегатор може обирати, яким операторам вузлів делегувати свої інтереси. Вага оператора вузла у механізмі консенсусу пропорційна загальній сумі стейкінгу, делегованій йому. Наразі механізм вибору делегатора обмежений: власники rETH чи stETH можуть відкликати свій ETH і перейти до іншого пулу, але реальна доступність вибору делегатора може бути значно покращена.
• Участь у механізмі консенсусу: делегатор може брати участь у консенсусі, не несячи повної відповідальності за підписку, не маючи довгого періоду виходу чи ризику скорочення, але все одно стримуючи операторів вузлів.

Посилення вибору делегатора

Є три способи посилити владу делегатора:

• Покращення інструментів голосування у пулі
• Посилення конкуренції між пулами
• Фіксація права делегування

Наразі голосування у пулі практично не здійснюється: у Rocket Pool будь-хто може стати оператором вузла, у Lido голосування здійснюється власниками LDO, а не ETH. Lido запропонувала механізм подвійного управління LDO + stETH, який дозволяє активувати захисний механізм для блокування нових голосувань і, відповідно, додавання або видалення операторів вузлів, що певною мірою дає власникам stETH право голосу. Проте ця влада все ще обмежена і може бути посилена.

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

Ми можемо вирішити перші дві проблеми, обмеживши суму штрафу, наприклад, до 2 або 4 ETH. Тоді решта ETH може бути безпечно внесена і негайно виведена, що дозволяє двосторонній обмін навіть для менших пулів стейкінгу. Ми можемо вирішити третю проблему, створивши загальний контракт для випуску, який керує LST (аналогічно ERC-4337 і ERC-6900 для гаманців), щоб гарантувати безпеку будь-яких токенів стейкінгу, випущених через цей контракт.

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

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

Участь у консенсусі

Навіть не враховуючи поточних проблем ліквідного стейкінгу, існують обмеження для поточних методів незалежного стейкінгу. Припустимо, що використовується single-slot finality, ідеально кожен slot може обробляти близько 100,000–1,000,000 BLS-підписів. Навіть якщо ми використовуємо рекурсивні SNARK для агрегації підписів, для відстеження підписів потрібно призначити кожному підпису бітове поле учасника. Якщо Ethereum стане мережею глобального масштабу, навіть повністю децентралізоване зберігання бітових полів буде недостатнім: у кожному slot 16 МБ підтримують лише близько 64 millions стейкерів.

З цієї точки зору, розподіл стейкінгу на більш складний шар з можливістю скорочення і менш складний шар має сенс: складний шар діє у кожному slot, але може мати лише 10,000 учасників, а менш складний шар залучається лише час від часу. Менш складний шар може бути повністю захищений від скорочення або випадково отримувати можливість внести депозит і стати об’єктом скорочення протягом кількох slot.

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

Ось кілька пропозицій щодо того, як можуть працювати ці ролі малих стейкерів:

• У кожному slot випадково обирається 10,000 малих стейкерів, які можуть підписати те, що вони вважають правильним для цього slot. Використовуйте малих стейкерів як вхід для запуску правила вибору гілки LMD GHOST. Якщо вибір гілки, керований малими стейкерами, і вибір гілки, керований операторами вузлів, розходяться, клієнт користувача не приймає жодного блоку як фінального і показує помилку. Це змушує спільноту втрутитися для вирішення ситуації.
• Делегатор може надіслати транзакцію, оголосивши мережі, що він онлайн і готовий бути малим стейкером протягом наступної години. Повідомлення, надіслані вузлом (блок або доказ), вимагають підпису як вузла, так і випадково обраного делегатора для підтвердження вузла.
• Делегатор може надіслати транзакцію, оголосивши мережі, що він онлайн і готовий бути малим стейкером протягом наступної години. У кожному періоді випадково обирається 10 делегаторів як inclusion list provider і ще 10,000 делегаторів як виборці. Вони обираються до k-slot і мають k-slot вікно для підтвердження своєї онлайн-активності у ланцюзі. Кожен підтверджений inclusion list provider може опублікувати inclusion list, і для кожного inclusion list або включаються транзакції з inclusion list, або достатня кількість виборців голосує, що inclusion list недоступний, інакше блок вважається недійсним.

Усі ці малі стейкерські вузли мають спільну рису: їм не потрібно активно брати участь у кожному slot, і навіть легкий вузол може виконувати всю роботу. Тому розгортання вузла вимагає лише перевірки консенсусного шару, оператори вузлів можуть використовувати додатки або браузерні плагіни, які здебільшого пасивні, мають низькі вимоги до обчислень, обладнання чи технічних знань і навіть не потребують таких передових технологій, як ZK-EVM.

Усі ці «малі ролі» мають спільну мету: запобігти цензурі транзакцій з боку 51% більшості операторів вузлів. Перший і другий способи також запобігають участі більшості у відкаті фінальності. Третій спосіб безпосередньо спрямований на боротьбу з цензурою, але він більш вразливий до вибору більшістю операторів вузлів.

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

1. З точки зору протоколу, кожен валідатор може встановити два стейкінгові ключі: постійний стейкінговий ключ P і прив’язану адресу Ethereum для виклику, а також швидкий стейкінговий ключ Q. Підписи для вибору гілки відстежуються за допомогою P, а підписи для інформації — за допомогою Q. Якщо результати зберігання PQ не збігаються, жоден блок не приймається як фінальний, а пул ліквідності відповідає за випадковий вибір представників.
2. Протокол загалом залишається незмінним, але відкритий ключ валідатора для цього періоду встановлюється як P+Q. Зверніть увагу, що для скорочення два повідомлення можуть мати різні ключі Q, але однаковий ключ P; дизайн скорочення повинен враховувати це.
3. Ключ Q може використовуватися у протоколі лише для підпису та перевірки inclusion list у блоці. У цьому випадку Q може бути смарт-контрактом, а не окремим ключем, тому пул стейкінгу може реалізувати складнішу логіку голосування, приймаючи inclusion list від випадково обраних провайдерів або достатню кількість голосів про недоступність inclusion list.

Висновок

Якщо все реалізовано правильно, незначне коригування дизайну proof-of-stake може вирішити дві проблеми одночасно:

• Надати можливість тим, хто сьогодні не має ресурсів або можливості самостійно брати участь у proof-of-stake, долучитися до нього, зберігаючи більше влади у своїх руках: (i) вибір, які вузли підтримувати, і (ii) активна участь у консенсусі у більш легкій, але все ще значущій формі, ніж повна робота вузла proof-of-stake. Не всі учасники оберуть один або обидва варіанти, але кожен, хто обере хоча б один, отримає значне покращення порівняно з поточним станом.
• Зменшити кількість підписів, які консенсусний шар Ethereum повинен обробляти у кожному slot, навіть у режимі single-slot finality, до приблизно 10,000 або подібної невеликої кількості. Це також сприятиме децентралізації, полегшуючи запуск вузлів валідації для кожного.

Для цих рішень можна знайти підходи на різних рівнях абстракції: надання прав користувачам у самому протоколі proof-of-stake, вибір користувачів між протоколами proof-of-stake, а також налаштування у протоколі. Вибір слід робити обережно, і зазвичай краще обирати мінімально необхідне налаштування, щоб максимально зменшити складність протоколу та зміни у його економіці, водночас досягаючи бажаних цілей.

Особлива подяка Mike Neuder, Justin Drake та іншим за відгуки та рецензії. Див. також: статті Mike Neuder, Dankrad Feist та arixon.eth на схожі теми.