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

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

Что такое EigenLayer

EigenLayer — рестейкинг-протокол, предоставляющий возможность повторного использования застейканного в Beacon Chain ETH. Иными словами, при помощи EigenLayer ETH может быть одновременно использован для обеспечения безопасности как сети Ethereum, так и созданных на основе EigenLayer приложений (они же — AVS-ы).

Зачем нужен токен EIGEN

Во-первых, это не гавернанс-токен типа ENA или REZ. Во-вторых, чтобы понять место EIGEN в экосистеме EigenLayer, придется разобраться с десятком новых концептов и терминов, предложенных командой Eigen Labs в 43-страничном документе, посвященном EIGEN-у. С этого и начнем!

Work Token

В основу proof-of-stake блокчейнов заложена следующая логика. Чтобы выполнять работу (digital work), необходимую для функционирования блокчейна (подтверждение блоков, участие в голосованиях и т. п.), и получать соответствующее вознаграждение за это, необходимо застейкать нативный для этого блокчейна токен в определенном количестве. В случае некачественного выполнения работы соответствующий валидатор лишается застейканных токенов (эти токены слешатся). Такие токены команда Eigen Labs предлагает именовать work tokens — к ним относятся ETH, SOL и прочие токены L1-POS-сетей.

Universal Objective Work Token

Обычно work token создается и используется для выполнения конкретных задач (digital tasks) в рамках одного блокчейна/протокола — ETH обеспечивает безопасность сети Ethereum, SOL — сети Solana и т.п. EigenLayer трансформирует ETH в универсальный work token. Иными словами, EigenLayer расширяет функционал ETH, позволяя использовать его для выполнения работы не только для сети Ethereum, но и для других протоколов (например, оракулов или мостов, созданных как AVS-ы с использованием EigenLayer). Таким образом, из просто work token’a ETH превращается в универсальный work token.

Faults in Digital Tasks

При выполнении цифровых задач возможны ошибки (faults) — это могут быть случайные (напр., в связи с багом в коде клиента) либо преднамеренные (напр., попытка двойной траты) ошибки либо невыполнение принятой на себя работы. За совершение подобных ошибок стейк валидатора в L1-POS-сети слэшится. Команда Eigen Labs предлагает разделять все ошибки на:

 ⁃ Objectively Attributable Faults — объективные ошибки, которые могут быть обнаружены алгоритмически/математически и для обнаружения которых не требуется чье-либо субъективное мнение (напр., подписание валидатором двух конфликтующих блоков);

 ⁃ Intersubjectively Attributable Faults — ошибки, наличие которых очевидно для большинства наблюдателей системы, но которые при этом не могут быть обнаружены алгоритмически/математически (напр., некорректное предоставление оракулом данных из внешнего мира в блокчейн);

 ⁃ Non-attributable Faults — факты и события, в отношении которых для наблюдателя невозможно сформулировать вывод об их корректности/ошибочности (напр., предполагаемое раскрытие приватной информации валидаторами приватной сети);

 ⁃ Subjective Faults — факты и события, в отношении которых возможна только субъективная оценка, но не тезис об их корректности/ошибочности (напр., рейтинг ресторанов).

Меня зовут Завьялов Илья Николаевич. Я предприниматель и увлекаюсь финансами. Добро пожаловать в мой блог.

Medium — medium.com/@IliaNicolaevichZavialov  

Substack — ilianicolaevichzavialov.substack.com/

Где лежит грань между вторым и четвертым пунктом, может спросить внимательный читатель. “Мы сами точно не знаем” — ответит команда Eigen Labs, используя однако куда более туманные формулировки. Так или иначе, на этом этапе важно запомнить второй вид ошибок — именно ради них существует EIGEN.

Tyranny-of-majority

Тирания большинства. Ситуация, когда большинство валидаторов злонамеренно нарушают правила сети (например, подписывают конфликтующие блоки). В Ethereum заложены защитные механизмы, обеспечивающие слэшинг таких валидаторов и сохранение целостности и непрерывности основной каноничной сети. На практике это означает, что даже в случае сговора 80% валидаторов не согласные с ними честные ноды всегда могут форкнуть сеть, при этом корректность их сети (несмотря на то, что поддержали ее меньшинство валидаторов) будет очевидна всем сторооним наблюдателям. 

Суть токена EIGEN

Заявленная цель создания EIGEN — создание универсального фреймворка для внедрения криптоэкономической безопасности от интерсубъективных ошибок (intersubjectively attributable faults), допущенных стейкерами EIGEN, без тирании большинства.

Если более простым языком, то EIGEN и EigenLayer для ошибок этого вида (применительно к любому протоколу/AVS) хотят стать тем, чем ETH и Ethereum являются для ошибок первого вида (применительно к консенсусу в Ethereum).

Если совсем простым языком. Косяки при выполнении работы для Ethereum выявляются автоматически (ну почти), а накосячивший теряет свои ETH, при этом защита от тирании большинства обеспечивается возможностью форка сети. Косяки при выполнении работы для протоколов поверх EigenLayer будут выявляться другими людьми, а накосячивший будет терять свои EIGEN, при этом защита от тирании большинства будет обеспечиваться возможностью форка EIGEN.

Рестейкинг ETH через EigenLayer vs. стейкинг EIGEN

Задумка команды Eigen Labs следующая:

 ⁃ рестейкнутый ETH будет использоваться для разрешения споров, связанных с objectively attributable faults;

 ⁃ застейканный EIGEN будет использоваться для разрешения споров, связанных с intersubjectively attributable faults.

Еще раз, зачем нужен EIGEN?

EIGEN будет защищать AVS-ы от интерсубъективных ошибок. Например, задеплоенный в виде AVS-а оракул сможет использовать для своей работы:

 ⁃ рестейкнутый ETH, который будет слэшиться у операторов, допустивших объективные ошибки (напр., двойное подписание чего-то, что нельзя подписывать два раза);

 ⁃ застейканный EIGEN, который будет обеспечивать защиту от ошибок, наличие которых не может быть проверено алгоритмически “внутри блокчейна” (напр., злонамеренной передачи информации о цене BTC в $1 вместо положенных $60k).

В отличие от ETH, EIGEN будет не слэшиться, а форкаться. Это попытка “вшить” в EIGEN механику социального консенсуса — только вместо выбора каноничной сети выбираться будет каноничный контракт EIGEN’а. Короче slashing for objective failures and forking for subjective failures. 

Как работает форк EIGEN?

В случае предполагаемой интерсубъективной ошибки (то есть ошибки, факт которой не может быть подтвержден внутри блокчейна алгоритмически) оператора AVS-а любой желающий (ну почти) может инициировать спор. В рамках этого спора создается форк EIGEN-токена, а по итогам спора по заранее определенным правилам социального консенсуса определяется “правильная” версия EIGEN’a. Примерно тридцать страниц вайтпейпера посвящены описанию того:

 ⁃ как нам форкать EIGEN так, чтобы это проходило незаметно для не-стейкеров, например тех кто использует EIGEN в дефи или держит на кошельке/бирже (для этого придумали разделение на EIGEN и bEIGEN);

 ⁃ как правильно врапать (to wrap) bEIGEN в EIGEN и обратно;

 ⁃ как правильно настроить экономику форка (для этого придумали Deflation-per-fork/DPF, Commitment-per-fork/CPF и пр.);

 ⁃ какой порядок действий и тайминги нужны для форка EIGEN;

 ⁃ как правильно рассчитать криптоэкономическую безопасность (для этого придумали способы расчета cost-of-corruption, profit-from-corruption и пр.);

 ⁃ как будет работать форк EIGEN в условиях множества активных AVS-ов;

 ⁃ какие приложения можно строить поверх этой архитектуры, и какое будущее ждет EigenLayer.

Ответы (имхо не всегда убедительные) на эти вопросы можно найти в вайтпейпере. 

Что еще интересного в вайтпейпере

По всему документу мы читаем, что стейкинг EIGEN нужен для споров по intersubjectively attributable faults. Речь идет об ошибках, в отношении кототорых имеется “почти универсальное согласие наблюдателей”. Кто определяет, когда такое согласие имеется? Что мешает проектам использовать стейкинг EIGEN для разрешения споров о subjective faults? Если ничего, то почему EIgen Labs активно отмахивается от этого юзкейса?

Некоторые из предложенных механик я не смог понять (например, о роли держателей bEIGEN в AVS’ах, не связанных с текущим спором, криптоэкономической математике и мониторинге косяков операторов AVS'ов) — полагаю, не все механики понимают и авторы вайтпейпера, а описанные в нем концепты будут дополняться и корректироваться.

Интересно, что предполагается предоставление большой свободы AVS’ам (архитектура лайт-нод для проверки ошибок, отдельные правила разрешения споров и форка bEIGEN и пр.) — если такой подход сохранится, мы неизбежно увидим рано или поздно косяки в коде со стороны AVS’ов и последующие за ними слэшинги и форки.