XRPL Mendesak Pengendali Nod untuk Menaiktaraf ke xrpld 3.2.1 Selepas Banjir Manifest Penyahsah

Judul: XRPL mendesak peningkatan nod segera selepas "banjir manifest" menekan sumber rangkaian Pengarah Kejuruteraan Ripple, Vijay Khanna, pada 2 Ogos mendesak operator nod XRP Ledger untuk memasang xrpld v3.2.1 segera selepas pembangun mengesan "banjir validator manifest" pada 31 Julai. Pembaikan pantas ini membatasi cara nod memproses, menyimpan, dan berkongsi data manifest daripada identiti validator yang tidak dikenali — mencegah penyerang daripada menghabiskan memori, penyimpanan, bandwidth, dan CPU nod — serta mengekalkan operasi buku besar biasa semasa pemasangan pemaafan. Apa yang berlaku - Pada 31 Julai, pembangun mengamati lonjakan manifest validator yang datang daripada identiti yang tidak dikenali. Walaupun buku besar terus ditutup secara normal, peristiwa ini memberi tekanan kepada sumber nod dan komunikasi peer-to-peer. - Tiada bukti awam mengenai dana yang dicuri, transaksi yang diubah, atau kegagalan konsensus. Pembangun tidak mengeluarkan CVE ataupun mengedarkan anggaran kerugian kewangan yang berkaitan dengan insiden ini. - XRPL Operations mengatakan akan mengeluarkan laporan teknikal pasca-kejadian; pada 2 Ogos, asal-usul banjir, jumlah keseluruhan, dan kesan sumber tepat masih tidak diumumkan. Mengapa manifest validator penting - Manifest validator adalah rekod yang ditandatangani secara kriptografi yang mengikat identiti utama stabil validator kepada kunci sementara yang digunakan untuk mesej pengesahan harian. Apabila operator menukar kunci sementara, mereka menerbitkan manifest baharu yang ditandatangani oleh kunci utama supaya rakan-rakan boleh mengesahkan perubahan tersebut. - Sebelum pembaikan pantas, xrpld boleh menerima, menyimpan cache, dan menghantar semula manifest yang disusun dengan betul untuk kunci validator yang tidak dikenali. Penyerang boleh memanfaatkan tingkah laku itu dengan mencipta banyak identiti yang tidak dikenali dan memaksa rakan-rakan untuk membuang memori, penyimpanan, bandwidth, dan kuasa pemprosesan untuk menangani data tersebut. Repositori kod menggambarkan masalah ini sebagai penyalahgunaan penyebaran manifest. Apa yang terkandung dalam xrpld 3.2.1 - Rilis rasmi xrpld 3.2.1 (bertarikh 31 Julai; ditandatangani dan diterbitkan awal 1 Ogos) mengandungi enam komitmen merentas 13 fail. Empat komitmen secara langsung membatasi pemprosesan manifest tidak dipercayai. Perlindungan utama: - Penolakan awal manifest terlalu besar sebelum nod sepenuhnya menghuraikannya, mengurangkan kerja CPU setiap objek jahat. - Batasan bilangan manifest tidak dipercayai yang dibenarkan dalam satu mesej rangkaian — dikenakan semasa menerima dan semasa menyediakan mesej untuk rakan-rakan. Batch terlalu besar dibuang tanpa memutuskan sambungan rakan yang belum dikemaskini, memudahkan kepadanan pelaksanaan. - Batasan per nod terhadap identiti validator asing yang disimpan dalam memori, dibataskan pada 100. Apabila penuh, manifest tidak disenaraikan baharu ditolak sementara validator yang dipercayai dan diingati terus diproses. - Perubahan cara maklumat manifest tidak dipercayai disimpan dan disebarkan, menargetkan penyebaran rakan tidak disenaraikan bukan manifest daripada validator yang disusun/dipercayai. Ini mengekalkan penukaran kunci validator sah sambil menghalang pertumbuhan cache tanpa sempadan. Panduan operator dan nota pelaksanaan - Khanna menasihatkan validator dan operator infrastruktur untuk meningkatkan ke v3.2.1 "secepat mungkin". Proses yang disarankan: lakukan pembaruan perisian biasa, tunggu satu hingga dua minit untuk mengesahkan xrpld berjalan, kemudian mulakan semula perkhidmatan sekali lagi. Permulaan semula kedua membantu membersihkan sebarang manifest tidak dipercayai yang masih disimpan dalam memori sebelum pembaikan. - Operator juga harus mengesahkan sistem mereka mempercayai kunci penandatanganan paket GPG Ripple semasa. Ripple menukar kunci itu pada 18 Februari; nod yang belum mempercayai kunci baharu mungkin tidak menerima pembaruan automatik. - Kemas kini ini adalah untuk operator infrastruktur (bursa, pihak penyimpanan, latar belakang dompet, penyedia data, dan perniagaan yang menjalankan pelayan XRPL). Pemegang XRP biasa tidak perlu memindahkan dana, menukar kunci, atau mengambil tindakan apa-apa. Konteks dan langkah seterusnya - Pembaikan pantas ini mengikuti pelancaran lebih luas xrpld v3.2.0 (15 Jun), yang menukar nama pelayan rujukan daripada rippled kepada xrpld dan memerlukan operator untuk mengemas kini konfigurasi. Pengambilan v3.2.0 lebih pantas di kalangan validator berbanding rangkaian nod yang lebih luas; banjir manifest memberi alasan kuat tambahan kepada operator yang tinggal untuk beralih ke 3.2.1. - XRPL Operations telah menjanjikan laporan teknikal pasca-kejadian yang akan menerangkan bila aktiviti itu pertama kali diwartakan, sama ada sebarang nod menjadi tidak tersedia, jumlah manifest, dan seberapa pantas operator melaksanakan pemaafan. Sehingga laporan itu diterbitkan, butiran yang disahkan masih terhad kepada pembaikan 3.2.1 dan permintaan agar operator meningkatkan dan memulakan semula. Intisari Jika anda menjalankan infrastruktur XRPL, anggap ini sebagai keperluan mendesak: tingkatkan ke xrpld 3.2.1 dan ikuti cadangan permulaan semula dua langkah untuk membersihkan sebarang manifest tidak dipercayai yang masih tersimpan. Untuk komuniti XRPL secara keseluruhan, insiden ini kelihatan sebagai cubaan penghabisan sumber bukan kompromi protokol — tetapi laporan pasca-kejadian akan penting untuk mengesahkan lingkungan penuh.