Penulis: KarenZ, Foresight News
Pada dini hari waktu Beijing tanggal 26 Juni, Base memberikan pelajaran infrastruktur yang cukup tenang kepada pasar.
Timeline gangguan ini cukup jelas:
- Pukul 00.03 dini hari, Base melaporkan status pembuatan blok mainnet abnormal, tim sedang menyelidiki.
- Pukul 00.52, Base memastikan masalah terletak pada sebuah blok yang bermasalah, yang akan mengganggu pembuatan blok selanjutnya.
- Pukul 01.21, Base telah menemukan masalah konsensus yang menyebabkan blok tidak valid diurutkan. Hal ini mencegah pembuatan blok baru setelah blok 47806542. Sequencer dan node internal telah pulih secara awal.
- Pukul 01.51, pengurutan blok baru telah pulih, sinkronisasi node internal normal.
- Pukul 01.58, Base mengonfirmasi pembuatan blok yang sehat telah pulih, infrastruktur ekosistem dapat melanjutkan sinkronisasi.
- Pukul 03.22, Base menambahkan bahwa sequencer dan sistem terkait tetap stabil, blok telah dihasilkan secara normal, dan menyebut tim telah menemukan akar penyebab penghentian ini, sedang memvalidasi rencana perbaikan, dan akan merilis laporan analisis lengkap di kemudian hari.
Halaman status Base menunjukkan bahwa insiden ini memengaruhi deposit, penarikan, pembuatan blok, dan perangkat lunak klien di mainnet Base.
Sequencer Aktif Tunggal, Membuat Penghentian Terasa Lebih Menyakitkan
Base adalah Rollup yang dibangun di atas Ethereum. Ia mengeksekusi banyak transaksi di L2, lalu mengirimkan data yang diperlukan dan informasi status terkait ke Ethereum.
Yang dirasakan langsung oleh pengguna setiap hari bukanlah diagram arsitektur, tetapi apakah transaksi bisa masuk ke blok, apakah node bisa sinkron, dan apakah dompet, pertukaran, serta layanan cross-chain dapat berfungsi normal.
Sebelum Flashblocks diluncurkan, Base menggunakan sistem sequencer dengan ketersediaan tinggi: dari 5 instance sequencer, satu instance bertindak sebagai leader, bertanggung jawab membangun blok dan menyebarkannya melalui P2P, sementara 4 lainnya sebagai follower yang menyinkronkan status chain; jika leader saat ini berhenti memproduksi blok, sistem akan melakukan pergantian kepemimpinan.
Desain ini menunjukkan bahwa Base sebenarnya memiliki redundansi. Masalahnya, redundansi lebih banyak menyelesaikan failover dan ketersediaan, tidak setara dengan beberapa sequencer independen yang berpartisipasi secara bersamaan dalam pembuatan blok. Produksi blok harian tetap ditanggung oleh leader saat ini. Begitu ada masalah pada konsensus, pengurutan, atau jalur sinkronisasi node, yang pertama dirasakan pengguna adalah berhentinya kemajuan blok baru.
Setelah Flashblocks diluncurkan, pembangunan blok Base mendapat tambahan mekanisme pra-konfirmasi tingkat 200 milidetik. Dokumentasi Base menyatakan, Flashblocks selalu aktif di Base, semua blok dibangun oleh Flashblocks builder; aplikasi dapat memilih apakah akan menggunakan data pra-konfirmasi atau melanjutkan menunggu konfirmasi blok standar 2 detik melalui RPC standar. Dengan kata lain, Flashblocks sudah menjadi bagian dari infrastruktur pembangunan blok Base saat ini, tetapi merupakan pilihan opsional bagi aplikasi yang ingin mengakses pengalaman pra-konfirmasi.
Penjelasan di halaman status keamanan Base lebih spesifik: sebuah masalah konsensus menyebabkan blok tidak valid diurutkan, yang selanjutnya mencegah pembuatan blok baru setelah blok 47806542. Penyebab sebenarnya masih perlu menunggu analisis lengkap resmi.
Gangguan Base Sebelumnya Disebabkan Ketidakmampuan Mengonfigurasi Sequencer Baru
Ini bukan pertama kalinya Base menghentikan pembuatan blok karena masalah terkait sequencer. Pada 5 Agustus 2025, mainnet Base pernah mengalami gangguan jaringan selama 33 menit. Analisis resmi pasca-insiden menyebutkan, sequencer aktif ini mulai mengalami penundaan karena aktivitas on-chain, Conductor yang mengelola kluster ketersediaan tinggi (HA) secara otomatis mengalihkan kepemimpinan ke sequencer baru; namun sequencer baru saat itu masih dalam proses konfigurasi, tidak dapat memproduksi blok, dan karena Conductor belum sepenuhnya diaktifkan pada sequencer tersebut, sistem tidak dapat melanjutkan inisiasi pergantian berikutnya. Tim kemudian secara manual menjeda HA, dan mengalihkan kepemimpinan ke sequencer yang sehat, sebelum pulih sepenuhnya.
Melihat dua insiden ini bersama-sama, perlu kehati-hatian: masalah Agustus 2025 mengarah pada alur pergantian ketersediaan tinggi sequencer, sedangkan insiden gangguan hari ini adalah masalah konsensus yang menyebabkan blok tidak valid diurutkan, dan mencegah pembuatan blok baru setelah blok 47806542.
Keduanya bersama-sama menunjukkan satu realitas: L2 dapat mengandalkan Ethereum dalam masalah inti seperti ketersediaan data, penyelesaian, keamanan, dan finalitas, tetapi ketersediaan harian sangat bergantung pada sequencer dan sistem operasional terkait. Selama blok baru tidak dapat terus dihasilkan, yang dilihat pengguna adalah transaksi terhenti di jalan.
Gangguan Ini Terjadi di Sekitar Waktu Peluncuran B20
Waktu terjadinya insiden ini agak halus. Base saat itu sedang berada di sekitar jendela upgrade Beryl.
Waktu aktivasi mainnet Beryl semula ditetapkan pukul 02.00 dini hari waktu Beijing tanggal 26 Juni, saat ini telah ditunda hingga pukul 02.00 dini hari tanggal 27 Juni.
Inti dari Beryl mencakup tiga hal: memperkenalkan standar token native B20, memperpendek periode konfirmasi final penarikan single proof dari 7 hari menjadi 5 hari, serta melalui Reth V2 membawa pengurangan penggunaan disk hingga 50% dan peningkatan throughput sekitar 33%.
Perbedaan B20 terletak pada implementasi dasarnya. Berbeda dengan ERC-20 yang sebagian besar diterapkan dalam bentuk kontrak pintar EVM, B20 diimplementasikan oleh Rust precompile, dan dibuat melalui B20Factory tunggal. Ia juga memiliki kemampuan bawaan seperti peran izin, batas pasokan, mint/burn, jeda, strategi transfer, memo, dan ERC-2612 permit. Secara sederhana, Base telah membuat banyak fungsi dasar token yang berulang kali dibangun, diaudit, dan dipelihara oleh penerbit, menjadi kotak peralatan tingkat chain.
B20 paling mudah memicu asosiasi pasar, bahkan ada pengguna komunitas yang mengasosiasikannya dengan Base menerbitkan token. Namun, B20 membahas "bagaimana orang lain dapat menerbitkan aset secara lebih standar di Base"; sedangkan Base menerbitkan token membahas "apakah Base akan memperkenalkan token jaringan miliknya sendiri di masa depan".
Yang pertama sudah ditulis dalam upgrade Beryl, yang terakhir masih menjadi isu yang diperhatikan pasar tetapi belum diumumkan secara resmi.
Penghentian ini akan membuat diskusi penerbitan token Base menjadi lebih realistis. Pasar sebelumnya bertanya: apakah Base akan menerbitkan token, kapan, dan bagaimana pembagian airdrop. Setelah insiden, yang lebih layak ditanyakan adalah: jika di masa depan benar-benar memperkenalkan token jaringan, tanggung jawab apa yang harus diembannya? Apakah desentralisasi sequencer, batasan tata kelola, anggaran keamanan, atau distribusi hak dan tanggung jawab dalam respons insiden?
