Uniswap Zehir Havuzu Tuzağı: 29 Saatte 131.888 Dolar Topladı

Orijinal başlık: "Fiyat %0, Uygulama %12,8: Uniswap v4 'Zehir Havuzu' Dinamik Ücret Tuzağı İncelemesi"

Orijinal yazar: Wang Zihao, BitsLab

22-23 Ağustos 2026 tarihlerinde, BNB Chain üzerindeki bir Uniswap v4 USDC/WBNB dinamik ücret havuzu, toplayıcı fiyat tekliflerinde %0 ücret gösterirken, kullanıcıların gerçek işlemlerinden %12,8 LP ücreti kesildi. Yaklaşık 29 saat içinde bu havuzda 21.086 işlem gerçekleşti ve toplam 131.888 dolar ücret toplandı; ardından havuz kapatıldı. Tüm mağdur işlemler başarılı oldu: sözleşme hacklenmedi, çıktı kullanıcının belirlediği alt sınırın üzerindeydi ve hiçbir anormal sinyal yoktu—fark sessizce ücrete dönüştü.

Bu makale, örnek bir işlemi giriş noktası olarak ele alıyor:

(0x7615dec2ce80506ec461a47739eb8533ac2bc7c605ca56c255964481b76363d0: Kullanıcı 5.926,90 USDT yatırdı, beklenenden 757,43 USDT daha az aldı) ve bu havuzun "fiyat %0, uygulama %12,8" durumunu nasıl başardığını ayrıştırıyor: ücret fonksiyonunun üç katmanlı belirlemesi, etkisiz hale getirilen kayma koruması ve diğer LP'leri dışarıda tutan beyaz liste. Tüm sonuçlar zincir üstü verilere ve yerel kontrollü doğrulamaya dayanmaktadır.

01 Fiyat Teklifinden Uygulamaya Giden Yol

Kullanıcı toplayıcı arayüzünde takas başlattıktan sonra tüm yol şu şekilde ilerler:

Bu yolda iki arka plan gerçeği vardır ve sonraki her katman belirlemesi bu ikisine dayanır.

Önce v4 tarafına bakalım: Hook'un işlem bazında ücreti geçersiz kılmasına izin verir. PoolKey.fee = 0x800000 dinamik ücret havuzunu belirtir; Hook, beforeSwap'ın üçüncü dönüş değerinde 0x400000 | fee taşır. v4-core'da bu dönüş değerini alan kod (Pool.sol:303-305):

isOverride() geçersiz kılma bayrağını kontrol eder, removeOverrideFlagAndValidate() 0x400000'ı çıkarır ve MAX_LP_FEE = 1.000.000 (%100) değerini aşmadığını doğrular, ardından bu ücretle mevcut takası yürütür ve Swap olayını yazar. Yani Hook ne döndürürse kullanıcı onu öder—çıktı hala amountOutMin'in üzerinde olduğu sürece. Bu resmi bir özelliktir; volatiliteye veya envantere göre ücret ayarlamak meşru kullanımlardır.

Şimdi Hook'un kendisine bakalım: yalnızca iki izin beyan ediyor. v4, izinleri sözleşme adresinin düşük 14 bitinde kodlar (Hooks.sol:29-47), dağıtım sırasında doğrular ve sonradan değiştirilemez. v4-core tarafındaki bayrak tanımları ve adres çözümlemesi karşılıklı okunur:

Zincir üstünde ölçülen getHookPermissions() dönüşü bit eşlemiyle tutarlıdır: yalnızca bu iki bit doğrudur.

Hook'un kaynak kodu yoktur. Bu makale, bayt kodundan ücret fonksiyonunun tamamını tersine derledi—aşağıda, zincir üzerinde çalışmış bu mantığın davranışsal ayrıştırması yer almaktadır:

Şimdi katman katman inceleyelim. İlk iki katman "bu bir simülasyon mu?" sorusunu yanıtlar; üçüncü katman gerçek işlemin ne kadar ödeyeceğini belirler.

02 Ücret Fonksiyonunun Üç Katmanlı Belirlemesi

Belirleme 1: Çağıranı Ayırt Etme

Ücret fonksiyonu çağrıldıktan sonra önce tx.origin karşılaştırılır: üç sabit adresten herhangi birine eşitse doğrudan geri dönüş kademesi döndürülür. Geri dönüş kademesi şu anda %0 olarak yapılandırılmıştır.

Üç adres rastgele seçilmemiştir. eth_call'da from belirtilmediğinde işlemin origin'i sıfır adresine düşer—toplayıcı toplu fiyat sorguları genellikle belirtmez. Yerel fork'ta doğrudan doğrulama:

İlk katman yalnızca bu üç adresi tanır. Bir sonraki katmanda, normal bir adres belirtildikten sonra Hook'un nasıl ayırt edebileceğine bakalım.

Belirleme 2: Gas Kontrolü

tx.origin'i normal bir adresle değiştirip tekrar denediğimizde dönüş yine %0 olur—ilk katman atlatıldı, ancak ücret değişmedi. Bu, ilk katmanın tek belirleme olmadığını gösterir; ikinci katmana geçiyoruz: gasleft() * 10100 / 10000 >= gate.

Toplayıcı fiyat teklifleri genellikle yüksek gas verir; böylece aday rotalar simülasyonda gas yetersizliği nedeniyle başarısız olmaz. Gerçek işlem Hook'a girmeden önce gas, Router, yetkilendirme ve ön atlamalar tarafından tüketilir. Aynı kod, üç farklı gas:

Sınır çizgisi ölçümlerde 16,85M–16,9M gas arasındadır. 30M ile 2,59M arasındaki fark, "fiyat teklifi" ile "uygulama" arasındaki farktır.

Belirleme 3: İşlem Bazında Sözde Rastgelelik

İlk iki katmanı geçen gerçek işlem üçüncü katmana girer: blok ortamı parmak izi hash'lenir, 10.000'e mod alınır ve sonucun bulunduğu aralığa göre karşılık gelen ücret kademesi döndürülür. Mevcut yapılandırma üç kademedir: %8 / %10 / %10; boş kalırsa %0'a döner.

Bu katmanda dikkate değer iki tasarım vardır. Parmak izine calldata'nın üç alanı karıştırılır—toplayıcı fiyat teklifinin calldata'sı ile gerçek rotanın calldata'sı zaten farklıdır, dolayısıyla parmak izi de doğal olarak farklıdır. Ayrıca, işlem bazında sözde rastgelelik ücreti dağılımlı hale getirir; birkaç işleme bakarak deseni fark etmek zordur ve basit kural numaralandırması engellenemez.

Tüm 21.086 zincir üstü olayda 19 tarihsel ücret kademesi (%6,8–%28) görülmektedir; bu, ücret kademelerinin yönetici fonksiyonu tarafından ihtiyaca göre yeniden yapılandırıldığını gösterir. Örnek işlem gerçekleştiğinde geçerli olan %12,8'dir.

Üç Katmanın Birleşik Görünümü

Bu noktada "zehir havuzu" için bir tanım yapabiliriz—aynı anda üç koşulu sağlayan bir v4 havuzu: PoolKey.fee dinamik ücret bayrağı taşır; ücret kararı kamu piyasa durumunu değil, yürütme ortamı sinyallerini (gas, origin, blok ortamı) okur; fiyat teklifi simülasyonu ile zincir üstü yürütme arasındaki ücret sistematik olarak ayrışır ve yararlanan taraf zehir havuzu dağıtıcısıdır. Ayrım, ücretin ne okuduğundadır: herhangi bir çağırana aynı ücreti döndüren programlanabilir piyasa tasarımıdır; "kimin fiyat sorduğuna" göre farklı ücret döndüren ise yönlendirme sistemine yönelik bir aldatmacadır.

Buraya kadar ücret ayrışmasının mekanizması tamamlandı. Ancak ücret alındıktan sonra işlemin neden hala başarılı olduğu bir sonraki sorudur.

03 Kayma Koruması Neden Geri Dönmedi

Önce bu işlemin tam yoluna ve tutarlarına bakalım:

İlgili atlamanın Swap olayı, geçerli ücreti fee alanına kaydeder: 128000. v4'ün ücret birimi 1.000.000'u %100 olarak alır; 128000, %12,8'dir. Bu işlemin kaybı iki açıdan ölçülebilir: havuz açısından ücret WBNB girdisinden alınır; tüm rota açısından stablecoin giriş-çıkış farkı 757,43 USDT olup %12,7794 kayba karşılık gelir; buna ön atlama ücretleri ve depeg sapması da dahildir. İki rakam arasındaki fark yalnızca 0,02 yüzde puanıdır; bu da kaybın ana kaynağının bu havuzun LP ücreti olduğunu gösterir.

amountOutMin yalnızca nihai çıktı alt sınırını doğrular; ara atlamalarda ne kadar ücret alındığına bakmaz:

%12,8'lik ücret, %20,32'lik tamponun tamamıyla içinde kalır; çıktı hala alt sınırın üzerindedir—işlem başarılı olur, geri dönmez. Ana akım stablecoin rotalarında normal varsayılan %0,1–%1'dir; bu rota 20 kattan fazla alan sağlamıştır. Kullanıcı geniş tamponun "daha güvenli" olduğunu düşünürken, aslında yol üzerindeki her sözleşmeyi karşı tarafın öz disiplinine bırakmıştır. Bu hesabı grafiğe dökelim:

04 Zehir Havuzu Dağıtıcısının Operasyonları

Beyaz Liste: Diğer LP'leri Dışarıda Tutma

Beyaz liste mantığı beforeAddLiquidity içindedir; tersine derlenmiş sonuç aşağıdadır:

Likidite eklemek için üç kapıdan geçmek gerekir: önce her v4 Hook'unda bulunan PoolManager çağrı kontrolü, ardından resmi PositionManager üzerinden geçiş ve son olarak pozisyon sahibinin beyaz listesinin doğrulanması. Listede olmayan adresler burada sözleşme tarafından geri çevrilir; diğer LP'ler giremez, ücret geliri seyrelmez ve tamamı dağıtıcıya gider. Listenin kendisi bir yönetici fonksiyonu (seçici 0xc4452e52) tarafından adres bazında yönetilir.

%0 Kademesi ve Hacim Şişirme

21.086 işlemi bir arada incelediğimizde dağılım net bir desen gösterir: %0 kademesinde 6.946 işlem, 12.947.751 dolar hacim, işlem başına ortalama 1.864 dolar; ücretli kademede 14.140 işlem, 1.120.106 dolar hacim, işlem başına ortalama 79 dolar. Büyük hacimli işlemler %0 kademesinde yoğunlaşırken, ücretler küçük işlemlerde toplanır. Büyük %0 işlemlerinin en makul açıklaması, dağıtıcının yüksek gas ile kendi kendine işlem yapmasıdır: yüksek gas, toplayıcı fiyat teklifiyle aynı belirlemeye denk gelir ve kendi kendine işlemlerin ücret maliyeti sıfıra yakındır. Şişirilen hacim, havuzu piyasa listelerinde üst sıralara taşır (anlık görüntüde 24 saatlik hacim yaklaşık 10,82 milyon dolar, 16.671 işlem); toplayıcıların gözünde bu, derinliği iyi ve ücreti düşük bir havuzdur.

Ücret Kademelerinin İhtiyaca Göre Yeniden Yapılandırılması

Belirleme 3'te bahsedilen 19 tarihsel ücret kademesi, tersine derlenen ücret yapılandırma fonksiyonundan gelir (seçici 0x4d909a45, kamuya açık imza kaydı yok):

Dört ücret kademesi ve eşikler bir bütün olarak paketlenir ve keccak(poolId, 2) depolama yuvasına yazılır. Zincir üstünde bu yuvanın okuması 0x0138800186a00186a0'dır ve fonksiyonun paketleme formatıyla parça parça eşleşir. Ücret kademeleri burada dağıtım sırasında sabitlenmemiş, her an ayarlanabilir parametrelerdir.

Yaşam Döngüsü

Bu havuz 08-22 06:57'de oluşturuldu, 07:13'te ilk takas gerçekleşti, 21:39'da bu makalenin örnek işlemi yapıldı; 08-23 12:25'te son işlem gerçekleşti ve ardından kapatıldı. Tüm aktif dönem yaklaşık 29 saattir; toplam hacim 14.067.857 dolar, ücret geliri 131.888 dolardır (dağıtıcı maliyetleri düşülmemiştir). İnceleme sırasında kayıt bayrağı tekrar etkin duruma dönmüştür—havuz hala mevcuttur ve her an yeniden etkinleştirilebilir.

05 Tam Yol

Tüm saldırı zincirini birleştirelim:

Tüm zincirin nedenselliği yukarıdaki şemadadır; üç koşuldan biri eksik olursa bu yöntem işe yaramaz: simülasyonun ilk iki katmanı yakalaması, gerçek işlemin üçüncü katmana düşmesi ve tamponun ücretten büyük olması.

06 Düzeltmeler ve Öneriler

İlk nokta toplayıcının fiyat teklifi yöntemindedir. Kök neden, simülasyon ile yürütmenin aynı yolu izlememesidir: fiyat teklifi idealize edilmiş havuz düzeyinde sorgular kullanır, sıfır adres ve yüksek gas ile yapılır; gerçek işlem gerçek kimlik ve tüketilmiş gas ile gelir. Hook bu farkları tam olarak okuyabilir ve ücret ayrışır. Çözüm, simülasyonu yürütmeye yaklaştırmaktır—gerçekte gönderilecek Router calldata'sı, gerçek from/to ve zincir üstü işleme yakın gas ile simülasyon yapmak; işlem sonrasında Swap olayını çözüp fee'yi kontrol etmek, fiyat teklifiyle uyuşmuyorsa ağırlığını düşürmek veya listeden çıkarmak.

İkinci nokta kullanıcının kayma ayarındadır. Kök neden, min_out'un çok gevşek verilmesidir: %20,32'lik tampon %12,8'lik ücreti tamamen yutar ve işlem normal şekilde başarılı olur. Ana akım stablecoin rotalarında %0,1–%1 günlük kullanım için yeterlidir; işlem başlatmadan önce bu rakama bir göz atın. Cüzdanlar ve arayüzler varsayılan değerleri sıkılaştırarak kullanıcıların risklerinin çoğunu engelleyebilir.

Üçüncü nokta rota kabulündedir. Kök neden, herhangi bir dinamik ücret havuzunun doğrudan fiyat teklifi rekabetine katılabilmesidir: açık kaynak kodu veya denetim kaydı olmayan Hook'lar bile şişirilmiş hacimle önerilen rotalara girebilir. Güvenilir profili olmayan dinamik ücret havuzları için varsayılan olarak rotaya dahil etmemek veya ağırlığını önemli ölçüde düşürmek en güvenli yaklaşımdır.

Veriler ve Açıklamalar

·Örnek işlem:

https://bscscan.com/tx/0x7615dec2ce80506ec461a47739eb8533ac2bc7c605ca56c255964481b76363d0 (blok 117497524)

·Havuz başlatma işlemi:

https://bscscan.com/tx/0x8fa72ef72d77b61f715dc9ce90548249ab045c6d78716078cd5ab425bbe69a05

·PoolManager:

0x28e2ea090877bf75740558f6bfb36a5ffee9e9df

·Pool ID:

0x36e5540e9dedc02229fe8a82aa5b10c0bf07d1fa74e4f2ffe0efd00fa1a36aea

·Hook:

0xd111b3ddd92e627f1864520c770e913ec04e0880 (kaynak kodu yok; sözde kod bu makale için bağımsız olarak tersine derlenmiştir; yönetici 0x08b03e1a5444d469f4dc954e74d3f662c94a6b13)

·Hacim ve ücretler: Bu havuzun tüm 21.086 Swap olayı işlem bazında toplanmıştır (eth_getLogs); WBNB, aynı işlemin yürütme fiyatıyla dönüştürülmüştür; gelir brüt değerdir, dağıtıcı maliyetleri düşülmemiştir