Analisis Anomali Singkat Layer Konsensus Ethereum Selama Dua Malam Berturut-turut

Baru-baru ini, lapisan konsensus Ethereum mengalami gangguan singkat, yang menarik perhatian luas di industri. Artikel ini akan menganalisis kejadian tersebut secara mendalam.

Ringkasan Acara

Pada malam tanggal 11 dan 12 Mei, lapisan konsensus Ethereum mengalami gangguan singkat. Analisis menunjukkan bahwa ini terutama disebabkan oleh beberapa node klien lapisan konsensus Ethereum yang kelebihan beban, menyebabkan node validator (Validator) mengalami downtime. Hal ini langsung mempengaruhi pemungutan suara Epoch, sehingga tidak dapat mencapai ambang batas 2/3 yang diperlukan, mengakibatkan lapisan konsensus tidak dapat mengonfirmasi finalitas.

Perlu dicatat bahwa meskipun terjadi anomali, jaringan Ethereum dapat pulih dengan cepat dalam waktu singkat. Ini mencerminkan ketahanan dan kemampuan perbaikan diri dari algoritma konsensus PoS Ethereum.

Rincian Acara

Dalam keadaan normal, status jaringan konsensus PoS Ethereum biasanya akan dipastikan dalam 2 Epoch (Finalized). Namun, dalam dua kejadian minggu lalu, terdapat keterlambatan dalam penetapan Epoch:

• 11 Mei: Epoch telah ditentukan tertunda 3 Epoch, sekitar 20 menit.
• 12 Mei: Epoch ditunda selama 8 Epoch, sekitar 51 menit.

Meskipun Epoch tidak dapat diselesaikan tepat waktu, jaringan Ethereum tetap menghasilkan blok dan memproses transaksi. Namun, karena tingkat suara dari node validator yang tidak cukup, Epoch tidak dapat mendapatkan jaminan keamanan tingkat konsensus dari jaringan PoS Ethereum.

Perlu dicatat bahwa dalam peristiwa kedua, karena penundaan penetapan melebihi ambang batas yang ditetapkan, mekanisme Inactivity leak dari algoritma konsensus Ethereum telah diaktifkan. Ini mengakibatkan sekitar 28 ETH disita, dan sekitar 50 ETH tidak diterbitkan.

Analisis Penyebab

Penyebab langsung dari dua kejadian ini adalah beberapa jenis klien node lapisan konsensus Ethereum yang mengalami beban berlebihan, yang menyebabkan node validator mengalami downtime dan tidak dapat melakukan pemungutan suara konsensus dengan normal. Secara spesifik:

1. Ketika node menerima saksi yang mengarah ke blok usang (Attestation), perlu menghitung ulang status rantai beacon untuk memverifikasi saksi-saksi ini, proses ini membutuhkan banyak sumber daya CPU dan memori.

2. Ketika menerima banyak saksi yang mengarah ke blok usang sekaligus, sumber daya node habis, menyebabkan node validasi mengalami downtime dan offline.

3. Meskipun masalah semacam ini dapat diatasi melalui caching yang mengacu pada blok berdasarkan saksi, namun karena pertumbuhan jumlah node verifikasi dan munculnya banyak attestation semacam itu, caching pada implementasi klien yang bermasalah menjadi jebol.

Saat ini, klien lapisan konsensus Teku dan Prysm telah merilis versi patch untuk mengatasi masalah tersebut. Versi patch akan menyaring saksi yang sudah usang, dan ketika saksi mengarah ke Slot yang sudah usang atau node yang belum pernah melihat Checkpoint, saksi tersebut akan diabaikan.

Ethereum keunggulan desain

Dalam kejadian ini, Ethereum menunjukkan keunggulan desainnya:

1. Keragaman klien: Desain implementasi klien yang berbeda, bahkan jika beberapa klien mengalami masalah, tidak akan mempengaruhi operasi normal klien lainnya.

2. Desain algoritma Gasper: memisahkan produksi blok dari finalisasi, sehingga meskipun finalisasi blok terhambat, produksi blok tidak akan terhenti, menjamin ketersediaan jaringan.

Pengalaman dan Inspirasi

1. Keragaman klien masih perlu ditingkatkan: Saat ini, keragaman klien Ethereum masih memiliki ruang untuk perbaikan, terutama klien lapisan eksekusi yang terpusat di Geth, yang mencapai 61%, terdapat risiko potensial.

2. Mekanisme pergantian klien perlu disempurnakan: Ketika suatu implementasi klien mengalami masalah, bagaimana cara beralih dengan aman ke implementasi klien yang normal tetap menjadi tantangan.

3. Pemantauan konsensus perlu diperkuat: Diperlukan layanan seperti Safe Head untuk terus memantau keadaan real-time jaringan Ethereum PoS, dan segera mendeteksi serta memberi peringatan tentang anomali.

4. Meningkatkan pendidikan pengguna: Meningkatkan pemahaman tentang mekanisme konsensus PoS Ethereum, untuk menghindari kepanikan yang tidak perlu di antara pengguna.

5. Lapisan aplikasi perlu siap menghadapi: Layer2, bursa, Oracle, dan aplikasi lainnya perlu menangani dengan benar skenario ketidakstabilan jaringan, seperti memperpanjang waktu konfirmasi atau menghentikan layanan.

Ringkasan

Peristiwa ini menunjukkan ketahanan dan kemampuan pemulihan diri dari algoritma konsensus PoS Ethereum, sekaligus mengungkap beberapa aspek yang perlu ditingkatkan. Di masa depan, ekosistem Ethereum perlu terus berinvestasi dalam keragaman klien, pemantauan jaringan, pendidikan pengguna, dan sebagainya, untuk meningkatkan stabilitas dan keandalan seluruh jaringan.