Uniswap v4'ün Hook Mekanizması: Fırsatlar ve Zorluklar Bir Arada

Uniswap v4 yakında çıkıyor, bu güncelleme sınırsız sayıda likidite havuzunu ve dinamik ücretleri desteklemek, tekil tasarım, flaş muhasebe, Hook mekanizması gibi birçok önemli yenilik getirecek. Bunlar arasında, Hook mekanizması güçlü ölçeklenebilirliği nedeniyle geniş ilgi görüyor.

Hook mekanizması, likidite havuzunun yaşam döngüsündeki belirli noktalarda özelleştirilmiş kodun çalıştırılmasına olanak tanır ve havuzun esnekliğini önemli ölçüde artırır. Ancak, bu esneklik yeni güvenlik zorluklarını da beraberinde getirmektedir. Bu makalede, Hook mekanizması ile ilgili güvenlik sorunları ve potansiyel riskler sistematik olarak ele alınacak ve topluluğun daha güvenli bir Uniswap v4 ekosistemi inşa etmesine katkıda bulunacaktır.

Uniswap v4'ün Temel Mekanizması

Güvenlik sorunlarını derinlemesine tartışmadan önce, Uniswap v4'ün birkaç temel mekanizmasını anlamamız gerekiyor:

1. Hook mekanizması

Hook, likidite havuzunun yaşam döngüsünün farklı aşamalarında çalışan bir sözleşmedir. Şu anda 4 gruba ayrılmış 8 Hook geri çağrısı bulunmaktadır:

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• beforeSwap/afterSwap
• bağış öncesi/bağış sonrası

Bu Hook'lar dinamik ücretler, zincir üstü limit emirleri, dağıtılmış büyük emirler gibi işlevleri gerçekleştirebilir.

2. Singleton mimarisi ve yıldırım muhasebesi

v4, tüm likidite havuzlarının aynı akıllı sözleşmede saklandığı bir singleton sözleşme tasarımını tanıttı. Bu, tüm havuz durumlarını yönetmek için PoolManager'a dayanır.

Lightning muhasebe, işlemleri kaydetmek için iç net bakiyeyi ayarlayarak çalışır, anlık transfer yerine. Gerçek transfer, işlemin sonunda gerçekleştirilir ve fonların bütünlüğünü garanti eder.

3. Kilit Mekanizması

Dış hesaplar doğrudan PoolManager ile etkileşimde bulunamaz, lock talep etmek için sözleşme aracılığıyla hareket etmelidir. İki ana etkileşim senaryosu vardır:

• Resmi veya kullanıcı tarafından dağıtılan yönlendirici sözleşmeleri aracılığıyla
• Hook entegrasyonu yapılmış sözleşme

Tehdit Modeli

Biz esasen iki tür tehdit modelini dikkate alıyoruz:

Tehdit Modeli I: Zararsız ama Açıkları Olan Hook

Bu durumda, geliştiricinin kötü niyetli olmadığı, ancak Hook'un açığı olabileceği anlamına gelir. Biz esasen v4'e özgü potansiyel açıklar üzerine odaklanıyoruz, örneğin:

• Kullanıcı fonlarını saklayan Hook
• Anahtar durum verilerini depolayan Hook

Araştırmalar, ilgili projelerin %36'sında güvenlik açıkları bulunduğunu, bunların başlıca erişim kontrolü sorunları ve girdi doğrulama sorunları içerdiğini göstermektedir.

Tehdit Modeli II: Kötü Amaçlı Hook

Bu durumda, geliştirici ve Hook'un kendisi kötü niyetlidir. Hook'u iki sınıfa ayırıyoruz:

• Yönetilen Hook: Kullanıcılar yönlendirici aracılığıyla Hook ile etkileşimde bulunur.
• Bağımsız Hook: Kullanıcı doğrudan Hook ile etkileşimde bulunabilir.

Havuz tipi Hook'lar varlıkları doğrudan çalmakta zorlanır, ancak maliyet yönetim mekanizmasını manipüle edebilir. Bağımsız Hook'ların yetkileri daha fazladır, eğer yükseltilebilirlerse risk daha yüksektir.

Önlemler

Tehdit modeli I için, erişim kontrolü ve girdi doğrulaması güçlendirilmelidir ve yeniden giriş koruması uygulanmalıdır.

Tehdit modeli II için, Hook'un kötü niyetli olup olmadığını değerlendirmek gerekmektedir. Barındırılan Hook'lar için maliyet yönetimi davranışlarına, bağımsız Hook'lar için ise güncellenebilirlik durumuna dikkat edilmelidir.

Sonuç

Hook mekanizması, Uniswap v4'e büyük bir potansiyel getirdi, ancak aynı zamanda yeni güvenlik zorluklarını da beraberinde getirdi. İlgili riskleri derinlemesine anlayarak ve uygun önlemleri alarak, Hook'un avantajlarını daha iyi değerlendirebilir ve DeFi ekosisteminin gelişimini ilerletebiliriz. Sonraki makalelerde, her bir tehdit modelindeki güvenlik sorunlarını daha derinlemesine analiz edeceğiz.