Sekarang, skalabilitas.
Terdapat dua kategori: jangka pendek dan jangka panjang.
Skalabilitas jangka pendek telah saya bahas di tempat lain. Secara garis besar:
Daftar akses tingkat blok (akan hadir di Glamsterdam) memungkinkan verifikasi blok secara paralel.
ePBS (akan hadir di Glamsterdam) memiliki berbagai fitur, salah satunya memungkinkan penggunaan sebagian besar setiap slot (bukan hanya beberapa ratus milidetik) untuk memverifikasi blok secara aman.
Penyesuaian harga gas memastikan biaya gas operasi sesuai dengan waktu eksekusi sebenarnya (serta biaya lain yang ditimbulkan). Kami juga mulai menjajaki gas multidimensi, yang memastikan pembatasan sumber daya berbeda. Kedua hal ini memungkinkan penggunaan porsi slot yang lebih besar untuk verifikasi blok tanpa risiko kasus luar biasa.
Terdapat roadmap bertahap untuk gas multidimensi.
Pertama, di Glamsterdam, kami memisahkan biaya “pembuatan state” dari biaya “eksekusi dan calldata”. Saat ini, SSTORE yang mengubah slot dari nonzero -> nonzero dikenakan biaya 5.000 gas, SSTORE yang mengubah zero -> nonzero dikenakan biaya 20.000. Salah satu penyesuaian harga di Glamsterdam secara signifikan meningkatkan biaya ekstra tersebut (misal menjadi 60.000); tujuan kami melakukan ini dan menaikkan batas gas adalah agar kapasitas eksekusi meningkat jauh lebih besar daripada kapasitas ukuran state, dengan alasan yang telah saya tulis sebelumnya (
g-state-by-creating-new-forms-of-state/24052
). Jadi di Glamsterdam, SSTORE tersebut akan mengenakan 5.000 gas “reguler” dan (misal) 55.000 gas “pembuatan state”.
Gas pembuatan state TIDAK dihitung dalam batas gas transaksi ~16 juta, sehingga pembuatan kontrak besar (lebih besar dari saat ini) akan dimungkinkan.
Salah satu tantangan: bagaimana hal ini bekerja di EVM? Opcode EVM (GAS, CALL…) semuanya mengasumsikan satu dimensi. Berikut pendekatan kami. Kami mempertahankan dua invarians:
Jika Anda melakukan panggilan dengan X gas, panggilan tersebut memiliki X gas yang dapat digunakan untuk “reguler” ATAU “pembuatan state” ATAU dimensi lain di masa depan
Jika Anda memanggil opcode GAS, ia memberi tahu Anda memiliki Y gas, kemudian Anda melakukan panggilan dengan X gas, Anda masih memiliki setidaknya Y-X gas, dapat digunakan untuk fungsi apa pun, setelah panggilan untuk melakukan operasi lanjutan
Kami membuat N+1 “dimensi” gas, di mana secara default N=1 (pembuatan state), dan dimensi tambahan disebut “reservoir”. Eksekusi EVM secara default mengonsumsi dimensi “spesialisasi” jika memungkinkan, jika tidak maka mengonsumsi dari reservoir. Misal, jika Anda memiliki (100.000 gas pembuatan state, 100.000 reservoir), lalu menggunakan SSTORE untuk membuat state baru tiga kali, sisa gas Anda menjadi (100.000, 100.000) -> (45.000, 95.000) -> (0, 80.000) -> (0, 20.000). GAS mengembalikan reservoir. CALL meneruskan jumlah gas yang ditentukan dari reservoir, ditambah semua gas non-reservoir.
Selanjutnya, kami beralih ke penetapan harga multi-dimensi, di mana dimensi berbeda dapat memiliki harga gas mengambang yang berbeda. Ini memberikan keberlanjutan ekonomi jangka panjang dan optimalitas (lihat
vitalik.eth.limo/general/2024/0
). Mekanisme reservoir menyelesaikan masalah sub-call di akhir artikel tersebut.
Sekarang, untuk skalabilitas jangka panjang, terdapat dua bagian: ZK-EVM dan blobs.
Untuk blobs, rencananya adalah terus mengembangkan PeerDAS, hingga mencapai kondisi akhir di mana idealnya dapat menangani ~8 MB/detik data. Cukup untuk kebutuhan Ethereum, tanpa berusaha menjadi lapisan data global. Saat ini, blobs digunakan untuk L2. Di masa depan, rencananya data blok Ethereum langsung masuk ke blobs. Ini diperlukan agar seseorang dapat memvalidasi rantai Ethereum hyperscale tanpa harus mengunduh dan mengeksekusi ulang secara pribadi: ZK-SNARKs menghilangkan kebutuhan eksekusi ulang, dan PeerDAS pada blobs memungkinkan verifikasi ketersediaan tanpa harus mengunduh sendiri.
Untuk ZK-EVM, tujuannya adalah meningkatkan “kenyamanan” dalam mengandalkannya secara bertahap:
Klien yang memungkinkan Anda berpartisipasi sebagai attester dengan ZK-EVM akan tersedia pada tahun 2026. Mereka belum cukup aman untuk menjalankan jaringan sepenuhnya, tetapi misal 5% jaringan bergantung padanya masih dapat diterima. (Jika ZK-EVM gagal, Anda tidak akan terkena slashing, hanya berisiko membangun pada blok tidak valid dan kehilangan pendapatan)
Pada tahun 2027, kami mulai merekomendasikan agar sebagian minoritas jaringan menjalankan ZK-EVM, dan pada saat yang sama fokus penuh pada verifikasi formal serta memaksimalkan keamanannya. Bahkan 20% jaringan menjalankan ZK-EVM memungkinkan peningkatan gaslimit secara signifikan, karena memungkinkan gaslimit meningkat pesat dengan jalur murah bagi solo staker, yang jumlahnya di bawah 20%.
Jika sudah siap, kami beralih ke pembuktian wajib 3-dari-5. Agar blok valid, harus memuat 3 dari 5 jenis proof dari sistem proof berbeda. Pada titik ini, kami memperkirakan semua node (kecuali node yang perlu melakukan indexing) akan bergantung pada proof ZK-EVM.
Terus tingkatkan ZK-EVM, dan jadikan sekuat, terverifikasi secara formal, dan sebagainya. Ini juga mulai melibatkan upaya perubahan VM (misal RISC-V)





