Pemutakhiran Ethereum Cancun semakin dekat, meninjau masa lalu, sekarang, dan masa depan pemutakhiran Cancun

Penulis: Fat Bird Finance

kehidupan lampau

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, ada TPS dan kinerja yang rendah, biaya bahan bakar yang tinggi, dan kemacetan yang serius. Pada saat yang sama, ruang disk yang diperlukan untuk menjalankan klien Ethereum juga berkembang pesat. Di bagian bawah, beban kerja untuk memastikan keamanan dan desentralisasi Ethereum Dampaknya dari algoritma konsensus di seluruh lingkungan juga menjadi semakin signifikan.

Oleh karena itu, di bawah premis desentralisasi, bagaimana mengirimkan lebih banyak data dan mengurangi gas untuk meningkatkan skalabilitas, dan bagaimana 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 guna mengoptimalkan keamanan. skalabilitas, Ethereum mempertimbangkan untuk menggunakan sharding untuk mengurangi beban kerja node, yang juga memungkinkan Ethereum membuat banyak blok sekaligus dan meningkatkan skalabilitasnya.

Saat ini, ruang setiap blok Ethereum adalah sekitar 200~300KB, ukuran minimum setiap transaksi adalah sekitar 100 byte, sekitar 2000 transaksi, dibagi dengan waktu blok 12 detik, batas atas TPS Ethereum terbatas pada sekitar 100 . Data ini jelas tidak dapat memenuhi kebutuhan Ethereum.

Oleh karena itu, Lapisan Ethereum 2 berfokus pada bagaimana menempatkan data dalam jumlah besar ke dalam ruang blok, dan memastikan keamanan melalui bukti penipuan dan bukti validitas.Inilah mengapa lapisan DA menentukan batas atas keamanan, yang juga merupakan konten inti dari Cancun meningkatkan.

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 dari Sui dan Aptos. jangka pendek, Ethereum hanya dapat Membangun struktur multi-lapisan dengan Rollup sebagai intinya, sehingga pemutakhiran Cancun untuk menyelesaikan TPS, biaya gas, dan pengalaman pengembang sangat penting untuk peta jalan Ethereum.

Bagaimana roadmap Ethereum direncanakan?

Pembaruan penting terkini dan tujuan mereka

Pada tanggal 1 Desember 2020, rantai suar secara resmi dirilis, membuka jalan untuk peningkatan POS

Pembaruan London pada 5 Agustus 2021, EIP1559 mengubah model ekonomi Ethereum;

Pada tanggal 15 September 2022, pemutakhiran Paris (TheMerge) menyelesaikan peralihan POW ke POS;

Pada 12 April 2023, Shanghai ditingkatkan untuk mengatasi masalah penarikan janji;

Model ekonomi dan pemutakhiran terkait POS telah selesai, dan beberapa pemutakhiran berikutnya telah memecahkan masalah kinerja Ethereum, TPS, dan pengalaman pengembang;

Langkah selanjutnya difokuskan pada TheSurge di roadmap Ethereum.

Sasaran: Untuk mencapai 100.000+ TPS dalam Rollup.

Terutama ada 2 solusi, 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 fragmentasi:

Dilema skema sharding: Sharding digunakan untuk menyertakan sharding negara, sharding transaksi, dll., tetapi sinkronisasi antara shard yang berbeda menjadi masalah. Saat ini, secara teknis sulit untuk menyelesaikan sinkronisasi data node jaringan skala besar. Tidak hanya apakah itu tidak dapat menyelesaikan situasi MEV, tetapi juga sejumlah besar tambalan mungkin diperlukan 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 pembuatan blok terpusat + verifikasi terdesentralisasi + ketahanan sensor. Ini juga terkait dengan pengambilan sampel ketersediaan data (DAS) dan produsen blok yang disebutkan di bawah. - Pemisahan Paket (PBS) dan Penyensoran Daftar Tahan (Crlist) terkait. Signifikansi terbesar dari ide inti Danksharding adalah mengubah Ethereum L1 menjadi lapisan penyelesaian terpadu dan ketersediaan data (DataAvailability).

Skema sharding dibagi menjadi 2 langkah, saat ini dibagi menjadi Proto-danksharding dan Fully-Rollup.

Proto-danksharding：

Pendahuluan: Dengan memperkenalkan blob untuk membantu L2 mengurangi biaya dan meningkatkan throughput, ini juga membuka jalan bagi sharding penuh sebagai pra-skema untuk danksharding. Diharapkan setelah proto-danksharding, dibutuhkan waktu 2-5 tahun untuk implementasi danksharing.

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, sangat mengurangi penyimpanan tekanan rantai utama, tetapi juga mengurangi biaya rollup.

Rollup Sepenuhnya

Pendahuluan: Rollup memperluas kapasitas sepenuhnya, dengan fokus pada pemanfaatan ketersediaan data.

isi:

Desain P2P DAS: Beberapa pekerjaan dan penelitian terkait dengan 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 jahat, atau waktu henti yang lama dari node blok besar).

Pertemuan Pengembang Inti Ethereum

Setiap peningkatan Ethereum bergantung pada pertemuan pengembang inti, melalui diskusi bersama 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 diterima terlebih dahulu pada rapat pengembang inti (singkatnya ACD), dan kemudian tim klien akan mengujinya terlepas dari apakah EIP disertakan dalam pemutakhiran atau tidak Setelah tes akhir, tinjau lagi, lalu putuskan apakah akan memasukkannya ke dalam pemutakhiran yang sebenarnya berdasarkan diskusi.

Ada dua jenis pertemuan, yaitu pertemuan lapisan konsensus dan pertemuan lapisan eksekutif, yang diadakan secara bergantian setiap minggu:

Konferensi Lapisan Konsensus (AllCore Developers Consensus - ACDC), berfokus pada lapisan konsensus Ethereum (Proof of Stake, Beacon Chain, dll.);

Konferensi lapisan eksekutif (solusi AllCore Developers - ACDE), yang berfokus pada lapisan eksekusi Ethereum (EVM, jadwal Gas, dll.).

Ada tiga 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;

EthereumMagicians: Sebuah "forum" untuk menginginkan diskusi seputar EIP dan topik teknis lainnya.

Jadwal Pertemuan Terkait Eskalasi Cancun

Menurut isi pembahasannya, pemutakhiran Cancun ini secara kasar dapat dibagi menjadi lima tahap.

Tahap pertama - memperkenalkan tema pemutakhiran

Perkenalkan tugas baru opcode proto-danksharding, EOF, dan "penghancuran diri", diskusikan secara singkat konten pemutakhiran Shanghai

Setelah penggabungan Ethereum selesai pada 15 September 22, 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 opcode proto-danksharding, EOF dan "penghancuran diri" untuk pertama kalinya. Saat ini, ruang lingkup khusus proto-danksharding belum ditentukan, dan beberapa pengembang awalnya berpikir bahwa, pemutakhiran Shanghai dapat dibagi menjadi beberapa pemutakhiran kecil, seperti mengaktifkan penarikan ETH yang dijanjikan terlebih dahulu, dan kemudian memutakhirkan EIP4844, tetapi beberapa pengembang berpikir bahwa mengimplementasikan pemutakhiran yang lebih besar dalam satu langkah lebih berarti.

Fase 2 - Menentukan kerangka waktu dan persiapan upacara KZG

Pada akhir tahun 2022, konferensi Ethereum terutama akan berfokus pada EOF dan EIP4844. Pada saat yang sama, kami akan terus mempromosikan upacara penyiapan pra-kredibel yang diperlukan oleh EIP4844 - upacara KZG. Pengembang akan secara resmi menentukan pemutakhiran 4844 mana yang akan muncul pada 23 Januari

Pada tanggal 22 November, EOF atau proto-danksharding disebutkan dalam panggilan konferensi dari semua pengembang inti Ethereum #149. Saat ini, pengembang masih mempertimbangkan untuk menempatkannya di pemutakhiran Shanghai;

Dalam pertemuan Lapisan Konsensus pada 12/02/22, Trent Van Epps, kepala ekosistem Ethereum, memperbarui kemajuan upacara penyiapan tepercaya yang diperlukan untuk implementasi EIP4844, yang bertujuan untuk menghasilkan kode aman yang akan digunakan dalam EIP4844. VanEpps berharap upacara tersebut akan menjadi salah satu yang terbesar yang pernah ada di ruang crypto, mengumpulkan 8.000 hingga 10.000 kontribusi Periode kontribusi publik dari 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.Seorang pengembang Ethereum Foundation tertentu keberatan untuk menunda EOF ke Cancun, dengan alasan bahwa jika perubahan kode tidak termasuk di Shanghai, itu akan masuk Kemungkinan Cancun sangat kecil. Mengenai kode penghancuran diri, beberapa pengembang menganjurkan memajukan EIP4758 pada saat itu, tetapi menonaktifkan opcode ini secara langsung akan merusak beberapa aplikasi. Pengembang percaya bahwa sebelum membuat kasing tepi untuk melindungi jenis kontrak ini, EIP ini harus ditimbang lagi untuk jangka waktu tertentu;

Dalam rapat pengembang inti pada 9 Desember 22, implementasi upacara KZG dipromosikan terkait pemutakhiran Cancun Saat ini, upacara pengaturan kredibel yang diperlukan oleh EIP4844 sudah siap;

Dalam pertemuan Lapisan Konsensus pada 16/12/22, dengan topik EIP4844, para pengembang membahas penggabungan dua permintaan tarikan (PR) yang berbeda ke dalam spesifikasi untuk proto-danksharding, yang terkait dengan bagaimana node menangani data yang dipangkas dari Satu adalah bahwa ketika informasi tentang gumpalan hilang di blok tertentu, kode kesalahan baru akan diperkenalkan ke node peringatan;

Dalam rapat pengembang inti pada tanggal 5 Januari 23, para pengembang mencapai konsensus untuk menghapus modifikasi kode yang terkait dengan penerapan EOF dari pemutakhiran Shanghai. Saat ini, Beiko menyarankan untuk memutuskan apakah EOF harus dimasukkan dalam rintangan setelah dua minggu. Kun sedang ditingkatkan;

Tahap 3 - Pembahasan Awal Ruang Lingkup Proposal

Pada akhir 23 Januari, EOF dipindahkan ke Cancun untuk ditingkatkan setelah dikeluarkan dari Shanghai. Dalam dua bulan berikutnya, diskusi terutama berfokus pada proposal lain kecuali EOF dan EIP4844. 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 rapat pengembang inti pada 20 Januari 23, EOF dipindahkan ke Cancun untuk ditingkatkan;

Dalam rapat pengembang inti pada 6 Maret 23, proposal awal untuk pemutakhiran Cancun adalah: EIP4788 (akar status rantai suar publik), EIP2537 (melakukan operasi secara efisien seperti verifikasi tanda tangan BLS dan verifikasi SNARK), EIP-5920 (pengenalan baru opcode MEMBAYAR), dan implementasi gabungan dari EIP6189 (untuk membuat SELFDESTRUCT kompatibel dengan pohon Verkle) dan EIP-6190 (mengubah fungsi SELFDESTRUCT untuk hanya menyebabkan perubahan status dalam jumlah terbatas);

Dalam pertemuan pengembang inti pada 16 Maret 23, selain EOF dan EIP4844, proposal berikut dipertimbangkan untuk dimasukkan di Cancun: format SSZ, penghapusan SELFDESTRUCT, EIP2537, EVMMAX, EIP1153, instruksi SWAP dan DUP tanpa batas, pengenalan PAY Beacon status root dalam kode dan EVM;

Dalam rapat 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. Tetapi mengenai penerapan EOF, pengembang dari tim klien Erigon(EL) menyatakan bahwa EOF "telah berubah terlalu banyak" untuk digabungkan dengan proposal peningkatan Ethereum EIP4844 dalam pemutakhiran Cancun yang akan datang, yang diusulkan untuk ditingkatkan di Cancun Implement EOF di hard fork tak lama kemudian;

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

Pada tanggal 23 April, ada arahan yang jelas untuk proposal yang harus dicakup oleh pemutakhiran Cancun. Simpul utamanya adalah pertemuan pengembang pada tanggal 13 April. Pertemuan ini mengusulkan 9 EIP, dan Tim sendiri juga memiliki pemahaman yang lebih mendalam tentang proposal alternatif Diskusi, dalam pertemuan pada tanggal 27 April, EIP6780, EIP6475 dan EIP1153 ditentukan untuk dimasukkan dalam Cancun, sementara EOF dan EVMMAX (subset EIP yang terkait dengan implementasi EOF) telah dihapus dari pemutakhiran Cancun, pemutakhiran EOF terutama dapat membantu Kontrol Versi EVM dan beberapa set aturan kontrak dapat dijalankan pada saat yang sama, yang kondusif untuk ekspansi Ethereum selanjutnya.Namun, mengingat kelayakan seluruh pemutakhiran, pemutakhiran EOF dapat dipromosikan dengan pemutakhiran harian sebagai berikut- ke atas

Pada 12 April 23, pemutakhiran Ethereum Shanghai selesai;

Selain pertemuan dev inti pada 13.04.23 di mana pengembang membahas EIP4844 (untuk mengekspos data tentang root status CL di EL), setidaknya ada sembilan EIP lain yang dipertimbangkan untuk pemutakhiran, yaitu EIP4844, penghapusan SELFDESTRUCT ( EIP-6780, EIP4758, EIP6046, EIP6190), EIP5920, EIP1153, EIP2537, EIP4788, EVMMAXEIPs (EIP6601 dan EIP6690), perubahan SSZ (EIP6475, EIP6493, EIP 6465, EIP6404 dan EIP6466 ), EIP 5656 dan EIP6193 ;

Dalam pertemuan pengembang inti pada 27-23 April, beberapa kemajuan dan kompromi menjadi fokus. Pertama, EIP4844 terus diidentifikasi untuk disertakan dalam pemutakhiran Cancun, sementara EIP berikut telah ditambahkan: EIP6780 (mengubah fungsionalitas opcode SELFDESTRUCT), EIP6475 (jenis Simple Serialization (SSZ) baru untuk mewakili nilai opsional), EIP1153 ( menambahkan baru kedua, EIP yang sedang dipertimbangkan tetapi tidak secara resmi disertakan dalam pemutakhiran adalah EIP6913 (memperkenalkan instruksi SETCODE), EIP6493 (mendefinisikan skema tanda tangan untuk transaksi yang disandikan SSZ), EIP4788 (mengungkapkan akar rantai suar di blok EL header), EIP2537 (menambahkan kurva BLS12-381 sebagai prekompilasi) dan EIP5656 (memperkenalkan instruksi EVM baru untuk menyalin wilayah memori); akhirnya, EOF dan EVMMAX (subset EIP yang terkait dengan implementasi EOF) telah dihapus dari pemutakhiran Cancun. Pembaruan EOF telah dihapus dari pemutakhiran Shanghai di Konferensi Pengembang Ethereum pada awal Januari 2023, dan secara default muncul di pemutakhiran Cancun dari akhir Januari 2023 hingga awal April 2023, tetapi pengembangan pada 29 April 23 EOF dihapus lagi selama pertemuan penulis.

Tahap kelima - penentuan proposal akhir dan penyempurnaan detail

Pada tanggal 23 Mei, detail proposal akhir sebagian besar disederhanakan dan ditingkatkan Perubahan SSZ->RLP berarti bahwa dua SSZEIP di Cancun tidak lagi diperlukan, jadi EIPs6475 dan 6493 akan dipindahkan dari Cancun untuk peningkatan. Juga di kaukus pada tanggal 26, Tim Beiko menyarankan agar pembicaraan di masa mendatang seputar perluasan cakupan Cancun dibatasi pada lima EIP berikut: EIP-5920, 5656, 7069, 4788, dan 2530. Para pengembang sekarang telah menentukan sepenuhnya pemutakhiran Cancun.

Pertemuan Konsensus Inti Ethereum pada 5 Mei 23 membahas EIP4788, yang disebutkan terakhir kali, dan menambahkan diskusi tentang EIP6987 dan EIP6475, masing-masing tentang validator dan transaksi SSZ;

Dalam pertemuan lapisan eksekutif Ethereum ke-161 pada 11 Mei 23, TimBeiko mengatakan bahwa ruang lingkup pemutakhiran Cancun masih dapat dimodifikasi dalam beberapa minggu ke depan, tetapi jika tidak ada saran yang jelas dari pengembang, ruang lingkup pemutakhiran Cancun akan Jadilah Pertahankan status "default", dan diskusi tentang EIP-4844 menunjukkan bahwa pengembang setuju untuk menghapus SSZ dari implementasi EL EIP-4844, tetapi itu tidak memengaruhi kemajuan lanjutan 6475. Selain itu, pengembang juga sempat membahas dua EIP untuk dipertimbangkan di Cancun, yaitu EIP6969 (versi EIP1559 yang dimodifikasi) dan EIP5656 (Instruksi EVM yang efisien untuk menyalin wilayah memori);

Perkembangan 4844 dibahas secara singkat dalam pertemuan Konsensus Pengembang pada 18.05.23, seperti mengizinkan aplikasi kontrak cerdas pada EL untuk memverifikasi bukti status CL;

Penonaktifan SELFDESTRUCT, perubahan spesifikasi EIP-4844, manajemen opcode, dan potensi penambahan Cancun dibahas dalam pertemuan Ethereum Core ke-162 pada 25 Mei 2023. Tim Beiko menyarankan agar percakapan di masa mendatang seputar perluasan cakupan Cancun dibatasi pada lima EIP berikut: EIP-5920, 5656, 7069, 4788, dan 2530. Pengembang akan menentukan jangkauan penuh Dencun (Deneb+Cancun) dalam beberapa minggu ke depan;

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. spesifikasi meningkat dari maksimal 4 blob menjadi 6 per blok. Pada saat yang sama, pengembang sedang mempertimbangkan untuk memasukkan EIP4788 ke dalam pemutakhiran Cancun;

Dalam rapat pengembang inti pada 13 Juni 2023, para pengembang secara resmi mengonfirmasi ruang lingkup pemutakhiran, termasuk EIP4844, EIP1153, EIP5656, EIP6780, dan EIP4788;

Dalam rapat konsensus pada 15 Juni 2023, dibahas EIP CL-centric mana yang akan dimasukkan di Deneb, di antaranya, EIP-6988, EIP-7044, EIP-7045 diusulkan untuk ditambahkan, dan tim klien CL menyepakati berikutnya Uji peningkatan jumlah gumpalan pada jaringan uji EIP-4844 Devnet6, dan buat keputusan akhir tentang masalah ini dalam waktu dua minggu Pada saat yang sama, Michael Neuder, seorang peneliti di Ethereum Foundation, mengusulkan untuk membatalkan 32 ETH batas kontribusi untuk membantu mengurangi pertumbuhan set validator aktif;

Dalam pertemuan pada 22 Juni 2023, Tim mengusulkan untuk memindahkan alamat yang telah dikompilasi dari 4844 ke 0xA, mengemasnya dan memindahkan BLS ke alamat lain, meskipun prekompilasi ini diperkenalkan melalui EIP2537, namun tidak akan dipertimbangkan dalam rencana Cancun;

Dalam rapat konsensus pada 29 Juni 2023, pengembang terus membahas jumlah blob, menaikkan batas target blob dari 2 menjadi 3, dan menaikkan batas blob maksimum dari 4 menjadi 6. Pada saat yang sama, Devnet testnet 4844 #7 akan segera diluncurkan.

hidup ini

Konten intinya adalah EIP4844, Proto-Danksharding

Rentang EIP terakhir untuk pemutakhiran Cancun adalah: EIP4844, EIP1153, EIP5656, EIP6780, dan EIP4788. Pada saat yang sama, dalam pertemuan Ethereum ACDC ke-111 pada 19 Juni, pengembang terus membahas EIP6988, EIP7044, dan EIP7045 untuk dimasukkan ke Deneb. Pengembang mengatakan bahwa mereka berencana untuk menggabungkan ketiga EIP tersebut ke dalam spesifikasi Deneb dalam beberapa minggu mendatang.

Analisis EIP kunci

####EIP4844

Perkenalan:

Nama proposal EIP4844 adalah Proto-Danksharding, yang merupakan solusi pra-sharding untuk versi lengkap Danksharding Seluruh rangkaian skema sharding sebenarnya berputar di sekitar Rollup untuk ekspansi on-chain. Tujuan dari solusi ini adalah untuk memperluas Layer 2 Rollup - dengan membantu L2 mengurangi biaya dan meningkatkan throughput, sambil membuka jalan untuk sharding penuh.

Dalam panggilan konferensi pada tanggal 23 Februari, pengembang Ethereum memutakhirkan EIP4844 dan menamainya Deneb, yang merupakan nama bintang kelas satu di Cygnus. Artinya, nama EIP4844 pada versi GitHub yang relevan akan diperbarui menjadi Deneb di masa depan; Dalam pertemuan pada 1 Maret, ada beberapa perubahan dalam spesifikasi pemutakhiran Ethereum berikutnya, yang disebut Deneb di sisi CL dan Cancun di sisi EL;

Dalam pertemuan pengembang pada tanggal 23 Juni 23, para pengembang akan memperbarui alamat EIP4844 yang telah dikompilasi sebelumnya. Saat ini, pengembang inti telah menambahkan 9 prekompilasi ke EVM, dan akan membuat dua prekompilasi di bawah alamat "0xA" dan "0xB" dengan mengaktifkan masing-masing EIP4844 dan 4788. Dalam rapat konsensus pada tanggal 29 Juni, Devnet#7, jaringan pengujian jangka pendek khusus untuk EIP4844, telah disiapkan.

EIP-4844 memperkenalkan jenis transaksi baru - BlobTranscation.

Pengantar gumpalan:

Blob, mirip dengan paket data plug-in, hanya memiliki ruang penyimpanan 128KB di awal. Di awal pembahasan proposal, target dan batas Blob adalah 2/4. Dalam rapat pengembang pada 9 Juni , 23, disesuaikan menjadi 3/6 . Artinya, saat ini setiap transaksi di Ethereum dapat membawa hingga tiga transaksi Blob, yaitu 384KB, dan kapasitas targetBlob setiap blok adalah 6, yaitu 768KB, dan dapat membawa maksimal 16 transaksi Blob, yaitu 2MB;

Ini mungkin memiliki dampak tertentu pada stabilitas jaringan, tetapi tim pengembangan Ethereum masih memutuskan untuk mengujinya terlebih dahulu untuk menghindari kebutuhan hard fork berikutnya untuk memperluas blok blob.

Blob menggunakan KZGcommit Hash sebagai Hash untuk verifikasi data, mirip dengan Merkle;

Setelah node menyinkronkan BlobTransaction pada rantai, bagian Blob akan kedaluwarsa dan dihapus setelah jangka waktu tertentu, dan waktu penyimpanannya adalah tiga minggu.

Peran Blob - tingkatkan TPS Ethereum sambil 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, yang secara langsung melebihi buku besar itu sendiri beberapa kali;

Untuk node, mengunduh 1MB hingga 2MB data blob 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;

Dan 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 - membuka bab pertama dari narasi Danksharding

Ekspansi tinggi: Saat ini, EIP-4844 pada awalnya dapat memperluas kapasitas L2. Versi lengkap Danksharding dapat memperluas jumlah data Blob di EIP-4844 dari 1MB menjadi 2MB menjadi 16MB menjadi 32MB, yang memastikan desentralisasi dan keamanan.Ekspansi tinggi;

Biaya rendah: Menurut analis Bernstein, Proto-dank-sharding dapat mengurangi biaya jaringan layer 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, dan biaya DA-nya dapat dikurangi hingga 5% dari aslinya;

Topia berharap dapat mengurangi biaya hingga 100 hingga 1000 kali lipat, karena jaringan utama Danksharding juga perlu mempertimbangkan keamanan dan kompatibilitas dengan penyiaran jaringan P2P Layer 1.

Solusi DA: Danksharding (solusi sharding untuk ekspansi Ethereum) saat ini dapat menyebabkan masalah seperti beban node yang berlebihan (di atas 16mb) dan ketersediaan data yang tidak mencukupi (masa berlaku 30 hari). Larutan:

Sampling DataAvailability - mengurangi beban 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 lengkap disimpan di seluruh buku besar Ethereum In Fang, premisnya adalah bahwa node harus memadai dan terdesentralisasi;

DAS menggunakan dua teknologi: pengkodean penghapusan (ErasureCoding) dan komitmen polinomial KZG (KZGCommitment);

Pemisahan pengusul-paket (PBS) - memecahkan masalah pembagian kerja antar node, memungkinkan node dengan konfigurasi kinerja tinggi untuk bertanggung jawab mengunduh semua data untuk penyandian dan distribusi, dan memungkinkan node dengan konfigurasi kinerja rendah untuk bertanggung jawab atas pemeriksaan di tempat dan verifikasi.

Node dengan konfigurasi kinerja tinggi dapat menjadi pembangun. Pembangun hanya perlu mengunduh data blob untuk penyandian dan membuat blok, lalu menyiarkan ke node lain untuk pemeriksaan langsung. Untuk pembangun, Karena volume data sinkronisasi dan kebutuhan bandwidth tinggi, maka akan relatif terpusat;

Node dengan konfigurasi kinerja rendah dapat menjadi pengusul (Pengusul). Pengusul hanya perlu memverifikasi validitas data dan membuat serta menyiarkan header blok (BlockHeader). Namun, untuk pengusul (Pengusul), jumlah data sinkron dan kebutuhan bandwidth relatif tinggi, rendah, sehingga akan terdesentralisasi.

Daftar anti-sensor (crList) - memecahkan masalah bahwa pembuat paket dapat dengan sengaja mengabaikan transaksi tertentu dan menyisipkan transaksi yang ingin mereka dapatkan MEV karena kekuatan tinjauan mereka yang berlebihan.

Sebelum pembangun (Builder) mengemas transaksi blok, pengusul (Pengusul) 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 bahwa pembangun tidak dapat memasukkan transaksi pribadinya sendiri untuk mendapatkan MEV, juga tidak dapat dengan sengaja menolak transaksi (kecuali Gaslimit penuh);

Setelah pengemasan, Builder menyiarkan versi terakhir dari daftar transaksi Hash ke Pengusul, dan Pengusul memilih salah satu daftar transaksi untuk menghasilkan header blok (BlockHeader) dan menyiarkannya;

Ketika node menyinkronkan data, itu 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 menjadi 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) mengkonfirmasikan header blok pemenang;

Builder membuka badan blok pemenang;

Panitia verifikasi (Panitia) melakukan konfirmasi badan blok pemenang dan melakukan voting verifikasi (jika blok lolos maka blok diproduksi, dan jika pengemas dengan sengaja tidak memberikan badan blok, dianggap blok tidak ada).

makna:

Pertama-tama, pembangun (Builder) memiliki lebih banyak kekuatan untuk mengemas transaksi, tetapi crList yang disebutkan di atas pertama-tama membatasi kemungkinan memasukkan transaksi untuk sementara, dan kedua, jika pembangun (Builder) ingin mendapat untung dengan mengubah urutan transaksi, itu Itu perlu membayar biaya penawaran yang besar di awal untuk memastikan dapat memperoleh kualifikasi kepala blok, kemudian keuntungan MEV yang diperolehnya akan semakin berkurang, dan secara keseluruhan akan berdampak pada cara dan nilai aktual perolehan MEV;

Namun, pada tahap awal, hanya sejumlah kecil orang yang dapat menjadi pengemas (mengingat masalah kinerja simpul), sementara kebanyakan orang hanya menjadi pengusul, yang dapat menyebabkan sentralisasi lebih lanjut. kecil Dalam keadaan tertentu, beberapa penambang berpengalaman dengan kemampuan MEV akan lebih mungkin untuk menawar dengan sukses, yang selanjutnya akan memengaruhi efek solusi MEV yang sebenarnya;

Hal ini berimplikasi pada beberapa solusi MEV yang menggunakan lelang MEV.

makna:

EIP4844 sebenarnya adalah versi Danksharding yang sangat disederhanakan: EIP4844 menyediakan antarmuka aplikasi yang sama dengan Danksharding, termasuk opcode baru bernama DataHash; dan objek data baru bernama BinaryLarge Objects, yaitu Blob;

proto-danksharding adalah proposal "bracket" (yaitu, format transaksi dan aturan verifikasi) untuk mengimplementasikan spesifikasi Danksharding lengkap: namun, belum ada sharding yang diterapkan, dan semua pemverifikasi dan pengguna masih perlu memverifikasi ketersediaan data lengkap secara langsung ;

Mengapa Anda memilih proto-danksharding daripada EIP4488 untuk langsung menurunkan biaya layer2 dalam jangka panjang, karena hanya sedikit penyesuaian yang diperlukan saat meningkatkan ke shard penuh di masa mendatang:

Perbedaan praktis utama antara EIP4488 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 mengimplementasikan sharding penuh (dengan pengambilan sampel ketersediaan data, dll.) adalah tugas yang kompleks, dan masih ada pekerjaan kompleks yang harus diselesaikan setelah mengimplementasikan proto-danksharding, kompleksitas ini akan dikontrol pada lapisan konsensus. Setelah proto-danksharding diterapkan, tim klien lapisan eksekutif, pengembang rollup, dan pengguna tidak perlu melakukan pekerjaan tambahan saat bertransisi ke sharding penuh.

Untuk mencapai sharding yang lengkap, perlu untuk menyelesaikan implementasi PBS yang sebenarnya, bukti yang didelegasikan, dan pengambilan sampel ketersediaan data, tetapi modifikasi tersebut akan terkonsentrasi pada lapisan CL, dan pengembang tidak perlu menyesuaikan kembali: saat ini 4844 mengimplementasikan jenis transaksi baru , yang mirip dengan Format transaksi, logika validasi silang konsensus, dan logika lapisan eksekusi yang diperlukan dalam shard lengkap sama persis, dan harga gas mandiri yang menyesuaikan sendiri untuk blob juga diturunkan. di masa depan, PBS dan bukti yang didelegasikan perlu diselesaikan Dan implementasi sebenarnya dari pengambilan sampel ketersediaan data, tetapi modifikasi ini hanya pada lapisan CL, dan tidak memerlukan modifikasi oleh pengembang lapisan EL atau rollup, yang nyaman bagi pengembang.

Diikuti oleh SELFDESTRUCTremoval, EIP-6780 akhirnya ditentukan sebagai solusi yang paling cocok, tetapi pada pertemuan pengembang pada tanggal 26, Tim mengusulkan untuk menambahkan SETCODE opcode lain ke proposal ini untuk memungkinkan akun terprogram tetap diperbarui

DESTRUKSI DIRIPenghapusan 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 kode kontrak, dan dapat dimodifikasi tanpa persetujuan akun Kode operasi saldo akun memiliki bahaya tersembunyi yang besar bagi keamanan Ethereum;

Satu-satunya cara untuk menghapus kontrak on-chain adalah SELFDESTRUCT. Jika Anda memanggil fungsi penghancuran diri dalam kontrak, Anda dapat merusak kontrak sendiri. 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 rapat pengembang inti pada 13 April 23, empat proposal tentang SELFDESTRUCT diperkenalkan untuk berpartisipasi dalam diskusi, yaitu 6780, 4758, 6046 dan 6190, dan EIP6780 tindak lanjut ditentukan sebagai proposal akhir.

Pendahuluan: penghancuran diri adalah tombol darurat dari kontrak pintar, yang menghancurkan kontrak dan mentransfer ETH yang tersisa ke akun yang ditunjuk.

EIP6780: Nonaktifkan SELFDESTRUCT kecuali mereka berada dalam transaksi yang sama dalam kontrak.

PEMBARUAN: Pada tanggal 26 Mei, tim mengusulkan bahwa selain menghapus SELFDESTRUCT, tambahkan opcode lain - SETCODE, agar akun terprogram tetap diperbarui. (Artinya, fungsi pembaruan ditambahkan, dan properti dalam kontrak pintar diperbarui melalui pembaruan/peningkatan) Di sini, keunggulan EIP4758 diserap, yang memungkinkan dapp memiliki ruang untuk peningkatan.

Alasan: Memanipulasi kode SELFDESTRUCT awalnya memerlukan perubahan ekstensif pada status akun, seperti menghapus semua kode dan penyimpanan. Hal ini menimbulkan kesulitan untuk menggunakan pohon Verkle di masa mendatang: setiap akun akan disimpan dalam banyak kunci akun berbeda yang tidak akan terhubung secara eksplisit ke akun root.

PERUBAHAN: EIP ini mengimplementasikan perubahan yang menghapus SELFDESTRUCT, kecuali dalam dua kasus berikut

Aplikasi yang hanya digunakan untuk menarik dana dari SELFDESTRUCT akan tetap berfungsi;

DESKRIPSI DIRI yang digunakan dalam transaksi yang sama dalam kontrak juga tidak perlu diubah.

Signifikansi: Meningkatkan keamanan

Sebelumnya, ada kontrak di mainnet yang menggunakan SELFDESTRUCT untuk membatasi siapa yang dapat melakukan transaksi melalui kontrak;

Untuk mencegah pengguna 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 terkait SELFDESTRUCT yang kemudian dihapus. 6780 secara resmi dipilih dalam pertemuan pengembang inti pada 28 April 23, dan tiga proposal lainnya ditinggalkan karena tim pengembangan Ethereum akhirnya ingin menghapus opcode SELFDESTRUCT sepenuhnya, dan tiga usul berikutnya lebih diubah dengan cara 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. Hal ini menimbulkan kesulitan untuk menggunakan pohon Verkle di masa mendatang: setiap akun akan disimpan dalam banyak kunci akun berbeda yang tidak akan terhubung secara eksplisit ke akun root.

Mengubah:

Opcode SELFDESTRUCT berganti nama menjadi SENDALL, sekarang hanya memindahkan semua ETH di akun ke pemanggil, skema tidak lagi merusak kode dan penyimpanan, atau mengubah nonce;

Semua pengembalian dana terkait SELFDESTRUCT telah dihapus

makna:

Fungsi asli dipertahankan dibandingkan dengan EIP-6780, karena beberapa aplikasi masih/perlu menggunakan kode SELFDESTRUCT.

EIP-6046 (usang): Ganti SELFDESTRUCT 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 menelusuri 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, dan atur saldo akun ke 0.

Setel nonce akun ke 2^64-1.

Tidak ada pengembalian dana sejak EIP-3529;

Aturan yang relevan SELFDESTRUCT dari EIP-2929 tetap tidak berubah.

makna:

Proposal ini memiliki lebih banyak fleksibilitas daripada perilaku lain yang secara langsung menghapus SELFDESTRUCT.

EIP-6190 (usang): Mengubah SELFDESTRUCT, kompatibel dengan Verkle, sehingga hanya menyebabkan sejumlah kecil perubahan status

Alasan: Sama seperti di atas, dengan pohon Verkle, akun akan diatur secara berbeda: properti akun (termasuk penyimpanan) akan memiliki kunci terpisah, tetapi tidak mungkin menelusuri 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.

Ubah: 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 ke-0 dari kontrak diatur ke alamat yang akan dipublikasikan saat kontrak menggunakan opcode CREATE (keccak256(alamatkontrak, nonce)). 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 semua akan ditransfer ke alamat di bagian atas tumpukan;

Bagian atas tumpukan muncul.

makna:

Dirancang untuk memungkinkan SELFDESTRUCT selanjutnya membentuk pohon Verkle dengan perubahan minimal;

Biaya gas meningkat dengan diterapkannya EIP-2929.

Lalu ada EIP1153, yang menghemat bahan bakar dan membuka jalan untuk desain penyimpanan masa depan

EIP1153X

Rangkuman: Opcode penyimpanan sementara, tambahkan opcode untuk memanipulasi status yang berperilaku sama seperti penyimpanan 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, framework 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.

Mengambil reentrancylock sebagai contoh, ia tidak dapat mengandalkan frame perantara untuk mentransmisikan keadaan kunci: SLOAD komunikasi SSTORE melalui penyimpanan mahal, dan penyimpanan sementara adalah solusi khusus dan hemat gas untuk masalah komunikasi antar-frame.

Berubah: Dua opcode baru ditambahkan ke EVM, TLOAD (0xb3) dan TSTORE (0xb4).

Penyimpanan sementara bersifat pribadi untuk kontrak yang memilikinya, dan seperti penyimpanan persisten, hanya kerangka kerja 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:

kunci masuk kembali；

Alamat CREATE2 yang dapat dihitung secara on-chain: parameter konstruktor dibaca dari kontrak pabrik, alih-alih diteruskan sebagai bagian dari hash kode inisialisasi;

Persetujuan EIP-20 transaksi tunggal, misalnya #temporaryApprove(addressspender, jumlah uint256);

Kontrak biaya transfer: bayar biaya ke kontrak token untuk membuka kunci transfer selama transaksi;

Mode "Sampai": Memungkinkan pengguna untuk melakukan semua operasi 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.

makna:

Hemat gas dan miliki aturan penagihan gas yang lebih sederhana;

Memecahkan masalah komunikasi antar bingkai;

tidak mengubah semantik operasi yang ada;

Tidak perlu mengosongkan slot penyimpanan setelah digunakan;

Desain penyimpanan masa depan (seperti pohon Verkle) tidak perlu mempertimbangkan masalah tolak bayar untuk penyimpanan instan.

Lalu ada 4788, yang dapat mengurangi asumsi kepercayaan dari kumpulan gadai

EIP4788：X

Singkat: Akar blok suar di EVM.

Pembaruan: Dalam pertemuan pengembang pada 15.06.23, pengembang mengusulkan untuk membuat perubahan kode untuk meningkatkan pengalaman pemegang saham, EIP ini akan mengungkapkan akar dari blok rantai suar, yang berisi informasi keadaan rantai internal EVM, untuk kepercayaan pengembang DApp- akses yang diminimalkan.

Berubah: Kirim akar hash dari setiap blok rantai suar di header payload eksekusi yang sesuai, simpan akar ini 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 mengungkapkan data root status lapisan kontrak (CL) di lapisan eksekusi (EL), yang dapat membuat protokol berbeda dan aplikasi di jaringan Ethereum Komunikasi antar program lebih efisien dan aman. Izinkan lebih banyak desain tanpa kepercayaan untuk staking pool, bridging, dan protokol restaking.

Akhirnya ada 5656, yang menyediakan opcode salinan memori baru yang efisien, tetapi saat ini sedang dalam keadaan untuk sementara disertakan dalam pemutakhiran karena bandwidth pengujiannya

####EIP5656X

Pendahuluan: MCOPY- instruksi penyalinan memori.

UPDATE: Pada 09.06.23, tim pengembang menyatakan bahwa mereka awalnya terbagi pada MCOPY karena sementara itu memecahkan masalah keamanan, mereka khawatir tentang bandwidth implementasi + pengujian yang diperlukan untuk menambahkannya ke pemutakhiran, tetapi akhirnya setuju untuk memasukkan EIP , Namun, jika pengembang mengalami masalah kapasitas dalam pengujian atau di sisi klien, itu akan dipertimbangkan untuk dihapus. Dengan demikian, MCOPY dalam keadaan untuk sementara disertakan dalam pemutakhiran Cancun.

Berubah: Memberikan instruksi EVM yang efisien untuk menyalin wilayah memori.

Signifikansi: Penyalinan memori adalah operasi mendasar, tetapi ada biaya untuk mengimplementasikannya di 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 komputasi;

Ini juga akan berguna bagi kompiler untuk menghasilkan bytecode yang lebih efisien dan lebih kecil;

Ini dapat menghemat sejumlah biaya gas untuk prekompilasi identitas, tetapi sebenarnya tidak dapat mempromosikan realisasi bagian ini.

Daftar calon EIP

Pada tanggal 15 Juni 23, rapat konsensus pengembang membahas EIP CL-centric mana yang akan disertakan di Deneb, di antaranya, EIP6988, EIP7044, dan EIP7045 diusulkan untuk ditambahkan.

EIP6988：X

Rangkuman: Mencegah validator yang dipangkas agar tidak terpilih sebagai pengusul blok.

Signifikansi: Peningkatan hukuman untuk pelanggaran node akan menguntungkan DVT.

EIP7044：X

Rangkuman: Memastikan bahwa pintu keluar validator yang ditandatangani valid secara permanen.

Signifikansi: Dapat meningkatkan pengalaman staker sampai batas tertentu.

EIP7045：X

Rangkuman: Perluas rentang penyertaan lot pengesahan dari rolling window satu zaman menjadi dua zaman.

Signifikansi: Meningkatkan keamanan jaringan.

Hapus analisis EIP

Dalam pertemuan Ethereum ACDE ke-160 pada tanggal 29 April 23, EVMMAX dan EOF dipastikan akan dihapus dari pemutakhiran ini, dan perubahan terkait EOF dapat diperkenalkan di pemutakhiran harian berikutnya

EVMMAXEIPs：

Rangkuman: EVMMAX bertujuan untuk menghadirkan 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.

EIP6601: Ekstensi Aritmatika Modular EVM (EVMMAX)

Ubah: Ini adalah iterasi dari EIP5843, perbedaan dari EIP5843 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;

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, dan EIP-6601 membangunnya dengan memperkenalkan bagian penyiapan, ruang memori terpisah, dan opcode baru untuk operasi aritmatika modular Menyediakan pengaturan dan fleksibilitas yang lebih baik sambil mendukung modul 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 untuk beroperasi pada nilai hingga 256 bit sebesar 90-95% dibandingkan dengan opcode ADDMOD yang ada;

Mengizinkan prakompilasi modexp diimplementasikan sebagai kontrak EVM;

Secara signifikan mengurangi biaya verifikasi ZKP dalam fungsi hash aljabar (seperti MiMC/Poseidon) dan EVM.

EIP6690：

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 EIP-6601 .

Perubahan EOF：

Pendahuluan: EOF adalah pemutakhiran ke EVM, yang memperkenalkan standar kontrak baru dan beberapa opcode baru. Bytecode EVM tradisional (bytecode) adalah urutan bytecode instruksi yang tidak terstruktur. 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.

EIP663：

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

EIP3540：

Perkenalan:

Di masa lalu, bytecode EVM yang diterapkan 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 fungsi baru Atau hentikan fungsionalitas lama.

EIP ini memperkenalkan wadah yang dapat diperpanjang dan dikontrol versi untuk EVM, dan menyatakan format kontrak EOF. Berdasarkan hal ini, kode dapat diverifikasi saat kontrak EOF diterapkan, yaitu validasi waktu pembuatan, yang berarti bahwa itu dapat mencegah Kontrak yang tidak masuk akal yang sesuai dengan format EOF diterapkan. Perubahan ini mengimplementasikan kontrol versi EOF, yang akan membantu menonaktifkan instruksi EVM yang ada atau memperkenalkan fungsi skala besar (seperti abstraksi akun) di masa mendatang.

makna:

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 alat analisis data pada rantai.

EIP3670：

Pendahuluan: Berdasarkan EIP-3540, tujuannya adalah untuk memastikan bahwa kode kontrak EOF sesuai dengan format dan valid.Untuk kontrak yang tidak sesuai dengan format, penyebarannya akan dicegah dan Legacybytecode tidak akan terpengaruh.

Signifikansi: Berdasarkan wadah yang diperkenalkan oleh 3540, EIP-3670 memastikan bahwa kode dalam kontrak EOF valid, atau mencegahnya untuk disebarkan. Ini berarti opcode yang tidak terdefinisi tidak dapat digunakan dalam kontrak EOF, yang memiliki keuntungan tambahan yaitu mengurangi jumlah versi EOF yang perlu ditambahkan.

EIP4200：

Perkenalan:

Opcode khusus EOF pertama diperkenalkan: RJUMP, RJUMPI, dan RJUMPV, yang menyandikan tujuan sebagai nilai langsung yang ditandatangani. Compiler dapat menggunakan opcode JUMP baru ini untuk mengoptimalkan biaya bahan bakar penerapan dan eksekusi JUMP karena mereka menghilangkan runtime yang diperlukan untuk melakukan jumpdestanalysis untuk opcode JUMP dan JUMPI yang ada. EIP ini merupakan pelengkap dari lompatan dinamis.

Dibandingkan dengan operasi JUMP tradisional, perbedaannya adalah bahwa operasi seperti RJUMP tidak menentukan posisi offset tertentu, tetapi menentukan posisi offset relatif (dari dynamicjumps -> static jumps), karena staticjumps seringkali cukup.

Signifikansi: mengoptimalkan jaringan dan mengurangi biaya.

EIP4750：

Ambil fungsi 4200 selangkah lebih maju: dengan memperkenalkan dua opcode baru CALLF dan RETF, solusi alternatif direalisasikan untuk situasi yang tidak dapat digantikan oleh RJUMP, RJUMPI dan RJUMPV, sehingga JUMPDEST tidak lagi diperlukan dalam kontrak EOF, jadi Oleh karena itu lompatan dinamis dinonaktifkan.

Signifikansi: Mengoptimalkan kode dengan membagi kode menjadi beberapa bagian.

EIP5450：

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 gasnya 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 underflows/overflows. 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.

Setelah pembaruan pertemuan pengembang pada 26 Mei, perubahan jenis transaksi dari SSZ ke RLP terkait dengan EIP4844 berarti bahwa dua SSZEIP di Cancun tidak lagi diperlukan, sehingga EIP 6475 dan 6493 dipindahkan dari Cancun untuk meningkatkan

####EIP6475X

Pendahuluan: Proposal pendamping ke EIP4844. 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 Eksekusi Ethereum ke-161, diskusi tentang format serialisasi SSZ untuk EIP4844 mengungkapkan bahwa awalnya pengembang cenderung memperkenalkan iterasi awal format SSZ ke EL melalui transaksi blob, dan akhirnya pengembang berencana untuk membawa semua jenis transaksi telah ditingkatkan dari RLP ke SSZ, tetapi pengembang telah mempertimbangkan untuk menghapus SSZ dari EIP-4844 mengingat jalurnya yang tidak jelas dan tentunya tidak dapat menerapkannya pada pemutakhiran Cancun. Setelah banyak diskusi, pengembang setuju untuk menghapus SSZ dari implementasi EL EIP-4844, tetapi mereka belum menghapus EIP6475. Setelah pembaruan 26 Mei, perubahan SSZ->RLP berarti bahwa dua SSZEIP di Cancun tidak lagi diperlukan: sehingga EIP 6475 dan 6493 akan dipindahkan dari Cancun untuk pemutakhiran.

####EIP6493X

Pendahuluan: Skema tanda tangan transaksi SSZ. EIP ini menentukan skema tanda tangan untuk transaksi yang dikodekan 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: Perubahan SSZ

Pendahuluan: SimpleSerialiZe adalah metode serialisasi yang digunakan pada rantai suar.

SSZchanges juga menyertakan tiga proposal pendukung lainnya, kali ini hanya 6465 yang diperkenalkan.

EIP6465: Root penarikan SSZ, yang menentukan proses migrasi dari komitmen Merkle-PatriciaTrie (MPT) yang ada ke penarikan Simple Serialization (SSZ);

EIP6404/ EIP6466：

Keduanya menentukan proses untuk memigrasikan komitmen Merkle-PatriciaTrie (MPT) yang ada ke Serialisasi Sederhana (SSZ).

EIP-6404— Akar transaksi SSZ

EIP-6466— Basis Penerimaan SSZ

Tim Beiko menyarankan dalam pertemuan pengembang inti pada tanggal 26 Mei bahwa percakapan di masa mendatang seputar perluasan cakupan Cancun dibatasi pada lima EIP berikut: EIP5920, 5656, 7069, 4788, dan 2537, dan proposal selanjutnya akan dihasilkan dalam cakupan ini. EIP5656 dan EIP4788 berikutnya dikonfirmasi sebagai proposal pemutakhiran formal, dan 5920, 7069, dan 2537 telah dihapus. Di antara mereka, EIP5920 disebabkan oleh kekhawatiran pengembang tentang potensi efek samping dari cara mentransfer ETH, serta penalaran, pengujian, dan pekerjaan keamanan. Dihapus dari pemutakhiran.

EIP5920：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 operasi lain yang tidak disengaja.

Mengubah:

Opcode baru telah diperkenalkan: (PAY)PAY_OPCODE, di mana:

Keluarkan dua nilai dari tumpukan: addrthenval.

Transfer wei dari alamat eksekusi val 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.

Signifikansi: hemat gas.

PEMBARUAN: Pada 06.09.23, PAY telah dihapus dari pemutakhiran karena kekhawatiran tentang potensi efek samping yang mungkin ada dalam cara transfer ETH, dan pekerjaan penalaran, pengujian, dan keamanan diperlukan untuk meloloskan proposal.

####EIP7069X

Pendahuluan: Instruksi PANGGILAN yang dimodifikasi

Perubahan: 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 yang dipanggil kembali;

Sebelum aturan 63/64 diperkenalkan, gas yang tersedia untuk penelepon perlu dihitung secara akurat. Soliditas memiliki aturan rumit yang mencoba memperkirakan biaya di pihak penelepon dalam mengeksekusi panggilan itu sendiri untuk menetapkan nilai gas yang masuk akal.

Aturan 63/64 saat ini diperkenalkan:

Inspeksi kedalaman panggilan dihapus;

Pastikan untuk menyimpan setidaknya 5.000 gas sebelum menjalankan perilaku yang dipanggil;

Pastikan setidaknya 2300 gas tersedia untuk perilaku yang dipanggil.

Aturan subsidi: seperti subsidi 2300 yang terkenal, ketika kontrak memanggil kontrak lain, kontrak yang dipanggil akan mendapatkan 2300gas untuk melakukan operasi yang sangat terbatas (cukup untuk melakukan sedikit perhitungan dan menghasilkan log, tetapi tidak cukup untuk mengisi slot penyimpanan ), karena menetapkan jumlah gas yang tetap, selama harga gas dapat disesuaikan, orang tidak dapat menentukan jenis perhitungan apa yang dapat didukung oleh gas tersebut.

Signifikansi: Membuka jalan untuk pengenalan EOF di masa depan, dan mempermudah menjalankan kontrak besar.

Hapus opsionalitas gas: perintah baru tidak mengizinkan penentuan batas gas, tetapi bergantung pada "aturan 63/64" (terutama mengacu pada penetapan harga ulang gas yang digunakan untuk sejumlah besar operasi IO di EIP-150, yang meningkatkan konsumsi gas untuk operasi tertentu) untuk Membatasi gas, peningkatan penting ini adalah untuk menyederhanakan aturan seputar "subsidi", terlepas dari apakah nilainya dikirim atau tidak, penelepon tidak perlu melakukan perhitungan tentang gas;

Dengan diperkenalkannya proposal baru, pengguna selalu dapat mengatasi kesalahan Outof Gas dengan mengirimkan lebih banyak gas dalam transaksi (tunduk pada batas gas blok, tentu saja).

Beberapa kontrak yang hanya mengirim gas dalam jumlah terbatas ke panggilan mereka dipatahkan oleh mekanisme biaya baru ketika sebelumnya menaikkan biaya penyimpanan (misalnya EIP-1884 meningkatkan gas untuk opcode tertentu). 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;

Lebih Banyak Kode Pengembalian Status Kenyamanan: Fungsi kenyamanan telah diperkenalkan yang mengembalikan kode status yang lebih rinci: sukses (0), kembali (1), gagal (2), dan dapat diperluas di masa mendatang.

EIP2537：X

Singkat: Prekompilasi manipulasi kurva BLS12-381.

DIUBAH: Menambahkan operasi pada kurva BLS12-381 sebagai prekompilasi ke set yang diperlukan untuk melakukan operasi secara efisien seperti verifikasi tanda tangan BLS dan melakukan verifikasi SNARK.

Signifikansi: Ethereum dapat membuat bukti kriptografi yang lebih aman dan memungkinkan interoperabilitas yang lebih baik dengan rantai suar.

PR3175 disebutkan, tetapi tidak pernah terpilih, tidak ada diskusi lebih lanjut

PR3175：X

Rangkuman: Proposal ini akan mencegah validator yang dihukum untuk mengusulkan pemblokiran saat dikeluarkan dari antrean. 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, PR3175 sedang dalam proses diformat sebagai EIP, dan akan diubah menjadi EIP-6987, yaitu, untuk alasan keamanan, untuk mencegah pemilihan node verifikasi yang dipotong adalah pengusul blok.

masa depan

Berdasarkan informasi di atas, kami telah mencapai kesimpulan berikut:

1. Tujuan utama pemutakhiran Cancun adalah, dalam urutan prioritas, perluasan, keamanan, penghematan bahan bakar, 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;

Ketiga adalah interoperabilitas, seperti optimalisasi koneksi, komunikasi dan interoperabilitas antar dapps (4788, 7044 dan 6988);

Data yang diharapkan: Testnet 4844 dapat mengurangi biaya opsiderollup sebesar 50%; solusi teknis dari EigenLayer dan Celestia belum mengungkapkan terlalu banyak, dan data mereka tidak dapat dievaluasi; Ethstorage memperkirakan bahwa biaya DA akan turun menjadi 5% dari aslinya ; Topia diharapkan dapat mengurangi biaya hingga 100~1000 kali lipat.

2. 2 hingga 5 tahun ke depan ketika Cancun ditingkatkan ke Danksharding adalah periode pengembangan emas untuk proyek lapisan DA

Batas atas keamanan Lapisan 2 bergantung pada lapisan DA yang diadopsinya Proto-Danksharding akan menguntungkan protokol penyimpanan, protokol modular, dan jaringan ekspansi penyimpanan L1 melalui penyimpanan data status 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 meninggalkan ruang untuk protokol terdesentralisasi lainnya untuk penyimpanan jangka panjang (Tujuan dari protokol konsensus Ethereum bukan untuk menjamin penyimpanan semua data historis selamanya. Sebaliknya, tujuannya adalah untuk menyediakan papan buletin real-time yang sangat aman, dan memberikan ruang bagi protokol terdesentralisasi lainnya untuk melakukan penyimpanan jangka panjang.);

Kedua, Danksharding mengurangi biaya DA, tetapi masalah waktu pendaratan aktual dan ketersediaan data juga perlu diselesaikan.

Pengurangan biaya DA: Sebelum pembaruan ini, calldata diperlukan untuk merilis data dari rollup ke rantai utama Ethereum, dan biaya gas untuk memanggil kode ini sangat mahal, yang merupakan pengeluaran terbesar di layer2. EIP4844 memperkenalkan blob data sebagai rollups Ruang data tambahan yang unik akan sangat mengurangi biaya penyimpanan, sehingga mengurangi biaya DA.

Waktu pendaratan sebenarnya lama, dan TPS yang dapat ditingkatkan dan gas yang dapat dikurangi masih terbatas, sehingga baik untuk pengembangan lanjutan proyek lapisan DA di masa mendatang:

Dalam artikel sharding data iablesecurity polynya tentang danksharding, menunjukkan bahwa penerapannya akan memakan waktu 2-5 tahun;

Kalaupun mendarat, TPS yang bisa dinaikkan dan level gas yang bisa diturunkan masih terbatas:

EIP4844 saat ini mendukung 6 blob, dan masalah perluasan di masa mendatang hanya dapat diselesaikan oleh Danksharding;

Ruang blok Ethereum saat ini sekitar 200KB. Setelah Danksharding, ukuran yang direncanakan dalam spesifikasi adalah 32 megabita, yaitu peningkatan sekitar 100 kali lipat. Saat ini, TPS Ethereum adalah sekitar 15, dan dalam keadaan ideal, akan menjadi sekitar 1500 setelah dinaikkan 100 kali lipat, yang bukan peningkatan besar dalam hal besaran.

Oleh karena itu, waktu implementasi yang lama + perubahan aktual yang terbatas akan menguntungkan proyek lapisan DA. Beberapa proyek DA seperti Celestia dan Eigenda masih dapat bersaing dengan Danksharding melalui biaya yang lebih murah dan TPS yang lebih cepat. Proyek DA baru seperti ETHstoragetopia juga dapat mengisi celah pasar sebelumnya.

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 jaringan portal Ethereum (saat ini sedang dikembangkan) sedang dikembangkan) atau protokol pihak ketiga seperti penjelajah blok, data historis di BitTorrent, atau penyimpanan spontan oleh pengguna individual.

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;

Ini bagus untuk jaringan ekspansi penyimpanan L1, seperti Ethstorage, yang dapat memberikan solusi tingkat kedua untuk penyimpanan yang dapat diprogram dengan biaya penyimpanan yang lebih rendah.

3. Upgrade Cancun baik untuk keragaman L2, L3, RAAS dan ketersediaan data dan trek lainnya

Analisis trek L2:

Lapisan Atas 2, lima proyek seperti ArbitrumOrbit, OPStack, Polygon2.0, FractalScaling (di bawah StarkWare) dan HyperChain (di bawah zkSync) akan menguntungkan. Pengurangan biaya penyimpanan yang dibawa oleh blob akan sangat meningkatkan rangkaian masalah biaya dan skalabilitas sebelumnya yang membatasi pengembangan layer2, dan sangat meningkatkan throughput data.Setelah menyelesaikan masalah biaya, head layer2 akan memiliki kesempatan untuk terus menerapkan spesifik fungsi, ekologi L3 bersamaan multi-rantai yang disesuaikan tingkat tinggi;

Kesenjangan dalam biaya operasi antara Lapisan 2 lapis kedua dan Lapisan 2 arus utama akan dipersempit, memberi beberapa proyek kecil lebih banyak peluang untuk pengembangan, seperti Aztec, Metis, Boba, ZKspace, layer2.finance, dll.;

Meskipun kebutuhan nyata dari 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 Wasm, yang dapat memperkenalkan lebih banyak web2 developer.

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 dari 5 lapisan2 teratas dan munculnya berbagai DA baru, kami harus memberi tanda tanya apakah proyek baru dapat membentuk jalur.

Pertama-tama, keuntungan dari penerapan rantai aplikasi head layer2 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 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.

Seri OP: Meskipun peningkatan batuan dasar +4844 dari tumpukan OP telah membawa beberapa peningkatan kecil dalam biaya dan efisiensi, daya tarik peningkatan tersebut tidak kuat;

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. Namun, sebagian besar ZKRAAS yang saat ini ada di pasaran masih menggunakan proyek terkemuka (seperti ZkSync) untuk memotong rantai, dan hambatannya masih belum kuat.

Oleh karena itu, dalam jangka pendek, OPRAAS masih memiliki ruang untuk pengembangan sebelum lapisan 3. Dalam jangka panjang, ZKRAAS dan lapisan 3 mungkin menjadi tren masa depan.

ZKRAAS 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 keranjang 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. Pembaruan Cancun meningkatkan pengalaman pengembang dan pengguna

Proposal penting kedua dari pemutakhiran Cancun, SELFDESTRUCTremoval, akan lebih meningkatkan keamanan Ethereum.Pada saat yang sama, untuk masalah pembaruan akun prosedural yang mungkin ada setelah penghapusan, kode operasi baru SETCODE disiapkan untuk memperbaiki situasi ini;

Proposal ketiga EIP1153 yang ditingkatkan oleh Cancun menambahkan kode operasi penyimpanan sementara, yang pertama dapat menghemat bahan bakar, kedua menyelesaikan masalah komunikasi antar-bingkai, dan akhirnya membuka jalan untuk desain penyimpanan di masa mendatang, seperti pohon Verkle tidak perlu mempertimbangkan pengembalian uang pertanyaan penyimpanan sementara;

EIP5656, proposal keempat dari pemutakhiran Cancun, 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 dari pemutakhiran Cancun adalah EIP4788, yang dapat membuat komunikasi antara berbagai protokol dan aplikasi di jaringan Ethereum lebih efisien dan aman, dan juga memungkinkan desain yang lebih tidak dapat dipercaya untuk staking pool, bridging dan restaking protokol;

Pemutakhiran Cancun terbaru (15 Juni 23) mengusulkan untuk menambahkan pemutakhiran EIP CL-centric: EIP6988, EIP7044, dan EIP7045, yang meningkatkan keamanan dan kegunaan Ethereum secara detail, seperti meningkatkan Pengalaman penjamin dan meningkatkan keamanan jaringan, dll.

Di antara proposal yang dihapus, transisi SSZ->RLP menyebabkan dua SSZEIP (EIP6475 dan EIP6493) dihapus dari pemutakhiran Cancun; proposal terkait EOF dihapus dari pemutakhiran Cancun lagi setelah dihapus dari pemutakhiran Shanghai, dan saat ini dipertimbangkan mungkin Ini akan langsung diimplementasikan dalam pemutakhiran harian nanti; EVMMAX juga dihapus dari Cancun untuk pemutakhiran bersama dengan EOF karena merupakan bagian dari EIP yang terkait dengan implementasi EOF; mengingat potensi efek samping yang mungkin ada dalam cara mentransfer ETH, dan kebutuhan untuk lulus proposal Penalaran, pengujian dan pekerjaan keamanan, EIP5920 dihapus dari pemutakhiran.

5. Hubungan dengan zkml dan abstraksi akun

Efek kecil pada zkml

ZKML adalah kombinasi dari Zero Knowledge Proof (ZeroKnowledge) dan Machine Learning (Machine Learning); 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, sebagai daya saing inti proyek, juga perlu untuk dienkripsi untuk menjaga hambatan persaingan. Jika ada masalah kepercayaan seperti ini, model ML akan 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: diperlukan struktur penyimpanan terpisah seperti Ruang dan Waktu, dan teknologi intinya adalah protokol keamanan baru "SQL Proof". Atau sambungkan data on-chain dan off-chain secara sederhana Format SQL dan muat hasilnya langsung ke kontrak pintar;

ZK-SNARKs adalah bentuk utama ZK dalam ZKML, yang dapat beradaptasi dengan kebutuhan daya komputasi ML pada rantai. Dengan perkembangan kriptografi, khususnya bukti SNARK rekursif akan menguntungkan penerapan ZKML pada rantai:

ZK-SNARK dicirikan oleh 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. Ini hanya membutuhkan satu pembukti Sifat interaksi dengan pemverifikasi menjadikan ZK-SNARK efisien dan praktis dalam aplikasi praktis, dan lebih cocok untuk kebutuhan daya komputasi on-chain ML.

Saat ini tidak mungkin untuk melatih pada rantai, dan hanya hasil perhitungan off-chain yang dapat disimpan pada rantai:

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). Model ZK yang besar membuktikan bahwa diperlukan daya komputasi yang lebih tinggi, yang tidak dapat didukung pada rantai. Yang populer saat ini ZK-SNARK hanya mendukung bukti skala nol-pengetahuan ML kecil dan perhitungan dalam jumlah 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, pemutakhiran Cancun dapat mengurangi biaya bukti ZKrollup sampai batas tertentu:

Biaya transaksi zkSync saat ini bergantung pada 3 aspek:

Biaya sumber daya tetap yang dikonsumsi oleh pemverifikasi untuk menghasilkan sertifikat SNARK dan memverifikasinya relatif tinggi;

Biaya gas ketika verifikator mengirimkan bukti SNARK ke mainnet Ethereum, bagian dari biaya ini akan meningkat karena 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 teratasi, dan biaya bukti ZKP dapat dikurangi hingga batas tertentu.Tren pengembangan seri ZK tidak boleh diremehkan.

Kedua, abstraksi akun mengubah transaksi tx tradisional menjadi operasi pengguna, lalu mengemas operasi pengguna ke dalam blok dengan ECDSA, yang menempati lebih banyak penyimpanan di rantai daripada sebelumnya, sehingga persyaratan penyimpanan lebih tinggi;

Kemudian, abstraksi akun dan ZKrollup dapat saling melengkapi:

Saat ini, masalah abstraksi akun adalah GasFee mahal, karena terlalu banyak langkah dan kontrak pintar yang terlibat, banyak data, yang membuat GasFee mahal, keuntungan dari ZKRollup adalah dapat mengurangi data;

Abstraksi akun mempersulit jaminan keamanan: Karena AA melibatkan banyak kontrak, keamanan menjadi masalah. Namun, setelah L2 secara bertahap dibentuk di masa mendatang, lapisan konsensus tidak akan lagi diubah, kontrak pintar akan lebih banyak digunakan, dan keamanan abstraksi akun juga akan meningkat, dapat dijamin, dan dengan verifikasi tepercaya dari ZKrollup, keamanan akan lebih ditingkatkan.

Terakhir, mengingat 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 dari 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;

Optimalisasi aktivitas AI dan on-chain: 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 secara bertahap akan menguntungkan pengembangan abstraksi akun di masa mendatang dari perluasan ruang penyimpanan, hingga saling melengkapi dengan ZKrollup, dan kemudian kombinasi dengan teknologi AI.

6. Melihat kembali peta jalan Ethereum, apa selanjutnya

Saat ini, Layer2 tidak memiliki kinerja yang mirip dengan Solana (dalam hal latensi dan throughput), juga tidak memiliki kinerja fragmentasi seperti Near, juga tidak memiliki kinerja eksekusi paralel seperti Sui dan Aptos. Pembaruan Cancun telah meningkatkan kepemimpinan Ethereum sebagai pemimpin;

Setelah peningkatan Cancun, diperkirakan beberapa waktu pengembangan utama akan menjadi sepenuhnya-danksharding (2~5 tahun), pendaratan MEV dan PBS (1~3 tahun), abstraksi akun (1~2 tahun), ZK semuanya (3~ 6 tahun) ), EOF dan pengalaman pengembang (berapa kali Anda melihat ekstensi?).

Scourge

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 pre-emption dapat diperkenalkan.

PBS adalah pemisahan pembuat 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, yaitu ide eksternalisasi MEV.

Tingkat penyelesaian PBS saat ini masih sangat rendah, dan yang lebih matang adalah kerjasama dengan solusi MEV eksternal - mevboost dari flashbots.

Versi lanjutan dari "Enshrined 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 Relaiing Optimis, yang meningkatkan fleksibilitas dan kemampuan beradaptasi kerangka kerja PBS

TheVerge

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 dengan perubahan status konsensus; EnshrinedRollups.

Pohon Verkle adalah alternatif yang lebih efisien untuk pohon Merkle khusus negara bagian yang tidak perlu menyediakan jalur dari setiap simpul kembar (simpul yang memiliki induk yang sama) ke simpul yang dipilih, tetapi hanya jalur itu sendiri sebagai bukti Sebagian, bukti Verkle 3 kali lebih efisien daripada bukti Merkle.

EnshrinedRollup mengacu pada Rollup yang memiliki semacam integrasi konsensus pada L1. Keuntungannya adalah ia mewarisi konsensus L1 dan tidak memerlukan token tata kelola untuk melakukan pemutakhiran rollup. Pada saat yang sama, dengan melakukan perhitungan 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.

Pembersihan

ThePurge 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 menyediakan layanan di tingkat P2P.

keadaan terbengkalai. 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 negara harus mengurangi node negara yang perlu disimpan dengan total 20-50 GB.

Pada tahap kelima Pembersihan, EIP4444 secara eksplisit ditulis ke dalam Peta Jalan. EIP-4444 mengharuskan klien untuk menghapus data yang lebih lama dari satu tahun. Pada saat yang sama, ada beberapa tugas pengoptimalan EVM pada tahap ini, seperti menyederhanakan mekanisme Prakompilasi GAS dan EVM, dll.;

Berbelanja secara royal

Di tahap keenam terakhir Splurge, EIP4337 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 dan dompet pemulihan sosial , dll.;