Keyakinan yang Teguh Setelah Krisis Keamanan: Mengapa SUI Masih Memiliki Potensi Pertumbuhan Jangka Panjang?
1. Reaksi berantai yang disebabkan oleh satu serangan
Pada 22 Mei 2025, protokol AMM terkemuka yang dikerahkan di jaringan SUI, Cetus, mengalami serangan hacker. Penyerang memanfaatkan celah logika yang terkait dengan "masalah overflow integer" untuk melakukan manipulasi yang tepat, mengakibatkan kerugian lebih dari 200 juta dolar aset. Kejadian ini tidak hanya merupakan salah satu insiden keamanan terbesar di bidang DeFi sejauh ini tahun ini, tetapi juga menjadi serangan hacker paling merusak sejak peluncuran jaringan utama SUI.
Menurut data DefiLlama, TVL seluruh jaringan SUI anjlok lebih dari 330 juta USD pada hari serangan terjadi, dan jumlah yang terkunci dalam protokol Cetus sendiri menguap sebesar 84% dalam sekejap, turun menjadi 38 juta USD. Akibatnya, beberapa token populer di SUI mengalami penurunan drastis antara 76% hingga 97% dalam waktu satu jam, memicu perhatian luas pasar terhadap keamanan SUI dan stabilitas ekosistemnya.
Namun, setelah gelombang guncangan ini, ekosistem SUI menunjukkan ketahanan dan kemampuan pemulihan yang kuat. Meskipun peristiwa Cetus membawa fluktuasi kepercayaan dalam jangka pendek, dana on-chain dan tingkat aktivitas pengguna tidak mengalami penurunan yang berkelanjutan, melainkan mendorong seluruh ekosistem untuk meningkatkan perhatian terhadap keamanan, pembangunan infrastruktur, dan kualitas proyek.
2. Analisis Penyebab Serangan Cetus
2.1 Proses Implementasi Serangan
Menurut analisis teknis tim Slow Mist tentang insiden serangan Cetus, para peretas berhasil memanfaatkan celah aritmatika kunci dalam protokol, dengan bantuan pinjaman kilat, manipulasi harga yang tepat, dan cacat kontrak, mencuri lebih dari 200 juta dolar aset digital dalam waktu singkat. Jalur serangan dapat dibagi menjadi tiga tahap berikut:
①Meluncurkan pinjaman kilat, mengendalikan harga
Hacker pertama-tama memanfaatkan slippage maksimum untuk melakukan pinjaman kilat 10 miliar haSUI, meminjam sejumlah besar dana untuk melakukan manipulasi harga.
Pinjaman kilat memungkinkan pengguna untuk meminjam dan mengembalikan dana dalam satu transaksi, hanya perlu membayar biaya layanan, dengan karakteristik leverage tinggi, risiko rendah, dan biaya rendah. Hacker memanfaatkan mekanisme ini untuk menurunkan harga pasar dalam waktu singkat, dan mengendalikannya secara tepat dalam rentang yang sangat sempit.
Kemudian, penyerang bersiap untuk membuat posisi likuiditas yang sangat sempit, dengan rentang harga yang ditetapkan secara tepat antara penawaran terendah 300.000 dan harga tertinggi 300.200, dengan lebar harga hanya 1,00496621%.
Dengan cara di atas, hacker berhasil mengendalikan harga haSUI dengan menggunakan jumlah token yang cukup besar dan likuiditas yang besar. Kemudian, mereka juga melakukan manipulasi terhadap beberapa token yang tidak memiliki nilai nyata.
② Tambah likuiditas
Penyerang membuat posisi likuiditas yang sempit, menyatakan menambahkan likuiditas, tetapi karena adanya kerentanan pada fungsi checked_shlw, akhirnya hanya menerima 1 token.
Pada dasarnya disebabkan oleh dua alasan:
Pengaturan masker terlalu lebar: setara dengan batas maksimum penambahan likuiditas yang sangat besar, menyebabkan verifikasi terhadap input pengguna dalam kontrak menjadi tidak berarti. Hacker dengan mengatur parameter yang tidak biasa, membangun input yang selalu kurang dari batas tersebut, sehingga berhasil melewati deteksi overflow.
Data overflow terpotong: Saat melakukan operasi pergeseran n << 64 pada nilai n, terjadi pemotongan data karena pergeseran melebihi lebar bit efektif dari tipe data uint256 (256 bit). Bagian overflow tinggi secara otomatis dibuang, menyebabkan hasil perhitungan jauh di bawah yang diharapkan, sehingga sistem meremehkan jumlah haSUI yang diperlukan untuk pertukaran. Hasil perhitungan akhir sekitar kurang dari 1, tetapi karena dibulatkan ke atas, akhirnya dihitung sama dengan 1, yaitu hacker hanya perlu menambahkan 1 token untuk mendapatkan likuiditas yang besar.
③ Mengeluarkan likuiditas
Melakukan pembayaran pinjaman kilat, menjaga keuntungan besar. Akhirnya menarik aset token dengan total nilai mencapai ratusan juta dolar dari beberapa kolam likuiditas.
Situasi kerugian dana sangat serius, serangan menyebabkan aset berikut dicuri:
12,90 juta SUI (sekitar 54 juta dolar)
6000 juta USDC
490 juta dolar Haedal Staked SUI
1950万美元TOILET
Token lain seperti HIPPO dan LOFI turun 75-80%, likuiditas menipis
2.2 Penyebab dan karakteristik kerentanan kali ini
Kerentanan Cetus kali ini memiliki tiga karakteristik:
Biaya perbaikan sangat rendah: Di satu sisi, penyebab mendasar dari peristiwa Cetus adalah kesalahan dalam perpustakaan matematika Cetus, bukan kesalahan mekanisme harga protokol atau kesalahan arsitektur dasar. Di sisi lain, kerentanan hanya terbatas pada Cetus itu sendiri, dan tidak ada hubungannya dengan kode SUI. Sumber kerentanan terletak pada satu pemeriksaan kondisi batas, hanya perlu mengubah dua baris kode untuk sepenuhnya menghilangkan risiko; setelah perbaikan selesai, dapat segera diterapkan ke jaringan utama, memastikan logika kontrak selanjutnya lengkap dan mencegah kerentanan tersebut.
Tingkat kerahasiaan tinggi: Kontrak telah berjalan stabil selama dua tahun tanpa gangguan, Cetus Protocol telah menjalani beberapa audit, tetapi tidak ada celah yang ditemukan, penyebab utamanya adalah karena perpustakaan Integer_Mate yang digunakan untuk perhitungan matematika tidak termasuk dalam ruang lingkup audit.
Hacker memanfaatkan nilai ekstrem untuk secara tepat membangun rentang transaksi, menciptakan skenario yang sangat jarang dengan likuiditas yang sangat tinggi, sehingga memicu logika abnormal, yang menunjukkan bahwa masalah semacam ini sulit ditemukan melalui pengujian biasa. Masalah semacam ini seringkali berada di zona buta dalam pandangan orang, sehingga terpendam cukup lama sebelum ditemukan.
Bukan hanya masalah Move:
Move unggul dalam keamanan sumber daya dan pemeriksaan tipe dibandingkan dengan berbagai bahasa kontrak pintar, memiliki deteksi bawaan untuk masalah overflow integer dalam situasi umum. Overflow ini terjadi karena saat menambahkan likuiditas, jumlah token yang diperlukan dihitung menggunakan nilai yang salah untuk pemeriksaan batas atas, dan operasi pergeseran digunakan menggantikan operasi perkalian biasa. Sementara itu, jika menggunakan operasi penjumlahan, pengurangan, perkalian, atau pembagian biasa, Move secara otomatis akan memeriksa situasi overflow dan tidak akan mengalami masalah pemotongan bit tinggi seperti ini.
Kerentanan serupa juga muncul dalam bahasa lain (seperti Solidity, Rust), bahkan lebih mudah dieksploitasi karena kurangnya perlindungan terhadap overflow integer; sebelum pembaruan versi Solidity, pemeriksaan overflow sangat lemah. Dalam sejarah, telah terjadi overflow penjumlahan, overflow pengurangan, overflow perkalian, dan penyebab langsungnya adalah karena hasil perhitungan melebihi batas. Misalnya, kerentanan pada dua kontrak pintar BEC dan SMT dalam bahasa Solidity, keduanya mengeksploitasi parameter yang dirancang dengan cermat untuk menghindari pernyataan pemeriksaan dalam kontrak, melakukan transfer berlebih untuk melakukan serangan.
3. Mekanisme Konsensus SUI
3.1 Pengenalan Mekanisme Konsensus SUI
Gambaran Umum:
SUI mengambil kerangka Delegated Proof of Stake (DPoS)). Meskipun mekanisme DPoS dapat meningkatkan throughput transaksi, ia tidak dapat memberikan tingkat desentralisasi yang sangat tinggi seperti PoW (Proof of Work). Oleh karena itu, tingkat desentralisasi SUI relatif rendah, ambang batas untuk pemerintahan relatif tinggi, dan pengguna biasa sulit untuk mempengaruhi pemerintahan jaringan secara langsung.
Rata-rata jumlah validator: 106
Rata-rata periode Epoch: 24 jam
Proses mekanisme:
Penyerahan hak: Pengguna biasa tidak perlu menjalankan node sendiri, cukup dengan menyetor SUI dan mendelegasikannya kepada calon validator, mereka dapat berpartisipasi dalam jaminan keamanan jaringan dan distribusi hadiah. Mekanisme ini dapat menurunkan batas partisipasi bagi pengguna biasa, sehingga mereka dapat berpartisipasi dalam konsensus jaringan dengan "mempekerjakan" validator yang terpercaya. Ini juga merupakan salah satu keuntungan DPoS dibandingkan dengan PoS tradisional.
Mewakili putaran pemblokiran: Sebagian kecil validator yang terpilih menghasilkan blok dalam urutan tetap atau acak, meningkatkan kecepatan konfirmasi dan meningkatkan TPS.
Pemilihan dinamis: Setelah setiap periode pemungutan suara berakhir, berdasarkan bobot suara, dilakukan rotasi dinamis untuk memilih kembali kumpulan Validator, memastikan vitalitas node, konsistensi kepentingan, dan desentralisasi.
Keunggulan DPoS:
Efisiensi tinggi: Karena jumlah node pencipta blok dapat dikontrol, jaringan dapat menyelesaikan konfirmasi dalam tingkat milidetik, memenuhi kebutuhan TPS yang tinggi.
Biaya rendah: Jumlah node yang terlibat dalam konsensus lebih sedikit, sehingga bandwidth jaringan dan sumber daya komputasi yang dibutuhkan untuk sinkronisasi informasi dan agregasi tanda tangan berkurang secara signifikan. Dengan demikian, biaya perangkat keras dan operasional menurun, dan tuntutan terhadap daya komputasi juga berkurang, sehingga biayanya lebih rendah. Akhirnya, ini menghasilkan biaya transaksi pengguna yang lebih rendah.
Keamanan Tinggi: Mekanisme staking dan delegasi membuat biaya dan risiko serangan meningkat secara bersamaan; dipadukan dengan mekanisme penyitaan di blockchain, secara efektif menekan perilaku jahat.
Sementara itu, dalam mekanisme konsensus SUI, digunakan algoritma berbasis BFT (Byzantine Fault Tolerance), yang mengharuskan lebih dari dua pertiga suara dari para validator untuk mencapai kesepakatan sebelum transaksi dapat dikonfirmasi. Mekanisme ini memastikan bahwa meskipun sejumlah kecil node berbuat jahat, jaringan tetap dapat beroperasi dengan aman dan efisien. Setiap peningkatan atau keputusan besar juga memerlukan lebih dari dua pertiga suara untuk dapat dilaksanakan.
Pada dasarnya, DPoS sebenarnya adalah solusi kompromi dari segitiga ketidakmungkinan, yang melakukan kompromi antara desentralisasi dan efisiensi. DPoS memilih untuk mengurangi jumlah node pemblokiran aktif untuk mendapatkan kinerja yang lebih tinggi dalam "segitiga ketidakmungkinan" yang melibatkan keamanan-desentralisasi-skala. Dibandingkan dengan PoS atau PoW murni, DPoS melepaskan tingkat desentralisasi total tertentu, tetapi secara signifikan meningkatkan throughput jaringan dan kecepatan transaksi.
3.2 Kinerja SUI dalam serangan ini
3.2.1 Operasi mekanisme pembekuan
Dalam peristiwa ini, SUI dengan cepat membekukan alamat terkait penyerang.
Dari sudut pandang kode, ini membuat transaksi transfer tidak dapat dikemas ke dalam blockchain. Node validasi adalah komponen inti dari blockchain SUI, bertanggung jawab untuk memvalidasi transaksi dan menjalankan aturan protokol. Dengan secara kolektif mengabaikan transaksi yang terkait dengan penyerang, para validator ini setara dengan menerapkan mekanisme 'pembekuan akun' yang mirip dengan yang ada dalam keuangan tradisional di tingkat konsensus.
SUI sendiri dilengkapi dengan mekanisme daftar penolakan (deny list), ini adalah fungsi daftar hitam yang dapat menghentikan transaksi yang melibatkan alamat yang terdaftar. Karena fungsi ini sudah ada di klien, maka ketika serangan terjadi
SUI dapat segera membekukan alamat hacker. Jika tidak ada fungsi ini, bahkan jika SUI hanya memiliki 113 validator, Cetus akan sulit untuk mengoordinasikan semua validator satu per satu dalam waktu singkat.
3.2.2 Siapa yang memiliki kekuasaan untuk mengubah daftar hitam?
TransactionDenyConfig adalah file konfigurasi YAML/TOML yang dimuat secara lokal oleh setiap validator. Siapa pun yang menjalankan node dapat mengedit file ini, memuat ulang secara langsung atau me-restart node, dan memperbarui daftar. Secara permukaan, setiap validator tampaknya bebas mengekspresikan nilai-nilai mereka sendiri.
Sebenarnya, untuk konsistensi dan efektivitas kebijakan keamanan, pembaruan konfigurasi kunci ini biasanya dilakukan secara terkoordinasi karena ini adalah "pembaruan mendesak yang didorong oleh tim SUI", sehingga pada dasarnya adalah Yayasan SUI (atau pengembang yang diberi wewenang) yang menetapkan dan memperbarui daftar penolakan ini.
SUI menerbitkan daftar hitam, secara teori validator dapat memilih untuk menggunakannya atau tidak -- tetapi kenyataannya sebagian besar orang akan secara otomatis menggunakannya. Oleh karena itu, meskipun fitur ini melindungi dana pengguna, pada dasarnya memang memiliki tingkat sentralisasi tertentu.
3.2.3 Esensi dari fungsi daftar hitam
Fungsi daftar hitam sebenarnya bukanlah logika dasar dari protokol, melainkan lebih seperti lapisan tambahan untuk menghadapi situasi darurat dan memastikan keamanan dana pengguna.
Pada dasarnya adalah mekanisme jaminan keamanan. Mirip dengan "rantai pengaman" yang terikat pada pintu, hanya diaktifkan bagi mereka yang ingin melanggar masuk ke rumah, yaitu bagi orang yang berniat jahat terhadap protokol. Bagi pengguna:
Untuk pemegang besar, penyedia likuiditas utama, protokol sangat ingin menjamin keamanan dana, karena pada kenyataannya data on-chain tvl semua berasal dari kontribusi pemegang besar. Untuk memastikan perkembangan jangka panjang protokol, pasti akan mengutamakan keamanan.
Untuk individu ritel, kontributor aktivitas ekosistem, dan pendukung kuat dalam pembangunan teknologi dan komunitas. Pihak proyek juga berharap dapat menarik individu ritel untuk bersama-sama membangun, agar ekosistem dapat diperbaiki secara bertahap dan meningkatkan tingkat retensi. Sedangkan untuk bidang defi, yang terpenting adalah keamanan dana.
Kunci untuk menilai "apakah terpusat" adalah apakah pengguna memiliki kendali atas aset. Dalam hal ini, SUI menggunakan bahasa pemrograman Move untuk mencerminkan.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
10 Suka
Hadiah
10
6
Posting ulang
Bagikan
Komentar
0/400
RektRecorder
· 5jam yang lalu
Kursi depan lokasi kerugian besar
Lihat AsliBalas0
LiquidityNinja
· 5jam yang lalu
Melihat ke bawah, sudah menutup posisi.
Lihat AsliBalas0
MevHunter
· 5jam yang lalu
Menunggu untuk dump di dasar, masih ada waktu di masa depan.
Lihat AsliBalas0
NeverVoteOnDAO
· 5jam yang lalu
Ini bukan pertama kalinya saya dibobol, jadi terbiasa saja.
Lihat AsliBalas0
BtcDailyResearcher
· 5jam yang lalu
Cut Loss keluar gg
Lihat AsliBalas0
consensus_whisperer
· 5jam yang lalu
Meledak seperti ini masih ingin menipu orang untuk catch a falling knife?
Ekosistem SUI menunjukkan ketahanan: Analisis peningkatan keamanan setelah serangan Cetus dan potensi pertumbuhan jangka panjang
Keyakinan yang Teguh Setelah Krisis Keamanan: Mengapa SUI Masih Memiliki Potensi Pertumbuhan Jangka Panjang?
1. Reaksi berantai yang disebabkan oleh satu serangan
Pada 22 Mei 2025, protokol AMM terkemuka yang dikerahkan di jaringan SUI, Cetus, mengalami serangan hacker. Penyerang memanfaatkan celah logika yang terkait dengan "masalah overflow integer" untuk melakukan manipulasi yang tepat, mengakibatkan kerugian lebih dari 200 juta dolar aset. Kejadian ini tidak hanya merupakan salah satu insiden keamanan terbesar di bidang DeFi sejauh ini tahun ini, tetapi juga menjadi serangan hacker paling merusak sejak peluncuran jaringan utama SUI.
Menurut data DefiLlama, TVL seluruh jaringan SUI anjlok lebih dari 330 juta USD pada hari serangan terjadi, dan jumlah yang terkunci dalam protokol Cetus sendiri menguap sebesar 84% dalam sekejap, turun menjadi 38 juta USD. Akibatnya, beberapa token populer di SUI mengalami penurunan drastis antara 76% hingga 97% dalam waktu satu jam, memicu perhatian luas pasar terhadap keamanan SUI dan stabilitas ekosistemnya.
Namun, setelah gelombang guncangan ini, ekosistem SUI menunjukkan ketahanan dan kemampuan pemulihan yang kuat. Meskipun peristiwa Cetus membawa fluktuasi kepercayaan dalam jangka pendek, dana on-chain dan tingkat aktivitas pengguna tidak mengalami penurunan yang berkelanjutan, melainkan mendorong seluruh ekosistem untuk meningkatkan perhatian terhadap keamanan, pembangunan infrastruktur, dan kualitas proyek.
2. Analisis Penyebab Serangan Cetus
2.1 Proses Implementasi Serangan
Menurut analisis teknis tim Slow Mist tentang insiden serangan Cetus, para peretas berhasil memanfaatkan celah aritmatika kunci dalam protokol, dengan bantuan pinjaman kilat, manipulasi harga yang tepat, dan cacat kontrak, mencuri lebih dari 200 juta dolar aset digital dalam waktu singkat. Jalur serangan dapat dibagi menjadi tiga tahap berikut:
①Meluncurkan pinjaman kilat, mengendalikan harga
Hacker pertama-tama memanfaatkan slippage maksimum untuk melakukan pinjaman kilat 10 miliar haSUI, meminjam sejumlah besar dana untuk melakukan manipulasi harga.
Pinjaman kilat memungkinkan pengguna untuk meminjam dan mengembalikan dana dalam satu transaksi, hanya perlu membayar biaya layanan, dengan karakteristik leverage tinggi, risiko rendah, dan biaya rendah. Hacker memanfaatkan mekanisme ini untuk menurunkan harga pasar dalam waktu singkat, dan mengendalikannya secara tepat dalam rentang yang sangat sempit.
Kemudian, penyerang bersiap untuk membuat posisi likuiditas yang sangat sempit, dengan rentang harga yang ditetapkan secara tepat antara penawaran terendah 300.000 dan harga tertinggi 300.200, dengan lebar harga hanya 1,00496621%.
Dengan cara di atas, hacker berhasil mengendalikan harga haSUI dengan menggunakan jumlah token yang cukup besar dan likuiditas yang besar. Kemudian, mereka juga melakukan manipulasi terhadap beberapa token yang tidak memiliki nilai nyata.
② Tambah likuiditas
Penyerang membuat posisi likuiditas yang sempit, menyatakan menambahkan likuiditas, tetapi karena adanya kerentanan pada fungsi checked_shlw, akhirnya hanya menerima 1 token.
Pada dasarnya disebabkan oleh dua alasan:
Pengaturan masker terlalu lebar: setara dengan batas maksimum penambahan likuiditas yang sangat besar, menyebabkan verifikasi terhadap input pengguna dalam kontrak menjadi tidak berarti. Hacker dengan mengatur parameter yang tidak biasa, membangun input yang selalu kurang dari batas tersebut, sehingga berhasil melewati deteksi overflow.
Data overflow terpotong: Saat melakukan operasi pergeseran n << 64 pada nilai n, terjadi pemotongan data karena pergeseran melebihi lebar bit efektif dari tipe data uint256 (256 bit). Bagian overflow tinggi secara otomatis dibuang, menyebabkan hasil perhitungan jauh di bawah yang diharapkan, sehingga sistem meremehkan jumlah haSUI yang diperlukan untuk pertukaran. Hasil perhitungan akhir sekitar kurang dari 1, tetapi karena dibulatkan ke atas, akhirnya dihitung sama dengan 1, yaitu hacker hanya perlu menambahkan 1 token untuk mendapatkan likuiditas yang besar.
③ Mengeluarkan likuiditas
Melakukan pembayaran pinjaman kilat, menjaga keuntungan besar. Akhirnya menarik aset token dengan total nilai mencapai ratusan juta dolar dari beberapa kolam likuiditas.
Situasi kerugian dana sangat serius, serangan menyebabkan aset berikut dicuri:
12,90 juta SUI (sekitar 54 juta dolar)
6000 juta USDC
490 juta dolar Haedal Staked SUI
1950万美元TOILET
Token lain seperti HIPPO dan LOFI turun 75-80%, likuiditas menipis
2.2 Penyebab dan karakteristik kerentanan kali ini
Kerentanan Cetus kali ini memiliki tiga karakteristik:
Biaya perbaikan sangat rendah: Di satu sisi, penyebab mendasar dari peristiwa Cetus adalah kesalahan dalam perpustakaan matematika Cetus, bukan kesalahan mekanisme harga protokol atau kesalahan arsitektur dasar. Di sisi lain, kerentanan hanya terbatas pada Cetus itu sendiri, dan tidak ada hubungannya dengan kode SUI. Sumber kerentanan terletak pada satu pemeriksaan kondisi batas, hanya perlu mengubah dua baris kode untuk sepenuhnya menghilangkan risiko; setelah perbaikan selesai, dapat segera diterapkan ke jaringan utama, memastikan logika kontrak selanjutnya lengkap dan mencegah kerentanan tersebut.
Tingkat kerahasiaan tinggi: Kontrak telah berjalan stabil selama dua tahun tanpa gangguan, Cetus Protocol telah menjalani beberapa audit, tetapi tidak ada celah yang ditemukan, penyebab utamanya adalah karena perpustakaan Integer_Mate yang digunakan untuk perhitungan matematika tidak termasuk dalam ruang lingkup audit.
Hacker memanfaatkan nilai ekstrem untuk secara tepat membangun rentang transaksi, menciptakan skenario yang sangat jarang dengan likuiditas yang sangat tinggi, sehingga memicu logika abnormal, yang menunjukkan bahwa masalah semacam ini sulit ditemukan melalui pengujian biasa. Masalah semacam ini seringkali berada di zona buta dalam pandangan orang, sehingga terpendam cukup lama sebelum ditemukan.
Move unggul dalam keamanan sumber daya dan pemeriksaan tipe dibandingkan dengan berbagai bahasa kontrak pintar, memiliki deteksi bawaan untuk masalah overflow integer dalam situasi umum. Overflow ini terjadi karena saat menambahkan likuiditas, jumlah token yang diperlukan dihitung menggunakan nilai yang salah untuk pemeriksaan batas atas, dan operasi pergeseran digunakan menggantikan operasi perkalian biasa. Sementara itu, jika menggunakan operasi penjumlahan, pengurangan, perkalian, atau pembagian biasa, Move secara otomatis akan memeriksa situasi overflow dan tidak akan mengalami masalah pemotongan bit tinggi seperti ini.
Kerentanan serupa juga muncul dalam bahasa lain (seperti Solidity, Rust), bahkan lebih mudah dieksploitasi karena kurangnya perlindungan terhadap overflow integer; sebelum pembaruan versi Solidity, pemeriksaan overflow sangat lemah. Dalam sejarah, telah terjadi overflow penjumlahan, overflow pengurangan, overflow perkalian, dan penyebab langsungnya adalah karena hasil perhitungan melebihi batas. Misalnya, kerentanan pada dua kontrak pintar BEC dan SMT dalam bahasa Solidity, keduanya mengeksploitasi parameter yang dirancang dengan cermat untuk menghindari pernyataan pemeriksaan dalam kontrak, melakukan transfer berlebih untuk melakukan serangan.
3. Mekanisme Konsensus SUI
3.1 Pengenalan Mekanisme Konsensus SUI
Gambaran Umum:
SUI mengambil kerangka Delegated Proof of Stake (DPoS)). Meskipun mekanisme DPoS dapat meningkatkan throughput transaksi, ia tidak dapat memberikan tingkat desentralisasi yang sangat tinggi seperti PoW (Proof of Work). Oleh karena itu, tingkat desentralisasi SUI relatif rendah, ambang batas untuk pemerintahan relatif tinggi, dan pengguna biasa sulit untuk mempengaruhi pemerintahan jaringan secara langsung.
Rata-rata jumlah validator: 106
Rata-rata periode Epoch: 24 jam
Proses mekanisme:
Penyerahan hak: Pengguna biasa tidak perlu menjalankan node sendiri, cukup dengan menyetor SUI dan mendelegasikannya kepada calon validator, mereka dapat berpartisipasi dalam jaminan keamanan jaringan dan distribusi hadiah. Mekanisme ini dapat menurunkan batas partisipasi bagi pengguna biasa, sehingga mereka dapat berpartisipasi dalam konsensus jaringan dengan "mempekerjakan" validator yang terpercaya. Ini juga merupakan salah satu keuntungan DPoS dibandingkan dengan PoS tradisional.
Mewakili putaran pemblokiran: Sebagian kecil validator yang terpilih menghasilkan blok dalam urutan tetap atau acak, meningkatkan kecepatan konfirmasi dan meningkatkan TPS.
Pemilihan dinamis: Setelah setiap periode pemungutan suara berakhir, berdasarkan bobot suara, dilakukan rotasi dinamis untuk memilih kembali kumpulan Validator, memastikan vitalitas node, konsistensi kepentingan, dan desentralisasi.
Keunggulan DPoS:
Efisiensi tinggi: Karena jumlah node pencipta blok dapat dikontrol, jaringan dapat menyelesaikan konfirmasi dalam tingkat milidetik, memenuhi kebutuhan TPS yang tinggi.
Biaya rendah: Jumlah node yang terlibat dalam konsensus lebih sedikit, sehingga bandwidth jaringan dan sumber daya komputasi yang dibutuhkan untuk sinkronisasi informasi dan agregasi tanda tangan berkurang secara signifikan. Dengan demikian, biaya perangkat keras dan operasional menurun, dan tuntutan terhadap daya komputasi juga berkurang, sehingga biayanya lebih rendah. Akhirnya, ini menghasilkan biaya transaksi pengguna yang lebih rendah.
Keamanan Tinggi: Mekanisme staking dan delegasi membuat biaya dan risiko serangan meningkat secara bersamaan; dipadukan dengan mekanisme penyitaan di blockchain, secara efektif menekan perilaku jahat.
Sementara itu, dalam mekanisme konsensus SUI, digunakan algoritma berbasis BFT (Byzantine Fault Tolerance), yang mengharuskan lebih dari dua pertiga suara dari para validator untuk mencapai kesepakatan sebelum transaksi dapat dikonfirmasi. Mekanisme ini memastikan bahwa meskipun sejumlah kecil node berbuat jahat, jaringan tetap dapat beroperasi dengan aman dan efisien. Setiap peningkatan atau keputusan besar juga memerlukan lebih dari dua pertiga suara untuk dapat dilaksanakan.
Pada dasarnya, DPoS sebenarnya adalah solusi kompromi dari segitiga ketidakmungkinan, yang melakukan kompromi antara desentralisasi dan efisiensi. DPoS memilih untuk mengurangi jumlah node pemblokiran aktif untuk mendapatkan kinerja yang lebih tinggi dalam "segitiga ketidakmungkinan" yang melibatkan keamanan-desentralisasi-skala. Dibandingkan dengan PoS atau PoW murni, DPoS melepaskan tingkat desentralisasi total tertentu, tetapi secara signifikan meningkatkan throughput jaringan dan kecepatan transaksi.
3.2 Kinerja SUI dalam serangan ini
3.2.1 Operasi mekanisme pembekuan
Dalam peristiwa ini, SUI dengan cepat membekukan alamat terkait penyerang.
Dari sudut pandang kode, ini membuat transaksi transfer tidak dapat dikemas ke dalam blockchain. Node validasi adalah komponen inti dari blockchain SUI, bertanggung jawab untuk memvalidasi transaksi dan menjalankan aturan protokol. Dengan secara kolektif mengabaikan transaksi yang terkait dengan penyerang, para validator ini setara dengan menerapkan mekanisme 'pembekuan akun' yang mirip dengan yang ada dalam keuangan tradisional di tingkat konsensus.
SUI sendiri dilengkapi dengan mekanisme daftar penolakan (deny list), ini adalah fungsi daftar hitam yang dapat menghentikan transaksi yang melibatkan alamat yang terdaftar. Karena fungsi ini sudah ada di klien, maka ketika serangan terjadi
SUI dapat segera membekukan alamat hacker. Jika tidak ada fungsi ini, bahkan jika SUI hanya memiliki 113 validator, Cetus akan sulit untuk mengoordinasikan semua validator satu per satu dalam waktu singkat.
3.2.2 Siapa yang memiliki kekuasaan untuk mengubah daftar hitam?
TransactionDenyConfig adalah file konfigurasi YAML/TOML yang dimuat secara lokal oleh setiap validator. Siapa pun yang menjalankan node dapat mengedit file ini, memuat ulang secara langsung atau me-restart node, dan memperbarui daftar. Secara permukaan, setiap validator tampaknya bebas mengekspresikan nilai-nilai mereka sendiri.
Sebenarnya, untuk konsistensi dan efektivitas kebijakan keamanan, pembaruan konfigurasi kunci ini biasanya dilakukan secara terkoordinasi karena ini adalah "pembaruan mendesak yang didorong oleh tim SUI", sehingga pada dasarnya adalah Yayasan SUI (atau pengembang yang diberi wewenang) yang menetapkan dan memperbarui daftar penolakan ini.
SUI menerbitkan daftar hitam, secara teori validator dapat memilih untuk menggunakannya atau tidak -- tetapi kenyataannya sebagian besar orang akan secara otomatis menggunakannya. Oleh karena itu, meskipun fitur ini melindungi dana pengguna, pada dasarnya memang memiliki tingkat sentralisasi tertentu.
3.2.3 Esensi dari fungsi daftar hitam
Fungsi daftar hitam sebenarnya bukanlah logika dasar dari protokol, melainkan lebih seperti lapisan tambahan untuk menghadapi situasi darurat dan memastikan keamanan dana pengguna.
Pada dasarnya adalah mekanisme jaminan keamanan. Mirip dengan "rantai pengaman" yang terikat pada pintu, hanya diaktifkan bagi mereka yang ingin melanggar masuk ke rumah, yaitu bagi orang yang berniat jahat terhadap protokol. Bagi pengguna:
Untuk pemegang besar, penyedia likuiditas utama, protokol sangat ingin menjamin keamanan dana, karena pada kenyataannya data on-chain tvl semua berasal dari kontribusi pemegang besar. Untuk memastikan perkembangan jangka panjang protokol, pasti akan mengutamakan keamanan.
Untuk individu ritel, kontributor aktivitas ekosistem, dan pendukung kuat dalam pembangunan teknologi dan komunitas. Pihak proyek juga berharap dapat menarik individu ritel untuk bersama-sama membangun, agar ekosistem dapat diperbaiki secara bertahap dan meningkatkan tingkat retensi. Sedangkan untuk bidang defi, yang terpenting adalah keamanan dana.
Kunci untuk menilai "apakah terpusat" adalah apakah pengguna memiliki kendali atas aset. Dalam hal ini, SUI menggunakan bahasa pemrograman Move untuk mencerminkan.