Основи переставлення

З урахуванням деякого активу X, ми позначаємо через [X] переставлений актив, тобто актив, який "упаковує" X таким чином, що частина або весь X може бути захоплений якоюсь стороною за деякої довільної умови.

Основний приклад, представлений компанією EigenLayer, полягає в тому, що одиночний стейкер перерозподіляє свої поточні ETH, які він ставить. Для цього одиночний стейкер оновлює свою адресу виведення на адресуEigenLayer podEigenPods - це смарт-контракти, які відстежують, за які сервіси соло-ставкер підписався для захисту своєї ставки. EigenPod у кінцевому підсумку стає власником активу soETH, тоді як він нараховує соло-ставкеру пере-ставлену репрезентацію їх заставленого ETH.

Власність на актив soETH у нашій структурі позначає «перший право» на виведення ETH з протоколу Ethereum, тобто володіє більш старшим правом, ніж будь-який інший учасник у ланцюжку. Коли сольний стейкер вирішує вивести свої ETH з протоколу Ethereum, виведені ETH проходять через контракт EigenPod, перевіряючи, чи дозволено сольному стейкеру викупити весь обсяг soETH чи ні (ми побачимо пізніше, коли це може бути не так). З нашими балансовими звітами:

Ми робимо кожен крок явним в наступному:

1. Одинокий стейкер депонує свій ETH до протоколу Ethereum, отримуючи віртуальну позицію soETH від протоколу Ethereum.
2. Одинокий стейкер фактично вносить своє soETH до EigenLayer, встановлюючи свою адресу виведення на адресу підкасту EigenLayer. В обмін одинокий стейкер отримує віртуальну позицію [soETH] від EigenLayer, що дозволяє їм в кінцевому підсумку виконувати порядок операцій у зворотному напрямку.

Дисбаланси балансів

Ми вже можемо зробити деякі цікаві спостереження з вищезазначених балансів. По-перше, протокол Ethereum зовсім не має уявлення про [soETH], оскільки це не відображається в його власному балансовому звіті. Це питання обговорювалося в “Розбунтовування PBS: Напрямок протоколом забезпечених зобов'язань пропонентів (PEPC)Валідатор, якому було зменшено винагороду EigenLayer, все ще має повний баланс стейкінгу на балансі протоколу Ethereum, що може спричинити моральний ризик та дисбаланс у винагородах (фактично наполовину стейкнутий валідатор все ще отримує повні винагороди від протоколу Ethereum). Ми деталізуємо ситуацію зменшення винагороди в наступних балансах, даючи довільні числа для ілюстрації проблеми:

Це питання вирішується, як тільки EigenLayer вірно повідомляє про вирізання EigenLayer валідатору протоколу Ethereum, перебалансовуючи аркуші. Це можливо з EIP-7002: Виконавчий шар викликаних виходів, хоча й на грубому рівні, оскільки бінарний тригер просто виходить з валідатора, але для того, щоб активувати сигнал до протоколу Ethereum PoS, все ще потрібний проміжний шар EigenLayer або EigenPod. Ця дія в інтересах EigenLayer, оскільки належне обліку користується послугами, які захищені за допомогою EigenLayer, і також в кінцевому підсумку підвищує довіру операторів і повторних перевіряючих у вірному виконанні платформи.

Більш тонкий тригер може змусити частковий зняття балансу валідатора з консенсусу Ethereum, не виходячи повністю з валідатора. Це бажано для служб EigenLayer, які бажають штрафувати валідаторів частково, не викликаючи виходу. Зауважте, що ні EIP-7002, ні часткові вилучення, спровоковані шаром виконання, не доступні на сьогоднішній день на основній мережі Ethereum. Також зверніть увагу, що @mikeneuder/eip-7251-faq">MaxEB (видалення 32 ETH ліміту на основний валідатор стейкінгу) гарно поєднується з частковими виведеннями, що усуває додатковий стимул для валідаторів залишатися роз'єднаними (запуск багатьох валідаторів з 32 ETH замість одного валідатора з 2048 ETH, наприклад).

Відсутність цієї часткової функції зняття коштів створює додатковий стимул тримати облік EigenLayer окремо від обліку протоколу Ethereum, що, як ми вже зазначали вище, може призвести до невідповідностей. У наступному ми зображуємо валідатора, якому EigenLayer зняв 8 ETH, що не виводить валідатора з його обов'язків у рамках консенсусу (баланс виштовхування становить 16 ETH):

AVS претендує

Хтось може дивуватися, куди пішло 8 [soETH] у попередньому прикладі. Це рішення залишається на вибір Службам, які активно підтверджуються за допомогою EigenLayer (AVS). AVS - це сервіс, що вимагає певного стейкінгу як застави. Наявність стейкінгу дозволяє сервісу віддати вірогідне зобов'язання щодо певної продуктивності, оскільки стейкінг може бути зменшений, якщо сервіс не виконується належним чином.

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

1. AVS стверджує: Ми використовуємо [soETH], щоб позначити ці претензії, підкреслюючи, що вони походять від вартості активу у дужках [ ].
2. Претензія на повторне ставлення: Тепер ми будемо використовувати [soETH]* для підкреслення особливої якості цієї претензії, яку викуповує лише той, хто відновлює ставки, лише після врегулювання всіх інших претензій AVS. Іншими словами, претензія того, хто відновлює ставки, має найнижчий старшинство, викупаючи активи, що залишились після врегулювання всіх інших претензій AVS.

1. Одиночний стейкер переставляє стейки.
   1. Таким чином, soETH перебуває під контролем EigenPod.
   2. [soETH]* отримує соло рестейкер, вимога на їх зарестейковані активи.
2. Самостійний стейкер видає новий клейм, [soETH] зі свого EigenPod.
3. Претензія надається в заставу до AVS.
   1. [soETH] перекладено на AVS.
   2. Ре-ставкер отримує квиток avs.[soETH].

Якщо валідатор діє проти цілей AVS (наприклад, спричинення умови різання AVS), AVS може вирішити, наприклад, спалити претензію валідатора на його ETH, або залишити ставку як дохід AVS. Ми проілюструємо цей другий варіант у наступному, припускаючи, що протокол Ethereum просто зараховує 8 ETH на EigenPod як частковий зняття після звіту про EigenLayer-різання, після чого EigenLayer передає його AVS:

1. AVS знижує заставу одиночного переставника.
   1. Забезпечення AVS складається з 32 [soETH]. Після того як було повідомлено про зменшення, AVS видаляє 8 [soETH] з застави, і повідомляє про зменшення EigenPod, який також зменшує свої зобов'язання на 8 [soETH].
   2. AVS більше не нараховує 32 avs.[soETH] соло рестейкеру, зменшуючи цей вимогу на 8 avs.[soETH].
   3. Бувши знижений AVS, EigenPod зменшує претензію на самостійного повторного стейкера на 8 [soETH]*.
2. EigenPod повідомляє про штрафування протоколу Ethereum, що спричиняє виведення 8 ETH.
   1. Вимога щодо активів, що перебувають у стейкінгу протоколу Ethereum, зменшилася до 24 soETH.
   2. Частковий виведення 8 ETH обробляється, і EigenPod отримує 8 ETH, які раніше були заблоковані в протоколі Ethereum.
3. EigenPod пересилає штраф у розмірі 8 ETH до AVS, яка вільна розпоряджатися ним так, як їй заманеться.

Ре-ре-ре-ре-…-стейкінг

Функція (і ризик), що пропонується EigenLayer, полягає в можливості для повторного стейкера продовжувати вводити нові зобов'язання, які вони обіцяють виконати. Іншими словами, після того, як ставка була знову залучена, знову залучена ставка може бути знову залучена знову, і знову, і знову... З практичної точки зору повторний стейкер вводить нові зобов'язання, підписуючись на більше послуг через свій EigenPod.

Для досягнення повної загальності, та в очікуванні наступних розділів, де активи, крім soETH, будуть перевідкладені, ми позначимо $X$ актив, який перевідкладається перевідкладувачем. Подивимося, як працює перевідкладення декілька разів:

Ми позначаємо актив X, який був перевідкладений p разів. Наразі це просте визначення, але ми намекнемо на деякі властивості цих активів після деталізації кроків цих балансів. EigenPod може друкувати ці зобов'язання на вимогу, ковзаючи нові активи кожного разу, коли перевідкладувач зобов'язується до нових AVSs.

1. Переставник ставить актив X під контроль EigenPod. Цей акт є зобов'язанням з боку переставника, що якщо вони не зможуть надати послуги, на які вони підписалися, частина або весь актив X може бути відібраний у них. Заява [X]* отримана для підтвердження цього зобов'язання.
2. Ми деталізуємо тут переставника, який зобов'язується забезпечити безпеку ланцюга Y.
   1. Пере-стейкер отримує перший переставлений актив [X]¹, увійшовши до AVS «Забезпечення ланцюга Y».
   2. Повторний стейкер ставить [X]¹ під ланцюг Y, отримуючи soY.[X]¹ (вимога за їх стейк + винагорода - штрафи). Ланцюг Y повинен «розуміти», що повторно стейкований актив наразі забезпечує його протокол, тобто він повинен бути впевнений, що є щось на кону для когось.
3. Ми деталізуємо тут переставника, який зобов'язується забезпечити безпеку ланцюга Z.
   1. Ре-ставкер отримує ре-ставлене майно [X]², увійшовши в ланцюг забезпечення AVS "Забезпечення ланцюга Z".
   2. Переставник ставить [X]² під ланцюг Z, отримуючи soZ.[X]² (вимога щодо їх ставки + винагорода - пеня). Ланцюг Z повинен «розуміти», що переставлений актив в даний час забезпечує його протокол, тобто повинен бути впевнений, що є щось на кону для когось.

На основі вищезазначених балансів ми тепер вирішуємо деякі питання. Ми спостерігаємо, що ланцюг Y отримує [X]¹, тоді як ланцюг Z отримує [X]². Чи ці активи одного й того ж типу, і чи можемо ми просто сказати, що вони обидва отримують активи типу [X]?

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

1. Case 1: AVSs, тут ланцюги Y та Z механізми консенсусу, просто спалюють токени, які були знищені, що робить більшість протоколів PoS. Коли токени знищені, ієрархія претензій насправді не має значення: Якщо обидва ланцюги Y та Z хотіли б знищити токени знову за 32 ETH, все, що вони досягають, це подвійне знищення одного й того ж заставного.
   1. Примітка: Андерс називає це «спрі-стейкінг», повторно стейкуючи кілька разів без ієрархії претензій 😊
2. Випадок 2: AVSs хочуть отримати токени, які перебувають під загрозою, наприклад, компенсувати якісь сторони, які були обмануті. Один приклад тут єMEV-Boost+, оператор AVS є пропонентом блоку, який зобов'язується не маніпулювати отриманим відкритим вмістом блоку, і якщо вони це роблять, вони зобов'язуються компенсувати будівничого та реле за безлад. У цьому випадку, припустимо, що кілька AVS викупають свої вимоги одночасно внаслідок паралельних відхилень тим же пере-ставкером, і не вистачає ставок, щоб покрити всі вимоги. Тоді питання старшинства вимог або розподілу виплат стає актуальним.

Розбунтовування AVSs

У попередньому розділі ми представили AVS – це послуги, які зобов'язується надавати валідатор повторного стейкінгу. Зобов'язання забезпечується через EigenLayer, який бере на себе право власності на частку рестейкера, що перевіряється, і врегулює претензії, висунуті AVS.

Але що саме таке AVS? Так само, як ми розділили вище протоколи LST та оператори LST, тут має сенс обговорити ці дві функціональні ролі окремо та призначити їм різні активи та вимоги.

Коротко кажучи, AVS вимагає заставу для надання послуг, наприклад, AVS робить достовірне твердження, що атака на AVS призведе до втрати певної частки застави, що наразі утримується AVS. AVS тут розглядається як протокол, який залучає операторів для надання послуг. Ми потім розрізняємо два способи взаємодії між re-stakers та AVS:

1. Рестейкери як оператори AVS: AVS втілює протокол, який шукає операторів для функціонування, а оператори вузлів, які повторно здійснюють стейкінг своїх soETH, самі стають операторами протоколу AVS.
2. Re-stakers як постачальники капіталу для оператора AVS: У цьому випадку оператор AVS приймає (повторно) стейкові активи для виконання своєї функції оператора від імені делегаторів, що надають капітал. Після цього рестейкер делегує свої повторно стейковані активи операторові AVS, який виконує певну функцію від імені рестейкера.

У вищевказаних розділах ми визначили перевіряючого перезавантажувача як постачальника капіталу (їхня власна ставка перезавантажується) та оператора AVS (вимагається, щоб вони самі надали певні послуги). Однак ми можемо розглянути іншу конструкцію, де перевіряючий перезавантажувач не працює з AVS самостійно, а замість цього делегує цю функцію деякому оператору. Це може дозволити соло перезавантажувачам конкурувати за доходність з інтегрованими постачальниками послуг стейкінгу (SSP)/операторами. У наведеному прикладі вводиться ситуація, де один оператор AVS перевіряє на деяких ланцюгах Y та Z від імені перезавантажувача. Ми робимо припущення, що всі претензії AVS є одного типу [X] (жодної ієрархії претензій).

1. Переставляючи, користувач ставить актив X під контроль EigenPod. Ця дія є зобов'язанням від переставляючого, що у разі невиконання обов'язків, на які вони підписались, частина або весь актив X може бути вилучений у них. Вимога [X]* надходить для представлення цього зобов'язання.
2. Ми докладно описуємо тут пере-стейкера, який зобов'язується забезпечити безпеку ланцюга Y, делегуючи обов'язки валідації оператору AVS.
   1. Re-staker отримує переставлений актив [X], увійшовши до AVS «Забезпечення ланцюга Y».
   2. Ре-стейкер передає ре-ставлене майно [X] оператору AVS, отримуючи «квиток» noY.[X].
   3. Оператор AVS ставить [X] під ланцюгом Y, отримуючи таким чином [X] (вимога за їх ставку + винагорода - штрафи). Ланцюг Y повинен «розуміти», що перевірений актив в даний час захищає його протокол, тобто він повинен бути впевнений, що є щось на кону для когось.
3. Ми деталізуємо тут рестейкер, який зобов'язується забезпечити безпеку ланцюга Z, делегуючи обов'язки валідації оператору AVS.
   1. Re-staker отримує переставлений актив [X], увійшовши в AVS «Забезпечення ланцюгом Y».
   2. Рестейкер передає рестейкінгований актив [X] оператору AVS, отримуючи «квиток» noZ.[X].
   3. Оператор AVS ставить [X] під ланцюгом Z, отримуючи soZ.[X] (вимога за їхнім стейком + винагорода - штрафи). Ланцюг Z повинен «розуміти», що переставлений актив зараз захищає його протокол, тобто він повинен бути впевнений, що є щось на ставку для когось.

У цій парадигмі ми відновлюємо знайомі конструкції. Рестейкер отримує актив без активу, вже натякаючи на можливість зрідження таких позицій. Ми обговоримо ці передові конструкції в наступному пості, але перш ніж це зробити, давайте згадаємо поточні дослідження «PBS для AVS» як підходу до зменшення централізації операторів.

ПідОптимістична система делегування (ODF)запропоновано Дрю Ван дер Верф (див. такожДоповідь на недавньому семінарі з криптоекономіки у Колумбії від 0xKydo) , re-staker може укласти угоду про операції з AVSs, на які він підписується, на відкритому ринку "співпроцесорів". Співпроцесори можуть бути ідентифіковані ролью "будівельника" PBS, спеціалізованою сутністю, здатною виконувати потенційно інтенсивні операції, які недоступні для несофістикованих або обмежених обчисленнями сутностей, таких як сольні стейкери. Співпроцесори подають пропозиції re-stakerам в аукціонному стилі закупівель, що дозволяє re-stakerу визначити найбільш прибуткового оператора. Для подальшого гарантування продуктивності співпроцесори є обліковими учасниками, відкриваючи себе втраті застави, якщо вони подають доказово недійсний шматок роботи під час своїх операцій.

Disclaimer：

1. Ця стаття перепублікована з [ дзеркало], Усі авторські права належать оригінальному авторові [Ціна агентства]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Навчаннякоманда, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно власністю автора і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.