Перед тем как вы погрузитесь в изучение статьи, обратите внимание на тот факт что всё упомянутое в ней не является финансовой рекомендацией для принятие более взвешенного решения просьба провести свое собственное исследование.
В контексте AVS, операторы играют ключевую роль — пользователи делегируют им средства, что обеспечивает безопасность AVS.
Здесь видна распределенная архитектура, в которой стейкер и оператор разделены. При этом, они связаны посредством взаимодействия контрактов Delegation Manager, который отвечает за делегированные средства и выбираемый TokenPool. Впоследствии, “слэшерам” отправляются запросы для проверки процесса на предмет наличия мошенничества.
Если сделать архитектуру ещё более модульной, чем в абзаце выше, то это привнесет ещё большее быстродействие и надежность и будет выглядеть следующим образом:
Внедряются еще несколько смарт-контрактов:
DA, или доступность данных — это концепция в блокчейне, которая гарантирует, что определенные данные будут доступны всем, кто хочет их получить. Это особенно важно для децентрализованных приложений (dApps) и протоколов, которые требуют надежного хранения данных и постоянного, а главное быстрого доступа к ним.
— Основные аспекты DA:
Недавно был проведен эксперимент. В EigenDA одновременно загрузили блоки:
EigenDA работает на основе трех компонентов:
Принцип работы EigenDA
EigenLayer был разработан с продуманной архитектурой, которая при необходимости позволяет обновлять смрат-контракты. Также, имеется функция приостановки протокола на случай чрезвычайной ситуации.
Operations Multisig: Возможность и ответственность за принятие решений относительно обновлений контрактов, приостановки функциональности и корректировки параметров изначально были делегированы шести основным мультиподписям управления 3/6. То есть, консенсус достигается при согласии половины владельцев мультиподписи — это касается “главного” управленческого инструмента.
Pauser Multisig: Также, есть менее влиятельная мультиподпись 1/14, которая может лишь приостанавливать протокол. То есть, решения одного участника будет достаточно для временного приостановления деятельности протокола.
Community Multisig: Данная мультиподпись может выполнять экстренные действия, включая немедленное выполнение срочных обновлений или замену Operations Multisig в случае компрометации закрытого ключа. Она включает в себя 13 участников из сообщества Ethereum, и консенсус достигается при согласии 9 из 13 участников.
Операторы
Стейкер — зависимый от оператора участник. Зависимость вызвана тем, что “проводником” между Стейкером и TokenPool, которые в тандеме обеспечивают безопасность приложений, является оператор. Операторы — это участники в экосистеме рестейкинга. Они регистрируются в EigenLayer и позволяют стейкинг-валидаторам делегировать свои активы. Каждый участник может стать оператором, но это затруднительная и затратная процедура, так что, многие делегируют свои средства уже запущенным операторам. Операторы не обязаны иметь минимальное количество делегированных токенов, и получают 10% общих вознаграждений, остальные 90% распределяются пропорционально среди стейкеров.
В контексте AVS, операторы играют ключевую роль — пользователи делегируют им средства, что обеспечивает безопасность AVS.
Модульность
Модульная архитектура достигается путём упрощения контрактов, вследствие чего Eigenlayer выглядит следующим образом:
Здесь видна распределенная архитектура, в которой стейкер и оператор разделены. При этом, они связаны посредством взаимодействия контрактов Delegation Manager, который отвечает за делегированные средства и выбираемый TokenPool. Впоследствии, “слэшерам” отправляются запросы для проверки процесса на предмет наличия мошенничества.
Если сделать архитектуру ещё более модульной, чем в абзаце выше, то это привнесет ещё большее быстродействие и надежность и будет выглядеть следующим образом:
Внедряются еще несколько смарт-контрактов:
- TokenManager управляет стейкингом и выводами средств.
- DelegationManager позволяет операторам отслеживать доли.
- SlasherManager предоставляет разработчикам AVS интерфейс для определения логики слэша.
EigenDA
— Что такое DA (Data Availability)?DA, или доступность данных — это концепция в блокчейне, которая гарантирует, что определенные данные будут доступны всем, кто хочет их получить. Это особенно важно для децентрализованных приложений (dApps) и протоколов, которые требуют надежного хранения данных и постоянного, а главное быстрого доступа к ним.
— Основные аспекты DA:
- Гарантия доступности: DA обеспечивает уверенность в том, что существующие данные действительно можно получить и использовать.
- Безопасность: Системы DA должны соответствовать условиям, которые гарантируют безопасность данных.
- Пропускная способность: Это скорость, с которой система может принимать и обрабатывать данные — чем выше, тем лучше.
Недавно был проведен эксперимент. В EigenDA одновременно загрузили блоки:
- L1s: Bitcoin, Ethereum, Solana, Celo, Celestia, Avalanche, BNB chain, Fantom.
- L2s: Polygon, Mantle, Base, Arbitrum, Optimism, XAI games, Blast, Scroll, ZKSync, Mode, Taiko.
EigenDA работает на основе трех компонентов:
- Операторы EigenDA — это сторонние участники, работающие на узлах EigenDA через EigenLayer. Успешная проверка данных позволяет оператору сохранить объект и отправить подтверждение обратно.
- Дисперсер EigenDA управляет взаимодействием между клиентами, операторами и контрактами.
- Ретривер EigenDA запрашивает данные у операторов, проверяет их и восстанавливает исходный объект для пользователя.
Принцип работы EigenDA
- Секвенсор: Это система, которая собирает пакет транзакций и отправляет его в EigenDA в виде большого двоичного объекта (блоба).
- Дисперсер: Этот модуль разбивает блоб на более мелкие части (фрагменты) и создает специальный код (обязательство KZG), который подтверждает, что каждая часть правильная. Затем дисперсер отправляет эти части операторам EigenDA и получает от них подтверждения (подписи), что они хранят эти фрагменты.
- Аггрегация подписей: После получения всех подписей дисперсер объединяет их и регистрирует блоб в блокчейне, отправляя транзакцию в контракт EigenDA Manager с агрегированной подписью и данными блоба.
- Проверка: Контракт EigenDA Manager проверяет агрегированную подпись с помощью контракта EigenDA Registry и сохраняет результат в блокчейне.
- Идентификатор блоба: После того как блоб был успешно зарегистрирован, секвенсор публикует его идентификатор в своем контракте входящих сообщений. Этот идентификатор не превышает 100 байт.
- Проверка доступности: Прежде чем принять идентификатор блоба, контракт входящих проверяет у контракта менеджера EigenDA, сертифицирован ли блоб как доступный. Если да, идентификатор принимается; если нет — он отклоняется.
EigenLayer был разработан с продуманной архитектурой, которая при необходимости позволяет обновлять смрат-контракты. Также, имеется функция приостановки протокола на случай чрезвычайной ситуации.
Operations Multisig: Возможность и ответственность за принятие решений относительно обновлений контрактов, приостановки функциональности и корректировки параметров изначально были делегированы шести основным мультиподписям управления 3/6. То есть, консенсус достигается при согласии половины владельцев мультиподписи — это касается “главного” управленческого инструмента.
Pauser Multisig: Также, есть менее влиятельная мультиподпись 1/14, которая может лишь приостанавливать протокол. То есть, решения одного участника будет достаточно для временного приостановления деятельности протокола.
Community Multisig: Данная мультиподпись может выполнять экстренные действия, включая немедленное выполнение срочных обновлений или замену Operations Multisig в случае компрометации закрытого ключа. Она включает в себя 13 участников из сообщества Ethereum, и консенсус достигается при согласии 9 из 13 участников.