Güvenlik krizinden sonraki kararlı inanç: Neden SUI hala uzun vadeli yükseliş potansiyeline sahip?

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

2025年5月22日, SUI ağı üzerinde konuşlanan ö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 müdahale gerçekleştirdi ve 200 milyon dolardan fazla varlık kaybına yol açtı. 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ı haline geldi.

DefiLlama verilerine göre, SUI tüm zincir TVL'si saldırının gerçekleştiği gün bir anda 330 milyon dolardan fazla düştü ve Cetus protokolünün kendine ait kilitli miktarı aniden %84 azalarak 38 milyon dolara geriledi. Bununla birlikte, SUI üzerindeki birçok popüler token (Lofi, Sudeng, Squirtle gibi) sadece bir saat içinde %76'dan %97'ye kadar düştü ve bu durum SUI'nin güvenliği ve ekosisteminin istikrarı konusunda piyasada geniş bir endişe yarattı.

Ama bu şok dalgasının ardından, SUI ekosistemi güçlü bir dayanıklılık ve iyileşme yeteneği sergiledi. Cetus olayı kısa vadede güven dalgalanmalarına yol açsa da, zincir üzerindeki fonlar ve kullanıcı aktivitesi sürekli bir düşüş yaşamadı, aksine tüm ekosistemin güvenlik, altyapı inşası ve proje kalitesine olan ilgisini önemli ölçüde artırdı.

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

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

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

Slow Mist ekibinin Cetus saldırı olayıyla ilgili teknik analizine göre, hackerlar protokoldeki kritik bir aritmetik taşma açığını başarıyla kullanarak, hızlı krediler, doğru 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 genel olarak aşağıdaki üç aşamaya ayrılabilir:

①Hızlı kredi başlatmak, fiyatı manipüle etmek

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

Lightning loan, kullanıcıların aynı işlemde borç alıp geri ödeyebilmesine olanak tanır ve yalnızca işlem ücreti ödenmesi gerekir. Bu mekanizma, yüksek kaldıraç, düşük risk ve düşük maliyet özelliklerine sahiptir. Hackerlar bu mekanizmayı kullanarak piyasadaki fiyatları kısa sürede düşürdü ve bunu son derece dar bir aralıkta hassas bir şekilde kontrol etti.

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

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 etti. Ardından, birkaç gerçek değeri olmayan token'a karşı da manipülasyon yaptılar.

② likidite ekle

Saldırganlar dar bir likidite pozisyonu oluşturur, likidite eklediklerini beyan eder, ancak checked_shlw fonksiyonundaki bir açık nedeniyle sonunda sadece 1 token alırlar.

Temelde iki sebepten kaynaklanmaktadır:

1. Maske ayarları çok geniş: Kullanıcı girişlerinin sözleşme içindeki doğrulamalarını etkisiz hale getiren, eşdeğer olarak büyük bir likidite ekleme sınırına yol açar. Hackerlar anormal parametreler ayarlayarak, girişi bu sınırdan her zaman daha küçük olacak şekilde yapılandırarak taşma kontrolünü atlattılar.

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

③ likiditeyi çekme

Hızlı kredi geri ödemesi yaparak büyük kazançları koruyun. Sonunda birden fazla likidite havuzundan toplam değeri yüz milyonlarca dolara ulaşan 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万美元USDC

• 490 milyon dolar Haedal Stake edilmiş SUI

• 1950万美元TOILET

• Diğer tokenler olan HIPPO ve LOFI %75-80 düştü, likidite tükendi.

2.2 Bu açıkları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 ve bu, 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, yalnızca iki satır kodun değiştirilmesiyle risk tamamen ortadan kaldırılabilir; onarım tamamlandıktan sonra hemen ana ağa 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 bulunmadı; bunun başlıca nedeni, matematiksel hesaplama için kullanılan Integer_Mate kütüphanesinin denetim kapsamına dahil edilmemiş olmasıdır.

Korsanlar, uç değerleri kullanarak ticaret aralığını hassas bir şekilde oluşturuyor, aşırı yüksek likidite sunan nadir senaryoları oluşturarak anormal mantığı tetikliyor. Bu tür sorunların sıradan testlerle tespit edilmesinin zor olduğunu gösteriyor. Bu tür sorunlar genellikle insanların görsel alanlarının kör noktalarında bulunur, bu nedenle uzun süre gizli kalır ve ancak sonra keşfedilir.

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

Move, kaynak güvenliği ve tür kontrolü açısından çeşitli akıllı sözleşme dillerinden üstündür ve yaygın senaryolar için tam sayı taşma sorunlarının yerel denetimini içerir. Bu taşma, likidite eklerken gereken token miktarını hesaplarken yanlış bir değerin üst sınır kontrolü olarak kullanılması ve kaydırma işleminin normal çarpma işleminin yerine geçmesi nedeniyle olmuştur. Eğer normal toplama, çıkarma, çarpma veya bölme işlemleri kullanılsaydı, Move'da taşma durumları otomatik olarak kontrol edilir ve bu tür yüksek bit kesme sorunu ortaya çıkmazdı.

Benzer açıklar diğer dillerde (örneğin Solidity, Rust) de ortaya çıkmıştır ve tam sayı taşmasını önleyen koruma eksikliği nedeniyle daha kolay istismar edilebilir; Solidity sürüm güncellemelerinden önce 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 doğrudan sebebi, işlemin sonucunun aralığı aşmasıdır. Örneğin, Solidity dilindeki BEC ve SMT adlı iki akıllı sözleşme üzerindeki açıklar, sözleşmedeki kontrol ifadelerini atlatmak için özenle hazırlanmış parametreler aracılığıyla aşırı transfer gerçekleştirerek saldırı gerçekleştirmiştir.

3. SUI'nin konsensüs mekanizması

3.1 SUI konsensüs mekanizmasının 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 son derece yüksek bir merkeziyetsizlik seviyesi sağlayamaz. 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:

• Haklar Yetkilendirme: Normal kullanıcıların kendi düğümlerini çalıştırmalarına gerek yoktur, sadece SUI'yi stake edip aday doğrulayıcıya yetkilendirdiklerinde, 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üvenilir" doğrulayıcıları "istihdam ederek" ağ konsensüsüne katılmalarını mümkün kılar. Bu, DPoS'un geleneksel PoS'a göre en büyük avantajlarından biridir.

• 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 rotasyon yapılır, Validator kümesi yeniden seçilir, düğümlerin canlılığını, çıkarların tutarlılığını ve merkeziyetsizliği garanti eder.

DPoS'un avantajları:

• Yüksek verimlilik: Blok üretim düğüm sayısı kontrol edilebilir olduğundan, ağ milisaniye seviyesinde onaylanabilir ve yüksek TPS gereksinimlerini karşılayabilir.

• Düşük maliyet: Konsensüse katılan düğümlerin 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üne olan talep azalır, maliyet daha da düşer. Sonuç olarak, daha düşük kullanıcı işlem ücretleri sağlanır.

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

Aynı zamanda, SUI'nin konsensüs mekanizmasında, BFT (Bizans Hata Toleransı) tabanlı bir algoritma kullanılmakta olup, doğrulayıcılar arasında üçte ikiden fazla oy birliği sağlandığında işlem onaylanabilmektedir. Bu mekanizma, az sayıda düğüm 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ımında da, uygulanabilmesi için üçte ikiden fazla oy gerekmektedir.

Temelde, DPoS aslında imkansız bir üçgenin bir 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 üçgeni" içinde, daha yüksek performans elde etmek için aktif blok üretici node sayısını azaltmayı seçerken, saf PoS veya PoW'a kıyasla belirli bir düzeyde tam merkeziyetsizlikten feragat etmiştir, ancak ağın işlem kapasitesini ve işlem hızını önemli ölçüde artırmıştır.

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

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

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

Kod açısından bakıldığında, transfer işlemlerinin zincire paketlenmesini engellemektir. Doğrulama düğümleri SUI blok zincirinin temel bileşenleridir, işlemleri doğrulamaktan ve protokol kurallarını uygulamaktan sorumludurlar. Saldırganlarla ilgili işlemleri topluca göz ardı ederek, bu doğrulayıcılar konsensüs seviyesinde geleneksel finansal sistemdeki 'hesap dondurma' mekanizmasına benzer bir uygulama gerçekleştirmiş olurlar.

SUI, kendiliğinden 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, bir hacker'ın adresini hemen dondurabilir. Bu özellik olmasa bile, SUI yalnızca 113 doğrulayıcıya sahip olsa bile, Cetus'un tüm doğrulayıcıları kısa sürede birer birer yanıt vermesi zor olacaktır.

3.2.2 Kimin kara listeyi değiştirme yetkisi var?

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 kritik yapılandırmanın güncellemeleri genellikle koordinedir. Bu bir "SUI ekibi tarafından zorunlu güncelleme" olduğundan, temelde SUI Vakfı (veya yetkilendirilmiş geliştiricileri) bu reddetme listesini ayarlamakta ve güncellemektedir.

SUI kara listeyi yayınladı, teorik olarak doğrulayıcılar bunun uygulanıp uygulanmayacağına karar verebilir------ancak pratikte çoğu kişi otomatik olarak bunu kabul eder. Bu nedenle, bu özellik kullanıcı fonlarını korusa da, aslında belirli bir merkeziyetçilik düzeyine sahiptir.

3.2.3 Kara liste işlevinin özüdür

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 gibi görünmektedir.

Temelde bir güvenlik garanti mekanizmasıdır. Kapıya bağlı bir "hırsızlık zinciri" gibi, sadece evin kapısını zorlamak isteyen, yani protokolü kötüye kullanmak 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 fon güvenliğini sağlamak istediği yerdir, çünkü aslında zincir üzerindeki verilerdeki 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ği öncelikli olarak sağlamak zorundadır.

• Bireysel yatırımcılar için, ekosistem canlılığına katkıda bulunanlar, teknoloji ve topluluk ortak yapımının güçlü desteği