Що сталося на ринку повторного стейкінгу? Аналіз помилок і успіхів у дизайні EigenLayer через два роки

Глибокий ретроспективний аналіз шляху повторного стейкінгу EigenLayer: пройдені труднощі, внесок EigenDA — усе це прокладає шлях до нового напрямку EigenCloud. Ця стаття написана Кайдо, відповідальним за наратив EigenCloud, підготовлена, перекладена та написана Саорсою для Foresight News.

(Передісторія: Звіт на 10 000 слів — всебічне розуміння лідера повторного стейкінгу EigenLayer) (Додаткова інформація: Що таке флагманський продукт протоколу повторного стейкінгу EigenLayer — EigenDA?)

Час від часу друзі надсилають мені іронічні твіти про повторний стейкінг, але жоден із них не потрапляє в суть проблеми. Тому я вирішив написати власну рефлексійну «статтю-скаргу».

Можливо, ви вважаєте, що я занадто близько до цієї справи, щоб бути об’єктивним; або що я занадто гордий, щоб визнати, що ми «прорахувалися». Ви можете подумати, що навіть якщо всі вже впевнені у «провалі повторного стейкінгу», я все одно напишу довгу статтю на захист і так і не визнаю слово «провал».

Ці погляди цілком логічні, і багато з них мають під собою підстави.

Але ця стаття має на меті лише об’єктивно показати факти: що саме сталося, що вдалося реалізувати, що ні, і які уроки ми з цього винесли.

Я сподіваюся, що досвід, описаний у статті, буде універсальним і стане корисним для інших розробників екосистеми.

Після понад двох років підключення всіх основних AVS (автономних верифікаційних сервісів) до EigenLayer і розробки EigenCloud, я хочу чесно підбити підсумки: де ми помилилися, де зробили все правильно і куди рухатимемося далі.

Що таке повторний стейкінг (Restaking)?

Той факт, що сьогодні мені все ще потрібно пояснювати «що таке повторний стейкінг», вже свідчить про те, що коли ця тема була в центрі уваги галузі, ми не змогли її належно донести. Ось вам «урок № 0» — фокусуйтесь на одному ключовому наративі і повторюйте його знову і знову.

Мета команди Eigen завжди була «просто сказати, складно зробити»: підвищити верифікованість позаланцюгових обчислень, щоб люди могли безпечніше створювати застосунки на блокчейні.

AVS — це наша перша спроба у цьому напрямку з чіткою позицією.

AVS (автономний верифікаційний сервіс) — це мережа із доказом частки (PoS), у якій група децентралізованих операторів виконує позаланцюгові завдання. Дії цих операторів контролюються, і у разі порушення їхній стейк підлягає штрафу. Щоб реалізувати «штрафний механізм», необхідно мати «стейкінговий капітал» як основу.

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

Отже, концептуальна рамка повторного стейкінгу виглядає так:

• AVS: «сервісний рівень», основа нової PoS-криптоекономічної системи безпеки;
• Повторний стейкінг: «капітальний рівень», що за рахунок повторного використання стейкінгових активів забезпечує безпеку цих систем.

Я й досі вважаю цю ідею дуже витонченою, але реальність виявилася далекою від ідеалу — багато речей не вдалося реалізувати так, як планувалося.

Те, що не вдалося

1. Ми обрали неправильний ринок: надто нішевий

Нам був потрібен не «будь-який верифікований розрахунок», а лише ті системи, що від самого початку мають децентралізацію, штрафний механізм і повну криптоекономічну безпеку.

Ми хотіли, щоб AVS стали «інфраструктурними сервісами» — як SaaS (програмне забезпечення як сервіс) для розробників, щоб кожен міг створювати свій AVS.

Такий підхід, хоч і був принциповим, суттєво звузив потенційну аудиторію розробників.

У результаті ми стикнулися з ринком, який був «малим за масштабом, повільним за розвитком і з високим порогом входу»: мало потенційних користувачів, великі витрати на впровадження, довгі цикли розробки як для команди, так і для розробників. Побудова інфраструктури EigenLayer, інструментів розробника чи кожного окремого AVS займала місяці або навіть роки.

Минуло майже три роки: наразі у нас лише два основних AVS працюють у продакшн-середовищі — це DIN (децентралізована інфраструктурна мережа) від Infura та EigenZero від LayerZero. Такий «рівень впровадження» складно назвати «широким».

Чесно кажучи, ми спочатку уявляли, що команди захочуть мати криптоекономічну безпеку й децентралізованих операторів уже з першого дня, але реальний ринок потребував «більш поступових, прикладних рішень».

2. Через регуляторне середовище ми були змушені «мовчати»

Ми запускали проєкт на піку «ери Гері Генслера» (примітка: Гері Генслер — голова SEC США, відомий жорстким регулюванням криптоіндустрії). У той час багато стейкінгових компаній були під слідством і судовими позовами.

Як «проєкт повторного стейкінгу», майже кожне наше публічне висловлювання могло бути витлумачене як «інвестиційна обіцянка» чи «реклама прибутку», а то й викликати судову повістку.

Ця регуляторна невизначеність визначила наш спосіб комунікації: ми не могли відкрито висловлюватися, навіть коли нас заливали хвилі негативу, партнери знімали з себе відповідальність, а громадськість атакувала — ми не могли одразу спростувати непорозуміння.

Ми навіть не могли просто сказати «це не так», бо спочатку треба було оцінити юридичні ризики.

У підсумку, без достатньої комунікації, ми випустили токени з локацією. Зараз, озираючись назад, це було досить ризиковано.

Якщо вам здавалося, що «команда Eigen ухиляється від відповіді або підозріло мовчить» щодо чогось — це, швидше за все, було спричинено саме таким регуляторним середовищем. Навіть одна неправильна публікація може принести значні ризики.

3. Ранні AVS розмили цінність бренду

Ранній бренд Eigen у значній мірі тримався на Sreeram (ключовий член команди) — його енергія, оптимізм і віра в те, що системи й люди можуть ставати кращими, забезпечили команді велику підтримку.

Десятки мільярдів застейканого капіталу ще більше підсилювали цю довіру.

Але наша спільна промоція перших AVS не відповідала «висоті бренду». Багато ранніх AVS були гучними, але лише ганялися за трендами, не були прикладом ані «найкращої технології», ані «найвищої доброчесності».

З часом EigenLayer почали асоціювати із «черговим лідо-майнінгом чи аірдропом». Більшість нинішніх сумнівів, втоми чи навіть неприйняття нашої моделі беруть початок саме з цього етапу.

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

4. Надмірна технічна орієнтація на «мінімізацію довіри» призвела до зайвої складності дизайну

Ми намагалися побудувати «ідеальну універсальну систему штрафів» — універсальну, гнучку, таку, що покриває всі сценарії покарання, щоб досягти «мінімізації довіри».

Але на практиці це призвело до повільної розробки продукту і потребувало багато часу на пояснення механізму, який «більшість ще не готові зрозуміти». Навіть зараз нам доводиться постійно роз’яснювати систему штрафів, запущену майже рік тому.

Зараз очевидно, що правильніше було б спочатку випустити просте рішення для покарань, дати різним AVS протестувати більш сфокусовану модель, а потім поступово ускладнювати систему. Ми ж поставили «складний дизайн» на перше місце, і зрештою заплатили за це швидкістю і зрозумілістю…