Hard fork Pectra dijadwalkan akan diluncurkan pada bulan Maret 2025. Upgrade Pectra mencakup 11 protokol teknis (EIP), yaitu:
EIP-2537: Prekompilasi Operasi Kurva BLS12-381
EIP-2935: Menyimpan nilai hash blok historis di State
EIP-6110: Menyediakan deposit validator on-chain
EIP-7002: Pemicu Pelaksanaan Keluar
EIP-7251: Tambahkan MAX_EFFECTIVE_BALANCE
EIP-7549: Memindahkan indeks komite ke luar validasi
EIP-7623: Menambahkan biaya calldata
EIP-7685: Permintaan Lapisan Eksekusi Umum
EIP-7691: Meningkatkan throughput Blob
EIP-7702: Tetapkan kode akun EOA
EIP-7840: Menambahkan Rencana Blob ke File Konfigurasi EL
Protokol Teknis Terkait Penyetoran
EIP-6110: Pra-penyusunan Operasi Kurva BLS12-381
Sederhanakan proses partisipasi pengguna dalam staking, sehingga waktu tunggu dapat dipangkas secara signifikan.
Cara pengguna berpartisipasi dalam staking adalah dengan menyimpan 32 ETH di lapisan eksekusi dan didokumentasikan dalam Log Acara, lalu lapisan konsensus akan mengeksekusi log acara untuk menentukan apakah ada yang berpartisipasi dalam staking, dan pengguna yang berpartisipasi dalam staking akan menjadi validator.
Namun, validator lapisan konsensus pertama perlu memutuskan titik waktu mana yang akan disepakati untuk disimpan terlebih dahulu, jika tidak, beberapa validator akan melihat 5 penyimpanan baru, sementara yang lain hanya melihat 3, oleh karena itu validator lapisan konsensus akan memberikan suara untuk blok lapisan eksekusi mana yang akan dirujuk (eth1data), memastikan bahwa semua orang melihat blok lapisan eksekusi yang sama.
Namun, pada awalnya, dalam desainnya untuk menghindari kesalahan besar yang mengakibatkan fork di lapisan eksekusi, maka blok lapisan eksekusi yang diacu (eth1data) akan menjadi blok lapisan eksekusi sekitar 10 jam yang lalu, memastikan bahwa ketika kesalahan besar terjadi, para pengembang lapisan konsensus memiliki waktu yang cukup untuk bereaksi, namun ini juga berarti bahwa partisipasi dalam staking juga memerlukan waktu lebih dari 10 jam untuk mulai berlaku.
Setelah protokol teknis EIP-6110 dijalankan, data janji pengguna pada kontrak akan langsung menjadi bagian dari lapisan eksekusi, dan karena blok lapisan konsensus itu sendiri akan berisi blok lapisan eksekusi (tetapi bukan eth1data), validator lapisan konsensus tidak perlu lagi mempertimbangkan masalah "mengonfirmasi bahwa blok memori lapisan eksekusi referensi adalah sama", selama blok memori lapisan konsensus dipilih oleh lebih dari dua pertiga validator, semua orang akan mencapai konsensus pada blok lapisan eksekusi yang sama. Oleh karena itu, setelah berpartisipasi dalam janji, pengguna dapat menunggu blok memori lapisan eksekusi menyelesaikan pemrosesan paling cepat dalam waktu sekitar 13 menit, dan klien lapisan konsensus juga dapat menghapus logika kompleks yang awalnya digunakan untuk memproses data staking.
EIP-7002: Menyimpan Nilai Hash Blok Historis di State
Ini dapat digunakan untuk meningkatkan proses bagi validator untuk membatalkan atau menarik setoran dan penghasilan, mengurangi risiko bagi validator.
Partisipasi dalam penyetoran memerlukan dua kunci, yaitu Validator Key dan Withdrawal Credential.
Validator Key digunakan untuk memverifikasi konten validator, Withdrawal Credential digunakan saat validator menarik staking, deposit dan pendapatan akan ditarik ke alamat tersebut, selain itu, saat ini penarikan staking harus dilakukan dengan menggunakan Validator Key.
Jika kehilangan Kunci Validator, maka tidak dapat melakukan pekerjaan validasi dan tidak dapat menarik staking; Jika kehilangan Withdrawal Credential, maka semua staking dan pendapatan akan hilang. Selain itu, sebagian pengguna akan menggunakan layanan staking pihak ketiga seperti Lido, ketika menggunakan platform-platform ini, pengguna perlu menyimpan Withdrawal Credential sendiri, sementara Kunci Validator disimpan dan digunakan oleh penyedia layanan untuk melakukan pekerjaan validasi.
Dengan menerapkan protokol teknis EIP-7002, pengguna dapat menggunakan Withdrawal Credential untuk memanggil 'Kontrak Penarikan' (yaitu dideploy di 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) untuk keluar dari penjaminan (Exit) atau menarik sebagian deposit dan pendapatan (Partial Withdrawal) sendiri, yang dapat mengurangi risiko terkait penggunaan layanan penjaminan pihak ketiga. Jika pengguna terlibat dalam penjaminan sendiri namun kehilangan Kunci Validator, pengguna juga dapat keluar dari penjaminan dengan cara ini.
Parameter untuk memulai permintaan termasuk validator \ _pubkey dan jumlah: validator \ _pubkey adalah Kunci Validator (Publik) validator, dan jumlah adalah jumlah yang akan ditarik.
Kredensial Penarikan yang memulai permintaan harus merupakan Kredensial Penarikan validator_pubkey validator.
Saat memanggil kontrak Withdraw untuk mengajukan permintaan, Anda harus menyertakan biaya Gas (ETH), Biaya Gas akan dihitung berdasarkan jumlah permintaan penarikan saat ini, jika jumlah permintaan banyak, biaya Gas akan naik.
Jika Kredensial Penarikan pengguna adalah kontrak, Anda dapat pergi ke Kontrak Penarikan untuk mendapatkan jumlah biaya saat ini, lalu mengajukan permintaan dan melampirkan biaya; tetapi jika Kredensial Penarikan adalah akun EOA, tidak mungkin untuk mendapatkan biaya yang akurat, Anda hanya bisa mensimulasikan di luar rantai dan membayar biaya berlebih (tidak akan dikembalikan) untuk memastikan permintaan berhasil dilakukan.
*Catatan: Jika Kredensial Penarikan Anda masih dalam format kunci publik BLS, ingatlah untuk mengalihkannya ke format alamat EL terlebih dahulu. *
EIP-7251: Menambahkan MAX_EFFECTIVE_BALANCE
Dapat secara signifikan meningkatkan batas jumlah pledge untuk mengurangi jumlah validator, dan validator yang belum mencapai batas dapat secara otomatis menikmati pendapatan pledge.
Pengguna yang melakukan penyerahan sebagai validator harus menyediakan jumlah ETH MAX_EFFECTIVE_BALANCE, tidak kurang dan tidak lebih (saat ini MAX_EFFECTIVE_BALANCE adalah 32 ETH). Jika pengguna memiliki 1024 ETH untuk diserahkan, mereka dapat melakukan penyerahan sebanyak 32 kali, mengaktifkan 32 validator, dan menjalankan 32 node validator. Partisipasi aktif dalam penyerahan telah mengakibatkan sekitar 1 juta validator saat ini, dan jumlahnya terus bertambah. Hal ini tidak hanya membuat data status lapisan konsensus menjadi lebih besar, tetapi juga meningkatkan beban jaringan p2p lapisan konsensus, karena tanda tangan dari puluhan ribu validator harus terus-menerus disampaikan dan digabungkan di lapisan jaringan p2p setiap Slot (setiap 12 detik).
Setelah menjalankan protokol teknis EIP-7251, batas bawah staking (MIN_ACTIVATION_BALANCE) tetap 32 ETH, tetapi batas atas (MAX_EFFECTIVE_BALANCE) akan ditingkatkan secara signifikan menjadi 2048 ETH. Anda dapat melakukan staking pada jumlah ETH antara 32 hingga 2048 dan dapat memperoleh imbalan staking tanpa perlu mengambil imbalan secara berkala. Anda dapat mengakumulasi 32 ETH kemudian melanjutkan staking baru.
Saat ini, validator yang sudah ada tidak perlu keluar dari staking terlebih dahulu sebelum bergabung kembali untuk melakukan staking bersama, tetapi dapat langsung menggunakan 'kontrak penggabungan deposit' yang baru ditambahkan di lapisan eksekusi (dideploy di 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) untuk memanggil kredensial penarikan validator dan memulai permintaan penggabungan deposit.
Parameter permintaan penggabungan deposit termasuk source_pubkey dan target_pubkey: kedua kunci ini adalah Validator Key dari validator, validator sumber akan digabungkan ke validator target.
Kredensial Penarikan yang Diajukan harus menjadi Kredensial Penarikan dari verifikator sumber.
Saat memanggil kontrak gabungan deposit untuk menginisiasi permintaan, Anda harus melampirkan biaya (ETH). Biaya akan dihitung berdasarkan jumlah permintaan saat ini, jika jumlah permintaan banyak, biaya akan meningkat.
Jika Kredensial Penarikan pengguna adalah kontrak, maka Anda dapat memanggil kontrak setoran gabungan untuk mendapatkan jumlah biaya saat ini, dan kemudian memulai permintaan dan melampirkan biaya; Namun, jika Kredensial Penarikan adalah akun EOA, tidak ada cara untuk mendapatkan biaya yang akurat, sehingga Anda hanya dapat mensimulasikan off-chain di muka dan membayar kelebihan biaya (yang tidak akan dikembalikan) untuk memastikan bahwa permintaan akan berhasil dieksekusi.
Catatan: Jika Withdrawal Credential Anda dalam format kunci publik BLS, Anda perlu beralih terlebih dahulu dan mengubahnya menjadi format alamat EL.
EIP-7685: Permintaan Lapisan Eksekusi Umum
Buat pipa informasi CL EL-> formal sehingga pengguna dan layanan staking dapat mengirim permintaan langsung ke lapisan konsensus.
Pengguna dapat langsung mengirim permintaan dari lapisan eksekusi ke lapisan konsensus, layanan staking (misalnya Lido) dapat beroperasi dalam mode yang lebih terdesentralisasi. Misalnya permintaan penarikan staking EIP-7002 yang disebutkan sebelumnya, dan permintaan penggabungan deposit EIP-7251. Jika tidak ada protokol teknis ini, pengguna Lido harus percaya bahwa penyedia layanan node Lido akan jujur dalam menjalankan penarikan staking atau penggabungan deposit di lapisan konsensus; dengan adanya protokol teknis ini, pengguna Lido dapat langsung mengirimkan permintaan melalui kontrak tata kelola di lapisan eksekusi.
Permintaan-permintaan ini akan dibedakan berdasarkan Jenis Permintaan, serta permintaan akan diajukan melalui kontrak-kontrak yang berbeda. Akhirnya, permintaan-permintaan ini akan ditulis ke dalam blok memori lapisan eksekusi, sehingga lapisan konsensus dapat langsung mengakses informasi ini melalui blok memori eksekusi tanpa perlu menulis logika parsing yang terpisah lagi.
EIP-6110、EIP-7002 dan EIP-7251 semuanya menggunakan standar yang ditetapkan oleh EIP-7685 untuk merumuskan permintaan:
EIP-6110 Tambahkan permintaan staking: Jenis Permintaan = 0, melalui kontrak Deposit
(0x00000000219ab540356cbb839cbe05303d7705fa) melakukan permintaan.
Permintaan Penarikan Staking EIP-7002: Jenis Permintaan=1, melalui kontrak Withdraw
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) Memulai permintaan.
Penggabungan Permintaan Deposit EIP-7251: Jenis Permintaan=2, melalui Kontrak Konsolidasi
Protokol Teknis untuk Meningkatkan Pengalaman Pengguna
EIP-7702: Mengatur Kode Akun EOA
Mengubah akun EOA menjadi akun kontrak dengan bebas, secara signifikan meningkatkan pengalaman pengguna.
Ada beberapa kekurangan dalam penggunaan akun EOA, antara lain:
Perlu untuk mencatat dan menyimpan kunci pribadi atau frase pengingat, yang merupakan hambatan tinggi bagi pengguna baru untuk mendaftar dan menggunakan.
Satu transaksi akun EOA hanya dapat melakukan satu operasi, misalnya, untuk menukar USDT ke ETH di Uniswap, Anda harus memulai transaksi untuk menyetujui USDT terlebih dahulu, kemudian baru dapat mengirim transaksi lain untuk melakukan pertukaran.
Pengendalian izin yang tidak dapat dipecahkan, seperti memberikan beberapa operasi akun untuk dioperasikan oleh pihak ketiga, pengguna harus menangani setiap urusan sendiri dan setiap operasi harus ditandatangani dan ditransaksikan satu kali.
Tidak ada mekanisme pemulihan, jadi Anda hanya dapat menyimpan kunci pribadi atau frasa mnemonik sendiri, dan jika Anda kehilangannya, Anda tidak akan pernah bisa mendapatkan kembali aset akun.
Jika itu adalah akun kontrak pintar (misalnya Safe), maka semua masalah di atas dapat diselesaikan:
Pengguna dapat menggunakan kunci pribadi dalam chip keamanan ponsel (atau komputer) untuk menandatangani otorisasi, tidak perlu mengingat kunci pribadi atau kata-kata mnemonik, atau menggunakan email untuk menandatangani otorisasi, atau berbagai metode otorisasi lainnya.
Anda dapat mengelompokkan beberapa operasi ke dalam Batch dan menjalankannya dalam satu transaksi, operasi DApp yang sebelumnya rumit dapat diselesaikan hanya dengan satu kali tanda tangan otorisasi, satu kali transaksi.
Dapat mengatur izin dengan sangat rinci, pengguna dapat memberikan wewenang kepada pihak ketiga untuk mengontrol akun mereka sendiri, sambil secara bersamaan menentukan 'interaksi dengan kontrak apa yang diizinkan', 'tindakan apa yang tidak boleh dilakukan', 'maksimum aset yang dapat digunakan dalam transfer aset', atau 'jumlah maksimum operasi per minggu' dan sebagainya.
Dapat menambahkan mekanisme Pemulihan, sehingga aset akun dapat dipindahkan ke akun baru melalui mekanisme Pemulihan ketika kata pemulihan, ponsel, atau email hilang.
Usulan EIP-7702 adalah memberikan kemampuan kepada akun EOA untuk berubah menjadi akun kontrak. Pengguna menggunakan kunci pribadi EOA untuk menandatangani pesan transformasi, konten tandatangan mencakup "Chain ID", "alamat kontrak yang akan diubah", dan "Nilai Nonce EOA":
Chain ID: digunakan untuk mencegah tanda tangan A rantai direplay ke rantai B. Namun, jika Chain ID diisi 0, itu berarti bersedia berubah menjadi setiap rantai.
Alamat kontrak yang ingin diubah: Jika Anda mengisi alamat kontrak Safe, maka akun EOA Anda akan berubah menjadi kontrak Safe; jika mengosongkan alamat (alamat(0)), itu berarti pembatalan perubahan, kembali menjadi akun EOA biasa.
Nilai Nonce EOA: Digunakan untuk mencegah tanda tangan diputar ulang. Jika nilai nonce meningkat, tanda tangan asli akan dibatalkan.
Namun, ada beberapa hal yang perlu diperhatikan:
Kunci privat EOA dapat terus digunakan
Bahkan jika akun EOA pengguna berubah menjadi kontrak, ia masih dapat terus digunakan seperti akun EOA aslinya. Misalnya, jika akun EOA Anda berubah menjadi kontrak Safe, Anda dapat menggunakan antarmuka Safe, mengikuti alur transaksi Safe, dan juga dapat terus menggunakan dompet EOA asli untuk menandatangani dan mengirim transaksi. Namun, hal ini juga berarti keamanan akun terbatas pada kunci pribadi tersebut.
Masih tentang keamanan kunci pribadi EOA
Bahkan jika EOA pengguna menjadi MultiSig, selama dia tidak kehilangan kunci pribadi EOA, keamanan akunnya akan selalu menjadi keamanan kunci pribadi EEO: dia masih harus menjaga kunci pribadinya atau frasa mnemonik aman, dan akunnya tidak akan seaman MultiSig.
Penyimpanan akun EOA tidak akan diformat
Ketika akun EOA berubah menjadi kontrak dan menulis data ke Storage-nya, data yang ditulis ke Storage tidak akan diformat karena akun EOA berubah menjadi kontrak lain atau pembatalan transformasi kecuali tindakan penghapusan data yang jelas dilakukan, jadi pengembang harus memperhatikan agar Storage tidak membaca data yang ditinggalkan oleh kontrak sebelumnya, dapat merujuk ke ERC-7201.
Proses EIP-7702 tidak termasuk inisialisasi
Kontrak umum biasanya memerlukan langkah inisialisasi, yang secara bersamaan menulis informasi pemilik kontrak ke akun saat dikerjakan (misalnya kunci publik atau alamat), untuk menghindari kehilangan kepemilikan akun karena langkah-langkah implementasi dapat 'dihadang' (Frontrun). Ini biasanya dilakukan oleh Kontrak Factory yang mengimplementasikan 'implementasi+inisialisasi', tetapi karena EIP-7702 mengalami perubahan langsung, bukan dari Factory yang mengimplementasikan kontrak ke EOA, sehingga penyerang dapat menyalin tanda tangan perubahan pengguna dan mengirimkan transaksi ke rantai lebih dulu untuk mengubah pengguna tetapi menginisialisasi akun ke yang dapat dikendalikan oleh penyerang, oleh karena itu pengembang perlu memperhatikan EIP-7702. Metode pencegahan yang mungkin adalah dengan memeriksa tanda tangan akun EOA dalam fungsi inisialisasi, sehingga meskipun 'dihadang', penyerang tidak dapat menghasilkan tanda tangan akun EOA tersebut untuk menyelesaikan inisialisasi.
Permintaan perubahan penjaga gerbang dompet
Dompet perlu mengawasi dengan baik untuk pengguna, menghentikan permintaan dari situs web DApp jahat yang meminta pengguna menandatangani transaksi transformasi dan memberi peringatan kepada pengguna, jika tidak, jika pengguna menandatangani transaksi transformasi yang jahat, akan menyebabkan aset langsung dipindahkan. Berikut adalah contoh implementasi kontrak transformasi:
Akun Ithaca Aman yang Dimodifikasi
Akun Ithaca
Protokol Teknologi DApp
EIP-2537: Prekompilasi Operasi Kurva BLS12-381
Menurunkan biaya aplikasi bukti tanpa pengetahuan berbasis kurva BLS, sehingga menjadi lebih layak.
EIP-2537 menambahkan beberapa kontrak pra-kompilasi untuk menyediakan operasi kurva BLS yang murah, sehingga pengembangan aplikasi bukti pengetahuan nol berbasis kurva BLS akan menjadi lebih memungkinkan.
EIP-2935: Menyimpan Hash Blok Historis di Negara Bagian
Hal ini memungkinkan pengembang atau node untuk membaca hash blok blok memori masa lalu langsung dari penyimpanan kontrak sistem.
Jika pengembang perlu membuktikan isi blok memori sebelumnya, misalnya, jika tantangan penipuan Optimismtic Rollup ingin membuktikan bahwa transaksi ada di 1000 blok memori sebelumnya, penantang tidak dapat mengatakannya secara langsung.
"Percayalah, 1000 blok memori benar-benar ada sebelumnya", dia harus memberikan bukti, tetapi tidak ada bukti langsung untuk membuktikan bahwa "1000 blok memori sebelumnya berisi konten ini", jadi dia harus membuktikan transaksi dalam "rantai" blok memori, blok demi blok, hingga mencapai 1000 blok sebelumnya, dan kemudian membuktikan bahwa transaksi tersebut ada di blok tersebut.
Setiap blok akan menunjuk ke blok induk, sehingga dapat membuktikan setiap blok dalam sejarah satu per satu.
Misalkan saat ini blok memori dengan angka 10000, dan tantangan penipuan ingin memberikan bukti bahwa blok memori dengan nomor 9000 memiliki transaksi X, penantang harus mulai dengan hash blok memori 10000, pertama-tama buktikan hash dari blok memori induk 9999 yang terhubung ke blok memori 10000, dan kemudian buktikan blok memori 9998... Sampai blok memori 9000, isi blok memori 9000 diusulkan mengandung transaksi X.
Setelah EIP-2935, akan ada kontrak sistem (digunakan pada 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) yang akan menyimpan hash hingga 8192 blok memori sebelumnya. Setiap kali blok memori baru dihasilkan, kontrak sistem akan secara otomatis diperbarui untuk menulis hash dari blok sebelumnya ke dalam kontrak sistem (hash dari 8192 blok memori sebelumnya akan ditulis ulang).
Dengan cara ini, dalam contoh tantangan penipuan Optimismtic Rollup, penantang tidak harus kembali ke blok memori sebelumnya untuk membuktikan satu blok memori pada satu waktu, tetapi dapat langsung membuktikan bahwa dalam keadaan saat ini dari rantai blok memori 10000, nilai Penyimpanan tertentu (sesuai dengan blok memori 9000) dari kontrak sistem adalah nilai hash dari blok memori 9000. Jika kisarannya melebihi 8192, seperti blok memori 1000, maka paling banyak itu adalah satu langkah lagi untuk membuktikan nilai hash blok memori 1808 (= 10000 - 8192), dan kemudian membuktikan nilai hash blok memori 1000 dalam kontrak sistem dalam keadaan rantai blok memori 1808 saat ini.
Ini juga membuka jalan bagi Klien Tanpa Status di masa depan (Stateless Client): node ringan di masa depan tidak perlu lagi menyimpan Header Blok dari semua blok memori dalam sejarah, tetapi ketika diperlukan nilai hash blok memori tertentu dari sejarah atau konten blok memori, maka mintalah orang lain untuk memberikan bukti dengan cara yang sama seperti contoh tantangan penipuan sebelumnya.
EIP-7623:: Meningkatkan biaya calldata
Meningkatkan biaya penggunaan calldata untuk mempublikasikan data, untuk menyediakan ruang keamanan yang cukup untuk meningkatkan Batas Gas Blok dan jumlah Blob.
Dengan meningkatnya permintaan publikasi data Rollup, pengenalan Blob dalam EIP-4844 untuk memungkinkan Rollup menyimpan data dengan harga yang sangat murah, peningkatan jumlah Blob telah lama menjadi upgrade yang diharapkan oleh komunitas, seperti peningkatan Limit Gas Blok yang sedang didorong oleh komunitas baru-baru ini, semuanya mencerminkan kebutuhan ekosistem untuk meningkatkan sumber daya.
!
△ Semakin banyak validator telah menyatakan dukungan untuk meningkatkan Batas Gas Blok.
Namun, baik meningkatkan Batas Gas Blok atau jumlah Blob, akan menimbulkan tekanan lebih besar pada jaringan p2p Ethereum karena volume data transaksi yang lebih besar, yang akan meningkatkan efisiensi serangan oleh penyerang, kecuali biaya publikasi data juga ditingkatkan.
Setelah rilis protokol EIP-7623, biaya calldata akan meningkat 2,5 kali lipat dari sebelumnya 'Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas' menjadi 'Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas'.
Awalnya, jika penyerang menggunakan semua Batas Gas Blok (30M) untuk memasukkan data sampah, ukuran data blok memori akan menjadi sekitar 1,79 MB (30M / 16), dibandingkan dengan ukuran blok memori rata-rata hanya sekitar 100 KB. Jika Batas Gas Blok ditingkatkan menjadi 40M, penyerang dapat menghasilkan blok memori sekitar 2,38 MB. Ketika biaya calldata meningkat sebesar 2,5x, efisiensi penyerang akan berkurang menjadi maksimum 0,72MB untuk 30M dan 0,95MB untuk 40M, sehingga Block Gas Limit dan Blob dapat ditingkatkan dengan lebih percaya diri. Namun, protokol teknis ini tidak ingin mempengaruhi pengguna umum yang "tidak menggunakan calldata untuk mempublikasikan data", sehingga akan menghitung total penggunaan gas transaksi dengan dua cara, mana yang lebih tinggi:
Cara perhitungan Gas transaksi asli, dikombinasikan dengan biaya calldata lama: yaitu menghitung calldata dalam cara 'Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas', dan menambahkan Gas yang dihabiskan oleh transaksi serta Gas yang dihabiskan oleh kontrak penyebaran.
Hanya menghitung penggunaan Gas calldata secara murni, tetapi menggunakan biaya baru untuk menghitungnya: yaitu menghitung calldata dalam cara 'Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas', tetapi tidak termasuk Gas yang digunakan dalam eksekusi atau Gas yang digunakan untuk implementasi kontrak sehingga bagi pengguna umum yang tidak 'mempublikasikan data menggunakan calldata' (misalnya, menukar di Uniswap), penggunaan Gas utama sebenarnya terjadi pada bagian eksekusi, bahkan jika calldata dihitung dengan biaya baru, itu tidak akan melebihi Gas yang digunakan dalam eksekusi, oleh karena itu pengguna umum tidak akan terpengaruh.
Yang benar-benar terpengaruh akan menjadi Rollup dengan skala kecil, karena Blob memiliki ukuran tetap dan biaya tetap, sehingga efisiensi Rollup kecil dalam menggunakan Blob rendah, lebih murah untuk menggunakan calldata, tetapi setelah EIP-7623, biaya Rollup kecil ini akan meningkat 2,5 kali lipat, mereka mungkin harus beralih ke penggunaan Blob atau mencari cara untuk bekerja sama dan berbagi satu Blob.
EIP-7691: Meningkatkan throughput blob
Meningkatkan jumlah Blob, memberikan lebih banyak ruang untuk publikasi data ke Rollup.
EIP-7691 meningkatkan jumlah Blob dari "Target: 3 Blob, Batas atas: 6 Blob" menjadi "Target: 6 Blob, Batas atas: 9 Blob", memberikan lebih banyak ruang untuk publikasi data kepada Rollup.
Catatan: Selain itu, ada beberapa desain di pasar biaya Blob yang perlu disempurnakan, seperti kecepatan penyesuaian biaya tidak cukup instan dan dasar biaya terlalu rendah, tetapi ini bukan masalah yang ingin dipecahkan oleh protokol teknis ini.
Perjanjian Teknis Lainnya
EIP-7549: Memindahkan indeks komite dari validasi
Sesuaikan konten pemungutan suara validator untuk memudahkan suara dikumpulkan dan mengurangi tekanan pada jaringan P2P.
Validator secara acak ditugaskan ke sekelompok komite dan pasangan untuk setiap zaman
Dalam pemungutan suara blok memori, suara validator di setiap komite dapat digabungkan bersama, yang mengurangi jumlah suara yang disahkan di jaringan P2P, tetapi suara validator akan berisi informasi tentang jumlah komite yang dimiliki validator, yang berarti bahwa suara dari komite yang berbeda tidak dapat dikumpulkan, bahkan jika mereka semua memberikan suara pada blok memori yang sama.
EIP-7549 menghapus informasi bahwa validator milik komite pertama dari konten pemungutan suara, sehingga validator dari komite yang berbeda dapat digabungkan bersama ketika konten pemungutan suara sama, semakin mengurangi jumlah suara yang disahkan di jaringan P2P dan mengurangi tekanan pada jaringan P2P.
EIP-7840: Tambahkan Paket Blob ke Profil EL
Buat file konfigurasi untuk parameter blob di lapisan eksekusi, simpan node lapisan eksekusi kesulitan meminta node lapisan konsensus untuk parameter terkait blob.
Parameter terkait blob saat ini disimpan dalam node lapisan konsensus, tetapi node lapisan eksekusi masih memerlukan parameter ini dalam beberapa kasus (misalnya, RPC eth_feeHistory), sehingga mereka harus meminta node lapisan konsensus.
EIP-7840 membuat file konfigurasi untuk parameter terkait blob pada lapisan eksekusi, dan node di lapisan eksekusi dapat langsung membaca parameter terkait blob melalui file konfigurasi ini tanpa harus meminta node lapisan konsensus.
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.
Pengenalan Hard Fork Ethereum Pectra
Penulis: NIC Lin, Medium
Hard fork Pectra dijadwalkan akan diluncurkan pada bulan Maret 2025. Upgrade Pectra mencakup 11 protokol teknis (EIP), yaitu:
Protokol Teknis Terkait Penyetoran
EIP-6110: Pra-penyusunan Operasi Kurva BLS12-381
Sederhanakan proses partisipasi pengguna dalam staking, sehingga waktu tunggu dapat dipangkas secara signifikan.
Cara pengguna berpartisipasi dalam staking adalah dengan menyimpan 32 ETH di lapisan eksekusi dan didokumentasikan dalam Log Acara, lalu lapisan konsensus akan mengeksekusi log acara untuk menentukan apakah ada yang berpartisipasi dalam staking, dan pengguna yang berpartisipasi dalam staking akan menjadi validator.
Namun, validator lapisan konsensus pertama perlu memutuskan titik waktu mana yang akan disepakati untuk disimpan terlebih dahulu, jika tidak, beberapa validator akan melihat 5 penyimpanan baru, sementara yang lain hanya melihat 3, oleh karena itu validator lapisan konsensus akan memberikan suara untuk blok lapisan eksekusi mana yang akan dirujuk (eth1data), memastikan bahwa semua orang melihat blok lapisan eksekusi yang sama.
Namun, pada awalnya, dalam desainnya untuk menghindari kesalahan besar yang mengakibatkan fork di lapisan eksekusi, maka blok lapisan eksekusi yang diacu (eth1data) akan menjadi blok lapisan eksekusi sekitar 10 jam yang lalu, memastikan bahwa ketika kesalahan besar terjadi, para pengembang lapisan konsensus memiliki waktu yang cukup untuk bereaksi, namun ini juga berarti bahwa partisipasi dalam staking juga memerlukan waktu lebih dari 10 jam untuk mulai berlaku.
!
△ CL区块里的10900000eth1data，它里面记载的Block Hash是执行层区块21683339，出现在它的10个小时以前。
Setelah protokol teknis EIP-6110 dijalankan, data janji pengguna pada kontrak akan langsung menjadi bagian dari lapisan eksekusi, dan karena blok lapisan konsensus itu sendiri akan berisi blok lapisan eksekusi (tetapi bukan eth1data), validator lapisan konsensus tidak perlu lagi mempertimbangkan masalah "mengonfirmasi bahwa blok memori lapisan eksekusi referensi adalah sama", selama blok memori lapisan konsensus dipilih oleh lebih dari dua pertiga validator, semua orang akan mencapai konsensus pada blok lapisan eksekusi yang sama. Oleh karena itu, setelah berpartisipasi dalam janji, pengguna dapat menunggu blok memori lapisan eksekusi menyelesaikan pemrosesan paling cepat dalam waktu sekitar 13 menit, dan klien lapisan konsensus juga dapat menghapus logika kompleks yang awalnya digunakan untuk memproses data staking.
EIP-7002: Menyimpan Nilai Hash Blok Historis di State
Ini dapat digunakan untuk meningkatkan proses bagi validator untuk membatalkan atau menarik setoran dan penghasilan, mengurangi risiko bagi validator.
Partisipasi dalam penyetoran memerlukan dua kunci, yaitu Validator Key dan Withdrawal Credential.
Validator Key digunakan untuk memverifikasi konten validator, Withdrawal Credential digunakan saat validator menarik staking, deposit dan pendapatan akan ditarik ke alamat tersebut, selain itu, saat ini penarikan staking harus dilakukan dengan menggunakan Validator Key.
Jika kehilangan Kunci Validator, maka tidak dapat melakukan pekerjaan validasi dan tidak dapat menarik staking; Jika kehilangan Withdrawal Credential, maka semua staking dan pendapatan akan hilang. Selain itu, sebagian pengguna akan menggunakan layanan staking pihak ketiga seperti Lido, ketika menggunakan platform-platform ini, pengguna perlu menyimpan Withdrawal Credential sendiri, sementara Kunci Validator disimpan dan digunakan oleh penyedia layanan untuk melakukan pekerjaan validasi.
Dengan menerapkan protokol teknis EIP-7002, pengguna dapat menggunakan Withdrawal Credential untuk memanggil 'Kontrak Penarikan' (yaitu dideploy di 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) untuk keluar dari penjaminan (Exit) atau menarik sebagian deposit dan pendapatan (Partial Withdrawal) sendiri, yang dapat mengurangi risiko terkait penggunaan layanan penjaminan pihak ketiga. Jika pengguna terlibat dalam penjaminan sendiri namun kehilangan Kunci Validator, pengguna juga dapat keluar dari penjaminan dengan cara ini.
*Catatan: Jika Kredensial Penarikan Anda masih dalam format kunci publik BLS, ingatlah untuk mengalihkannya ke format alamat EL terlebih dahulu. *
EIP-7251: Menambahkan MAX_EFFECTIVE_BALANCE
Dapat secara signifikan meningkatkan batas jumlah pledge untuk mengurangi jumlah validator, dan validator yang belum mencapai batas dapat secara otomatis menikmati pendapatan pledge.
Pengguna yang melakukan penyerahan sebagai validator harus menyediakan jumlah ETH MAX_EFFECTIVE_BALANCE, tidak kurang dan tidak lebih (saat ini MAX_EFFECTIVE_BALANCE adalah 32 ETH). Jika pengguna memiliki 1024 ETH untuk diserahkan, mereka dapat melakukan penyerahan sebanyak 32 kali, mengaktifkan 32 validator, dan menjalankan 32 node validator. Partisipasi aktif dalam penyerahan telah mengakibatkan sekitar 1 juta validator saat ini, dan jumlahnya terus bertambah. Hal ini tidak hanya membuat data status lapisan konsensus menjadi lebih besar, tetapi juga meningkatkan beban jaringan p2p lapisan konsensus, karena tanda tangan dari puluhan ribu validator harus terus-menerus disampaikan dan digabungkan di lapisan jaringan p2p setiap Slot (setiap 12 detik).
Setelah menjalankan protokol teknis EIP-7251, batas bawah staking (MIN_ACTIVATION_BALANCE) tetap 32 ETH, tetapi batas atas (MAX_EFFECTIVE_BALANCE) akan ditingkatkan secara signifikan menjadi 2048 ETH. Anda dapat melakukan staking pada jumlah ETH antara 32 hingga 2048 dan dapat memperoleh imbalan staking tanpa perlu mengambil imbalan secara berkala. Anda dapat mengakumulasi 32 ETH kemudian melanjutkan staking baru.
Saat ini, validator yang sudah ada tidak perlu keluar dari staking terlebih dahulu sebelum bergabung kembali untuk melakukan staking bersama, tetapi dapat langsung menggunakan 'kontrak penggabungan deposit' yang baru ditambahkan di lapisan eksekusi (dideploy di 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) untuk memanggil kredensial penarikan validator dan memulai permintaan penggabungan deposit.
Catatan: Jika Withdrawal Credential Anda dalam format kunci publik BLS, Anda perlu beralih terlebih dahulu dan mengubahnya menjadi format alamat EL.
EIP-7685: Permintaan Lapisan Eksekusi Umum
Buat pipa informasi CL EL-> formal sehingga pengguna dan layanan staking dapat mengirim permintaan langsung ke lapisan konsensus.
Pengguna dapat langsung mengirim permintaan dari lapisan eksekusi ke lapisan konsensus, layanan staking (misalnya Lido) dapat beroperasi dalam mode yang lebih terdesentralisasi. Misalnya permintaan penarikan staking EIP-7002 yang disebutkan sebelumnya, dan permintaan penggabungan deposit EIP-7251. Jika tidak ada protokol teknis ini, pengguna Lido harus percaya bahwa penyedia layanan node Lido akan jujur dalam menjalankan penarikan staking atau penggabungan deposit di lapisan konsensus; dengan adanya protokol teknis ini, pengguna Lido dapat langsung mengirimkan permintaan melalui kontrak tata kelola di lapisan eksekusi.
Permintaan-permintaan ini akan dibedakan berdasarkan Jenis Permintaan, serta permintaan akan diajukan melalui kontrak-kontrak yang berbeda. Akhirnya, permintaan-permintaan ini akan ditulis ke dalam blok memori lapisan eksekusi, sehingga lapisan konsensus dapat langsung mengakses informasi ini melalui blok memori eksekusi tanpa perlu menulis logika parsing yang terpisah lagi.
EIP-6110、EIP-7002 dan EIP-7251 semuanya menggunakan standar yang ditetapkan oleh EIP-7685 untuk merumuskan permintaan:
(0x00000000219ab540356cbb839cbe05303d7705fa) melakukan permintaan.
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) Memulai permintaan.
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) mengajukan permintaan.
Protokol Teknis untuk Meningkatkan Pengalaman Pengguna
EIP-7702: Mengatur Kode Akun EOA
Mengubah akun EOA menjadi akun kontrak dengan bebas, secara signifikan meningkatkan pengalaman pengguna.
Ada beberapa kekurangan dalam penggunaan akun EOA, antara lain:
Jika itu adalah akun kontrak pintar (misalnya Safe), maka semua masalah di atas dapat diselesaikan:
Usulan EIP-7702 adalah memberikan kemampuan kepada akun EOA untuk berubah menjadi akun kontrak. Pengguna menggunakan kunci pribadi EOA untuk menandatangani pesan transformasi, konten tandatangan mencakup "Chain ID", "alamat kontrak yang akan diubah", dan "Nilai Nonce EOA":
Namun, ada beberapa hal yang perlu diperhatikan:
Bahkan jika akun EOA pengguna berubah menjadi kontrak, ia masih dapat terus digunakan seperti akun EOA aslinya. Misalnya, jika akun EOA Anda berubah menjadi kontrak Safe, Anda dapat menggunakan antarmuka Safe, mengikuti alur transaksi Safe, dan juga dapat terus menggunakan dompet EOA asli untuk menandatangani dan mengirim transaksi. Namun, hal ini juga berarti keamanan akun terbatas pada kunci pribadi tersebut.
Bahkan jika EOA pengguna menjadi MultiSig, selama dia tidak kehilangan kunci pribadi EOA, keamanan akunnya akan selalu menjadi keamanan kunci pribadi EEO: dia masih harus menjaga kunci pribadinya atau frasa mnemonik aman, dan akunnya tidak akan seaman MultiSig.
Ketika akun EOA berubah menjadi kontrak dan menulis data ke Storage-nya, data yang ditulis ke Storage tidak akan diformat karena akun EOA berubah menjadi kontrak lain atau pembatalan transformasi kecuali tindakan penghapusan data yang jelas dilakukan, jadi pengembang harus memperhatikan agar Storage tidak membaca data yang ditinggalkan oleh kontrak sebelumnya, dapat merujuk ke ERC-7201.
Proses EIP-7702 tidak termasuk inisialisasi
Kontrak umum biasanya memerlukan langkah inisialisasi, yang secara bersamaan menulis informasi pemilik kontrak ke akun saat dikerjakan (misalnya kunci publik atau alamat), untuk menghindari kehilangan kepemilikan akun karena langkah-langkah implementasi dapat 'dihadang' (Frontrun). Ini biasanya dilakukan oleh Kontrak Factory yang mengimplementasikan 'implementasi+inisialisasi', tetapi karena EIP-7702 mengalami perubahan langsung, bukan dari Factory yang mengimplementasikan kontrak ke EOA, sehingga penyerang dapat menyalin tanda tangan perubahan pengguna dan mengirimkan transaksi ke rantai lebih dulu untuk mengubah pengguna tetapi menginisialisasi akun ke yang dapat dikendalikan oleh penyerang, oleh karena itu pengembang perlu memperhatikan EIP-7702. Metode pencegahan yang mungkin adalah dengan memeriksa tanda tangan akun EOA dalam fungsi inisialisasi, sehingga meskipun 'dihadang', penyerang tidak dapat menghasilkan tanda tangan akun EOA tersebut untuk menyelesaikan inisialisasi.
Dompet perlu mengawasi dengan baik untuk pengguna, menghentikan permintaan dari situs web DApp jahat yang meminta pengguna menandatangani transaksi transformasi dan memberi peringatan kepada pengguna, jika tidak, jika pengguna menandatangani transaksi transformasi yang jahat, akan menyebabkan aset langsung dipindahkan. Berikut adalah contoh implementasi kontrak transformasi:
Protokol Teknologi DApp
EIP-2537: Prekompilasi Operasi Kurva BLS12-381
Menurunkan biaya aplikasi bukti tanpa pengetahuan berbasis kurva BLS, sehingga menjadi lebih layak.
EIP-2537 menambahkan beberapa kontrak pra-kompilasi untuk menyediakan operasi kurva BLS yang murah, sehingga pengembangan aplikasi bukti pengetahuan nol berbasis kurva BLS akan menjadi lebih memungkinkan.
EIP-2935: Menyimpan Hash Blok Historis di Negara Bagian
Hal ini memungkinkan pengembang atau node untuk membaca hash blok blok memori masa lalu langsung dari penyimpanan kontrak sistem.
Jika pengembang perlu membuktikan isi blok memori sebelumnya, misalnya, jika tantangan penipuan Optimismtic Rollup ingin membuktikan bahwa transaksi ada di 1000 blok memori sebelumnya, penantang tidak dapat mengatakannya secara langsung.
"Percayalah, 1000 blok memori benar-benar ada sebelumnya", dia harus memberikan bukti, tetapi tidak ada bukti langsung untuk membuktikan bahwa "1000 blok memori sebelumnya berisi konten ini", jadi dia harus membuktikan transaksi dalam "rantai" blok memori, blok demi blok, hingga mencapai 1000 blok sebelumnya, dan kemudian membuktikan bahwa transaksi tersebut ada di blok tersebut.
Setiap blok akan menunjuk ke blok induk, sehingga dapat membuktikan setiap blok dalam sejarah satu per satu.
Misalkan saat ini blok memori dengan angka 10000, dan tantangan penipuan ingin memberikan bukti bahwa blok memori dengan nomor 9000 memiliki transaksi X, penantang harus mulai dengan hash blok memori 10000, pertama-tama buktikan hash dari blok memori induk 9999 yang terhubung ke blok memori 10000, dan kemudian buktikan blok memori 9998... Sampai blok memori 9000, isi blok memori 9000 diusulkan mengandung transaksi X.
Setelah EIP-2935, akan ada kontrak sistem (digunakan pada 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) yang akan menyimpan hash hingga 8192 blok memori sebelumnya. Setiap kali blok memori baru dihasilkan, kontrak sistem akan secara otomatis diperbarui untuk menulis hash dari blok sebelumnya ke dalam kontrak sistem (hash dari 8192 blok memori sebelumnya akan ditulis ulang).
Dengan cara ini, dalam contoh tantangan penipuan Optimismtic Rollup, penantang tidak harus kembali ke blok memori sebelumnya untuk membuktikan satu blok memori pada satu waktu, tetapi dapat langsung membuktikan bahwa dalam keadaan saat ini dari rantai blok memori 10000, nilai Penyimpanan tertentu (sesuai dengan blok memori 9000) dari kontrak sistem adalah nilai hash dari blok memori 9000. Jika kisarannya melebihi 8192, seperti blok memori 1000, maka paling banyak itu adalah satu langkah lagi untuk membuktikan nilai hash blok memori 1808 (= 10000 - 8192), dan kemudian membuktikan nilai hash blok memori 1000 dalam kontrak sistem dalam keadaan rantai blok memori 1808 saat ini.
Ini juga membuka jalan bagi Klien Tanpa Status di masa depan (Stateless Client): node ringan di masa depan tidak perlu lagi menyimpan Header Blok dari semua blok memori dalam sejarah, tetapi ketika diperlukan nilai hash blok memori tertentu dari sejarah atau konten blok memori, maka mintalah orang lain untuk memberikan bukti dengan cara yang sama seperti contoh tantangan penipuan sebelumnya.
EIP-7623:: Meningkatkan biaya calldata
Meningkatkan biaya penggunaan calldata untuk mempublikasikan data, untuk menyediakan ruang keamanan yang cukup untuk meningkatkan Batas Gas Blok dan jumlah Blob.
Dengan meningkatnya permintaan publikasi data Rollup, pengenalan Blob dalam EIP-4844 untuk memungkinkan Rollup menyimpan data dengan harga yang sangat murah, peningkatan jumlah Blob telah lama menjadi upgrade yang diharapkan oleh komunitas, seperti peningkatan Limit Gas Blok yang sedang didorong oleh komunitas baru-baru ini, semuanya mencerminkan kebutuhan ekosistem untuk meningkatkan sumber daya.
!
△ Semakin banyak validator telah menyatakan dukungan untuk meningkatkan Batas Gas Blok.
Namun, baik meningkatkan Batas Gas Blok atau jumlah Blob, akan menimbulkan tekanan lebih besar pada jaringan p2p Ethereum karena volume data transaksi yang lebih besar, yang akan meningkatkan efisiensi serangan oleh penyerang, kecuali biaya publikasi data juga ditingkatkan.
Setelah rilis protokol EIP-7623, biaya calldata akan meningkat 2,5 kali lipat dari sebelumnya 'Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas' menjadi 'Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas'.
Awalnya, jika penyerang menggunakan semua Batas Gas Blok (30M) untuk memasukkan data sampah, ukuran data blok memori akan menjadi sekitar 1,79 MB (30M / 16), dibandingkan dengan ukuran blok memori rata-rata hanya sekitar 100 KB. Jika Batas Gas Blok ditingkatkan menjadi 40M, penyerang dapat menghasilkan blok memori sekitar 2,38 MB. Ketika biaya calldata meningkat sebesar 2,5x, efisiensi penyerang akan berkurang menjadi maksimum 0,72MB untuk 30M dan 0,95MB untuk 40M, sehingga Block Gas Limit dan Blob dapat ditingkatkan dengan lebih percaya diri. Namun, protokol teknis ini tidak ingin mempengaruhi pengguna umum yang "tidak menggunakan calldata untuk mempublikasikan data", sehingga akan menghitung total penggunaan gas transaksi dengan dua cara, mana yang lebih tinggi:
Yang benar-benar terpengaruh akan menjadi Rollup dengan skala kecil, karena Blob memiliki ukuran tetap dan biaya tetap, sehingga efisiensi Rollup kecil dalam menggunakan Blob rendah, lebih murah untuk menggunakan calldata, tetapi setelah EIP-7623, biaya Rollup kecil ini akan meningkat 2,5 kali lipat, mereka mungkin harus beralih ke penggunaan Blob atau mencari cara untuk bekerja sama dan berbagi satu Blob.
EIP-7691: Meningkatkan throughput blob
Meningkatkan jumlah Blob, memberikan lebih banyak ruang untuk publikasi data ke Rollup.
EIP-7691 meningkatkan jumlah Blob dari "Target: 3 Blob, Batas atas: 6 Blob" menjadi "Target: 6 Blob, Batas atas: 9 Blob", memberikan lebih banyak ruang untuk publikasi data kepada Rollup.
Catatan: Selain itu, ada beberapa desain di pasar biaya Blob yang perlu disempurnakan, seperti kecepatan penyesuaian biaya tidak cukup instan dan dasar biaya terlalu rendah, tetapi ini bukan masalah yang ingin dipecahkan oleh protokol teknis ini.
Perjanjian Teknis Lainnya
EIP-7549: Memindahkan indeks komite dari validasi
Sesuaikan konten pemungutan suara validator untuk memudahkan suara dikumpulkan dan mengurangi tekanan pada jaringan P2P.
Validator secara acak ditugaskan ke sekelompok komite dan pasangan untuk setiap zaman
Dalam pemungutan suara blok memori, suara validator di setiap komite dapat digabungkan bersama, yang mengurangi jumlah suara yang disahkan di jaringan P2P, tetapi suara validator akan berisi informasi tentang jumlah komite yang dimiliki validator, yang berarti bahwa suara dari komite yang berbeda tidak dapat dikumpulkan, bahkan jika mereka semua memberikan suara pada blok memori yang sama.
EIP-7549 menghapus informasi bahwa validator milik komite pertama dari konten pemungutan suara, sehingga validator dari komite yang berbeda dapat digabungkan bersama ketika konten pemungutan suara sama, semakin mengurangi jumlah suara yang disahkan di jaringan P2P dan mengurangi tekanan pada jaringan P2P.
EIP-7840: Tambahkan Paket Blob ke Profil EL
Buat file konfigurasi untuk parameter blob di lapisan eksekusi, simpan node lapisan eksekusi kesulitan meminta node lapisan konsensus untuk parameter terkait blob.
Parameter terkait blob saat ini disimpan dalam node lapisan konsensus, tetapi node lapisan eksekusi masih memerlukan parameter ini dalam beberapa kasus (misalnya, RPC eth_feeHistory), sehingga mereka harus meminta node lapisan konsensus.
EIP-7840 membuat file konfigurasi untuk parameter terkait blob pada lapisan eksekusi, dan node di lapisan eksekusi dapat langsung membaca parameter terkait blob melalui file konfigurasi ini tanpa harus meminta node lapisan konsensus.