Catatan Editor: Seiring dengan terus berkembangnya ekosistem Ethereum, bagaimana cara meningkatkan skalabilitas jaringan tanpa mengorbankan keamanan dan desentralisasi telah menjadi isu inti. Dalam artikel ini, Vitalik Buterin lebih lanjut merangkum jalur skalabilitas Ethereum: dalam jangka pendek melalui optimasi mekanisme Gas, paralelisasi verifikasi blok, dan peningkatan efisiensi eksekusi teknis lainnya; dalam jangka panjang bergantung pada arsitektur data ZK-EVM dan blobs untuk mendorong peningkatan kapasitas jaringan.
Secara keseluruhan, peta jalan ini menyediakan serangkaian solusi skalabilitas yang dilaksanakan secara bertahap, bertujuan untuk memberikan fondasi bagi Ethereum untuk terus memperluas kapasitas jaringannya dalam beberapa tahun ke depan.
Berikut adalah teks aslinya:
Sekarang mari kita bicara tentang skalabilitas (scaling). Ini terutama terbagi menjadi dua bagian: skalabilitas jangka pendek dan skalabilitas jangka panjang.
Skalabilitas Jangka Pendek
Tentang skalabilitas jangka pendek, saya telah menulis di tempat lain. Inti pemikirannya kira-kira sebagai berikut:
· Daftar akses tingkat blok (block-level access lists) (yang akan dirilis dalam upgrade Glamsterdam) memungkinkan verifikasi blok dilakukan secara paralel.
· ePBS (juga akan dirilis dalam Glamsterdam) memiliki beberapa fitur, salah satunya adalah: ini memungkinkan kita untuk menggunakan porsi waktu yang lebih besar dalam setiap slot untuk memverifikasi blok dengan aman, alih-alih hanya menggunakan beberapa ratus milidetik seperti sekarang.
· Penetapan ulang harga Gas (gas repricing) akan memastikan biaya gas untuk berbagai operasi sesuai dengan waktu eksekusi aktualnya (serta biaya lain yang mereka timbulkan). Kami juga sedang mengeksplorasi mekanisme gas multidimensi (multidimensional gas) secara awal, yang memungkinkan sumber daya yang berbeda untuk memiliki batas atas yang terpisah. Kombinasi keduanya memungkinkan kita menggunakan porsi slot time yang lebih besar saat memverifikasi blok, tanpa khawatir dengan skenario terburuk.
Mengenai gas multidimensi, kami telah membuat peta jalan bertahap. Tahap pertama adalah dalam upgrade Glamsterdam, memisahkan 'biaya pembuatan status' dari 'biaya eksekusi dan calldata'.
Misalnya, saat ini: operasi SSTORE, jika mengubah slot penyimpanan dari bukan nol → bukan nol, biayanya 5000 gas; jika dari nol → bukan nol, biayanya 20000 gas.
Dalam satu kali penetapan ulang harga gas di Glamsterdam, biaya tambahan ini akan dinaikkan secara signifikan (misalnya menjadi 60000). Tujuannya adalah, sambil meningkatkan batas atas gas, agar kemampuan eksekusi dapat diskalakan jauh lebih cepat daripada skalabilitas ukuran status.
Alasannya, saya telah menulis sebelumnya: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
Jadi, di Glamsterdam: operasi SSTORE ini akan mengonsumsi 5000 'gas biasa', dan 55000 'gas pembuatan status', misalnya.
Perlu diperhatikan: gas pembuatan status tidak akan diperhitungkan dalam batas atas gas transaksi sekitar 16 juta.
Ini berarti: akan menjadi mungkin untuk membuat kontrak yang lebih besar dari sekarang.
Bagaimana Gas Multidimensi Diimplementasikan dalam EVM?
Di sini muncul pertanyaan: Desain EVM defaultnya mengasumsikan gas hanya memiliki satu dimensi, misalnya opcode GAS, CALL, dll. semuanya berdasarkan asumsi ini.
Metode solusi kami adalah menjaga dua invarian:
Jika Anda memulai panggilan (call) dengan X gas, maka panggilan tersebut akan memiliki X gas, yang dapat digunakan untuk 'operasi biasa', atau 'pembuatan status', atau dimensi lain yang mungkin ditambahkan di masa depan.
Jika opcode GAS memberi tahu Anda bahwa saat ini ada Y gas, lalu Anda memulai panggilan yang mengonsumsi X gas, maka setelah panggilan kembali, Anda masih memiliki setidaknya Y − X gas, yang dapat digunakan untuk operasi selanjutnya.
Cara implementasinya adalah: Kami memperkenalkan N+1 dimensi gas. Secara default N = 1 (pembuatan status), dimensi tambahan disebut reservoir (cadangan).
Logika eksekusi EVM adalah:
Jika memungkinkan, konsumsi gas dari dimensi khusus terlebih dahulu.
Jika tidak cukup, konsumsi dari reservoir.
Misalnya, jika Anda memiliki: (100000 gas pembuatan status, 100000 reservoir)
Jika Anda menggunakan SSTORE untuk membuat status baru tiga kali, proses perubahan gas adalah: (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000)
Dalam desain ini:
Opcode GAS mengembalikan nilai reservoir.
CALL akan meneruskan jumlah gas yang ditentukan dari reservoir, dan secara bersamaan meneruskan semua gas non-reservoir.
Penetapan Harga Gas Multidimensi
Setelah itu, kami akan lebih lanjut memperkenalkan penetapan harga multidimensi (multi-dimensional pricing), yang memungkinkan dimensi sumber daya yang berbeda memiliki harga gas mengambang yang berbeda.
Ini akan membawa:
Keberlanjutan ekonomi jangka panjang yang lebih baik.
Efisiensi konfigurasi sumber daya yang lebih optimal.
Detail lebih lanjut: https://vitalik.eth.limo/general/2024/05/09/multidim.html
Dan mekanisme reservoir justru memecahkan masalah panggilan turunan (sub-call) yang disebutkan di akhir artikel itu.
Skalabilitas Jangka Panjang
Skalabilitas jangka panjang terutama mencakup dua arah: ZK-EVM dan Blobs.
Blobs
Untuk blobs, kami berencana untuk terus mengiterasi PeerDAS, dan pada akhirnya berharap mencapai kapasitas throughput data sekitar 8 MB/detik.
Skala ini:
Cukup untuk memenuhi kebutuhan Ethereum sendiri.
Tidak dimaksudkan untuk menjadi 'lapisan data global'.
Saat ini, blobs terutama digunakan untuk L2. Rencana masa depan adalah agar data blok Ethereum itu sendiri langsung ditulis ke dalam blobs.
Tujuan melakukan ini adalah memungkinkan orang memverifikasi jaringan Ethereum yang sangat tereskalasi tanpa harus mengunduh dan mengeksekusi ulang seluruh rantai:
ZK-SNARKs menghilangkan kebutuhan untuk mengeksekusi ulang.
PeerDAS + blobs memungkinkan verifikasi ketersediaan data tanpa mengunduh semua data.
ZK-EVM
Untuk ZK-EVM, tujuan kami adalah secara bertahap meningkatkan ketergantungan jaringan padanya.
2026: Akan muncul klien yang mendukung ZK-EVM, memungkinkan node untuk berpartisipasi dalam attestation menggunakan ZK-EVM. Namun, mereka belum cukup aman untuk membuat seluruh jaringan bergantung padanya. Namun, jika sekitar 5% jaringan menggunakannya, itu dapat diterima. (Jika ZK-EVM bermasalah, Anda tidak akan di-slash, tetapi mungkin membangun di blok yang tidak valid, sehingga kehilangan pendapatan.)
2027: Kami akan mulai menyarankan lebih banyak node untuk menjalankan ZK-EVM, sambil fokus pada verifikasi formal dan peningkatan keamanan. Bahkan jika hanya 20% jaringan yang menggunakan ZK-EVM, itu dapat memungkinkan kami secara signifikan meningkatkan batas gas, karena ini memberikan jalur verifikasi biaya rendah untuk solo staker, dan proporsi solo staker sendiri juga kurang dari 20%.
Setelah teknologi matang: Kami akan memperkenalkan mekanisme bukti wajib 3-of-5. Artinya, sebuah blok harus memuat setidaknya 3 bukti dari 5 sistem bukti yang berbeda untuk dianggap valid. Pada saat itu, kami memperkirakan bahwa kecuali node yang perlu melakukan pengindeksan, sebagian besar node akan bergantung pada bukti ZK-EVM.
Jangka Panjang: Terus menyempurnakan ZK-EVM, membuatnya lebih tangguh, dan melakukan verifikasi formal yang lebih ketat. Tahap ini juga mungkin melibatkan perubahan pada tingkat mesin virtual, seperti ke arah RISC-V.
Detail lebih lanjut: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052







