Uniswap v4'ün Hook Mekanizması: Potansiyel ve Riskler
Uniswap v4 yakında çıkacak, bu güncelleme her işlem çifti için sonsuz sayıda likidite havuzunu ve dinamik ücretleri destekleyen, tekil tasarım, anlık muhasebe, Hook mekanizması ve ERC1155 token standardını destekleyen yeni özellikler getiriyor. Bu arada, Hook mekanizması güçlü potansiyeli nedeniyle geniş bir dikkat topladı.
Hook mekanizması, likidite havuzunun yaşam döngüsündeki belirli noktalarda özel kodun çalıştırılmasına izin verir ve bu, havuzun ölçeklenebilirliğini ve esnekliğini büyük ölçüde artırır. Ancak, Hook mekanizması aynı zamanda iki ucu keskin bir kılıç olabilir. Güçlü ve esnek olmasına rağmen, Hook'un güvenli bir şekilde kullanılması da önemli bir zorluktur. Hook'un karmaşıklığı kaçınılmaz olarak yeni potansiyel saldırı vektörlerini beraberinde getirir.
Bu makale, Uniswap v4'teki Hook mekanizmasının ilgili kavramlarını tanıtacak ve mevcut güvenlik risklerini özetleyecektir.
Uniswap v4'ün temel mekanizması
Derinlemesine tartışmadan önce, Uniswap v4'ün mekanizmasını temel düzeyde anlamamız gerekiyor. Resmi duyurulara ve beyaz kitaba göre, Hook, tekil mimari ve anlık muhasebe, özelleştirilmiş likidite havuzları ve birden fazla havuzda verimli yönlendirme sağlamak için üç önemli işlevdir.
Hook mekanizması
Hook, likidite fon havuzunun yaşam döngüsünün farklı aşamalarında çalışan bir sözleşmeyi ifade eder ve herkesin karar verme süreçlerine katılmasını sağlar. Bu şekilde, yerel olarak dinamik ücretleri desteklemek, zincir üzerinde limit emirleri eklemek veya zaman ağırlıklı ortalama piyasa yapıcı (TWAMM) büyük siparişleri dağıtmak mümkün hale gelir.
Şu anda dört gruba ayrılmış sekiz Hook geri çağrısı var, her grup ( bir çift geri çağrı içeriyor ):
beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
bağış öncesi/bağış sonrası
Tekil, Yıldırım Hesaplama ve Kilit Mekanizması
Singleton yapısı ve Lightning muhasebesi, maliyetleri düşürerek ve verimliliği sağlayarak performansı artırmayı amaçlamaktadır. Tüm likidite havuzlarının aynı akıllı sözleşmede saklandığı yeni bir singleton sözleşmesi tanıtmaktadır. Bu singleton tasarımı, tüm havuzların durumunu depolamak ve yönetmek için bir PoolManager'a dayanmaktadır.
v4 sürümü, hızlı muhasebe ve kilit mekanizmasını tanıttı. Kilit mekanizmasının çalışma şekli aşağıdaki gibidir:
locker sözleşmesi PoolManager üzerinde lock talep eder.
PoolManager, bu locker kontrat adresini lockData kuyruğuna ekler ve lockAcquired geri çağrısını çağırır.
locker sözleşmesi geri çağrımda mantığını yürütür. Yürütme sürecindeki havuz etkileşimleri sıfır olmayan para artışlarına neden olabilir, ancak yürütme sona erdiğinde, tüm artışlar sıfıra eşitlenmelidir.
PoolManager, lockData kuyruğu ve para artışının durumunu kontrol eder. Doğrulandıktan sonra, o locker sözleşmesini siler.
Genel olarak, kilitleme mekanizması eşzamanlı erişimi önler ve tüm işlemlerin tasfiye edilmesini garanti eder. Bu yaklaşım, işlemlerin anlık transfer gerçekleştirmek yerine iç net bakiyeyi ayarladığını ifade eder. Herhangi bir değişiklik havuzun iç bakiyesinde kaydedilir, gerçek transfer ise işlemin sonunda gerçekleştirilir.
Kilitleme mekanizmasının varlığı nedeniyle, dışarıdaki tüm hesaplar (EOA) doğrudan PoolManager ile etkileşime giremez. Herhangi bir etkileşim sözleşme aracılığıyla gerçekleştirilmelidir. Temelde iki tür sözleşme etkileşim senaryosu bulunmaktadır:
locker sözleşmesi resmi kod kütüphanesinden veya kullanıcı tarafından dağıtılmıştır. Bu durum, bir yönlendirici üzerinden etkileşim olarak değerlendirilebilir.
locker sözleşmesi ve Hook'un aynı sözleşmeye entegre edilmesi veya üçüncü taraf bir varlık tarafından kontrol edilmesi durumu, Hook aracılığıyla etkileşim olarak değerlendirilebilir.
Tehdit Modeli
İlgili güvenlik sorunlarını tartışmadan önce, tehdit modelini belirlememiz gerekiyor. Temel olarak aşağıdaki iki durumu dikkate almalıyız:
Tehdit modeli I: Hook kendisi iyidir, ancak bir güvenlik açığı vardır.
Tehdit Modeli II: Hook kendisi kötü niyetlidir.
Tehdit Modeli I'ndeki güvenlik sorunları
Tehdit modeli I, Hook'un kendisiyle ilgili zayıflıklara odaklanmaktadır. Bu tehdit modeli, geliştiricinin ve Hook'un kötü niyetli olmadığını varsayıyor. Ancak, akıllı sözleşmelerdeki mevcut bilinen zayıflıklar da Hook'ta ortaya çıkabilir.
v4 sürümüne özgü potansiyel açıklar üzerinde odaklanmayı seçiyoruz, özellikle aşağıdaki iki tür Hook'a dikkat ediyoruz:
Kullanıcı fonlarını saklayan Hook. Saldırganlar bu Hook'u hedef alarak fonları transfer edebilir ve varlık kaybına neden olabilir.
Kullanıcılar veya diğer protokollerin bağımlı olduğu kritik durum verilerini depolayan Hook. Saldırganlar kritik durumu değiştirmeye çalışabilir, diğer kullanıcılar veya protokoller yanlış durumu kullandığında potansiyel riskler doğurabilir.
Araştırmalarımız sonucunda, Hook, PoolManager ve dış üçüncü taraflar arasındaki risk etkileşimlerinden kaynaklanan birkaç ciddi güvenlik açığı tespit ettik. Bu açıklar, erişim kontrol sorunları ve girdi doğrulama sorunları olmak üzere iki kategoriye ayrılabilir.
Erişim kontrolü sorunu
v4'teki geri çağırma fonksiyonları, 8 Hook geri çağırma ve lock geri çağırma dahil olmak üzere sorunlara neden olabilir. Bu fonksiyonlar sadece PoolManager tarafından çağrılmalı, diğer adresler tarafından çağrılmamalıdır. Hook'lar için, güçlü bir erişim kontrol mekanizması oluşturmak hayati öneme sahiptir, özellikle de bunların havuzun kendisi dışında diğer taraflar tarafından çağrılabilmesi durumunda.
Giriş doğrulama sorunu
Kilitleme mekanizması olmasına rağmen, bazı savunmasız Hook uygulamalarındaki yetersiz girdi doğrulaması nedeniyle güvenilmeyen dış çağrılar ile sonuçlanabilecek bir saldırı senaryosu vardır:
Hook, kullanıcıların etkileşimde bulunmayı planladığı likidite havuzunu doğrulamamıştır. Bu, sahte token'lar içeren ve zararlı mantık uygulayan kötü niyetli bir likidite havuzu olabilir.
Bazı anahtar Hook fonksiyonları, dışarıdan her türlü çağrıyı mümkün kılar.
Güvenilmeyen dış çağrılar son derece tehlikelidir, çeşitli saldırı türlerine yol açabilir, bunlar arasında yeniden giriş saldırıları da bulunmaktadır.
Önlemler
Bu tür güvenlik sorunlarından kaçınmak için, duyarlı dış/kamu fonksiyonlarına gerekli erişim kontrolünü uygun şekilde uygulamak ve giriş parametrelerini doğrulamak, etkileşimi doğrulamak için önemlidir. Ayrıca, reentrancy koruması, Hook'un standart mantık akışında tekrar tekrar çalıştırılmadığından emin olmaya yardımcı olabilir.
Tehdit Modeli II'ndeki güvenlik sorunları
Bu tehdit modelinde, geliştiricinin ve onun Hook'unun kötü niyetli olduğunu varsayıyoruz. Anahtar, sağlanan Hook'un kullanıcı transferlerini veya yetkilendirdiği kripto varlıkları işleyip işleyemeyeceğidir.
Erişim Hook yöntemine göre, Hook'u iki kategoriye ayırıyoruz:
Yönetilen Hook: Hook bir giriş noktası değildir. Kullanıcıların Hook ile etkileşimde bulunmak için bir yönlendirici aracılığıyla hareket etmeleri gerekir.
Bağımsız Hook: Hook, kullanıcıların doğrudan etkileşimde bulunmasına olanak tanıyan bir giriş noktasıdır.
Yönetimli Hook
Kullanıcının kripto varlıkları router'a transfer edildi veya yetkilendirildi. PoolManager bir bakiye kontrolü gerçekleştirdiğinden, kötü niyetli Hook'ların bu varlıkları doğrudan çalması kolay değildir. Ancak, potansiyel bir saldırı yüzeyi hala vardır; örneğin, v4 sürümündeki ücret yönetim mekanizması saldırganlar tarafından Hook aracılığıyla manipüle edilebilir.
Bağımsız Tip Hook
Hook bir giriş noktası olarak kullanıldığında, durum daha karmaşık hale gelir. Hook daha fazla güç kazanır ve teorik olarak bu etkileşim aracılığıyla istenilen herhangi bir işlemi gerçekleştirebilir.
v4 sürümünde, kod mantığının doğrulanması çok önemlidir. Ana sorun, kod mantığının manipüle edilip edilemeyeceğidir. Eğer Hook yükseltilebilir ise, bu, görünüşte güvenli bir Hook'un yükseltme sonrasında kötü niyetli hale gelebileceği anlamına gelir ve bu da büyük bir risk oluşturur. Bu riskler şunları içerir:
Yükseltilebilir aracılar ( doğrudan saldırıya uğrayabilir )
Kendini yok etme mantığı var. selfdestruct ve create2'nin birleşik çağrısı durumunda saldırıya uğrayabilir.
Önlemler
Hook'un kötü niyetli olup olmadığını değerlendirmek kritik bir noktadır. Özellikle, yönetilen Hook'lar için, maliyet yönetimi davranışlarına odaklanmalıyız; bağımsız Hook'lar için ise, esas odak noktası bunların yükseltilebilir olup olmadığıdır.
Sonuç
Bu makale, Uniswap v4'ün Hook güvenlik sorunlarıyla ilgili temel mekanizmaları kısaca özetlemekte ve iki tehdit modeli ile ilgili güvenlik risklerini sunmaktadır. Hook mekanizması güçlü bir işlevselliğe sahip olmasına rağmen, yeni güvenlik zorlukları da getirmektedir. Geliştiricilerin ve kullanıcıların bu potansiyel risklerin farkında olmaları ve Uniswap v4 kullanırken varlık güvenliğini sağlamak için uygun önlemleri almaları gerekmektedir.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Uniswap v4 Hook Mekanizması: Güçlü Özelliklerin Ardındaki Güvenlik Zorlukları
Uniswap v4'ün Hook Mekanizması: Potansiyel ve Riskler
Uniswap v4 yakında çıkacak, bu güncelleme her işlem çifti için sonsuz sayıda likidite havuzunu ve dinamik ücretleri destekleyen, tekil tasarım, anlık muhasebe, Hook mekanizması ve ERC1155 token standardını destekleyen yeni özellikler getiriyor. Bu arada, Hook mekanizması güçlü potansiyeli nedeniyle geniş bir dikkat topladı.
Hook mekanizması, likidite havuzunun yaşam döngüsündeki belirli noktalarda özel kodun çalıştırılmasına izin verir ve bu, havuzun ölçeklenebilirliğini ve esnekliğini büyük ölçüde artırır. Ancak, Hook mekanizması aynı zamanda iki ucu keskin bir kılıç olabilir. Güçlü ve esnek olmasına rağmen, Hook'un güvenli bir şekilde kullanılması da önemli bir zorluktur. Hook'un karmaşıklığı kaçınılmaz olarak yeni potansiyel saldırı vektörlerini beraberinde getirir.
Bu makale, Uniswap v4'teki Hook mekanizmasının ilgili kavramlarını tanıtacak ve mevcut güvenlik risklerini özetleyecektir.
Uniswap v4'ün temel mekanizması
Derinlemesine tartışmadan önce, Uniswap v4'ün mekanizmasını temel düzeyde anlamamız gerekiyor. Resmi duyurulara ve beyaz kitaba göre, Hook, tekil mimari ve anlık muhasebe, özelleştirilmiş likidite havuzları ve birden fazla havuzda verimli yönlendirme sağlamak için üç önemli işlevdir.
Hook mekanizması
Hook, likidite fon havuzunun yaşam döngüsünün farklı aşamalarında çalışan bir sözleşmeyi ifade eder ve herkesin karar verme süreçlerine katılmasını sağlar. Bu şekilde, yerel olarak dinamik ücretleri desteklemek, zincir üzerinde limit emirleri eklemek veya zaman ağırlıklı ortalama piyasa yapıcı (TWAMM) büyük siparişleri dağıtmak mümkün hale gelir.
Şu anda dört gruba ayrılmış sekiz Hook geri çağrısı var, her grup ( bir çift geri çağrı içeriyor ):
Tekil, Yıldırım Hesaplama ve Kilit Mekanizması
Singleton yapısı ve Lightning muhasebesi, maliyetleri düşürerek ve verimliliği sağlayarak performansı artırmayı amaçlamaktadır. Tüm likidite havuzlarının aynı akıllı sözleşmede saklandığı yeni bir singleton sözleşmesi tanıtmaktadır. Bu singleton tasarımı, tüm havuzların durumunu depolamak ve yönetmek için bir PoolManager'a dayanmaktadır.
v4 sürümü, hızlı muhasebe ve kilit mekanizmasını tanıttı. Kilit mekanizmasının çalışma şekli aşağıdaki gibidir:
locker sözleşmesi PoolManager üzerinde lock talep eder.
PoolManager, bu locker kontrat adresini lockData kuyruğuna ekler ve lockAcquired geri çağrısını çağırır.
locker sözleşmesi geri çağrımda mantığını yürütür. Yürütme sürecindeki havuz etkileşimleri sıfır olmayan para artışlarına neden olabilir, ancak yürütme sona erdiğinde, tüm artışlar sıfıra eşitlenmelidir.
PoolManager, lockData kuyruğu ve para artışının durumunu kontrol eder. Doğrulandıktan sonra, o locker sözleşmesini siler.
Genel olarak, kilitleme mekanizması eşzamanlı erişimi önler ve tüm işlemlerin tasfiye edilmesini garanti eder. Bu yaklaşım, işlemlerin anlık transfer gerçekleştirmek yerine iç net bakiyeyi ayarladığını ifade eder. Herhangi bir değişiklik havuzun iç bakiyesinde kaydedilir, gerçek transfer ise işlemin sonunda gerçekleştirilir.
Kilitleme mekanizmasının varlığı nedeniyle, dışarıdaki tüm hesaplar (EOA) doğrudan PoolManager ile etkileşime giremez. Herhangi bir etkileşim sözleşme aracılığıyla gerçekleştirilmelidir. Temelde iki tür sözleşme etkileşim senaryosu bulunmaktadır:
locker sözleşmesi resmi kod kütüphanesinden veya kullanıcı tarafından dağıtılmıştır. Bu durum, bir yönlendirici üzerinden etkileşim olarak değerlendirilebilir.
locker sözleşmesi ve Hook'un aynı sözleşmeye entegre edilmesi veya üçüncü taraf bir varlık tarafından kontrol edilmesi durumu, Hook aracılığıyla etkileşim olarak değerlendirilebilir.
Tehdit Modeli
İlgili güvenlik sorunlarını tartışmadan önce, tehdit modelini belirlememiz gerekiyor. Temel olarak aşağıdaki iki durumu dikkate almalıyız:
Tehdit Modeli I'ndeki güvenlik sorunları
Tehdit modeli I, Hook'un kendisiyle ilgili zayıflıklara odaklanmaktadır. Bu tehdit modeli, geliştiricinin ve Hook'un kötü niyetli olmadığını varsayıyor. Ancak, akıllı sözleşmelerdeki mevcut bilinen zayıflıklar da Hook'ta ortaya çıkabilir.
v4 sürümüne özgü potansiyel açıklar üzerinde odaklanmayı seçiyoruz, özellikle aşağıdaki iki tür Hook'a dikkat ediyoruz:
Kullanıcı fonlarını saklayan Hook. Saldırganlar bu Hook'u hedef alarak fonları transfer edebilir ve varlık kaybına neden olabilir.
Kullanıcılar veya diğer protokollerin bağımlı olduğu kritik durum verilerini depolayan Hook. Saldırganlar kritik durumu değiştirmeye çalışabilir, diğer kullanıcılar veya protokoller yanlış durumu kullandığında potansiyel riskler doğurabilir.
Araştırmalarımız sonucunda, Hook, PoolManager ve dış üçüncü taraflar arasındaki risk etkileşimlerinden kaynaklanan birkaç ciddi güvenlik açığı tespit ettik. Bu açıklar, erişim kontrol sorunları ve girdi doğrulama sorunları olmak üzere iki kategoriye ayrılabilir.
Erişim kontrolü sorunu
v4'teki geri çağırma fonksiyonları, 8 Hook geri çağırma ve lock geri çağırma dahil olmak üzere sorunlara neden olabilir. Bu fonksiyonlar sadece PoolManager tarafından çağrılmalı, diğer adresler tarafından çağrılmamalıdır. Hook'lar için, güçlü bir erişim kontrol mekanizması oluşturmak hayati öneme sahiptir, özellikle de bunların havuzun kendisi dışında diğer taraflar tarafından çağrılabilmesi durumunda.
Giriş doğrulama sorunu
Kilitleme mekanizması olmasına rağmen, bazı savunmasız Hook uygulamalarındaki yetersiz girdi doğrulaması nedeniyle güvenilmeyen dış çağrılar ile sonuçlanabilecek bir saldırı senaryosu vardır:
Hook, kullanıcıların etkileşimde bulunmayı planladığı likidite havuzunu doğrulamamıştır. Bu, sahte token'lar içeren ve zararlı mantık uygulayan kötü niyetli bir likidite havuzu olabilir.
Bazı anahtar Hook fonksiyonları, dışarıdan her türlü çağrıyı mümkün kılar.
Güvenilmeyen dış çağrılar son derece tehlikelidir, çeşitli saldırı türlerine yol açabilir, bunlar arasında yeniden giriş saldırıları da bulunmaktadır.
Önlemler
Bu tür güvenlik sorunlarından kaçınmak için, duyarlı dış/kamu fonksiyonlarına gerekli erişim kontrolünü uygun şekilde uygulamak ve giriş parametrelerini doğrulamak, etkileşimi doğrulamak için önemlidir. Ayrıca, reentrancy koruması, Hook'un standart mantık akışında tekrar tekrar çalıştırılmadığından emin olmaya yardımcı olabilir.
Tehdit Modeli II'ndeki güvenlik sorunları
Bu tehdit modelinde, geliştiricinin ve onun Hook'unun kötü niyetli olduğunu varsayıyoruz. Anahtar, sağlanan Hook'un kullanıcı transferlerini veya yetkilendirdiği kripto varlıkları işleyip işleyemeyeceğidir.
Erişim Hook yöntemine göre, Hook'u iki kategoriye ayırıyoruz:
Yönetilen Hook: Hook bir giriş noktası değildir. Kullanıcıların Hook ile etkileşimde bulunmak için bir yönlendirici aracılığıyla hareket etmeleri gerekir.
Bağımsız Hook: Hook, kullanıcıların doğrudan etkileşimde bulunmasına olanak tanıyan bir giriş noktasıdır.
Yönetimli Hook
Kullanıcının kripto varlıkları router'a transfer edildi veya yetkilendirildi. PoolManager bir bakiye kontrolü gerçekleştirdiğinden, kötü niyetli Hook'ların bu varlıkları doğrudan çalması kolay değildir. Ancak, potansiyel bir saldırı yüzeyi hala vardır; örneğin, v4 sürümündeki ücret yönetim mekanizması saldırganlar tarafından Hook aracılığıyla manipüle edilebilir.
Bağımsız Tip Hook
Hook bir giriş noktası olarak kullanıldığında, durum daha karmaşık hale gelir. Hook daha fazla güç kazanır ve teorik olarak bu etkileşim aracılığıyla istenilen herhangi bir işlemi gerçekleştirebilir.
v4 sürümünde, kod mantığının doğrulanması çok önemlidir. Ana sorun, kod mantığının manipüle edilip edilemeyeceğidir. Eğer Hook yükseltilebilir ise, bu, görünüşte güvenli bir Hook'un yükseltme sonrasında kötü niyetli hale gelebileceği anlamına gelir ve bu da büyük bir risk oluşturur. Bu riskler şunları içerir:
Önlemler
Hook'un kötü niyetli olup olmadığını değerlendirmek kritik bir noktadır. Özellikle, yönetilen Hook'lar için, maliyet yönetimi davranışlarına odaklanmalıyız; bağımsız Hook'lar için ise, esas odak noktası bunların yükseltilebilir olup olmadığıdır.
Sonuç
Bu makale, Uniswap v4'ün Hook güvenlik sorunlarıyla ilgili temel mekanizmaları kısaca özetlemekte ve iki tehdit modeli ile ilgili güvenlik risklerini sunmaktadır. Hook mekanizması güçlü bir işlevselliğe sahip olmasına rağmen, yeni güvenlik zorlukları da getirmektedir. Geliştiricilerin ve kullanıcıların bu potansiyel risklerin farkında olmaları ve Uniswap v4 kullanırken varlık güvenliğini sağlamak için uygun önlemleri almaları gerekmektedir.