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ğına konuşlandırılan öncü AMM protokolü Cetus, bir siber saldırıya uğradı. Saldırgan, "tam sayı taşması problemi" ile ilgili bir mantık açığını kullanarak hassas bir kontrol gerçekleştirdi ve 200 milyon dolardan fazla varlık kaybına neden oldu. Bu olay, yılın en büyük DeFi güvenlik kazalarından biri olmasının yanı sıra, SUI ana ağının lansmanından bu yana en yıkıcı siber saldırı oldu.

DefiLlama verilerine göre, SUI tüm zincir TVL'si saldırı günü bir anda 330 milyon doların üzerinde bir düşüş yaşadı, Cetus protokolünün kendine ait kilitli fonu ise anında %84 oranında buharlaştı ve 38 milyon dolara düştü. Dolaylı etkisiyle, SUI üzerindeki birçok popüler token sadece bir saat içinde %76'dan %97'ye kadar düştü, bu da SUI'nin güvenliği ve ekosistem istikrarı konusundaki geniş bir endişeyi tetikledi.

Ancak bu dalga sonrasında, SUI ekosistemi güçlü bir dayanıklılık ve iyileşme yeteneği sergiledi. Cetus olayı kısa vadede güven dalgalanmalarına neden olsa da, zincir üzerindeki fonlar ve kullanıcı aktifliği sürekli bir düşüş yaşamadı, aksine tüm ekosistemin güvenlik, altyapı inşası ve proje kalitesine olan dikkatini önemli ölçüde artırdı.

2. Cetus olayı saldırı nedeni analizi

2.1 Saldırı Uygulama Süreci

Slow Mist ekibinin Cetus saldırı olayına yönelik teknik analizine göre, saldırganlar protokoldeki bir kritik aritmetik taşma açığını başarıyla kullanarak, flaş krediler, hassas fiyat manipülasyonu ve sözleşme kusurları yardımıyla kısa bir süre içinde 200 milyon dolardan fazla dijital varlık çaldılar. Saldırı yolu yaklaşık olarak aşağıdaki üç aşamaya ayrılabilir:

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

Hackerler önce maksimum kayma ile 100 milyar haSUI hızlı kredi alarak büyük miktarda fon kiralayıp fiyat manipülasyonu yaptı.

Lightning loan, kullanıcıların aynı işlemde borç alıp geri ödeyebilmesini sağlar, yalnızca işlem ücreti ödenir ve yüksek kaldıraç, düşük risk, düşük maliyet gibi özelliklere sahiptir. Hackerlar bu mekanizmayı kullanarak kısa bir süre içinde piyasa fiyatını düşürdü ve bunu hassas bir şekilde çok dar bir aralıkta kontrol etti.

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

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

② Likidite ekle

Saldırgan, dar bir likidite pozisyonu oluşturur, likidite eklemeyi talep eder, ancak checked_shlw fonksiyonundaki bir açık nedeniyle, sonunda yalnızca 1 token alır.

Temelde iki nedenden kaynaklanmaktadır:

1. Maske ayarı çok geniş: Bu, büyük bir likidite ekleme sınırına eşdeğerdir ve sözleşmede kullanıcı girdileri için yapılan doğrulamaları etkisiz hale getirir. Hackerlar, anormal parametreler ayarlayarak girdileri her zaman bu sınırdan küçük olacak şekilde yapılandırarak taşma denetimini geçmiştir.

2.Verilerin taşması kesildi: n değerine n << 64 kaydırma işlemi uygulanırken, kaydırmanın uint256 veri tipinin etkili bit genişliğini (256 bit) aşmasından dolayı veri kesilmesi meydana geldi. Yüksek bit taşma kısmı otomatik olarak atıldı ve bu da işlemin sonucunun beklenenden çok daha düşük olmasına neden oldu, bu nedenle sistem, gerekli haSUI miktarını düşük tahmin etti. Nihai hesaplama sonucu yaklaşık 1'den küçük, ancak yukarı yuvarlandığı için son hesaplama 1'e eşit oldu, yani hacker sadece 1 token ekleyerek büyük bir likidite elde edebilir.

③ Likiditeyi çekmek

Lightning loan geri ödemesi yaparak büyük kâr elde edin. Sonunda birden fazla likidite havuzundan toplam değeri yüz milyonlarca dolara ulaşan token varlıkları çekin.

Fon kaybı durumu ciddi, saldırı aşağıdaki varlıkların çalınmasına neden oldu:

• 12,9 milyon SUI (yaklaşık 54 milyon dolar)
• 6000万美元USDC
• 490 milyon dolar Haedal Staked SUI
• 1950万美元TOILET
• Diğer tokenler olan HIPPO ve LOFI %75-80 düştü, likidite tükendi.

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 hata olup, protokolün fiyat mekanizması hatası veya alt yapı 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 kenar durumu kontrolünde yatmaktadır, yalnızca iki satır kodun değiştirilmesi riski tamamen ortadan kaldırmak için yeterlidir; onarım tamamlandıktan sonra hemen ana ağa dağıtılabilir, sonraki sözleşme mantığının eksiksiz olmasını sağlar ve bu açığı ortadan kaldırır.

2. Yüksek gizlilik: Sözleşme iki yıl boyunca sorunsuz çalıştı, Cetus Protocol birçok denetim gerçekleştirdi, ancak açıklar bulunamadı, bunun başlıca nedeni, matematiksel hesaplamalar için kullanılan Integer_Mate kütüphanesinin denetim kapsamına dahil edilmemesidir.

Hackerlar, aşırı değerleri kullanarak ticaret aralıklarını hassas bir şekilde inşa ederler, olağanüstü yüksek likiditeye sahip son derece nadir senaryolar oluştururlar, bu da anormal mantığı tetikler. Bu tür sorunlar, genellikle insanların gözlem alanında kör noktalar halinde olduğundan, uzun süre boyunca gizli kalırlar ve ancak daha sonra fark edilirler.

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

Move, kaynak güvenliği ve tür kontrolü konusunda çeşitli akıllı sözleşme dillerinden üstündür ve yaygın durumlarda tam sayı taşması sorunlarına yönelik yerel bir denetim içerir. Bu taşma, likidite eklerken gereken token miktarını hesaplamak için önce yanlış bir değerle üst sınır kontrolü yapılmasından ve kaydırma işleminin yerine geleneksel çarpma işleminin kullanılmasından kaynaklanmıştır; oysa Move'da geleneksel toplama, çıkarma, çarpma ve bölme işlemlerinde taşma durumu otomatik olarak kontrol edilir ve bu tür yüksek bit kesme problemleri meydana gelmez.

Benzer açıklar diğer dillerde (örneğin Solidity, Rust) de 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ı. Tarihsel olarak toplama taşması, çıkarma taşması, çarpma taşması gibi durumlar yaşanmıştır ve bunların doğrudan nedeni, hesaplama sonuçlarının aralığın dışına çıkmasıdır. Örneğin, Solidity dilindeki BEC ve SMT adındaki iki akıllı sözleşmedeki açıklar, dikkatlice yapılandırılmış parametreler aracılığıyla sözleşmedeki kontrol ifadelerini atlayarak aşırı transfer gerçekleştirme saldırısını sağlamıştır.

3. SUI'nin konsensüs mekanizması

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

Genel Bakış:

SUI, Delegeli Hisse Kanıtı (DeleGated Proof of Stake, kısaca DPoS)) çerçevesini benimsemektedir. DPoS mekanizması, işlem hacmini artırabilse de, PoW (İş Kanıtı) gibi yüksek bir merkeziyetsizlik seviyesi sağlayamaz. Bu nedenle, SUI'nin merkeziyetsizlik seviyesi görece düşüktür ve yönetişim engeli görece yüksektir; bu da sıradan kullanıcıların ağ yönetişimini doğrudan etkilemesini zorlaştırır.

• Ortalama doğrulayıcı sayısı: 106
• Ortalama Epoch süresi: 24 saat

Mekanizma süreci:

• Hak sahipliği yetkilendirmesi: Normal kullanıcıların kendi düğümlerini çalıştırmalarına gerek yoktur, sadece SUI'yi teminat olarak gösterip aday doğrulayıcılara yetkilendirdiklerinde ağ güvenliğine katkıda bulunabilir 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üvenilir" doğrulayıcıları "istihdam ederek" ağ konsensüsüne katılımını sağlar. Bu da DPoS'un geleneksel PoS'a göre büyük bir avantajıdır.

• Temsilci blok oluşturma turu: Seçilen azınlık doğrulayıcılar 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 dönüşüm yapılır, Validator kümesi yeniden seçilir, bu da düğümlerin canlılığını, çıkar birliğini ve merkeziyetsizliği garanti eder.

DPoS'un avantajları:

• Yüksek verimlilik: Blok oluşturma düğümü sayısının kontrol edilebilir olması nedeniyle, ağ milisaniye seviyesinde onaylama gerçekleştirebilir ve yüksek TPS talebini karşılayabilir.

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

• Yüksek güvenlik: Staking ve temsil mekanizmaları saldırı maliyetini ve riskini senkronize bir şekilde artırır; zincir üzerindeki el koyma mekanizması ile birlikte kötü niyetli davranışları etkili bir şekilde baskılar.

Aynı zamanda, SUI'nin konsensüs mekanizmasında, işlemleri onaylamak için doğrulayıcıların üçte ikisinden fazlasının oybirliği sağlamasını gerektiren BFT (Bizans Hata Toleransı) 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ışmaya devam etmesini sağlar. Herhangi bir güncelleme veya önemli bir karar alındığında da uygulanabilmesi için üçte ikinin üzerinde oy gereklidir.

Esasında, DPoS aslında imkansız bir üçgenin bir tür uzlaşma çözümüdür ve merkeziyetsizlik ile verimlilik arasında bir denge sağlamaktadır. DPoS, güvenlik-merkeziyetsizlik-ölçeklenebilirlik "imkansız üçgeninde", daha yüksek performans elde etmek için aktif blok üreten düğüm sayısını azaltmayı seçmiş, saf PoS veya PoW'a göre belirli bir derecede tam merkeziyetsizliği feda etmiştir, ancak ağın işlem hacmini ve işlem hızını önemli ölçüde artırmıştır.

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

3.2.1 Don freeze mekanizmasının çalışması

Bu olayda, SUI saldırganla ilgili adresleri hızlıca dondurdu.

Kod seviyesinden bakıldığında, transfer işlemlerinin zincire paketlenmesini engellemekte. Doğrulama düğümleri SUI blok zincirinin temel bileşenleridir, işlemleri doğrulamak ve protokol kurallarını uygulamakla sorumludur. Saldırganla ilgili işlemleri topluca göz ardı ederek, bu doğrulayıcılar, geleneksel finansal sistemlerdeki 'hesap dondurma' mekanizmasına benzer bir şekilde konsensüs seviyesinde bir uygulama gerçekleştirmiştir.

SUI, kendi içinde bir reddetme listesi (deny list) mekanizması barındırıyor, bu bir kara liste işlevidir ve listelenen adreslerle ilgili her türlü işlemi engelleyebilir. Bu işlev istemcide mevcut olduğundan, saldırı gerçekleştiğinde

SUI, hacker adreslerini hemen dondurabilir. Bu özellik olmasa, SUI sadece 113 doğrulayıcıya sahip olsa bile, Cetus'un tüm doğrulayıcıları kısa sürede tek tek yanıt vermeye koordine etmesi zor olacaktır.

3.2.2 Kara listeyi kim değiştirme yetkisine sahip?

TransactionDenyConfig, her doğrulayıcı tarafından yerel olarak yüklenen bir YAML/TOML yapılandırma dosyasıdır. Herhangi bir düğüm çalıştıran kişi bu dosyayı düzenleyebilir, sıcak yeniden yükleme yapabilir veya düğümü yeniden başlatabilir ve listeyi güncelleyebilir. Görünüşte, her bir 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. Çünkü bu, "SUI ekibinin başlattığı acil bir güncelleme"dir, bu nedenle temelde SUI vakfı (veya yetkilendirilmiş geliştiricileri) bu reddetme listesini oluşturur ve günceller.

SUI kara listeyi yayınladı, teorik olarak doğrulayıcılar bunu kullanıp kullanmamayı seçebilir ------ ancak pratikte çoğu kişi varsayılan olarak bunu otomatik olarak kabul edecektir. Bu nedenle, bu özellik kullanıcı fonlarını korusa da, aslında belirli bir merkezileşme derecesine sahiptir.

3.2.3 Kara liste özelliğinin doğası

Kara liste özelliği aslında protokolün alt düzeyinde bir mantık değildir, daha çok ani durumlarla başa çıkmak ve kullanıcı fonlarının güvenliğini sağlamak için ek bir güvenlik katmanı gibi görünmektedir.

Esasında bir güvenlik garanti mekanizmasıdır. Kapıya bağlı bir "hırsızlık zinciri" gibi, yalnızca evin kapısını zorlamak isteyen, yani protokole zarar vermek isteyenler için devreye girer. Kullanıcılar için:

• Büyük yatırımcılar için, likiditenin ana sağlayıcıları, protokolün en çok fonların güvenliğini sağlamak istediği yerdir, çünkü aslında zincir üzerindeki veriler tvl tamamen büyük yatırımcıların katkılarıyla oluşmaktadır, protokolün uzun süreli gelişimi için güvenliğin öncelikli olarak sağlanması gerekmektedir.

• Bireysel yatırımcılar için, ekosistem aktivitesine katkıda bulunanlar, teknoloji ve topluluk iş birliğinin güçlü destekçileri. Proje sahipleri ayrıca bireysel yatırımcıları iş birliğine çekmeyi umuyor, böylece ekosistem kademeli olarak geliştirilebilir ve kalıcılık artırılabilir. DeFi alanında ise en önemli konu hala fon güvenliğidir.

"Merkeziyetsizlik" olup olmadığını belirlemenin anahtarı, kullanıcıların varlıkları üzerinde kontrol sahibi olup olmadığıdır. Bu noktada, SUI, kullanıcı varlıklarına saygı gösteren Move programlama dili sayesinde bu durumu ortaya koymaktadır.