Paradigm CTO: Menafsirkan Hard Fork Praha setelah peningkatan Ethereum Cancun

Kata-kata: Georgios Konstantopoulos, CTO, Paradigma

Kompiler: Luffy, Berita Pandangan ke Depan

Tujuan artikel ini adalah untuk memberikan gambaran umum tentang pandangan tim Paradigm Reth tentang EIP apa yang harus dimasukkan dalam Hard Fork Praha (peningkatan besar berikutnya ke Konsensus Ethereum setelah Cancun Hard Fork) dan rencana keseluruhan kami untuk “EL Core Dev” pada tahun 2024. Pandangan berikut terus berkembang dan mewakili pandangan tim Reth saat ini dan tidak selalu mewakili seluruh tim Paradigma.

Kami pikir Hard Fork Praha kemungkinan akan terwujud di EthereumTestnet pada Q3 2024 dan di Mainnet pada akhir tahun. Itu harus mencakup:

• EIP yang terkait dengan staking, seperti EIP-7002 yang mendukung staking ulang dan kumpulan staking tanpa kepercayaan.
• Variasi EVM terpisah.
• Kami bersedia bekerja dengan tim mana pun yang ingin melihat lebih jauh ke Praha atau Hard Fork EL masa depan lainnya dan dengan senang hati memberikan panduan dan bantuan di mana memodifikasi basis kode Reth.

Apa yang harus dilakukan:

• Kami percaya EIP berikut harus diprioritaskan: 7002, 6110, 2537.
• Kami mendukung EOF yang dijelaskan dalam spesifikasi dan berharap untuk menyelesaikan ruang lingkup dan membuat meta EIP sesegera mungkin.
• Kami bersedia menambahkan EIP-4844 Max Blob Gas. Kami tidak memiliki pendapat tentang angka-angka tertentu, tetapi kami mengundang orang-orang data untuk bekerja sama dengan kami dalam topik tersebut.
• Kami dengan senang hati merilis versi EIP-7547: berisi daftar untuk membantu lapisan dasar melawan sensor.

Apa yang tidak boleh dilakukan:

• Kami tidak mendukung dimasukkannya Verkle Tries di Hard Fork Praha, tetapi mendukung tim klien untuk mulai mengerjakan ini pada Q2 2024 dengan komitmen untuk merilis dalam peningkatan Osaka pada tahun 2025.
• Kami tidak berpikir kami harus meningkatkan batas gas eksekusi L1 atau ukuran kontrak, tetapi kami mengundang orang-orang data untuk bekerja dengan kami untuk menyelidiki dampaknya terhadap jaringan. Kami bersedia mengubah persepsi kami karena tes sebelumnya telah menunjukkan bahwa Reth Node dapat menangani peningkatan beban tanpa masalah.
• Kami percaya bahwa EIP Abstraksi Dompet/Akun perlu diuji secara lebih bermusuhan satu sama lain untuk lebih memahami ruang trade-off. Jika mereka tidak saling eksklusif, maka kami akan bersedia untuk menerapkan beberapa EIP terkait AA di masa depan.
• Jika masyarakat setuju dengan backdoor NSA yang dikabarkan, kita dapat melewati batas pada EIP-7212 (secp256r1).
• Topik peta jalan lainnya: Kami tidak memiliki pemahaman aktual tentang kopling garpu CL EIP atau CL / EL, tetapi EIP 7549 dan 7251 terlihat menjanjikan. Kami juga ingin berkontribusi pada pekerjaan PeerDAS dari sisi EL sebanyak mungkin. Saat ini kami ingin menghindari memperkenalkan akar SSZ (EIP 6404, 6465, 6466). Akhirnya, kami melihat peluang untuk memberikan solusi pengarsipan data jangka panjang untuk blob, riwayat, dan status yang kedaluwarsa, karena EIP-4844 dan EIP-4444 menjelaskan hal ini, dan masih harus ditentukan apakah Ethereum bersedia memberikan solusi seperti itu.

Perluas secara rinci di bawah ini.

Hal yang harus dilakukan

Secara abstrak, kami mendukung 1) lebih lanjut menjembatani kesenjangan antara CL dan EL, dan 2) modifikasi EVM dapat dilakukan sebagai karya solo, dan dapat diuji secara terpisah dan paralel.

EIP-7002

EIP ini membuka kumpulan staking ulang dan staking tanpa kepercayaan dengan mengaktifkan Smart Contract di sisi EL untuk mengontrol 1 atau lebih validator di sisi CL. Dalam pandangan kami, setidaknya akan memungkinkan kumpulan staking yang ada untuk menghapus lapisan sentralisasi dari Kontrak Cerdas yang memungkinkan penarikan.

Memperkenalkan prakompilasi stateful ke EVM adalah abstraksi baru yang perlu kita dapatkan dalam implementasi EVM kita, tetapi di luar itu, kami pikir ini adalah EIP langsung.

EIP-6110

EIP memperkenalkan deposito di negara EL, menyederhanakan manajemen negara yang perlu dilakukan pada CL. Dalam hal implementasi, ini mirip dengan pelacakan penarikan CL, jadi secara keseluruhan, kami pikir ini juga merupakan EIP yang sederhana dan mandiri.

EIP-2537

Saat ini ada beberapa implementasi BLS12-381, yang merupakan kurva yang sering digunakan di banyak SNARKs, BLS Signature Algorithms, dan EIP-4844. Kami menganggapnya sebagai kompleksitas implementasi yang rendah karena hanya mengekspos algoritma validasi kurva melalui antarmuka yang telah dikompilasi. Kita mungkin juga membutuhkan hash dari kurva BLS12-381 yang telah dikompilasi sebelumnya.

EOF

*Catatan penerjemah: EOF adalah singkatan dari EVM Object Format, yang diterjemahkan ke format objek Ethereum, dan berisi serangkaian EIP yang menjanjikan untuk membuat eksekusi Ethereum lebih efisien, konsisten, dan dapat ditingkatkan. Rencana awal diimplementasikan dalam Shanghai Upgrade, yang kemudian dihapus. *

EOF akan mendukung Solidity dan Vyper. Tidak ada keraguan bahwa pemformatan kode dan tweak verifikasi akan membuat analisis bytecode jauh lebih sederhana, dan kami sarankan untuk mempertimbangkan hal lain dengan hati-hati. Kami telah merekomendasikan beberapa EIP di bawah ini, tetapi kami bersedia untuk menyesuaikannya lebih lanjut.

Di sisi positif:

• Perubahan khusus EVM yang dapat diuji menggunakan Ethereum / Testnet dan diimplementasikan oleh satu orang.
• Perubahan EVM yang diinginkan Vyper dan Solidity
• Membantu meningkatkan kinerja dan meningkatkan batas ukuran kontrak.
• Menghilangkan kebutuhan untuk analisis bytecode saat runtime untuk EVM. Tanpa caching yang terlibat, waktu untuk analisis bisa setinggi 50% dan meningkat seiring bertambahnya ukuran kontrak.
• Aktifkan pemuatan kode parsial untuk membantu menjalankan Kontrak Cerdas yang besar.
• Devex: Akan memungkinkan masalah “tumpukan terlalu dalam” diperbaiki melalui dupN/swapN dan peningkatan perkakas lainnya.
• Bukti masa depan: Fitur baru dapat diperkenalkan dengan aman di L2, dan alat ini akan tahu apa yang kompatibel.

Aspek buruk:

• Rentang dan target dinamis.
• Tidak ada dorongan kuat oleh para pendukung untuk memasukkannya.
• Dukungan untuk kode warisan masih diperlukan
• Sebelum adopsi, ada ketidaksepakatan sementara antara EthereumMainnet dan rantai EVM lainnya.

Kami percaya fitur EOF berikut harus digunakan pada tahun 2024. Kami merekomendasikan pelingkupan dan berkomitmen untuk implementasi sesegera mungkin. Hal lain harus dipertimbangkan untuk penyebaran berikutnya. Rekomendasi kami adalah:

EIP-3540 (EOF - EVM Object Format v1): Memperkenalkan kode dan wadah data, dan menambahkan struktur dan versi ke bytecode Ethereum.

• EIP-3670 (EOF - Validasi Kode): Menolak kontrak apa pun yang tidak mengikuti format EOF saat digunakan. Jalankan kode yang lebih terstruktur dan nonaktifkan perintah yang tidak valid dan tidak ditentukan.
• EIP-663 (Infinite SWAP &; DUP Instructions): Ini memecahkan masalah “tumpukan terlalu dalam” dalam soliditas dan memiliki efek samping sebagai nilai instan melalui analisis JUMPDEST. Fitur yang sangat diinginkan dari bahasa EVM. EIP-4200 (EOF - Static Relative Jumps): Analisis statis yang lebih baik tanpa lompatan yang tidak pasti. Kompilasi AOT yang lebih baik. Lompatan lebih kondusif untuk penggunaan kembali kode. EIP-4750 (EOF - Fungsi): Membutuhkan resolusi subrutin yang dapat menggunakan lompatan dinamis tetapi tidak lompatan statis. Ini juga memungkinkan kode parsial untuk dimuat, yang bekerja sempurna dengan Verkle untuk meningkatkan batas ukuran kontrak.
• EIP-5450 (EOF - Stack Validation): Verifikasi kode dan persyaratan tumpukan. Hapus runtime, stack, underflow, dan pemeriksaan luapan untuk semua instruksi kecuali CALLF (EIP-4750) EIP-7480 (EOF - Data Section Access Instruction): Memungkinkan akses ke bagian data bytecode. EIP-7069 (Improved CALL Directive): Kemampuan untuk menghilangkan observabilitas gas dari CALL, sehingga memudahkan untuk mengubah harga gas di masa mendatang. Meskipun independen dari EOF, kami melihat ini sebagai kesempatan yang baik untuk memperkenalkannya.

Kami tidak begitu yakin tentang EIP-6206 (EOF - JUMPF dan fungsi non-return). Meskipun memungkinkan pengoptimalan panggilan ekor dalam fungsi EOF, kita masih perlu melihat apa yang dilakukan profil bahasa untuk itu. Jika tidak, kami pikir kami dapat menghapusnya dari cakupan dan menyertakannya dalam pembaruan EOF berikutnya.

Kami memperkirakan beban kerja di atas adalah 1 orang yang bekerja penuh waktu selama 1-2 bulan. Kami bersedia mempersempitnya lebih jauh.

Catatan tentang bytecode lama:

• Meskipun kami dapat melarang bytecode lama/non-EOF baru, kami tidak dapat menghentikan bytecode lama yang ada, yang secara efektif bertindak sebagai EOF “v0”. Bytecode lama masih memerlukan analisis JUMPDEST setelah EOF dan masih memerlukan penanganan kode khusus untuk memecahnya menjadi potongan-potongan di Verkle Trys.
• Sepengetahuan kami, tidak mungkin untuk memverifikasi konversi dari bytecode non-EOF ke EOF tanpa akses ke Kode Sumber, tetapi kami bersedia melihat mekanisme untuk memfasilitasi konversi ini.
• Atau, kami bersedia mencari cara untuk memaksa migrasi negara ke EOF.

Meningkatkan jumlah blob EIP-4844

Kami terbuka untuk perubahan ini, yang akan sesuai dengan peningkatan MAX_BLOB_GAS_PER_BLOCK dan TARGET_BLOB_GAS_PER_BLOCK. EIP-4844 berbunyi:

Pilih nilai TARGET_BLOB_GAS_PER_BLOCK dan MAX_BLOB_GAS_PER_BLOCK agar sesuai dengan target 3 blob (0,375 MB) per blok (hingga 6 blob). Batas awal yang kecil ini dirancang untuk meminimalkan ketegangan pada jaringan yang disebabkan oleh EIP, dan jumlah blob diperkirakan akan meningkat dalam peningkatan di masa mendatang karena jaringan menunjukkan keandalan pada blok yang lebih besar.

Sebenarnya, ini adalah perubahan kode kecil dan kami perlu menyelidiki dampak aktualnya di kumpulan transaksi, tetapi kami pikir kami dapat menggunakan kembali infrastruktur pengujian stres EIP-4844 untuk ini. Mungkin sulit bagi CL untuk menyebarkan lebih banyak gumpalan, dan kami menghormati pendapat tim CL.

Jangan lakukan

Verkle Mencoba

Tl; TL;DR: Kami tidak melihat upaya untuk menyebarkan Verkle pada akhir 2024/awal 2025. Kami merekomendasikan agar tim mengalokasikan sumber daya untuk ini pada Q2 2024 dan berkomitmen untuk menerapkan di Osaka Hard Fork pada Q2-Q3 2025.

Di sisi positif:

• Memungkinkan klien cahaya yang lebih murah dengan bukti penyimpanan yang lebih kecil.
• Stateless eksekusi dengan menyertakan prestate baca di header blok, yang juga dapat menyebabkan peningkatan kinerja karena akses state statis.
• Meningkatkan batas ukuran kontrak dengan memotong bytecode dan memungkinkan pemuatan kode parsial.
• Status kedaluwarsa menjadi lebih dapat diterima karena biaya yang lebih rendah untuk status “memulihkan”.

Kerugian:

• Dampak perubahan dan upaya untuk menerapkan dan menguji.
• Perubahan perhitungan gas: Verkle Tries memperkenalkan ukuran saksi ke dalam fitur perhitungan gas. Kami khawatir bahwa perubahan harga penyimpanan belum dieksplorasi (misalnya, berapa biaya konsumen gas teratas setelah Verkle)?
• Integrasi aplikasi: Apa yang harus dilakukan aplikasi dengan validator Merkle Patricia Trie saat transisi Overlay berjalan? Bagaimana seharusnya eth_getProof berperilaku?

Meskipun kami memahami manfaat Verkle Try, kami pikir lebih banyak pertimbangan perlu diberikan pada bagaimana alat/kontrak pihak ketiga perlu disesuaikan, dan apa dampaknya terhadap Layer 2 dan sejenisnya selama periode transisi. Awalnya kami memiliki keraguan tentang strategi migrasi karena menyatakan bahwa trie Verkle harus diperbarui ketika negara dibaca dari MPT yang sudah ada sebelumnya, tetapi tampaknya tidak lagi demikian. Oleh karena itu, kami mendukung pendekatan overlay sebagai jalur migrasi yang layak.

Dokumentasi untuk strategi migrasi Verkle tampaknya sudah ketinggalan zaman, karena sebagian besar sumber daya masih menyatakan bahwa trie Verkle harus diperbarui saat membaca status dari MPT. Kami ingin melihat dokumentasi transisi dengan pendekatan terbaru, seperti yang luar biasa ini. Kami juga ingin melihat draf EIP tentang strategi transisi.

Oleh karena itu, kami masih mendukung peluncurannya pada tahun 2025 alih-alih menerapkan di Hard Fork Praha.

Batas Gas L1

Kami tidak berpikir menaikkan batas gas L1 akan membuat banyak perbedaan dalam praktik. Kami juga percaya bahwa sebagian besar pelanggan dapat menangani peningkatan beban rata-rata, tetapi kami ingin waspada tentang skenario terburuk, jadi kami tidak menyarankan untuk meningkatkan batas gas L1 saat ini. Kami percaya bahwa meningkatkan batas gas gumpalan adalah solusi yang lebih menjanjikan dalam jangka pendek.

Kami mengundang orang lain untuk bekerja bersama kami dalam penelitian ke arah ini, sering kali seputar pemecahan pengukuran sumber daya di EVM. Disertasi Broken Meter adalah titik awal yang baik untuk penelitian di bidang ini.

Abstraksi Akun

Kami ingin menyertakan 1 EIP atau lebih, tetapi kami ingin melihat lebih banyak perbandingan pengalaman pengguna dan pengalaman pengembang antara setiap proposal untuk lebih memahami trade-off dan upaya integrasi alat. Kami melihat EIP / ERC berikut, tetapi jangan ragu untuk memberi tahu kami:

• EIP-3074: Kode Operasi AUTH dan AUTHCALL ERC-4337: Menggunakan Alt Mempool untuk Abstraksi Akun
• EIP-5806: Transaksi yang Didelegasikan
• EIP-5920: Kode Operasi PAY
• EIP-6913: Direktif SETCODE EIP-7377: Transaksi migrasi
• RIP-7560: Abstraksi Akun Asli - Core EIP - Persekutuan Pesulap Ethereum

Yang perlu kita perhatikan di atas adalah bahwa “abstraksi akun” seperti “fungsi verifikasi abstrak, tujuan utamanya adalah untuk mengimplementasikan rotasi kunci rahasia, membuat kunci multisig, dan memberi kita jalur untuk secara otomatis mencapai resistensi kuantum”.