Jinjin Finance Blockchain, 10 Juni Bug dalam kode penyortir Arbitrum minggu ini menyebabkan gangguan singkat pada kemampuan jaringan untuk mengirimkan transaksi dalam batch, dan transaksi tidak dapat dikonfirmasi pada rantai utama. Kerentanan telah diperbaiki, dan fungsi pengiriman kumpulan transaksi telah dipulihkan. Pada 10 Juni, Arbitrum Foundation merilis laporan analisis setelah fakta tentang bug penyortir Arbitrum Selanjutnya, mari kita tinjau dan lihat mengapa kejadian bug ini tidak menyebabkan dana pengguna hilang.
** Timeline Peristiwa Bug Penyortir Arbitrum **
Pada 06:04:53 tanggal 7 Juni 2023, penerbit batch gagal memperbarui tampilan status L1 karena masalah sementara dengan simpul L1 collator Arbitrum. Karena masalah akar penyebab, penyortir Arbitrum terus mencoba menanyakan status nomor blok tampilan L1 sebelumnya. Ini berarti bahwa bahkan setelah masalah node L1 sementara menyelesaikan sendiri, penerbit batch akan terus mencoba untuk menanyakan status nomor blok L1 yang lama, dan node L1 tidak lagi memiliki statusnya karena bukan merupakan node arsip.
Pada 09:38:28 tanggal 7 Juni 2023, poster kumpulan Arbitrum menghentikan publikasi transaksi karena telah mencapai batas transaksi antrian maksimum yang dikonfigurasi (256), yang sama dengan batas mempool. Jika batas ini tidak tercapai, posting massal akan dilanjutkan seperti biasa.
Pada pukul 11:09 tanggal 7 Juni 2023, karena batch yang tidak dipublikasikan, peringatan dipicu pada kontrak pintar Sequencer Inbox untuk memeriksa batch baru, dan peringatan dikirim ke saluran Slack.
Pada pukul 11:10, kurangnya rilis batch baru-baru ini memicu peringatan berbasis log dan mengirimkan peringatan level kritis ke saluran Slack.
Pada pukul 11:13, seorang anggota tim komunitas memprakarsai PagerDuty dengan seorang anggota tim SRE, yang segera mengetahui kejadian tersebut dan mulai menanggapi.
Pada pukul 11:19:02 pagi, tim SRE memulai kembali poster batch, namun karena batas maksimum antrean transaksi yang disebutkan sebelumnya, poster batch tidak dapat dipublikasikan. Tim SRE menyadari masalah ini dan mulai beralih ke penyedia RPC L1 pihak ketiga dalam upaya untuk memitigasi masalah tersebut.
Pada 11:24:16, 5 menit setelah poster batch dimulai, itu memperbarui tampilan status L1 dan menerbitkan transaksi batch pertama.
Pada pukul 11:25:09, konfigurasi poster batch diubah untuk menggunakan penyedia RPC L1 pihak ketiga dan dimulai ulang karena tim SRE sudah mulai membuat perubahan ini dan tidak melihat pengelompokan. Setelah restart, transaksi batch terus terjadi.
Pada pukul 11:30:21 pagi, 5 menit setelah poster batch dimulai, tampilan status L1 diperbarui, yang memicu status L1 tidak sinkron, yang juga merupakan akar penyebab masalah. Status L1 diperbarui ke nomor blok terakhir 17428199, tetapi menggunakan nonce terbaru 178078, sesuai dengan blok terbaru pada saat itu, alih-alih blok terakhir yang disimpan dalam statusnya, yang mengakibatkan semua transaksi antrean di Redis dihapus Kecuali, karena Redis menganggap transaksi ini telah dikonfirmasi.
Pukul 11:30:26, poster batch memposting batch baru. Redis bergantung pada tampilan status L1 untuk menentukan apa yang akan dipublikasikan, tetapi saat ini antrean Redis kosong, seperti yang dinyatakan sebelumnya, status L1 salah, dan kumpulan diterbitkan dengan nomor acak dalam status 178078, tetapi untuk Menentukan batch yang akan diterbitkan, menggunakan nomor blok yang tidak relevan 17428199, menghasilkan batch lama dengan nomor seri 229209 yang diterbitkan, yang sebenarnya diterbitkan pada 11:24:16 sebelumnya, dan kemudian poster batch dimulai kembali. Karena batch lama 229209 telah diterbitkan, transaksi L1 yang diajukan oleh batch tersebut dibatalkan.
Pada pukul 11:36:35, alamat poster batch kehabisan Ether karena tidak mengembalikan biaya gas, sehingga berhenti terbit. Ini adalah mekanisme yang disengaja untuk mencegah poster batch mengonsumsi semua gas yang disimpan di biaya batch pemulihan.
Pada pukul 11:46, anggota tim Nitro menerima telepon untuk menyelesaikan masalah perangkat lunak dengan pemulihan batch.
Sekitar pukul 11:58, Arbitrum mulai menerima laporan bahwa beberapa pengguna menemukan bahwa ada masalah dengan penyortir (menyiarkan transaksi yang baru disortir ke node RPC), karena semakin banyak transaksi yang dipesan karena masalah poster batch daripada memposting ke rantai, masalah ini terutama memengaruhi klien umpan dengan koneksi internet yang buruk atau alokasi memori yang tidak mencukupi, karena mereka lebih cenderung untuk berhenti dan mengalami masalah koneksi ulang. Arbitrum merekomendasikan agar pengguna yang menjalankan beberapa node RPC menjalankan relai umpan lokal untuk mengurangi bandwidth eksternal yang diperlukan.
Pada pukul 12:03, Arbitrum menghapus pembatasan laju umpan Cloudflare untuk mengatasi masalah klien yang mencapai batas laju saat mencoba menyambung kembali setelah terputus karena koneksi internet.
Pada pukul 12:05, Arbitrum menghapus semua pembatasan kecepatan Cloudflare untuk memungkinkan peningkatan pemanfaatan RPC publik bagi mereka yang node-nya mengalami kesulitan mempertahankan koneksi ke feed.
Pada pukul 12:12:09, poster batch yang salah ditutup dan toko antrean Redis dibersihkan untuk menghapus status buruk.
Pukul 12:12:40, poster batch dimulai pada versi lama v2.0.14, dan tidak ada masalah root.
Pada pukul 12:21:56, gelombang pertama poster gelombang yang baru dibuka berhasil, dan terus berjalan sejak saat itu.
Pelajaran peristiwa bug penyortir Arbitrum dipelajari
Pemadaman disebabkan oleh bug di poster batch. Sequencer itu sendiri tidak terpengaruh atau terganggu dan terus memproses transaksi selama proses. Laporan bahwa sequencer kehabisan dana tidak benar. Mekanisme pendanaan Arbitrum terdiri dari dua dompet, yaitu: dompet "sequencer" dan dompet "pengembalian dana gas". Hanya ketika sequencer berhasil melepaskan batch, maka akan dikembalikan. Jaringan Arbitrum belum mengembalikan dana ke sequencer untuk ini kegagalan dana, dan masalah terkait tidak disebabkan oleh sequencer kehabisan dana, jadi tidak ada dana pengguna yang berisiko.
Arbitrum akan membersihkan opsi konfigurasi yang telah ditambahkan dalam solusi sementara. Nantinya, Arbitrum berencana untuk mengevaluasi ulang klien sequencer dan masalah timeout server untuk meningkatkan keandalan jaringan jika terjadi backlog transaksi. Sebuah "v2.1.0- beta baru .2" versi beta. Selain itu, Arbitrum akan membuat halaman status jaringan publik untuk mengurangi kebingungan jika ada masalah dengan layanan tersebut.
Artikel ini direferensikan dari situs resmi Arbitrum Foundation
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Pengamatan Emas | Tinjauan acara bug penyortir Arbitrum
Pengarang: Golden Finance Jason
Jinjin Finance Blockchain, 10 Juni Bug dalam kode penyortir Arbitrum minggu ini menyebabkan gangguan singkat pada kemampuan jaringan untuk mengirimkan transaksi dalam batch, dan transaksi tidak dapat dikonfirmasi pada rantai utama. Kerentanan telah diperbaiki, dan fungsi pengiriman kumpulan transaksi telah dipulihkan. Pada 10 Juni, Arbitrum Foundation merilis laporan analisis setelah fakta tentang bug penyortir Arbitrum Selanjutnya, mari kita tinjau dan lihat mengapa kejadian bug ini tidak menyebabkan dana pengguna hilang.
** Timeline Peristiwa Bug Penyortir Arbitrum **
Pada 06:04:53 tanggal 7 Juni 2023, penerbit batch gagal memperbarui tampilan status L1 karena masalah sementara dengan simpul L1 collator Arbitrum. Karena masalah akar penyebab, penyortir Arbitrum terus mencoba menanyakan status nomor blok tampilan L1 sebelumnya. Ini berarti bahwa bahkan setelah masalah node L1 sementara menyelesaikan sendiri, penerbit batch akan terus mencoba untuk menanyakan status nomor blok L1 yang lama, dan node L1 tidak lagi memiliki statusnya karena bukan merupakan node arsip.
Pada 09:38:28 tanggal 7 Juni 2023, poster kumpulan Arbitrum menghentikan publikasi transaksi karena telah mencapai batas transaksi antrian maksimum yang dikonfigurasi (256), yang sama dengan batas mempool. Jika batas ini tidak tercapai, posting massal akan dilanjutkan seperti biasa.
Pada pukul 11:09 tanggal 7 Juni 2023, karena batch yang tidak dipublikasikan, peringatan dipicu pada kontrak pintar Sequencer Inbox untuk memeriksa batch baru, dan peringatan dikirim ke saluran Slack.
Pada pukul 11:10, kurangnya rilis batch baru-baru ini memicu peringatan berbasis log dan mengirimkan peringatan level kritis ke saluran Slack.
Pada pukul 11:13, seorang anggota tim komunitas memprakarsai PagerDuty dengan seorang anggota tim SRE, yang segera mengetahui kejadian tersebut dan mulai menanggapi.
Pada pukul 11:19:02 pagi, tim SRE memulai kembali poster batch, namun karena batas maksimum antrean transaksi yang disebutkan sebelumnya, poster batch tidak dapat dipublikasikan. Tim SRE menyadari masalah ini dan mulai beralih ke penyedia RPC L1 pihak ketiga dalam upaya untuk memitigasi masalah tersebut.
Pada 11:24:16, 5 menit setelah poster batch dimulai, itu memperbarui tampilan status L1 dan menerbitkan transaksi batch pertama.
Pada pukul 11:25:09, konfigurasi poster batch diubah untuk menggunakan penyedia RPC L1 pihak ketiga dan dimulai ulang karena tim SRE sudah mulai membuat perubahan ini dan tidak melihat pengelompokan. Setelah restart, transaksi batch terus terjadi.
Pada pukul 11:30:21 pagi, 5 menit setelah poster batch dimulai, tampilan status L1 diperbarui, yang memicu status L1 tidak sinkron, yang juga merupakan akar penyebab masalah. Status L1 diperbarui ke nomor blok terakhir 17428199, tetapi menggunakan nonce terbaru 178078, sesuai dengan blok terbaru pada saat itu, alih-alih blok terakhir yang disimpan dalam statusnya, yang mengakibatkan semua transaksi antrean di Redis dihapus Kecuali, karena Redis menganggap transaksi ini telah dikonfirmasi.
Pukul 11:30:26, poster batch memposting batch baru. Redis bergantung pada tampilan status L1 untuk menentukan apa yang akan dipublikasikan, tetapi saat ini antrean Redis kosong, seperti yang dinyatakan sebelumnya, status L1 salah, dan kumpulan diterbitkan dengan nomor acak dalam status 178078, tetapi untuk Menentukan batch yang akan diterbitkan, menggunakan nomor blok yang tidak relevan 17428199, menghasilkan batch lama dengan nomor seri 229209 yang diterbitkan, yang sebenarnya diterbitkan pada 11:24:16 sebelumnya, dan kemudian poster batch dimulai kembali. Karena batch lama 229209 telah diterbitkan, transaksi L1 yang diajukan oleh batch tersebut dibatalkan.
Pada pukul 11:36:35, alamat poster batch kehabisan Ether karena tidak mengembalikan biaya gas, sehingga berhenti terbit. Ini adalah mekanisme yang disengaja untuk mencegah poster batch mengonsumsi semua gas yang disimpan di biaya batch pemulihan.
Pada pukul 11:46, anggota tim Nitro menerima telepon untuk menyelesaikan masalah perangkat lunak dengan pemulihan batch.
Sekitar pukul 11:58, Arbitrum mulai menerima laporan bahwa beberapa pengguna menemukan bahwa ada masalah dengan penyortir (menyiarkan transaksi yang baru disortir ke node RPC), karena semakin banyak transaksi yang dipesan karena masalah poster batch daripada memposting ke rantai, masalah ini terutama memengaruhi klien umpan dengan koneksi internet yang buruk atau alokasi memori yang tidak mencukupi, karena mereka lebih cenderung untuk berhenti dan mengalami masalah koneksi ulang. Arbitrum merekomendasikan agar pengguna yang menjalankan beberapa node RPC menjalankan relai umpan lokal untuk mengurangi bandwidth eksternal yang diperlukan.
Pada pukul 12:03, Arbitrum menghapus pembatasan laju umpan Cloudflare untuk mengatasi masalah klien yang mencapai batas laju saat mencoba menyambung kembali setelah terputus karena koneksi internet.
Pada pukul 12:05, Arbitrum menghapus semua pembatasan kecepatan Cloudflare untuk memungkinkan peningkatan pemanfaatan RPC publik bagi mereka yang node-nya mengalami kesulitan mempertahankan koneksi ke feed.
Pada pukul 12:12:09, poster batch yang salah ditutup dan toko antrean Redis dibersihkan untuk menghapus status buruk.
Pukul 12:12:40, poster batch dimulai pada versi lama v2.0.14, dan tidak ada masalah root.
Pada pukul 12:21:56, gelombang pertama poster gelombang yang baru dibuka berhasil, dan terus berjalan sejak saat itu.
Pelajaran peristiwa bug penyortir Arbitrum dipelajari
Pemadaman disebabkan oleh bug di poster batch. Sequencer itu sendiri tidak terpengaruh atau terganggu dan terus memproses transaksi selama proses. Laporan bahwa sequencer kehabisan dana tidak benar. Mekanisme pendanaan Arbitrum terdiri dari dua dompet, yaitu: dompet "sequencer" dan dompet "pengembalian dana gas". Hanya ketika sequencer berhasil melepaskan batch, maka akan dikembalikan. Jaringan Arbitrum belum mengembalikan dana ke sequencer untuk ini kegagalan dana, dan masalah terkait tidak disebabkan oleh sequencer kehabisan dana, jadi tidak ada dana pengguna yang berisiko.
Arbitrum akan membersihkan opsi konfigurasi yang telah ditambahkan dalam solusi sementara. Nantinya, Arbitrum berencana untuk mengevaluasi ulang klien sequencer dan masalah timeout server untuk meningkatkan keandalan jaringan jika terjadi backlog transaksi. Sebuah "v2.1.0- beta baru .2" versi beta. Selain itu, Arbitrum akan membuat halaman status jaringan publik untuk mengurangi kebingungan jika ada masalah dengan layanan tersebut.
Artikel ini direferensikan dari situs resmi Arbitrum Foundation