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 2023'te, SUI ağı üzerine konuşlanmış olan önde gelen AMM protokolü Cetus, bir siber saldırıya uğradı. Saldırganlar, "tam sayı taşma problemi" ile ilgili bir mantık açığını kullanarak hassas bir kontrol gerçekleştirdi ve bu durum 200 milyon doların üzerinde bir varlık kaybına neden oldu. Bu olay, 2023 yılı itibarıyla 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 tam zincir TVL, saldırının gerçekleştiği gün 330 milyon doların üzerinde bir düşüş yaşadı ve Cetus protokolünün kendi kilitli miktarı anında %84 azalarak 38 milyon dolara düştü. Bunun sonucunda, 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 ekosistem istikrarı hakkında piyasada geniş bir endişe yarattı.

Ancak bu darbe 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 neden olsa da, zincir üzerindeki fonlar ve kullanıcı aktivitesi sürdürülebilir bir düşüş yaşamamış, aksine tüm ekosistemin güvenlik, altyapı inşası ve proje kalitesine olan ilgisinin önemli ölçüde artmasına yol açmıştır.

Bu makale, 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 dönecek, henüz gelişim aşamasının erken döneminde olan bu halka açık zincirin mevcut ekosistem yapısını gözden geçirecek ve gelecekteki gelişim potansiyelini tartışacaktır.

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

2.1 Saldırı Uygulama Süreci

Slow Mist ekibinin Cetus saldırısı olayı üzerine yaptığı teknik analizine göre, hackerlar protokoldeki kritik bir aritmetik taşma açığını başarıyla kullanarak, hızlı kredi, hassas fiyat manipülasyonu ve akıllı sözleşme kusurları ile kısa sürede 200 milyon dolardan fazla dijital varlık çaldı. Saldırı yolu genel olarak aşağıdaki üç aşamaya ayrılabilir:

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

Hackerler önce maksimum kayma ile 100 milyar haSUI anlık kredi alarak büyük miktarda fon borçlandırdı ve fiyat manipülasyonu yaptı.

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

Sonra saldırgan, fiyat aralığını tam olarak 300,000 ile 300,200 arasında ayarlayarak 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 bir likidite ile haSUI fiyatını başarılı bir şekilde manipüle ettiler. Ardından, birkaç gerçek değeri olmayan token üzerinde de manipülasyon yaptılar.

② likidite ekle

Saldırgan, likidite eklemeyi beyan ederek dar bir likidite pozisyonu oluşturuyor, ancak checked_shlw fonksiyonundaki bir açığın nedeniyle sonunda yalnızca 1 token alıyor.

Esasında iki nedenden dolayı:

1. Maske ayarları çok geniş: Bu, muazzam bir likidite ekleme sınırı ile eşdeğerdir ve sözleşmedeki kullanıcı girişi doğrulamalarını etkisiz hale getirir. Hackerlar anormal parametreler ayarlayarak, girişi her zaman bu sınırdan küçük olacak şekilde yapılandırarak taşma kontrolünü aşmışlardı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 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 da hesaplama sonucunun beklenenden çok daha düşük olmasına neden oldu, böylece sistem, işlem için gereken haSUI miktarını düşük tahmin etti. Sonuçta hesaplanan değer yaklaşık 1'den küçük, ancak yukarı yuvarlama yapıldığı için son hesaplama 1'e eşit çıkıyor, bu da hacker'ın yalnızca 1 token ekleyerek büyük likiditeyi alabileceği anlamına geliyor.

③ Likiditeyi çekme

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

• 490万美元 Haedal Stake edilmiş SUI

• 1950万美元TOILET

• Diğer tokenler olan HIPPO ve LOFI %75-80 oranında 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 altyapı hatası değildir. Diğer yandan, açık yalnızca Cetus ile sınırlıdır ve SUI'nin kodu ile hiçbir ilgisi yoktur. Açığın kaynağı bir sınır koşulu kontrolündedir, riski tamamen ortadan kaldırmak için yalnızca iki satır kodun değiştirilmesi yeterlidir; onarım tamamlandıktan sonra hemen ana ağa dağıtılabilir, böylece sonraki sözleşme mantığının eksiksiz olmasını sağlayarak bu açığı ortadan kaldırı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 ise matematik hesaplamaları için kullanılan Integer_Mate kütüphanesinin denetim kapsamına dahil edilmemiş olmasıdır.

Korsanlar, aşırı değerleri kullanarak işlem aralıklarını hassas bir şekilde yapılandırıyor, son derece yüksek likidite sunan nadir durumlar oluşturuyor, ancak bu 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özünden kaçan kör noktalarda yer alıyor, bu nedenle uzun süre boyunca gizli kalıyor.

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şması sorununa yönelik yerel bir tespit mekanizması içerir. Bu taşma, likidite eklerken gereken token sayısını hesaplarken öncelikle yanlış bir değer kullanılarak üst sınır kontrolü yapıldığından ve yer değiştirme işlemi yerine normal çarpma işlemi kullanıldığından kaynaklanmaktadır; eğer normal toplama, çıkarma, çarpma ve bölme işlemleri kullanılsaydı, Move'da taşma durumu otomatik olarak kontrol edilir ve bu tür yüksek bit kesilmesi sorunları ortaya çıkmazdı.

Benzer açıklar diğer dillerde (örneğin Solidity, Rust) de ortaya çıkmıştır ve hatta tam sayı taşması korumasının eksikliği nedeniyle daha kolay istismar edilebilir; Solidity sürüm güncellemelerinden önce taşma kontrolü çok zayıftı. Tarihte toplama taşması, çıkarma taşması, çarpma taşması gibi olaylar yaşanmıştır ve doğrudan nedeni, işlemin sonucunun sınırları aşmasıdır. Örneğin, Solidity dilindeki BEC ve SMT adlı iki akıllı kontrattaki açıklar, dikkatlice yapılandırılmış parametreler aracılığıyla kontrattaki kontrol ifadelerini atlayarak aşırı transfer gerçekleştirme saldırısını mümkün kılmış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ırsa da, PoW (İş Kanıtı) kadar yüksek bir merkeziyetsizlik seviyesi sağlayamamaktadır. Bu nedenle, SUI'nin merkeziyetsizlik seviyesi nispeten düşüktür ve yönetişim eşiği nispeten yüksektir; sıradan kullanıcılar ağ yönetimini doğrudan etkilemekte zorlanmaktadır.

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

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

Mekanizma süreci:

• Haklar Devir: Sıradan kullanıcıların kendi düğümlerini çalıştırmasına gerek yoktur, sadece SUI'yi stake edip aday doğrulayıcılara devretmeleri yeterlidir, böylece ağ güvenliğine katkıda bulunabilir ve ödül dağıtımına katılabilirler. Bu mekanizma, sıradan kullanıcıların katılım eşiğini düşürmekte ve güvenilir doğrulayıcıları "kiralayarak" ağ konsensüsüne katılmalarını sağlamaktadır. Bu, DPoS'un geleneksel PoS'a göre en büyük avantajlarından biridir.

• Temsilci turu blok oluşturma: Az sayıda seçilen 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 olarak döngüye girilir, Validator kümesi yeniden seçilir, bu da düğümlerin canlılığını, çıkar uyumunu ve merkeziyetsizliği garanti eder.

DPoS'un avantajları:

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

• Düşük maliyet: Konsensüse katılan düğüm sayısı azaldığı için, 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şletme maliyetleri düşmekte, hesaplama gücü talepleri azalmaktadır, maliyetler daha düşük olmaktadır. Sonuç olarak, daha düşük kullanıcı işlem ücretleri sağlanmıştır.

• Yüksek güvenlik: Stake etme ve yetkilendirme mekanizmaları, saldırı maliyetlerini ve risklerini senkronize bir şekilde 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, işlemin onaylanabilmesi için doğrulayıcıların üçte ikisinden fazlasının oy birliğine varmasını gerektiren BFT (Bizans Hatası 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 karar alındığında da uygulamaya geçebilmek için üçte ikinin üzerinde oy gerekmektedir.

Temelde, DPoS aslında imkansız üç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 karşılığında aktif blok üreten düğüm sayısını azaltmayı seçmekte, saf PoS veya PoW'a göre belirli bir düzeyde tam merkeziyetsizlikten feragat etmekte ancak ağın işlem kapasitesini ve işlem hızını önemli ölçüde artırmaktadır.

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

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

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

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

SUI, kendi içinde bir reddetme listesi (deny list) mekanizması barındırıyor, bu bir kara liste işlevi olup, listelenmiş adresler ile ilgili her türlü işlemi engelleyebiliyor. Bu işlev istemci içinde mevcut olduğundan, saldırı gerçekleştiğinde

SUI, hacker adreslerini hemen dondurabilir. Bu özellik olmadan, SUI yalnızca 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 Siyahı değiştirme yetkisi kimde?

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 serbestçe 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, "SUI ekibinin yürüttüğü acil bir güncelleme" olduğu için, temelde SUI vakfı (veya yetkilendirdiği geliştiriciler) bu reddetme listesini ayarlayıp günceller.

SUI kara listeyi yayınladı, teorik olarak doğrulayıcılar bunu kullanmayı seçebilir------ama pratikte çoğu insan varsayılan olarak otomatik olarak kabul eder. Bu nedenle, bu özellik kullanıcı fonlarını korusa da, aslında belirli bir derecede merkezileşme söz konusudur.

3.2.3 Kara liste fonksiyonunun özü

Kara liste işlevi aslında protokolün alt seviyesindeki bir mantık değil, daha çok ani durumlarla başa çıkmak ve kullanıcı fonlarının güvenliğini sağlamak için ek bir güvenlik garantisi katmanı gibidir.

Temelde bir güvenlik garanti mekanizmasıdır. Kapının üzerinde bağlı olan bir "hırsızlık zinciri" gibi, sadece evin kapısını ihlal etmek isteyenler, 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 fon güvenliğini garanti etmek istediği yerdir, çünkü aslında zincir üzerindeki veriler tvl, tamamen ana büyük yatırımcılar tarafından katkıda bulunmaktadır. Protokolün uzun vadeli gelişimi için, güvenliğin öncelikli olarak sağlanması gerekecektir.

• Perakendeciler için, ekosistem aktivitesine katkıda bulunanlar, teknoloji ve topluluk iş birliğinin güçlü destekçileri. Proje sahipleri aynı zamanda umuyor ki