Güvenlik krizi sonrası sağlam inanç: Neden SUI hâlâ uzun vadeli yükseliş potansiyeline sahip?
1. Bir saldırının tetiklediği zincirleme reaksiyon
22 Mayıs 2025'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 kontrol gerçekleştirdi ve 200 milyon dolardan fazla varlık kaybına neden oldu. Bu olay, ş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.
Verilere göre, SUI tam zincir TVL'si saldırı günü 3.3 milyar doların üzerinde bir düşüş yaşadı ve Cetus protokolünün kendi kilitli miktarı anında %84 azalarak 38 milyon dolara düştü. Bu durumdan etkilenen, SUI üzerindeki birçok popüler token sadece bir saat içinde %76'dan %97'ye kadar düştü ve bu durum, SUI'nin güvenliği ve ekosisteminin istikrarı hakkında piyasalarda geniş bir endişe yarattı.
Ancak bu darbenin ardından, SUI ekosistemi güçlü bir dayanıklılık ve toparlanma yeteneği gösterdi. Cetus olayı kısa vadede güven dalgalanmalarına yol açsa 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 dikkatinin önemli ölçüde arttırılmasına yol açtı.
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, hâlâ 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
Güvenlik ekibinin Cetus saldırı olayına yönelik teknik analizine göre, hackerlar protokoldeki önemli bir aritmetik taşma açığını başarıyla kullandı ve flash kredi, hassas fiyat manipülasyonu ve sözleşme hatalarından faydalanarak kısa 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:
①Açık bir kredi başlatın, fiyatları manipüle edin
Hackerlar önce maksimum kayma ile 100 milyar haSUI flaş kredisi alarak büyük miktarda fon borçlandılar ve fiyat manipülasyonu yaptılar.
Flash loan, kullanıcıların aynı işlemde borç alıp geri ödemesine olanak tanır, yalnızca 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 onu son derece dar bir aralıkta hassas bir şekilde kontrol etmiştir.
Sonrasında saldırgan, fiyat aralığını tam olarak en düşük teklif olan 300,000 ile en yüksek teklif olan 300,200 arasında belirleyerek son derece dar bir likidite pozisyonu oluşturmayı hazırladı; fiyat genişliği yalnızca 1.00496621%.
Yukarıdaki yöntemle, hackerlar yeterince büyük bir token miktarı ve devasa likidite kullanarak haSUI fiyatını başarıyla manipüle etti. Ardından, birkaç gerçek değeri olmayan tokeni hedef alarak manipülasyon gerçekleştirdiler.
② Likidite ekle
Saldırganlar dar bir likidite pozisyonu oluşturur, likidite ekleyeceğini beyan eder, ancak checked_shlw fonksiyonundaki bir güvenlik açığı nedeniyle sonunda yalnızca 1 token alır.
Temelde iki nedenden dolayı:
Maske ayarları çok geniş: Kullanıcı girdilerine yönelik sözleşmedeki kontrolü etkisiz hale getiren büyük bir likidite ekleme sınırına eşdeğerdir. 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.Verilerin taşması kesildi: n değerine n << 64 kaydırma işlemi uygulandığında, uint256 veri türünün geçerli bit genişliğini (256 bit) aşan kaydırma nedeniyle 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ı. Nihai hesaplama sonucu yaklaşık 1'den küçük, ancak yukarı yuvarlama nedeniyle son hesaplanan değer 1'e eşit oldu, yani hacker sadece 1 token ekleyerek büyük bir likiditeyi çekebilir.
③ likiditeyi çekmek
Hızlı kredi geri ödemesi yaparak büyük kârları koruyun. Sonunda, birden fazla likidite havuzundan toplam değeri milyarlarca dolara ulaşan token varlıklarını çekin.
Fon kaybı durumu ciddi, saldırı sonucu aşağıdaki varlıklar çalındı:
12.9 milyon SUI (yaklaşık 5,400,000 USD)
6000万美元USDC
490 milyon dolar Haedal Staked SUI
1950万美元TOILET
Diğer tokenler olan HIPPO ve LOFI %75--80 düşüş yaşadı, likidite tükendi.
2.2 Bu zaafiyetin nedenleri ve özellikleri
Cetus'un bu açığının üç özelliği var:
Onarım 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ı ya da altyapı hatası değildir. Diğer yandan, açık sadece 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 kod değişikliği ile risk tamamen ortadan kaldırılabilir; onarım tamamlandıktan sonra hemen ana ağa dağıtılabilir, ardından sözleşme mantığının tamamlanmasını sağlamak için bu açığın önüne geçilir.
Yüksek gizlilik: Sözleşme iki yıl boyunca sorunsuz çalıştı, birçok denetim yapıldı, ancak açıklar bulunamadı, 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, uç değerleri kullanarak işlem aralıklarını hassas bir şekilde oluşturarak, olağanüstü yüksek likiditeye sahip nadir bir senaryo oluştururlar ve bu, 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 bir kör noktada bulunur, bu nedenle uzun süre gizli kalır ve ancak sonra keşfedilir.
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 denetim içerir. Bu taşma, likidite eklenirken gereken token miktarını hesaplarken önce yanlış bir değeri üst sınır kontrolü için kullanmaktan kaynaklanmıştır ve normal çarpma işlemi yerine kaydırma işlemi kullanılmıştır. Eğer normal toplama, çıkarma, çarpma veya bölme işlemleri kullanılsaydı, Move'da taşma durumu otomatik olarak kontrol edilecekti ve bu tür yüksek bit kesme sorunları yaşanmayacaktı.
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 istismar edilmiştir; Solidity sürüm güncellemeleri öncesinde taşma kontrolü oldukça zayıftı. Tarihte toplama taşması, çıkarma taşması, çarpma taşması gibi durumlar yaşanmış, doğrudan nedenleri işlemlerin sonuçlarının aralığı aşmasıdır. Örneğin, Solidity dilindeki BEC ve SMT isimli iki akıllı sözleşmedeki açıklar, dikkatlice yapılandırılmış parametreler aracılığıyla sözleşme içindeki kontrol ifadelerini atlayarak aşırı transfer gerçekleştirip saldırı yapmayı başarmıştır.
3. SUI'nin konsensüs mekanizması
3.1 SUI konsensüs mekanizmasının 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 düzeyi sunamamaktadır. Bu nedenle, SUI'nin merkeziyetsizlik düzeyi 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 etkilemesini zorlaştırmaktadır.
Ortalama doğrulayıcı sayısı: 106
Ortalama Epoch döngüsü: 24 saat
Mekanizma süreci:
Hak Yönetimi: Normal kullanıcılar kendi düğümlerini çalıştırmak zorunda kalmadan, sadece SUI'yi stake edip aday doğrulayıcılara devrederek 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ı sağlar. Bu, DPoS'un geleneksel PoS'a göre büyük bir avantajıdır.
Temsilci blok üretim aşaması: Seçilen az sayıda doğrulayıcı, belirli veya rastgele bir sırayla blok üretir, onay hızını artırır ve TPS'yi yükseltir.
Dinamik seçime: Her oy sayım dönemi sona erdikten sonra, oy ağırlığına göre dinamik dönüşüm gerçekleştirilir, Validator kümesi yeniden seçilir, düğüm canlılığını, çıkarların tutarlılığını ve merkeziyetsizliği garanti eder.
DPoS'un avantajları:
Yüksek verimlilik: Blok oluşturma düğünü sayısı kontrol edilebilir olduğundan, ağ milisaniye düzeyinde onaylama gerçekleştirebilir ve yüksek TPS gereksinimlerini 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ü gereksinimleri azalır ve maliyetler daha düşük olur. Sonuç olarak, daha düşük kullanıcı işlem ücretleri elde edilir.
Yüksek güvenlik: Stake etme ve yetkilendirme mekanizmaları, saldırı maliyetlerini ve risklerini 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ılmakta ve işlemlerin onaylanabilmesi için doğrulayıcıların üçte ikisinden fazlasının oy birliği sağlaması gerekmektedir. Bu mekanizma, az sayıda düğüm kötülük yapsa bile, ağın güvenli ve verimli bir şekilde çalışmaya devam etmesini sağlar. Herhangi bir yükseltme veya önemli karar alındığında da, uygulanabilmesi için yine üçte ikiden fazla oy gerekmektedir.
Esasında, DPoS aslında imkansız üçgenin bir uzlaşma çözümüdür ve merkeziyetsizlik ile verimlilik arasında bir denge kurar. DPoS, güvenlik-merkeziyetsizlik-ölçeklenebilirlik "imkansız üçgeninde", daha yüksek performans elde etmek için aktif blok üreten düğüm sayısını azaltmayı seçer. Saf PoS veya PoW'a kıyasla, belirli bir düzeyde tamamen merkeziyetsizleşmeden vazgeçmiş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 donanım mekanizmasının çalışması
Bu olayda, SUI saldırganla ilgili adresleri hızlı bir şekilde dondurdu.
Kod düzeyinde bakıldığında, transfer işlemlerinin zincire paketlenmesini engellemekte. 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, kendisinde bir reddetme listesi (deny list) mekanizması barındırmaktadır; bu, listelenmiş adreslerle ilgili herhangi bir işlemi engelleyebilen bir kara liste işlevidir. Bu özellik istemcide mevcut olduğundan, saldırı gerçekleştiğinde
SUI, hacker adreslerini hemen dondurabilir. Bu özellik olmasa, SUI'nin sadece 113 doğrulayıcısı olsa bile, tüm doğrulayıcıları kısa sürede tek tek yanıt vermeye koordine etmek zor olur.
3.2.2 Kara listeyi kim değiştirme hakkına sahiptir?
TransactionDenyConfig, her doğrulayıcının yerel olarak yüklediği 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ırmaların güncellemeleri genellikle koordinelidir. Bu, "takım tarafından zorunlu güncelleme" olduğu için, esasen vakfın (veya yetkilendirilmiş geliştiricilerinin) bu reddetme listesini ayarlayıp güncellemesi gerekmektedir.
Yasak listeyi yayımlamak, teorik olarak doğrulayıcıların bunu kullanıp kullanmamayı seçebileceği anlamına gelir------ancak pratikte çoğu kişi bunu otomatik olarak kabul edecektir. Bu nedenle, bu özellik kullanıcı fonlarını korusa da, özünde bir dereceye kadar merkeziyetçiliği vardır.
3.2.3 Kara liste fonksiyonunun özü
Kara liste işlevi aslında protokolün alt düzey 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 katmanıdır.
Temelde bir güvenlik garanti mekanizmasıdır. Kapıya bağlı bir "soygun zinciri" gibi, sadece evinize girmeye çalışanlar, 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ı olan protokoller, fonların güvenliğini sağlamak için en çok önem göstermelidir, çünkü aslında zincir üzerindeki verilerdeki tvl tamamen büyük yatırımcıların katkılarıyla oluşmaktadır. Protokollerin uzun süreli gelişimi için güvenliği sağlamak öncelikli olacaktır.
Perakendeciler için, ekosistem aktivitesine katkıda bulunanlar, teknoloji ve topluluk ortaklığına güçlü destek verenler. Proje sahipleri aynı zamanda perakendecileri de ortaklık yapmaya çekmek istiyor, böylece ekosistemi kademeli olarak geliştirebilir ve tutunma oranını artırabilirler. Defi alanında ise en öncelikli olan.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 Likes
Reward
13
4
Share
Comment
0/400
LiquidityOracle
· 2h ago
düşüş oldu... ne zaman düşecek acaba?
View OriginalReply0
SatoshiNotNakamoto
· 16h ago
Karanlık ve rüzgar gibi yürümek
View OriginalReply0
PuzzledScholar
· 16h ago
Belirsiz olma, bu sıfır sıkışma tarzı bir yükseliş.
SUI ekosisteminin dayanıklılığı: Cetus saldırı olayı analizi ve gelecekteki gelişim potansiyeli üzerine tartışma
Güvenlik krizi sonrası sağlam inanç: Neden SUI hâlâ uzun vadeli yükseliş potansiyeline sahip?
1. Bir saldırının tetiklediği zincirleme reaksiyon
22 Mayıs 2025'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 kontrol gerçekleştirdi ve 200 milyon dolardan fazla varlık kaybına neden oldu. Bu olay, ş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.
Verilere göre, SUI tam zincir TVL'si saldırı günü 3.3 milyar doların üzerinde bir düşüş yaşadı ve Cetus protokolünün kendi kilitli miktarı anında %84 azalarak 38 milyon dolara düştü. Bu durumdan etkilenen, SUI üzerindeki birçok popüler token sadece bir saat içinde %76'dan %97'ye kadar düştü ve bu durum, SUI'nin güvenliği ve ekosisteminin istikrarı hakkında piyasalarda geniş bir endişe yarattı.
Ancak bu darbenin ardından, SUI ekosistemi güçlü bir dayanıklılık ve toparlanma yeteneği gösterdi. Cetus olayı kısa vadede güven dalgalanmalarına yol açsa 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 dikkatinin önemli ölçüde arttırılmasına yol açtı.
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, hâlâ 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
Güvenlik ekibinin Cetus saldırı olayına yönelik teknik analizine göre, hackerlar protokoldeki önemli bir aritmetik taşma açığını başarıyla kullandı ve flash kredi, hassas fiyat manipülasyonu ve sözleşme hatalarından faydalanarak kısa 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:
①Açık bir kredi başlatın, fiyatları manipüle edin
Hackerlar önce maksimum kayma ile 100 milyar haSUI flaş kredisi alarak büyük miktarda fon borçlandılar ve fiyat manipülasyonu yaptılar.
Flash loan, kullanıcıların aynı işlemde borç alıp geri ödemesine olanak tanır, yalnızca 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 onu son derece dar bir aralıkta hassas bir şekilde kontrol etmiştir.
Sonrasında saldırgan, fiyat aralığını tam olarak en düşük teklif olan 300,000 ile en yüksek teklif olan 300,200 arasında belirleyerek son derece dar bir likidite pozisyonu oluşturmayı hazırladı; fiyat genişliği yalnızca 1.00496621%.
Yukarıdaki yöntemle, hackerlar yeterince büyük bir token miktarı ve devasa likidite kullanarak haSUI fiyatını başarıyla manipüle etti. Ardından, birkaç gerçek değeri olmayan tokeni hedef alarak manipülasyon gerçekleştirdiler.
② Likidite ekle
Saldırganlar dar bir likidite pozisyonu oluşturur, likidite ekleyeceğini beyan eder, ancak checked_shlw fonksiyonundaki bir güvenlik açığı nedeniyle sonunda yalnızca 1 token alır.
Temelde iki nedenden dolayı:
2.Verilerin taşması kesildi: n değerine n << 64 kaydırma işlemi uygulandığında, uint256 veri türünün geçerli bit genişliğini (256 bit) aşan kaydırma nedeniyle 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ı. Nihai hesaplama sonucu yaklaşık 1'den küçük, ancak yukarı yuvarlama nedeniyle son hesaplanan değer 1'e eşit oldu, yani hacker sadece 1 token ekleyerek büyük bir likiditeyi çekebilir.
③ likiditeyi çekmek
Hızlı kredi geri ödemesi yaparak büyük kârları koruyun. Sonunda, birden fazla likidite havuzundan toplam değeri milyarlarca dolara ulaşan token varlıklarını çekin.
Fon kaybı durumu ciddi, saldırı sonucu aşağıdaki varlıklar çalındı:
12.9 milyon SUI (yaklaşık 5,400,000 USD)
6000万美元USDC
490 milyon dolar Haedal Staked SUI
1950万美元TOILET
Diğer tokenler olan HIPPO ve LOFI %75--80 düşüş yaşadı, likidite tükendi.
2.2 Bu zaafiyetin nedenleri ve özellikleri
Cetus'un bu açığının üç özelliği var:
Onarım 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ı ya da altyapı hatası değildir. Diğer yandan, açık sadece 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 kod değişikliği ile risk tamamen ortadan kaldırılabilir; onarım tamamlandıktan sonra hemen ana ağa dağıtılabilir, ardından sözleşme mantığının tamamlanmasını sağlamak için bu açığın önüne geçilir.
Yüksek gizlilik: Sözleşme iki yıl boyunca sorunsuz çalıştı, birçok denetim yapıldı, ancak açıklar bulunamadı, 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, uç değerleri kullanarak işlem aralıklarını hassas bir şekilde oluşturarak, olağanüstü yüksek likiditeye sahip nadir bir senaryo oluştururlar ve bu, 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 bir kör noktada bulunur, bu nedenle uzun süre gizli kalır ve ancak sonra keşfedilir.
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 denetim içerir. Bu taşma, likidite eklenirken gereken token miktarını hesaplarken önce yanlış bir değeri üst sınır kontrolü için kullanmaktan kaynaklanmıştır ve normal çarpma işlemi yerine kaydırma işlemi kullanılmıştır. Eğer normal toplama, çıkarma, çarpma veya bölme işlemleri kullanılsaydı, Move'da taşma durumu otomatik olarak kontrol edilecekti ve bu tür yüksek bit kesme sorunları yaşanmayacaktı.
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 istismar edilmiştir; Solidity sürüm güncellemeleri öncesinde taşma kontrolü oldukça zayıftı. Tarihte toplama taşması, çıkarma taşması, çarpma taşması gibi durumlar yaşanmış, doğrudan nedenleri işlemlerin sonuçlarının aralığı aşmasıdır. Örneğin, Solidity dilindeki BEC ve SMT isimli iki akıllı sözleşmedeki açıklar, dikkatlice yapılandırılmış parametreler aracılığıyla sözleşme içindeki kontrol ifadelerini atlayarak aşırı transfer gerçekleştirip saldırı yapmayı başarmıştır.
3. SUI'nin konsensüs mekanizması
3.1 SUI konsensüs mekanizmasının 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 düzeyi sunamamaktadır. Bu nedenle, SUI'nin merkeziyetsizlik düzeyi 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 etkilemesini zorlaştırmaktadır.
Ortalama doğrulayıcı sayısı: 106
Ortalama Epoch döngüsü: 24 saat
Mekanizma süreci:
Hak Yönetimi: Normal kullanıcılar kendi düğümlerini çalıştırmak zorunda kalmadan, sadece SUI'yi stake edip aday doğrulayıcılara devrederek 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ı sağlar. Bu, DPoS'un geleneksel PoS'a göre büyük bir avantajıdır.
Temsilci blok üretim aşaması: Seçilen az sayıda doğrulayıcı, belirli veya rastgele bir sırayla blok üretir, onay hızını artırır ve TPS'yi yükseltir.
Dinamik seçime: Her oy sayım dönemi sona erdikten sonra, oy ağırlığına göre dinamik dönüşüm gerçekleştirilir, Validator kümesi yeniden seçilir, düğüm canlılığını, çıkarların tutarlılığını ve merkeziyetsizliği garanti eder.
DPoS'un avantajları:
Yüksek verimlilik: Blok oluşturma düğünü sayısı kontrol edilebilir olduğundan, ağ milisaniye düzeyinde onaylama gerçekleştirebilir ve yüksek TPS gereksinimlerini 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ü gereksinimleri azalır ve maliyetler daha düşük olur. Sonuç olarak, daha düşük kullanıcı işlem ücretleri elde edilir.
Yüksek güvenlik: Stake etme ve yetkilendirme mekanizmaları, saldırı maliyetlerini ve risklerini 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ılmakta ve işlemlerin onaylanabilmesi için doğrulayıcıların üçte ikisinden fazlasının oy birliği sağlaması gerekmektedir. Bu mekanizma, az sayıda düğüm kötülük yapsa bile, ağın güvenli ve verimli bir şekilde çalışmaya devam etmesini sağlar. Herhangi bir yükseltme veya önemli karar alındığında da, uygulanabilmesi için yine üçte ikiden fazla oy gerekmektedir.
Esasında, DPoS aslında imkansız üçgenin bir uzlaşma çözümüdür ve merkeziyetsizlik ile verimlilik arasında bir denge kurar. DPoS, güvenlik-merkeziyetsizlik-ölçeklenebilirlik "imkansız üçgeninde", daha yüksek performans elde etmek için aktif blok üreten düğüm sayısını azaltmayı seçer. Saf PoS veya PoW'a kıyasla, belirli bir düzeyde tamamen merkeziyetsizleşmeden vazgeçmiş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 donanım mekanizmasının çalışması
Bu olayda, SUI saldırganla ilgili adresleri hızlı bir şekilde dondurdu.
Kod düzeyinde bakıldığında, transfer işlemlerinin zincire paketlenmesini engellemekte. 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, kendisinde bir reddetme listesi (deny list) mekanizması barındırmaktadır; bu, listelenmiş adreslerle ilgili herhangi bir işlemi engelleyebilen bir kara liste işlevidir. Bu özellik istemcide mevcut olduğundan, saldırı gerçekleştiğinde
SUI, hacker adreslerini hemen dondurabilir. Bu özellik olmasa, SUI'nin sadece 113 doğrulayıcısı olsa bile, tüm doğrulayıcıları kısa sürede tek tek yanıt vermeye koordine etmek zor olur.
3.2.2 Kara listeyi kim değiştirme hakkına sahiptir?
TransactionDenyConfig, her doğrulayıcının yerel olarak yüklediği 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ırmaların güncellemeleri genellikle koordinelidir. Bu, "takım tarafından zorunlu güncelleme" olduğu için, esasen vakfın (veya yetkilendirilmiş geliştiricilerinin) bu reddetme listesini ayarlayıp güncellemesi gerekmektedir.
Yasak listeyi yayımlamak, teorik olarak doğrulayıcıların bunu kullanıp kullanmamayı seçebileceği anlamına gelir------ancak pratikte çoğu kişi bunu otomatik olarak kabul edecektir. Bu nedenle, bu özellik kullanıcı fonlarını korusa da, özünde bir dereceye kadar merkeziyetçiliği vardır.
3.2.3 Kara liste fonksiyonunun özü
Kara liste işlevi aslında protokolün alt düzey 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 katmanıdır.
Temelde bir güvenlik garanti mekanizmasıdır. Kapıya bağlı bir "soygun zinciri" gibi, sadece evinize girmeye çalışanlar, 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ı olan protokoller, fonların güvenliğini sağlamak için en çok önem göstermelidir, çünkü aslında zincir üzerindeki verilerdeki tvl tamamen büyük yatırımcıların katkılarıyla oluşmaktadır. Protokollerin uzun süreli gelişimi için güvenliği sağlamak öncelikli olacaktır.
Perakendeciler için, ekosistem aktivitesine katkıda bulunanlar, teknoloji ve topluluk ortaklığına güçlü destek verenler. Proje sahipleri aynı zamanda perakendecileri de ortaklık yapmaya çekmek istiyor, böylece ekosistemi kademeli olarak geliştirebilir ve tutunma oranını artırabilirler. Defi alanında ise en öncelikli olan.