Основы повторного стейкинга

Для некоторого актива X мы обозначаем через [X] переосложненный актив, то есть актив, "упаковывающий" X таким образом, что часть или весь X может быть захвачен какой-либо стороной при наличии произвольного условия.

Базовый пример, представленный EigenLayer, заключается в том, что соло-стейкер снова ставит свои текущие ETH на стейкинг. Для этого соло-стейкер обновляет свой адрес для вывода на адрес Под EigenLayerEigenPods - это смарт-контракты, которые отслеживают, за какие услуги соло-стейкер подписался, чтобы обеспечить их стейкингом. 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, что, как мы отметили выше, может привести к несоответствиям. В следующем примере изображен валидатор, лишенный 8 ETH EigenLayer, что не выводит валидатора из его обязанностей по консенсусу (баланс исключения составляет 16 ETH):

AVS утверждает

Можно задаться вопросом, куда девается 8 [soETH] в предыдущем примере. Это решение остается за службами, активно проверяемыми с помощью EigenLayer (AVS). AVS - это служба, требующая определенной ставки в качестве залога. Наличие залога позволяет службе сделать достоверное обязательство по выполнению определенной работы, поскольку залог может быть сокращен, если служба не выполняется должным образом.

Валидатор, который делает повторный стейкинг, регистрируется в AVS через свой EigenPod. Когда он это делает, EigenPod чеканит новые претензии, которые предлагаются AVS и представляют залог, который в настоящее время находится в EigenPod. Теперь мы должны провести различие между двумя типами претензий:

1. AVS утверждает: Мы используем [soETH], чтобы обозначить эти утверждения, подчеркивая, что они происходят от стоимости актива в квадратных скобках [ ].
2. Re-staker claim: Теперь мы будем использовать [soETH]* для подчеркивания особенного качества этого требования, которое может быть использовано только владельцем Re-staker после того, как все AVS требования будут урегулированы. Другими словами, требование Re-staker имеет самый низкий приоритет и используется для восстановления активов, оставшихся после урегулирования всех остальных AVS требований.

1. Одинокий стейкер перепоставляет.
   1. Таким образом, soETH находится под контролем EigenPod.
   2. [soETH]* получает сольный ре-стейкер, претензию на их ре-стейкнутые активы.
2. Одинокий стейкер создает новый клим, [soETH] из своего EigenPod.
3. Заявление предоставляется в залог в AVS.
   1. [soETH] переводится на AVS.
   2. Re-staker получает квитанцию 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 актив X, заново стейкаемый p раз. Пока это простое определение, но мы намекнем на некоторые свойства этих активов после детального изложения шагов этих балансов. EigenPod способен печатать эти обязательства по своему усмотрению, создавая новые активы всякий раз, когда заново стейкер обязывается к новым AVSs.

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

Исходя из вышеприведенных балансов, теперь мы рассмотрим несколько вопросов. Мы замечаем, что цепочка Y получает [X]¹, в то время как цепочка Z получает [X]². Являются ли эти активы одного типа, и можно ли сказать, что обе они получают активы типа [X]?

Ответ был бы отрицательным, если бы существовала иерархия AVS-претензий. Представьте себе ситуацию, когда рестейкер совершает нарушения, подлежащие штрафу, на обеих цепях одновременно, и обе цепи хотят штрафовать весь залог. Мы можем тогда рассмотреть два случая:

1. Случай 1: AVSs, здесь механизмы консенсуса цепей Y и Z, просто сжигают токены, которые были обесценены, что является типичным для большинства протоколов PoS. Когда токены сжигаются, иерархия требований на самом деле не имеет значения: если обе цепи Y и Z хотели бы обесценить повторного стейкера на 32 ETH, все, что они делают, - это сжигают один и тот же заложенный дважды коллатерал.
   1. Примечание: Андерс называет это "спри-стейкинг", многократное повторное стейкинг без иерархии претенций 😊
2. Случай 2: AVSs хотят получить токены, которые находятся под страховкой, например, чтобы компенсировать какую-то сторону, которая была оскорблена. Пример здесь MEV-Boost+, оператор AVS является предложителем блока, который обязуется не вмешиваться в содержимое блока, полученное открытым текстом, и если это происходит, он обязуется компенсировать строителя и реле за беспорядок. В этом случае предположим, что несколько AVS одновременно выкупают свои требования после параллельных отклонений тем же переставщиком, и ставка не хватает на покрытие всех требований. Тогда вопрос старшинства требований или распределения выплат становится актуальным.

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

В предыдущем разделе мы познакомились с AVSs, которые представляют собой услуги, на которые обязуется предоставить стейкинг-валидатор. Обязательство обеспечивается посредством EigenLayer, которая берет на себя владение стейком валидатора и урегулирует претензии, выдвигаемые AVSs.

Но что такое AVS на самом деле? Подобно тому, как мы выше разделили протоколы LST и операторов LST, здесь имеет смысл обсудить эти две функциональные роли отдельно и назначить им разные активы и требования.

Короче говоря, AVS требует залога для предоставления услуги, например, AVS делает правдоподобное заявление о том, что атака на AVS приведет к потере некоторой части залога, в настоящее время удерживаемого AVS. AVS здесь рассматривается как протокол, привлекающий операторов для предоставления услуг. Затем мы разъясняем два способа взаимодействия с AVS, которые могут использовать повторные стейкеры:

1. Ре-стейкеры в качестве операторов AVS: AVS воплощает в себе протокол, который ищет операторов для функционирования, а операторы узлов, которые повторно ставят свои soETH, сами становятся операторами протокола AVS.
2. Re-stakers as capital providers for an AVS operator: В этом случае оператор 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. Ре-стейкер получает ре-застейкенный актив [X], вступая в AVS "Защищающая цепь Y".
   2. Ре-стейкер передает пере-заложенный актив [X] оператору AVS, получая "квитанцию" noZ.[X].
   3. Оператор AVS ставит [X] под цепочку Z, получая таким образом [X] (заявку на свою ставку + вознаграждение - штрафы). Цепочка Z должна «понимать», что повторно поставленный актив в данный момент обеспечивает ее протокол, т.е. она должна быть уверена, что у кого-то что-то на кону.

В этой парадигме мы восстанавливаем знакомые конструкции. Никакое имущество не получает ре-стейкер, уже намекая на возможность ликвидации таких позиций. Мы обсудим эти продвинутые конструкции в следующем посте, но перед этим давайте упомянем текущие исследования по «PBS для AVS» как подход к снижению централизации операторов.

ПодОптимистичная система делегирования (ODF)предложенный Дрю Ван дер Верф (см. такжеДоклад недавнего мастер-класса по криптоэкономике в Колумбии 0xKydo) рестейкер может заключить сделку по эксплуатации AVS, на которые он подписывается на открытом рынке «сопроцессоров». Сопроцессоры могут быть идентифицированы с ролью «строителя» PBS, специализированной сущности, способной выполнять потенциально интенсивные операции, которые недоступны неопытным или ограниченным вычислительными ресурсами сущностям, таким как соло-стейкеры. Сопроцессоры подают заявки на рестейкеров в рамках механизма аукциона закупок, позволяя рестейкеру определить наиболее прибыльного оператора. Для дальнейшего обеспечения производительности сопроцессоры являются участниками с обязательством, подвергая себя риску потерять свою обязательную сумму, если они представляют доказуемо недействительный кусок работы в ходе своей деятельности.

Disclaimer：

1. Эта статья перепечатана из [зеркало], Все авторские права принадлежат оригинальному автору [Цена агентства]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и они быстро справятся с этим.
2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.