Dalam artikel sebelumnya, kami secara rinci mengulas siklus hidup validator Ethereum dan membahas berbagai aspek terkait hard fork Electra yang akan datang. Sekarang, saatnya fokus pada perubahan yang akan datang dalam upgrade Electra dan Prague, dan menjelaskannya secara detail.
Sejarah hard fork 'proof of stake' Ethereum 2.0 sangat kompleks. Dimulai dengan menambahkan lapisan sinyal ke lapisan eksekusi yang ada, di mana konsensus proof of stake diluncurkan di lapisan sinyal sementara lapisan eksekusi tetap menggunakan proof of work (hard fork Phase0 dan Altair). Kemudian, dalam hard fork Bellatrix, proof of stake diaktifkan sepenuhnya (meskipun penarikan belum diaktifkan). Selanjutnya, hard fork Capella mengizinkan penarikan, menyelesaikan siklus hidup validator. Hard fork terbaru, Deneb (bagian dari upgrade Dencun (Deneb/Cancun)), membuat revisi kecil pada parameter rantai sinyal, seperti jendela waktu bukti, penanganan keluarnya sukarela, dan pembatasan pergantian validator. Perubahan utama dalam Dencun terjadi dalam lapisan eksekusi, dengan diperkenalkannya transaksi blob, gas blob, KZG commitment untuk blob, dan pembuangan operasi SELFDESTRUCT.
Sekarang, hard fork Prague/Electra (dikenal juga sebagai Pectra) menghadirkan pembaruan penting untuk lapisan eksekusi dan konsensus. Sebagai pemeriksa proyek Lido, kami secara khusus memperhatikan perubahan terkait konsensus dan staking dalam hard fork ini. Namun, kami tidak dapat mengabaikan perubahan lapisan eksekusi dalam Prague karena termasuk fitur-fitur penting yang memengaruhi jaringan Ethereum dan validator. Mari kita telusuri detail perubahan ini.
Gambaran Tingkat Lebih Tinggi Pectra
Electra telah memperkenalkan banyak fitur ke lapisan sinyal. Pembaruan utama termasuk:
Memungkinkan saldo efektif validator berubah antara 32 hingga 2048 ETH (bukan tetap 32 ETH).
Memungkinkan validator untuk menginisiasi penarikan melalui sertifikat penarikan tingkat kedua (tidak lagi memerlukan kunci validator aktif).
Mengubah cara pemrosesan deposit Eth1 pada lapisan beacon (tidak lagi dari analisis acara pada kontrak deposit).
Menambahkan kerangka kerja baru untuk memproses permintaan kontrak Eth1 konvensional di lapisan beacon (mirip dengan cara pengelolaan deposito sebelumnya pada Electra).
Sementara itu, Prague mengenalkan perubahan berikut untuk tingkat pelaksanaan:
Sebuah kontrak pra-kompilasi baru, 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 (sangat berguna untuk klien tanpa status).
Menambahkan biaya gas calldata untuk mengurangi ukuran blok dan mendorong proyek untuk memindahkan operasi yang padat calldata (seperti rollup) ke blob yang diperkenalkan dalam Dencun.
Mendukung lebih banyak blob untuk setiap blok Eth1, dan menyediakan API untuk membaca jumlah ini.
Memungkinkan EOA (Eksternal Akun Pemilik) memiliki kode akun mereka sendiri, yang secara signifikan memperluas operasi yang dapat dilakukan oleh EOA, seperti melakukan multicalls atau mendeplegasikan eksekusi ke alamat lain.
Mari kita lihat (EIP) Proposal Peningkatan Ethereum yang relevan untuk diskusi lebih lanjut:
EIP-7251: Menambahkan MAX_EFFECTIVE_BALANCE
EIP-7002: Keluar yang Dapat Dipicu oleh Lapisan Pelaksanaan
EIP-6110: Menyediakan deposit validator on-chain
EIP-7549: Mengeluarkan Indeks Komite dari Bukti
EIP-7685: Permintaan Lapisan Eksekusi Umum
EIP-2537: Pra-penyimpanan operasi kurva BLS12-381
EIP-2935: Menyimpan hash blok historis dalam status
EIP-7623: Menambahkan biaya calldata
EIP-7691: peningkatan throughput blob
EIP-7840: Menambahkan penjadwalan blob ke file konfigurasi EL
EIP-7702: Mengatur kode rekening EOA
Beberapa EIP ini terutama terkait dengan lapisan konsensus (beacon), sedangkan yang lain terkait dengan lapisan eksekusi. Beberapa melintasi kedua lapisan tersebut karena beberapa operasi (seperti deposit dan penarikan) memerlukan perubahan sinkronisasi antara lapisan konsensus dan eksekusi. Karena saling ketergantungan ini, memisahkan Electra dan Prague tidak praktis, oleh karena itu kita akan melihat setiap EIP secara berurutan dan menentukan komponen Ethereum yang terpengaruh dalam setiap kasus.
EIP-7251: Menambahkan MAX_EFFECTIVE_BALANCE
Referensi: EIP-7251
Sejak hard fork Phase0 pertama, untuk mempersiapkan bukti kepemilikan Ethereum, hingga Electra, saldo maksimum yang valid untuk validator tetap pada 32 ETH. Untuk mengaktifkan validator, setidaknya diperlukan saldo aktivasi minimum (32 ETH). Setelah diaktifkan, validator memulai dengan saldo maksimum ini, namun dapat mengurangi saldo validitasnya hingga saldo ejeksi (16 ETH), dan akan diusir ketika mencapai ambang batas tersebut. Logika "minimal" ini tetap tidak berubah dalam Electra, tetapi sekarang saldo maksimum yang efektif telah ditingkatkan menjadi 2048 ETH. Oleh karena itu, validator dapat melakukan deposito antara 32 hingga 2048 ETH untuk mengaktifkan, dan semua jumlah ini akan berkontribusi pada saldo validitasnya. Perubahan ini menandai transisi dari "32ETH-Proof of Stake" ke "Proof of Stake" :)
Saldo efektif yang dapat berubah ini sekarang akan digunakan untuk:
Meningkatkan probabilitas menjadi proposer blok, sebanding dengan saldo yang valid
Meningkatkan probabilitas menjadi anggota komite sinkronisasi, sebanding dengan saldo yang valid
Sebagai dasar untuk mengurangi jumlah hukuman yang terkait dengan perhitungan dan tidak aktif
Kegiatan pertama adalah operasi paling menguntungkan bagi validator. Oleh karena itu, setelah Electra, validator dengan staking besar akan lebih sering terlibat dalam proposal blok dan komite sinkronisasi, dengan frekuensi sebanding dengan saldo efektif mereka.
Pengaruh lainnya terkait dengan pemotongan. Semua pemotongan denda sebanding dengan saldo efektif validator:
Hukuman pemotongan "segera" dan "tertunda" lebih besar untuk validator dengan staking tinggi.
Denda pemangkasan 'terlambat' bersama dengan validator yang memiliki jaminan tinggi juga lebih besar, karena bagian 'terpotong' dari total jaminan menjadi lebih besar.
Pelapor yang melaporkan validator dengan saldo sisa yang tinggi akan menerima potongan jaminan yang lebih besar.
Electra juga mengusulkan perubahan pada rasio pemotongan, mendefinisikan bagian dari saldo validator yang dipotong dan diterima oleh pelapor.
Selanjutnya adalah dampak ketidakefektifan. Ketika validator tidak aktif (membuktikan atau mengusulkan) saat aktif, skor ketidakefektifan akan terakumulasi, mengakibatkan hukuman ketidakefektifan diberlakukan setiap periode. Hukuman ini juga berhubungan dengan saldo efektif validator dalam proporsi.
Karena peningkatan saldo efektif, "batas penggantian" untuk validator juga telah berubah. Dalam Ethereum "pra-Electra", validator biasanya memiliki saldo efektif yang sama, dan batas penggantian keluar didefinisikan sebagai "tidak lebih dari 1/65536 (spec.churn_limit_quotient) dari total taruhan dapat keluar dalam satu siklus." Ini menciptakan jumlah validator "tetap" dengan taruhan yang sama untuk keluar. Namun, setelah "Electra", ada kemungkinan bahwa hanya beberapa "paus" yang akan keluar, karena mereka mewakili bagian penting dari total saham.
Pertimbangan lain adalah rotasi kunci validator yang banyak pada satu instansi validator tunggal. Validator besar saat ini terpaksa menjalankan ribuan kunci validator pada satu instansi untuk menyesuaikan dengan jumlah staking besar, membaginya menjadi bagian 32 ETH. Dengan Electra, perilaku ini tidak lagi menjadi wajib. Dari segi keuangan, perubahan ini tidak terlalu berpengaruh karena imbalan dan probabilitas berkorelasi secara linear dengan jumlah staking. Oleh karena itu, 100 validator dengan masing-masing 32 ETH setara dengan satu validator 3200 ETH. Selain itu, beberapa kunci validator aktif dapat memiliki tanda terima Eth1 yang sama, memungkinkan semua imbalan ditarik ke satu alamat ETH tunggal, sehingga menghindari biaya gas yang terkait dengan penggabungan imbalan. Namun, mengelola banyak kunci akan menimbulkan biaya pengelolaan tambahan.
Kemampuan saldo validator agregat telah ditambahkan dengan jenis permintaan eksekusi baru. Sebelumnya, kami memiliki setoran dan penarikan. Sekarang, akan ada jenis lain: permintaan agregat. Ini menggabungkan dua validator menjadi satu. Permintaan operasi ini akan mencakup kunci publik validator sumber dan kunci publik tujuan, dan akan ditangani seperti setoran dan penarikan. Agregasi juga akan memiliki batasan permintaan tertunda dan penggantian saldo, seperti setoran dan penarikan.
Ringkasan sebagai berikut:
Untuk validator independen kecil, Electra telah memperkenalkan kemampuan untuk secara otomatis meningkatkan saldo efektif mereka (dan hadiah). Sebelumnya, surplus di atas 32 ETH hanya dapat ditarik, tetapi setelah Electra, surplus ini pada akhirnya akan berkontribusi pada keseimbangan efektifnya. Namun, saldo efektif hanya dapat ditingkatkan dalam kelipatan spec.effective_balance_increment (1 ETH), yang berarti bahwa peningkatan hanya terjadi setelah "batas 1 ETH" berikutnya tercapai.
Untuk validator independen besar, Electra memberikan penyederhanaan manajemen yang signifikan dengan memungkinkan penggabungan kunci validator aktif menjadi satu, meskipun ini tidak mengubah aturan permainan, mengelola staking 1x2048 jelas lebih sederhana daripada mengelola 64x32.
Bagi penyedia staking likuiditas, mereka mengumpulkan staking kecil dari pengguna dan mendistribusikannya di antara para validator, Electra menambahkan lebih banyak fleksibilitas dalam skema distribusi staking, namun juga memerlukan restrukturisasi yang serius terhadap akuntansi validator dengan saldo efektif tetap 32 ETH.
Salah satu topik penting lainnya adalah data historis dan estimasi keuntungan validator, yang sangat relevan bagi peserta baru yang mencoba mengevaluasi risiko dan imbal hasil. Sebelum Electra (pada saat penulisan ini), batas atas 32 ETH (baik minimum maupun maksimum) menciptakan keseragaman dalam data historis. Saldo efektif, imbalan, hukuman pengurangan individu, frekuensi proposal blok, dan indikator lainnya bagi semua validator adalah sama. Keseragaman ini memungkinkan Ethereum untuk menguji mekanisme konsensusnya tanpa adanya nilai anomali statistik, sehingga mengumpulkan data perilaku jaringan yang berharga.
Setelah Electra, akan ada perubahan signifikan dalam distribusi staking. Validator besar akan lebih sering berpartisipasi dalam proposal blok dan komite sinkronisasi, menghadapi hukuman yang lebih besar dalam acara pemotongan, dan memiliki dampak yang lebih besar pada pemotongan yang tertunda, antrean aktivasi, dan antrian 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 untuk semua validator. Ini berarti bahwa hadiah dan garis miring validator masih dapat diperkirakan berdasarkan "per 1 ETH" (atau lebih tepatnya, berdasarkan spec.effective_balance_increment, yang dapat berubah di masa mendatang).
Untuk informasi lebih lanjut, silakan lihat artikel kami sebelumnya tentang perilaku validator.
EIP-7002: Keluaran Lapisan Eksekusi yang Dapat Dipicu
Referensi: EIP-7002
Setiap validator di Ethereum memiliki dua pasang kunci: kunci aktif dan kunci penarikan. Kunci publik BLS aktif berfungsi sebagai identitas utama validator di rantai pancang, dan pasangan kunci ini digunakan untuk menandatangani blok, bukti, pemangkasan, sinkronisasi komite agregat, dan (sebelum EIP ini) keluar sukarela (untuk konsensus validator yang keluar setelah penundaan). Pasangan kunci kedua ("tanda terima penarikan") dapat berupa pasangan kunci BLS lainnya atau akun Eth1 konvensional (kunci privat dan alamat). Sekarang, penarikan ke alamat ETH memerlukan pesan penarikan yang ditandatangani oleh kunci privat BLS aktif. EIP ini telah mengalami perubahan.
Faktanya, pemilik kedua pasangan kunci (aktif dan penarikan) ini bisa berbeda. Kunci aktif validator bertanggung jawab atas tugas verifikasi: menjalankan server, menjaganya tetap aktif dan berjalan, dll., Sementara kredensial penarikan biasanya dikendalikan oleh pemilik saham, yang menerima hadiah dan bertanggung jawab atas dana tersebut. Saat ini, hanya pemilik saham yang mengontrol kredensial penarikan yang tidak dapat memulai penarikan validator dan hanya dapat menarik hadiah. Situasi ini memungkinkan pemilik kunci aktif validator untuk secara efektif menahan saldo validator sebagai "sandera". Validator dapat "menandatangani" pesan keluar dan menyerahkannya kepada pemilik pasak, tetapi solusi ini tidak ideal. Selain itu, ekstraksi dan penarikan saat ini memerlukan interaksi dengan validator lapisan suar melalui API khusus.
Solusi terbaik adalah memungkinkan pemilik jaminan untuk melakukan penarikan dan pencairan secara bersamaan melalui kontrak pintar konvensional. Ini melibatkan pemeriksaan tanda tangan Eth1 standar, yang sangat menyederhanakan operasi.
EIP ini memungkinkan pemegang staking untuk memicu penarikan dan penarikan (mirip dengan proses deposit menggunakan kontrak "deposit" yang ada) dengan mengirimkan transaksi standar dari alamat ETH mereka ke kontrak pintar khusus.
Penyetor mengirim permintaan penarikan (permintaan 'in') ke kontrak penarikan sistem.
Kontrak mengenakan biaya tertentu (dalam ETH) untuk mengurangi potensi serangan jahat, dan serupa dengan EIP-1559, biaya akan meningkat saat antrian permintaan sibuk.
Kontrak akan menyimpan permintaan penarikan / penarikan 'in' ke dalam penyimpanannya.
Ketika blok diusulkan ke lapisan sinyal, permintaan penarikan / penarikan 'in' dalam antrian akan diambil dari penyimpanan.
Lapisan beacon mengelola permintaan 'in', berinteraksi dengan saldo validator aktif, mengatur penarikan validator, dan membentuk permintaan 'out'.
Permintaan penarikan "out" diproses di lapisan eksekusi, dan pemberi jamin menerima ETH mereka.
Meskipun deposito adalah operasi yang dipicu di blok Eth1, kemudian 'bergerak' ke lapisan tanda dalam antrian deposito 'tertunda', penarikan mengikuti skema yang berbeda. Mereka dipicu di lapisan tanda (melalui CLI), lalu 'bergerak' ke blok Eth1. Saat ini, kedua skema akan beroperasi melalui kerangka umum yang sama (seperti yang dijelaskan di bawah): buat permintaan di lapisan Eth1, proses antrean 'tertunda' deposito/penarikan/gabungan, dan proses di lapisan tanda. Untuk operasi 'output' seperti penarikan, antrian output juga akan diproses, dengan hasil 'diselesaikan' di blok Eth1.
Dengan EIP ini, para penjamin dapat menggunakan transaksi ETH biasa untuk menarik dan mengeluarkan penjamin mereka tanpa perlu berinteraksi langsung dengan CLI penjamin atau mengakses infrastruktur penjamin. Ini sangat menyederhanakan operasi penjamin, terutama bagi penyedia penjamin besar. Infrastruktur penjamin sekarang dapat sepenuhnya terisolasi karena hanya perlu memelihara kunci penjamin yang aktif, sementara semua operasi penjamin dapat ditangani di tempat lain. Ini menghilangkan kebutuhan bagi penjamin independen untuk menunggu tindakan penjamin yang aktif, dan secara signifikan menyederhanakan bagian luar rantai seperti Modul Penjamin Komunitas seperti layanan Lido.
Oleh karena itu, EIP ini 'menyelesaikan' operasi pengepakan sepenuhnya dan memindahkannya ke lapisan Eth1, secara signifikan mengurangi risiko keamanan infrastruktur dan meningkatkan desentralisasi inisiatif pengepakan yang independen.
EIP-6110: Menyediakan Deposit Verifier On-Chain
Referensi: EIP-6110
Saat ini, deposit dilakukan melalui peristiwa dalam kontrak 'deposit' sistem (seperti yang dibahas secara rinci dalam artikel sebelumnya). Kontrak menerima ETH dan bukti validator, menghasilkan peristiwa 'Deposit()', peristiwa tersebut kemudian diurai dan diubah menjadi permintaan deposit di lapisan beacon. Sistem ini memiliki banyak kekurangan: itu memerlukan voting pada eth1data lapisan beacon, yang menambahkan keterlambatan yang signifikan. Selain itu, lapisan beacon perlu melakukan querying pada lapisan eksekusi, yang lebih lanjut meningkatkan kompleksitas. Masalah-masalah ini dibahas secara rinci dalam EIP. Salah satu cara yang lebih sederhana, tanpa harus menangani banyak masalah ini, adalah dengan langsung menyertakan permintaan deposit di blok Eth1 pada lokasi yang ditentukan. Mekanisme ini mirip dengan proses penarikan yang dijelaskan dalam EIP sebelumnya.
Perubahan yang diusulkan dalam EIP ini sangat menjanjikan. Penanganan eth1data sekarang dapat sepenuhnya dihapus, tidak perlu lagi memvoting atau menunda waktu yang lama antara peristiwa di sisi Eth1 dan deposit di lapisan beacon (saat ini sekitar 12 jam). Ini juga menghapus logika snapshot kontrak deposit. EIP ini menyederhanakan penanganan deposit dan membuatnya sejajar dengan skema penarikan di atas.
Bagi para penyetor dan validator, perubahan-perubahan ini secara signifikan mengurangi keterlambatan antara deposit dan aktivasi validator. Ketika validator dipotong, tambahan yang diperlukan juga akan lebih cepat.
Tidak ada yang perlu dikatakan lebih lanjut tentang EIP ini, kecuali bahwa itu menghapus logika yang sudah ketinggalan zaman, menyederhanakan proses, dan menciptakan hasil yang lebih baik untuk semua pihak terkait.
EIP-7685: Permintaan Lapisan Eksekusi Universal
Referensi: EIP-7685
EIP ini seharusnya diajukan sebelum tiga EIP terkait deposito/penarikan/gabungan pertama, karena ini merupakan dasar bagi EIP tersebut. Namun, pengantarannya di sini bertujuan untuk menekankan kebutuhan akan pertumbuhan data khusus yang konsisten antara blok (lapisan) Eth1 (eksekusi) dan beacon (konsensus). EIP ini memengaruhi dua lapisan, membuat pemrosesan permintaan yang dipicu oleh transaksi ETH reguler menjadi lebih efisien. Saat ini, kita dapat mengamati:
Kejadian deposit dalam blok Eth1 'dipindahkan' ke blok penanda untuk diproses.
Permintaan penarikan dalam blok penanda telah "dipindahkan" ke blok Eth1 untuk diproses.
beacon.
Tiga tindakan ini menunjukkan perlunya penanganan yang konsisten dari berbagai jenis permintaan saat beralih antara lapisan pelaksanaan dan lapisan penanda. Selain itu, kami perlu memiliki kemampuan untuk memicu tindakan-tindakan ini hanya menggunakan lapisan Eth1, karena ini akan memungkinkan kami memisahkan infrastruktur validator dari infrastruktur manajemen staking untuk meningkatkan keamanan. Oleh karena itu, solusi umum untuk mengelola jenis permintaan ini adalah praktis dan diperlukan.
EIP ini membentuk kerangka kerja untuk setidaknya tiga situasi utama: deposit, penarikan, dan konsolidasi. Itulah mengapa EIP awal memperkenalkan bidang seperti WITHDRAWAL_REQUEST_TYPE dan DEPOSIT_REQUEST_TYPE, sekarang konsolidasi akan menambahkan bidang lain, yaitu CONSOLIDATION_REQUEST_TYPE. Selain itu, EIP ini juga mungkin mencakup mekanisme umum untuk membatasi penanganan permintaan semacam ini (lihat konstanta: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Meskipun rincian implementasi kerangka kerja ini masih tidak tersedia, namun pasti akan mencakup jenis permintaan kunci, mekanisme integritas (misalnya, permintaan hash dan merkleisasi) serta antrian penanganan dan pembatasan laju yang akan ditangani.
EIP ini memiliki makna arsitektur yang memungkinkan Eth1 untuk memicu operasi kunci di lapisan beacon melalui kerangka yang terpadu. Bagi pengguna akhir dan proyek, ini berarti bahwa semua permintaan yang dipicu di lapisan Eth1 akan disampaikan dan ditangani dengan lebih efisien di lapisan beacon.
EIP-2537: Prekompilasi Operasi Kurva BLS12-381
Referensi: EIP-2537
Jika Anda tidak ingin memahaminya secara mendalam, Anda dapat menganggap pra-kompilasi BLS12-381 sebagai operasi enkripsi 'hash' yang kompleks yang sekarang dapat digunakan dalam kontrak pintar. Untuk mereka yang tertarik, mari kita jelajahi lebih lanjut.
Operasi matematika yang dilakukan pada kurva eliptik seperti BLS12-381 (dan BN-254 yang sesuai) saat ini digunakan untuk dua tujuan utama:
Tanda tangan BLS, di mana 'pairing' khusus digunakan untuk memverifikasi tanda tangan ini. Tanda tangan BLS sangat digunakan oleh pemeriksa karena mereka menggabungkan beberapa tanda tangan menjadi satu. Pemeriksa bergantung pada tanda tangan BLS berdasarkan kurva BLS12-381 (meskipun mereka juga dapat menggunakan kurva lain yang mendukung 'pairing', seperti BN254).
Verifikasi bukti zkSNARK, di mana pasangan digunakan untuk memverifikasi bukti. Selain itu, komitmen KZG untuk blok besar yang diperkenalkan oleh hard fork Dencun juga menggunakan pasangan untuk memverifikasi komitmen blok.
Jika Anda ingin memverifikasi tanda tangan BLS atau bukti zkSNARK dalam kontrak pintar, Anda harus menghitung "pasangan" ini, yang secara komputasi sangat mahal. Ethereum sudah memiliki kontrak yang telah dikompilasi sebelumnya (EIP-196 dan EIP-197) untuk operasi kurva BN254. Namun, kurva BLS12-381 (yang sekarang dianggap lebih aman dan lebih banyak digunakan saat ini) belum diimplementasikan seperti yang telah dikompilasi sebelumnya. Dengan tidak adanya prakompilasi seperti itu, menerapkan pasangan dan operasi kurva lainnya dalam kontrak pintar membutuhkan banyak perhitungan, seperti yang ditunjukkan di sini, dan mengkonsumsi sejumlah besar gas (sekitar ~ 10 ^ 5 hingga 10 ^ 6 gas).
EIP ini membuka pintu bagi banyak aplikasi potensial, terutama dalam verifikasi tanda tangan BLS yang murah berdasarkan kurva BLS12-381. Ini memungkinkan skema ambang batas untuk mewujudkan berbagai tujuan. Seperti yang disebutkan sebelumnya, validator Ethereum telah menggunakan tanda tangan berbasis BLS12-381. Melalui EIP ini, kontrak cerdas standar sekarang dapat dengan efisien memverifikasi tanda tangan validator yang diagregasi. Ini dapat menyederhanakan pembuktian konsensus dan jembatan aset lintas-jaringan, karena tanda tangan BLS banyak digunakan di blockchain. Tanda tangan BLS ambang batas itu sendiri memungkinkan konstruksi banyak skema ambang batas yang efisien, digunakan untuk pemungutan suara, pembangkitan nomor acak terdesentralisasi, multisig, dan lain-lain.
Verifikasi bukti zkSNARK yang lebih murah akan membuka banyak aplikasi. Banyak solusi berbasis zkSNARK saat ini terhambat oleh biaya verifikasi yang tinggi, yang membuat beberapa proyek hampir tidak praktis. EIP ini berpotensi mengubah hal ini.
EIP-2935：Menyimpan Hash Blok Historis di dalam Status
Referensi: EIP-2935
Usulan EIP ini menyarankan untuk menyimpan 8192 (sekitar 27,3 jam) hash blok historis dalam status blockchain, untuk memperluas sejarah bagi klien tanpa status (seperti rollup) dan kontrak pintar. Ini mengusulkan untuk mempertahankan perilaku opcode BLOCKHASH saat ini, mempertahankan batasan 256 blok, sambil memperkenalkan kontrak sistem baru yang dirancang khusus untuk menyimpan dan mengakses hash historis. Kontrak ini melakukan operasi set() saat memproses blok di lapisan eksekusi. Metodenya get() dapat diakses oleh siapa pun untuk mengambil hash blok yang diperlukan dari buffer lingkaran.
Saat ini, mengacu pada hash blok historis dalam EVM memungkinkan, tetapi akses terbatas hanya pada 256 blok terakhir (sekitar 50 menit). Namun, dalam beberapa kasus, akses ke data blok yang lebih lama sangat penting, terutama untuk aplikasi lintas rantai (yang memerlukan bukti data blok sebelumnya) dan klien tanpa keadaan, yang secara teratur membutuhkan akses ke hash blok sebelumnya.
EIP ini memperluas rentang waktu yang tersedia untuk rollup dan aplikasi lintas rantai, memungkinkan mereka mengakses data historis secara langsung di EVM tanpa perlu mengumpulkannya secara eksternal. Oleh karena itu, solusi-solusi ini menjadi lebih stabil dan berkelanjutan.
EIP-7623: Menambahkan biaya calldata
Referensi: EIP-7623
calldata mengatur ukuran payload transaksi yang tersedia, yang dalam beberapa kasus dapat sangat besar (misalnya, saat mentransfer array besar atau buffer biner sebagai parameter). Penggunaan calldata yang signifikan terutama disebabkan oleh rollup, yang mengirimkan payload transaksi melalui calldata yang berisi status rollup saat ini.
Memperkenalkan data biner yang besar dan dapat diverifikasi ke dalam blockchain sangat penting bagi rollup. Pembaruan Dencun (Deneb-Cancun) memperkenalkan inovasi penting ini untuk kasus penggunaan semacam ini - transaksi blob (EIP-4844). Transaksi blob memiliki biaya gas 'blob' khususnya, meskipun tubuhnya disimpan sementara, tetapi bukti enkripsi (komitmen KZG) beserta hash-nya diintegrasikan ke lapisan konsensus. Oleh karena itu, dibandingkan dengan penyimpanan data menggunakan calldata, blob menyediakan solusi yang lebih baik untuk rollup.
Mendorong rollup untuk memindahkan datanya ke blob dapat dicapai melalui metode 'tongkat wortel'. Biaya gas blob yang lebih rendah berfungsi sebagai 'wortel', sementara EIP ini menekan penyimpanan data yang berlebihan dalam transaksi dengan meningkatkan biaya calldata sebagai 'pengungkit'. EIP ini melengkapi EIP-7691 (Peningkatan Kapasitas Blob), yang meningkatkan jumlah maksimum blob yang diizinkan setiap blok.
EIP-7691: peningkatan throughput blob
Referensi: EIP-7691
Pada hard fork Dencun sebelumnya, blob diperkenalkan, dan nilai awal jumlah maksimum dan target blob 'per blok' adalah perkiraan yang konservatif. Ini dikarenakan kompleksitas bagaimana jaringan p2p akan menangani penyebaran objek biner besar di antara node validator. Konfigurasi sebelumnya terbukti baik, dan saat ini merupakan waktu yang tepat untuk menguji nilai baru. Sebelumnya, jumlah target/maksimum blob per blok disetel menjadi 3/6. Batasan-batasan ini sekarang ditingkatkan menjadi 6/9.
Gabungan dengan EIP-7623 sebelumnya (meningkatkan biaya calldata), penyesuaian ini lebih mendorong rollup untuk memindahkan datanya dari calldata ke blob. Pekerjaan mencari parameter blob terbaik masih berlanjut.
EIP-7840: Menambahkan penjadwalan blob ke file konfigurasi EL
Referensi: EIP-7840
Usulan EIP ini menambahkan target dan jumlah blob maksimum 'per blok' (yang telah dibahas sebelumnya) serta 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 seperti memperkirakan biaya gas blob.
EIP-7702: Mengatur Kode Akun EOA
Referensi: EIP-7702
Ini adalah EIP yang sangat penting, yang akan membawa perubahan besar bagi pengguna Ethereum. Seperti yang kita ketahui, EOA (External Owned Account) tidak dapat memiliki kode apa pun, tetapi dapat menyediakan tanda tangan transaksi (tx.origin). Di sisi lain, kontrak pintar memiliki bytecode, tetapi tidak dapat secara aktif memberikan tanda tangan 'nya' sendiri. Setiap interaksi pengguna yang memerlukan logika tambahan, otomatis, dan dapat diverifikasi saat ini hanya dapat dilakukan dengan memanggil kontrak eksternal untuk melakukan operasi yang diperlukan. Namun, dalam situasi ini, kontrak eksternal menjadi msg.sender dari kontrak berikutnya, sehingga memanggil 'dari panggilan kontrak, bukan pengguna'.
EIP ini memperkenalkan jenis transaksi SET_CODE_TX_TYPE=0x04 baru (kami memiliki transaksi 0x1 lama sebelumnya, transaksi 0x02 baru dari Berlin dan peningkatan EIP-1559, dan transaksi blob 0x03 yang diperkenalkan di Dencun). Jenis perdagangan baru ini memungkinkan Anda mengatur kode untuk akun EOA. Akibatnya, ini memungkinkan EOA untuk mengeksekusi kode eksternal "dalam konteks akun EOA-nya sendiri". Dari perspektif luar, EOA tampaknya "meminjam" kode dari kontrak eksternal dan menjalankannya selama transaksi. Secara teknis, ini dilakukan dengan menambahkan tupel data otorisasi khusus ke penyimpanan "kode" alamat EOA (sampai EIP ini, penyimpanan "kode" ini selalu kosong ke EOA).
Saat ini, jenis transaksi 0x04 baru yang diusulkan dalam EIP ini berisi sebuah array:
Setiap elemen memungkinkan akun menggunakan kode dari alamat yang ditentukan (dari item otorisasi terakhir yang valid). Saat memproses transaksi semacam itu, kode EOA yang diberikan diatur ke nilai alamat khusus 0xef0100 || (23 byte), di mana alamat menunjuk ke kontrak dengan kode yang diperlukan, || mewakili penggabungan, dan 0xef0100 mewakili nilai sihir khusus yang tidak dapat dimasukkan ke dalam kontrak cerdas biasa (berdasarkan EIP-3541). Nilai sihir ini memastikan bahwa EOA ini tidak dapat dianggap sebagai kontrak biasa dan tidak dapat dipanggil seperti kontrak biasa.
Ketika EOA ini menginisiasi transaksi, alamat yang ditentukan akan digunakan untuk memanggil kode yang sesuai dalam konteks EOA tersebut. Meskipun detail implementasi lengkap dari EIP ini masih belum jelas, namun dapat dipastikan akan membawa perubahan signifikan.
Salah satu dampak utamanya adalah kemampuan untuk melakukan panggilan ganda (multicall) langsung dari EOA. Panggilan ganda merupakan tren berkelanjutan dalam DeFi, dengan banyak protokol menyediakan fitur ini sebagai alat yang kuat (misalnya Uniswap V4, Balancer V3, atau Euler V2). Dengan adanya EIP ini, sekarang dapat langsung melakukan panggilan ganda dari EOA.
Misalnya, fitur baru ini mengatasi masalah umum dalam DeFi: keefisienan dua transaksi terpisah untuk approve() + anything(). EIP ini memungkinkan logika 'prapersetujuan' yang umum, sehingga seperti approve(X) + deposit(X) dapat diselesaikan dalam satu transaksi.
Salah satu keuntungan lain dari mampu 'mewakili' transaksi yang didelegasikan oleh EOA adalah konsep sponsor. Sponsor adalah fitur yang sering dibahas dan sangat diinginkan untuk membantu pengguna baru masuk ke Ethereum.
Logika yang dapat diprogram yang terkait dengan EOA membuka banyak kemungkinan, seperti menerapkan pembatasan keamanan, mengatur batas pengeluaran, memaksa persyaratan KYC, dll.
Tentu saja, pergeseran ini juga menimbulkan sejumlah pertanyaan desain. Salah satu masalah adalah penggunaan chain_id, yang menentukan apakah tanda tangan yang sama dapat valid di beberapa jaringan, tergantung pada apakah itu disertakan atau tidak termasuk dalam tanda tangan. Komplikasi lain adalah pilihan antara menggunakan alamat kode objek dan menyematkan bytecode yang sebenarnya. Kedua metode memiliki fitur dan keterbatasan unik mereka sendiri. Selain itu, penggunaan nonce memainkan peran kunci dalam menentukan apakah izin adalah "multi-tujuan" atau "tujuan tunggal". Elemen-elemen ini memengaruhi fungsionalitas dan masalah keamanan, termasuk aspek-aspek seperti tanda tangan pembatalan massal dan kemudahan penggunaan. Vitalik mengangkat pertanyaan-pertanyaan ini dalam diskusi (di sini) yang perlu ditelusuri lebih lanjut.
Perlu diperhatikan bahwa perubahan ini akan mempengaruhi mekanisme keamanan Ethereum, tx.origin. Lebih banyak detail tentang implementasi EIP ini diperlukan, tetapi tampaknya perilaku require(tx.origin == msg.sender) akan berubah. Pemeriksaan ini selalu menjadi metode yang paling dapat diandalkan untuk memastikan bahwa msg.sender adalah EOA, bukan kontrak. Metode lain, seperti pemeriksaan EXTCODESIZE (untuk memeriksa apakah itu adalah kontrak), sering kali gagal dan dapat dihindari (misalnya, dengan memanggil konstruktor atau dengan mendeploy kode ke alamat yang telah ditentukan sebelumnya setelah transaksi). Pemeriksaan ini digunakan untuk mencegah serangan reentrancy dan flash loan, tetapi jauh dari ideal karena juga menghambat integrasi dengan protokol eksternal. Setelah EIP ini, bahkan pemeriksaan yang dapat diandalkan require(tx.origin == msg.sender) tampaknya menjadi usang. Protokol harus beradaptasi dengan cara menghapus pemeriksaan ini karena perbedaan antara 'EOA' dan 'kontrak' tidak lagi berlaku - sekarang setiap alamat dapat memiliki kode yang terkait.
Pemisahan tradisional antara EOA dan kontrak pintar terus kabur. EIP ini membuat Ethereum lebih dekat dengan desain seperti TON, di mana setiap akun pada dasarnya adalah kode yang dapat dieksekusi. Seiring interaksi dengan protokol menjadi semakin kompleks, menggunakan logika yang dapat diprogram untuk meningkatkan pengalaman pengguna akhir adalah evolusi alami dari proses ini.
Kesimpulan
Peningkatan Praha / Electra (Pectra) dijadwalkan pada Maret 2025. Perubahan rencana yang paling signifikan termasuk:
Validasi variabel pemangku saham, dengan jumlah maksimal hingga 2048 ETH, akan mengubah secara signifikan distribusi pemangku saham, jadwal pemangku saham, dan menyederhanakan manajemen penyedia pemangku saham besar dengan mengintegrasikan pemangku saham yang lebih kecil.
Memperbaiki interaksi antara lapisan eksekusi dan lapisan konsensus, menyederhanakan pertukaran data antara blok eksekusi Eth1 dan blok rantai tanda. Ini akan sangat menyederhanakan proses deposit, aktivasi, penarikan, dan penarikan, mempercepat proses ini dan membentuk dasar untuk interaksi lebih lanjut antara lapisan konsensus dan lapisan eksekusi.
Dalam kontrak pintar, dukung tanda tangan BLS yang lebih murah dan verifikasi zkSNARK langsung melalui pra-kompilasi 'pairing-friendly' baru BLS12-381
Mendorong Rollups untuk mengadopsi transaksi blob dengan meningkatkan ambang batas transaksi blob dan biaya calldata
Membuat EOA berperan sebagai akun yang dapat diprogram, memberinya kemampuan untuk pemanggilan ganda, penjaminan, dan fitur canggih lainnya
Seperti yang Anda lihat, Pectra akan memiliki dampak besar pada pengalaman pengguna akhir dari lapisan staking dan konsensus, serta lapisan eksekusi. Meskipun kami tidak dapat secara rinci menganalisis semua perubahan ini melalui kode pada tahap ini karena pengembangan masih berlangsung, kami akan mencakup pembaruan ini dalam artikel di masa depan.
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Menganalisis Hard Fork Ethereum yang akan datang - Upgrade Pectra
Pengenalan
Dalam artikel sebelumnya, kami secara rinci mengulas siklus hidup validator Ethereum dan membahas berbagai aspek terkait hard fork Electra yang akan datang. Sekarang, saatnya fokus pada perubahan yang akan datang dalam upgrade Electra dan Prague, dan menjelaskannya secara detail.
Sejarah hard fork 'proof of stake' Ethereum 2.0 sangat kompleks. Dimulai dengan menambahkan lapisan sinyal ke lapisan eksekusi yang ada, di mana konsensus proof of stake diluncurkan di lapisan sinyal sementara lapisan eksekusi tetap menggunakan proof of work (hard fork Phase0 dan Altair). Kemudian, dalam hard fork Bellatrix, proof of stake diaktifkan sepenuhnya (meskipun penarikan belum diaktifkan). Selanjutnya, hard fork Capella mengizinkan penarikan, menyelesaikan siklus hidup validator. Hard fork terbaru, Deneb (bagian dari upgrade Dencun (Deneb/Cancun)), membuat revisi kecil pada parameter rantai sinyal, seperti jendela waktu bukti, penanganan keluarnya sukarela, dan pembatasan pergantian validator. Perubahan utama dalam Dencun terjadi dalam lapisan eksekusi, dengan diperkenalkannya transaksi blob, gas blob, KZG commitment untuk blob, dan pembuangan operasi SELFDESTRUCT.
Sekarang, hard fork Prague/Electra (dikenal juga sebagai Pectra) menghadirkan pembaruan penting untuk lapisan eksekusi dan konsensus. Sebagai pemeriksa proyek Lido, kami secara khusus memperhatikan perubahan terkait konsensus dan staking dalam hard fork ini. Namun, kami tidak dapat mengabaikan perubahan lapisan eksekusi dalam Prague karena termasuk fitur-fitur penting yang memengaruhi jaringan Ethereum dan validator. Mari kita telusuri detail perubahan ini.
Gambaran Tingkat Lebih Tinggi Pectra
Electra telah memperkenalkan banyak fitur ke lapisan sinyal. Pembaruan utama termasuk:
Sementara itu, Prague mengenalkan perubahan berikut untuk tingkat pelaksanaan:
Mari kita lihat (EIP) Proposal Peningkatan Ethereum yang relevan untuk diskusi lebih lanjut:
Beberapa EIP ini terutama terkait dengan lapisan konsensus (beacon), sedangkan yang lain terkait dengan lapisan eksekusi. Beberapa melintasi kedua lapisan tersebut karena beberapa operasi (seperti deposit dan penarikan) memerlukan perubahan sinkronisasi antara lapisan konsensus dan eksekusi. Karena saling ketergantungan ini, memisahkan Electra dan Prague tidak praktis, oleh karena itu kita akan melihat setiap EIP secara berurutan dan menentukan komponen Ethereum yang terpengaruh dalam setiap kasus.
EIP-7251: Menambahkan MAX_EFFECTIVE_BALANCE
Referensi: EIP-7251
Sejak hard fork Phase0 pertama, untuk mempersiapkan bukti kepemilikan Ethereum, hingga Electra, saldo maksimum yang valid untuk validator tetap pada 32 ETH. Untuk mengaktifkan validator, setidaknya diperlukan saldo aktivasi minimum (32 ETH). Setelah diaktifkan, validator memulai dengan saldo maksimum ini, namun dapat mengurangi saldo validitasnya hingga saldo ejeksi (16 ETH), dan akan diusir ketika mencapai ambang batas tersebut. Logika "minimal" ini tetap tidak berubah dalam Electra, tetapi sekarang saldo maksimum yang efektif telah ditingkatkan menjadi 2048 ETH. Oleh karena itu, validator dapat melakukan deposito antara 32 hingga 2048 ETH untuk mengaktifkan, dan semua jumlah ini akan berkontribusi pada saldo validitasnya. Perubahan ini menandai transisi dari "32ETH-Proof of Stake" ke "Proof of Stake" :)
Saldo efektif yang dapat berubah ini sekarang akan digunakan untuk:
Kegiatan pertama adalah operasi paling menguntungkan bagi validator. Oleh karena itu, setelah Electra, validator dengan staking besar akan lebih sering terlibat dalam proposal blok dan komite sinkronisasi, dengan frekuensi sebanding dengan saldo efektif mereka.
Pengaruh lainnya terkait dengan pemotongan. Semua pemotongan denda sebanding dengan saldo efektif validator:
Electra juga mengusulkan perubahan pada rasio pemotongan, mendefinisikan bagian dari saldo validator yang dipotong dan diterima oleh pelapor.
Selanjutnya adalah dampak ketidakefektifan. Ketika validator tidak aktif (membuktikan atau mengusulkan) saat aktif, skor ketidakefektifan akan terakumulasi, mengakibatkan hukuman ketidakefektifan diberlakukan setiap periode. Hukuman ini juga berhubungan dengan saldo efektif validator dalam proporsi.
Karena peningkatan saldo efektif, "batas penggantian" untuk validator juga telah berubah. Dalam Ethereum "pra-Electra", validator biasanya memiliki saldo efektif yang sama, dan batas penggantian keluar didefinisikan sebagai "tidak lebih dari 1/65536 (spec.churn_limit_quotient) dari total taruhan dapat keluar dalam satu siklus." Ini menciptakan jumlah validator "tetap" dengan taruhan yang sama untuk keluar. Namun, setelah "Electra", ada kemungkinan bahwa hanya beberapa "paus" yang akan keluar, karena mereka mewakili bagian penting dari total saham.
Pertimbangan lain adalah rotasi kunci validator yang banyak pada satu instansi validator tunggal. Validator besar saat ini terpaksa menjalankan ribuan kunci validator pada satu instansi untuk menyesuaikan dengan jumlah staking besar, membaginya menjadi bagian 32 ETH. Dengan Electra, perilaku ini tidak lagi menjadi wajib. Dari segi keuangan, perubahan ini tidak terlalu berpengaruh karena imbalan dan probabilitas berkorelasi secara linear dengan jumlah staking. Oleh karena itu, 100 validator dengan masing-masing 32 ETH setara dengan satu validator 3200 ETH. Selain itu, beberapa kunci validator aktif dapat memiliki tanda terima Eth1 yang sama, memungkinkan semua imbalan ditarik ke satu alamat ETH tunggal, sehingga menghindari biaya gas yang terkait dengan penggabungan imbalan. Namun, mengelola banyak kunci akan menimbulkan biaya pengelolaan tambahan.
Kemampuan saldo validator agregat telah ditambahkan dengan jenis permintaan eksekusi baru. Sebelumnya, kami memiliki setoran dan penarikan. Sekarang, akan ada jenis lain: permintaan agregat. Ini menggabungkan dua validator menjadi satu. Permintaan operasi ini akan mencakup kunci publik validator sumber dan kunci publik tujuan, dan akan ditangani seperti setoran dan penarikan. Agregasi juga akan memiliki batasan permintaan tertunda dan penggantian saldo, seperti setoran dan penarikan.
Ringkasan sebagai berikut:
Salah satu topik penting lainnya adalah data historis dan estimasi keuntungan validator, yang sangat relevan bagi peserta baru yang mencoba mengevaluasi risiko dan imbal hasil. Sebelum Electra (pada saat penulisan ini), batas atas 32 ETH (baik minimum maupun maksimum) menciptakan keseragaman dalam data historis. Saldo efektif, imbalan, hukuman pengurangan individu, frekuensi proposal blok, dan indikator lainnya bagi semua validator adalah sama. Keseragaman ini memungkinkan Ethereum untuk menguji mekanisme konsensusnya tanpa adanya nilai anomali statistik, sehingga mengumpulkan data perilaku jaringan yang berharga.
Setelah Electra, akan ada perubahan signifikan dalam distribusi staking. Validator besar akan lebih sering berpartisipasi dalam proposal blok dan komite sinkronisasi, menghadapi hukuman yang lebih besar dalam acara pemotongan, dan memiliki dampak yang lebih besar pada pemotongan yang tertunda, antrean aktivasi, dan antrian 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 untuk semua validator. Ini berarti bahwa hadiah dan garis miring validator masih dapat diperkirakan berdasarkan "per 1 ETH" (atau lebih tepatnya, berdasarkan spec.effective_balance_increment, yang dapat berubah di masa mendatang).
Untuk informasi lebih lanjut, silakan lihat artikel kami sebelumnya tentang perilaku validator.
EIP-7002: Keluaran Lapisan Eksekusi yang Dapat Dipicu
Referensi: EIP-7002
Setiap validator di Ethereum memiliki dua pasang kunci: kunci aktif dan kunci penarikan. Kunci publik BLS aktif berfungsi sebagai identitas utama validator di rantai pancang, dan pasangan kunci ini digunakan untuk menandatangani blok, bukti, pemangkasan, sinkronisasi komite agregat, dan (sebelum EIP ini) keluar sukarela (untuk konsensus validator yang keluar setelah penundaan). Pasangan kunci kedua ("tanda terima penarikan") dapat berupa pasangan kunci BLS lainnya atau akun Eth1 konvensional (kunci privat dan alamat). Sekarang, penarikan ke alamat ETH memerlukan pesan penarikan yang ditandatangani oleh kunci privat BLS aktif. EIP ini telah mengalami perubahan.
Faktanya, pemilik kedua pasangan kunci (aktif dan penarikan) ini bisa berbeda. Kunci aktif validator bertanggung jawab atas tugas verifikasi: menjalankan server, menjaganya tetap aktif dan berjalan, dll., Sementara kredensial penarikan biasanya dikendalikan oleh pemilik saham, yang menerima hadiah dan bertanggung jawab atas dana tersebut. Saat ini, hanya pemilik saham yang mengontrol kredensial penarikan yang tidak dapat memulai penarikan validator dan hanya dapat menarik hadiah. Situasi ini memungkinkan pemilik kunci aktif validator untuk secara efektif menahan saldo validator sebagai "sandera". Validator dapat "menandatangani" pesan keluar dan menyerahkannya kepada pemilik pasak, tetapi solusi ini tidak ideal. Selain itu, ekstraksi dan penarikan saat ini memerlukan interaksi dengan validator lapisan suar melalui API khusus.
Solusi terbaik adalah memungkinkan pemilik jaminan untuk melakukan penarikan dan pencairan secara bersamaan melalui kontrak pintar konvensional. Ini melibatkan pemeriksaan tanda tangan Eth1 standar, yang sangat menyederhanakan operasi.
EIP ini memungkinkan pemegang staking untuk memicu penarikan dan penarikan (mirip dengan proses deposit menggunakan kontrak "deposit" yang ada) dengan mengirimkan transaksi standar dari alamat ETH mereka ke kontrak pintar khusus.
Meskipun deposito adalah operasi yang dipicu di blok Eth1, kemudian 'bergerak' ke lapisan tanda dalam antrian deposito 'tertunda', penarikan mengikuti skema yang berbeda. Mereka dipicu di lapisan tanda (melalui CLI), lalu 'bergerak' ke blok Eth1. Saat ini, kedua skema akan beroperasi melalui kerangka umum yang sama (seperti yang dijelaskan di bawah): buat permintaan di lapisan Eth1, proses antrean 'tertunda' deposito/penarikan/gabungan, dan proses di lapisan tanda. Untuk operasi 'output' seperti penarikan, antrian output juga akan diproses, dengan hasil 'diselesaikan' di blok Eth1.
Dengan EIP ini, para penjamin dapat menggunakan transaksi ETH biasa untuk menarik dan mengeluarkan penjamin mereka tanpa perlu berinteraksi langsung dengan CLI penjamin atau mengakses infrastruktur penjamin. Ini sangat menyederhanakan operasi penjamin, terutama bagi penyedia penjamin besar. Infrastruktur penjamin sekarang dapat sepenuhnya terisolasi karena hanya perlu memelihara kunci penjamin yang aktif, sementara semua operasi penjamin dapat ditangani di tempat lain. Ini menghilangkan kebutuhan bagi penjamin independen untuk menunggu tindakan penjamin yang aktif, dan secara signifikan menyederhanakan bagian luar rantai seperti Modul Penjamin Komunitas seperti layanan Lido.
Oleh karena itu, EIP ini 'menyelesaikan' operasi pengepakan sepenuhnya dan memindahkannya ke lapisan Eth1, secara signifikan mengurangi risiko keamanan infrastruktur dan meningkatkan desentralisasi inisiatif pengepakan yang independen.
EIP-6110: Menyediakan Deposit Verifier On-Chain
Referensi: EIP-6110
Saat ini, deposit dilakukan melalui peristiwa dalam kontrak 'deposit' sistem (seperti yang dibahas secara rinci dalam artikel sebelumnya). Kontrak menerima ETH dan bukti validator, menghasilkan peristiwa 'Deposit()', peristiwa tersebut kemudian diurai dan diubah menjadi permintaan deposit di lapisan beacon. Sistem ini memiliki banyak kekurangan: itu memerlukan voting pada eth1data lapisan beacon, yang menambahkan keterlambatan yang signifikan. Selain itu, lapisan beacon perlu melakukan querying pada lapisan eksekusi, yang lebih lanjut meningkatkan kompleksitas. Masalah-masalah ini dibahas secara rinci dalam EIP. Salah satu cara yang lebih sederhana, tanpa harus menangani banyak masalah ini, adalah dengan langsung menyertakan permintaan deposit di blok Eth1 pada lokasi yang ditentukan. Mekanisme ini mirip dengan proses penarikan yang dijelaskan dalam EIP sebelumnya.
Perubahan yang diusulkan dalam EIP ini sangat menjanjikan. Penanganan eth1data sekarang dapat sepenuhnya dihapus, tidak perlu lagi memvoting atau menunda waktu yang lama antara peristiwa di sisi Eth1 dan deposit di lapisan beacon (saat ini sekitar 12 jam). Ini juga menghapus logika snapshot kontrak deposit. EIP ini menyederhanakan penanganan deposit dan membuatnya sejajar dengan skema penarikan di atas.
Bagi para penyetor dan validator, perubahan-perubahan ini secara signifikan mengurangi keterlambatan antara deposit dan aktivasi validator. Ketika validator dipotong, tambahan yang diperlukan juga akan lebih cepat.
Tidak ada yang perlu dikatakan lebih lanjut tentang EIP ini, kecuali bahwa itu menghapus logika yang sudah ketinggalan zaman, menyederhanakan proses, dan menciptakan hasil yang lebih baik untuk semua pihak terkait.
EIP-7685: Permintaan Lapisan Eksekusi Universal
Referensi: EIP-7685
EIP ini seharusnya diajukan sebelum tiga EIP terkait deposito/penarikan/gabungan pertama, karena ini merupakan dasar bagi EIP tersebut. Namun, pengantarannya di sini bertujuan untuk menekankan kebutuhan akan pertumbuhan data khusus yang konsisten antara blok (lapisan) Eth1 (eksekusi) dan beacon (konsensus). EIP ini memengaruhi dua lapisan, membuat pemrosesan permintaan yang dipicu oleh transaksi ETH reguler menjadi lebih efisien. Saat ini, kita dapat mengamati:
Tiga tindakan ini menunjukkan perlunya penanganan yang konsisten dari berbagai jenis permintaan saat beralih antara lapisan pelaksanaan dan lapisan penanda. Selain itu, kami perlu memiliki kemampuan untuk memicu tindakan-tindakan ini hanya menggunakan lapisan Eth1, karena ini akan memungkinkan kami memisahkan infrastruktur validator dari infrastruktur manajemen staking untuk meningkatkan keamanan. Oleh karena itu, solusi umum untuk mengelola jenis permintaan ini adalah praktis dan diperlukan.
EIP ini membentuk kerangka kerja untuk setidaknya tiga situasi utama: deposit, penarikan, dan konsolidasi. Itulah mengapa EIP awal memperkenalkan bidang seperti WITHDRAWAL_REQUEST_TYPE dan DEPOSIT_REQUEST_TYPE, sekarang konsolidasi akan menambahkan bidang lain, yaitu CONSOLIDATION_REQUEST_TYPE. Selain itu, EIP ini juga mungkin mencakup mekanisme umum untuk membatasi penanganan permintaan semacam ini (lihat konstanta: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Meskipun rincian implementasi kerangka kerja ini masih tidak tersedia, namun pasti akan mencakup jenis permintaan kunci, mekanisme integritas (misalnya, permintaan hash dan merkleisasi) serta antrian penanganan dan pembatasan laju yang akan ditangani.
EIP ini memiliki makna arsitektur yang memungkinkan Eth1 untuk memicu operasi kunci di lapisan beacon melalui kerangka yang terpadu. Bagi pengguna akhir dan proyek, ini berarti bahwa semua permintaan yang dipicu di lapisan Eth1 akan disampaikan dan ditangani dengan lebih efisien di lapisan beacon.
EIP-2537: Prekompilasi Operasi Kurva BLS12-381
Referensi: EIP-2537
Jika Anda tidak ingin memahaminya secara mendalam, Anda dapat menganggap pra-kompilasi BLS12-381 sebagai operasi enkripsi 'hash' yang kompleks yang sekarang dapat digunakan dalam kontrak pintar. Untuk mereka yang tertarik, mari kita jelajahi lebih lanjut.
Operasi matematika yang dilakukan pada kurva eliptik seperti BLS12-381 (dan BN-254 yang sesuai) saat ini digunakan untuk dua tujuan utama:
Jika Anda ingin memverifikasi tanda tangan BLS atau bukti zkSNARK dalam kontrak pintar, Anda harus menghitung "pasangan" ini, yang secara komputasi sangat mahal. Ethereum sudah memiliki kontrak yang telah dikompilasi sebelumnya (EIP-196 dan EIP-197) untuk operasi kurva BN254. Namun, kurva BLS12-381 (yang sekarang dianggap lebih aman dan lebih banyak digunakan saat ini) belum diimplementasikan seperti yang telah dikompilasi sebelumnya. Dengan tidak adanya prakompilasi seperti itu, menerapkan pasangan dan operasi kurva lainnya dalam kontrak pintar membutuhkan banyak perhitungan, seperti yang ditunjukkan di sini, dan mengkonsumsi sejumlah besar gas (sekitar ~ 10 ^ 5 hingga 10 ^ 6 gas).
EIP ini membuka pintu bagi banyak aplikasi potensial, terutama dalam verifikasi tanda tangan BLS yang murah berdasarkan kurva BLS12-381. Ini memungkinkan skema ambang batas untuk mewujudkan berbagai tujuan. Seperti yang disebutkan sebelumnya, validator Ethereum telah menggunakan tanda tangan berbasis BLS12-381. Melalui EIP ini, kontrak cerdas standar sekarang dapat dengan efisien memverifikasi tanda tangan validator yang diagregasi. Ini dapat menyederhanakan pembuktian konsensus dan jembatan aset lintas-jaringan, karena tanda tangan BLS banyak digunakan di blockchain. Tanda tangan BLS ambang batas itu sendiri memungkinkan konstruksi banyak skema ambang batas yang efisien, digunakan untuk pemungutan suara, pembangkitan nomor acak terdesentralisasi, multisig, dan lain-lain.
Verifikasi bukti zkSNARK yang lebih murah akan membuka banyak aplikasi. Banyak solusi berbasis zkSNARK saat ini terhambat oleh biaya verifikasi yang tinggi, yang membuat beberapa proyek hampir tidak praktis. EIP ini berpotensi mengubah hal ini.
EIP-2935：Menyimpan Hash Blok Historis di dalam Status
Referensi: EIP-2935
Usulan EIP ini menyarankan untuk menyimpan 8192 (sekitar 27,3 jam) hash blok historis dalam status blockchain, untuk memperluas sejarah bagi klien tanpa status (seperti rollup) dan kontrak pintar. Ini mengusulkan untuk mempertahankan perilaku opcode BLOCKHASH saat ini, mempertahankan batasan 256 blok, sambil memperkenalkan kontrak sistem baru yang dirancang khusus untuk menyimpan dan mengakses hash historis. Kontrak ini melakukan operasi set() saat memproses blok di lapisan eksekusi. Metodenya get() dapat diakses oleh siapa pun untuk mengambil hash blok yang diperlukan dari buffer lingkaran.
Saat ini, mengacu pada hash blok historis dalam EVM memungkinkan, tetapi akses terbatas hanya pada 256 blok terakhir (sekitar 50 menit). Namun, dalam beberapa kasus, akses ke data blok yang lebih lama sangat penting, terutama untuk aplikasi lintas rantai (yang memerlukan bukti data blok sebelumnya) dan klien tanpa keadaan, yang secara teratur membutuhkan akses ke hash blok sebelumnya.
EIP ini memperluas rentang waktu yang tersedia untuk rollup dan aplikasi lintas rantai, memungkinkan mereka mengakses data historis secara langsung di EVM tanpa perlu mengumpulkannya secara eksternal. Oleh karena itu, solusi-solusi ini menjadi lebih stabil dan berkelanjutan.
EIP-7623: Menambahkan biaya calldata
Referensi: EIP-7623
calldata mengatur ukuran payload transaksi yang tersedia, yang dalam beberapa kasus dapat sangat besar (misalnya, saat mentransfer array besar atau buffer biner sebagai parameter). Penggunaan calldata yang signifikan terutama disebabkan oleh rollup, yang mengirimkan payload transaksi melalui calldata yang berisi status rollup saat ini.
Memperkenalkan data biner yang besar dan dapat diverifikasi ke dalam blockchain sangat penting bagi rollup. Pembaruan Dencun (Deneb-Cancun) memperkenalkan inovasi penting ini untuk kasus penggunaan semacam ini - transaksi blob (EIP-4844). Transaksi blob memiliki biaya gas 'blob' khususnya, meskipun tubuhnya disimpan sementara, tetapi bukti enkripsi (komitmen KZG) beserta hash-nya diintegrasikan ke lapisan konsensus. Oleh karena itu, dibandingkan dengan penyimpanan data menggunakan calldata, blob menyediakan solusi yang lebih baik untuk rollup.
Mendorong rollup untuk memindahkan datanya ke blob dapat dicapai melalui metode 'tongkat wortel'. Biaya gas blob yang lebih rendah berfungsi sebagai 'wortel', sementara EIP ini menekan penyimpanan data yang berlebihan dalam transaksi dengan meningkatkan biaya calldata sebagai 'pengungkit'. EIP ini melengkapi EIP-7691 (Peningkatan Kapasitas Blob), yang meningkatkan jumlah maksimum blob yang diizinkan setiap blok.
EIP-7691: peningkatan throughput blob
Referensi: EIP-7691
Pada hard fork Dencun sebelumnya, blob diperkenalkan, dan nilai awal jumlah maksimum dan target blob 'per blok' adalah perkiraan yang konservatif. Ini dikarenakan kompleksitas bagaimana jaringan p2p akan menangani penyebaran objek biner besar di antara node validator. Konfigurasi sebelumnya terbukti baik, dan saat ini merupakan waktu yang tepat untuk menguji nilai baru. Sebelumnya, jumlah target/maksimum blob per blok disetel menjadi 3/6. Batasan-batasan ini sekarang ditingkatkan menjadi 6/9.
Gabungan dengan EIP-7623 sebelumnya (meningkatkan biaya calldata), penyesuaian ini lebih mendorong rollup untuk memindahkan datanya dari calldata ke blob. Pekerjaan mencari parameter blob terbaik masih berlanjut.
EIP-7840: Menambahkan penjadwalan blob ke file konfigurasi EL
Referensi: EIP-7840
Usulan EIP ini menambahkan target dan jumlah blob maksimum 'per blok' (yang telah dibahas sebelumnya) serta 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 seperti memperkirakan biaya gas blob.
EIP-7702: Mengatur Kode Akun EOA
Referensi: EIP-7702
Ini adalah EIP yang sangat penting, yang akan membawa perubahan besar bagi pengguna Ethereum. Seperti yang kita ketahui, EOA (External Owned Account) tidak dapat memiliki kode apa pun, tetapi dapat menyediakan tanda tangan transaksi (tx.origin). Di sisi lain, kontrak pintar memiliki bytecode, tetapi tidak dapat secara aktif memberikan tanda tangan 'nya' sendiri. Setiap interaksi pengguna yang memerlukan logika tambahan, otomatis, dan dapat diverifikasi saat ini hanya dapat dilakukan dengan memanggil kontrak eksternal untuk melakukan operasi yang diperlukan. Namun, dalam situasi ini, kontrak eksternal menjadi msg.sender dari kontrak berikutnya, sehingga memanggil 'dari panggilan kontrak, bukan pengguna'.
EIP ini memperkenalkan jenis transaksi SET_CODE_TX_TYPE=0x04 baru (kami memiliki transaksi 0x1 lama sebelumnya, transaksi 0x02 baru dari Berlin dan peningkatan EIP-1559, dan transaksi blob 0x03 yang diperkenalkan di Dencun). Jenis perdagangan baru ini memungkinkan Anda mengatur kode untuk akun EOA. Akibatnya, ini memungkinkan EOA untuk mengeksekusi kode eksternal "dalam konteks akun EOA-nya sendiri". Dari perspektif luar, EOA tampaknya "meminjam" kode dari kontrak eksternal dan menjalankannya selama transaksi. Secara teknis, ini dilakukan dengan menambahkan tupel data otorisasi khusus ke penyimpanan "kode" alamat EOA (sampai EIP ini, penyimpanan "kode" ini selalu kosong ke EOA).
Saat ini, jenis transaksi 0x04 baru yang diusulkan dalam EIP ini berisi sebuah array:
authorization_list = [[chain_id, alamat, nonce, y_parity, r, s], ...]
Setiap elemen memungkinkan akun menggunakan kode dari alamat yang ditentukan (dari item otorisasi terakhir yang valid). Saat memproses transaksi semacam itu, kode EOA yang diberikan diatur ke nilai alamat khusus 0xef0100 || (23 byte), di mana alamat menunjuk ke kontrak dengan kode yang diperlukan, || mewakili penggabungan, dan 0xef0100 mewakili nilai sihir khusus yang tidak dapat dimasukkan ke dalam kontrak cerdas biasa (berdasarkan EIP-3541). Nilai sihir ini memastikan bahwa EOA ini tidak dapat dianggap sebagai kontrak biasa dan tidak dapat dipanggil seperti kontrak biasa.
Ketika EOA ini menginisiasi transaksi, alamat yang ditentukan akan digunakan untuk memanggil kode yang sesuai dalam konteks EOA tersebut. Meskipun detail implementasi lengkap dari EIP ini masih belum jelas, namun dapat dipastikan akan membawa perubahan signifikan.
Salah satu dampak utamanya adalah kemampuan untuk melakukan panggilan ganda (multicall) langsung dari EOA. Panggilan ganda merupakan tren berkelanjutan dalam DeFi, dengan banyak protokol menyediakan fitur ini sebagai alat yang kuat (misalnya Uniswap V4, Balancer V3, atau Euler V2). Dengan adanya EIP ini, sekarang dapat langsung melakukan panggilan ganda dari EOA.
Misalnya, fitur baru ini mengatasi masalah umum dalam DeFi: keefisienan dua transaksi terpisah untuk approve() + anything(). EIP ini memungkinkan logika 'prapersetujuan' yang umum, sehingga seperti approve(X) + deposit(X) dapat diselesaikan dalam satu transaksi.
Salah satu keuntungan lain dari mampu 'mewakili' transaksi yang didelegasikan oleh EOA adalah konsep sponsor. Sponsor adalah fitur yang sering dibahas dan sangat diinginkan untuk membantu pengguna baru masuk ke Ethereum.
Logika yang dapat diprogram yang terkait dengan EOA membuka banyak kemungkinan, seperti menerapkan pembatasan keamanan, mengatur batas pengeluaran, memaksa persyaratan KYC, dll.
Tentu saja, pergeseran ini juga menimbulkan sejumlah pertanyaan desain. Salah satu masalah adalah penggunaan chain_id, yang menentukan apakah tanda tangan yang sama dapat valid di beberapa jaringan, tergantung pada apakah itu disertakan atau tidak termasuk dalam tanda tangan. Komplikasi lain adalah pilihan antara menggunakan alamat kode objek dan menyematkan bytecode yang sebenarnya. Kedua metode memiliki fitur dan keterbatasan unik mereka sendiri. Selain itu, penggunaan nonce memainkan peran kunci dalam menentukan apakah izin adalah "multi-tujuan" atau "tujuan tunggal". Elemen-elemen ini memengaruhi fungsionalitas dan masalah keamanan, termasuk aspek-aspek seperti tanda tangan pembatalan massal dan kemudahan penggunaan. Vitalik mengangkat pertanyaan-pertanyaan ini dalam diskusi (di sini) yang perlu ditelusuri lebih lanjut.
Perlu diperhatikan bahwa perubahan ini akan mempengaruhi mekanisme keamanan Ethereum, tx.origin. Lebih banyak detail tentang implementasi EIP ini diperlukan, tetapi tampaknya perilaku require(tx.origin == msg.sender) akan berubah. Pemeriksaan ini selalu menjadi metode yang paling dapat diandalkan untuk memastikan bahwa msg.sender adalah EOA, bukan kontrak. Metode lain, seperti pemeriksaan EXTCODESIZE (untuk memeriksa apakah itu adalah kontrak), sering kali gagal dan dapat dihindari (misalnya, dengan memanggil konstruktor atau dengan mendeploy kode ke alamat yang telah ditentukan sebelumnya setelah transaksi). Pemeriksaan ini digunakan untuk mencegah serangan reentrancy dan flash loan, tetapi jauh dari ideal karena juga menghambat integrasi dengan protokol eksternal. Setelah EIP ini, bahkan pemeriksaan yang dapat diandalkan require(tx.origin == msg.sender) tampaknya menjadi usang. Protokol harus beradaptasi dengan cara menghapus pemeriksaan ini karena perbedaan antara 'EOA' dan 'kontrak' tidak lagi berlaku - sekarang setiap alamat dapat memiliki kode yang terkait.
Pemisahan tradisional antara EOA dan kontrak pintar terus kabur. EIP ini membuat Ethereum lebih dekat dengan desain seperti TON, di mana setiap akun pada dasarnya adalah kode yang dapat dieksekusi. Seiring interaksi dengan protokol menjadi semakin kompleks, menggunakan logika yang dapat diprogram untuk meningkatkan pengalaman pengguna akhir adalah evolusi alami dari proses ini.
Kesimpulan
Peningkatan Praha / Electra (Pectra) dijadwalkan pada Maret 2025. Perubahan rencana yang paling signifikan termasuk:
Seperti yang Anda lihat, Pectra akan memiliki dampak besar pada pengalaman pengguna akhir dari lapisan staking dan konsensus, serta lapisan eksekusi. Meskipun kami tidak dapat secara rinci menganalisis semua perubahan ini melalui kode pada tahap ini karena pengembangan masih berlangsung, kami akan mencakup pembaruan ini dalam artikel di masa depan.