Завьялов Илья Николаевич про EigenLayer (Ч.2).

Перед тем как вы погрузитесь в изучение статьи, обратите внимание на тот факт что всё упомянутое в ней не является финансовой рекомендацией для принятие более взвешенного решения просьба провести свое собственное исследование.

Операторы 

Стейкер — зависимый от оператора участник. Зависимость вызвана тем, что “проводником” между Стейкером и TokenPool, которые в тандеме обеспечивают безопасность приложений, является оператор. Операторы — это участники в экосистеме рестейкинга. Они регистрируются в EigenLayer и позволяют стейкинг-валидаторам делегировать свои активы. Каждый участник может стать оператором, но это затруднительная и затратная процедура, так что, многие делегируют свои средства уже запущенным операторам. Операторы не обязаны иметь минимальное количество делегированных токенов, и получают 10% общих вознаграждений, остальные 90% распределяются пропорционально среди стейкеров.

В контексте AVS, операторы играют ключевую роль — пользователи делегируют им средства, что обеспечивает безопасность AVS.

Модульность

Модульная архитектура достигается путём упрощения контрактов, вследствие чего Eigenlayer выглядит следующим образом:

Здесь видна распределенная архитектура, в которой стейкер и оператор разделены. При этом, они связаны посредством взаимодействия контрактов Delegation Manager, который отвечает за делегированные средства и выбираемый TokenPool. Впоследствии, “слэшерам” отправляются запросы для проверки процесса на предмет наличия мошенничества.

Если сделать архитектуру ещё более модульной, чем в абзаце выше, то это привнесет ещё большее быстродействие и надежность и будет выглядеть следующим образом:

Внедряются еще несколько смарт-контрактов:

• TokenManager управляет стейкингом и выводами средств.
• DelegationManager позволяет операторам отслеживать доли.
• SlasherManager предоставляет разработчикам AVS интерфейс для определения логики слэша. 

EigenDA 

— Что такое DA (Data Availability)?

DA, или доступность данных — это концепция в блокчейне, которая гарантирует, что определенные данные будут доступны всем, кто хочет их получить. Это особенно важно для децентрализованных приложений (dApps) и протоколов, которые требуют надежного хранения данных и постоянного, а главное быстрого доступа к ним.

— Основные аспекты DA: 

1. Гарантия доступности: DA обеспечивает уверенность в том, что существующие данные действительно можно получить и использовать.
2. Безопасность: Системы DA должны соответствовать условиям, которые гарантируют безопасность данных.
3. Пропускная способность: Это скорость, с которой система может принимать и обрабатывать данные — чем выше, тем лучше.

EigenDA — масштабируемое хранилище данных с пропускной способностью 15мб/с (120Mbps), является самым быстродействующим DA из ныне существующих. В планах, обозначено развитие пропускной способности до 100мб/с и более. Ключевым преимуществом продукта является то, что EigenDA не нужен собственный токен, поскольку безопасность обеспечивается депонированным $ETH. Это более выигрышная позиция относительно других проектов из этой категории — Dymension, Celestia, Avail. Также, важно выделить что масштабируемость тут происходит как горизонтально так и линейно. То есть, большее количество операторов позволяет масштабироваться более эффективно.

Недавно был проведен эксперимент. В EigenDA одновременно загрузили блоки:

• L1s: Bitcoin, Ethereum, Solana, Celo, Celestia, Avalanche, BNB chain, Fantom.
• L2s: Polygon, Mantle, Base, Arbitrum, Optimism, XAI games, Blast, Scroll, ZKSync, Mode, Taiko.

Как следствие, протокол был загружен всего лишь на 54%.

EigenDA работает на основе трех компонентов:

• Операторы EigenDA — это сторонние участники, работающие на узлах EigenDA через EigenLayer. Успешная проверка данных позволяет оператору сохранить объект и отправить подтверждение обратно.
• Дисперсер EigenDA управляет взаимодействием между клиентами, операторами и контрактами.
• Ретривер EigenDA запрашивает данные у операторов, проверяет их и восстанавливает исходный объект для пользователя.

Принцип работы EigenDA

1. Секвенсор: Это система, которая собирает пакет транзакций и отправляет его в EigenDA в виде большого двоичного объекта (блоба).
2. Дисперсер: Этот модуль разбивает блоб на более мелкие части (фрагменты) и создает специальный код (обязательство KZG), который подтверждает, что каждая часть правильная. Затем дисперсер отправляет эти части операторам EigenDA и получает от них подтверждения (подписи), что они хранят эти фрагменты.
3. Аггрегация подписей: После получения всех подписей дисперсер объединяет их и регистрирует блоб в блокчейне, отправляя транзакцию в контракт EigenDA Manager с агрегированной подписью и данными блоба.
4. Проверка: Контракт EigenDA Manager проверяет агрегированную подпись с помощью контракта EigenDA Registry и сохраняет результат в блокчейне.
5. Идентификатор блоба: После того как блоб был успешно зарегистрирован, секвенсор публикует его идентификатор в своем контракте входящих сообщений. Этот идентификатор не превышает 100 байт.
6. Проверка доступности: Прежде чем принять идентификатор блоба, контракт входящих проверяет у контракта менеджера EigenDA, сертифицирован ли блоб как доступный. Если да, идентификатор принимается; если нет — он отклоняется.

EigenLayer был разработан с продуманной архитектурой, которая при необходимости позволяет обновлять смрат-контракты. Также, имеется функция приостановки протокола на случай чрезвычайной ситуации.

Operations Multisig: Возможность и ответственность за принятие решений относительно обновлений контрактов, приостановки функциональности и корректировки параметров изначально были делегированы шести основным мультиподписям управления 3/6. То есть, консенсус достигается при согласии половины владельцев мультиподписи — это касается “главного” управленческого инструмента.

Pauser Multisig: Также, есть менее влиятельная мультиподпись 1/14, которая может лишь приостанавливать протокол. То есть, решения одного участника будет достаточно для временного приостановления деятельности протокола.

Community Multisig: Данная мультиподпись может выполнять экстренные действия, включая немедленное выполнение срочных обновлений или замену Operations Multisig в случае компрометации закрытого ключа. Она включает в себя 13 участников из сообщества Ethereum, и консенсус достигается при согласии 9 из 13 участников.