Güvenlik krizi sonrası sağlam inanç: Neden SUI hala uzun vadeli yükseliş potansiyeline sahip?

1. Bir saldırının tetiklediği zincirleme reaksiyon

22 Mayıs 2025'te, SUI ağında konuşlandırılan önde gelen AMM protokolü Cetus, bir siber saldırıya uğradı. Saldırgan, "tam sayı taşma problemi" ile ilgili bir mantık açığını kullanarak hassas bir kontrol gerçekleştirdi ve 200 milyon dolardan fazla varlık kaybına yol açtı. Bu olay, yılın başından beri DeFi alanındaki en büyük ölçekli güvenlik kazalarından biri olmanın yanı sıra SUI ana ağının lansmanından bu yana en yıkıcı siber saldırı haline geldi.

Verilere göre, SUI tüm zincir TVL'si saldırı günü bir anda 3,3 milyar doların üzerinde bir düşüş yaşadı, Cetus protokolünün kendi kilitli miktarı ise anında %84 oranında buharlaştı ve 38 milyon dolara düştü. Bu durumdan etkilenen, SUI üzerindeki birçok popüler token (Lofi, Sudeng, Squirtle gibi) yalnızca bir saat içinde %76'dan %97'ye kadar düştü ve bu, piyasada SUI'nin güvenliği ve ekosistem istikrarı konusunda geniş bir endişe yarattı.

Ancak bu darbenin ardından, SUI ekosistemi güçlü bir dayanıklılık ve iyileşme yeteneği gösterdi. Cetus olayı kısa vadede güven dalgalanmalarına neden olsa da, zincir üzerindeki fonlar ve kullanıcı aktifliği sürdürülebilir bir düşüş yaşamadı; aksine, tüm ekosistemin güvenlik, altyapı inşası ve proje kalitesine olan ilgisinin önemli ölçüde arttırmasına yol açtı.

Bu saldırı olayının nedenleri, SUI'nin düğüm konsensüs mekanizması, MOVE dilinin güvenliği ve SUI'nin ekosistem gelişimi etrafında, henüz gelişiminin erken aşamasında olan bu kamu zincirinin mevcut ekosistem yapısını inceleyecek ve gelecekteki gelişim potansiyelini tartışacağız.

2. Cetus olayı saldırı neden analizi

2.1 Saldırı Gerçekleştirme Süreci

Cetus saldırı olayının teknik analizi doğrultusunda, hackerlar protokoldeki kritik bir aritmetik taşma açığını başarıyla kullanarak, flash loan, hassas fiyat manipülasyonu ve sözleşme açıklarıyla kısa sürede 200 milyon dolardan fazla dijital varlık çaldılar. Saldırı yolu kabaca aşağıdaki üç aşamaya ayrılabilir:

①Hızlı kredi başlat, fiyatı manipüle et

Hackerlar önce maksimum kayma ile 100 milyar haSUI hızlı kredi alarak büyük miktarda fon ödünç aldılar ve fiyat manipülasyonu yaptılar.

Kısa vadeli kredi, kullanıcıların aynı işlemde borç alıp geri ödemesine olanak tanır, sadece işlem ücreti ödenir ve yüksek kaldıraç, düşük risk ve düşük maliyet özelliklerine sahiptir. Hırsızlar bu mekanizmayı kullanarak piyasa fiyatını kısa sürede düşürdü ve bunu çok dar bir aralıkta hassas bir şekilde kontrol etti.

Ardından saldırgan, fiyat aralığını tam olarak 300,000 en düşük teklif ve 300,200 en yüksek fiyat arasında belirleyerek son derece dar bir likidite pozisyonu oluşturmayı planladı; fiyat genişliği yalnızca %1.00496621.

Yukarıdaki yöntemle, hackerlar yeterince büyük bir token miktarı ve devasa likidite kullanarak haSUI fiyatını başarıyla kontrol ettiler. Ardından, birkaç gerçek değeri olmayan token üzerinde de manipülasyon yaptılar.

② Likidite ekle

Saldırganlar dar bir likidite pozisyonu oluşturur, likidite eklediklerini beyan ederler, ancak checked_shlw fonksiyonundaki bir açığın nedeni ile sonunda yalnızca 1 token alırlar.

Esasında iki nedenden kaynaklanmaktadır:

1. Maske ayarları çok geniş: Bu, büyük bir likidite ekleme üst sınırına eşdeğerdir ve sözleşmede kullanıcı girdileri için yapılan doğrulamayı etkisiz hale getirir. Hırsızlar, anormal parametreler ayarlayarak girdileri her zaman bu üst sınırdan küçük olacak şekilde yapılandırmışlardır, böylece taşma kontrolünü geçmiştir.

2. Veri taşması kesildi: n değerine n << 64 kaydırma işlemi uygulandığında, kaydırma uint256 veri türünün etkili bit genişliğini (256 bit) aştığı için veri kesilmesi meydana geldi. Yüksek bit taşma kısmı otomatik olarak atıldı ve bu, hesaplama sonucunun beklenenden çok daha düşük olmasına neden oldu, bu da sistemin gereken haSUI miktarını düşük tahmin etmesine yol açtı. Sonuçta hesaplanan değer yaklaşık 1'den küçük olmasına rağmen, yukarı yuvarlama nedeniyle son hesaplanan değer 1'e eşit oldu; yani, bir hacker sadece 1 token ekleyerek büyük likidite elde edebilir.

③ Likiditeyi çekme

Açık kredi geri ödemesi yaparak büyük kârlar elde edin. Sonuç olarak, birden fazla likidite havuzundan toplam değeri yüz milyonlarca dolar olan token varlıklarını çekin.

Fon kaybı durumu ciddi, saldırı sonucunda aşağıdaki varlıklar çalındı:

• 12,9 milyon SUI (yaklaşık 54 milyon dolar)

• 6000 milyon USDC

• 490 milyon dolar Haedal Staked SUI

• 1950 milyon $ TOILET

• Diğer tokenler, örneğin HIPPO ve LOFI, %75-80 oranında düştü, likidite kurudu.

2.2 Bu güvenlik açığının nedenleri ve özellikleri

Cetus'un bu açığının üç özelliği var:

1. Onarım maliyeti son derece düşük: Bir yandan, Cetus olayının temel nedeni Cetus matematik kütüphanesindeki bir hatadır, protokolün fiyat mekanizması hatası veya altyapı hatası değildir. Diğer yandan, güvenlik açığı yalnızca Cetus ile sınırlıdır ve SUI'nin kodu ile ilgili değildir. Açığın kaynağı bir sınır koşulu kontrolündedir, sadece iki satır kodun değiştirilmesi riski tamamen ortadan kaldırabilir; onarım tamamlandıktan sonra hemen ana ağa dağıtılabilir, sonraki sözleşme mantığının eksiksiz olmasını sağlamak için bu açığın ortadan kaldırılmasını garanti eder.

2. Yüksek gizlilik: Sözleşme iki yıl boyunca sorunsuz bir şekilde çalıştı ve birden fazla denetim gerçekleştirildi, ancak açıklar bulunamadı. Bunun başlıca nedeni, matematiksel hesaplamalar için kullanılan Integer_Mate kütüphanesinin denetim kapsamına alınmamasıdır.

Hackerlar, aşırı değerleri kullanarak ticaret aralığını hassas bir şekilde oluşturarak, son derece yüksek likiditeye sahip nadir senaryolar oluşturdu ve bu da olağandışı mantığın tetiklenmesine neden oldu. Bu tür sorunlar, genellikle insanların gözünden kaçan bir kör noktada yer alır, bu nedenle uzun süre boyunca fark edilmeden kalır.

3. Sadece Move'a özgü bir sorun değil:

Move, kaynak güvenliği ve tür kontrolü açısından birçok akıllı sözleşme dilinden üstündür ve yaygın durumlarda tam sayı taşma sorunları için yerleşik bir denetim sağlar. Bu taşma, likidite eklenirken gerekli token miktarını hesaplarken, önce yanlış bir değeri üst sınır kontrolü olarak kullanmaktan kaynaklanmıştır ve kaydırma işlemi, normal çarpma işlemi yerine kullanılmıştır. Eğer normal toplama, çıkarma, çarpma veya bölme işlemleri kullanılsaydı, Move içinde taşma durumu otomatik olarak kontrol edilecek ve böyle bir yüksek bit kesilmesi sorunu yaşanmayacaktı.

Diğer dillerde (örneğin Solidity, Rust) benzer açıklar da ortaya çıkmış, hatta tam sayı taşması korumasının eksikliği nedeniyle daha kolay istismar edilmiştir; Solidity sürüm güncellemeleri öncesinde taşma kontrolü oldukça zayıftı. Tarihte toplama taşması, çıkarma taşması, çarpma taşması gibi durumlar yaşanmıştır ve bu durumların doğrudan nedeni, işlem sonuçlarının aralığı aşmasıdır. Örneğin, Solidity dilindeki BEC ve SMT adlı iki akıllı sözleşmedeki açıklar, dikkatlice yapılandırılmış parametreler aracılığıyla sözleşmedeki kontrol ifadelerini aşarak aşırı transferler gerçekleştirilerek saldırı yapılmıştır.

3. SUI'nin konsensüs mekanizması

3.1 SUI konsensüs mekanizması tanıtımı

Genel Bakış:

SUI, Delegated Proof of Stake (DPoS)) çerçevesini benimsemektedir. DPoS mekanizması işlem hacmini artırsa da, PoW (Proof of Work) kadar yüksek bir merkeziyetsizlik seviyesi sunamamaktadır. Bu nedenle, SUI'nin merkeziyetsizlik seviyesi görece düşüktür, yönetim eşiği görece yüksektir ve sıradan kullanıcıların ağ yönetimini doğrudan etkilemesi zordur.

• Ortalama doğrulayıcı sayısı: 106

• Ortalama Epoch süresi: 24 saat

Mekanizma süreci:

• Hak Delegasyonu: Normal kullanıcılar kendi düğümlerini çalıştırmak zorunda kalmadan, SUI'yi stake edip aday doğrulayıcılara devretmeleri yeterlidir; bu sayede ağ güvenliği sağlama ve ödül dağıtımına katılabilirler. Bu mekanizma, normal kullanıcıların katılım eşiğini düşürerek, "güvendiği" doğrulayıcıları "istihdam" ederek ağ konsensüsüne katılmalarına olanak tanır. Bu, DPoS'un geleneksel PoS'a göre büyük bir avantajıdır.

• Temsilci turu blok oluşturma: Seçilen az sayıda doğrulayıcı, sabit veya rastgele bir sırayla blok oluşturur, bu da onay hızını artırır ve TPS'yi yükseltir.

• Dinamik seçim: Her oy sayım dönemi sona erdikten sonra, oy ağırlığına göre dinamik bir döngü gerçekleştirilir ve Validator kümesi yeniden seçilir, böylece düğümlerin canlılığı, çıkarların uyumu ve merkeziyetsizlik sağlanır.

DPoS'un avantajları:

• Yüksek verimlilik: Blok üretim nodlarının sayısı kontrol edilebilir olduğu için, ağ milisaniye seviyesinde onay tamamlayabilir ve yüksek TPS ihtiyacını karşılayabilir.

• Düşük maliyet: Konsensüse katılan düğüm sayısının azalması, bilgi senkronizasyonu ve imza birleştirme için gereken ağ bant genişliği ve hesaplama kaynaklarının önemli ölçüde azalmasını sağlar. Böylece donanım ve işletme maliyetleri düşer, hesaplama gücü gereksinimleri azalır ve maliyetler daha düşük olur. Sonuçta, daha düşük kullanıcı işlem ücretleri sağlanır.

• Yüksek güvenlik: Hisse senedi ve yetkilendirme mekanizmaları, saldırı maliyetlerini ve risklerini aynı anda artırır; zincir üzerindeki el koyma mekanizması ile birlikte, kötü niyetli davranışları etkili bir şekilde bastırır.

Aynı zamanda, SUI'nin konsensüs mekanizmasında, işlemleri onaylamak için doğrulayıcıların üçte ikisinden fazlasının oy birliği sağladığı BFT (Byzantine Fault Tolerance) tabanlı bir algoritma kullanılmaktadır. Bu mekanizma, az sayıda düğüm kötü niyetli olsa bile, ağın güvenli ve verimli bir şekilde çalışmasını sağlar. Herhangi bir güncelleme veya önemli karar alındığında da, uygulanabilmesi için üçte ikiden fazla oy gerekmektedir.

Esasında, DPoS aslında imkansız bir üçgenin bir tür uzlaşma çözümüdür ve merkezsizlik ile verimlilik arasında bir denge sağlamaktadır. DPoS, güvenlik-merkezsizlik-ölçeklenebilirlik "imkansız üçgeninde", daha yüksek performans karşılığında aktif blok üretici sayısını azaltmayı seçer, saf PoS veya PoW'a göre belirli bir düzeyde tam merkezsizlikten feragat etmesine rağmen, ağın işleme kapasitesini ve işlem hızını önemli ölçüde artırmaktadır.

3.2 Bu saldırıda SUI'nin performansı

3.2.1 dondurma mekanizmasının işleyişi

Bu olayda, SUI saldırganla ilgili adresleri hızlı bir şekilde dondurdu.

Kod düzeyinde bakıldığında, transfer işlemlerinin zincire paketlenmesini engellemektir. Doğrulama düğümleri SUI blok zincirinin temel bileşenleridir ve işlemleri doğrulamak ve protokol kurallarını uygulamakla sorumludurlar. Saldırganla ilgili işlemleri topluca görmezden gelerek, bu doğrulayıcılar bir bakıma geleneksel finansal sistemdeki 'hesap dondurma' mekanizmasına benzer bir durumu konsensüs düzeyinde uygulamış oldular.

SUI kendisi bir reddetme listesi (deny list) mekanizması içerir, bu bir kara liste işlevi olup listelenen adreslerle ilgili herhangi bir işlemi engelleyebilir. Bu işlev istemcide mevcut olduğundan, saldırı gerçekleştiğinde

SUI, hacker adreslerini anında dondurabilir. Bu özellik yoksa, SUI sadece 113 doğrulayıcıya sahip olsa bile, tüm doğrulayıcıları kısa sürede tek tek yanıt vermeye koordine etmek zordur.

3.2.2 Kara listeyi kim değiştirme hakkına sahiptir?

TransactionDenyConfig, her doğrulayıcının yerel olarak yüklediği bir YAML/TOML yapılandırma dosyasıdır. Bu dosyayı düzenleyip, sıcak yeniden yükleme yapabilir veya düğümü yeniden başlatabilir ve listeyi güncelleyebilir. Görünüşte, her doğrulayıcı kendi değerlerini özgürce ifade ediyormuş gibi görünüyor.

Aslında, güvenlik politikalarının tutarlılığı ve etkinliği için, bu tür kritik yapılandırma güncellemeleri genellikle koordine bir şekilde yapılır. Bu bir "zorunlu acil güncelleme" olduğundan, esasen bu reddetme listesini kuran ve güncelleyen vakıf (veya onun yetkilendirdiği geliştiriciler)dir.

SUI kara listeyi yayınladı, teorik olarak doğrulayıcılar bunu kullanmayı seçebilir------ancak pratikte çoğu kişi bunu otomatik olarak kullanmayı varsayıyor. Bu nedenle, bu özellik kullanıcı fonlarını korusa da, esasen belirli bir merkeziyetçiliğe sahiptir.

3.2.3 Kara liste işlevinin özü

Kara liste işlevi aslında protokolün alt katman mantığı değildir, daha çok acil durumlarla başa çıkmak ve kullanıcı fonlarının güvenliğini sağlamak için ek bir güvenlik garantisi olarak düşünülebilir.

Temelde bir güvenlik garanti mekanizmasıdır. Bir kapının üzerine takılan "hırsızlık zinciri" gibi, sadece evinize girmeye çalışan, yani protokole zarar vermek isteyen kişiler için devreye girer. Kullanıcılar açısından:

• Büyük yatırımcılar için, likiditenin ana sağlayıcıları, protokolün en çok fon güvenliğini sağlamak istediği yerlerdir, çünkü aslında zincir üstü verilerdeki TVL tamamen büyük yatırımcıların katkılarından oluşmaktadır. Protokolün uzun vadeli gelişimi için, güvenliğin öncelikli olarak sağlanması gerekecektir.

• Bireysel yatırımcılar, ekosistem aktifliğine katkıda bulunanlar, teknoloji ve topluluk ortaklığına güçlü destek verenler. Proje ekibi ayrıca bireysel yatırımcıları ortaklık kurmaya çekmeyi umuyor, böylece ekosistemi yavaş yavaş geliştirebilir ve bağlılığı artırabilir.