Bip, bip, bip. Bip, bip, bip.

Tidur Steven terganggu oleh bel tajam ponselnya, yang secara tiba-tiba menariknya dari mimpinya. Di kegelapan, layar bersinar terang, bergetar dengan keras di meja samping tempat tidurnya. Beep, beep, beep. Dia menggerutu, menggosok mata dengan ngantuk, dan meraih perangkatnya. Mata terpejam saat melihat pesan, hatinya merasa sedih—node-nya mati. Tanpa ragu, dia melompat keluar dari tempat tidur, setengah berpakaian, gugup membuka kunci ponselnya saat pesan-pesan lain terus masuk. Kemudian menyadarkannya—seluruh cluster mati.

Pada saat ini, di seluruh dunia, di berbagai kota dan zona waktu, ratusan operator node sedang menatap ponsel mereka dengan kesadaran yang sama: Saat yang mereka takuti telah tiba—sebuah gangguan.

Perkenalan

Seperti semua sistem terdistribusi, Solana beroperasi di bawah realitas bahwa cacat implementasi tunggal atau kasus tepi yang tidak jelas dapat menyebabkan kegagalan di seluruh jaringan. Outage, meskipun mengganggu, adalah bagian yang tak terhindarkan dari memelihara infrastruktur terdistribusi yang kompleks—baik dalam blockchain terdesentralisasi, bursa terpusat, atau bahkan penyedia layanan cloud besar seperti Amazon atau Microsoft.

Pertanyaannya bukanlah apakah kegagalan akan terjadi, tetapi kapan—dan bagaimana jaringan berkembang untuk beradaptasi dan memperkuat diri terhadap insiden masa depan. Meskipun pengujian simulasi yang ketat, testnet yang diincentivasi, dan program bug bounty yang aktif, tidak ada sistem—tidak peduli seberapa baik desainnya—dapat memprediksi setiap mode kegagalan yang mungkin terjadi. Pelajaran paling berharga berasal dari operasi dunia nyata.

Selama lima tahun terakhir, Solana telah mengalami tujuh insiden pemadaman terpisah, lima di antaranya disebabkan oleh bug klien dan dua oleh ketidakmampuan jaringan untuk menangani banjir spam transaksi. Versi awal Solana tidak memiliki mekanisme manajemen kemacetan utama, seperti biaya prioritas dan pasar biaya lokal, yang kemudian terbukti penting dalam mengurangi tekanan jaringan. Kurangnya mekanisme tersebut menyebabkan periode penurunan kinerja dan kemacetan yang berkepanjangan sepanjang tahun 2022 karena jaringan pada dasarnya memberi insentif spam.

Kejadian historis gangguan dan kinerja menurun Solana

Artikel ini akan menganalisis setiap gangguan Solana secara detail, memeriksa penyebab akar, peristiwa pemicu, dan langkah-langkah yang diambil untuk menyelesaikannya. Selain itu, kita akan membahas aspek kunci dari restart jaringan, pelaporan bug, dan konsep dasar kegagalan kelangsungan hidup dan keamanan. Meskipun bagian-bagian ini sebaiknya dibaca secara berurutan, masing-masing dirancang untuk berdiri sendiri, memungkinkan pembaca untuk melompat ke topik atau insiden gangguan yang paling menarik bagi mereka.

Kehidupan dan Keamanan

Menurut teorema CAP, juga dikenal sebagai Teorema Brewer, sebuah sistem terdistribusi hanya dapat mencapai dua dari tiga properti:

• Konsistensi - Setiap bacaan melihat semua tulisan sebelumnya.
• Ketersediaan - Setiap permintaan menerima tanggapan.
• Toleransi partisi - Sistem tetap beroperasi meskipun terjadi partisi jaringan.

Untuk blockchain, toleransi partisi adalah hal yang penting—gangguan jaringan tidak dapat dihindari. Hal ini memaksa untuk memilih antara AP (Availability + Partition Tolerance) dan CP (Consistency + Partition Tolerance). Seperti kebanyakan rantai PoS fast-finality, Solana memprioritaskan konsistensi daripada ketersediaan, menjadikannya sistem CP. Ia menghentikan selama kegagalan kritis daripada melayani data usang atau memungkinkan penulisan yang tidak aman. Meskipun hal ini berarti perangkat lunak node dapat masuk ke dalam keadaan tidak dapat pulih yang memerlukan intervensi manual, hal ini memastikan dana pengguna tetap aman.

Posisi Solana dalam pertukaran trade-off teorema CAP

Kegagalan Ketersediaan: terjadi ketika blockchain berhenti berkembang, mencegah transaksi dikonfirmasi dan blok diproduksi karena waktu henti validator, partisi jaringan, atau kebuntuan konsensus. Dalam konteks teorema CAP, hal ini sesuai dengan kehilangan ketersediaan.

Kegagalan Keamanan: terjadi ketika status terfinalisasi dari blockchain diubah atau di-fork dengan tidak semestinya. Hal ini dapat menyebabkan sejarah yang konflik atau pengeluaran ganda, sering kali disebabkan oleh bug konsensus atau serangan jahat. Dalam konteks teorema CAP, hal ini sesuai dengan kehilangan konsistensi.

Solana memprioritaskan keamanan daripada kelancaran. Oleh karena itu, jaringan akan berhenti dalam kasus tekanan jaringan ekstrim atau kegagalan konsensus daripada mengambil risiko korupsi status. Meskipun gangguan dapat mengganggu dan dapat memengaruhi aplikasi, pengguna, dan validator, mereka lebih disukai daripada konsekuensi bencana dari ledger yang tidak konsisten atau korup.

Restart Jaringan

Merestart jaringan Solana melibatkan identifikasi slot blok terakhir yang dikonfirmasi secara optimis dan me-reboot node dari snapshot status lokal yang dipercayai dari slot tersebut. Karena slot restart tidak ditentukan di rantai, operator validator harus mencapai konsensus di luar rantai untuk setuju pada titik rollback yang aman. Koordinasi ini terjadi secara publik di saluran #mb-validators di Solana Tech Discord, di mana operator validator profesional berkomunikasi secara real time. Sebagian besar operator memiliki sistem peringatan otomatis yang memberi tahu mereka saat produksi blok terhenti, memastikan respons yang cepat.

Setelah mencapai konsensus pada slot restart yang benar, operator menggunakan alat ledger untuk menghasilkan snapshot lokal baru, me-reboot validator mereka, dan menunggu setidaknya 80% dari total staking kembali online. Hanya setelah itu jaringan melanjutkan produksi blok dan validasi. Memverifikasi bahwa tidak lebih dari 20% staking offline ketika klaster restart memastikan cukup margin keamanan untuk tetap online dalam kasus node bercabang atau kembali offline segera setelah restart.

Pelaporan Bug

Program bug bounty memberi penghargaan kepada peneliti keamanan untuk mengidentifikasi dan melaporkan kerentanan perangkat lunak. Ini adalah garis pertahanan kritis, karena secara proaktif memberi insentif menangkap bug sebelum mereka dapat dieksploitasiPara peneliti keamanan dan pengembang yang mengidentifikasi potensi kerentanan dalam klien Agave didorong untuk melaporkannya melalui saluran keamanan yang tepat.Panduan pengungkapan terperinci dapat ditemukan di repositori GitHub Agave.

Hadiah ditawarkan untuk laporan yang valid tentang kerentanan kritis, dengan pembayaran berdasarkan tingkat keparahan:

• Kehilangan Dana: Hingga 25.000 SOL
• Pelanggaran Konsensus atau Keselamatan: Hingga 12.500 SOL
• Ketersediaan atau Kehilangan Ketersediaan: Hingga 5.000 SOL

Selain itu klien FireDancer memiliki program bug bounty terpisah diselenggarakan melalui Immunefi, menawarkan hadiah maksimum $500.000 USDC untuk temuan penting.

Kasus Gangguan

Bagian berikut memberikan analisis kronologis terperinci tentang pemadaman Solana dan periode penurunan kinerja, mulai dari peluncuran Mainnet Beta pada 16 Maret 2020. Pemeriksaan ini akan menyoroti insiden utama, akar penyebabnya, dan peningkatan jaringan selanjutnya, menawarkan wawasan tentang bagaimana Solana telah berevolusi untuk meningkatkan stabilitas dan ketahanan dari waktu ke waktu.

Bug Turbin: Desember 2020

Waktu tidak aktif: Sekitar enam jam

Masalah inti: Bug propagasi blok

Perbaikan:

• Melacak blok berdasarkan hash bukan nomor slot
• Perbaiki tempat-tempat di Turbin di mana deteksi kesalahan dapat dilakukan lebih awal
• Menyebarkan kesalahan yang pertama terdeteksi ke semua validator melalui gosip

Kegagalan ini disebabkan oleh sebuahmasalah perbaikan blok yang sebelumnya dikenal dan pemrosesan kodedipicu oleh bug yang tidak teridentifikasi diMekanisme penyebaran blok Solana, turbineKegagalan terjadi ketika validator mengirimkan dua blok berbeda untuk slot yang sama dan mengpropagasi keduanya ke dua partisi terpisah (A dan B) sementara partisi ketiga secara mandiri mendeteksi ketidaksesuaian.

Karena setiap partisi hanya memegang saham minoritas, tidak ada yang bisa mencapai konsensus supermayoritas untuk memajukan rantai. Masalah mendasar berasal dari bagaimana struktur data internal Solana melacak blok dan status komputasinya. Sistem menggunakan nomor slot Proof of History (PoH) (pengidentifikasi u64) untuk mereferensikan status dan blok di slot tersebut. Setelah jaringan dibagi menjadi partisi, node salah menafsirkan blok A dan B sebagai identik, mencegah perbaikan yang tepat dan sinkronisasi blok.

Setiap partisi menganggap bahwa partisi lain memiliki blok yang sama, menyebabkan konflik mendasar:

• Node yang memegang blok A menolak fork yang berasal dari blok B
• Node-node yang memegang blok B menolak garpu yang berasal dari blok A

Karena transisi negara berbeda antara partisi, validator tidak dapat memperbaiki atau mendamaikan garpu, mencegah finalitas.

Penanganan untuk masalah ini adalah untukIzinkan layanan melacak blok berdasarkan hash, bukan nomor slotJika sejumlah blok untuk slot yang sama membuat partisi, mereka akan diperlakukan sama seperti partisi dengan blok yang menempati slot yang berbeda. Node akan dapat memperbaiki semua fork yang memungkinkan, dan konsensus akan dapat menyelesaikan partisi.

Meskipun bug adalah penyebab utama dari gangguan tersebut, sebagian besar waktu tidak beroperasi disebabkan oleh menunggu cukup bobot staking untuk kembali online, karena Solana membutuhkan setidaknya 80% partisipasi staking untuk melanjutkan produksi blok.

IDO Protokol Anggur: September 2021

Waktu tidak beroperasi: Tujuh belas jam

Masalah akar: Tumpahan memori yang disebabkan oleh transaksi bot

Perbaikan:

• Abaikan kunci tulis pada program-program
• Batasan tingkat tarif pada pengiriman transaksi
• Perilaku Pengulangan RPC yang Dapat Dikonfigurasi
• Prioritas transaksi suara TPU

Pada 14 September 2021, Solana mengalami kemacetan jaringan besar setelah peluncuran penawaran DEX awal (IDO) on-chain oleh Grape Protocol di platform crowdfunding Raydium AcceleRaytor. Dalam 12 menit setelah IDO, jaringan menjadi kewalahan oleh banjir transaksi berbasis bot yang belum pernah terjadi sebelumnya dan berhenti memproduksi slot yang di-rooting. Bot ini secara efektif mengeksekusi serangan distributed denial-of-service (DDoS), mendorong beban transaksi di luar kapasitas jaringan.

Pada saat kemacetan puncak:

• Beberapa validator menerima lebih dari 300.000 transaksi per detik.
• Data transaksi mentah melebihi 1 Gbps, dengan 120.000 paket per detik.
• Lalu lintas kadang-kadang melebihi batas fisik antarmuka jaringan, menyebabkan kehilangan paket di port switch sebelum mencapai validator.

Slot Solana per detik selama gangguan IDO Grape pada 14 September 2021(Sumber data: Jump Crypto)

Salah satu bot menyusun transaksinya untuk menulis-mengunci 18 akun utama, termasuk program token SPL global dan program Serum DEX yang sekarang sudah tidak berfungsi. Ini memblokir semua transaksi yang berinteraksi dengan akun ini, sangat mengurangi kemampuan pemrosesan paralel Solana. Alih-alih mengeksekusi transaksi secara independen, jaringan menjadi macet, memproses transaksi secara berurutan — memperburuk kemacetan.

Sebuah perbaikan yang mengabaikan kunci tulis pada program-program telah dikembangkan dan dijadwalkan untuk dirilis. Kemudian, reboot jaringan memungkinkan upgrade ini, secara permanen menghilangkan vektor serangan ini.

Selama acara IDO, validator menerima banjir transaksi berbasis bot dan, pada gilirannya, meneruskan kelebihan transaksi ke pemimpin berikutnya, memperkuat kemacetan. Reboot jaringan memperkenalkan batas tarif pada penerusan transaksi untuk mencegah badai transaksi di masa depan dari para pemimpin yang luar biasa.

Node RPC Solana secara otomatis akan mencoba kembali transaksi yang gagal, fitur ini dirancang untuk meningkatkan keandalan. Namun, mekanisme retry ini memperparah banjir transaksi di bawah keadaan kemacetan ekstrem, yang membuat transaksi lama tetap beredar daripada memungkinkan jaringan pulih. Solana 1.8 memperkenalkan perilaku retry RPC yang bisa dikonfigurasi, memungkinkan aplikasi untuk mengoptimalkan retry dengan waktu kedaluwarsa yang lebih singkat dan strategi exponential backoff.

Dalam kondisi kemacetan berat, pemimpin Solana gagal memasukkan transaksi suara, yang sangat penting untuk menjaga konsensus. Akibatnya, kurangnya suara yang terkonfirmasi menyebabkan konsensus terhenti, menghentikan produksi blok root baru. Versi terbaru dari klien Solana memperkenalkan mekanisme untuk memprioritaskan transaksi suara, mencegah transaksi tersebut tenggelam oleh transaksi reguler dalam peristiwa mendatang.

Bug Kedua: Integer Overflow

Selama restart jaringan, masalah kedua muncul. Validator melaporkan jumlah saham aktif yang sangat berfluktuasi. Masalah ini berasal dari bug di mana persentase taruhan salah dikalikan dengan 100, melebihi nilai maksimum yang mungkin. Mekanisme inflasi telah menciptakan begitu banyak token SOL baru sehingga meluap bilangan bulat 64-bit yang tidak ditandatangani. Bug ini dengan cepat diidentifikasi dan ditambal sebelum restart kedua.

Kemacetan Tinggi: Januari 2022

Waktu henti: Tidak ada

Penyebab akar: Transaksi ganda berlebihan

Perbaikan sebagian:

• Rilis Solana 1.8.12 dan 1.8.14
• Optimisasi deduplikasi SigVerify
• Peningkatan dalam kinerja cache executor

Antara 6 Januari dan 12 Januari 2022, jaringan utama Solana mengalami kemacetan serius, menyebabkan kinerja menurun dan gangguan parsial. Gangguan disebabkan oleh bot yang melakukan spam transaksi duplikat berlebihan, yang signifikan mengurangi kapasitas jaringan. Blok-blok memerlukan waktu lebih lama dari yang diharapkan untuk diproses, menyebabkan pemimpin berikutnya bercabang dan lebih lanjut mengurangi throughput. Pada puncaknya, tingkat keberhasilan transaksi turun hingga 70%. Klien kesulitan menangani transaksi jaringan yang semakin kompleks dan tinggi komputasinya, mengekspos keterbatasan dalam kemampuannya untuk memenuhi permintaan.

Instabilitas tambahan terjadi dari 21 hingga 23 Januari, dengan kemacetan yang tetap persisten. Pada 22 Januari, titik akhir RPC publik ( https://api.mainnet-beta.solana.com) offline karena penyalahgunaan, karena panggilan RPC berkelompok yang dibombardir membanjiri sistem.

Untuk mengatasi masalah-masalah ini, Rilis Solana 1.8.12 secara khusus ditujukan untuk kelelahan cache program, sementara versi 1.8.14 memperkenalkan perbaikan pada cache Sysvar, penolakan SigVerify, dan penggandaan SigVerify.

Candy Machine Spam: April / May 2022

Waktu tidak beroperasi: Delapan jam

Masalah akar: Spam transaksi dari akun bot

Perbaikan:

• Pajak bot pada program mesin permen
• Peningkatan memori di Solana v1.10

Pada 30 April 2022, Solana mengalami lonjakan permintaan transaksi yang belum pernah terjadi sebelumnya. Beberapa node melaporkan mencapai enam juta permintaan per detik, menghasilkan lebih dari 100 Gbps lalu lintas per node. Lonjakan ini dipicu oleh bot yang mencoba untuk mengamankan NFT baru melalui program Metaplex Candy Machine. Mekanisme cetak ini beroperasi berdasarkan prinsip siapa cepat dia dapat, menciptakan insentif ekonomi yang kuat untuk membanjiri jaringan dengan transaksi dan memenangkan pencetakan.

30 April / 1 Mei 2022 Gangguan Mesin Permen, paket per detik masuk(Sumber data: Jump Crypto)

Ketika volume transaksi meroket, validator kehabisan memori dan jatuh, akhirnya menghentikan konsensus. Hasil pemungutan suara yang tidak memadai mencegah finalisasi blok sebelumnya, mencegah garpu yang ditinggalkan dibersihkan. Akibatnya, validator menjadi kewalahan oleh banyaknya fork yang harus mereka evaluasi, melebihi kapasitas mereka bahkan setelah restart dan memerlukan intervensi manual untuk memulihkan jaringan.

Meskipun gangguan ini memiliki kesamaan dengan insiden September 2021, Solana menunjukkan ketahanan yang lebih baik. Meskipun mengalami 10.000% lebih banyak permintaan transaksi daripada gangguan sebelumnya, jaringan tetap beroperasi untuk jangka waktu yang lebih lama, mencerminkan peningkatan yang dilakukan oleh komunitas validator sebagai respons terhadap tantangan penskalaan sebelumnya.

Outage Mesin Permen 30 April / 1 Mei 2022, validator aktif(Sumber data: Jump Crypto)

Restart jaringan hanya memakan waktu kurang dari 1,5 jam setelah snapshot kanonikal disetujui. Solana v1.10 termasuk peningkatan penggunaan memori untuk memperpanjang waktu node dapat bertahan dari konsensus yang lambat atau terhenti.

Namun, masalah mendasar masih belum terselesaikan. Pemimpin masih memproses transaksi yang bersaing untuk data akun yang sama berdasarkan prinsip siapa cepat dia dapat tanpa pencegahan spam yang efektif, sehingga pengguna tidak dapat memprioritaskan urgensi transaksi mereka. Untuk mengatasi hal ini, tiga mekanisme jangka panjang diusulkan sebagai solusi praktis.

Pengadopsian QUIC: Sebelumnya, Solana mengandalkan protokol jaringan UDP (User Datagram Protocol) untuk mengirim transaksi melalui Gulf Stream dari node RPC ke pemimpin saat ini. Meskipun cepat dan efisien, UDP tidak memiliki koneksi, kurangnya kontrol aliran dan penerimaan pengakuan. Oleh karena itu, tidak ada cara yang berarti untuk mencegah atau mengurangi perilaku abusive. Untuk mengendalikan lalu lintas jaringan, protokol penerimaan transaksi validator (yaitu Tahap Pengambilan TPU) diimplementasikan kembali dengan QUIC.

QUIC berupaya menawarkan yang terbaik dari TCP dan UDP. Ini memfasilitasi komunikasi cepat, asinkron seperti UDP tetapi dengan sesi yang aman dan strategi kontrol aliran lanjutan dari TCP. Ini memungkinkan batasan ditempatkan pada sumber lalu lintas individu sehingga jaringan dapat fokus pada pemrosesan transaksi yang sah. QUIC juga memiliki konsep aliran terpisah, sehingga jika satu transaksi terjatuh, itu tidak menghalangi yang lain. QUIC akhirnya diintegrasikan ke klien Solana Labs dengan rilis 1.13.4.

Stake-Weighted Quality of Service (SWQoS): Sebuah sistem baru yang memprioritaskan lalu lintas jaringan berdasarkan jumlah saham yang dimiliki oleh validator diperkenalkan, memastikan bahwa mereka yang memiliki saham lebih tinggi dapat mengirimkan transaksi lebih efisien. Dalam mekanisme ini, seorang validator dengan 3% dari total saham dapat mengirimkan hingga 3% dari total paket ke pemimpin. SWQoS bertindak sebagai langkah resistensi Sybil, membuat lebih sulit bagi pelaku jahat untuk membanjiri jaringan dengan transaksi berkualitas rendah. Pendekatan ini menggantikan model pertama datang, pertama dilayani sebelumnya, yang menerima transaksi secara sembarangan tanpa mempertimbangkan sumbernya.

Pengenalan Biaya Prioritas: Setelah transaksi diserap, mereka masih bersaing untuk mengakses data akun bersama. Sebelumnya, perselisihan ini diselesaikan berdasarkan siapa cepat dia dapat, tidak memberikan cara kepada pengguna untuk memberi sinyal urgensi transaksi mereka. Karena siapa pun dapat mengirimkan transaksi, pembobotan taruhan tidak cocok untuk diprioritaskan pada tahap ini. Untuk mengatasi hal ini, instruksi baru ditambahkan ke program Anggaran Komputasi, memungkinkan pengguna untuk menentukan biaya tambahan yang dikumpulkan saat eksekusi dan penyertaan blok. Rasio fee-to-compute-unit menentukan prioritas eksekusi transaksi, memastikan pendekatan yang lebih dinamis dan berbasis pasar untuk pemesanan transaksi.

Mesin Permen Bot Pajak

Metaplex dengan cepat memperkenalkan pajak bot yang terkode keras sebesar 0.01 SOL pada transaksi mintberinteraksi dengan program Candy Machine untuk melawan spam yang didorong oleh bot. Mekanisme anti-spam ini memberlakukan biaya minimal untuk mencegah aktivitas berbahaya tanpa menghukum pengguna sah yang melakukan kesalahan secara tidak sengaja. Pajak dikenakan dalam skenario tertentu, termasuk:

• Mencoba membuat ketika Mesin Permen tidak aktif
• Mencoba membuat ketika tidak ada item yang tersisa
• Transaksi di mana mint atau atur koleksi bukan instruksi terakhir
• Penggunaan ID koleksi yang salah
• Petunjuk Koleksi Set yang Tidak Cocok
• Kesalahan penanda-pembayar antara set koleksi dan instruksi mint
• Transaksi mencurigakan yang melibatkan program-program yang dilarang
• Mencoba membuat dari Mesin Permen yang dilindungi oleh AllowList tanpa memiliki token allowlist yang diperlukan

Pencegah ekonomi ini terbukti sangat efektif. Penembak jitu mint dengan cepat terkuras, dan aktivitas spam berhenti. Dalam beberapa hari pertama, botters secara kolektif kehilangan lebih dari 426 SOL.

Bug Durable Nonce: Juni 2022

Waktu tidak aktif: Empat setengah jam

Masalah akar: Bug nonce tahan lama yang menyebabkan kegagalan konsensus

Perbaikan:

• Penonaktifan sementara transaksi nonce tahan lama
• Pembaruan Solana 1.10.23

Bug runtime memungkinkan transaksi nonce tahan lama tertentu diproses dua kali—sekali sebagai transaksi reguler dan sekali lagi sebagai transaksi nonce—jika mereka menggunakan blockhash terbaru alih-alih nonce tahan lama di bidang recent_blockhash. Hal ini menyebabkan perilaku non-deterministik di antara validator, karena beberapa node menolak eksekusi kedua sementara yang lain menerimanya. Secara kritis, karena lebih dari sepertiga validator menerima blok, hal ini mencegah mayoritas dua pertiga yang diperlukan mencapai konsensus.

Tidak seperti transaksi standar, transaksi nonce yang tahan lama tidak kedaluwarsa dan memerlukan mekanisme unik untuk mencegah eksekusi ganda. Mereka diproses secara serial menggunakan nilai nonce on-chain yang terikat pada setiap akun, yang diputar setiap kali transaksi nonce yang tahan lama diproses. Setelah diputar, transaksi nonce yang sama seharusnya tidak berlaku lagi.

Untuk mengatasi masalah itu, transaksi nonce tahan lama sementara dinonaktifkan.Sebuah perbaikan kemudian diimplementasikan di Solana 1.10.23, yang mencegah eksekusi ganda dengan memisahkan domain nonce dan blockhash. Pembaruan memastikan bahwa saat memajukan akun nonce, blockhash di-hash dengan string tetap, membuat blockhash tidak valid sebagai nilai nonce. Akibatnya, transaksi yang dieksekusi sekali sebagai transaksi reguler tidak dapat dieksekusi ulang sebagai transaksi tahan lama, dan sebaliknya. Selain itu, tipe DurableNonce baru menggantikan nilai blockhash sebelumnya dalam status akun nonce, menambahkan keamanan tipe dan mencegah masalah serupa di masa depan.

Baca artikel blog Helius sebelumnya kami untuk memahami lebih lanjut tentang nonce tahan lama dan penggunaannya.

Bug Blok Ganda: September 2022

Waktu tidak beroperasi: Delapan setengah jam

Masalah akar: Bug dalam aturan pemilihan fork menyebabkan kegagalan konsensus

Perbaiki:

• Pembaruan klien

Outage ini dipicu oleh validator yang secara keliru memproduksi blok ganda pada ketinggian blok yang sama. Hal ini terjadi karena node utama validator dan node cadangan yang tidak digunakan secara bersamaan aktif, menggunakan identitas node yang sama tetapi mengusulkan blok yang berbeda. Kondisi ini bertahan setidaknya selama 24 jam sebelum terjadi outage, selama periode tersebut jaringan dengan benar menangani slot pemimpin ganda dari validator.

Klaster akhirnya berhenti ketika jaringan mengalami fork yang tidak dapat dipulihkan karena bug dalam logika pemilihan fork. Bug ini mencegah produsen blok membangun pada blok sebelumnya, menyebabkan kegagalan dalam konsensus.

Fork adalah kejadian rutin di Solana, dan validator biasanya menyelesaikannya dengan menyelaraskan pada fork dengan mayoritas suara (fork terberat). Ketika seorang validator memilih fork yang salah, ia harus beralih ke fork terberat untuk tetap selaras dengan jaringan. Namun, dalam kasus ini, validator tidak bisa kembali ke bank terberat jika slotnya cocok dengan slot terakhir yang mereka pilih. Kekurangan ini menyebabkan validator tetap terjebak, mencegah konsensus berlanjut, dan akhirnya menyebabkan jaringan terhenti.

Bug blok duplikat, pemilihan fork terganggu, September 2022(Sumber: Laine, Michael Hubbard)

Pada contoh di atas, validator C yang bermasalah menghasilkan blok ganda untuk slot pemimpinnya dari 5 hingga 8. Ketika validator G mengambil alih sebagai pemimpin selanjutnya, ia hanya melihat salah satu dari duplikat tersebut dan memperpanjang cabangnya sesuai. Namun, pemimpin berikutnya, validator D, mendeteksi kedua blok ganda dari validator C dan memutuskan untuk membuangnya, alih-alih membangun cabangnya di atas slot 4.

Seiring berjalannya jaringan, fork yang dibangun oleh validator G mendapatkan suara mayoritas taruhan, memperkuat posisinya sebagai rantai kanonikal. Menyadari bahwa forknya kalah, validator D mencoba beralih ke fork validator G. Namun, transisi tersebut gagal karena adanya bug dalam logika pemilihan fork. Masalah ini muncul karena nenek moyang umum dari kedua fork - blok duplikat di slot 5 - tidak ditangani dengan benar, sehingga mencegah validator D untuk mengenali mayoritas fork. Akibatnya, validator D tetap terjebak di forknya sendiri, tidak mampu bergabung kembali ke rantai utama.

Masalah tersebut terselesaikan setelah ditinjau oleh tim inti.Sebuah patch telah digabungkan ke dalam cabang master dan di-port kembali ke semua cabang rilis.

Blok Besar Melumpuhkan Turbin: Februari 2023

Waktu tidak aktif: Hampir 19 jam

Masalah inti: Kegagalan logika deduplikasi dalam layanan pengiriman shred

Perbaikan:

• Beberapa perbaikan pada logika deduplikasi dan penyaringan Turbin
• Menambahkan patch klien yang memaksa produsen blok untuk membatalkan jika mereka menghasilkan blok besar

Layanan penerusan shred kustom validator mengalami gangguan, mentransmisikan blok yang sangat besar (hampir 150.000 shred), beberapa kali lipat lebih besar dari blok standar, selama slot pemimpinnya. Hal ini membuat filter deduplikasi validator terlulup, menyebabkan data terus menerus diteruskan kembali. Masalah ini bertambah parah saat blok baru diproduksi, akhirnya menyaturasi protokol.

Outage blok besar, serpihan per blok, Februari 2023(Sumber: Laine, Michael Hubbard)

Lonjakan lalu lintas jaringan yang tidak normal melanda Turbine, memaksa data blok ditransmisikan melalui protokol Perbaikan Blok cadangan yang jauh lebih lambat. Meskipun Turbine dirancang untuk menahan blok-blok besar dengan menyaringnya, layanan pengiriman shred berfungsi di hulu logika penyaringan ini, yang mengurangi efektivitasnya. Selama periode yang terdegradasi, pemimpin blok secara otomatis beralih ke mode hanya suara, sebuah mekanisme keamanan di mana pemimpin mengecualikan transaksi ekonomi non-suara.

Akar penyebab masalah adalah kegagalan dalam logika deduplikasi dalam layanan pengiriman shred, mencegah pengiriman ulang yang redundan dari shreds. Selain itu, filter deduplikasi dalam pipeline pengiriman ulang tidak dirancang secara asli untuk mencegah perulangan dalam pohon Turbin, memperburuk masalah tersebut.

Jaringan secara manual dihidupkan kembali dengan penurunan ke versi perangkat lunak validator terakhir yang stabil diketahui. Untuk mengurangi masalah ini, Solana v1.13.7 dan v1.14.17 memperkenalkan peningkatan pada logika deduplikasi, meningkatkan kemampuannya untuk mencegah jenuh filter dan memastikan kinerja jaringan yang lebih kuat.

Loop Rekompilasi Tanpa Batas: Februari 2024

Waktu henti: Hampir lima jam

Masalah inti: Bug menyebabkan loop recompile tak terbatas di cache JIT

Perbaikan:

• Nonaktifkan pemuat lama v1.17.20

Agave validator just-in-time (JIT) mengkompilasi semua program sebelum melakukan transaksi yang mereferensikannya. Untuk mengoptimalkan kinerja, output JIT dari program yang sering digunakan di-cache, mengurangi kompilasi ulang yang tidak perlu. Sebagai bagian dari Agave v1.16, mekanisme caching yang ada, LoadedPrograms, diganti dengan implementasi baru yang disebut ExecutorsCache, yang memperkenalkan beberapa efisiensi.

LoadedPrograms menyediakan tampilan global fork-aware dari program cache, mengurangi duplikasi data akuntansi dan memungkinkan thread eksekusi transaksi untuk memuat program baru secara kooperatif, mencegah konflik kompilasi. Fitur utama dari sistem ini adalah melacak slot di mana program menjadi aktif (dikenal sebagai tinggi slot efektif) untuk mendeteksi invalidasi cache ketika data program on-chain diperbarui.

Tinggi slot efektif sebagian besar program berasal dari slot penyebaran mereka, yang disimpan di akun on-chain mereka. Namun, program yang disebarkan menggunakan loader lama tidak mempertahankan slot penyebaran ini di akun mereka. LoadedPrograms menugaskan program-program ini ketinggian slot efektif nol sebagai solusi.

Pengecualian terjadi ketika instruksi penyebaran terdeteksi, menandakan bahwa bytecode program telah diganti. Dalam hal ini, LoadedPrograms sementara memasukkan entri dengan tinggi slot efektif yang benar. Namun, karena transaksi tidak pernah mereferensikan entri ini, itu sangat rentan terhadap penggusuran. Ketika diusir, output JIT dibuang, dan program ditandai sebagai dibongkar, tetapi ketinggian slot efektif dipertahankan.

Jika transaksi kemudian mereferensikan program yang dibongkar ini, LoadedPrograms mengkompilasi ulang dan memasukkan kembali entri pada ketinggian slot efektifnya. Biasanya, ini akan membuat program tersedia untuk dieksekusi pada iterasi berikutnya. Namun, untuk program loader lama, output JIT baru diberi tinggi slot sentinel nol, menempatkannya di belakang entri yang dibongkar sebelumnya. Akibatnya, LoadedPrograms tidak pernah mengenali program sebagai dimuat, memicu loop kompilasi ulang berkelanjutan pada setiap iterasi.

Di Agave v1.16, LoadedPrograms tidak mendukung pemuatan kooperatif, memungkinkan transaksi pemicu dikemas ke dalam blok. Blok ini kemudian disebarkan di seluruh jaringan, menyebabkan setiap validator memutar ulang dan memasukkan loop kompilasi ulang tak terbatas yang sama. Karena lebih dari 95% saham cluster menjalankan Agave v1.17 selama pemadaman, sebagian besar validator menjadi terhenti di blok ini, menghentikan jaringan.

Bug ini diidentifikasi minggu sebelumnya selama penyelidikan pemadaman cluster Devnet, dan patch dijadwalkan untuk penyebaran. @jeff.washington/2024-02-06-solana-mainnet-beta-outage-report-619bd75b3ce0">Mitigasi yang dipilih adalah backport perubahan ke Agave v1.17 dan segera menghapus gerbang fitur setelah jaringan dimulai ulang. Ini menonaktifkan loader lama yang bertanggung jawab untuk memicu bug, mencegah kejadian lebih lanjut.

Pembaruan Kerentanan Terkoordinasi: Agustus 2024

Waktu Henti: Tidak ada

Masalah akar: Asumsi penyejajaran alamat ELF yang salah

Perbaikan:

• Pembaruan patch

Pada tanggal 5 Agustus, Insinyur inti Anza diberitahu tentang kerentanan pada klien Agave, yang dilaporkan oleh peneliti eksternal. Seorang penyerang bisa mengeksploitasi kelemahan ini untuk crash validator pemimpin, yang mengarah ke penghentian seluruh jaringan. Sebagai tanggapan, insinyur Anza dengan cepat mengembangkan tambalan, yang kemudian diaudit oleh beberapa perusahaan keamanan pihak ketiga.

Program Solana dikompilasi menggunakan LLVM ke dalam Format yang Dapat Dieksekusi dan Dapat Ditautkan (ELF). Kerentanan berasal dari asumsi penyelarasan alamat yang salah dalam file ELF yang dihasilkan ini. Meskipun sanitasi ELF biasanya memberlakukan berbagai pemeriksaan integritas, sanitasi tidak memvalidasi penyelarasan bagian .text. Pengawasan ini dapat memungkinkan file ELF perusak yang berbahaya untuk menentukan bagian .text yang tidak sejajar, yang mengarahkan mesin virtual untuk melompat ke alamat yang tidak valid. Ini akan mengakibatkan kesalahan segmentasi host, menabrak validator.

Penyerang dapat mengeksploitasi kerentanan ini dengan:

• Membuat program Solana berbahaya yang menggunakan opcode CALL_REG.
• Memanipulasi file ELF untuk salah menyelaraskan bagian .text.
• Menyebarkan dan memanggil program di jaringan, memicu crash validator.

Proses Pembaruan Patch

Setiap pembaruan patch yang dirilis secara publik akan segera membuat kerentanan jelas bagi semua. Ini dapat memungkinkan penyerang cukup waktu untuk merekayasa balik kerentanan dan menghentikan jaringan sebelum jumlah saham yang cukup ditingkatkan. Massa kritis validator perlu mengadopsi rilis patch secepat mungkin untuk menghindari skenario seperti itu.

Pada tanggal 7 Agustus, beberapa anggota dari Solana Foundation telah menghubungi validator melalui pesan pribadi di berbagai platform komunikasi, memberi tahu mereka tentang patch kritis yang akan datang dan membagikan pesan hash yang mengonfirmasi tanggal dan pengidentifikasi unik insiden tersebut. Beberapa anggota terkemuka Anza, Jito, dan Solana Foundation membagikan hash ini di X, GitHub, dan LinkedIn untuk memverifikasi keakuratan pesan. Contoh hash yang dibagikan:

Selama hari berikutnya, anggota inti terus menghubungi validator, menggarisbawahi pentingnya urgensi dan kerahasiaan. Pada waktu yang telah ditentukan, 8 Agustus, 2 PM UTC, operator validator menerima pesan lebih lanjut yang berisi instruksi untuk mengunduh, memverifikasi, dan menerapkan patch. Patch di-host di repositori Github dari insinyur Anza yang dikenal, bukan repositori Agave utama. Instruksi termasuk verifikasi file patch yang diunduh terhadap shasum yang disediakan.

Pada pukul 8 malam UTC pada tanggal 8 Agustus, sebagian besar saham telah ditambal, memastikan keamanan jaringan. Setelah ini, kerentanan dan patch yang sesuai diungkapkan kepada publik, disertai dengan panggilan untuk semua validator yang tersisa untuk meningkatkan.

Distribusi patch yang tenang dan koordinasi validator di belakang layar menimbulkan kekhawatiran tentang desentralisasi Solana. Tak lama setelah insiden itu, direktur eksekutif Solana Foundation, Dan Albert, menanggapi kritik ini dalam sebuah wawancara media.

"Saya pikir penting untuk tidak membingungkan sentralisasi dengan kemampuan untuk berkoordinasi. Ada 1.500 node penghasil blok di seluruh dunia yang dioperasikan oleh hampir sama banyak individu.... Kemampuan untuk berkomunikasi dengan mereka, atau beberapa dari mereka, secara sukarela, tidak harus bingung dengan sentralisasi. "

Pekan Blockchain Korea (KBW) 2024

Saya pikir penting untuk tidak membingungkan sentralisasi dengan kemampuan untuk berkoordinasi. Ada 1.500 node penghasil blok di seluruh dunia yang dioperasikan oleh hampir sama banyak individu.... Kemampuan untuk berkomunikasi dengan mereka, atau beberapa dari mereka, secara sukarela, tidak harus bingung dengan sentralisasi.

Kesimpulan

Pada tulisan ini, Solana telah melewati lebih dari setahun tanpa pemadaman, memenuhi tonggak penting untuk menghapus tag "beta" dari mainnet-beta. Frekuensi pemadaman tampaknya menurun seiring dengan matangnya jaringan, dan pengenalan Firedancer diharapkan dapat meningkatkan keragaman klien, mengurangi risiko bug yang belum ditemukan atau kasus tepi yang menyebabkan shutdown penuh di seluruh cluster. Namun, beberapa tokoh masyarakat, termasuk pendiri Helius Mert Mumtaz, telah memperkirakan bahwa pemadaman akan terus berlanjut. Waktu akan menjawabnya.

Banyak terima kasih kepada Zantetsu (Sistem Shinobi) dan OxIchigo atas meninjau versi-versi sebelumnya dari karya ini.

Disclaimer:

1. Artikel ini dicetak ulang dari [Helius]. Semua hak cipta milik penulis asli [Lostin]. Jika ada keberatan terhadap cetak ulang ini, harap hubungi Belajar Gatetim, dan mereka akan menanganinya dengan segera.
2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.
3. Tim gate Learn menerjemahkan artikel ke dalam bahasa lain. Menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang kecuali disebutkan.