Güvenlik krizinden sonraki 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şlanmış olan önde gelen 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 manipülasyon gerçekleştirdi ve 200 milyon dolardan fazla varlık kaybına neden oldu. Bu olay, yılın başından beri DeFi alanındaki en büyük ölçekli güvenlik kazalarından biri olmasının yanı sıra, SUI ana ağının faaliyete geçmesinden bu yana en yıkıcı siber saldırı haline geldi.

DefiLlama verilerine göre, SUI tüm zincir TVL'si saldırının gerçekleştiği gün 3.3 milyar dolardan fazla bir düşüş yaşadı ve Cetus protokolünün kendi kilitli miktarı anında %84 azalarak 38 milyon dolara düştü. Bu durumdan etkilenen birçok SUI üzerindeki 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ı hakkında piyasalarda geniş bir endişeye yol açtı.

Ancak bu darbe dalgasından sonra, 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 yol açmasına rağmen, zincir üzerindeki fonlar ve kullanıcı etkinliği sürekli bir düşüş yaşamadı, aksine tüm ekosistemi güvenlik, altyapı inşası ve proje kalitesine olan dikkatin önemli ölçüde artmasına teşvik etti.

2. Cetus olayının saldırı nedeni analizi

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

Sloth ekiplerinin Cetus saldırı olayına ilişkin teknik analizine göre, hackerlar protokoldeki bir anahtar aritmetik taşma açığını başarıyla kullanarak, hızlı krediler, kesin fiyat manipülasyonu ve sözleşme kusurları sayesinde kısa sürede 200 milyon dolardan fazla dijital varlık çaldı. Saldırı yolu büyük ölçüde 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ı krediyi kullanarak büyük miktarda fon borç aldılar ve fiyat manipülasyonu yaptılar.

Lightning loan, kullanıcıların aynı işlemde borç alıp geri ödemesine olanak tanır; sadece işlem ücreti ödenmesi yeterlidir ve yüksek kaldıraç, düşük risk, düşük maliyet gibi özellikler taşır. Hırsızlar bu mekanizmayı kullanarak piyasa fiyatını kısa süre içinde düşürmüş ve bunu dar bir aralıkta hassas bir şekilde kontrol etmiştir.

Ardından saldırgan, fiyat aralığını tam olarak 300,000 ile 300,200 arasında, fiyat genişliğini yalnızca %1.00496621 olarak ayarlayarak son derece dar bir likidite pozisyonu oluşturmayı planladı.

Yukarıdaki yöntemle, hackerlar yeterince büyük bir token miktarı ve devasa 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 eklediğini beyan eder, ancak checked_shlw fonksiyonundaki bir güvenlik açığı nedeniyle sonunda sadece 1 token alır.

Esasen iki nedenden kaynaklanmaktadır:

1. Maske ayarları çok geniş: Bu, büyük bir likidite ekleme sınırına eşdeğerdir ve sözleşme içindeki kullanıcı girdilerinin doğrulamasını etkisiz hale getirir. Hırsızlar, anormal parametreler ayarlayarak girişi her zaman bu sınırın altında tutarak taşma kontrolünü atlatmıştır.

2. Veri taşması kesildi: n değerine n << 64 kaydırma işlemi uygulandığında, kaydırma uint256 veri türünün geçerli 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ı, bu da hesaplama sonucunun beklenenden çok daha düşük olmasına neden oldu ve sistemin gerekli haSUI miktarını düşük tahmin etmesine yol açtı. Sonuç olarak hesaplama sonucu yaklaşık 1'den küçük oldu, ancak yukarı yuvarlama nedeniyle son hesaplama 1'e eşit oldu; bu da demek oluyor ki, bir hacker sadece 1 token ekleyerek büyük bir likidite elde edebilir.

③ likiditeyi çekmek

Hızlı kredi geri ödemesi yaparak büyük karlar elde edin. Sonunda, birden fazla likidite havuzundan toplam değeri milyarlarca dolara ulaşan token varlıklarını ç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 açığı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ı, Cetus matematik kütüphanesindeki bir hatadan kaynaklanmaktadır, protokolün fiyat mekanizması hatası veya altyapı hatası değildir. Diğer yandan, açık yalnızca Cetus ile sınırlıdır ve SUI'nin koduyla ilgili değildir. Açığın kaynağı, bir sınır koşulu kontrolünde olup, riski ortadan kaldırmak için sadece iki satır kodun değiştirilmesi yeterlidir; onarım tamamlandıktan sonra ana ağa hemen dağıtılabilir, böylece sonraki sözleşme mantığının eksiksiz olduğundan emin olunur ve bu açık ortadan kaldırılır.

2. Yüksek gizlilik: Sözleşme iki yıl boyunca sorunsuz bir şekilde ç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.

Hackerlar, aşırı değerleri kullanarak işlem aralığını hassas bir şekilde yapılandırır, son derece nadir bir senaryo olan ve çok yüksek likidite sunan senaryoları oluşturur, bu da 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 yer aldığı için uzun süre gizli kalır ve sonunda keşfedilir.

3. Sadece Move'un sorunu değil:

Move, kaynak güvenliği ve tür kontrolü açısından birçok akıllı sözleşme diline göre daha üstündür ve yerel olarak yaygın senaryolar için tam sayı taşma sorununu tespit eder. Bu taşma, likidite eklenirken gerekli token miktarının hesaplanmasında, öncelikle yanlış bir değerin üst sınır kontrolü olarak kullanılması ve kaydırma işleminin normal çarpma işlemi yerine geçmesi nedeniyle meydana gelmiştir. Eğer normal toplama, çıkarma, çarpma ve bölme işlemleri kullanılsaydı, Move otomatik olarak taşma durumunu kontrol eder ve böyle bir yüksek bit kesme sorunu ortaya çıkmazdı.

Benzer açıklar diğer dillerde (örneğin, Solidity, Rust) de ortaya çıkmış, hatta tam sayı taşma korumasının eksikliği nedeniyle daha kolay bir şekilde istismar edilmiştir; Solidity versiyon güncellemeleri öncesinde taşma kontrolü oldukça zayıftı. Tarihsel olarak toplama taşması, çıkarma taşması, çarpma taşması gibi durumlar meydana gelmiş, doğrudan nedeni işlemin sonucunun aralığı 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 atlayarak aşırı transfer gerçekleştirme saldırısı yapmıştır.

3. SUI'nin konsensüs mekanizması

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

Genel Bakış:

SUI, Delegeli Hisse Kanıtı çerçevesini (DeleGated Proof of Stake, kısaca DPoS)) benimsemektedir. DPoS mekanizması, işlem hacmini artırabilse de, PoW (İş Kanıtı) gibi 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 döngüsü: 24 saat

Mekanizma süreci:

• Hak sahipliği vekaleti: 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 vekalet verirlerse, 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, DPoS'un geleneksel PoS'a göre büyük bir avantajıdır.

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

• Dinamik Seçim: Her oy verme dönemi sonunda, oy ağırlığına göre dinamik döngü gerçekleştirilir, Validator kümesi yeniden seçilir, düğümlerin canlılığını, çıkar uyumunu ve merkeziyetsizliği garanti eder.

DPoS'un avantajları:

• Yüksek verimlilik: Blok oluşturma düğüm sayısı kontrol edilebilir olduğundan, ağ milisaniye seviyesinde onaylama tamamlayabilir ve yüksek TPS ihtiyaçlarını karşılayabilir.

• Düşük maliyet: Konsensusa 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şletim maliyetleri düşer, hesaplama gücü talepleri azalır, maliyet daha düşük olur. Sonuçta, daha düşük kullanıcı işlem ücretleri sağlanır.

• Yüksek güvenlik: Stake etme ve yetkilendirme mekanizması, saldırı maliyetini ve riskini aynı anda 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, BFT (Byzantine Fault Tolerance) tabanlı bir algoritma kullanılmıştır ve işlemin onaylanabilmesi için doğrulayıcıların üçte ikisinden fazlasının oybirliği sağlaması gerekmektedir. Bu mekanizma, azınlık düğümleri kötü niyetli olsa bile, ağın güvenli ve verimli bir şekilde çalışmasını sağlamaktadır. Herhangi bir yükseltme veya önemli karar alındığında da, uygulanabilmesi için üçte ikiden fazla oy gerekmektedir.

Temelde, DPoS aslında imkansız üçgenin bir tür uzlaşma çözümüdür ve merkeziyetsizlik ile verimlilik arasında bir denge kurmuştur. DPoS, güvenlik-merkeziyetsizlik-ölçeklenebilirlik "imkansız üçgeni" içinde, daha yüksek performans elde etmek için aktif blok oluşturma düğümü sayısını azaltmayı seçmektedir; bu, saf PoS veya PoW'a göre belirli bir düzeyde tam merkeziyetsizlikten feragat etmek anlamına gelir, ancak ağın işlem hacmini ve işlem hızını önemli ölçüde artırmaktadır.

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

3.2.1 Donmuş mekanizmanın çalışması

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

Kod düzeyinde bakıldığında, transfer işlemlerinin zincire paketlenmesini engellemek için yapılmaktadır. Doğrulayıcı düğümleri SUI blok zincirinin temel bileşenleridir, işlemleri doğrulamak ve protokol kurallarını uygulamakla sorumludurlar. Saldırganla ilgili işlemleri topluca görmezden gelerek, bu doğrulayıcılar, konsensüs düzeyinde geleneksel finansal sistemdeki 'hesap dondurma' mekanizmasına benzer bir uygulama gerçekleştirmiş olmaktadırlar.

SUI, kendi içinde bir reddetme listesi (deny list) mekanizmasına sahiptir, bu bir kara liste işlevi olup, listelenen adreslerle ilgili her türlü işlemi engelleyebilir. Bu özellik istemci içinde mevcut olduğundan, saldırı gerçekleştiğinde

SUI, hacker adreslerini anında dondurabilir. Bu özellik yoksa, SUI'nin yalnızca 113 doğrulayıcısı olsa bile, Cetus'un kısa bir süre içinde tüm doğrulayıcıları tek tek yanıt vermeye koordine etmesi zor olacaktır.

3.2.2 Kara listeyi kim değiştirebilir?

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 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 edilmiştir. Bunun nedeni, bu "SUI ekibi tarafından teşvik edilen acil bir güncelleme" olmasıdır; dolayısıyla temelde SUI vakfı (veya yetkilendirilmiş geliştiricileri) bu reddetme listesini ayarlar ve günceller.

SUI kara listeyi yayımladı, teorik olarak doğrulayıcılar bunu kullanmayı seçebilir -- ancak pratikte çoğu insan bunu otomatik olarak kabul edecektir. Bu nedenle, bu özellik kullanıcı fonlarını korusa da, aslında belirli bir merkeziyetçilik derecesine sahiptir.

3.2.3 Kara liste işlevinin özü

Kara liste fonksiyonu aslında protokolün alt yapısındaki bir mantık 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 katmanı gibidir.

Temelde bir güvenlik garanti mekanizmasıdır. Bir kapının üzerine bağlanmış bir "hırsızlık zinciri" gibi, sadece evin kapısını zorlamak isteyen, yani protokolü kötüye kullanmak isteyen kişiler 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 fon güvenliğini sağlamak istediği yerdir, çünkü aslında zincir üzerindeki verilerdeki tvl tamamen ana 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 öncelikle sağlanması gerekecektir.

• Bireysel yatırımcılar için, ekosistem aktivitesine katkıda bulunanlar, teknoloji ve topluluk iş birliğini güçlü bir şekilde destekleyenlerdir. Proje ekipleri ayrıca bireysel yatırımcıları birlikte çalışmaya çekmeyi umuyor, böylece ekosistemi kademeli olarak geliştirebilir ve tutma oranını artırabilirler. DeFi alanında ise en önemli şey hala fon güvenliğidir.

"Merkeziyetsizlik" olup olmadığını belirlemenin anahtarı, kullanıcıların varlıklarının kontrolüne sahip olup olmadıklarıdır. Bu noktada, SUI Move programlama diliyle bunu göstermektedir.