EigenLayer, Karak ve LRT'ler: Restaking Risk Döngüsü

Ethereum'un staking sistemi, doğrulayıcılara yalnızca tek bir şeyi güvence altına almaları için ödeme yapar: Ethereum'un kendisini. Restaking, zaten kilitli ve zaten cezalara tabi olan aynı teminatın, kendi ekonomik güvenliğini kolayca oluşturamayan diğer sistemleri de aynı anda destekleyebileceği gözlemine dayanır.

Bu gerçekten yararlı bir fikirdir. Oracle'lar, köprüler, veri kullanılabilirliği katmanları ve sıralayıcıların (sequencer) hepsi, kötü davrandığında para kaybeden büyük bir sermaye havuzuna ihtiyaç duyar; bunu sıfırdan inşa etmek ise pahalıdır. Restaking, bu sermayeyi zaten var olan bir havuzdan kiralar.

Bunun bedeli, teminatın artık el değiştirebileceği daha fazla yolun olmasıdır. Bu makale bunun ne kadar fazla olduğunu, protokollerin bunu nasıl sınırladığını, likit bir restaking tokeninin pozisyon hakkında neyi değiştirdiğini ve birini kaldıraçlamanın, reklamı yapılan getiriyle çok az ilgisi olan bir risk profili yarattığını ele alır.

1. Restaking gerçekte ne satar

Bir restaking ağının talep tarafı, ekonomik güvenlik isteyen bir dizi servisten oluşur. EigenLayer bunlara Actively Validated Services adını verir. Karak'ın protokol spesifikasyonu bunlara Distributed Secure Services adını verir ve bir DSS'i, operatörler için "görevleri ve ödülleri koordine eden" ve yetersiz performans nedeniyle operatör fonlarına slashing uygulama yetkisine sahip bir servis olarak tanımlar.

Her iki tasarımdaki tedarik zinciri de aynı üç role sahiptir:

Bütün ekonomik önerme bu üçüncü adımda yatar. Restaking getirisi, üçüncü taraflarca yazılmış ek slashing koşullarını kabul etmenin karşılığıdır. Bunu aynı risk üzerinde bedava ekstra getiri olarak değerlendiren herhangi bir analiz, işlemi yanlış okumuş demektir.

2. EigenLayer slashing yüzeyini nasıl sınırlar

Restaking'e yönelik en yaygın eleştiri, tek bir depozitonun sonunda aynı anda birçok servise taahhüt edilmesi ve bu yüzden kötü geçen tek bir günün aynı ETH'nin tekrar tekrar slashing'e uğramasına yol açabileceğidir. EigenLayer'ın tahsis tasarımı bunu doğrudan ele alır ve bunu doğru anlamak önemlidir, çünkü riskin popüler versiyonu gerçek olanı değildir.

Magnitude'lar ve benzersiz stake

EigenLayer tahsisi magnitude'lar üzerinden takip eder. Protokolün kontrat dokümantasyonuna göre, her operatörün her strateji için "tüm operator set'ler arasında tahsis edilebilecek azami magnitude" olarak tanımlanan bir max magnitude'ı vardır; bu değer, tahsis edilebilir stake'in %100'ünü temsil eden 1 WAD (1e18)'den başlar. O anda tahsis edilmiş kısım ise encumbered magnitude'dur.

Benzersiz stake'i ortaya çıkaran kısıtlama açıkça ifade edilir: "Bir operatör %100'den fazlasını tahsis edemez; bu nedenle bir stratejinin encumbered magnitude'u, o stratejinin max magnitude'unu asla aşamaz." Dokümantasyon, bunun stake'in birden fazla servise iki kez taahhüt edilmemesini garanti ettiğini belirtir.

Bir operatör, bir servis tarafından ancak üç koşul birlikte sağlandığında slashing'e açık hale gelir: operatör operator set'e kayıtlıdır veya kayıt sildirdikten sonra da slashing'e açık kalmaya devam eder, servis o stratejiyi ilgili operator set'e eklemiştir ve tahsisin current magnitude'u sıfırdan farklıdır.

Bir slashing gerçekleştiğinde, bu "allocation.currentMagnitude'u slashing'e uğrayan magnitude kadar azaltır" ve operatörün max magnitude'unu azaltan yeni bir kayıt ekler. Bu azalma kalıcıdır.

Bu tasarımın size gerçekte söylediği

"Aynı ETH'nin herkes tarafından slashing'e uğratılması" korkusu, mimari tarafından ele alınmıştır. Belirli bir stake birimi, bir seferde tek bir operator set'e tahsis edilir. Bir servis yalnızca kendisine açıkça taahhüt edileni alabilir. Bu gerçek bir güvence önlemidir ve riski nasıl tarttığını değiştirmelidir.

Gerçek maruziyet, çifte tahsis değil parçalanmadır. Bir operatör, magnitude'unu birden fazla operator set arasında bölebilir. Eğer %30'u bir servise, %30'u başka bir servise tahsis edilirse ve ikisi de tam tahsisatlarına slashing uygularsa, operatör %60 kaybeder. Slashing'ler %100'e kadar birikir, ama bunu aşamaz. Dolayısıyla etkin maruziyetin, operatörünün servisler arasındaki tahsislerinin toplamıdır ve bu, operatörüne sormaya değer bir sayıdır.

Yoğunlaşan risk, protokol değil delegasyondur. Benzersiz stake, sizi protokol düzeyinde çifte taahhütten korur. Sizi, zayıf koşullara sahip birçok servise agresif biçimde tahsis yapan bir operatörden korumaz. Operatörün tahsis politikası, bir restaking pozisyonundaki tek en önemli değişkendir ve bu politikayı seçen siz değil, operatöründür.

Çıkış, riskten daha yavaştır

Yönetilebilir bir riski yapısal bir riske dönüştüren kısım burasıdır.

EigenLayer'ın kontrat dokümantasyonu, mainnet'te 126.000 bloklık bir tahsis gecikmesi (yaklaşık 17,5 gün) ve 100.800 bloklık bir tahsis kaldırma gecikmesi (yaklaşık 14 gün) belirtir. Karak'ın protokol spesifikasyonu, staker'lar için açıkça "slashing olaylarının önceden sezilip kaçılmasını (front running) önlemek amacıyla" 9 günlük asgari bir çekim gecikmesi belirler; operatörler de bir servisten tahsis kaldırırken benzer bir gecikmeyle karşılaşır.

3. Karak ve alternatif uygulamalar

EigenLayer, paylaşılan güvenlik fikrinin tek uygulaması değildir ve tasarımları karşılaştırmak, hangi seçimlerin doğal olduğunu ve hangilerinin bilinçli kararlar olduğunu görmenin yararlı bir yoludur.

2024 denetimiyle birlikte yayımlanan Karak protokol spesifikasyonu, slashing'i sınırlamaya farklı bir yaklaşım getiren bir tasarımı tanımlar. Orantılı magnitude tahsis etmek yerine, "DSS'lerin önceden azami bir slashing edilebilir yüzde belirlemesi gerekir" ve bir slashing komitesi, adaletsiz slashing olaylarını veto edebilir.

Veto mekanizmasındaki ödünleşimi adlandırmakta fayda var. Adaletsiz bir slashing'i engelleyebilen bir komite, aynı zamanda değer önermesi güven minimizasyonu olan bir sisteme güvenilir bir taraf sokar. Bu iki seçenekten hiçbiri açıkça doğru değildir. Sermaye tahsis eden biri için önemli olan, hangisine güvendiğini bilmektir.

4. Likit bir restaking tokeni neyi ekler ve neyi kaldırır

Restaking'e alınmış bir pozisyonun bariz bir kullanılabilirlik sorunu vardır: sermaye, haftalar süren bir çıkışın ardında kilitlenir ve başka hiçbir şey için kullanılamaz. Likit bir restaking tokeni bunu, likit staking tokenlerinin doğrulayıcılar için eşdeğer sorunu çözdüğü şekilde çözer. Protokol depozitoları alır, restaking pozisyonunu işletir ve üzerinde bir hak talebini temsil eden devredilebilir bir token ihraç eder.

Neyi ekler

Anında devredilebilirlik. 14 günlük çıkış, tek bir blokta sonuçlanan merkeziyetsiz bir borsadaki satışla yer değiştirir.

Kompozitlik (composability). Token; teminat olarak, bir likidite havuzu varlığı olarak ve Pendle gibi platformlarda getiri tokenizasyonu için dayanak varlık olarak kullanılabilir hale gelir.

Dışarıdan sağlanan operatör seçimi. LRT protokolü, operatörleri ve tahsis politikasını seçer; bunu iyi yapıyorlarsa bu bir hizmettir.

Neyi kaldırır

Dayanak varlık üzerinde nominal değerden doğrudan bir hak talebi. Artık elinde, değeri hem restaking pozisyonuna hem de LRT protokolünün kendi ödeme gücüne ve dürüstlüğüne bağlı olan bir token var.

Slashing yüzeyine görünürlük. Operator set, desteklenen servisler ve bunlar arasındaki tahsis, LRT protokolü tarafından seçilir. Gerçek slashing maruziyetin, onların politikasının ürettiği her ne ise odur.

Getirinin anlamlı bir payı. Ücretler her katmanda üst üste biner: LRT protokolü ödüllerden bir pay alır, operatörler komisyon alır ve restaking protokolü de kendi payını alabilir. Her katman ödüllerin bir yüzdesini alırken, slashing koşulları anaparanın tamamına uygulanır.

Çıkış likiditesi ikamesi

En önemli sonuç inceliklidir. Bir LRT, dayanak pozisyonu likit hale getirmez. Size farklı bir çıkış sunar: tokeni protokolden itfa etmek yerine başka bir alıcıya satmak.

Sakin piyasalarda bu ikisi neredeyse eşdeğerdir, çünkü arbitrajcılar herhangi bir iskontoyu satın alıp itfa ederek tokeni itfa değerine yakın tutar. Stres altında ise keskin biçimde birbirinden ayrışırlar, çünkü bu arbitrajın itfa ayağı, herkesinkiyle aynı haftalar süren kuyruğa tabidir. Fiyatı normalde nominal değerde tutan mekanizma, gecikme ne kadar sürerse tam olarak o kadar süreyle devre dışı kalır.

Yani stres altında bir LRT'nin pratik çıkış fiyatını, dayanak varlığın değeri değil, ikincil piyasa derinliği belirler. Sonraki bölümdeki her şeyi yönlendiren tek gerçek budur.

5. Kaldıraç döngüsü

LRT'ler devredilebilir olduğundan, teminat olarak kullanılabilirler. Ve bir LRT'nin getirisi genellikle ETH ödünç almanın maliyetinin üzerinde olduğundan, bu arbitraj barizdir ve yoğun biçimde kullanılır.

Mekanizma

LRT'yi teminat olarak yatır, karşılığında ETH ödünç al, bu ETH'yi daha fazla LRT'ye dönüştür, yeniden yatır ve tekrarla. %80'lik bir kredi-değer oranında (LTV), döngü sonsuza kadar sürdürülürse toplam maruziyet özkaynağın beş katına yakınsar; altı pratik tur ise sizi yaklaşık dört katına götürür.

100 birim özkaynakla başlandığında, altı tur sonunda yaklaşık 295 birim ETH borcuna karşılık 395 birim LRT teminatı elde tutulur.

Getiri

LRT'nin %4,2 getiri sağladığını ve ETH ödünç almanın maliyetinin %3 olduğunu varsayalım:

• Gelir: 395'in %4,2'si = 16,6 birim
• Faiz: 295'in %3,0'ı = 8,9 birim
• Net: 100 birim özkaynak üzerinde 7,7 birim, yani yaklaşık %7,7

1,2 puanlık bir fark, %7,7'ye dönüştü. Satış konuşması budur ve aritmetik doğrudur.

Risk

Şekil 1'i okumak

İki çizgi de aynı birimdedir — özkaynağın yüzdesi — bu yüzden doğrudan karşılaştırılabilirler ve asıl mesele de bu karşılaştırmadır.

%80'den başlayın ve yatay okuyun. Yeşil çizgi %7,7 civarında, kırmızı çizgi ise %12 civarında yer alır. Bu, yukarıda tarif edilen pozisyondur: yılda yaklaşık %7,7 öder ve LRT, ETH karşısında yaklaşık %12 kaybederse yok olur.

Şimdi kredi-değer oranını yukarı sürükleyin. Gelir yavaşça artar, çünkü her ekstra tur aynı 1,2 puanlık farktan biraz daha fazlasını ekler. Hayatta kalınabilir düşüş ise çöker, çünkü her tur aynı özkaynağa karşı borç ekler. Asimetri, tam olarak bu argümandır: daha fazla getiri satın almaktan çok, daha fazla sigorta satıyorsunuzdur.

Şimdi kırmızı çizgiyi aşağıdaki iki paragrafla karşılaştırın. Bu kaldıraç seviyesinde %5'lik bir slashing, özkaynağın kabaca %20'sine denk gelir ve normalde LRT'nin fiyatını savunacak olan itfa kuyruğu, pozisyonu tehdit eden tam da o koşullarda yaklaşık iki hafta boyunca kullanılamaz hale gelir. Kırmızı çizgi, bir piyasa fiyatı üzerinden likidasyona uğrayabileceğini varsayar; aşağıdaki callout, bu fiyatın neden dayanak varlığın gerçek değerinden çok daha fazla düşebileceğini açıklar.

Öncelikle kırmızı çizgiyi okuyun ve onu bir ikincil piyasa rakamı olarak okuyun. Doğru soru, LRT'nin nominal değerinde olup olmadığı değildir. Doğru soru, itfa kuyrukta beklerken nominal değerin ne kadar altında işlem görebileceğidir — ve Şekil 1, bunun ne kadarına dayanabileceğini gösterir.

%85'lik bir likidasyon eşiğiyle standart Health Factor (sağlık faktörü) tanımını kullanarak:

Health Factor = (Teminat Değeri × Likidasyon Eşiği) ÷ Toplam Borç Değeri

Nominal değerde bu, (395 × 0,85) ÷ 295 = 1,14 olur. Şimdi Health Factor'ün 1'e ulaştığı LRT-ETH döviz kurunu çözelim:

395 × x × 0,85 = 295, dolayısıyla x = 0,879

LRT'nin ETH karşısındaki döviz kurunda %12,1'lik bir düşüş, pozisyonu likidasyona uğratır.

Bu örneğin size gerçekte söylediği

Getiri, bir getiri değil satılmış bir opsiyondur. Yılda kabaca %7,7 toplarsınız ve döviz kuru yaklaşık %12 düşerse özkaynağınızın büyük bir kısmını kaybedersiniz. Bu, ekonomik olarak LRT sabitlemesi üzerine, primi getiri olarak ödenen bir para dışı (out-of-the-money) satım opsiyonu satmakla aynı şekildir. Bu meşru bir işlemdir ve bir depozito gibi değil, kısa bir opsiyon pozisyonu gibi büyüklendirilmelidir.

%5'lik bir slashing, özkaynağın %20'sine mal olur. Slashing, dayanak restaking pozisyonunun değerini azaltır ve bu, LRT'nin döviz kuruna yansır. 4x maruziyette, 395 birim teminat üzerindeki %5'lik bir kesinti, 100 birim özkaynağa karşı yaklaşık 20 birime denk gelir. Döngü, slashing maruziyetini getiriyi çarptığı ile tam olarak aynı faktörle çarpar, ama çok daha küçük bir tabandan başlayarak.

Ve işte durumu aritmetiğin öne sürdüğünden daha kötü yapan kısım. Likidasyon tetikleyiciniz bir ikincil piyasa fiyatıdır. Bu fiyatı savunan mekanizma, itfa arbitrajıdır. İtfa, kabaca iki hafta sürer. Yani döngünün risk altında olduğu tam da o senaryoda, fiyat savunması, likidasyonun gerçekleşmesinden daha uzun bir süre boyunca kullanılamaz durumdadır.

Dolayısıyla doğru büyüklük sorusu "bu varlık değer kaybedecek mi" değil, "itfa kuyrukta beklerken bu varlığın ikincil piyasa fiyatı ne kadar düşebilir" sorusudur. Bunlar farklı sayılardır ve ikincisi çok daha büyüktür.

6. Bu riskler neden çeşitlendirilemez

Birden fazla farklı LRT tutmak, çeşitlendirme gibi hissettirir. Çoğu zaman öyle değildir, çünkü maruziyetler bağımlılıklarını paylaşır.

Pratik test basittir: elinizde tuttuğunuz her pozisyon için operator set'i, servisleri, borç verme piyasasını ve çıkış havuzunu yazın. Listeler örtüşüyorsa, birden fazla pozisyonun değil, birden fazla sarmalayıcı (wrapper) içinde tek bir pozisyonun vardır.

7. Bir değerlendirme kontrol listesi

8. Sonuç

Restaking, bedeli açıkça belirtilmiş gerçek bir finansal yeniliktir. Zaten Ethereum'u güvence altına almakta olan teminat, üçüncü taraflarca yazılmış ek slashing koşullarını üstlenir ve bunları kabul ettiği için ödüllendirilir. Protokoller bu yüzeyi sınırlamak için anlamlı bir çalışma yapmıştır. EigenLayer'ın benzersiz stake tasarımı, aynı stake'in birden fazla servise taahhüt edilmesini engeller; Karak'ın spesifikasyonu ise her servisi, adaletsiz bir slashing'i veto edebilen bir komiteyle birlikte, beyan edilmiş azami bir slashing edilebilir yüzdeyle sınırlar.

Hiçbir tasarımın kaldıramadığı şey çıkış gecikmesidir ve riskin gerçekte yoğunlaştığı yer de burasıdır. Yaklaşık iki haftalık bir çekim penceresi, doğru bir protokol mühendisliğidir, çünkü anlık çıkışlar katılımcıların hak ettikleri cezalardan kaçmasına izin verirdi. Bu aynı zamanda bir restaking pozisyonunun bir stop emriyle kapatılamayacağı anlamına gelir ve normalde likit bir restaking tokenini dayanak değerine yakın tutan arbitrajın, tam da tokenin baskı altında olduğu dönemlerde kullanılamaz hale geldiği anlamına gelir.

Bu bileşim, kaldıraçlı restaking döngülerini, farkın öne sürdüğünden çok daha riskli hale getiren şeydir. Döngü, birkaç puanlık net getiri öder ve savunma mekanizması yapısal olarak yetişemeyecek kadar yavaş olan bir döviz kurunda yaklaşık %12'lik bir hareketle likidasyona uğrar. Geniş bir kullanım fiyatına sahip kısa bir opsiyon pozisyonu olarak büyüklendirildiğinde savunulabilir bir işlemdir. Bir getiri ürünü olarak büyüklendirildiğinde ise, sonunda nominal değerinde olan bir varlığı elde tutarken DeFi'de büyük miktarda sermaye kaybetmenin en güvenilir tek yoludur.

Restaking'in diğer gelişmiş zincir üzeri stratejilerle nasıl karşılaştırıldığını görmek için gelişmiş DeFi getiri ve hedge stratejileri makalesine bakın. Bu döngülerin geçtiği borç verme piyasalarının teminatı gerçekte nasıl fiyatladığını ve likidasyona uğrattığını görmek için kaldıraçlı getiri ve kredi hesapları ve yumuşak likidasyonlar ve Curve LLAMMA makalelerine bakın.

Sıkça sorulan sorular

Kaynaklar ve ek okumalar

Birincil protokol dokümantasyonu:

• EigenLayer contracts — AllocationManager documentation
• Karak restaking — protocol specification
• Aave — Health factor and liquidations

İlgili CoinBeaver makaleleri:

• Gelişmiş DeFi getiri ve hedge stratejileri
• Kaldıraçlı getiri ve kredi hesapları: Gearbox ve Morpho Blue karşılaştırması
• Yumuşak likidasyonlar: Curve LLAMMA nasıl çalışır
• Pendle getiri ticareti nasıl çalışır
• DeFi borç verme açıklamalı
• Kripto likidasyonları açıklamalı

Bu makale eğitim amaçlıdır ve finansal tavsiye niteliği taşımaz. Yukarıda kullanılan tüm getiriler, kredi-değer oranları, likidasyon eşikleri ve pozisyon büyüklükleri, canlı protokol parametreleri değil, örnekleyici niteliktedir. Restaking protokolleri, operator set'ler, desteklenen servisler, slashing koşulları, ücret yapıları ve çekim gecikmeleri zamanla değişir; alıntılanan Karak rakamları, protokolün güncel durumunu yansıtmayabilecek 2024 tarihli bir spesifikasyondan gelmektedir. Sermaye taahhüt etmeden önce her parametreyi ilgili protokolün kendi dokümantasyonunda doğrulayın.