Güvenlik krizinin ardından 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ğı üzerinde konuşlanan önde gelen AMM protokolü Cetus, bir siber saldırıya uğradı. Saldırgan, "tam sayı taşması sorunu" ile ilgili bir mantık açığını kullanarak hassas bir manipülasyon gerçekleştirdi ve 200 milyon doların üzerinde varlık kaybına neden oldu. Bu olay, bu yıl şimdiye kadar DeFi alanındaki en büyük 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ı haline geldi.

DefiLlama verilerine göre, SUI tüm zincir TVL'si saldırı gerçekleştiği gün bir ara 330 milyon dolardan fazla düşüş yaşadı, Cetus protokolünün kendine ait kilitli miktarı ise anında %84 oranında buharlaştı ve 38 milyon dolara düştü. Dolaylı olarak, SUI üzerindeki birçok popüler token bir saat içinde %76'dan %97'ye kadar düşüş gösterdi ve bu durum, SUI'nin güvenliği ve ekosistem stabilitesi üzerine geniş bir pazar ilgisi yarattı.

Ancak bu darbe sonrası 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ı etkinliği sürekli 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ı.

Klein Labs, bu saldırı olayının nedenini, SUI'nin düğüm konsensüs mekanizmasını, MOVE dilinin güvenliğini ve SUI'nin ekosistem gelişimini etrafında toplayarak, henüz gelişim aşamasında olan bu kamu blok zincirinin mevcut ekosistem yapısını inceleyecek ve gelecekteki gelişim potansiyelini tartışacaktır.

2. Cetus olayı saldırı neden analizi

2.1 Saldırı Uygulama Süreci

Slo Mo ekiplerinin Cetus saldırı olayı üzerindeki teknik analizine göre, bilgisayar korsanları protokoldeki bir anahtar aritmetik taşma açığını başarıyla kullanarak, flaş kredi, hassas fiyat manipülasyonu ve sözleşme hataları ile kısa bir süre içinde 200 milyon doların üzerinde dijital varlık çaldı. Saldırı yolu genel olarak aşağıdaki üç aşamaya ayrılabilir:

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

Hackerler ilk olarak maksimum kayma ile 100 milyar haSUI hızlı kredisi alarak büyük miktarda fon borçlandılar ve fiyat manipülasyonu yaptılar.

Lightning loan kullanıcıların aynı işlemde borç almasına ve geri ödemesine olanak tanır; sadece işlem ücreti ödeyerek, yüksek kaldıraç, düşük risk ve düşük maliyet özelliklerine sahiptir. Hackerlar bu mekanizmayı kullanarak kısa bir süre içinde piyasa fiyatını düşürmüş ve bunu son derece dar bir aralıkta hassas bir şekilde kontrol etmiştir.

Sonrasında saldırgan, fiyat aralığını tam olarak 300.000 en düşük teklif ve 300.200 en yüksek fiyat arasında, yalnızca %1.00496621 genişliğinde olacak şekilde son derece dar bir likidite pozisyonu oluşturmayı planlıyor.

Yukarıdaki yöntemle, hackerlar yeterli miktarda token 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 de manipülasyon yaptılar.

② likidite ekle

Saldırgan, likidite ekleme iddiasıyla dar bir likidite pozisyonu oluşturuyor, ancak checked_shlw fonksiyonundaki bir açık nedeniyle sonunda yalnızca 1 token alıyor.

Temelde 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ı girişlerinin kontrolü etkisiz hale gelir. Hackerlar, anormal parametreler ayarlayarak, girişi her zaman bu üst sınırdan küçük olacak şekilde yapılandırarak taşma kontrolünü geçmiştir.

2.Verilerin kesilmesi: n değerine n << 64 kaydırma işlemi uygulandığında, kaydırma uint256 veri tipinin geçerli bit genişliğini (256 bit) aştığı için veriler kesildi. Yüksek bitlerin taşma kısmı otomatik olarak atıldı ve bu da hesaplama sonucunu beklenenden çok daha düşük hale getirdi, böylece sistem, değişim için gereken haSUI miktarını küçümsemiş oldu. Nihai hesaplama sonucu yaklaşık 1'den küçük oldu, ancak yukarıya doğru yuvarlandığı için sonuç 1'e eşit çıktı, yani hacker sadece 1 token ekleyerek büyük likidite elde edebildi.

③ likiditeyi çekmek

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

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

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

• 6000 milyon USDC

• 490 milyon $ 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 eksikliktir, protokolün fiyat mekanizması hatası veya alt yapı hatası değildir. Diğer yandan, açık 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ı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ğlamak için 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 tespit edilmedi. Bunun başlıca nedeni, matematiksel hesaplamalar için kullanılan Integer_Mate kütüphanesinin denetim kapsamına alınmamış olmasıdır.

Korsanlar, aşırı değerleri kullanarak işlem aralıklarını hassas bir şekilde oluşturur, son derece yüksek likiditeye sahip nadir senaryoları oluşturarak anormal mantığı tetikler. Bu tür sorunların sıradan testlerle tespit edilmesinin zor olduğunu gösterir. Bu tür sorunlar genellikle insanların görüş alanındaki kör noktalarda bulunur, bu nedenle uzun süre gizli kalır ve ancak sonra keşfedilir.

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

Move, kaynak güvenliği ve tür kontrollerinde birçok akıllı sözleşme dilinden üstündür ve yaygın durumlarda tam sayılardaki taşma sorununu yerel olarak tespit eden bir özellik sunar. Bu taşma, likidite eklerken gereken token miktarını hesaplarken, önce yanlış bir değer kullanılarak üst sınır kontrolü yapılmasından ve yerleşik bir kaydırma işlemi yerine geleneksel çarpma işleminin kullanılmamasından kaynaklanmıştır. Eğer Move'da geleneksel toplama, çıkarma, çarpma ve bölme işlemleri kullanılsa, taşma durumu otomatik olarak kontrol edilecektir; bu nedenle böyle bir yüksek bit kesimi problemi yaşanmayacaktır.

Benzer açıklar diğer dillerde (örneğin Solidity, Rust) de ortaya çıkmıştır ve hatta tam sayı taşma korumasının eksikliği nedeniyle daha kolay istismar edilebilir; Solidity sürüm güncellemelerinden önce taşma kontrolleri 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 işlemlerinin sonuçlarının sınırı aşmasıdır. Örneğin, Solidity dilindeki BEC ve SMT adlı iki akıllı sözleşmedeki açıklar, dikkatlice hazırlanmış parametreler aracılığıyla sözleşmedeki kontrol ifadelerini atlatarak aşırı transfer gerçekleştirme saldırılarına neden olmuştur.

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ırabilse de, PoW (Proof of Work) gibi yüksek bir merkeziyetsizlik seviyesi sunamamaktadır. Bu nedenle, SUI'nin merkeziyetsizlik seviyesi görece düşüktür, yönetim eşiği ise görece yüksektir; bu da sıradan kullanıcıların ağ yönetimini doğrudan etkilemelerini zorlaştırmaktadır.

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

• Ortalama Epoch döngüsü: 24 saat

Mekanizma akışı:

• Hak Sahipliği Yetkilendirmesi: Normal kullanıcıların kendi düğümlerini çalıştırmalarına gerek yoktur, sadece SUI'yi stake edip aday doğrulayıcıya yetkilendirmeleri yeterlidir, böylece 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ılmalarını sağlar. Bu da DPoS'un geleneksel PoS'a göre en büyük avantajlarından biridir.

• Temsilci turu blok oluşturma: Seçilen azınlık doğrulayıcılar, sabit veya rastgele bir sırayla blok oluşturur, 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 seti yeniden seçilir, düğümlerin canlılığını, çıkarların tutarlılığını ve merkeziyetsizliği garanti altına alır.

DPoS'un avantajları:

• Yüksek verimlilik: Blok üretim düğümü sayısının kontrol edilebilir olması sayesinde, ağ milisaniye seviyesinde onaylama yapabilir, yüksek TPS ihtiyacını karşılar.

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

• Yüksek güvenlik: Stake etme ve yetkilendirme mekanizması, saldırı maliyetini ve riskini senkronize bir şekilde artırır; zincir üzerindeki el koyma mekanizması ile kötü niyetli davranışları etkili bir şekilde bastırır.

Aynı zamanda, SUI'nin konsensüs mekanizmasında, BFT (Bizans Hatası Toleransı) tabanlı bir algoritma kullanılmıştır. Bu algoritmanın gereği olarak, doğrulayıcıların üçte ikisinden fazlasının oy birliği sağlaması, işlemlerin onaylanabilmesi için gereklidir. Bu mekanizma, az sayıda düğüm kötü niyetli davransa 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 uygulamaya geçmek için yine üçte ikinin üzerinde oy gereklidir.

Temelde, DPoS aslında imkansız üçgenin bir tür uzlaşma çözümüdür ve merkezsizlik ile verimlilik arasında bir denge kurmuştur. DPoS, güvenlik-merkezsizlik-ölçeklenebilirlik "imkansız üçgeni" içinde, daha yüksek bir performans elde etmek için aktif blok çıkaran node sayısını azaltmayı seçer, saf PoS veya PoW'a kıyasla belirli bir dereceye kadar tam merkezsizlikten ödün verirken, 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 dondurma mekanizmasının işleyişi

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

Kod seviyesinden bakıldığında, transfer işlemlerinin blok zincirine paketlenmesini engelleyen bir durumdur. Doğrulayıcı düğümleri, SUI blok zincirinin temel bileşenleridir ve işlemleri doğrulamak ve protokol kurallarını yürütmekle sorumludurlar. Bu doğrulayıcılar, saldırganla ilgili işlemleri kolektif olarak göz ardı ederek, konsensüs seviyesinde geleneksel finansal sistemlerdeki 'hesap dondurma' mekanizmasına benzer bir uygulama gerçekleştirmiş olurlar.

SUI'nin kendisi, listelenen adreslerle ilgili işlemleri engelleyebilen bir kara liste işlevi olan bir reddetme listesi (deny list) mekanizması ile donatılmıştır. Bu işlev istemcide mevcut olduğundan, saldırı meydana geldiğinde

SUI, hırsızların adreslerini hemen dondurabilir. Bu özellik yoksa, SUI sadece 113 doğrulayıcıya sahip olsa bile, Cetus'un tüm doğrulayıcıları kısa süre içinde tek tek yanıtlamasını koordine etmesi zor olacaktır.

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

TransactionDenyConfig, her doğrulayıcının yerel olarak yüklediği 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 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 kritik yapılandırmanın güncellenmesi genellikle koordine bir şekilde yapılır. Bu, "SUI ekibinin zorunlu bir güncellemesi" olduğundan, temelde SUI vakfı (veya yetkilendirilmiş geliştiricileri) bu reddetme listesini ayarlayıp güncellemektedir.

SUI kara listeyi yayımladı, teorik olarak doğrulayıcılar bunu kullanmayı seçebilir ------ ancak pratikte çoğu kişi varsayılan olarak otomatik olarak bunu benimseyecektir. Bu nedenle, bu özellik kullanıcı fonlarını korusa da, aslında belirli bir ölçüde merkezileşme içermektedir.

3.2.3 Kara liste işlevinin özü

Kara liste fonksiyonu aslında protokolün altındaki mantık değildir, daha çok acil durumlarla başa çıkmak ve kullanıcıların fonlarının güvenliğini sağlamak için ek bir güvenlik katmanı gibidir.

Temelde bir güvenlik garanti mekanizmasıdır. Kapının üzerine bağlı bir "hırsızlık zinciri" gibi, sadece evinize girmeye çalışan, 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ı olarak, protokol en çok fon güvenliğini garanti etmek istemektedir, çünkü aslında zincir üzerindeki verilerdeki toplam kilitli değer (TVL) tamamen ana büyük yatırımcılar tarafından katkıda bulunulmaktadır. Protokolün uzun vadeli gelişimi için güvenliğin öncelikli olarak sağlanması gerekecektir.

• Bireysel yatırımcılar için, ekosistem canlılığına katkıda bulunanlar, teknoloji ve topluluk birlikte inşasına güçlü destek verenler. Proje ekibi aynı zamanda bireysel yatırımcıları birlikte inşa etmeye çekmek istiyor.