Güvenlik krizi sonrası kararlı inanç: Neden SUI hâlâ uzun vadeli yükseliş potansiyeline sahip?

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

22 Mayıs 2023'te, SUI ağına dağıtılan ö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 dolardan fazla varlık kaybına neden oldu. Bu olay, yılın başından bu yana 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 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 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ü. Bu durumdan etkilenen, SUI üzerindeki birçok popüler token (Lofi, Sudeng, Squirtle gibi) sadece bir saat içinde %76 ila %97 oranında düştü ve bu durum SUI'nin güvenliği ve ekosisteminin istikrarı üzerine piyasalarda geniş bir endişe yarattı.

Ancak bu darbe sonrasında, SUI ekosistemi güçlü bir dayanıklılık ve iyileşme yeteneği sergiledi. Cetus olayı kısa vadede güven kaybına yol açsa da, zincir üzerindeki fonlar ve kullanıcı etkinliği sürdürülebilir bir düşüş yaşamadı; aksine, tüm ekosistem güvenlik, altyapı inşası ve proje kalitesine olan dikkatin önemli ölçüde artmasını sağladı.

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, henüz gelişim aşamasında olan bu kamu blockchain'inin mevcut ekosistem yapısını inceleyeceğiz ve gelecekteki gelişim potansiyelini tartışacağız.

2. Cetus olayı saldırı sebebi analizi

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

Güvenlik ekibinin Cetus saldırı olayına dair teknik analizine göre, hackerlar protokoldeki kritik bir aritmetik taşma açığını başarılı bir şekilde kullanarak, hızlı kredi, hassas fiyat manipülasyonu ve sözleşme hataları yardımıyla kısa bir süre içinde 200 milyon dolardan fazla dijital varlık çaldı. Saldırı yolu yaklaşık olarak aşağıdaki üç aşamaya ayrılabilir:

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

Hackerler öncelikle maksimum kayma ile 100 milyar haSUI hızlı kredi kullanarak büyük miktarda fon kiraladı ve fiyat manipülasyonu yaptı.

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 sürede piyasa fiyatını düşürmüş ve bunu çok dar bir aralıkta hassas bir şekilde kontrol etmiştir.

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

Yukarıdaki yöntemle, bir hacker yeterli miktarda token ve büyük likidite kullanarak haSUI fiyatını başarılı bir şekilde manipüle etti. Ardından, birkaç gerçek değeri olmayan token üzerinde de manipülasyon yaptılar.

② likidite ekle

Saldırgan, likidite ekleyeceğini beyan ederek dar bir likidite pozisyonu oluşturur, ancak checked_shlw fonksiyonundaki bir açık nedeniyle en sonunda sadece 1 token alır.

Temelde iki nedenden kaynaklanmaktadır:

1. Maske ayarları çok geniş: Bu, son derece büyük bir likidite ekleme üst sınırına eşdeğerdir ve sözleşmedeki kullanıcı girişinin doğrulamasını etkisiz hale getirir. Hackerlar, anormal parametreler ayarlayarak, girişi her zaman bu üst sınırdan küçük olacak şekilde yapılandırarak taşma kontrolünü atlatmışlardır.

2. Veri taşması kesildi: n değerine n << 64 kaydırma işlemi uygulandığında, taşmanın uint256 veri türünün geçerli bit genişliğini (256 bit) aşması nedeniyle 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, gerekli haSUI miktarını düşük tahmin etti. Sonuçta hesaplanan değer yaklaşık 1'den küçüktü, ancak yukarı yuvarlandığı için son hesaplama 1'e eşit oldu; bu da demek oluyor ki, hacker sadece 1 token ekleyerek büyük bir likidite elde edebiliyordu.

③ Likiditeyi çekmek

Açık kredi geri ödemesi yaparak büyük kazançlarınızı koruyun. Sonunda, birden fazla likidite havuzundan toplam değeri yüz milyonlarca dolar olan 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

• 4,9 milyon dolarlık Haedal Stake Edilen SUI

• 19,500,000 $ 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. Düzeltme 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, açık sadece 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 bulunmakta olup, riski tamamen ortadan kaldırmak için yalnızca iki satır kod değiştirmek yeterlidir; düzeltme tamamlandıktan sonra hemen ana ağa dağıtılabilir, böylece sonraki sözleşme mantığı eksiksiz hale getirilir ve bu açık ortadan kaldırılır.

2. Yüksek gizlilik: Sözleşme iki yıldır sorunsuz bir şekilde çalışmakta ve sıfır hata ile yürütülmektedir, Cetus Protocol birçok denetim gerçekleştirmiştir, ancak bir güvenlik açığı tespit edilmemiştir; 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 yapılandırıyor, son derece nadir bir senaryo oluşturmak için çok yüksek likidite sunarak anormal mantığı tetikliyor, bu da 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 bulunur, bu yüzden uzun süre boyunca gizli kalmaktadırlar.

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

Move, kaynak güvenliği ve tür denetiminde birçok akıllı sözleşme dilinden üstündür ve yaygın durumlarda tam sayı taşması sorunları için yerleşik bir denetim sunar. Bu taşma, likidite eklendiğinde gerekli token sayısını hesaplamak için önce yanlış bir değerin üst sınır kontrolü olarak kullanılması ve kaydırma işleminin geleneksel çarpma işleminin yerine geçmesi nedeniyle gerçekleşmiştir. Eğer Move'da geleneksel toplama, çıkarma, çarpma veya bölme işlemleri kullanılsaydı, otomatik olarak taşma durumu kontrol edilecek ve bu tür yüksek bit kesme sorunları ortaya çıkmayacaktı.

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 kullanılabilir hale gelmiştir; Solidity sürüm güncellemelerinden önce, taşma denetimi oldukça zayıftı. Tarihte toplama taşması, çıkarma taşması, çarpma taşması gibi olaylar yaşanmıştır ve doğrudan nedenleri, hesaplama sonuçlarının aralığı aşmasından kaynaklanmaktadır. Örneğin, Solidity dilindeki BEC ve SMT adlı iki akıllı sözleşmedeki açıklar, dikkatlice yapılandırılmış parametrelerle, sözleşmedeki denetleme ifadelerini atlayarak, aşırı transfer gerçekleştirmek için saldırı yapmıştır.

3. SUI'nin konsensüs mekanizması

3.1 SUI konsensüs mekanizması tanı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 düzeyde merkeziyetsizlik sunamaz. Bu nedenle, SUI'nin merkeziyetsizlik düzeyi görece düşük, yönetim eşiği ise oldukça yüksektir; 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:

• Hakkın Devrilmesi: Normal kullanıcıların düğüm çalıştırmasına gerek yoktur, sadece SUI'yi teminat gösterebilir ve aday doğrulayıcılara devredebilirler, 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, DPoS'un geleneksel PoS'a göre önemli bir avantajıdır.

• Temsilci blok oluşturma turu: Az sayıda seçilen doğrulayıcı, 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 sonunda, oy ağırlığına göre dinamik bir dönüşüm gerçekleştirilir ve Validator kümesi yeniden seçilir, bu da düğümlerin canlılığını, çıkarların tutarlılığını 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 ihtiyacını karşılayabilir.

• Düşük maliyet: Konsensusa katılan düğüm sayısının daha az olması, bilgi senkronizasyonu ve imza birleşimi için gereken ağ bant genişliği ve hesaplama kaynaklarının önemli ölçüde azalmasını sağlar. Böylece donanım ve işletme maliyetleri düşer, hesap gücü gereksinimleri azalır, maliyet daha düşük olur. Sonuçta daha düşük kullanıcı ücretleri gerçekleştirilir.

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

Aynı zamanda, SUI'nin konsensüs mekanizmasında, BFT (Bizans Hatalarına Tolerans) tabanlı bir algoritma kullanılmıştır. İşlemin onaylanabilmesi için doğrulayıcıların üçte ikisinden fazlasının oyu ile uzlaşma sağlanması gerekmektedir. Bu mekanizma, az sayıda düğüm kötü niyetli olsa bile, ağın güvenli ve verimli bir şekilde çalışmasını sağlar. Herhangi bir yükseltme veya önemli karar alırken, uygulanabilmesi için yine üçte ikiden fazla oy gerekmektedir.

Temelde, DPoS aslında imkansız üçgenin bir tür uzlaşma çözümüdür; merkeziyetsizlik ile verimlilik arasında bir denge kurmaktadır. DPoS, güvenlik-merkeziyetsizlik-ölçeklenebilirlik "imkansız üçgeni" içinde, daha yüksek performans elde etmek için aktif blok oluşturucu düğüm sayısını azaltmayı seçer; saf PoS veya PoW'ya kıyasla belirli bir derece merkeziyetsizlikten feragat edilmiş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 Donmuş Mekanizmanın İşleyişi

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

Kod açısından bakıldığında, transfer işlemlerinin zincire paketlenmesini engellemek için bir mekanizma. Doğrulayıcı düğümleri SUI blok zincirinin temel bileşenleridir, işlemleri doğrulamak ve protokol kurallarını uygulamakla sorumludurlar. Bu doğrulayıcılar, saldırganla ilgili işlemleri topluca görmezden gelerek, bir nevi geleneksel finansal sistemdeki 'hesap dondurma' mekanizmasını konsensüs düzeyinde uygulamış olurlar.

SUI, kendinde bir reddetme listesi (deny list) mekanizması barındırıyor; bu, listelenen adreslerle ilgili herhangi bir işlemi engelleyebilen bir kara liste işlevi. Bu özellik istemcide mevcut olduğundan, saldırı gerçekleştiğinde

SUI, hacker adreslerini anında dondurabilir. Bu özellik yoksa, SUI'nin sadece 113 doğrulayıcısı olsa bile, Cetus'un tüm doğrulayıcıları kısa sürede tek tek yanıt vermesi zor olacaktır.

3.2.2 Kara listeyi kim değiştirme hakkına sahiptir?

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ının 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ırmaların güncellenmesi genellikle koordine bir şekilde yapılmaktadır. Bu, "SUI ekibinin öncülük ettiği acil bir güncelleme" olduğundan, esasen bu reddetme listesini SUI Vakfı (veya onun yetkilendirdiği geliştiriciler) ayarlayıp güncellemektedir.

SUI kara listeyi yayımladı, teorik olarak doğrulayıcılar bunun kullanılıp kullanılmayacağına karar verebilir - ancak pratikte çoğu kişi bunu otomatik olarak benimseyecek. Bu nedenle, bu özellik kullanıcı fonlarını korusa da, özünde belirli bir merkeziyetçiliğe sahip olduğu doğrudur.

3.2.3 Kara liste işlevinin özü

Kara liste işlevi aslında protokolün alt katman mantığı 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 garantisi gibi görünmektedir.

Temelde 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 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 büyük yatırımcıların katkısıdır. Protokolün uzun vadeli gelişimi için güvenliğin öncelikli olarak sağlanması gerekecektir.

• Perakendeciler için, ekosistem aktivitesine katkıda bulunan, teknoloji ve topluluk ortaklığını güçlü bir şekilde destekleyen proje.