BAL (EIP-7928) kerap disebut sebagai “prasyarat eksekusi paralel” dalam diskusi Glamsterdam. Istilah ini tidak berarti seluruh transaksi langsung berjalan paralel; melainkan, hubungan akses state yang sebelumnya implisit kini menjadi batasan eksplisit yang dapat diverifikasi. Hanya jika batasan ini jelas, penjadwalan stabil dapat terwujud.
Lapisan batasan ini terhubung langsung dengan tujuan upgrade yang dijelaskan dalam Gambaran Umum Peningkatan Glamsterdam dan melengkapi mekanisme ePBS (EIP-7732): ePBS menetapkan batas kolaborasi produksi blok, sedangkan BAL mendefinisikan batas eksekusi. Dampak Glamsterdam pada DApp menunjukkan bagaimana perubahan di lapisan constraint memengaruhi ekspektasi performa aplikasi dan ritme rilis.
Apa Itu BAL (EIP-7928)?
BAL adalah Block-Level Access Lists, yaitu pencatatan akun dan slot penyimpanan yang diakses saat eksekusi blok, serta dapat mencakup hasil state pasca-eksekusi. Tujuan BAL bukan menggantikan execution engine, melainkan memberi deteksi konflik lebih awal dan input persiapan data yang lebih jelas.
Eksekusi serial tradisional memang konsisten, namun cepat mencapai limit efisiensi saat beban tinggi. Untuk eksekusi paralel, pertanyaan utama adalah: “Transaksi mana yang saling bertentangan?” Nilai BAL terletak pada pemindahan deteksi konflik dari waktu eksekusi ke fase pra-eksekusi yang dapat direncanakan. Berdasarkan roadmap Ethereum.org dan EIP-7928, BAL merupakan proposal utama untuk upgrade Glamsterdam.
Mengapa Ethereum Membutuhkan Block-Level Access Lists?
Ketika blok semakin kompleks, jika hubungan baca/tulis state hanya diketahui secara dinamis saat runtime, klien sulit merencanakan jalur eksekusi sejak awal. Walau perangkat keras memadai, efisiensi tetap dapat terganggu oleh konflik rollback dan penjadwalan berulang.
Block-level access lists mengurangi risiko “konflik baru ditemukan saat eksekusi.” Dengan constraint yang jelas di awal, klien dapat menyiapkan data, membagi tugas, dan mengisolasi konflik sehingga fluktuasi performa acak dapat ditekan. Untuk layanan indeksasi dan node arsip yang melakukan pembacaan state masif, pengetahuan awal tentang pola akses juga mengoptimalkan perencanaan I/O.
| Tahap Eksekusi |
Tanpa Pra-Batasan |
Dengan Batasan BAL |
| Waktu Deteksi Konflik |
Rollback saat eksekusi |
Prediksi sebelum eksekusi |
| Persiapan Data |
Muat data langsung |
Pengelompokan pra-eksekusi |
| Strategi Penjadwalan |
Berdasarkan pengalaman |
Berdasarkan aturan |
Tabel ini menunjukkan bahwa BAL mengubah “ketersediaan informasi” alih-alih hanya throughput akhir.
Bagaimana BAL Membantu Klien Identifikasi Konflik dan Optimalkan Penjadwalan?
Klien menggunakan access list untuk dua hal utama: membagi transaksi ke “set paralel” dan mempertahankan “jalur serial wajib.” Meski paralelisme penuh belum tercapai, segmen berkonflik rendah dapat dioptimalkan lebih dulu, sehingga cakupan paralelisme bertambah secara bertahap.
Dari sudut rekayasa, BAL bukan pemberi lonjakan performa instan, melainkan meningkatkan prediktabilitas eksekusi. Bagi tim operasi node, prediktabilitas lebih bernilai daripada puncak sesaat, karena berdampak pada SLA dan respons insiden. Perubahan tingkat konflik dan rollback di testnet adalah metrik utama menilai efektivitas BAL.
| Tahap Penjadwalan |
Tanpa Pra-Batasan |
Dengan Batasan BAL |
| Persiapan Pra-eksekusi |
Berdasarkan estimasi |
Pengelompokan via access list |
| Penanganan Konflik |
Rollback runtime sering |
Isolasi konflik lebih awal |
| Stabilitas Hasil |
Sangat fluktuatif |
Lebih prediktabel |
| Monitoring Operasi |
Sulit tentukan ambang |
Metrik terstruktur tersedia |
Gambar 1. Ilustrasi mekanisme BAL: bagaimana block-level access lists mendukung deteksi konflik dan penjadwalan eksekusi paralel.
Apa Hubungan BAL dengan Eksekusi Paralel?
BAL bukan “pengganti” eksekusi paralel, melainkan “lapisan prasyarat”-nya. Untuk eksekusi paralel juga butuh implementasi klien, strategi penjadwalan, dan manajemen state yang saling terintegrasi. Tanpa constraint dasar, paralelisme paksa justru menambah ketidakpastian.
Singkatnya, BAL mengubah eksekusi paralel dari konsep teoritis menjadi target rekayasa. BAL menjawab “apakah prasyarat sudah ada?”—bukan “apakah performa puncak sudah tercapai?” Bahkan jika strategi paralel agresif diterapkan, constraint akses BAL tetap vital untuk manajemen konflik.
Apa Implikasi BAL bagi Developer dan Tim Aplikasi?
Developer perlu lebih cermat pada pola akses state. Desain dengan penulisan frekuensi tinggi ke state yang sama, dependensi lintas kontrak kompleks, atau batch transaksi terikat bisa menimbulkan perilaku eksekusi baru di bawah constraint ini. Aplikasi wajib diuji jalur eksekusinya sebelum rilis, bukan sekadar uji fungsi.
Tim produk juga harus menyesuaikan komunikasi performa. Peningkatan pengalaman pengguna pasca-upgrade bisa jadi tidak linier, terutama saat ekosistem masih beradaptasi. Pendekatan prudent: gunakan metrik bertahap—konfirmasi stabilitas, tingkat kegagalan, dan persentil latensi, bukan sekadar rata-rata. Reset metrik dan rilis bertahap harus sinkron dengan kerangka adaptasi aplikasi.
Apa Batasan Implementasi dan Tantangan BAL?
Tantangan pertama: konsistensi lintas klien. Berbagai klien eksekusi bisa menafsirkan access list dan strategi penjadwalan berbeda, sehingga perlu konvergensi berkelanjutan lewat testnet dan regresi lintas klien, dengan snapshot metrik bertanggal.
Tantangan kedua: biaya pembelajaran ekosistem. Jika tim pengembang abai pada struktur akses state, deviasi performa bisa terjadi pasca-upgrade; kontrak lama mungkin tidak ramah akses, sehingga butuh alat dan waktu migrasi.
Tantangan ketiga: pembaruan sistem monitoring. Tim operasi perlu metrik baru terkait constraint akses untuk mengidentifikasi sumber masalah—apakah dari persiapan data, konflik penjadwalan, atau bottleneck engine eksekusi. Tanpa monitoring baru, potensi mekanisme tidak optimal. Untuk Checklist Persiapan Upgrade Node, log BAL dan tingkat rollback konflik wajib masuk kriteria penerimaan. Dalam Perbandingan Glamsterdam vs. Dencun/Fusaka, tantangan ini adalah risiko unik perubahan struktural dan tidak dapat diatasi hanya dengan pengalaman upgrade kapasitas.
Ringkasan
BAL (EIP-7928) mengatur urutan eksekusi dengan membuat hubungan akses state eksplisit, menstrukturkan deteksi konflik, dan memindahkan penjadwalan dari responsif menjadi perencanaan terverifikasi. Walau tidak sepenuhnya menentukan keberhasilan upgrade, BAL krusial untuk eksekusi paralel stabil dan menjadi mekanisme constraint inti di lapisan eksekusi Glamsterdam.
FAQ
Apakah BAL (EIP-7928) Itu Eksekusi Paralel?
Bukan. BAL adalah constraint layer prasyarat eksekusi paralel, menjadi fondasi deteksi konflik. Eksekusi paralel juga bergantung pada implementasi klien dan strategi penjadwalan.
Mengapa BAL Mempengaruhi Performa Aktual?
Karena hubungan akses state sudah eksplisit di awal, klien bisa menyiapkan data dan mengelompokkan tugas lebih awal, mengurangi rollback konflik saat runtime dan meningkatkan stabilitas eksekusi.
Apa Pembagian Tanggung Jawab antara BAL dan ePBS (EIP-7732)?
ePBS fokus pada batas kolaborasi produksi blok, BAL fokus pada batas constraint eksekusi. Keduanya berada di layer berbeda dan saling melengkapi dalam Glamsterdam.
Apa yang Harus Dilakukan Tim DApp terhadap Penerapan BAL?
Tinjau pola akses state dan jalur transaksi frekuensi tinggi, lakukan pengujian perilaku eksekusi sebelum dan sesudah upgrade, serta perbarui monitoring performa dan ambang peringatan agar tidak bergantung pada asumsi eksekusi lama.
Apakah BAL Menjamin Semua Transaksi Bisa Paralel?
Tidak. BAL hanya memberi deteksi konflik dan input penjadwalan; transaksi dengan konflik tinggi tetap harus serial. Cakupan paralelisme tergantung pola akses, implementasi klien, dan karakteristik beban jaringan.
