Teruskan Judul Asli: Penjelasan Hardfork Prague/Electra (Pectra)

memperkenalkan

Dalam artikel sebelumnya, kami secara menyeluruh meninjau siklus hidup validator Ethereum, membahas beberapa aspek terkait hardfork Electra yang akan datang. Sekarang, saatnya untuk fokus pada perubahan yang akan datang dalam upgrade Electra dan Prague serta menjelaskannya secara detail.

Sejarah Ethereum 2.0 'proof-of-stake' hardforks sangat kompleks. Dimulai dengan penambahan lapisan beacon ke lapisan eksekusi yang ada, meluncurkan konsensus proof-of-stake pada lapisan beacon sambil tetap mempertahankan proof-of-work pada lapisan eksekusi (hardfork Phase0 dan Altair). PoS kemudian sepenuhnya diaktifkan pada hardfork Bellatrix (meskipun penarikan tidak diaktifkan). Selanjutnya, hardfork Capella memungkinkan penarikan, menyelesaikan siklus validator. Hardfork terbaru, Deneb (bagian dari peningkatan Dencun (Deneb/Cancun)), membawa revisi minor pada parameter rantai beacon, seperti jendela waktu untuk menyertakan pernyataan, penanganan keluar sukarela, dan batas perputaran validator. Perubahan utama dalam Dencun berada pada lapisan eksekusi, memperkenalkan inovasi seperti transaksi blob, blob gas, komitmen KZG untuk blob, dan menghapus operasi SELFDESTRUCT.

Sekarang, hardfork Prague/Electra memperkenalkan peningkatan signifikan pada kedua lapisan eksekusi dan konsensus. Sebagai pemeriksa untuk proyek Lido, fokus kami sebagian besar pada perubahan konsensus dan staking dalam hardfork ini. Namun, kami tidak dapat mengabaikan perubahan lapisan eksekusi di Prague, karena mereka mencakup fitur-fitur kritis yang mempengaruhi jaringan Ethereum dan validator. Mari kita telusuri detail perubahan ini.

Gambaran Umum Tingkat Lanjut tentang Pectra

Electra memperkenalkan banyak fitur untuk lapisan beacon. Pembaruan utama meliputi:

• Memungkinkan validator memiliki saldo efektif mulai dari 32 hingga 2048 ETH (daripada tetap 32 ETH).
• Memungkinkan validator untuk memulai keluar dengan kredensial "penarikan" sekunder (tidak lagi memerlukan kunci validator aktif).
• Mengubah bagaimana deposit Eth1 diproses oleh lapisan beacon (menjauh dari mengurai acara dari kontrak deposit).
• Menambahkan kerangka kerja umum baru untuk menangani permintaan dari kontrak Eth1 reguler di lapisan beacon (mirip dengan bagaimana deposito dikelola sebelum Electra).

Sementara itu, Praha memperkenalkan perubahan pada lapisan eksekusi, seperti:

• Kontrak pra-dikompilasi baru yang mendukung kurva BLS12-381 untuk memverifikasi bukti zkSNARK (selain kurva BN254 yang populer).
• Kontrak sistem baru untuk menyimpan dan mengakses hingga 8192 hash blok historis (berguna untuk klien tanpa status).
• Biaya gas panggilan data yang lebih tinggi untuk mengurangi ukuran blok dan mendorong proyek-proyek untuk memindahkan operasi yang membutuhkan panggilan data (seperti rollups) ke blob, yang diperkenalkan dalam Dencun.
• Dukungan untuk jumlah blob yang lebih besar per blok Eth1, bersama dengan API untuk membaca angka-angka ini.
• Mengizinkan EOAs (Akun Milik Eksternal) memiliki kode akun mereka sendiri, secara dramatis memperluas apa yang dapat dilakukan EOAs, seperti menjalankan multicalls atau menyerahkan eksekusi ke alamat lain.

Mari kita merujuk pada Proposal Peningkatan Ethereum (EIP) yang relevan untuk memfasilitasi diskusi lebih lanjut:

• EIP-7251: Meningkatkan BATAS_EFEKTIF_MAKSIMUM
• EIP-7002: Keluaran yang Dapat Dipicu oleh Layer Eksekusi
• EIP-6110: Pasok deposit validator di rantai
• EIP-7549: Pindahkan indeks komite di luar Attestation
• EIP-7685: Permintaan lapisan eksekusi tujuan umum
• EIP-2537: Pra-kompilasi untuk operasi kurva BLS12-381
• EIP-2935: Simpan hash blok historis di dalam state
• EIP-7623: Memperbesar biaya calldata
• EIP-7691: throughput blob meningkat
• EIP-7840: Menambahkan jadwal blob ke file konfigurasi EL
• EIP-7702: Tetapkan kode akun EOA

Beberapa EIP ini terutama menangani lapisan konsensus (beacon), sementara yang lain berhubungan dengan lapisan eksekusi. Beberapa mencakup kedua lapisan, karena operasi tertentu seperti deposit dan penarikan memerlukan perubahan yang disinkronkan di seluruh lapisan konsensus dan eksekusi. Karena ketergantungan ini, memisahkan Electra dan Prague tidak praktis, jadi kita akan meninjau setiap EIP secara berurutan dan menentukan komponen Ethereum yang terpengaruh dalam setiap kasus.

EIP-7251: Tingkatkan MAX_EFFECTIVE_BALANCE

Referensi: EIP-7251

Sejak hardfork Phase0 pertama, diimplementasikan untuk mempersiapkan Ethereum untuk Proof-of-Stake, dan hingga Electra, saldo efektif maksimum validator ditetapkan pada 32 ETH. Mengaktifkan validator memerlukan setidaknya spec.min_activation_balance (32 ETH). Setelah aktivasi, validator memulai dengan saldo efektif maksimum ini tetapi dapat mengurangi saldo efektifnya ke spec.ejection_balance (16 ETH) dan dikeluarkan setelah mencapai ambang batas tersebut. Logika "minimum" ini tetap tidak berubah di Electra, tetapi sekarang spec.max_effective_balance telah meningkat menjadi 2048 ETH. Akibatnya, validator dapat menyetor antara 32 dan 2048 ETH untuk aktivasi, dengan semua jumlah dalam kisaran ini berkontribusi pada saldo efektif mereka. Pergeseran ini menandai perpindahan dari "proof-of-32ETH-stake" ke "proof-of-stake" :)

Saldo efektif variabel ini akan digunakan sekarang:

• untuk meningkatkan probabilitas menjadi penawar blok, sebanding dengan saldo efektif
• untuk meningkatkan probabilitas menjadi anggota komite sinkronisasi, sebanding dengan saldo efektif
• sebagai dasar perhitungan jumlah pemotongan relatif dan denda ketidakaktifan

Dua kegiatan pertama adalah tindakan paling bermanfaat bagi validator. Oleh karena itu, setelah Electra, validator dengan taruhan yang lebih besar akan lebih sering berpartisipasi dalam proposisi blok dan komite sinkronisasi, sebanding dengan saldo efektif mereka.

Efek lain terkait dengan pengurangan. Semua hukuman pengurangan proporsional terhadap saldo efektif validator:

• Denda pengurangan "segera" dan "ditunda" lebih besar bagi validator dengan taruhan yang lebih tinggi.
• Hukuman pemotongan "ditangguhkan" untuk validator yang dipotong bersama validator dengan taruhan besar juga lebih besar, karena fraksi "yang dipotong" dari total taruhan menjadi lebih besar.
• Seorang whistleblower yang melaporkan validator dengan saldo efektif yang lebih tinggi akan menerima sebagian lebih besar dari staked yang dipotong.

Electra juga mengusulkan perubahan dalam kuotasi pemangkasan, mendefinisikan sebagian dari saldo validator yang dipangkas dan diterima oleh pengadu.

Efek ketidakaktifan berikutnya. Ketika seorang validator offline saat aktif (memberikan atau mengajukan), sebuah skor ketidakaktifan terakumulasi, menyebabkan denda ketidakaktifan yang diterapkan setiap epoch. Denda-denda ini juga berbanding lurus dengan saldo efektif validator.

“Batasan churn” validator juga mengalami perubahan karena peningkatan saldo efektif. Di Ethereum “pra-Electra,” validator umumnya memiliki saldo efektif yang sama, dan batas keluar churn didefinisikan sebagai “tidak lebih dari 1/65536 (spec.churn_limit_quotient) dari total taruhan dapat keluar dalam satu epoch.” Hal ini menciptakan jumlah keluar validator “tetap” dengan taruhan yang sama. Namun, di “pasca-Electra,” kemungkinan terjadi skenario di mana hanya sedikit “paus” yang keluar, karena mereka mewakili sebagian besar total taruhan.

Pertimbangan lain adalah rotasi kunci validator yang banyak pada satu instansi validator. Validator besar saat ini terpaksa menjalankan ribuan kunci validator pada satu instansi untuk menampung taruhan besar, membaginya menjadi bagian 32 ETH. Dengan Electra, perilaku ini tidak lagi wajib. Secara finansial, perubahan ini tidak banyak berbeda karena imbalan dan probabilitas berkembang secara linear dengan jumlah yang dipertaruhkan. Dengan demikian, 100 validator dengan masing-masing 32 ETH setara dengan satu validator dengan 3200 ETH. Selain itu, beberapa kunci validator aktif dapat memiliki kredensial penarikan Eth1 yang sama, memungkinkan semua imbalan ditarik ke satu alamat ETH dan menghindari biaya gas yang terkait dengan konsolidasi imbalan. Namun, mengelola sejumlah besar kunci akan menimbulkan biaya administrasi tambahan.

Kemampuan untuk mengonsolidasikan saldo validator menambahkan jenis permintaan lapisan eksekusi lainnya. Sebelumnya, kami memiliki deposit dan penarikan. Sekarang, akan ada jenis lain: permintaan konsolidasi. Ini akan menggabungkan dua validator menjadi satu. Permintaan operasi ini akan mencakup pubkey validator sumber dan pubkey target, dan akan diproses dengan cara yang sama dengan deposit dan penarikan. Konsolidasi juga akan memiliki permintaan tertunda dan batas pergantian saldo, sama seperti deposit dan penarikan.

Untuk merangkum:

• Untuk validator solo kecil, Electra memperkenalkan kemampuan untuk secara otomatis meningkatkan saldo efektif (dan hadiah) mereka. Sebelumnya, surplus di atas 32 ETH hanya dapat ditarik, tetapi setelah Electra, surplus ini pada akhirnya akan berkontribusi pada keseimbangan efektif mereka. Namun, saldo efektif hanya dapat meningkat dalam kelipatan spec.effective_balance_increment (1 ETH), yang berarti peningkatan terjadi hanya setelah mencapai "batas 1 ETH" berikutnya.
• Bagi validator solo besar, Electra menawarkan penyederhanaan manajemen yang signifikan dengan memungkinkan konsolidasi beberapa kunci validator aktif menjadi satu. Meskipun bukan pengubah game, mengoperasikan satu 1x2048 staking secara tak terbantahkan lebih sederhana daripada mengelola 64x32 staking.
• Untuk penyedia staking likuid, yang mengumpulkan taruhan kecil dari pengguna dan mendistribusikannya di antara validator, Electra menambahkan lebih banyak fleksibilitas dalam skema distribusi taruhan tetapi, pada saat yang sama, memerlukan refactoring yang serius dari akuntansi validator, yang saat ini didasarkan pada saldo efektif tetap 32 ETH.

Salah satu topik penting lainnya adalah data historis dan estimasi keuntungan untuk validator, yang sangat relevan bagi peserta baru yang mencoba mengevaluasi risiko dan hasil. Batas 32 ETH (baik minimum maupun maksimum, dalam praktek) sebelum Electra (pada saat penulisan artikel ini) menciptakan keseragaman dalam data historis. Semua validator memiliki saldo efektif, imbalan, hukuman pemotongan individu, frekuensi proposal blok, dan metrik lain yang sama. Keseragaman ini memungkinkan Ethereum untuk menguji mekanisme konsensusnya dengan sejumlah besar validator tanpa adanya nilai ekstrem statistik, mengumpulkan data perilaku jaringan yang berharga.

Setelah Electra, distribusi saham akan berubah secara signifikan. Validator besar akan lebih sering berpartisipasi dalam proposal blok dan komite sinkronisasi, menerima hukuman yang lebih besar dalam acara pemotongan, dan memiliki pengaruh yang lebih besar pada pemotongan yang ditangguhkan, antrean aktivasi, dan antrean keluar. Meskipun ini dapat menciptakan tantangan dalam agregasi data, konsensus Ethereum memastikan bahwa perhitungan non-linear minimal. Satu-satunya komponen non-linear menggunakan sqrt(total_effective_balance) untuk menghitung reward dasar, yang berlaku seragam untuk semua validator. Ini berarti hadiah dan pemotongan validator masih dapat diperkirakan berdasarkan "per 1 ETH" (atau, lebih tepatnya, per spec.effective_balance_increment, yang berpotensi berubah di masa depan).

Untuk informasi lebih lanjut, lihat artikel sebelumnya tentang perilaku validator kami.

EIP-7002: Eksekusi lapisan triggerable keluar

Referensi: EIP-7002

Setiap validator di Ethereum memiliki dua pasangan kunci: kunci aktif dan kunci penarikan. Kunci publik BLS aktif berfungsi sebagai identitas utama validator dalam rantai beacon, dan pasangan kunci ini digunakan untuk menandatangani blok, asertasi, pemotongan, agregat komite sinkronisasi, dan (sebelum EIP ini) keluar sukarela (untuk memulai keluar validator dari konsensus setelah penundaan). Pasangan kunci kedua ("kredensial penarikan") dapat berupa pasangan kunci BLS lain atau akun Eth1 reguler (kunci privat dan alamat). Sekarang, menarik ke alamat ETH memerlukan pesan penarikan yang ditandatangani oleh kunci privat BLS aktif. EIP ini mengubah hal tersebut.

Dalam praktiknya, pemilik dari dua pasang kunci ini (aktif dan penarikan) bisa berbeda. Kunci aktif validator bertanggung jawab atas tugas validasi: menjalankan server, menjaga agar tetap beroperasi, dll., sementara kredensial penarikan biasanya dikendalikan oleh pemilik staking, yang menerima imbalan dan bertanggung jawab atas dana tersebut. Saat ini, seorang pemilik staking yang hanya mengendalikan kredensial penarikan tidak bisa memulai keluar validator dan hanya bisa menarik imbalan. Situasi ini memungkinkan pemilik kunci aktif validator untuk secara efektif memegang saldo validator sebagai “sandera.” Validator dapat “mempresign” pesan keluar dan memberikannya kepada pemilik staking, namun solusi ini tidak ideal. Selain itu, baik penarikan maupun keluar saat ini memerlukan interaksi dengan validator lapisan beacon menggunakan API khusus.

Solusi optimal adalah memungkinkan pemilik staking untuk melakukan kedua operasi exit dan penarikan menggunakan panggilan kontrak pintar reguler. Ini melibatkan pemeriksaan tanda tangan Eth1 standar, sangat menyederhanakan operasi.

EIP ini memungkinkan pemilik staking untuk memicu penarikan dan keluar melalui transaksi standar dari alamat ETH mereka ke kontrak pintar yang didedikasikan (mirip dengan proses deposit yang ada yang menggunakan kontrak “Deposit”). Proses penarikan (atau keluar jika cukup staked dihapus) berfungsi sebagai berikut:

• Pemilik staking mengirimkan permintaan penarikan (permintaan "masuk") ke kontrak "Penarikan" sistem.
• Kontrak mengenakan biaya tertentu (dalam ETH) untuk mengurangi serangan pengganggu potensial dan beroperasi secara mirip dengan EIP-1559, dengan biaya meningkat ketika antrian permintaan sibuk.
• Kontrak menyimpan permintaan penarikan/keluar "masuk" ke penyimpanannya.
• Ketika blok diajukan ke lapisan beacon, permintaan penarikan/keluar "masuk" yang diantrean diambil dari penyimpanan.
• Lapisan sorot memproses permintaan "masuk", berinteraksi dengan saldo validator aktif, menjadwalkan validator untuk keluar, dan membentuk permintaan penarikan "keluar".
• Permintaan penarikan "out" diproses pada lapisan eksekusi, dan pemilik staking menerima ETH mereka.

Sementara deposito adalah operasi yang dipicu di blok Eth1 dan kemudian "dipindahkan" ke lapisan Beacon menggunakan antrian deposito "pending", penarikan mengikuti skema yang berbeda. Mereka dipicu di lapisan Beacon (melalui CLI) dan kemudian "dipindahkan" ke blok Eth1. Sekarang, kedua skema tersebut akan beroperasi menggunakan kerangka kerja generik yang sama (sebagai berikut): pembuatan permintaan di lapisan Eth1, pemrosesan antrian deposito/penarikan/konsolidasi "pending", dan pemrosesan di lapisan Beacon. Untuk operasi "output" seperti penarikan, antrian output juga diproses, dan hasilnya "diselesaikan" di blok Eth1.

Dengan EIP ini, pemilik staking dapat menarik dan keluar dari validator mereka menggunakan transaksi ETH reguler tanpa perlu berinteraksi langsung dengan validator CLI atau mengakses infrastruktur validator. Hal ini sangat menyederhanakan operasi staking, terutama untuk penyedia staking besar. Infrastruktur validator sekarang hampir sepenuhnya terisolasi, karena hanya kunci validator aktif yang perlu dipelihara, sementara semua operasi staking dapat ditangani di tempat lain. Ini menghilangkan kebutuhan bagi solo staker untuk menunggu tindakan validator aktif dan secara signifikan menyederhanakan bagian luar dari layanan seperti Modul Staking Komunitas dari Lido.

Akibatnya, EIP ini "menyelesaikan" operasi staking dengan memigrasikannya sepenuhnya ke lapisan Eth1, secara signifikan mengurangi risiko keamanan infrastruktur, dan meningkatkan desentralisasi inisiatif staking salone.

EIP-6110: Memasok deposit validator di rantai

Referensi: EIP-6110

Saat ini, deposit diimplementasikan melalui acara dalam kontrak sistem “Deposit” (seperti yang dibahas secara detail dalam artikel sebelumnya). Kontrak ini menerima ETH dan kredensial validator, mengeluarkan acara “Deposit()”, dan acara-acara ini kemudian dianalisis dan diubah menjadi permintaan deposit di lapisan beacon. Sistem ini memiliki banyak kekurangan: membutuhkan voting untuk eth1data pada lapisan chain beacon, yang menambahkan penundaan yang signifikan. Selain itu, lapisan beacon perlu mengambil data dari lapisan eksekusi, yang memperkenalkan kompleksitas lebih lanjut. Masalah-masalah ini dibahas secara detail dalam EIP. Metode yang lebih sederhana, yang menghilangkan banyak masalah ini, melibatkan langsung menyertakan permintaan deposit dalam blok Eth1 di lokasi yang ditentukan. Mekanisme ini mencerminkan proses penanganan penarikan yang dijelaskan dalam EIP sebelumnya.

Perubahan yang diusulkan dalam EIP ini menjanjikan. Pemrosesan eth1data sekarang dapat sepenuhnya dihapus, menghilangkan kebutuhan untuk pemungutan suara atau penundaan lama antara peristiwa di sisi Eth1 dan inklusi deposit pada lapisan beacon (saat ini sekitar 12 jam). Ini juga menghapus logika untuk snapshot kontrak deposit. EIP ini menyederhanakan pemrosesan deposit dan menyelarasinya dengan skema pemrosesan penarikan yang dijelaskan di atas.

Baik pemilik staking maupun validator, perubahan ini secara signifikan mengurangi keterlambatan antara deposit dan aktivasi validator. Top-up, yang diperlukan ketika validator diserang, juga akan lebih cepat.

Tidak banyak yang bisa dikatakan tentang EIP ini selain bahwa itu menghapus logika usang, menyederhanakan proses, dan menciptakan hasil yang lebih baik untuk semua pihak yang terlibat.

EIP-7685: Permintaan lapisan eksekusi tujuan umum

Referensi: EIP-7685

EIP ini seharusnya argumen telah disajikan sebelum tiga EIP terdahulu terkait deposit/penarikan/konsolidasi, karena ini meletakkan dasar bagi mereka. Namun, diperkenalkan di sini untuk menekankan kebutuhan yang semakin meningkat untuk mekanisme generik untuk secara konsisten memindahkan data khusus antara blok rantai Eth1 (eksekusi) dan Beacon (konsensus) (lapisan). EIP ini memengaruhi kedua lapisan, membuat pemrosesan permintaan yang dipicu oleh transaksi ETH reguler lebih efisien. Saat ini, kami mengamati:

• Deposit events dalam blok Eth1 'dipindahkan' dari Eth1 ke blok Beacon untuk diproses.
• Permintaan penarikan di blok Beacon (menggunakan CLI) "dipindahkan" ke blok Eth1 untuk diproses.
• Kebutuhan untuk menangani konsolidasi validator, yang juga merupakan permintaan Eth1->Beacon.

Tiga operasi ini menunjukkan kebutuhan penanganan yang konsisten untuk berbagai jenis permintaan saat mereka berpindah antara lapisan eksekusi dan beacon. Selain itu, kami membutuhkan kemampuan untuk memicu operasi-operasi ini hanya menggunakan lapisan Eth1, karena ini akan memungkinkan kami mengisolasi infrastruktur validator dari infrastruktur pengelolaan staking, meningkatkan keamanan. Oleh karena itu, solusi generik untuk mengelola permintaan-permintaan seperti ini adalah praktis dan penting.

EIP ini menetapkan kerangka kerja untuk setidaknya tiga kasus utama: deposit, penarikan, dan konsolidasi. Inilah mengapa EIP sebelumnya memperkenalkan bidang seperti WITHDRAWAL_REQUEST_TYPE dan DEPOSIT_REQUEST_TYPE, dan sekarang konsolidasi akan menambahkan yang lain, CONSOLIDATION_REQUEST_TYPE. Selain itu, EIP ini kemungkinan akan mencakup mekanisme umum untuk menangani batasan untuk permintaan-permintaan tersebut (konstan referensi: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

Meskipun detail implementasi khusus untuk kerangka kerja ini belum tersedia, namun pasti akan mencakup jenis permintaan kunci, mekanisme integritas (misalnya, hashing dan Merkle-izing permintaan), serta pemrosesan antrian tertunda dengan pembatasan kecepatan.

EIP ini memiliki signifikansi arsitektural, memungkinkan Eth1 untuk memicu tindakan kritis di lapisan Beacon melalui kerangka kerja yang terpadu. Bagi pengguna dan proyek, ini berarti semua permintaan yang dipicu di lapisan Eth1 akan disampaikan dan diproses di lapisan Beacon dengan lebih efisien.

EIP-2537: Prekompilasi untuk operasi kurva BLS12-381

Referensi: EIP-2537

Jika Anda tidak ingin terlalu mendalam, Anda dapat mempertimbangkan prekomputasi BLS12-381 sebagai operasi kriptografi kompleks yang sekarang dapat digunakan dalam kontrak cerdas. Bagi yang tertarik, mari kita jelajahi ini lebih lanjut.

Operasi matematika pada kurva eliptik seperti BLS12-381 (dan pasangannya: BN-254) saat ini digunakan untuk dua tujuan utama:

• Tanda tangan BLS, di mana operasi khusus yang disebut "pairing" digunakan untuk memverifikasi tanda tangan ini. Tanda tangan BLS banyak digunakan oleh validator karena memungkinkan agregasi beberapa tanda tangan menjadi satu. Validator mengandalkan tanda tangan BLS berdasarkan kurva BLS12-381 (meskipun mereka juga dapat diimplementasikan menggunakan kurva apa pun yang mendukung pasangan, seperti BN254).
• verifikasi bukti zkSNARK, di mana pasangan digunakan untuk memvalidasi bukti. Selain itu, komitmen KZG terhadap blob (diperkenalkan oleh hard fork Dencun) juga menggunakan pasangan untuk memverifikasi komitmen blob.

Jika Anda ingin memverifikasi tanda tangan BLS atau bukti zkSNARK dalam kontrak pintar, Anda harus menghitung "pasangan" ini yang mahal secara komputasi. Ethereum sudah memiliki kontrak yang telah dikompilasi sebelumnya untuk operasi kurva BN254 (EIP-196 dan EIP-197). Namun, kurva BLS12-381 (yang sekarang diakui lebih aman dan jauh lebih banyak digunakan saat ini) belum diimplementasikan sebagai prakompilasi. Tanpa prakompilasi seperti itu, menerapkan pasangan dan operasi kurva lainnya dalam kontrak pintar memerlukan perhitungan berat, seperti yang ditunjukkan di sini, dan mengkonsumsi gas dalam jumlah besar (~ 10 ^ 5 hingga 10 ^ 6 gas).

EIP ini membuka pintu bagi banyak aplikasi potensial, terutama dalam memungkinkan verifikasi tanda tangan BLS yang murah berdasarkan kurva BLS12-381. Ini memungkinkan untuk menerapkan skema ambang batas untuk berbagai tujuan. Seperti disebutkan sebelumnya, validator Ethereum sudah menggunakan tanda tangan berbasis BLS12-381. Dengan EIP ini, kontrak pintar standar sekarang dapat melakukan verifikasi yang efisien terhadap tanda tangan validator agregat. Ini dapat menyederhanakan bukti konsensus dan menjembatani aset antar jaringan, karena tanda tangan BLS banyak digunakan di seluruh blockchain. Tanda tangan BLS ambang batas sendiri memungkinkan pembangunan banyak skema ambang batas yang efisien untuk pemungutan suara, pembuatan nomor acak terdesentralisasi, multisig, dll.

Verifikasi bukti zkSNARK yang lebih murah akan, pada gilirannya, membuka banyak aplikasi. Banyak solusi berbasis zkSNARK saat ini terhambat oleh biaya tinggi verifikasi bukti, membuat beberapa proyek hampir tidak praktis. EIP ini memiliki potensi untuk mengubah hal tersebut.

EIP-2935: Simpan hash blok historis dalam status

Referensi: EIP-2935

EIP ini mengusulkan untuk menyimpan 8192 (~ 27,3 jam) hash blok historis dalam keadaan blockchain, memberikan riwayat panjang untuk klien stateless (seperti rollup) dan kontrak pintar. Ini menyarankan mempertahankan perilaku opcode BLOCKHASH saat ini, mempertahankan pembatasan hingga 256 blok, sambil memperkenalkan kontrak sistem baru yang dirancang khusus untuk menyimpan dan mengambil hash historis. Kontrak ini melakukan operasi set() ketika lapisan eksekusi memproses blok. Metode get()-nya, dapat diakses oleh siapa saja, mengambil hash blok yang diperlukan dari buffer ring.

Saat ini, memang memungkinkan untuk merujuk pada hash blok historis dalam EVM, tetapi akses terbatas pada 256 blok terbaru (~50 menit). Namun, ada kasus di mana akses ke data blok yang lebih lama sangat penting, seperti untuk aplikasi lintas-rantai (yang memerlukan bukti data dari blok sebelumnya) dan klien tanpa status, yang sesekali memerlukan akses ke hash blok sebelumnya.

EIP ini memperluas horizon waktu yang tersedia untuk rollups dan aplikasi lintas-rantai, memungkinkan mereka mengakses data historis secara langsung di EVM tanpa perlu mengumpulkannya secara eksternal. Akibatnya, solusi-solusi ini menjadi lebih kokoh dan berkelanjutan.

EIP-7623: Meningkatkan biaya calldata

Referensi: EIP-7623

Biaya calldata mengatur ukuran yang tersedia dari muatan transaksi, yang dalam beberapa kasus bisa cukup besar (misalnya, saat melewati array besar atau buffer biner sebagai parameter). Penggunaan calldata yang signifikan terutama disebabkan oleh rollups, yang mengirimkan muatan melalui calldata yang berisi status rollup saat ini.

Kemampuan untuk memperkenalkan data biner yang besar dan dapat dibuktikan ke dalam blockchain sangat penting untuk rollup. Peningkatan Dencun (Deneb-Cancun) memperkenalkan inovasi besar untuk kasus penggunaan tersebut — transaksi blob (EIP-4844). Transaksi blob memiliki biaya gas "blob" khusus mereka sendiri, dan sementara tubuh mereka disimpan sementara, bukti kriptografi mereka (komitmen KZG), bersama dengan hash mereka, diintegrasikan ke dalam lapisan konsensus. Dengan demikian, blob memberikan solusi superior untuk rollup dibandingkan dengan menggunakan calldata untuk penyimpanan data.

Mendorong rollup untuk mentransisikan data mereka ke gumpalan dapat dicapai dengan menggunakan pendekatan "wortel dan tongkat". Mengurangi biaya gas blob berfungsi sebagai "wortel," sementara EIP ini berfungsi sebagai "tongkat" dengan meningkatkan biaya calldata, sehingga mengecilkan penyimpanan data yang berlebihan dalam transaksi. EIP ini melengkapi EIP-7691 berikutnya (peningkatan throughput Blob), yang meningkatkan jumlah maksimum blob yang diizinkan per blok.

EIP-7691: peningkatan throughput Blob

Referensi: EIP-7691

Blob diperkenalkan di hard fork Dencun sebelumnya, dan nilai awal untuk jumlah maksimum dan target blob "per-blok" adalah perkiraan konservatif. Hal ini disebabkan oleh kompleksitas memprediksi bagaimana jaringan p2p akan menangani propagasi objek biner besar antara node validator. Konfigurasi awal telah terbukti bekerja dengan baik, menjadikannya waktu yang tepat untuk menguji nilai baru. Sebelumnya, jumlah target/maksimum blob per blok ditetapkan pada 3/6. Batas ini sekarang dinaikkan menjadi 6/9, masing-masing.

Ketika digabungkan dengan EIP-7623 sebelumnya (Meningkatkan biaya calldata), penyesuaian ini lebih memotivasi rollups untuk beralih data mereka dari calldata ke blobs. Pencarian parameter blob optimal terus berlanjut.

EIP-7840: Tambahkan jadwal blob ke file konfigurasi EL

Referensi: EIP-7840

EIP ini mengusulkan menambahkan target dan jumlah maksimum blob 'per-block' (yang telah dibahas sebelumnya) dan nilai baseFeeUpdateFraction ke dalam file konfigurasi Ethereum Execution Layer (EL). Ini juga memungkinkan klien untuk mengambil nilai-nilai ini melalui API node. Fitur ini sangat berguna untuk tugas-tugas seperti memperkirakan biaya gas blob.

EIP-7702: Tetapkan kode akun EOA

Referensi: EIP-7702

Ini adalah EIP yang sangat penting yang akan membawa perubahan besar bagi pengguna Ethereum. Seperti yang kita ketahui, sebuah EOA (Eksternal Owned Account) tidak dapat memiliki kode tetapi dapat memberikan tanda tangan transaksi (tx.origin). Sebaliknya, sebuah kontrak pintar memiliki bytecode tetapi tidak dapat menyampaikan tanda tangan langsung "nya". Setiap interaksi dari pengguna yang memerlukan logika tambahan, otomatis, dan dapat diverifikasi saat ini hanya dapat dicapai dengan memanggil kontrak eksternal untuk melakukan tindakan yang diperlukan. Namun, dalam kasus tersebut, kontrak eksternal menjadi msg.sender untuk kontrak berikutnya, menjadikan panggilan "sebuah panggilan dari kontrak, bukan pengguna."

EIP ini memperkenalkan tipe transaksi SET_CODE_TX_TYPE=0x04 yang baru (sebelumnya kita memiliki transaksi lama 0x1, transaksi baru 0x02 dari upgrade Berlin dan EIP-1559, dan transaksi blob 0x03 yang diperkenalkan di Dencun). Tipe transaksi baru ini memungkinkan pengaturan kode untuk akun EOA. Pada dasarnya, ini memungkinkan EOA untuk menjalankan kode eksternal “dalam konteks akun EOA-nya sendiri”. Dari perspektif eksternal, terlihat seperti, selama transaksi, EOA “meminjam” kode dari kontrak eksternal dan menjalankannya. Secara teknis, ini dimungkinkan dengan menambahkan tuple data otorisasi khusus ke penyimpanan “kode” dari alamat EOA (sebelum EIP ini, penyimpanan “kode” ini selalu kosong untuk EOAs).

Saat ini, EIP ini mengusulkan bahwa jenis transaksi baru 0x04 mencakup array:

authorization_list = [[chain_id, alamat, nonce, y_parity, r, s], ...]

di mana setiap elemen memungkinkan akun untuk menggunakan kode dari alamat yang ditentukan (dari item otorisasi valid terakhir). Memproses transaksi semacam itu menetapkan kode EOA yang diberikan ke 0xef0100 khusus || nilai alamat (23 byte), di mana alamat menunjuk ke kontrak dengan kode yang diinginkan untuk dieksekusi, || menunjukkan penggabungan, dan 0xef0100 mewakili nilai ajaib khusus yang tidak dapat ditampung oleh kontrak pintar biasa (sesuai EIP-3541). Nilai ajaib ini memastikan bahwa EOA ini tidak dapat diperlakukan sebagai kontrak biasa atau memiliki panggilan yang dibuat untuk itu seperti itu.

Ketika EOA ini memulai transaksi, alamat yang ditentukan akan digunakan untuk memanggil kode yang sesuai dalam konteks EOA tersebut. Meskipun detail implementasi lengkap dari EIP ini belum diketahui, sudah pasti akan membawa perubahan signifikan.

Salah satu dampak utama adalah memungkinkan kemampuan untuk melakukan multicalls langsung dari EOA. Multicalls adalah tren yang sedang berlangsung di DeFi, dengan banyak protokol menawarkan fitur ini sebagai alat yang kuat (contohnya Uniswap V4, Balancer V3, atau Euler V2). Dengan EIP ini, multicalls sekarang dapat dilakukan langsung dari EOAs.

Sebagai contoh, fitur baru ini menyelesaikan masalah umum dalam DeFi: ketidakefisienan approve() + anything() yang memerlukan dua transaksi terpisah. EIP ini memungkinkan adanya logika "pra-persetujuan" generik, memungkinkan tindakan seperti approve(X) + deposit(X) untuk diselesaikan dalam satu transaksi.

Keuntungan lain yang diperkenalkan oleh kemampuan untuk mendelegasikan eksekusi transaksi "atas nama" EOA adalah konsep sponsorship. Sponsor sering dibahas dan fitur yang sangat diinginkan untuk orientasi pengguna baru ke Ethereum.

Logika yang dapat diprogram yang terkait dengan EOA membuka berbagai kemungkinan, seperti mengimplementasikan pembatasan keamanan, menetapkan batas pengeluaran, menegakkan persyaratan KYC, dan banyak lagi.

Secara alami, pergeseran ini juga menimbulkan banyak pertanyaan desain. Salah satu masalah adalah penggunaan chain_id, yang menentukan apakah tanda tangan yang sama dapat atau tidak dapat valid di beberapa jaringan berdasarkan penyertaan atau pengecualiannya dalam tanda tangan. Masalah kompleks lainnya adalah apakah akan menggunakan alamat kode target versus menyematkan bytecode yang sebenarnya. Kedua pendekatan memiliki fitur dan keterbatasan yang unik. Selain itu, penggunaan nonce memainkan peran kunci dalam menentukan apakah izin "multiguna" atau "sekali pakai." Elemen-elemen ini memengaruhi fitur dan masalah keamanan, termasuk aspek-aspek seperti pembatalan tanda tangan secara massal dan kemudahan penggunaan. Vitalik telah mengajukan pertanyaan-pertanyaan ini dalam sebuah diskusi (di sini), yang perlu ditelusuri lebih lanjut.

Sangat penting untuk dicatat bahwa perubahan ini akan berdampak pada salah satu mekanisme keamanan Ethereum, tx.origin. Rincian lebih lanjut tentang implementasi EIP ini diperlukan, tetapi sepertinya perilaku require(tx.origin == msg.sender) akan berubah. Pemeriksaan ini telah menjadi cara yang paling dapat diandalkan untuk memastikan bahwa msg.sender adalah EOA dan BUKAN kontrak. Metode lain, seperti memeriksa EXTCODESIZE (untuk memeriksa apakah itu kontrak), sering gagal dan dapat dilewati (misalnya, dengan memanggil dari konstruktor atau dengan menyebarkan kode di alamat yang telah ditentukan setelah transaksi). Pemeriksaan ini telah digunakan untuk mencegah serangan reentrancy dan flashloan tetapi jauh dari ideal karena mereka juga menghambat integrasi dengan protokol eksternal. Setelah EIP ini, bahkan pemeriksaan require(tx.origin == msg.sender) yang andal tampaknya menjadi usang. Protokol harus beradaptasi dengan menghapus pemeriksaan tersebut, karena perbedaan antara "EOA" dan "kontrak" tidak akan berlaku lagi - sekarang setiap alamat berpotensi memiliki kode terkait.

Pemisahan EOA tradisional dan kontrak pintar terus memudar. EIP ini mendekatkan Ethereum pada desain seperti TON, di mana setiap akun pada dasarnya adalah kode yang dapat dieksekusi. Evolusi ini adalah hal yang wajar karena interaksi dengan protokol semakin kompleks, sehingga diperlukan logika yang dapat diprogram untuk meningkatkan UX bagi pengguna akhir.

Kesimpulan

Upgrade Prague/Electra (Pectra) dijadwalkan dilakukan pada Maret 2025. Perubahan yang paling signifikan yang direncanakan termasuk:

• stake efektif validator variabel, hingga 2048 ETH, yang akan secara signifikan mengubah distribusi stake, jadwal validator, dan menyederhanakan manajemen untuk penyedia staking besar dengan mengkonsolidasikan stake yang lebih kecil
• interaksi lapisan eksekusi-ke-konsensus yang ditingkatkan, menyederhanakan pertukaran data antara blok eksekusi Eth1 dan blok rantai Beacon. Ini akan sangat menyederhanakan deposit, aktivasi, penarikan, dan keluar, mempercepat proses-proses ini dan membentuk dasar untuk interaksi lebih lanjut antara lapisan konsensus dan eksekusi
• dukungan untuk verifikasi tanda tangan BLS yang lebih murah dan zkSNARK langsung dalam kontrak pintar melalui pra-kompilasi BLS12-381 yang 'pairing-friendly' baru
• terus mendorong rollups untuk mengadopsi transaksi blob alih-alih calldata dengan meningkatkan ambang batas transaksi blob dan menaikkan biaya calldata
• memungkinkan EOAs untuk bertindak sebagai akun yang dapat diprogram, memberdayakan mereka dengan fitur seperti multicalls, sponsorships, dan fungsionalitas lanjutan lainnya

Seperti yang bisa Anda lihat, Pectra akan berdampak signifikan pada lapisan staking dan konsensus, serta pengalaman pengguna di lapisan eksekusi. Meskipun kita tidak dapat menganalisis semua perubahan ini secara detail melalui kode pada tahap ini, karena pengembangan sedang berlangsung, kita akan mencakup pembaruan ini dalam artikel-artikel mendatang.

Disclaimer:

1. Artikel ini direproduksi dari [TechFlow]. Meneruskan judul aslinya: The Prague/Electra (Pectra) Hardfork Explained. Hak cipta adalah milik penulis asli [MixBytes]. Jika Anda memiliki keberatan terhadap pemutar ulang, silakan hubungi Tim Belajar Gate, dan tim akan menanganinya sesegera mungkin sesuai dengan prosedur terkait.
2. Penafian: Pandangan dan opini yang terdapat dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan nasihat investasi apa pun.
3. Versi bahasa lain dari artikel ini diterjemahkan oleh tim gate Learn. Kecuali dinyatakan lain, artikel yang diterjemahkan tidak boleh disalin, didistribusikan atau dijiplak.