Uniswap v4 hook'ları, bir havuzun yaşam döngüsü olaylarına bağlanan özel kod parçalarıdır; böylece geliştiriciler paylaşılan bir sözleşmenin üzerinde ücretleri değiştirebilir, mantık ekleyebilir veya özel AMM matematiği çalıştırabilir. Hook'lar Uniswap'ı tek bir AMM'den, başkalarının üzerine inşa edebileceği bir platforma dönüştürür; ancak her yeni hook, istismar edilebilecek yeni bir akıllı sözleşme yüzeyi anlamına da gelir.
Öne çıkanlar
- Uniswap v4, v3'teki havuz başına fabrika modelini, tüm likiditeyi tutan ve her takası yönlendiren tek bir ETH singleton sözleşmesiyle değiştirir.
- Hook'lar, takas, mint, burn ve donation gibi havuz olaylarından önce veya sonra çalışan eklenti fonksiyonlarıdır ve geliştiricilerin ücret eğrilerini, oracle'ları ve emir türlerini özelleştirmesine olanak tanır.
- Mimari, özel AMM'leri, dinamik ücretleri ve MEV korumasını mümkün kılar; ancak riski de yoğunlaştırır: hatalı veya kötü niyetli bir hook, bağlı olduğu havuzu boşaltabilir.
- DeFi'deki LP kayıplarının çoğu piyasa hareketlerinden değil, akıllı sözleşme hatalarından kaynaklanır; bu nedenle denetim ve hook itibarı, gösterişli APY'den daha önemlidir.
Uniswap v4 hangi sorunu çözmeye çalışıyor
Uniswap v3, sermaye verimliliği açısından bir ileri adımdı. Konsantre likidite, LP'lerin yatırımlarını seçtikleri bir fiyat aralığında yoğunlaştırmasına olanak tanıdı; böylece aynı sermaye, v2 tarzı tam aralık pozisyona kıyasla daha fazla ücret kazanabildi. Karşılığında ise bedel karmaşıklıktı: aralıkları yönetmek, geçici kayıpları takip etmek ve yeniden dengeleme için gas ödemek.
v3 tasarımının az sayıda bireysel kullanıcının farkına vardığı yapısal bir sınırı da vardı. Yeni her havuz, v3 fabrikası tarafından dağıtılan yeni bir akıllı sözleşmeydi. Yüzlerce havuz, yüzlerce sözleşme demekti; her birinin kendi depolama alanı vardı ve her takas, çiftler arasında yönlendirme yapmak için sözleşmeler arasında atlamak zorundaydı. Bu da tam Ethereum'un Layer 2 ölçeklendirmeye çalıştığı bir anda gas'ı pahalı hale getiriyordu.
Uniswap v4, altyapıyı bu sorun etrafında yeniden tasarlıyor. Her havuz için bir sözleşme yerine protokol neredeyse her şeyi, tüm likiditeyi tutan ve her işlemi tek bir giriş noktasından yönlendiren singleton adlı tek bir sözleşmede topluyor. Hook'lar, bu yeniden tasarımı v3'ün sahip olduğu çeşitliliği dağıtım maliyeti olmadan koruyacak kadar esnek kılan özelliktir.
v4 singleton tasarımı protokolü nasıl değiştiriyor
v4'teki göze çarpan mimari değişiklik singleton'dır. v3'te yeni bir havuz dağıtmak yeni bir sözleşme dağıtmak demekti. v4'te havuzlar etkili biçimde tek bir sözleşmenin içindeki kayıtlardır ve aynı sözleşme her takası, mint'i ve burn'ü yürütür. Bu durumun kullanıcılar için üç pratik sonucu vardır.
İlk olarak, çoklu sıçramalı takaslar daha ucuz hale gelir. USDC'den WETH'ye ve oradan UNI'ye giden bir takas eskiden iki ya da üç havuz sözleşmesine dokunuyordu. v4'te ise yalnızca bir tanesine dokunuyor. Bu önemsiz bir altyapı detayı gibi görünebilir, ancak mainnet'te bir takasın ekonomik olarak uygulanabilir olması ile kullanıcının bir Layer 2'ye veya merkezi bir borsaya yönlendirilmesi arasındaki farkı belirleyebilir.
İkincisi, singleton sarmalanmış WETH yerine doğrudan native ETH tutabilir. Daha önce havuz muhasebesi, her işlemin ERC-20 transferlerini alabilen bir sözleşmeye ihtiyaç duyması nedeniyle sarmalanmış token'ların hikayesiydi. Tek bir sözleşme ve flash-accounting modeliyle singleton, ETH'yi doğrudan alacaklandırıp borçlandırabilir; bu da kullanıcıların sarma ve açma gas'ından tasarruf etmesini sağlar.
Üçüncüsü, gas ekibin "flash accounting" adını verdiği geçici depolama düzeniyle daha da azaltılıyor. Singleton, her işlemde token'ları havuza girip çıkarmak yerine farkları dahili olarak takip eder ve token bakiyelerini yalnızca işlemin sonunda mahsup eder. Sonuç olarak v4'te takas yapmak v3'e kıyasla belirgin biçimde daha ucuzdur; bu da aktif LP'ler ve sık sık yeniden dengeleme yapan stratejiler için önemlidir.
Yine de gözden kaçması kolay bir denge noktası vardır. DEX'in tamamını tek bir sözleşmede toplamak, aynı zamanda bir hatanın etki alanını da büyütür. Singleton'daki ciddi bir açık, v4 üzerindeki tüm havuzları eş zamanlı olarak etkileyen bir açık anlamına gelir. Bu, v3'ün parçalanmış riskinin mimari açıdan ayna görüntüsüdür ve ekibin geniş çaplı yayın öncesinde denetimler için bir yıldan fazla zaman harcamasının nedenlerinden biridir.
Bir Uniswap v4 kancası aslında nedir
Kanca, singleton'ın bir havuzun yaşam döngüsündeki belirli noktalarda çağırdığı bir akıllı kontrattır. Protokolün sunduğu yaşam döngüsü olayları arasında beforeSwap ve afterSwap, beforeModifyLiquidity ve afterModifyLiquidity ile beforeDonate ve afterDonate bulunur. Bir kanca, bir havuza kendini kaydettirir ve singleton ilgili adımda o kancaya yönlendirme yapar.
v4'teki bir havuzu kancaları ve bir likidite pozisyonu olan bir yapı olarak düşünebilirsiniz. Kanca değiştirmediği sürece havuz, Uniswap'ın bilinen sabit-ürün matematik modelini kullanmaya devam eder. Kancanın swap parametrelerini okumasına, havuz durumunu okumasına ve singleton'ın kullanacağı bir sonucu geri yazmasına izin verilir. Önemli olan, kancanın işlemi geri alarak eylemi reddedebilmesidir.
Bunun çalışması için v4 ekibi bir kanca izin sistemi geliştirdi. Her kanca adresi, hangi yaşam döngüsü olaylarını uyguladığını kodlar ve singleton, hangi geri çağrıların tetikleneceğini belirten bayrağı aramak için kanca adresinin düşük bitlerini kullanır. Bu, bir gaz optimizasyonu hilesidir, ancak aynı zamanda bir kancanın izinlerinin yalnızca adresinden görülebildiği anlamına gelir; bu da entegratörler ve panolar için faydalıdır.
Geliştiriciler için pratik model şudur: ilgilendiğiniz geri çağrıları uygulayan bir kontrat dağıtırsınız, onu özelleştirmek istediğiniz havuza kaydettirirsiniz ve o noktadan itibaren havuz üzerindeki her eylem sizin kodunuzdan geçer. Esasen Uniswap'ın takas katmanının üzerine küçük bir AMM, ya da otomatik bir piyasa yöneticisi, inşa ediyorsunuz.
Kancaların gerçekte neleri mümkün kıldığı: özel AMM'ler ve dinamik ücretler
Kancalar etrafındaki pazarlama söylemi, "Uniswap bir ürün olmak yerine bir platform haline geliyor" şeklindedir. Bu çoğunlukla doğrudur ve bunun nedenini görmenin en kolay yolu, kancaların gerçekte neler yapabileceğini adım adım incelemektir.
Dinamik ve kademeli ücretler. Bir kanca, koşullara bağlı olarak bir swap'te alınan ücreti değiştirebilir. Örneğin, bir stablecoin kancası fiyat peg'e yakın olduğunda temel puanın bir kesri kadar, volatilite yüksek olduğunda ise daha yüksek bir ücret alabilir. Bir kanca, fiyatı yukarı mı aşağı mı hareket ettirdiğine bağlı olarak farklı bir ücret de alabilir; bu, LP'ler için ilkel bir MEV yakalama biçimidir.
Özel AMM eğrileri. Varsayılan v4 havuzu hâlâ x*y=k sabit-ürün formülünü kullanır, ancak bir kanca fiilen herhangi bir fiyatlandırma modelini çalıştırabilir. Düşük volatiliteli çiftler için bir stableswap değişmezi, Curve tarzı hibrit bir eğri, sentetik varlıklar için Gauss ya da ortalamaya dönüş eğrisi, hatta tamamen harici bir oracle'ı izleyen bir kanca oluşturabilirsiniz. Havuz, Uniswap'ın takası, yönlendirmeyi ve singleton'ın güvenlik modelini sağladığı genel amaçlı bir likidite mercii haline gelir.
Zincir üstü limit emirler ve TWAMM. Bir beforeModifyLiquidity kancası, tek-tick likidite eklemelerini limit emirlerine dönüştürebilir: LP bir fiyat aralığı belirler ve piyasa fiyatı bu aralığı geçtikçe kanca pozisyonları mint eder ve yakar. Saatlerce büyük bir emri birçok küçük swape bölerek gerçekleştiren zaman-ağırlıklı ortalama piyasa yapıcısı stratejileri de bir kanca olarak ifade edilebilir.
Zincir üstü oracle'lar ve LP korumaları. Bir kanca, her swap'te depolama alanına ucuzca diğer kontratların okuyabileceği bir TWAP, VWAP ya da başka bir istatistik yazabilir. Kancalar ayrıca "1 dakikalık pencerenin son blokunda swap yapılmasın" gibi kuralları uygulayabilir; bu, kaba ama faydalı bir anti-MEV korumasıdır, ya da belirli koşullar sağlandığında bir havuzu durduran kill switch'ler uygulayabilir.
Yerel ETH ve gaz iadeleri. ETH'yi singleton tuttuğu için, kancalar LP'lere ETH olarak gaz iadeleri uygulayabilir ya da MEV ödüllerini swap edilebilir token yerine ETH olarak dağıtabilir. Tek bir kullanıcı için bu küçüktür, ancak likidite çekmeye çalışan protokol tasarımcıları için yapısal bir kaldıraçtır.
Bunların hiçbiri otomatik değildir. Yukarıdaki her özellik, bir geliştiricinin bir kanca oluşturmasını, dağıtmasını ve sürdürmesini gerektirir. Uniswap bir araç seti sunuyor, bir özellik listesi değil.
Denetlenmemiş kanca kodunun güvenlik riskleri
Her yeni kanca, yeni bir akıllı-kontrat yüzeyidir ve v4 hikâyesinin en çok dikkat edilmesi gereken kısmı budur. v3'te likiditeyi tutan kontratlar nispeten küçük, iyi denetlenmiş bir setti. v4'te herkes bir havuza bir kanca kaydettirebilir ve bu kanca, o havuzdaki her swap, mint ve burn işleminin kritik yolunda kod çalıştırma yetkisi kazanır.
Riskler birkaç kategoriye ayrılır ve LP'ler para yatırmadan önce her birini bilmelidir.
Kanadaki mantık hataları. beforeSwap veya beforeModifyLiquidity'deki bir hata, havuzun muhasebesini bozabilir, yatırılan miktarı aşan çekimlere izin verebilir ya da havuzu tamamen dondurabilir. Singleton doğrunun kaynağı olduğu için kanca doğrudan token çalamaz, ancak yine de havuzu, sıklıkla aynı blok içinde bir takip işlemi tarafından sömürülebilecek bir durumda bırakabilir.
Yeniden giriş ve kancalar arası etkileşim. Kancalar harici kontratlardır ve kötü niyetli bir kanca singleton'a yeniden girebilir ya da aynı havuzdaki diğer kancaları çağırabilir. Protokolün yeniden giriş kilitleri vardır, ancak kancalar arası etkileşim yüzeyi yeni olduğundan tamamı savaşta test edilmemiştir. Örneğin, aynı havuza bağlı iki kanca, hiçbir bireysel denetimin kapsamadığı şekillerde bir araya gelebilir.
Yönetici anahtarları ve yükseltilebilirlik. Birçok kanca, parametreleri değiştirebilen, davranışı durdurabilen ya da kontratı yükseltebilen bir owner adresiyle dağıtılır. Bir yönetici anahtarı tek bir arıza noktasıdır: ele geçirilmiş bir anahtar, havuz hâlâ aktifken kancanın davranışını değiştirebilir ve değişiklik yürürlüğe girmeden önce LP'lerin temiz bir şekilde çekilme yolu olmayabilir. Bir timelock'a sahip bir multisig, bir EOA'dan iyidir, ancak yine de bir güven meselesidir.
Oracle manipülasyonu. Harici oracle'ları okuyan ya da fiyata göre ücretleri değiştiren kancalar, yalnızca oracle kadar güvenlidir. Manipüle edilmiş bir oracle, bir kancayı LP'leri boşaltan sıfır ücretli bir swap alacak şekilde kandırabilir ya da havuzu saldırgana yarar sağlayan bir durumda kilitleyebilir.
Singleton içinde yoğunlaşan risk. Tek bir havuzu etkileyen bir kanca hatası yine de tek bir havuzu etkiler. Ancak özellikle singleton'ın yerel ETH muhasebesiyle etkileşen bazı hata sınıfları, ilke olarak birçok havuza aynı anda yayılabilir. Bu v4'e özgü değildir, ancak singleton topolojiyi v3'ün havuz başına tasarımından daha tehlikeli hale getirir.
Dürüst özet şudur: kancalar, sıradan bir kullanıcının kendi başına değerlendiremeyeceği v4 parçasıdır. "Bu havuz bir kanca kullanıyor" göz ardı edilecek bir etiket değildir. Daha güvenli varsayım, herhangi bir kancayı swap yolunun emanetinde olan üçüncü taraf bir akıllı kontrat olarak ele almak ve ek riski ek getiriye karşı tartmaktır.
MEV, LP koruması ve gerçekçi potansiyel
Maksimum çıkarılabilir değer, blok üreticilerinin ve arama yapanların işlemleri yeniden sıralayarak, ekleyerek ya da sansürleyerek elde edebildiği kâr, LP'ler için süregelen arka plan maliyetlerinden biridir. Özellikle sandviç saldırıları, kullanıcının işleminin önünde ve arkasında işlem yaparak swap'lerden değer çıkarır. LP'ler kaybı emer çünkü havuzun etkin fiyatı, kullanıcının kabul ettiği fiyattan daha kötüdür.
Kancalar, bu maliyeti azaltmak için inandırıcı bir araçtır. Bir beforeSwap kancası, commit-reveal şemaları, imzalı notlar ya da özel işlem yolları kullanarak işlemin bir sandviçin parçası olup olmadığını kontrol edebilir ve tespit ederse swap'i geri alabilir. Bir kanca ayrıca swap'lerin yalnızca belirli blok pozisyonlarına inmesini zorunlu kılabilir, sandviç gibi görünen işlemlere daha yüksek ücret uygulayabilir ya da büyük swap'leri sandviçlenmesi daha zor olan daha küçük atomik parçalara bölebilir.
Diğer yandan, kancalar aynı zamanda yeni bir MEV yüzeyidir. Swap parametrelerine ve havuz durumuna ayrıcalıklı erişimi olan bir kanca, operatörü tarafından o havuzdaki kullanıcıların önüne geçmek için kullanılabilir. Protokol, tıpkı bir oracle operatörünün oracle'ı manipüle etmesini engelleyemediği gibi, bunu da engelleyemez. Hafifletme, DeFi'nin geri kalanında olduğu gibidir: itibar, denetimler, kamuya açık izleme ve bir kanca kötü davrandığında likiditeyi çekmeye istekli bir topluluk.
Ciddi LP'ler için gerçekçi potansiyel gerçek ama sınırlıdır. Derin bir havuzdaki iyi tasarlanmış bir kanca, ters seçilimi anlamlı ölçüde azaltabilir; bu, "işlemim toplandı"nın teknik terimidir. Bu, bazen birkaç yüzde puanı tutarında daha yüksek net APR'ye dönüşür. Ne sihirli bir hiledir, ne de içinde bulunduğunuz havuzu anlamanın yerini tutar.
Bu durum likidite sağlayıcıları ve geliştiriciler için ne anlama geliyor?
Eğer bir LPyseniz, v4 dünyası sizden v3'ten biraz farklı bir iş akışı talep ediyor. Para yatırmadan önce dört soruyu yanıtlayabiliyor olmalısınız. Bu havuza hangi hook bağlı ve aslında ne yapıyor? Hook'un parametrelerini kim, hangi zaman çizelgesinde değiştirebilir? Hook denetlendi mi, kim tarafından? Hook tamamen çalışmayı bırakırsa arıza modu nedir; pozisyonunuz hâlâ çekilebilir durumda mı?
Bu sorulardan herhangi birinin yanıtı "Bilmiyorum" ise, havuz sermayenizin büyük bölümünü park etmek için doğru yer değildir. Hakkında sağlıklı bir değerlendirme yapamadığınız bir hook'tan gelen getiri, bir gecede sıfırlanabilecek bir getiridir. v3 için geçerli olan tavsiye v4 için daha da geçerlidir: pozisyonlarınızı manşet APY'ye göre değil, en kötü senaryoda akıllı kontrat hatasında kaybetmeyi göze alabileceğiniz büyüklüğe göre ayarlayın.
Eğer bir geliştiriciyseniz, hook'lar tasarım alanını gerçek anlamda genişletiyor. Aylar yerine haftalar içinde özel bir AMM piyasaya sürebilir, Uniswap'ı çatallamadan fiyat eğrileri üzerinde iterasyon yapabilir ve mevcut v4 yönlendiricisiyle kompoze edebilirsiniz; bu da aksi halde kendinizin oluşturması gereken likidite erişimini size sağlar. Bedeli ise aynı zamanda bir güvenlik ürünü de piyasaya sürmenizdir. v4 ekosistemindeki en özenli hook ekipleri, denetimleri, hata ödüllerini ve olay müdahalesini genel gider olarak değil, ürünün bir parçası olarak ele alıyor.
Her iki grup için pratik bir not: v4, v3'ten kasıtlı olarak daha izinli ve ekip, "onaylanmış" hook'lardan oluşan varsayılan bir liste derlemeyeceklerini açıkça belirtti. Piyasanın bu işi itibar, panolar ve toplayıcılar aracılığıyla yapması bekleniyor. Bu sinyaller olgunlaşana kadar, her hook kararı kişisel bir risk kararıdır.
Uniswap v4 hook'larını akıllıca nasıl takip edersiniz?
Uniswap v4 hook'ları hızlı hareket eder ve etraflarındaki haberler de öyle. Yeni hook tasarımları, denetimler, istismarlar ve geçişler araştırma forumlarında, yönetişim tartışmalarında ve proje bloglarında duyuruluyor; her birini ayrı ayrı okumak kaybeden bir oyun. Zippfeed, Uniswap v4 hook başlıklarını duygu puanlaması (boğa, nötr veya ayı) ve önem derecelendirmesiyle öne çıkararak gerçek protokol gelişmelerini tantanadan ayırmanıza ve hangi hook'ların pazarlama payı yerine gerçek likidite kazandığını takip etmenize olanak tanır.