"Transmisi Tanpa Tingkatan" dalam upgrade Ethereum Fusaka: Membangun mekanisme respons cepat untuk skalabilitas L2

Ethereum di masa depan akan seperti dipasangi "transmisi variabel tanpa tingkat", sehingga ekspansi Blob di masa mendatang tidak perlu lagi terikat erat dengan upgrade besar.

Penulis: Zhixiong Pan

Latar Belakang: Upgrade Gas Limit Tidak Perlu Hard Fork

Sebelum upgrade Fusaka, sebagian besar parameter inti di lapisan protokol Ethereum (seperti block reward, algoritma penyesuaian tingkat kesulitan, dll.) "ditanamkan" secara hardcoded di perangkat lunak klien. Ini berarti, bahkan hanya untuk mengubah satu nilai saja, harus melalui proses panjang proposal EIP, uji coba di testnet, dan koordinasi seluruh node jaringan untuk melakukan hard fork besar-besaran, yang biasanya memakan waktu setengah tahun atau bahkan lebih lama.

Sebelum ini, satu-satunya pengecualian di protokol Ethereum adalah Block Gas Limit (batas atas Gas per blok). Gas Limit tidak ditentukan oleh hard fork, tetapi validator diperbolehkan melakukan penyesuaian kecil melalui algoritma saat memproses blok (misalnya tahun ini dari 30M naik menjadi 60M). Mekanisme ini memberikan elastisitas tertentu pada jaringan.

Kemunculan EIP-7892, BPO (Blob Parameter Only), bertujuan memperluas elastisitas ini ke ranah data. Ia menjadikan parameter kunci Blob sebagai konfigurasi yang dapat diubah, dan melalui BPO, sebuah "hard fork ringan yang hanya mengubah parameter tanpa mengubah kode", perubahan dapat diterapkan. Dari sudut pandang pengembangan klien, ini hampir seperti melakukan hot update parameter.

Ini memungkinkan Ethereum untuk keluar dari pola "setiap kali ingin mengubah jumlah Blob harus menunggu hard fork besar berikutnya", dan dapat menyesuaikan parameter lebih sering melalui hard fork kecil BPO.

Mengapa Jumlah Blob Sangat Penting?

Objek inti dari penyesuaian kali ini adalah Blob. Sejak upgrade Cancun (Dencun), sebagian besar Rollup tidak lagi menulis sebagian besar data transaksi ke calldata yang mahal, melainkan bermigrasi ke Blob, sebuah "area mounting data sementara" khusus.

Logika ekonomi Blob sangat sederhana: Blob adalah sumber daya langka, jumlah Blob yang dapat dimounting per blok terbatas. Harganya berasal dari hubungan penawaran dan permintaan, ketika permintaan Layer 2 melebihi pasokan, harga per unit Blob akan naik, menyebabkan biaya transaksi L2 menjadi lebih mahal.

Oleh karena itu, selama keamanan tetap terjaga, meningkatkan batas atas jumlah Blob sebanyak mungkin adalah cara paling langsung untuk menurunkan biaya pengguna L2.

Parameter Inti: Mekanisme Target dan Max

Dalam rencana penyesuaian BPO, terdapat dua angka yang muncul berpasangan (misal 10/15). Ini adalah dua ambang kunci yang ditetapkan berdasarkan mekanisme EIP-4844:

Target (Nilai Target): "Regulator" Biaya

Ini adalah beban ideal yang ditetapkan oleh Ethereum. Sistem akan menyesuaikan biaya dasar (Base Fee) Blob secara dinamis berdasarkan nilai ini. Jika penggunaan aktual > Target, biaya naik untuk menekan permintaan; jika penggunaan aktual < Target, biaya turun.

Ini menentukan kapasitas throughput dan acuan tarif jaringan dalam kondisi normal.

Max (Nilai Maksimum): "Pemutus Sirkuit" Keamanan

Ini adalah batas keras fisik yang ditetapkan untuk mencegah jaringan lumpuh. Tidak peduli seberapa tinggi permintaan, protokol secara ketat membatasi jumlah Blob dalam satu blok tidak boleh melebihi nilai ini, untuk mencegah node mati atau terputus karena memproses data yang terlalu besar.

Ini adalah batas atas kemampuan jaringan.

Selain itu, sejak Pectra, parameter blob di mainnet pada dasarnya mengikuti pola "Max = 1.5 × Target": 6/9, 10/15, 14/21, semuanya mengikuti rasio ini.

Peta Jalan Upgrade: Mengapa Fusaka Memilih "Bertahap"?

Ekspansi kali ini tidak dilakukan sekaligus pada 3 Desember (UTC+8), melainkan menggunakan strategi tiga tahap yang ketat: "deploy teknologi dulu, baru lepaskan kapasitas".

Tahap Pertama: Upgrade Fusaka (3 Desember (UTC+8))

Status parameter: Target: 6 / Max: 9 (sama seperti versi Pectra sebelumnya, tidak ada perubahan).

Upgrade Fusaka mengaktifkan PeerDAS (sampling ketersediaan data) sebagai teknologi inti. Meskipun secara teknis sudah mampu menangani lebih banyak data, demi keamanan, pengembang memilih untuk tidak menambah beban jaringan pada hari pertama upgrade. Ini adalah "periode observasi keamanan", untuk memverifikasi stabilitas mekanisme PeerDAS di bawah lalu lintas saat ini.

Tahap Kedua: BPO 1 (diperkirakan 9 Desember (UTC+8))

Penyesuaian parameter: Target: 10 / Max: 15

Setelah PeerDAS berjalan stabil selama sekitar satu minggu, dilakukan hot update pertama melalui mekanisme BPO. Nilai target naik dari 6 menjadi 10. Ini adalah ekspansi substansial pertama dalam siklus Fusaka.

Tahap Ketiga: BPO 2 (diperkirakan 7 Januari 2026 (UTC+8))

Penyesuaian parameter: Target: 14 / Max: 21

Setelah satu bulan uji tekanan yang memadai, dilakukan hot update kedua. Dibandingkan saat Fusaka diluncurkan, kapasitas meningkat 2,3 kali lipat (6 → 14). Ini menandai realisasi penuh dari rencana ekspansi kali ini.

Ringkasan

Pengenalan BPO adalah sebuah tonggak sejarah. Ini mematahkan paradigma lama "setiap ekspansi Blob harus menunggu hard fork besar", dan memecah ekspansi menjadi serangkaian hard fork mini yang hanya mengubah parameter.

Ini berarti, Ethereum di masa depan akan seperti dipasangi "transmisi variabel tanpa tingkat", ekspansi Blob di masa mendatang tidak perlu lagi terikat erat dengan upgrade besar, dapat merencanakan BPO3, BPO4 sesuai kebutuhan L2 dan performa klien, dan melakukan penyesuaian throughput dengan hard fork kecil yang lebih sering, bukan hanya sekali dalam beberapa tahun.