Masa lalu, sekarang, dan masa depan peningkatan Cancun

Kehidupan Lalu

**Mengapa pemutakhiran Cancun diperlukan? **

• Visi Ethereum adalah menjadi lebih terukur dan lebih aman di bawah premis desentralisasi. Pembaruan Ethereum saat ini juga berkomitmen untuk menyelesaikan trilemma ini, tetapi telah menghadapi tantangan besar.
• Masalah dengan Ethereum:
• Saat ini, TPS dan kinerja rendah, biaya bahan bakar tinggi, dan kemacetan serius. Pada saat yang sama, ruang disk yang diperlukan untuk menjalankan klien Ethereum juga berkembang pesat. Di bagian bawah, pekerjaan memastikan keamanan dan desentralisasi Ethereum Dampak dari algoritma konsensus volume di seluruh lingkungan juga menjadi semakin signifikan.
• Oleh karena itu, di bawah premis desentralisasi, cara mengirimkan lebih banyak data dan mengurangi gas untuk meningkatkan skalabilitas, dan cara mengoptimalkan algoritme konsensus untuk memastikan keamanan adalah semua upaya yang dilakukan Ethereum saat ini.
• Untuk mengatasi trilema keamanan, desentralisasi, dan skalabilitas, Ethereum telah menggunakan mekanisme PoW-ke-PoS untuk lebih mengurangi ambang node, dan juga berencana menggunakan rantai suar untuk menetapkan verifikator secara acak untuk mengoptimalkan keamanan. skalabilitas, Ethereum mempertimbangkan untuk menggunakan sharding untuk mengurangi beban kerja node, yang juga memungkinkan Ethereum membuat banyak blok sekaligus dan meningkatkan skalabilitasnya.
• Ruang saat ini dari setiap blok Ethereum adalah sekitar 200~300 KB, ukuran minimum setiap transaksi adalah sekitar 100 byte, sekitar 2000 transaksi, dibagi dengan waktu blok 12 detik, batas atas TPS Ethereum dibatasi sekitar 100. Data ini jelas tidak dapat memenuhi kebutuhan Ethereum.
• Oleh karena itu, Ethereum Layer 2 berfokus pada cara memasukkan sejumlah besar data ke dalam blok Di luar angkasa, keamanan dijamin melalui bukti penipuan dan bukti validitas, itulah sebabnya lapisan DA menentukan batas atas keamanan, yang juga merupakan konten inti dari pemutakhiran Cancun.
• Rute berulang ekologi Ethereum tidak dapat membangun kinerja benchmark Solana (dalam hal penundaan dan throughput), dan kinerja fragmentasi Near tidak akan terlihat dalam jangka pendek, maupun kinerja eksekusi paralel Sui dan Aptos. Dalam jangka pendek, Ethereum hanya dapat membangun struktur multi-lapisan dengan Rollup sebagai intinya, sehingga Cancun melakukan peningkatan untuk menyelesaikan TPS, gas Biaya dan pengalaman pengembang sangat penting untuk roadmap Ethereum.

**Bagaimana roadmap Ethereum direncanakan? **

Beberapa peningkatan penting terakhir dan tujuannya

• 2020tahun12bulan1* Beacon chain secara resmi dirilis, membuka jalan untuk peningkatan POS*
• 2021**8bulan5** Peningkatan London, EIP1559 mengubah model ekonomi Ethereum;
• 2022tahun9bulan15* Peningkatan Paris (The Merge), menyelesaikan POW pengalihan POS;*
• 2023tahun4bulan12* Ditingkatkan di Shanghai, memecahkan masalah penarikan janji;*
• Model ekonomi dan pemutakhiran terkait POS telah selesai, dan beberapa pemutakhiran berikutnya telah menyelesaikan masalah kinerja Ethereum, TPS, dan pengalaman pengembang;
• Langkah selanjutnya adalah fokus pada peta jalan Ethereum The Lonjakan .
• Target: Capai 100.000+ TPS dalam Rollup.
• Ada skema 2, on-chain dan off-chain:
• Solusi off-chain: mengacu pada Layer2, termasuk rollup, dll.
• Skema on-chain: mengacu pada membuat perubahan langsung di L1, yang merupakan skema sharding yang populer Pemahaman sederhana tentang sharding adalah membagi semua node ke area yang berbeda dan menyelesaikan tugas di setiap area, yang secara efektif akan meningkatkan kecepatan;
• Analisis skema sharding:
• Dilema skema sharding: Sharding digunakan untuk menyertakan sharding negara, sharding transaksi, dll., tetapi sinkronisasi antara shard yang berbeda merupakan masalah. Saat ini, sulit untuk menyelesaikan sinkronisasi data node jaringan skala besar. , tidak hanya tidak dapat menyelesaikan situasi MEV, tetapi juga mungkin memerlukan banyak tambalan untuk mengatasi berbagai masalah yang mungkin timbul, yang tidak dapat direalisasikan dalam jangka pendek.
• Danksharding adalah desain sharding baru yang diusulkan untuk Ethereum, Ide intinya adalah Produksi blok terpusat + Verifikasi terdesentralisasi + **Tahan terhadap penyensoran,**Ini juga terkait dengan ketersediaan data yang disebutkan di bawah Sampling (DAS), Blokir Pemisahan Produsen-Pengemas (PBS) dan Daftar Ketahanan Sensor (Crlist). Signifikansi terbesar dari ide inti Danksharding terletak pada mengubah Ethereum L1 menjadi penyelesaian terpadu (penyelesaian) dan ketersediaan data (Ketersediaan data) Ketersediaan）层。

Skema sharding dibagi menjadi 2 langkah, saat ini dibagi menjadi Proto- sharding danBatalkan Sepenuhnya*****. ***

• Karena itu- danksharding**：**
• memperkenalkan: Bantu pengurangan biaya L2 dan tingkatkan throughput dengan memperkenalkan blob , sekaligus sebagai solusi pra-sharding untuk membuka jalan bagi sharding penuh. Diharapkan setelah proto-danksharding, implementasi danksharing memakan waktu 2-5 tahun.
• Konten: Fitur utama dari proto-danksharding adalah untuk memperkenalkan jenis transaksi blob baru. Blob memiliki karakteristik kapasitas besar dan biaya rendah. Menambahkan paket data semacam itu ke Ethereum dapat memungkinkan semua data rollup disimpan dalam blob, yang sangat meringankan beban rantai utama Tekanan penyimpanan juga dapat mengurangi biaya rollup.
• Penggabungan Sepenuhnya
• Pengantar: Rollup sepenuhnya diperluas, dengan fokus pada pemanfaatan ketersediaan data.
• isi:
• Desain P2P DAS: beberapa pekerjaan dan penelitian yang melibatkan masalah koneksi jaringan sharding data;
• Klien pengambilan sampel ketersediaan data: kembangkan klien ringan yang dapat dengan cepat menentukan apakah data tersedia dengan pengambilan sampel beberapa kilobyte secara acak;
• Penyembuhan diri DA yang efisien: mampu membangun kembali semua data secara efisien di bawah kondisi jaringan terburuk (mis., serangan validator berbahaya, atau waktu henti jangka panjang dari node blok besar).

Rapat Pengembang Inti Ethereum

Setiap pemutakhiran Ethereum bergantung pada pertemuan pengembang inti, melalui diskusi bersama para kontributor inti, dan menurut serangkaian proposal dari pengembang, arah pengembangan masa depan ditentukan

*Definisi: Pertemuan pengembang inti adalah panggilan konferensi mingguan yang diadakan oleh komunitas pengembangan Ethereum, di mana kontributor inti dari berbagai organisasi mendiskusikan masalah teknis dan mengoordinasikan pekerjaan Ethereum di masa mendatang. Mereka menentukan arah teknis masa depan dari protokol Ethereum, dan juga merupakan otoritas yang benar-benar membuat keputusan tentang pemutakhiran Ethereum. Mereka bertanggung jawab untuk memutuskan apakah EIP disertakan dalam pemutakhiran, apakah perlu mengubah peta jalan dan hal penting lainnya hal.

• Proses inti: Proses pemutakhiran yang berpusat pada EIP kira-kira sebagai berikut: Pertama, EIP pada awalnya diterima di konferensi pengembang inti (singkatnya ACD), dan kemudian tim klien akan mengujinya terlepas dari apakah EIP termasuk dalam perbarui atau tidak, dan Setelah tes terakhir, tinjau lagi, lalu putuskan apakah akan memasukkannya ke dalam pemutakhiran yang sebenarnya berdasarkan diskusi.
• Konferensi dibagi ke dalam kategori 2, yaitu pertemuan lapisan konsensus dan pertemuan lapisan eksekutif, yang diadakan secara bergantian setiap minggu:
• ** Pertemuan lapisan konsensus (Semua Konsensus Pengembang Inti - ACDC), berfokus pada lapisan konsensus Ethereum (bukti kepemilikan, rantai suar, dll.);**
• Rapat tingkat Eksekutif ( Semua Solusi Pengembang Inti - ACDE**), yang berfokus pada lapisan eksekusi Ethereum (EVM, **Gas jadwal, dll.).
• Ada 3 jenis pengelola inti Ethereum, terutama organisasi resmi atau forum sukarelawan yang membahas proposal:
• AllCoreDevs: pemelihara kode, bertanggung jawab untuk klien jaringan ETH1, memutakhirkan, memelihara kode Ethereum dan arsitektur inti;
• Bagian "Manajemen Proyek": mendukung pengembang Ethereum, mengoordinasikan hard fork, memantau EIP, dll., dan secara langsung membantu AllCoreDevs dengan komunikasi dan operasi;
• Ethereum Pesulap: Sebuah "forum" yang menginginkan diskusi seputar EIP dan topik teknis lainnya.

Jadwal Pertemuan Terkait Eskalasi Cancun

*Menurut konten diskusi, peningkatan Cancun ini secara kasar dapat dibagi menjadi tahap 5. ***

Tahap 1 - Memperkenalkan Tema Peningkatan

Perkenalkan tugas baruproto-danksharding***,EOF dan "penghancuran diri" * Opcode, diskusi dangkal tentang konten pemutakhiran Shanghai*

• Setelah penggabungan Ethereum selesai pada tanggal 15, 22 September, pertemuan pengembang ditangguhkan selama 4 minggu, memungkinkan pengembang untuk memeriksa EIP yang dibahas dalam pemutakhiran berikutnya selama satu bulan;
• Pada tanggal 28 Oktober 22, pertemuan pengembang pertama setelah merger mengusulkan penerapan proto-danksharding, EOF dan opcode "penghancuran diri" untuk pertama kalinya. Saat ini, ruang lingkup khusus proto-danksharding belum ditentukan, dan beberapa pengembang masih dalam tahap awal Menurut pendapat saya, pemutakhiran Shanghai dapat dibagi menjadi beberapa pemutakhiran kecil, seperti mengaktifkan penarikan ETH yang dijanjikan terlebih dahulu, lalu memutakhirkan EIP 4844, tetapi kelompok pengembang lain menganggap lebih masuk akal untuk mengimplementasikan pemutakhiran yang lebih besar dalam satu langkah.

**Fase 2 - Menentukan jangka waktu dan mempersiapkan upacara KZG

Pada akhir 2022**, konferensi Ethereum terutama berkisar pada ***EOF dan **EIP 4844 Diskusi, sambil terus mempromosikan EIP 4844 Upacara penetapan pra-kredibel diperlukan untuk upacara ***—KZG, pengembang akan berada di *******23 **** Tahun **** 1 **** bulan secara resmi dikonfirmasi peningkatan mana **** 4844 **** akan muncul di ***

• Pada tanggal 22 November, EOF atau proto-danksharding telah disebutkan dalam panggilan konferensi #149 dari semua pengembang inti Ethereum.Saat ini, pengembang masih mempertimbangkan untuk menempatkannya di pemutakhiran Shanghai;
• Dalam pertemuan lapisan konsensus pada 2, 22 Desember, Trent, kepala ekosistem Ethereum Van Epps memperbarui EIP 4844 Kemajuan dalam implementasi upacara pengaturan tepercaya yang diperlukan untuk menghasilkan a Kode keamanan yang digunakan di 4844. mobil van Epps berharap upacara tersebut akan menjadi salah satu yang terbesar di ruang crypto, mengumpulkan 8.000 hingga 10.000 kontribusi, dan periode kontribusi publik untuk upacara tersebut akan berlangsung sekitar 2 bulan dan dimulai sekitar bulan Desember;
• Dalam pertemuan pengembang inti pada hari yang sama, ada beberapa diskusi seputar EOF dan penonaktifan opcode penghancuran diri Pengembang Ethereum Foundation keberatan menunda EOF ke Cancun, dengan alasan bahwa jika perubahan kode tidak dimasukkan di Shanghai, itu akan Kemungkinan memasuki Cancun sangat kecil, mengenai kode penghancuran diri, ada pengembang yang menganjurkan memajukan EIP pada saat itu 4758, tetapi menonaktifkan opcode ini secara langsung akan merusak beberapa aplikasi, dan pengembang percaya bahwa EIP ini harus ditimbang lagi untuk sementara waktu sebelum membuat kasus tepi untuk melindungi jenis kontrak ini;
• Dalam pertemuan pengembang inti pada tanggal 9 Desember 22, implementasi upacara KZG dipromosikan terkait pemutakhiran Cancun, dan EIP saat ini 4844 Upacara penyiapan tepercaya yang diperlukan sudah siap;
• Dalam rapat lapisan konsensus pada 16 Desember 22, tentang EIP 4844, para pengembang mendiskusikan penggabungan dua pull request (PR) yang berbeda ke dalam spesifikasi untuk proto-danksharding, satu terkait dengan bagaimana node menangani ketersediaan data di luar titik tertentu setelah pemangkasan data, dan satu saat blok Kode kesalahan baru akan diperkenalkan untuk memperingatkan node ketika informasi tentang blob hilang
• Selama pertemuan pengembang inti pada 5 Jan 23, para pengembang mencapai konsensus untuk menghapus modifikasi kode terkait penerapan EOF dari pemutakhiran Shanghai, Beiko saat ini menyarankan untuk memutuskan setelah dua minggu apakah EOF harus disertakan di Cancun sedang ditingkatkan;

Tahap III - Pembahasan awal ruang lingkup proposal

Di akhir 231EOF pindah ke Cancun untuk promosi setelah dipindahkan dari promosi Shanghai , sejak itu 2 bulan terutama berputar kecuali untuk EOF* dan EIP Proposal lain selain 4844* dibahas, dan pada saat yang sama, ***EOF diusulkan untuk pindah dari Cancun. Periode waktu ini terutama dihabiskan untuk menggambarkan ruang lingkup proposal untuk peningkatan Cancún. ***

• Dalam pertemuan pengembang inti pada 20 Januari 23, EOF dipindahkan ke Cancun untuk peningkatan;
• Dalam rapat pengembang inti pada 6 Maret 23, proposal awal untuk pemutakhiran Cancun adalah: EIP 4788 (root status rantai suar publik), EIP 2537 (Efisien melakukan operasi seperti verifikasi tanda tangan BLS dan verifikasi SNARKs), EIP-5920 (memperkenalkan PAY opcode baru), dan EIP Implementasi gabungan dari 6189 (untuk membuat SELFDESTRUCT kompatibel dengan pohon Verkle) dan EIP-6190 (mengubah fungsi SELFDESTRUCT untuk hanya menyebabkan perubahan keadaan dalam jumlah terbatas);
• Dalam pertemuan pengembang inti pada 16 Maret 23, kecuali untuk EOF dan EIP 4844, proposal berikut dipertimbangkan untuk disertakan di Cancun: format SSZ, penghapusan SELFDESTRUCT, EIP 2537.EVMMAX.EIP

1153. Instruksi SWAP dan DUP yang tidak terbatas, memperkenalkan kode PAY dan root status beacon di EVM;

• Dalam pertemuan pengembang inti pada tanggal 30 Maret 23, proposal EIP-6780 untuk menonaktifkan SELFDESTRUCT diajukan untuk pertama kalinya, yang juga merupakan proposal untuk menonaktifkan SELFDESTRUCT yang akhirnya diputuskan untuk digunakan oleh Cancun. Namun mengenai penerapan EOF, dari Erigon (EL) Seorang pengembang di tim klien mengatakan EOF 'Terlalu Banyak Perubahan' untuk Bersaing dengan EIP Proposal Peningkatan Ethereum dalam Peningkatan Cancún Mendatang 4844, ada proposal untuk mengimplementasikan EOF di hard fork segera setelah pemutakhiran Cancun;

Tahap keempat - menentukan arah yang jelas untuk peningkatan proposal dan menghapus proposal yang tidak relevan

Dalam 234bulan, ada arahan yang jelas untuk proposal yang harus dicakup oleh pemutakhiran Cancun, dan simpul utama ada di 4*************************************** **************************************************** *********** EIP******, dan tim juga melakukan diskusi lebih mendalam tentang proposal alternatif, di 4bulan Dalam rapat tanggal 27,EIP 6780、EIP 6475 danEIP 1153 ***** ditentukan untuk dimasukkan dalam Cancun, dan pada saat yang sama *EOF dan EVMMAX (dengan * ***EOF **implementasi terkait EIP subset) telah dihapus dari pemutakhiran Cancun, pemutakhiran EOF terutama membantu EVM melakukan kontrol versi, dan dapat menjalankan beberapa rangkaian aturan kontrak secara bersamaan, yang akan membantu perluasan Ethereum selanjutnya, tetapi dengan mempertimbangkan kelayakan seluruh pemutakhiran, ** * EOFUpgrade dapat dilanjutkan dengan upgrade harian

• 234bulan12***, peningkatan Ethereum Shanghai telah selesai;**
• Selama rapat developer inti pada 13.04.23, developer membahas EIP 4844 (untuk mengekspos data tentang root status CL di EL), setidaknya ada sembilan EIP lain yang sedang dipertimbangkan untuk pemutakhiran, yaitu EIP 4844**, DESTIVASI DIRI HAPUS (EIP-6780, EIP 4758.EIP 6046.EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、EVMMAX EIP（EIP 6601 dan EIP 6690), SS perubahan（EIP 6475.EIP 6493.EIP 6465.EIP 6404 dan EIP 6466）、EIP 5656 dan****EIP 6193**；
• Dalam pertemuan pengembang inti pada tanggal 27 April 23, beberapa kemajuan dan kompromi menjadi fokus. Pertama, EIP4844 terus diidentifikasi untuk disertakan dalam pemutakhiran Cancun, dengan penambahan EIP berikut: EIP 6780 (Mengubah fungsi opcode SELFDESTRUCT), EIP 6475 (Tipe Simple Serialization (SSZ) baru untuk mewakili nilai opsional), EIP 1153 (tambahkan opcode baru untuk mengoperasikan status); kedua, EIP yang dipertimbangkan tetapi tidak secara resmi termasuk dalam pemutakhiran adalah EIP 6913 (pengenalan instruksi SETCODE), EIP 6493 (Tentukan skema tanda tangan untuk transaksi yang disandikan SSZ), EIP 4788 (Tampilkan root blok rantai suar di header blok EL), EIP 2537 (menambahkan kurva BLS12-381 sebagai prakompilasi) dan EIP 5656 (memperkenalkan instruksi EVM baru untuk menyalin wilayah memori); terakhir, EOF ** dan ** EVMMAX** (** EOF ** tergantung implementasi ** * EIP* subset) telah dihapus dari pemutakhiran Cancun. EOF Pemutakhiran dipindahkan dari Shanghai pada Konferensi Pengembang Ethereum pada awal 20231***, dan kemudian ditingkatkan dari * *** Dari akhir 1 hingga awal 4 di 23****, ini akan muncul di pemutakhiran Cancun secara default, tetapi di ** 23** **EOF **dihapus lagi dalam rapat pengembang di 29, 4. **

Tahap kelima - penentuan proposal akhir dan penyempurnaan detail

235bulan terutama merampingkan dan meningkatkan detail proposal akhir,SSZ-> Perubahan RLP berarti bahwa duaSSZ di Cancun tidak lagi diperlukan EIP**, jadiEIP 6475 dan 6493 akan dipindahkan dari Cancun untuk peningkatan. Sekaligus, dalam rapat inti pada hari 26, Tim Beiko merekomendasikan agar percakapan di masa mendatang seputar perluasan jangkauan Cancun dibatasi pada lima berikutEIP*:*EIP-5920 * ,5656,7069,4788 dan ****2530 * ****. Para pengembang sekarang telah menentukan sepenuhnya pemutakhiran Cancun. ***

*Pertemuan Konsensus Inti Ethereum pada 5/5/23, membahas EIP yang disebutkan terakhir 4788, sambil menambahkan EIP 6987 dan EIP Diskusi di 6475, kedua proposal ini masing-masing tentang verifikator dan transaksi SSZ;

• Dalam pertemuan lapisan eksekutif Ethereum ke-161 pada 11 Mei 23, Tim Beiko mengatakan bahwa ruang lingkup pemutakhiran Cancun masih dapat dimodifikasi dalam beberapa minggu ke depan, tetapi tanpa saran eksplisit dari pengembang, ruang lingkup pemutakhiran Cancun akan tetap dalam keadaan "default", dan diskusi tentang EIP-4844 menunjukkan bahwa pengembangan Penulis setuju untuk menghapus SSZ dari implementasi EL EIP-4844, **tetapi belum mempengaruhi kemajuan lanjutan dari ** 6475 **. **Selain itu, developer juga sempat membahas dua EIP untuk dipertimbangkan di Cancun, yaitu EIP 6969（EP

1559. dan EIP 5656 (instruksi EVM yang efisien untuk menyalin wilayah memori);

• Perkembangan di 4844 dibahas secara singkat dalam pertemuan Konsensus Pengembang pada 18-Mei-23, seperti mengizinkan aplikasi kontrak pintar di EL untuk memverifikasi bukti status CL;
• Penonaktifan SELFDESTRUCT, perubahan spesifikasi EIP-4844, manajemen opcode, dan potensi penambahan Cancun final dibahas dalam pertemuan Ethereum Core ke-162 pada 25 Mei 2023. Tim Beiko merekomendasikan agar percakapan di masa mendatang seputar perluasan jangkauan Cancun dibatasi pada lima EIP berikut: EIP-5920**, 5656, 7069,* ** 4788* ** dan ** 2530**. Pengembang akan mengonfirmasi dalam beberapa minggu ke depan ** Dencun** (****Deneb

• rangkaian lengkap Cancun****);** *Pada Pertemuan Ethereum Consensus Layer ke-110 pada 1 Juni 2023, seorang peneliti dari Ethereum Foundation memperkenalkan hasil eksperimen data tentang kemampuan node mainnet Ethereum untuk menyebarkan data dalam jumlah besar. EIP Spesifikasi 4844 meningkat dari maksimal 4 blob menjadi 6 per blok. Pada saat yang sama, pengembang sedang mempertimbangkan EIP 4788 termasuk dalam pemutakhiran Cancun;

• Dalam rapat pengembang inti pada 13 Juni 2023, para pengembang secara resmi mengonfirmasi ruang lingkup pemutakhiran, termasuk EIP 4844、EIP 1153、EIP 5656、EIP 6780、EIP 4788；
• Dalam rapat konsensus pada 15 Juni 2023, telah dibahas EIP CL-centric mana yang akan disertakan di Deneb, di antaranya, EIP-6988, EIP-7044, EIP-7045 diusulkan untuk ditambahkan, dan tim klien CL menyetujui ke yang berikut Jaringan uji EIP-4844 Devnet6 akan menguji peningkatan jumlah gumpalan dan membuat keputusan akhir tentang masalah tersebut dalam waktu dua minggu, sementara peneliti Ethereum Foundation Michael Neuder mengusulkan menghapus batas staking 32 ETH untuk membantu mengurangi pertumbuhan set validator aktif;
• Dalam rapat tanggal 22 Juni 2023, tim mengusulkan untuk memindahkan alamat yang telah dikompilasi dari 4844 ke 0xA, mengemasnya dan memindahkan BLS ke alamat lain, meskipun telah dikompilasi melalui EIP 2537, tetapi tidak akan dipertimbangkan di Cancun;
• Dalam rapat konsensus pada 29 Juni 2023, developer terus membahas jumlah blob, membatasi target blob Meningkat dari 2 menjadi 3, meningkatkan batas gumpalan maksimum dari 4 menjadi 6, dan 4844 jaringan uji Devnet #7 akan segera hadir.

hidup ini

• Konten intinya adalah EIP 4844，即Proto-Danksharding
• Kisaran EIP terakhir untuk pemutakhiran Cancun ini adalah: EIP 4844**、EIP 1153、EIP 5656、EIP 6780、EIP 4788. Sementara itu, pada pertemuan Ethereum ACDC ke-111 pada 19 Juni, pengembang terus membahas EIP 6988、** EIP 7044**、**EIP 7045 untuk disertakan di Deneb. Pengembang mengatakan bahwa mereka berencana untuk menggabungkan ketiga EIP tersebut ke dalam spesifikasi Deneb dalam beberapa minggu mendatang.

**Analisis KunciEIP

EIP 4844

• Perkenalan:
• Nama proposal EIP4844 adalah Proto-Danksharding, yang merupakan pra-protokol dari versi lengkap perluasan sharding Danksharding Seluruh rangkaian skema sharding sebenarnya berputar di sekitar Rollup untuk ekspansi on-chain. **Tujuan dari program ini adalah untuk memperluas ** 2 layer **Rollup——****Dengan membantu L2 mengurangi biaya dan meningkatkan throughput , sambil membuka jalan untuk sharding penuh (sharding). **
• Dalam panggilan konferensi 23 Februari, pengembang Ethereum akan EIP Pembaruan 4844 diberi nama Deneb, yang merupakan nama bintang dengan magnitudo pertama di konstelasi Cygnus, yang merupakan EIP pada versi GitHub yang relevan di masa mendatang Nama 4844 akan diperbarui menjadi Deneb; pada pertemuan tanggal 1 Juni 23, akan ada beberapa perubahan dalam spesifikasi pemutakhiran Ethereum berikutnya, yang disebut Deneb di sisi CL dan Cancun di sisi EL;
• Dalam pertemuan pengembang pada 23 Juni, 23 Juni, para pengembang bersiap untuk memperbarui EIP Alamat yang telah dikompilasi dari 4844. Saat ini, pengembang inti telah menambahkan 9 prekompilasi ke EVM dan akan mengaktifkan EIP oleh 4844 dan 4788 masing-masing membuat dua prekompilasi di bawah alamat "0xA" dan "0xB". Dalam rapat konsensus pada 29 Juni, EIP siap diluncurkan Devnet jaringan uji jangka pendek khusus 4844 #7。
• EIP-4844** memperkenalkan jenis transaksi baru - Blob Transkasi。**
• Profil gumpalan:
• Gumpalan, mirip dengan paket data plug-in, awalnya hanya 128 Ruang penyimpanan KB, pada awal pembahasan proposal, target dan batas Blob adalah 2/4, dan disesuaikan menjadi 3/6 dalam pertemuan pengembang pada 9 Juni 23. Artinya, saat ini setiap transaksi di Ethereum dapat membawa hingga tiga transaksi Blob, yaitu 384 KB, target tiap blok Kapasitas gumpalan adalah 6, yaitu 768 KB, yang dapat memuat hingga 16 blob, yaitu 2MB;
• Ini mungkin memiliki dampak tertentu pada stabilitas jaringan, tetapi tim pengembangan Ethereum masih memutuskan untuk menguji terlebih dahulu untuk menghindari kebutuhan garpu keras berikutnya untuk memperluas blok blob.
• Blob **di ** KZG commit Hash Sebagai ** Hash, digunakan untuk verifikasi data, fungsinya mirip dengan ** Merkle ;
• Node menyinkronkan Blob pada rantai Setelah Transaksi, bagian blob akan kedaluwarsa dan dihapus setelah jangka waktu tertentu, dan waktu penyimpanannya adalah tiga minggu.
• Fungsi blob - tingkatkan TPS Ethereum, sekaligus mengurangi biaya
• Saat ini, total volume data seluruh Ethereum hanya sekitar 1TB, dan Blob dapat membawa 2,5-5TB volume data tambahan ke Ethereum setiap tahun, jauh melebihi buku besar itu sendiri beberapa kali;
• Untuk node, mengunduh data blob tambahan 1MB hingga 2MB per blok tidak akan menyebabkan beban bandwidth, dan ruang penyimpanan hanya akan menambah jumlah tetap data blob sekitar 200~400GB per bulan, yang tidak akan mempengaruhi desentralisasi seluruh node Ethereum, tetapi perluasan di sekitar Rollup sangat meningkat;
• Faktanya, node itu sendiri tidak perlu menyimpan semua data blob, karena blob sebenarnya adalah paket data sementara, jadi sebenarnya node hanya perlu mengunduh data dalam jumlah tetap selama tiga minggu.
• Peran EIP-4844** - untuk membuka bab pertama dari narasi Danksharding
• **Ekspansi kapasitas tinggi: **Saat ini, EIP-4844 awalnya dapat memperluas kapasitas L2. Versi lengkap Danksharding dapat memperluas volume data Blob di EIP-4844 dari 1MB menjadi 2MB menjadi 16MB menjadi 32MB, memastikan desentralisasi dan keamanan Sementara mencapai ekspansi yang lebih tinggi;
• **Biaya rendah: **Analis Bernstein menunjukkan bahwa Proto-dank-sharding dapat mengurangi biaya jaringan lapisan 2 hingga 10-100 kali lipat dari level saat ini;
• Data sebenarnya:
• Jaringan uji Opside telah mengerahkan 4844, dan pengamatan saat ini dapat mengurangi biaya rollup hingga 50%;
• Solusi teknis DA EigenLayer tidak mengungkapkan terlalu banyak untuk mengevaluasi datanya;
• Sebenarnya, Celestia tidak ada hubungannya dengan Ethereum, dan biaya DA-nya tidak dapat dinilai sekarang, bergantung pada solusi teknis spesifiknya;
• Solusi Ethstorage adalah mengunggah sertifikat penyimpanan Layer2-nya, dan biaya DA-nya dapat dikurangi hingga 5% dari aslinya;
• Topia berharap dapat mengurangi biaya hingga 100~1000 kali lipat, karena jaringan utama Danksharding juga perlu mempertimbangkan keamanan dan kompatibilitas dengan penyiaran jaringan P2P Layer 1.
• **DA****Solusi: Danksharding (solusi sharding untuk ekspansi Ethereum) saat ini, jika ekspansi berlanjut, beban node mungkin terlalu besar (****16mb **** di atas) dan ketersediaan data yang tidak mencukupi (validitas 30 hari). Solusi: **
• Sampling ketersediaan data (Data Sampling Ketersediaan) - mengurangi beban pada node
• Potong data di Blob menjadi fragmen data, dan biarkan node berubah dari mengunduh data Blob menjadi memeriksa fragmen data Blob secara acak, sehingga fragmen data Blob tersebar di setiap node Ethereum, tetapi data Blob yang lengkap adalah disimpan di seluruh buku besar Ethereum, premisnya adalah bahwa node harus memadai dan terdesentralisasi;
• DAS menggunakan dua teknologi: kode penghapusan (Erasure Coding) dan Komitmen Polinomial KZG (KZG Komitmen);
• Proposer-Packager Separation (PBS)——Memecahkan masalah pembagian kerja node, biarkan node dengan konfigurasi kinerja tinggi bertanggung jawab untuk mengunduh semua data untuk distribusi penyandian, dan biarkan node dengan konfigurasi kinerja rendah bertanggung jawab untuk verifikasi pemeriksaan tempat.
• Node dengan konfigurasi kinerja tinggi dapat menjadi pembangun. Pembangun hanya perlu mengunduh data blob untuk penyandian dan membuat blok (Block), lalu menyiarkannya ke node lain untuk pemeriksaan langsung. Untuk pembangun, karena sinkronisasi kebutuhan volume data dan bandwidth tinggi, sehingga relatif terpusat;
• Node dengan konfigurasi kinerja rendah dapat menjadi pengusul (Pengusul), dan pengusul hanya perlu memverifikasi validitas data dan membuat serta menyiarkan header blok (Block Header), tetapi untuk pengusul (Proposer), volume data sinkronisasi dan persyaratan bandwidth rendah, sehingga akan didesentralisasi.
• Daftar anti-sensor (crList) - memecahkan masalah bahwa pembuat paket dapat dengan sengaja mengabaikan transaksi tertentu dan secara acak menyortir dan menyisipkan transaksi yang mereka ingin dapatkan MEV karena kekuatan peninjauannya yang berlebihan.
• Sebelum pembangun (Builder) mengemas transaksi blok, pengusul (Proposer) pertama-tama akan menerbitkan daftar tahan tinjauan (crList), yang berisi semua transaksi di mempool;
• Pembangun (Builder) hanya dapat memilih untuk mengemas dan menyortir transaksi di crList, yang berarti pembangun tidak dapat memasukkan transaksi pribadinya sendiri untuk mendapatkan MEV, juga tidak dapat dengan sengaja menolak transaksi (kecuali Gas batas penuh);
• Setelah pengepakan, Builder menyiarkan versi terakhir dari daftar transaksi Hash ke Pengusul, dan Pengusul memilih salah satu daftar transaksi untuk menghasilkan header blok (Block Tajuk) dan siaran;
• Ketika node menyinkronkan data, ia akan mendapatkan header blok dari pengusul (Pengusul), dan kemudian mendapatkan Badan blok dari pembuat paket (Builder), untuk memastikan bahwa Badan blok adalah versi terakhir yang dipilih.
• Dual-slot PBS - memecahkan masalah yang membuat pengemas terpusat semakin terpusat dengan mengakuisisi MEV
• Gunakan mode penawaran untuk menentukan blok:
• Pembangun (Builder) membuat header blok dari daftar transaksi setelah mendapatkan crList dan tawaran;
• Pengusul (Pengusul) memilih header blok dan pembangun (Builder) yang akhirnya berhasil menawar, dan pengusul tanpa syarat menerima biaya penawaran yang menang (terlepas dari apakah blok yang valid dihasilkan);
• Panitia verifikasi (Panitia) mengkonfirmasi header blok yang menang;
• Builder mengungkapkan badan blok pemenang;
• Panitia verifikasi (Panitia) melakukan konfirmasi badan blok pemenang dan melakukan voting verifikasi (jika blok lolos maka akan diproduksi blok, jika pengemas dengan sengaja tidak memberikan badan blok maka dianggap blok tidak ada).
• Arti:
• Pertama-tama, pembangun (Builder) memiliki kekuatan lebih untuk mengemas transaksi, tetapi crList yang disebutkan di atas pertama-tama membatasi kemungkinan memasukkan transaksi sementara, dan kedua, jika pembangun (Builder) ingin mendapat untung dengan mengubah urutan transaksi, maka perlu membayar banyak biaya penawaran di awal untuk memastikan dapat memperoleh kualifikasi kepala blok, kemudian keuntungan MEV yang diperolehnya akan semakin berkurang, dan secara keseluruhan akan berdampak pada sarana dan nilai sebenarnya. mendapatkan MEV;
• Namun, pada tahap awal, hanya sejumlah kecil orang yang dapat menjadi pengemas (mengingat masalah kinerja node), sementara kebanyakan orang hanya menjadi pengusul, yang dapat menyebabkan sentralisasi lebih lanjut. Pada saat yang sama, jumlah pengemas sangat kecil Dalam kasus , beberapa penambang berpengalaman dengan kemampuan MEV akan lebih mungkin untuk menawar dengan sukses, yang akan lebih memengaruhi efek solusi MEV yang sebenarnya;
• Memiliki beberapa dampak pada beberapa solusi MEV yang menggunakan lelang MEV.
• Arti:
• EIP 4844 Sebenarnya versi yang sangat disederhanakan Danksharding**: **Ini menyediakan antarmuka aplikasi yang sama dengan Danksharding, termasuk opcode baru bernama Data Hash; dan objek data baru bernama Biner Objek Besar, yaitu Gumpalan;
• proto-danksharding ** digunakan untuk mengimplementasikan ** Danksharding ** spesifikasi "bracket"** (** adalah format transaksi dan aturan verifikasi****) * * Proposal: Namun, belum ada sharding yang diterapkan, dan semua verifikator dan pengguna masih perlu memverifikasi ketersediaan data lengkap secara langsung;
• Mengapa perspektif jangka panjang memilih proto-danksharding bukan EIP 4488 ** secara langsung mengurangi biaya ** layer2 , karena hanya diperlukan penyesuaian kecil saat meningkatkan ke shard penuh di masa mendatang:
• EIP Perbedaan praktis utama antara 4488 dan proto-danksharding adalah bahwa EIP-4488 mencoba meminimalkan perubahan yang perlu dilakukan Ethereum hari ini, sementara proto-danksharding membuat lebih banyak perubahan pada Ethereum hari ini untuk meningkatkan ke Ethereum di masa mendatang. diperlukan untuk sharding versi lengkap;
• Meskipun merupakan tugas yang sangat kompleks untuk mencapai sharding lengkap (dengan sampling ketersediaan data, dll.), dan masih banyak pekerjaan yang harus dilakukan setelah proto-danksharding diimplementasikan, kompleksitas ini akan dikontrol pada lapisan konsensus. Setelah proto-danksharding diterapkan, tim klien lapisan eksekusi, pengembang rollup, dan pengguna tidak perlu melakukan pekerjaan tambahan apa pun untuk beralih ke sharding penuh.
• Untuk mencapai sharding yang lengkap, implementasi sebenarnya dari ** PBS, bukti delegasi, dan pengambilan sampel ketersediaan data perlu diselesaikan, tetapi modifikasi tersebut akan terkonsentrasi di ** CL * * layer, Pengembang tidak perlu menyesuaikan ulang **: 4844 saat ini mengimplementasikan jenis transaksi baru, yang persis sama dengan format transaksi, logika validasi silang konsensus, dan logika lapisan eksekusi yang diperlukan dalam shard lengkap, dan juga diturunkan untuk gumpalan , harga gas independen yang dapat disesuaikan sendiri, untuk mencapai sharding lengkap di masa mendatang, perlu untuk menyelesaikan implementasi PBS yang sebenarnya, bukti delegasi dan pengambilan sampel ketersediaan data, tetapi modifikasi ini hanya pada lapisan CL, dan tidak memerlukan pengembang lapisan EL atau rollup untuk memodifikasi, yang nyaman untuk pengembangan Oleh.

diikuti olehSELFDESTRUCT penghapusan***,EIP-6780 akhirnya ditentukan sebagai solusi yang paling cocok, tetapi pengembang di 26** Di pertemuan tim** mengusulkan untuk menambahkan opcode lain ke proposal iniSETCODE untuk memungkinkan akun terprogram tetap diperbarui***

PENGHANCURAN DIRI penghapusan EIP-6780**：**X

• latar belakang:
• Pada tanggal 21 Maret, Vitalik mengusulkan bahwa SELFDESTRUCT lebih berbahaya daripada kebaikan bagi ekologi Ethereum. Alasan utamanya adalah bahwa ini adalah satu-satunya yang dapat mengubah objek keadaan dalam jumlah tak terbatas dalam satu blok, menghasilkan perubahan dalam kode kontrak, dan dapat digunakan tanpa persetujuan akun. dapat mengubah kode operasi saldo akun, yang memiliki bahaya tersembunyi yang besar dalam keamanan Ethereum;**
• Satu-satunya cara untuk menghapus kontrak on-chain adalah SELFDESTRUCT. Jika Anda memanggil fungsi penghancuran diri dalam kontrak, Anda dapat merusak sendiri kontrak tersebut. Ethereum yang disimpan dalam kontrak akan dikirim ke alamat yang dirancang. Kode dan variabel penyimpanan yang tersisa akan dihapus di mesin negara. Sebenarnya, tindakan penghancuran kontrak terdengar bagus secara teori, tetapi sebenarnya sangat berbahaya. Meskipun fungsi penghancuran diri** dapat membantu pengembang menghapus kontrak pintar dan mentransfer saldo dalam kontrak ke alamat yang ditentukan dalam keadaan darurat, fitur ini juga digunakan oleh penjahat, menjadikannya sarana penyerangan. **
• Dalam pertemuan pengembang inti pada 13 April 23, empat proposal tentang SELFDESTRUCT diperkenalkan untuk berpartisipasi dalam diskusi, yaitu 6780, 4758, 6046 dan 6190, dan EIP berikutnya 6780 ditetapkan sebagai proposal akhir.
• Pendahuluan: penghancuran diri adalah tombol darurat dari kontrak pintar, yang menghancurkan kontrak dan mentransfer ETH yang tersisa ke akun yang ditunjuk.
• EIP 6780: Nonaktifkan SELFDESTRUCT kecuali mereka berada dalam transaksi yang sama dalam kontrak.
• UPDATE: Pada tanggal 26 Mei, tim mengusulkan bahwa selain menghapus SELFDESTRUCT, tambahkan opcode lain - SETCODE, agar akun terprogram tetap diperbarui. (yaitu fungsi pembaruan ditambahkan, dan properti dalam kontrak pintar diperbarui melalui pembaruan/peningkatan), berikut adalah penyerapan EIP Keunggulan 4758, yaitu dapat memberikan ruang dapp untuk melakukan upgrade.

• Alasan: Memanipulasi kode SELFDESTRUCT awalnya memerlukan perubahan ekstensif pada status akun, seperti menghapus semua kode dan penyimpanan. Ini menimbulkan kesulitan untuk menggunakan pohon Verkle di masa mendatang: setiap akun akan disimpan dalam banyak kunci akun berbeda yang tidak akan secara eksplisit ditautkan ke akun root.
• DIUBAH: EIP ini mengimplementasikan perubahan untuk menghapus SELFDESTRUCT, kecuali dalam dua kasus berikut
• Aplikasi yang hanya digunakan untuk SELFDESTRUCT untuk menarik dana akan tetap berfungsi;
• SELFDESTRUCT yang digunakan dalam transaksi yang sama dalam kontrak tidak perlu diubah.
• Signifikansi: Peningkatan keamanan
• Sebelumnya, ada kontrak di mainnet yang menggunakan SELFDESTRUCT untuk membatasi siapa yang dapat melakukan transaksi melalui kontrak;
• Cegah pengguna untuk terus menyetor dana dan berdagang di lemari besi setelah SELFDESTRUCT, maka lemari besi ini dapat menyebabkan siapa pun mencuri token di lemari besi selama penggunaan berulang.

Tiga proposal di bawah ini adalah proposal tentang SELFDESTRUCT yang kemudian dihapus, pada 23tahun**4 6780 secara resmi dipilih dalam rapat pengembang inti pada **28, dan tiga proposal lainnya ditinggalkan. adalah bahwa tim pengembangan Ethereum akhirnya ingin sepenuhnya menghapus opcode SELFDESTRUCT, dan tiga proposal berikut sebagian besar dimodifikasi dengan penggantian. ***

• EIP-4758 (DEPRECATED): Nonaktifkan SELFDESTRUCT dengan mengubah SELFDESTRUCT menjadi SENDALL, yang mengembalikan semua dana ke penelepon (mengirim semua eter di akun ke penelepon), tetapi tidak menghapus kode atau penyimpanan apa pun.
• Alasan: Sama seperti di atas, sebelumnya memanipulasi kode SELFDESTRUCT memerlukan perubahan ekstensif pada status akun, seperti menghapus semua kode dan penyimpanan. Ini menimbulkan kesulitan untuk menggunakan pohon Verkle di masa mendatang: setiap akun akan disimpan dalam banyak kunci akun berbeda yang tidak akan secara eksplisit ditautkan ke akun root.
• Mengubah:
• Opcode SELFDESTRUCT berganti nama menjadi SENDALL, sekarang hanya memindahkan semua ETH di akun ke pemanggil, skema ini tidak lagi menghancurkan kode dan penyimpanan, atau mengubah nomor acak;
• Semua pengembalian uang terkait SELFDESTRUCT telah dihapus
• Arti:
• Mempertahankan fungsionalitas asli dibandingkan dengan EIP-6780, karena beberapa aplikasi masih/perlu menggunakan kode SELFDESTRUCT.
• EIP-6046 (DEPRECATED): Ganti SELFDRUCT dengan DEACTIVATE. Ubah SELFDESTRUCT untuk tidak menghapus kunci penyimpanan dan gunakan nilai khusus di akun nonce untuk menunjukkan penonaktifan
• Alasan: Sama seperti di atas, dengan pohon Verkle, akun akan diatur secara berbeda: properti akun (termasuk penyimpanan) akan memiliki kunci terpisah, tetapi tidak mungkin melintasi dan menemukan semua kunci yang digunakan. Memanipulasi kode SELFDESTRUCT sebelumnya memerlukan perubahan ekstensif pada status akun, membuatnya sangat sulit untuk terus menggunakan SELFDESTRUCT di pohon Verkle.
• Mengubah:
• Ubah aturan yang diperkenalkan oleh EIP-2681 sehingga peningkatan nonce reguler dibatasi oleh 2^64-2 alih-alih 2^64-1;
• SELFDESTRUCT diubah menjadi:
• Jangan hapus kunci penyimpanan apa pun dan biarkan akun tetap di tempatnya;
• Transfer saldo akun ke target **, **atur saldo akun ke 0.
• Setel angka akun ke 2^64-1.
• Tidak ada pengembalian uang sejak EIP-3529;
• Aturan yang relevan SELFDESTRUCT dari EIP-2929 tetap tidak berubah.
• Arti:
• Proposal ini memiliki lebih banyak fleksibilitas daripada penghapusan langsung SELFDESTRUCT lainnya.
• EIP-6190 (DEPRECATED): Mengubah SELFDESTRUCT, kompatibel dengan Verkle, sehingga hanya menyebabkan perubahan status dalam jumlah terbatas
• Alasan: Sama seperti di atas, dengan pohon Verkle, akun akan diatur secara berbeda: properti akun (termasuk penyimpanan) akan memiliki kunci terpisah, tetapi tidak mungkin melintasi dan menemukan semua kunci yang digunakan. Memanipulasi kode SELFDESTRUCT sebelumnya memerlukan perubahan ekstensif pada status akun, membuatnya sangat sulit untuk terus menggunakan SELFDESTRUCT di pohon Verkle.
• DIUBAH: Alih-alih menghancurkan kontrak di akhir transaksi, hal berikut terjadi di akhir transaksi yang memanggilnya:
• Kode kontrak diatur ke 0x1, dan nomor acak diatur ke 2^64-1.
• Slot penyimpanan kontrak ke-0 diatur ke kontrak menggunakan opcode CREATE ( keccak256(alamat kontrak, nonce)) akan dikeluarkan saat alamat. Angka acak selalu 2^64-1.
• Jika kontrak hancur sendiri setelah panggilan diteruskan oleh satu atau lebih kontrak alias, setel slot penyimpanan ke-0 dari kontrak alias ke alamat yang dihitung pada langkah 2;
• Saldo kontrak akan sepenuhnya ditransfer ke alamat di bagian atas tumpukan;
• Bagian atas tumpukan muncul.
• Arti:
• Dirancang untuk memungkinkan SELFDESTRUCT selanjutnya membentuk pohon Verkle dengan perubahan minimal;
• Biaya gas meningkat dengan diterapkannya EIP-2929.

Diikuti olehEIP 1153***, sekaligus menghematgas, membuka jalan bagi desain penyimpanan masa depan***

EIP 1153X

• Singkat: Opcode toko sementara, tambahkan opcode untuk memanipulasi status yang berperilaku sama seperti toko tetapi dibuang setelah setiap transaksi.
• alasan:
• Menjalankan transaksi di Ethereum dapat menghasilkan beberapa frame eksekusi bersarang, setiap frame dibuat oleh instruksi CALL (atau serupa). Kontrak dapat dimasukkan kembali dalam transaksi yang sama, dalam hal ini lebih dari satu kerangka menjadi milik satu kontrak.
• Saat ini, frame ini dapat berkomunikasi dengan dua cara: input/output melalui instruksi CALL, dan melalui pembaruan toko. Komunikasi melalui I/O tidak aman jika ada kerangka perantara milik kontrak lain yang tidak dipercaya.
• dengan masuk kembali lock sebagai contoh, ia tidak dapat bergantung pada bingkai perantara untuk mengomunikasikan keadaan kunci: komunikasi SSTORE melalui penyimpanan SLOAD mahal, dan penyimpanan sementara adalah solusi khusus dan hemat bahan bakar untuk masalah komunikasi antar bingkai.
• Berubah: Dua opcode baru, TLOAD ( 0xb3 ) dan TSTORE ( 0xb4 ), ditambahkan ke EVM.
• Penyimpanan sementara bersifat pribadi untuk kontrak yang memilikinya, seperti halnya penyimpanan persisten, hanya kerangka kontrak pemilik yang dapat mengakses penyimpanan sementaranya. Saat mengakses penyimpanan, semua bingkai mengakses penyimpanan sementara yang sama dengan cara yang sama seperti penyimpanan persisten, tetapi berbeda dari memori.
• Kasus penggunaan potensial:
• masuk kembali kunci;
• Alamat CREATE2 yang dapat dihitung secara on-chain: parameter konstruktor dibaca dari kontrak pabrik, bukan diteruskan sebagai bagian dari hash kode inisialisasi;
• Persetujuan EIP-20 transaksi tunggal, misalnya #temporaryApprove(address pemboros, jumlah uint256);
• Kontrak biaya transfer: bayar biaya ke kontrak token untuk membuka kunci transfer selama transaksi;
• Mode "Sampai": Memungkinkan pengguna untuk melakukan semua tindakan sebagai bagian dari panggilan balik, dan memeriksa apakah "sampai" seimbang di akhir;
• Metadata panggilan proxy: Berikan metadata tambahan untuk mengimplementasikan kontrak tanpa menggunakan data panggilan, seperti nilai parameter konstruktor proxy yang tidak dapat diubah.
• Arti:
• Hemat gas**, dengan lebih sederhana** gas aturan penagihan;
• ** Memecahkan masalah komunikasi antar bingkai; **
• ** Jangan ubah semantik operasi yang ada; **
• Tidak perlu mengosongkan tangki penyimpanan setelah digunakan;
• ** Desain penyimpanan masa depan (seperti pohon ** Verkle **) tidak perlu mempertimbangkan pengembalian uang untuk penyimpanan instan. **

Diikuti dengan 4788, dapat mengurangi asumsi kepercayaan pada kelompok gadai**

EIP 4788**：**X

• Pendahuluan: Root blok suar di EVM. *Perbarui: Dalam pertemuan pengembang pada 15 Juni 23, pengembang mengusulkan untuk membuat perubahan kode untuk meningkatkan pengalaman pemegang saham, EIP ini akan mengungkapkan akar dari blok rantai suar, yang berisi informasi status rantai internal EVM, untuk pengembangan DApp kepercayaan penulis meminimalkan akses.
• DIUBAH: Komit root hash dari setiap blok rantai suar di header payload eksekusi yang sesuai, simpan root tersebut dalam kontrak dalam status eksekusi, dan tambahkan opcode baru untuk membaca kontrak itu.
• Signifikansi: Ini adalah proposal modifikasi kode yang mengusulkan untuk memodifikasi Mesin Virtual Ethereum (EVM) sehingga dapat mengekspos status lapisan kontrak (CL) root Data pada lapisan eksekusi (EL) dapat membuat komunikasi antara berbagai protokol dan aplikasi di jaringan Ethereum menjadi lebih efisien dan aman**. ** Izinkan lebih banyak desain tanpa kepercayaan untuk staking pool, bridging, dan restaking protokol.

Yang terakhir adalah5656***, yang menyediakan opcode salinan memori baru yang efisien, tetapi saat ini dalam keadaan sementara disertakan dalam pemutakhiran karena bandwidth pengujiannya** *

EIP 5656X

• Pendahuluan: MCOPY

• Instruksi salinan memori. Pembaruan: 09.06.23, tim pengembang menyatakan bahwa mereka pada awalnya terpecah pada MCOPY karena sementara ini memecahkan masalah keamanan, mereka masih khawatir untuk menambahkannya ke bandwidth implementasi+pengujian yang diperlukan untuk pemutakhiran, tetapi akhirnya setuju untuk menyertakan EIP , tetapi akan dipertimbangkan untuk dihapus jika pengembang mengalami masalah kapasitas dalam pengujian atau di sisi klien. Oleh karena itu, MCOPY* dalam keadaan untuk sementara disertakan dalam pemutakhiran Cancun. **

• Berubah: Memberikan instruksi EVM yang efisien untuk menyalin wilayah memori.
• Signifikansi: Penyalinan memori adalah operasi dasar, tetapi ada biaya untuk mengimplementasikannya pada EVM.
• Dengan tersedianya instruksi MCOPY, kata kode dan kalimat dapat disalin lebih akurat, yang akan meningkatkan kinerja penyalinan memori sekitar 10,5%, yang sangat berguna untuk berbagai operasi intensif kalkulasi;
• Ini juga akan berguna bagi kompiler untuk menghasilkan bytecode yang lebih efisien dan lebih kecil;
• Ini dapat menghemat sejumlah biaya gas identitas yang telah dikompilasi sebelumnya, tetapi sebenarnya tidak dapat mempromosikan penerapan bagian ini.

Daftar Pendek****EIP

Pada 236bulan15**, rapat konsensus pengembang dibahas di *** Yang mana EIP** berpusat pada CL termasuk dalam Deneb, dimana ****** EIP 6988******、EIP 7044、******EIP 7045 *** *** diusulkan untuk bergabung. ***

EIP 6988**：**X

• Singkat: Mencegah validator yang dipangkas agar tidak terpilih sebagai pengusul blok.
• Signifikansi: Peningkatan hukuman untuk pelanggaran node akan menguntungkan DVT.

EIP 7044**：**X

• Ringkasan: Memastikan bahwa pintu keluar validator yang ditandatangani valid secara permanen.
• Signifikansi: Ini dapat meningkatkan pengalaman pembuat taruhan sampai batas tertentu.

EIP 7045**：**X

• Pendahuluan: akan pengesahan Kisaran inklusi slot meluas dari rolling window satu zaman ke dua zaman.
• Signifikansi: Meningkatkan keamanan jaringan.

Hapus analisis EIP

Pada hari 29*********************** ************************************************* Di ** 160********** ACDE****** pertemuan Ethereum, EVMMAX dan **** EOF **** dipastikan akan dihapus dari pemutakhiran ini, perubahan terkait EOF* dapat diperkenalkan di pemutakhiran harian berikutnya***

EVMMAX EIP**：**

• Singkat: EVMMAX bertujuan untuk memberikan fleksibilitas yang lebih besar pada operasi aritmatika dan skema tanda tangan di Ethereum. Saat ini, terdapat dua proposal EVMMAX, satu dengan EOF dan satu lagi tanpa EOF.
• EIP 6601: Ekstensi Aritmatika Modular EVM (EVMMAX)
• Perubahan: adalah EIP 5843 iterasi, dengan EIP Perbedaan 5843 adalah:
• 6601 memperkenalkan jenis bagian EOF baru yang menyimpan modulus, parameter Montgomery yang telah dihitung sebelumnya, jumlah nilai yang akan digunakan (modulus yang dapat dikonfigurasi runtime masih didukung);
• 6601 menggunakan ruang memori terpisah untuk nilai EVMMAX, dengan opcode muat/simpan baru untuk memindahkan nilai antara memori EVM<->EVMMAX;
• The 6601 mendukung operasi pada moduli hingga 4096 bit (batas tentatif disebutkan dalam EIP).
• Signifikansi: EIP-5843 memperkenalkan penambahan, pengurangan, dan perkalian modular yang efisien untuk Mesin Virtual Ethereum, EIP-6601 peningkatan lebih lanjut atas dasar ini, dengan memperkenalkan bagian pengaturan, ruang memori terpisah, dan opcode baru, untuk operasi aritmatika modular menyediakan pengaturan yang lebih baik dan fleksibilitas sambil mendukung modulus yang lebih besar dan meningkatkan kinerja EVM.
• Sebagai kontrak EVM, memungkinkan operasi aritmatika kurva eliptik pada berbagai kurva (termasuk BLS12-381);
• MULMOD mengurangi biaya gas operasi pada nilai hingga 256 bit sebesar 90-95% dibandingkan dengan ADDMOD opcodes yang ada;
• Mengizinkan prakompilasi modexp diimplementasikan sebagai kontrak EVM;
• Secara signifikan mengurangi biaya verifikasi ZKP dalam fungsi hash aljabar (misalnya MiMC/Poseidon) dan EVM.
• EIP 6690：
• Perubahan: EIP-6990 adalah proposal yang diadaptasi dari EIP-6601 untuk memperkenalkan operasi aritmatika modular yang dioptimalkan ke EVM tanpa bergantung pada EOF. Sementara EIP-6601 membutuhkan EIP-4750 dan EIP-3670 sebagai dependensi, EIP-6990 memberikan solusi yang lebih mandiri. Ini memberikan pendekatan yang lebih disederhanakan dengan menghilangkan ketergantungan pada EOF.
• Signifikansi: Ini mempertahankan fungsionalitas inti EIP-6601 untuk melakukan operasi aritmatika modular yang dioptimalkan pada modulus ganjil hingga 4096 bit, penyederhanaan ini memungkinkan implementasi dan adopsi yang lebih efisien sambil tetap memberikan manfaat yang terkait dengan manfaat EIP-6601.

** EOF perubahan****：**

• Pendahuluan: EOF adalah peningkatan ke EVM, yang memperkenalkan standar kontrak baru dan beberapa opcode baru. Bytecode EVM tradisional (bytecode) adalah urutan instruksi yang tidak terstruktur (unstructured urutan instruksi) bytecode. EOF memperkenalkan konsep wadah, yang mengimplementasikan bytecode terstruktur. Wadah terdiri dari header dan beberapa bagian untuk menyusun bytecode. Setelah pemutakhiran, EVM akan dapat melakukan kontrol versi dan menjalankan beberapa rangkaian aturan kontrak secara bersamaan.
• EIP 663：
• Singkat: Instruksi SWAP dan DUP tidak terbatas
• Signifikansi: Dengan memperkenalkan dua instruksi baru: SWAPN dan DUPN, yang berbeda dari SWAP dan DUP dengan meningkatkan kedalaman tumpukan dari 16 elemen menjadi 256 elemen
• EIP 3540：
• Perkenalan:
• Di masa lalu, bytecode EVM yang digunakan pada rantai tidak memiliki struktur yang ditentukan sebelumnya, dan kode hanya akan diverifikasi sebelum dijalankan di klien. Ini bukan hanya biaya tidak langsung, tetapi juga menghalangi pengembang untuk memperkenalkan yang baru fitur atau fitur lama yang sudah tidak digunakan lagi.
• EIP ini memperkenalkan wadah yang dapat diperluas dan dikontrol versi untuk EVM, dan menyatakan format kontrak EOF Berdasarkan ini, kode dapat diverifikasi saat menerapkan kontrak EOF, yaitu pembuatan Validasi waktu, yang berarti bahwa kontrak yang tidak sesuai dengan format EOF dapat dicegah untuk diterapkan. Perubahan ini mengimplementasikan kontrol versi EOF, yang akan membantu menonaktifkan instruksi EVM yang ada atau memperkenalkan fungsi berskala besar (seperti abstraksi akun) di masa depan.
• Arti:
• Kontrol versi kondusif untuk pengenalan atau penghentian fungsi baru di masa mendatang (seperti pengenalan abstraksi akun);
• Pemisahan kode kontrak dan data bermanfaat untuk verifikasi L2 (op), mengurangi biaya gas validator L2. Pada saat yang sama, pemisahan kode kontrak dan data juga lebih nyaman untuk pekerjaan analisis data on-chain peralatan.
• EIP 3670：
• Pendahuluan: Berdasarkan EIP-3540, tujuannya adalah untuk memastikan bahwa kode kontrak EOF sesuai dengan format dan valid, dan penerapan kontrak yang tidak sesuai dengan format akan dicegah tanpa memengaruhi Warisan bytecode。
• Signifikansi: Berdasarkan wadah yang diperkenalkan oleh 3540, EIP-3670 memastikan bahwa kode dalam kontrak EOF valid, atau mencegahnya untuk diterapkan. Ini berarti opcode yang tidak terdefinisi tidak dapat digunakan dalam kontrak EOF, yang memiliki keuntungan tambahan yaitu mengurangi jumlah versi EOF yang perlu ditambahkan.
• EIP 4200：
• Perkenalan:
• Memperkenalkan opcode khusus EOF pertama: RJUMP, RJUMPI, dan RJUMPV, yang menyandikan tujuan sebagai nilai langsung yang ditandatangani. Kompiler dapat menggunakan opcode JUMP baru ini untuk mengoptimalkan biaya gas saat menerapkan dan menjalankan JUMP karena mereka menghilangkan kebutuhan opcode JUMP dan JUMPI yang ada untuk melakukan jumpdest Waktu berjalan yang diperlukan untuk analisis. EIP ini untuk dinamis Penambahan lompatan.
• Dibandingkan dengan operasi JUMP tradisional, perbedaannya adalah bahwa operasi seperti RJUMP tidak menentukan posisi offset tertentu, tetapi menentukan posisi offset relatif (dari dinamis melompat -> lompatan statis), karena berkali-kali statis lompatan sudah cukup.
• Signifikansi: optimalkan jaringan dan kurangi biaya.
• EIP 4750：
• Ambil fungsi 4200 selangkah lebih maju: dengan memperkenalkan CALLF Dua opcode baru dan RETF mengimplementasikan solusi alternatif untuk situasi yang tidak dapat digantikan oleh RJUMP, RJUMPI dan RJUMPV, sehingga JUMPDEST tidak diperlukan lagi dalam kontrak EOF, sehingga dinamis dilarang melompat.
• Signifikansi: optimalkan kode dengan membagi kode menjadi beberapa bagian.
• EIP 5450：
• Latar belakang: Latar belakang masih bahwa kontrak Ethereum tidak diperiksa saat dikerahkan, dan hanya serangkaian pemeriksaan yang dilakukan saat berjalan, apakah tumpukan meluap (batas atas 1024), apakah gas cukup, dan seterusnya.
• Konten: Menambahkan pemeriksaan validitas lain untuk kontrak EOF, kali ini di tumpukan. EIP ini mencegah situasi di mana penerapan kontrak EOF dapat menyebabkan stack underflow atau overflow (stack aliran bawah/meluap). Dengan cara ini, klien dapat mengurangi jumlah pemeriksaan validitas yang mereka lakukan selama pelaksanaan kontrak EOF.
• Signifikansi: Peningkatan besar adalah membuat pemeriksaan ini yang terjadi selama eksekusi sesedikit mungkin, dan lebih banyak pemeriksaan terjadi saat kontrak diterapkan.

5bulan26****************************** **************************************************** **************************************** 4844Jenis transaksi terkait berubah dariSSZ****** menjadiRLPberarti bahwa Cancun's two a****** SSZ EIP******, jadiEIP 6475 dan 6493** dipindahkan dari Cancun untuk upgrade***

EIP 6475X

• Pendahuluan: EIP Proposal pendamping ke 4844. Proto-danksharding memperkenalkan jenis transaksi baru yang menggunakan pengkodean SSZ alih-alih pengkodean RLP yang digunakan oleh jenis transaksi lainnya.
• PEMBARUAN: Selama Pertemuan Pengembang Inti Lapisan Eksekutif Ethereum ke-161, ada diskusi tentang EIP Pembahasan format serialisasi SSZ untuk 4844 menunjukkan bahwa awalnya developer lebih suka memperkenalkan iterasi awal format SSZ ke EL melalui transaksi blob, dan akhirnya developer berencana untuk memutakhirkan semua jenis transaksi dari RLP ke SSZ, tetapi mengingat alurnya yang tidak jelas dan pasti. tidak Diimplementasikan pada pemutakhiran Cancun, pengembang telah mempertimbangkan untuk menghapus SSZ dari EIP-4844. Setelah banyak diskusi, pengembang setuju untuk menghapus SSZ dari implementasi EL EIP-4844,** tetapi tidak ada penghapusan EIP6475****. **SSZ-> Perubahan RLP berarti dua SSZ di Cancun tidak lagi diperlukan EIP: ** Oleh karena itu EIP 6475 dan 6493 akan dipindahkan dari Cancun untuk peningkatan. **

EIP 6493X

• Pendahuluan: Skema tanda tangan transaksi SSZ. EIP ini menentukan skema tanda tangan untuk transaksi yang disandikan Serialisasi Sederhana (SSZ) dan akan membahas bagaimana node harus menangani jenis transaksi blob yang diformat dalam format SSZ pada CL tetapi dikodekan secara berbeda pada EL. EIP ini adalah bagian dari pembaruan format serialisasi Ethereum untuk konsistensi lintas lapisan;
• Latar belakang: SSZ perubahan
• Pendahuluan: Sederhana SerialiZe, adalah metode serialisasi yang digunakan pada rantai suar.
• SS Perubahan tersebut juga mencakup tiga proposal pendukung lainnya, kali ini hanya 6465 yang diperkenalkan.
• EIP 6465: Root penarikan SSZ, mendefinisikan Merkle-Patricia yang ada Komitmen Migration of Trie (MPT) untuk penarikan Simple Serialization (SSZ);
• EIP 6404 / EIP 6466：
• Keduanya menentukan Merkle-Patricia yang ada Promise Trie (MPT) sedang dalam proses migrasi ke Simple Serialization (SSZ).
• EIP-6404 — Akar transaksi SSZ
• EIP-6466 — dasar penerimaan SSZ

Tim Beiko** menyarankan perkembangan di masa depan seputar perluasan Cancun dalam rapat pengembang inti pada 5bulan26*** Percakapan adalah terbatas pada lima berikutEIP:EIP 5920,5656,7069,4788 dan 2537, proposal tindak lanjut akan dihasilkan dalam lingkup ini. Tindak lanjutEIP 5656**** danEIP 4788 dikonfirmasi sebagai proposal pemutakhiran resmi,5920,7069 dan2537 dihapus di manaEIP 5920 adalah karena kekhawatiran pengembang tentang potensi efek samping dari cara mentransfer ETH*, serta pekerjaan penalaran, pengujian, dan keamanan yang belum selesai, jadi dari pemutakhiran menghapus. ***

EIP 5920**：**X

• Pendahuluan: opcode pembayaran. Memperkenalkan opcode baru PAY untuk transfer Ethereum, yang mengirimkan Ether ke alamat tanpa memanggil salah satu fungsinya.
• Alasan: Saat ini, mengirim ether ke suatu alamat mengharuskan pengguna memanggil fungsi di alamat tersebut, yang memiliki beberapa masalah:
• Pertama, ini membuka vektor untuk serangan reentrancy, karena penerima dapat menelepon kembali ke pengirim;
• Kedua, ini membuka vektor DoS, jadi fungsi induk harus menyadari bahwa penerima mungkin kehabisan bensin atau panggilan balik;
• Akhirnya, opcode CALL tidak perlu mahal untuk transfer eter sederhana, karena memerlukan perluasan memori dan tumpukan, memuat data lengkap penerima, termasuk kode dan memori, dan akhirnya perlu melakukan panggilan, mungkin melakukan hal lain tanpa sengaja.
• Mengubah:
• Opcode baru diperkenalkan: ( PAY) PAY_OPCODE di mana:
• Keluarkan dua nilai dari tumpukan: addrthen val.
• Transfer wei dari val alamat eksekusi ke addr alamat. Jika addr adalah alamat nol, valwei akan diprogram dari alamat eksekusi.
• Potensi jebakan: Kontrak yang ada akan digunakan secara independen dari saldo dompet mereka yang sebenarnya, karena sudah memungkinkan untuk mengirim ether ke alamat tanpa meneleponnya.
• Artinya: hemat gas**. ** *Pembaruan: 09.06.23 PAY telah dihapus dari pemutakhiran karena kekhawatiran tentang potensi efek samping dari cara transfer ETH, dan pekerjaan penalaran, pengujian, dan keamanan yang diperlukan untuk meloloskan proposal.

EIP 7069X

• Pendahuluan: Instruksi PANGGILAN yang dimodifikasi
• DIUBAH: Memperkenalkan tiga instruksi panggilan baru, CALL2, DELEGATECALL2, dan STATICCALL2, yang memiliki efek menyederhanakan semantik. Bertujuan untuk menghapus observabilitas gas dari arahan baru dan membuka pintu ke kelas kontrak baru yang tidak terpengaruh oleh penetapan harga ulang.
• latar belakang:
• Aturan 63/64: batasi kedalaman panggilan dan pastikan penelepon memiliki sisa gas untuk membuat perubahan status setelah penerima kembali;
• Sebelum aturan 63/64 diperkenalkan, diperlukan perhitungan yang sedikit lebih akurat dari gas yang tersedia untuk penelepon. Soliditas memiliki aturan rumit yang mencoba memperkirakan biaya di pihak penelepon dalam mengeksekusi panggilan itu sendiri untuk menetapkan nilai gas yang masuk akal.
• **Saat ini memperkenalkan **63/64th Aturan:
• Inspeksi kedalaman panggilan dihapus;
• Pastikan untuk menyimpan setidaknya 5.000 gas sebelum menjalankan perilaku yang dipanggil;
• Pastikan setidaknya ada 2300 gas yang tersedia untuk perilaku yang dipanggil.
• Aturan subsidi: seperti subsidi 2300 yang terkenal, ketika kontrak memanggil kontrak lain, kontrak yang dipanggil akan mendapatkan 2300 gas digunakan untuk melakukan operasi yang sangat terbatas (cukup untuk melakukan sedikit kalkulasi dan menghasilkan log, tetapi tidak cukup untuk mengisi slot penyimpanan), dan karena menetapkan jumlah gas yang tetap, tidak ada cara bagi orang untuk menentukannya sebagai selama harga gas bisa disesuaikan Jenis perhitungan apa yang bisa didukung oleh gas?
• Signifikansi: ** Membuka jalan untuk pengenalan ** EOF ** di masa mendatang, dan lebih nyaman untuk pengoperasian kontrak besar. **
• Opsionalitas gas yang dihapus: arahan baru tidak mengizinkan gas yang ditentukan batasi, tetapi andalkan "aturan 63/64" (terutama mengacu pada penetapan harga ulang gas untuk sejumlah besar operasi IO di EIP-150, yang meningkatkan konsumsi gas pada operasi tertentu) untuk membatasi gas. Peningkatan penting ini menyederhanakan proses seputar aturan " Allowance", terlepas dari apakah nilainya terkirim atau tidak, penelepon tidak perlu melakukan perhitungan terkait gas;
• Setelah memperkenalkan proposal baru, pengguna selalu dapat mengatasi Out dengan mengirimkan lebih banyak gas dalam transaksi (tentu saja, tunduk pada batas gas blok) kesalahan Gas.
• Sebelumnya saat menaikkan biaya penyimpanan (mis. EIP-1884 meningkatkan gas untuk opcode tertentu) beberapa kontrak yang hanya mengirim gas dalam jumlah terbatas ke panggilan mereka dipatahkan oleh mekanisme penetapan biaya yang baru. Sebelumnya beberapa kontrak memiliki tutup gas yang secara permanen membatasi jumlah gas yang dapat mereka keluarkan, bahkan jika mereka mengirimkannya ke sub-panggilan mereka, itu tidak akan berhasil, tidak peduli berapa banyak gas tambahan yang mereka kirimkan, karena panggilan akan membatasi jumlah yang dikirim.
• Membuka jalan untuk pengenalan EOF: Setelah EVM Object Format (EOF) diperkenalkan, instruksi panggilan lama dapat ditolak dalam kontrak EOF, memastikan bahwa mereka sebagian besar kebal terhadap perubahan harga gas. Karena operasi ini diperlukan untuk menghilangkan observasi gas, EOF akan membutuhkannya sebagai pengganti instruksi yang ada;
• Kode pengembalian status yang lebih nyaman: Fungsi kenyamanan telah diperkenalkan yang mengembalikan kode status yang lebih rinci: sukses (0), pulihkan (1), gagal (2), dan dapat diperpanjang di masa mendatang.

EIP 2537**：**X

• Pendahuluan: Prekompilasi manipulasi kurva BLS12-381.
• Berubah: Menambahkan operasi pada kurva BLS12-381 sebagai prakompilasi ke set yang diperlukan untuk melakukan verifikasi tanda tangan BLS secara efisien dan melakukan verifikasi SNARK, dll.
• Signifikansi: Ethereum dapat membuat bukti kriptografi yang lebih aman dan memungkinkan interoperabilitas yang lebih baik dengan rantai suar**. **

*** PR 3175*** *** Disebutkan tetapi tidak terpilih, tidak ada diskusi lebih lanjut ***

PR 3175**：**X

• Singkat: Proposal ini akan mencegah validator yang dihukum untuk mengusulkan blok saat di-dequeued. Jika lebih dari 50% validator dihukum karena perilaku jahat, validator tersebut masih dapat mengusulkan pemblokiran saat dihapus secara paksa dari jaringan. Mengubah logika ini adalah perubahan lapisan CL yang relatif kecil yang memberikan perlindungan terhadap "mode kegagalan tinggi", kata pengembang.
• Menurut Pertemuan Konsensus Pengembang Inti Ethereum ke-108 pada tanggal 4 Mei, PR 3175 sedang dalam proses diformat sebagai EIP dan akan diubah menjadi EIP-6987, yang untuk alasan keamanan untuk mencegah validator yang disayat terpilih sebagai pengusul blok.

masa depan

Berdasarkan informasi di atas, kami telah mencapai kesimpulan berikut:

**1.**Tujuan utama pemutakhiran Cancun adalah, sesuai urutan prioritas, perluasan kapasitas, keamanan, penghematan gas, dan interoperabilitas:

• Tidak ada keraguan bahwa perluasan adalah prioritas pertama (4844);
• Keselamatan dan penghematan gas adalah prioritas kedua (6780, 1153, 5656 dan 7045), sambil mempertimbangkan pengalaman pengembang tertentu;
• Yang ketiga adalah interoperabilitas, seperti optimalisasi koneksi, komunikasi dan interoperabilitas antar dapps (4788, 7044 dan 6988);
• Data yang diharapkan: testnet 4844 dapat mengurangi opside 50% dari biaya penggabungan; solusi teknis EigenLayer dan Celestia belum mengungkapkan terlalu banyak, dan datanya tidak dapat dievaluasi; Ethstorage memperkirakan bahwa biaya DA akan turun hingga 5% dari aslinya; Topia berharap dapat mengurangi biaya sebanyak 100~1000 kali.

2.** Peningkatan Cancun Di masa depan 2~5 tahun Danksharding**, ini adalah periode pengembangan emas dari proyek lapisan DA****

• Lapisan Batas atas keamanan 2 tergantung pada lapisan DA yang diadopsi Proto-Danksharding akan menguntungkan protokol penyimpanan, protokol modular, dan jaringan ekspansi penyimpanan L1 melalui penyimpanan data negara yang lebih murah.
• **Pertama, **Danksharding kembali ke esensi mesin status Ethereum. V God menyebutkan bahwa tujuan dari protokol konsensus Ethereum bukanlah untuk menjamin penyimpanan permanen semua data historis. Sebaliknya, tujuannya adalah untuk menyediakan papan buletin real-time yang sangat aman dan menyisakan ruang untuk protokol terdesentralisasi lainnya untuk penyimpanan jangka panjang. (Itu tujuan dari protokol konsensus Ethereum bukanlah untuk menjamin penyimpanan semua data historis selamanya. Sebaliknya, tujuannya adalah untuk menyediakan papan buletin real-time yang sangat aman, dan menyisakan ruang untuk protokol terdesentralisasi lainnya untuk melakukan penyimpanan jangka panjang. ）；
• **Kedua, **Danksharding **mengurangi biaya **DA **, tetapi masalah waktu pendaratan aktual dan ketersediaan data juga perlu diselesaikan. **
• DA** pengurangan biaya: **Sebelum pembaruan ini, calldata diperlukan untuk menerbitkan data dari rollup ke rantai utama Ethereum, dan biaya gas untuk memanggil kode ini sangat mahal, yaitu lapisan Pembayaran terbesar 2, EIP 4844 memperkenalkan blob data sebagai ruang data tambahan yang unik untuk rollup, yang akan sangat mengurangi biaya penyimpanan, sehingga mengurangi biaya DA.
• Waktu pendaratan sebenarnya lama, dan ** TPS ** yang ditingkatkan dan ** gas ** yang ditingkatkan masih terbatas, jadi bagus untuk ** DA * * proyek lapisan dalam Pengembangan lanjutan selanjutnya:
• iable tentang danksharding di polynya Dalam artikel sharding data keamanan, diindikasikan bahwa implementasinya akan memakan waktu 2-5 tahun;
• ** Bahkan jika mendarat, itu dapat meningkatkan ** TPS ** dan mengurangi ** gas ** magnitudo masih terbatas:**
• EIP 4844 saat ini mendukung 6 blob, dan masalah perluasan di masa mendatang hanya dapat diselesaikan oleh Danksharding;
• Ruang blok Ethereum saat ini sekitar 200 KB. Setelah Danksharding, ukuran yang direncanakan dalam spesifikasi adalah 32 megabita, yaitu peningkatan sekitar 100 kali lipat. Saat ini, TPS Ethereum adalah sekitar 15. Dalam keadaan ideal, akan menjadi sekitar 1500 setelah dinaikkan 100 kali lipat, yang bukan peningkatan besar dalam hal besaran.
• Oleh karena itu, waktu yang lama untuk mendarat + Perubahan aktual yang terbatas akan menguntungkan DA Proyek lapisan, beberapa seperti Celestia, ** Eigenda** ** ** DA ** proyek masih dapat melewati biaya yang lebih murah dan lebih cepat ** TPS ** untuk bersaing dengan ** Danksharding ** di masa depan , ** Penyimpanan ETH Topia*** dan proyek DA baru lainnya juga dapat mengisi celah pasar sebelum mendarat. **
• Masalah teknis seperti masalah penyimpanan data dan ketersediaan data juga perlu ditangani:
• Ada dua biaya utama DA, satu adalah biaya bandwidth jaringan, yang lainnya adalah biaya penyimpanan, dan 4844 itu sendiri tidak menyelesaikan masalah penyimpanan dan masalah bandwidth rantai blok
• Blob akan disimpan pada lapisan konsensus Ethereum selama sekitar 3 minggu dan kemudian dihapus. Jika Anda ingin menyimpan catatan sejarah lengkap dan menyediakan semua data, solusi saat ini meliputi: dapp sendiri menyimpan data yang terkait dengan dirinya sendiri, dan portal Ethereum jaringan (saat ini sedang dalam pengembangan) atau protokol pihak ketiga seperti penjelajah blok, data historis di BitTorrent, atau penyimpanan spontan oleh pengguna individu.
• Oleh karena itu, Proto-Danksharding akan menguntungkan protokol penyimpanan, protokol modular, dan jaringan ekspansi penyimpanan L1:
• Permintaan untuk memanggil data historis akan mengarah ke saluran pengembangan baru untuk protokol penyimpanan terdesentralisasi atau protokol indeks pihak ketiga;
• Perjanjian modular selanjutnya dapat mengeksekusi transaksi melalui Rollup berkecepatan tinggi, lapisan penyelesaian aman bertanggung jawab atas penyelesaian, dan lapisan ketersediaan data berkapasitas besar dan berbiaya rendah bertanggung jawab atas jaminan;
• Jaringan ekspansi penyimpanan L1 yang bagus, seperti Eth penyimpanan, yang dapat memberikan solusi tingkat kedua untuk penyimpanan yang dapat diprogram dengan biaya penyimpanan yang lebih rendah.

**3.**Manfaat upgrade Cancun L2keanekaragaman, L3, RAAS dan Ketersediaan Data dan Trek Lainnya

• Analisis trek L2:
• Head Layer2, seperti Arbitrum Orbit、OP Tumpukan, Poligon2.0, Fraktal 5 proyek termasuk Penskalaan (di bawah StarkWare) dan HyperChain (di bawah zkSync) akan mendapat manfaat. Pengurangan biaya penyimpanan yang dibawa oleh blob akan membuat seri sebelumnya menjadi lapisan terbatas 2 Biaya pengembangan dan masalah skalabilitas telah sangat ditingkatkan, dan throughput data telah sangat ditingkatkan.Setelah menyelesaikan masalah biaya, lapisan kepala 2 Akan ada peluang untuk terus menerapkan ekologi L3 bersamaan multi-rantai yang sangat disesuaikan untuk fungsi tertentu;
• Kesenjangan dalam biaya operasi antara Layer2 lapis kedua dan Layer2 arus utama akan dipersempit, memberikan beberapa proyek kecil lebih banyak peluang untuk pengembangan, seperti Aztec, Metis, Boba, ZKspace, layer2.finance, dll.;
• Meskipun kebutuhan nyata proyek blockchain modular masih harus diverifikasi, beragam bahasa pemrograman masih dimungkinkan, seperti Starkware's Cario, bahasa seri Move, bahasa seri C, c ++, C # dan Go yang didukung oleh Wasm, yang dapat memperkenalkan Lebih banyak pengembang web2.
• Analisis trek Raas:
• Keunggulan Raas sendiri terletak pada tingkat penyesuaiannya yang tinggi, persyaratan yang disesuaikan > biaya murni dan efisiensi, sehingga pengurangan biaya merupakan keuntungan besar dari Rollup yang disesuaikan.
• Tapi masalah dengan trek RAAS adalah mungkin OverHype, dan bahkan ada keraguan tentang trek RAAS itu sendiri. ** Menghadapi persaingan ** 5 ** kepala** layer2 **, munculnya berbagai ** DA ** baru, dapatkah proyek baru merupakan Kita harus menempatkan tanda tanya di lintasan. **
• Pertama, lapisan tajuk 2 Keuntungan penyebaran rantai aplikasi terletak pada integritas kerangka jaringan dan keamanan ekologi antar rantai, dan keuntungan RAAS terletak pada penyesuaian dan kebebasannya;
• Namun, hambatan teknis RAAS dari seri OP dan ZK saat ini tidak kuat, dan mereka masih dalam tahap testnet dalam jangka pendek, dan tidak ada interaksi produk yang sebenarnya. Mengingat kemajuan aktual RAAS, bentuk teknis dan keuntungan ekologis dari layer3 di masa depan, permintaan RAAS yang sebenarnya diragukan.
• Departemen OP: Meskipun OP peningkatan batuan dasar tumpukan + Peluncuran 4844 telah menghasilkan sedikit peningkatan biaya dan efisiensi, tetapi peningkatan tersebut tidak terlalu menarik;
• Seri ZK: Saat ini, banyak proyek terkemuka mengikuti rute ZKEVM dan lebih memperhatikan kompatibilitas dengan Ethereum, sehingga desain sirkuit akan mengorbankan efisiensi tertentu, dan tidak ditargetkan seperti seri OP. Tapi ZK saat ini ada di pasaran Sebagian besar RAAS masih menggunakan proyek terkemuka (seperti ZkSync) untuk memotong rantai, dan hambatannya masih belum kuat.
• JADI, jangka pendek OP RAAS** **Masih ada ruang untuk pengembangan sebelum ** layer3 ** mendarat. Dalam jangka panjang, ** ZK RAAS ** dan ** layer3 ** mungkin menjadi tren masa depan. **
• ZK RAAS memiliki kerugian biaya yang lebih besar setelah 4844, dan mengkonsumsi lebih banyak daya komputasi daripada OP. Meskipun biaya mengunggah ke L1 lebih kecil dari OP, ini hanya setetes dalam ember dibandingkan dengan biaya proses pembuktian, sementara OP Keuntungannya adalah dapat dengan cepat membangun ekologi dalam waktu singkat, dan masih ada ruang untuk pengembangan sebelum lapisan3 mendarat;
• Untuk aplikasi defi konvensional dan pasar NFT, transformasi rollup bukanlah persyaratan yang kaku. Hanya aplikasi pembayaran atau game yang membutuhkan efisiensi tinggi yang memiliki permintaan rollup yang lebih kuat. Di masa depan, proyek defi mungkin di l2, proyek sosial mungkin di l3 atau off-chain, dan akhirnya data inti dan hubungan ditempatkan di l2. Proyek game perlu ke l3 atau rollup, tetapi mengingat sebagian besar saat ini permainan berantai pada dasarnya adalah Dana, dan ketidakmampuan token untuk beredar secara eksternal telah membawa hambatan pengembangan, ditambah dengan munculnya permainan di seluruh rantai, daya tarik ekologis l3 itu sendiri jauh lebih besar daripada rollup.

**4.**Pemutakhiran Cancun meningkatkan pengalaman pengembang dan pengguna

• Cancun meng-upgrade proposal penting kedua SELFDRUCT penghapusan selanjutnya akan meningkatkan keamanan Ethereum Pada saat yang sama, untuk kemungkinan masalah pembaruan akun terprogram setelah penghapusan, kami berencana untuk memperkenalkan kode operasi baru SETCODE untuk memperbaiki situasi ini;
• EIP Proposal Ketiga untuk Peningkatan Cancun 1153 menambahkan kode operasi penyimpanan sementara, yang pertama dapat menghemat gas, kedua menyelesaikan masalah komunikasi antar-bingkai, dan akhirnya membuka jalan untuk desain penyimpanan di masa mendatang, seperti pohon Verkle, yang tidak perlu mempertimbangkan masalah pengembalian sementara penyimpanan;
• Proposal keempat EIP untuk peningkatan Cancun 5656 memperkenalkan instruksi penyalinan memori MCOPY, yang dapat menyalin kata dan kalimat kode dengan lebih akurat, yang akan meningkatkan kinerja penyalinan memori sekitar 10%;
• Proposal kelima untuk peningkatan Cancun adalah EIP 4788 dapat membuat komunikasi antara berbagai protokol dan aplikasi dalam jaringan Ethereum menjadi lebih efisien dan aman, dan juga memungkinkan desain yang lebih tidak dapat dipercaya untuk kumpulan janji, menjembatani, dan memulihkan protokol;
• Cancun memutakhirkan terbaru (15 Juni 23) mengusulkan pemutakhiran EIP CL-centric: EIP 6988.EIP 7044.EIP 7045, yang meningkatkan keamanan dan kegunaan Ethereum secara detail, seperti meningkatkan pengalaman pemberi dana dan meningkatkan keamanan jaringan.
• Di antara proposal yang dihapus, SSZ-> Transformasi RLP membuat dua SSZ EIP（EIP 6475 dan EIP

6493. telah dihapus dari pemutakhiran Cancun; proposal terkait EOF telah dihapus dari pemutakhiran Cancun setelah dihapus dari pemutakhiran Shanghai, dan saat ini dianggap dapat langsung diimplementasikan dalam pemutakhiran harian selanjutnya; EVMMAX disebabkan oleh beberapa EIP terkait dengan Subset implementasi EOF, sehingga juga dipindahkan dari Cancun untuk ditingkatkan bersama dengan EOF; mengingat potensi efek samping yang mungkin ada dalam cara mentransfer ETH, serta pekerjaan penalaran, pengujian, dan keamanan yang diperlukan untuk meloloskan proposal , EIP 5920 dihapus dari pemutakhiran.

**5. **Hubungan dengan zkml dan abstraksi akun

** Sedikit efek pada zkml**

• ZKML adalah bukti tanpa pengetahuan (Zero Pengetahuan) dan pembelajaran mesin (Mesin Pembelajaran); kombinasi model blockchain dan ML ** memecahkan masalah perlindungan privasi dan verifikasi pembelajaran mesin:
• Perlindungan privasi: kerahasiaan data input, seperti menggunakan informasi pribadi dalam jumlah besar sebagai data untuk memberi makan mesin untuk pelatihan, kerahasiaan informasi pribadi merupakan persyaratan utama; atau parameter model adalah daya saing inti proyek, dan enkripsi juga diperlukan untuk menjaga hambatan persaingan. Saat masalah kepercayaan seperti ini terjadi, model ML terhalang untuk mendapatkan data dan aplikasi berskala lebih besar.
• Verifikasi: Teknologi bukti tanpa pengetahuan memiliki berbagai aplikasi, dan ZKP memungkinkan pengguna untuk mengetahui kebenaran informasi tanpa verifikasi. Dan karena model pembelajaran mesin memerlukan banyak kalkulasi, model ML dapat menghasilkan bukti melalui ZK-SNARK, mengurangi ukuran bukti dan mengurangi kebutuhan daya komputasi ML.
• Persyaratan penyimpanan ZKML ** tidak ada hubungannya dengan ** DA **: **Butuh sesuatu seperti Ruang Teknologi inti dari struktur penyimpanan terpisah ini adalah protokol keamanan baru "bukti SQL". Sederhananya, ini adalah gudang data di sebelah blockchain, memungkinkan pengembang untuk terhubung on-chain dan off-chain dalam format SQL sederhana. data dan memuat hasilnya langsung ke kontrak pintar;
• ZK-SNARKs ** adalah bentuk utama dari ** ZK ** di ** ZKML **, dan dapat beradaptasi dengan kalkulasi on-chain dari ** **ML ** ** Dengan perkembangan kriptografi, terutama rekursif **SNARK bukti akan bermanfaat ZKML Mendarat di rantai:
• ZK-SNARK ditandai dengan kekompakan yang tinggi. Menggunakan ZK-SNARK memungkinkan pembukti menghasilkan bukti singkat, dan pemverifikasi tidak perlu berinteraksi dan hanya perlu melakukan sejumlah kecil perhitungan untuk memverifikasi validitasnya. Pembuktian semacam ini hanya membutuhkan satu kali Sifat interaksi antara pemverifikasi dan pemverifikasi menjadikan ZK-SNARKs efisien dan praktis dalam aplikasi praktis, dan lebih cocok untuk kebutuhan daya komputasi ML pada rantai.
• Saat ini tidak mungkin untuk melatih pada chain, dan hanya hasil perhitungan off-chain yang dapat disimpan pada chain:
• Masalah ML saat ini lebih disebabkan oleh kebutuhan daya komputasi yang tidak terpenuhi dan kinerja rendah yang disebabkan oleh keterbatasan algoritme (tidak dapat dihitung secara paralel). Bukti ZK model besar memerlukan daya komputasi yang lebih tinggi, yang tidak dapat didukung pada rantai. Yang populer saat ini ZK-SNARKs hanya mendukung ML zero-knowledge proof dengan skala kecil dan perhitungan kecil, yaitu, keterbatasan daya komputasi merupakan faktor kunci yang mempengaruhi pengembangan aplikasi blockchain ZKML, dan rantai hanya dapat menyimpan hasil off- perhitungan rantai.

Abstraksi akun yang bagus

• Pertama-tama, peningkatan Cancun dapat dikurangi sampai batas tertentu ZK rollup Bukti Biaya:
• Biaya transaksi zkSync saat ini bergantung pada 3 aspek:
• Biaya sumber daya tetap yang dikonsumsi oleh pemverifikasi untuk menghasilkan bukti SNARK dan memverifikasinya relatif tinggi;
• Biaya gas ketika verifikator mengirimkan bukti SNARK ke mainnet Ethereum, bagian dari biaya ini akan meningkat sesuai dengan kepadatan mainnet;
• Biaya layanan yang dibayarkan oleh pengguna kepada verifikator, termasuk konfirmasi transaksi, siaran pesan, dll.
• Oleh karena itu, jika 4844 diperkenalkan, masalah peningkatan biaya gas yang disebabkan oleh kemacetan jaringan utama akan dikurangi, dan biaya bukti ZKP dapat dikurangi hingga batas tertentu, meskipun tidak seberapa dibandingkan dengan biaya pembuatan bukti, mengingat ZK masih dalam tahap awal, tren pengembangan seri ZK ke depan tidak boleh diremehkan.
• Kedua, abstraksi akun mengubah transaksi ** tx ** tradisional menjadi ** operasi pengguna, lalu ** operasi pengguna menggunakan ECDSA * * Dikemas dalam blok, penyimpanan pada rantai menempati lebih banyak dari sebelumnya, sehingga persyaratan penyimpanan lebih tinggi;
• **Selanjutnya, abstraksi akun dan ** ZK rollup dapat saling melengkapi:
• Masalah abstraksi akun saat ini adalah Gas Biayanya mahal, karena terlalu banyak langkah dan kontrak pintar yang terlibat, jadi ada banyak data yang mengarah ke Gas Biaya mahal, dan ZK Keuntungan dari Rollup adalah dapat mengurangi data;
• Abstraksi akun mempersulit jaminan keamanan: Karena AA melibatkan banyak kontrak, keamanan menjadi masalah, tetapi setelah pembentukan bertahap L2 di masa mendatang, lapisan konsensus tidak akan diubah, kontrak pintar akan memiliki lebih banyak kegunaan, dan keamanan abstraksi akun juga dapat dijamin, dengan bantuan ZK Verifikasi rollup yang tepercaya akan semakin meningkatkan keamanan.
• **Akhirnya, dengan munculnya teknologi ** AI , ini dapat membantu meningkatkan keamanan kontrak on-chain dan mengoptimalkan langkah-langkah transaksi atau aktivitas on-chain:
• AI dan keamanan: Teknologi AI dapat digunakan untuk meningkatkan keamanan dan perlindungan privasi transaksi on-chain. Misalnya, platform keamanan Web3 SeQure menggunakan AI untuk mendeteksi dan mencegah serangan jahat, penipuan, dan kebocoran data, serta menyediakan mekanisme pemantauan dan alarm waktu nyata untuk memastikan keamanan dan stabilitas transaksi pada rantai;
• AI dan optimalisasi aktivitas di rantai: Aktivitas di blockchain meliputi transaksi, eksekusi kontrak, dan penyimpanan data. Melalui analisis cerdas dan kemampuan prediksi AI, aktivitas on-chain dapat dioptimalkan dengan lebih baik dan efisiensi serta kinerja keseluruhan ditingkatkan. AI dapat membantu mengidentifikasi pola transaksi, mendeteksi aktivitas yang tidak biasa, dan memberikan rekomendasi waktu nyata untuk mengoptimalkan alokasi sumber daya untuk jaringan blockchain melalui analisis data dan pelatihan model.
• **Oleh karena itu, pemutakhiran Cancun akan dimulai dari perluasan ruang penyimpanan, hingga integrasi dengan ** ZK Saling melengkapi ** dan kombinasi dengan teknologi ** AI ** secara bertahap akan menguntungkan pengembangan abstraksi akun di masa mendatang. **

**6.*Melihat kembali roadmap Ethereum, apa selanjutnya

• **Saat ini, **Layer2 ** tidak memiliki performa (dalam hal latensi dan throughput) yang mirip dengan ** Solana **, atau sejenisnya ** Near ** Seperti itu kinerja sharding, dan tidak ada kinerja eksekusi paralel seperti ** Sui ** dan ** Aptos **, pemutakhiran Cancun telah meningkatkan posisi terdepan Ethereum sebagai pemimpin; **
• Setelah peningkatan Cancun, diperkirakan beberapa waktu pengembangan utama Fully-Danksharding** (2~5 tahun), *MEV * dan ** Pendaratan PBS (1~3 tahun), abstraksi akun (1~2 tahun), ***ZK * * *Semuanya (3~6 tahun), EOF dan pengalaman pengembang (berapa kali Anda melihat ekstensi?). **

Itu Momok

• Sasaran: Fokus pada pemecahan masalah MEV.
• Solusi: Minimalkan MEV pada lapisan aplikasi melalui "Proposer-Builder Separation (PBS)". Saat ini, blob dapat dioptimalkan, dan layanan pra-konfirmasi atau perlindungan pra-pembebasan dapat diperkenalkan.
• PBS adalah pemisahan produsen blok dan penyortir. Penyortir hanya bertanggung jawab untuk menyortir, terlepas dari rantainya, dan pembuat blok tidak peduli dengan transaksi tersebut, dan langsung memilih paket yang dibuat oleh penyortir dan meletakkannya di rantai. Proses ini akan membuat keseluruhan proses menjadi lebih adil dan meringankan masalah MEV, yang merupakan gagasan eksternalisasi MEV.
• Tingkat penyelesaian PBS masih sangat rendah, dan yang lebih matang Kolaborasi dengan solusi MEV eksternal - mevboost oleh flashbots.
• Versi lanjutan dari "Diabadikan Proposer-Builder Separation (ePBS)" memiliki tingkat penyelesaian yang lebih rendah dan siklus yang lebih panjang, dan diperkirakan tidak akan diterapkan dalam jangka pendek. Selain itu, ada versi progresif dari PEPC dan Optimis Relaying, yang meningkatkan fleksibilitas dan kemampuan beradaptasi dari kerangka kerja PBS

Itu Ambang

• Sasaran: Gunakan pohon Verkel untuk menggantikan Merkle, perkenalkan solusi minimalisasi kepercayaan, aktifkan light node untuk mendapatkan keamanan yang sama dengan node penuh, dan buat verifikasi blok sesederhana dan seportabel mungkin.
• Pada saat yang sama, ZKisasi L1 dengan jelas ditambahkan ke peta jalan Verge.ZK akan menjadi tren umum ekspansi dan percepatan di masa mendatang;
• Solusi: Perkenalkan zk-SNARK untuk menggantikan sistem bukti lama, termasuk klien ringan berbasis SNARK; SNARK untuk perubahan status konsensus; Diabadikan Rollup。
• Pohon Verkle adalah alternatif yang lebih efisien untuk pohon Merkle khusus negara bagian yang tidak perlu menyediakan jalur dari setiap simpul kembar (simpul yang berbagi induk yang sama) ke simpul yang dipilih, tetapi hanya jalur itu sendiri sebagai bukti Bagian dari Verkle bukti 3 kali lebih efisien daripada bukti Merkle.
• Diabadikan Rollup mengacu pada Rollup yang memiliki semacam integrasi konsensus di L1. Keuntungannya adalah ia mewarisi konsensus L1 dan tidak memerlukan token tata kelola untuk melakukan pemutakhiran rollup. Pada saat yang sama, dengan melakukan penghitungan di luar rantai dan hanya memublikasikan hasilnya ke blockchain, dapat meningkatkan jumlah transaksi, tetapi kesulitan teknis implementasinya relatif besar. Kombinasi dari rollup ini di masa depan akan dapat memenuhi sebagian besar kebutuhan ekosistem blockchain dalam beberapa dekade mendatang.

Itu membersihkan

• The Purge mengacu pada tujuan menyederhanakan protokol dengan mengurangi persyaratan penyimpanan untuk berpartisipasi dalam memvalidasi jaringan. Ini terutama dicapai melalui hibernasi dan manajemen sejarah dan negara. Dormansi Data Historis (EIP-4444) memungkinkan klien memangkas data historis yang lebih lama dari satu tahun dan berhenti melayani di tingkat P2P.
• Keadaan tidak aktif. Ketika datang untuk menangani pertumbuhan negara, ada dua tujuan utama: keadaan tanpa kewarganegaraan yang lemah, yang mengacu pada tujuan hanya menggunakan negara untuk membangun blok, tetapi tidak memverifikasinya; Negara sedang diakses. Hibernasi status harus mengurangi status yang perlu disimpan oleh node dengan total 20-50 GB。
• Pada Purge tahap kelima, EIP 4444 secara eksplisit ditulis ke dalam Peta Jalan, EIP-4444 mengharuskan klien untuk menghapus data yang lebih lama dari satu tahun, dan pada tahap ini masih ada beberapa pekerjaan pengoptimalan EVM, seperti menyederhanakan mekanisme prakompilasi GAS dan EVM, dll.;

Itu Berbelanja mewah

• Di babak keenam terakhir Splurge, EIP 4337 juga disebutkan.Sebagai proposal tata letak jangka panjang untuk ekologi dompet, abstraksi akun akan semakin meningkatkan kemudahan penggunaan dompet di masa mendatang, termasuk menggunakan stablecoin untuk membayar bensin, dompet pemulihan sosial, dll.;

Bahan referensi:

• Pembaruan rapat dev inti Ethereum:
• Ethereum Semua Pengembang Inti Hubungi #148 Langganan
• Ethereum Semua Pengembang Inti Hubungi Langganan #149
• Ethereum Panggilan Lapisan Konsensus #99 Langganan
• Ethereum Semua Pengembang Inti Hubungi #150 Langganan
• Ethereum Semua Pengembang Inti Hubungi #151 Langganan
• Ethereum Panggilan Lapisan Konsensus #100 Langganan
• Ethereum Panggilan Semua Pengembang Inti #152 Langganan
• Ethereum Panggilan Semua Pengembang Inti #153 Langganan
• Ethereum Diskusi forum Penyihir asli:
• Ethereum Panggilan Semua Pengembang Inti #156 Langganan
• Ethereum Panggilan Semua Pengembang Inti #157 Langganan
• Ethereum Panggilan Semua Pengembang Inti #158 Langganan
• Ethereum Panggilan Semua Pengembang Inti #159 Langganan
• Ethereum Panggilan Semua Pengembang Inti #160 Langganan
• Ethereum Panggilan Konsensus Semua Pengembang Inti #108 Langganan
• Ethereum Panggilan Semua Pengembang Inti #161 Langganan
• Ethereum Panggilan Konsensus Semua Pengembang Inti #109 Langganan
• Ethereum Panggilan Semua Pengembang Inti #162 Langganan
• Ethereum Panggilan Konsensus Semua Pengembang Inti #110 Langganan *Tim men-tweet tentang peningkatan Ethereum Cancun terbaru (09.06.23):
• Panggilan Konsensus Semua Pengembang Inti Ethereum #111 Langganan
• Ethereum Panggilan Konsensus Semua Pengembang Inti #112 Langganan
• Konten terkait peningkatan Ethereum:
• Pengantar kode penghancuran diri:
• Jelajahi proposal EVMMAX dan BLS12-381
• Selain EIP-4844, apa lagi yang termasuk dalam pemutakhiran Cancun? Mengintip panggilan konsensus terbaru Ethereum
• Konten baru apa yang telah ditambahkan dalam peningkatan Ethereum Shanghai?
• tweet:
• OKE Ventures: Setelah peningkatan Ethereum Shanghai, Cancun meningkatkan peluang investasi potensial- Berita Pandangan ke Depan
• Selain EIP-4844 profil tinggi, proposal apa yang akan disertakan dalam pemutakhiran Cancun?
• V God: Fungsi EVM layak dipertimbangkan untuk dihapus
• Proto-Danksharding FAQ
• Direkomendasikan oleh V God丨 Pemahaman mendalam tentang roadmap sharding Ethereum, membaca laporan ini sudah cukup
• Artikel untuk memahami Danksharding, paket pemutakhiran baru Ethereum
• Menguraikan fakta menarik dan rahasia tersembunyi di peta jalan terbaru Ethereum
• Vitalik: Mengapa SELFDESTRUCT lebih berbahaya daripada kebaikan bagi ekologi Ethereum
• Visi Ethereum:
• Pekerjaan blok Research Fellow Brrr: Bagaimana Proto-Danksharding Mempercepat L1 Ethereum Skalabilitas rollup
• Pertemuan Ethereum ACDC ke-111: Membahas ruang lingkup akhir peningkatan Deneb dan tiga proposal termasuk EIP-7044
• KOL Intip Stacy Muur pada evolusi solusi penskalaan Ethereum: OP Stack、Sewenang-wenang Orbit, Poligon 2.0
• Perbandingan horizontal dari tiga jenis Rollups: Classic Rollups (Optimistic/ZK Rollup）、Diabadikan Rollup, Berdaulat Rollup
• [AMA] Kami adalah EF Research (Pt. 8: 07 Juli, 2022):
• 3 lagu populer yang patut dipikirkan ulang pada tahun 2023
• EDCON Montenegro Pemikiran di Akhir Tahun 2023: Melihat Tren Infrastruktur dan Aplikasi
• Fantasi tak terbatas tentang kemungkinan menggabungkan AI dan Web3
• AI+Web3: Menjelajahi integrasi kecerdasan buatan dan blockchain
• Membandingkan zk-rollup dan op-rollup: menganalisis mengapa zkSync saat ini dari metode verifikasi Biaya gas tinggi
• "Menambahkan volume ke volume": solusi abstraksi akun di era Rollup
• Interpretasi mendalam tentang ZKML: prinsip teknis, skenario aplikasi, keuntungan dan tantangan
• ZKML: teknologi penyebaran model yang mengintegrasikan AI dan blockchain untuk mencapai perlindungan privasi
• bisa data keamanan pecahan
• Dialog dengan Qi, pendiri EthStorage Zhou | Ketersediaan Data dan Penyimpanan Terdesentralisasi
• Baca roadmap pengembangan Ethereum versi terbaru dalam satu artikel
• Tentang Ruang Dan Pengenalan singkat tentang Waktu
• Usulan asli:
• EIP 4844：
• EIP 6780：
• EIP 1153：
• EIP 5920：
• EIP 5656：
• EIP 7069：
• EIP 4788：
• EIP 2537：
• EVMMAX EIP：
• EIP 6601：
• EIP 6990：
• EOF perubahan：
• EIP 663：
• EIP 3540：
• EIP 3670：
• EIP 4200：
• EIP 4750：
• EIP 5450：
• EIP 6475：
• EIP 6493：
• Humas 3175：