Pada 30 November 2023, pengembang Ethereum berkumpul di Zoom untuk pertemuan All Core Developers Consensus (ACDC) call #122. Panggilan konferensi ACDC adalah serangkaian pertemuan dua mingguan yang dimoderatori oleh peneliti Ethereum Foundation Danny Ryan di mana pengembang mendiskusikan dan mengoordinasikan perubahan pada lapisan konsensus Ethereum (CL). Minggu ini, para pengembang fokus pada perkembangan terbaru dalam pengujian Cancun / Deneb, termasuk:
· Peluncuran Devnet #12: Pengujian perangkat lunak klien Teku, Lodestar, dan Lighthouse pada Devnet #12, serta semua perangkat lunak klien lapisan eksekusi (EL), sedang berlangsung. Tim Prysm mengharapkan perangkat lunak mereka siap untuk pengujian dalam waktu dua hingga tiga minggu di Devnet terbaru.
· Masalah Keluar Validator di Devnet #11: Di Devnet #11, pengembang telah mengidentifikasi masalah yang terkait dengan keluarnya validator, yang saat ini sedang diselesaikan oleh tim klien Nimbus. Devnet #11 akan terus berfungsi secara normal sampai masalah teratasi.
· Klarifikasi Spesifikasi Jaringan: Pengembang membahas klarifikasi spesifikasi untuk permintaan "BlockByRoot" dan "BlobSidecarsByRoot", mengklarifikasi apakah node lapisan konsensus (CL) harus menanggapi permintaan ini dalam urutan tertentu.
Selain pembaruan Cancun / Deneb, para pengembang membahas beberapa masalah proses yang diangkat oleh Tim Beiko, Kepala Dukungan Protokol Yayasan Ethereum, untuk meningkatkan koordinasi peningkatan Ethereum.
Devnet # 12
Pada Rabu, 30 November 2023, upgrade Cancun/Deneb resmi diluncurkan di Devnet #12. Mario Vega dari tim pengujian Ethereum Foundation mengatakan bahwa "tidak ada masalah besar yang diidentifikasi hingga saat ini" di tiga klien CL yang saat ini berjalan di testnet. Barnabas Busa, seorang DevOps engineer di Foundation, menyebutkan bahwa ada total 225 validator yang tersebar di tiga node antara Lighthouse, Teku, dan Lodestar. Karena stabilitas Devnet # 12, Parithosh Jayanthi, seorang insinyur DevOps di Foundation, bertanya kepada pengembang apakah mereka harus mulai merencanakan garpu bayangan Goerli untuk menguji Cancun / Deneb lebih lanjut. Namun, mengingat bahwa Prysm, klien CL paling populer saat ini, belum bergabung dengan Devnet # 12, para pengembang telah memutuskan untuk menunda rencana untuk garpu bayangan Goerli sampai perangkat lunak klien Prysm siap untuk pengujian. Beiko menyarankan untuk pindah ke garpu bayangan Goerli beberapa saat sebelum akhir tahun. Karena stabilitas Devnet # 12, rencana ditunda sampai perangkat lunak klien Prysm siap untuk pengujian.
Devnet #11
Pengembang Nimbus, yang menggunakan nama layar "Dustin", membagikan rincian masalah Devnet # 11 yang sedang dikerjakan timnya. Masalah ini pertama kali ditemukan ketika pengembang keluar dari sepertiga validator Devnet #11 untuk digunakan pada Devnet #12. Ryan bertanya kepada Dustin apakah dia dapat menemukan masalah ini dengan pengujian tambahan. Dustin menjawab bahwa, menurutnya, sifat kesalahan ini disebabkan oleh detail implementasi di luar ruang lingkup spesifikasi konsensus. Namun, ia juga mengakui bahwa ada "ketegangan yang jelas" antara menulis perangkat lunak klien secara ketat ke spesifikasi CL untuk menguji manfaat cakupan dan mengarungi area abu-abu spesifikasi untuk mencapai kinerja node yang lebih baik.
"Maksud saya lebih banyak pengujian selalu baik, tetapi mencari tahu lebih sistematis bagaimana menggabungkan lebih banyak fungsi sisi klien ke dalam menjalankan tes mungkin lebih otomatis, apakah itu menggunakan Apache Hive atau Kurtosis atau apa pun. Saya pikir itu pasti akan berguna jika masalah ini dapat diselesaikan atau hal-hal dapat dipecah dengan cukup baik untuk dapat menggabungkan lebih banyak tugas-tugas ini, "tambah Dustin, menambahkan bahwa tantangan lain yang harus dipertimbangkan oleh pengembang CL adalah mencari tahu tingkat detail bahwa spesifikasi CL harus menentukan dan menstandarisasi perilaku node. "Tantangan lain di sini adalah tingkat standardisasi, yang sebenarnya bukan hanya masalah rekayasa perangkat lunak, seberapa standar perilakunya?" tanya Dustin. Semua klien CL lulus tes yang memeriksa perilaku dasar, tetapi perilaku di luar ruang lingkup tes ini ambigu. "Apakah ini hal-hal yang sengaja tidak jelas? Apa yang harus benar-benar jelas oleh norma dan apa yang harus sengaja dikaburkan?" Dustin bertanya.
Paling tidak, para pengembang setuju untuk menambahkan lebih banyak tes ke Devnet dan testnet di masa depan untuk sejumlah besar validator keluar di Cancun / Deneb. Ryan juga mengakui bahwa ada ruang untuk cakupan pengujian yang lebih ketat dan komprehensif ketika datang ke klien CL dan implementasi spesifikasi CL. Vega menyarankan agar Dustin membuat posting HackMD yang merinci kekhawatirannya dan mendiskusikan topik tersebut pada panggilan tes Cancun / Deneb berikutnya. Jayanthi menambahkan bahwa berdasarkan beberapa masalah yang baru-baru ini diidentifikasi pada Cancun / Deneb Devnets, ada kebutuhan yang jelas bagi pengembang untuk memiliki alat yang secara sistematis dapat melakukan sejumlah perilaku terkait integrasi on-chain, seperti mempertaruhkan penarikan ETH, penarikan validator, dll. Untuk melakukan ini, Jayanthi merekomendasikan untuk membangun alat semacam itu menggunakan campuran suite uji Hive dan Kurtosis.
Berbicara tentang alat pengujian baru untuk upgrade Cancun / Deneb, Jayanthi mencatat bahwa pengembang sedang mengerjakan alat untuk mengaktifkan reuni rantai dengan andal di Devnet dan testnet. Untuk memastikan bahwa alat ini berfungsi, Jayanthi meminta pengembang untuk membagikan rincian bug yang diketahui yang memicu reorg rantai di Ethereum. Jayanthi menjelaskan bahwa ia akan menggunakan bug ini untuk menguji alat dan memastikan bahwa alat tersebut dapat mengidentifikasi dengan andal kapan reorganisasi terjadi dan kapan diselesaikan.
Klarifikasi spesifikasi jaringan
Para pengembang secara singkat membahas permintaan tarik terbuka yang diusulkan oleh peneliti Ethereum Foundation Justin Traglia mengenai urutan tanggapan yang harus dikembalikan klien CL ketika menerima permintaan "BlockbyRoot" atau "BlobSidecarsByRoot". Ryan bertanya bagaimana tim klien CL yang berbeda sudah menerapkan fitur ini. Tak satu pun dari pengembang yang menelepon menjawab pertanyaan ini. Ryan menyarankan untuk menghidupkan kembali diskusi di saluran Ethereum Research &; Development Discord untuk melibatkan pengembang klien yang lebih luas. Ryan mengakui bahwa ada ambiguitas dalam spesifikasi dua permintaan, yang "mungkin menjadi penyebab masalah dan kasus tepi yang aneh" dan "layak untuk diklarifikasi dan diselesaikan," Ryan menegaskan.
Ryan juga menyebutkan bahwa ia akan merilis versi baru dari spesifikasi CL dalam beberapa hari ke depan. Versi terbaru secara signifikan menambahkan spesifikasi ketika klien CL dapat menyediakan blok dan blok melalui permintaan RPC "byRoot". Untuk latar belakang lebih lanjut tentang diskusi tentang mengambil blok dan blok yang hilang melalui permintaan RPC "byRoot", silakan merujuk ke log panggilan sebelumnya. Ryan menekankan bahwa penambahan baru pada spesifikasi CL yang disertakan dalam versi terbaru tidak akan memiliki perubahan yang melanggar pada kode yang memengaruhi kode untuk validator yang sudah berjalan di Devnet #11 atau #12.
Proses perencanaan upgrade
Selanjutnya, para pengembang membahas berbagai item proses yang diusulkan oleh Beiko. Beiko mengatakan bahwa posting blog yang memperingatkan pengguna testnet Goerli tentang penghentian yang akan datang dalam waktu 3 bulan setelah peningkatan Cancun / Deneb diaktifkan di Goerli, atau 1 bulan setelah peningkatan diaktifkan di mainnet Ethereum, mana saja yang lebih lambat, akan dipublikasikan di blog Ethereum Foundation pada 30 November. Sejak kesimpulan panggilan, posting blog di atas telah diterbitkan dan dapat dibaca di sini.
Beiko menyarankan untuk membuat folder khusus peningkatan di bawah repositori "pm" Ethereum untuk mengatur berbagai file yang terkait dengan peningkatan tertentu ke dalam satu folder untuk digunakan nanti. Pengembang di telepon setuju dengan saran Beiko.
Item proses kedua yang diusulkan oleh Beiko adalah tentang membuat dokumen "Meta EIP" untuk melacak cakupan penuh peningkatan jaringan yang telah diselesaikan di Ethereum. "Tidak ada tempat yang baik untuk melacak cakupan penuh peningkatan jaringan sebelum menyebarkan dan mengumumkannya dalam posting blog," tulis Beiko dalam sebuah posting tentang proposal Meta EIP-nya. "Untuk Dencun, kami memiliki EIP EL dalam file penurunan harga 7 yang sulit ditemukan, dan CL EIP adalah bagian dari Spesifikasi Rantai Suar 3. Ini tidak bagus, karena keduanya agak sulit ditemukan, mereka menggunakan 'format' yang berbeda, dan mereka mengarah pada duplikasi. Karena ERC dan EIP sekarang terpisah, saya sarankan (kembali) menggunakan Meta EIP untuk melacak EIP yang termasuk dalam peningkatan jaringan. Para pengembang mendukung pembuatan dokumen-dokumen ini. Beiko mengatakan dia akan menyusun dokumen untuk tinjauan peningkatan Cancun / Deneb minggu ini.
Akhirnya, Beiko mengajukan pertanyaan tentang kegunaan menandai perubahan kode yang diusulkan, Ethereum Improvement Proposals (EIPs), sebagai "Pertimbangkan Inklusi" (CFI). Menurut Beiko, CFI adalah status yang secara historis digunakan pengembang sebagai "sinyal lunak", yang menunjukkan bahwa penulis EIP harus terus mengerjakan proposal yang mungkin dimasukkan dalam hard fork di masa depan. Ini hanya digunakan untuk perubahan dan peningkatan kode yang berfokus pada EL. 「[CFI] lebih tinggi dari ide-ide acak dari orang-orang acak, tetapi sebelum mereka diterima di garpu," kata Beiko.
Di masa lalu, pelabelan CFI telah melakukan sedikit atau tidak ada upaya dalam menunjukkan EIP mana pada EL yang akan diterapkan dalam peningkatan, atau kapan. Ini telah diterapkan pada berbagai EIP dengan berbagai tingkat kesiapan kode dan dukungan dari tim klien. Dalam kasus proposal EVM Object Format (EOF), pengembang menggunakan tag ini untuk menunjukkan komitmen mereka untuk menerapkan EOF dalam peningkatan mendatang berikutnya, Cancun/Deneb. Namun, EOF, serta beberapa proposal lain yang juga ditandai sebagai CFI, telah ditolak dari Cancun / Deneb, dan tidak jelas status EIP ini ditandai sebagai CFI dalam peningkatan berikutnya Praha / Electra.
Beiko mengatakan bahwa jika keadaan ini tidak membantu, pengembang harus menghapusnya, tetapi jika mereka berniat untuk menyimpannya, pengembang CL juga harus menggunakan label yang sama pada perubahan kode yang mereka pertimbangkan untuk diterapkan dalam peningkatan CL. Tidak jelas sejauh mana proses peninjauan CL EIP mencerminkan proses peninjauan EL EIP dan apakah mereka harus berkembang dengan cara yang sama di masa depan. Biasanya, perubahan kode yang diusulkan pada spesifikasi CL dibahas pada panggilan konferensi ACDC, sementara EIP yang diusulkan ke spesifikasi EL dibahas pada panggilan konferensi ACDE.
Danno Ferrin dari Swirlds Labs juga datang dengan ide untuk membuat bidang placeholder untuk semua EIP, baik CL atau EL terkait, yang mengidentifikasi status mereka selama proses peninjauan, termasuk status CFI. Pada panggilan ini, tidak ada keputusan yang jelas tentang topik status EIP dan pelabelan CFI.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Ringkasan pertemuan terbaru pengembang inti Ethereum: Devnet #12启动, proses perencanaan peningkatan
Pada 30 November 2023, pengembang Ethereum berkumpul di Zoom untuk pertemuan All Core Developers Consensus (ACDC) call #122. Panggilan konferensi ACDC adalah serangkaian pertemuan dua mingguan yang dimoderatori oleh peneliti Ethereum Foundation Danny Ryan di mana pengembang mendiskusikan dan mengoordinasikan perubahan pada lapisan konsensus Ethereum (CL). Minggu ini, para pengembang fokus pada perkembangan terbaru dalam pengujian Cancun / Deneb, termasuk:
· Peluncuran Devnet #12: Pengujian perangkat lunak klien Teku, Lodestar, dan Lighthouse pada Devnet #12, serta semua perangkat lunak klien lapisan eksekusi (EL), sedang berlangsung. Tim Prysm mengharapkan perangkat lunak mereka siap untuk pengujian dalam waktu dua hingga tiga minggu di Devnet terbaru.
· Masalah Keluar Validator di Devnet #11: Di Devnet #11, pengembang telah mengidentifikasi masalah yang terkait dengan keluarnya validator, yang saat ini sedang diselesaikan oleh tim klien Nimbus. Devnet #11 akan terus berfungsi secara normal sampai masalah teratasi.
· Klarifikasi Spesifikasi Jaringan: Pengembang membahas klarifikasi spesifikasi untuk permintaan "BlockByRoot" dan "BlobSidecarsByRoot", mengklarifikasi apakah node lapisan konsensus (CL) harus menanggapi permintaan ini dalam urutan tertentu.
Selain pembaruan Cancun / Deneb, para pengembang membahas beberapa masalah proses yang diangkat oleh Tim Beiko, Kepala Dukungan Protokol Yayasan Ethereum, untuk meningkatkan koordinasi peningkatan Ethereum.
Devnet # 12
Pada Rabu, 30 November 2023, upgrade Cancun/Deneb resmi diluncurkan di Devnet #12. Mario Vega dari tim pengujian Ethereum Foundation mengatakan bahwa "tidak ada masalah besar yang diidentifikasi hingga saat ini" di tiga klien CL yang saat ini berjalan di testnet. Barnabas Busa, seorang DevOps engineer di Foundation, menyebutkan bahwa ada total 225 validator yang tersebar di tiga node antara Lighthouse, Teku, dan Lodestar. Karena stabilitas Devnet # 12, Parithosh Jayanthi, seorang insinyur DevOps di Foundation, bertanya kepada pengembang apakah mereka harus mulai merencanakan garpu bayangan Goerli untuk menguji Cancun / Deneb lebih lanjut. Namun, mengingat bahwa Prysm, klien CL paling populer saat ini, belum bergabung dengan Devnet # 12, para pengembang telah memutuskan untuk menunda rencana untuk garpu bayangan Goerli sampai perangkat lunak klien Prysm siap untuk pengujian. Beiko menyarankan untuk pindah ke garpu bayangan Goerli beberapa saat sebelum akhir tahun. Karena stabilitas Devnet # 12, rencana ditunda sampai perangkat lunak klien Prysm siap untuk pengujian.
Devnet #11
Pengembang Nimbus, yang menggunakan nama layar "Dustin", membagikan rincian masalah Devnet # 11 yang sedang dikerjakan timnya. Masalah ini pertama kali ditemukan ketika pengembang keluar dari sepertiga validator Devnet #11 untuk digunakan pada Devnet #12. Ryan bertanya kepada Dustin apakah dia dapat menemukan masalah ini dengan pengujian tambahan. Dustin menjawab bahwa, menurutnya, sifat kesalahan ini disebabkan oleh detail implementasi di luar ruang lingkup spesifikasi konsensus. Namun, ia juga mengakui bahwa ada "ketegangan yang jelas" antara menulis perangkat lunak klien secara ketat ke spesifikasi CL untuk menguji manfaat cakupan dan mengarungi area abu-abu spesifikasi untuk mencapai kinerja node yang lebih baik.
"Maksud saya lebih banyak pengujian selalu baik, tetapi mencari tahu lebih sistematis bagaimana menggabungkan lebih banyak fungsi sisi klien ke dalam menjalankan tes mungkin lebih otomatis, apakah itu menggunakan Apache Hive atau Kurtosis atau apa pun. Saya pikir itu pasti akan berguna jika masalah ini dapat diselesaikan atau hal-hal dapat dipecah dengan cukup baik untuk dapat menggabungkan lebih banyak tugas-tugas ini, "tambah Dustin, menambahkan bahwa tantangan lain yang harus dipertimbangkan oleh pengembang CL adalah mencari tahu tingkat detail bahwa spesifikasi CL harus menentukan dan menstandarisasi perilaku node. "Tantangan lain di sini adalah tingkat standardisasi, yang sebenarnya bukan hanya masalah rekayasa perangkat lunak, seberapa standar perilakunya?" tanya Dustin. Semua klien CL lulus tes yang memeriksa perilaku dasar, tetapi perilaku di luar ruang lingkup tes ini ambigu. "Apakah ini hal-hal yang sengaja tidak jelas? Apa yang harus benar-benar jelas oleh norma dan apa yang harus sengaja dikaburkan?" Dustin bertanya.
Paling tidak, para pengembang setuju untuk menambahkan lebih banyak tes ke Devnet dan testnet di masa depan untuk sejumlah besar validator keluar di Cancun / Deneb. Ryan juga mengakui bahwa ada ruang untuk cakupan pengujian yang lebih ketat dan komprehensif ketika datang ke klien CL dan implementasi spesifikasi CL. Vega menyarankan agar Dustin membuat posting HackMD yang merinci kekhawatirannya dan mendiskusikan topik tersebut pada panggilan tes Cancun / Deneb berikutnya. Jayanthi menambahkan bahwa berdasarkan beberapa masalah yang baru-baru ini diidentifikasi pada Cancun / Deneb Devnets, ada kebutuhan yang jelas bagi pengembang untuk memiliki alat yang secara sistematis dapat melakukan sejumlah perilaku terkait integrasi on-chain, seperti mempertaruhkan penarikan ETH, penarikan validator, dll. Untuk melakukan ini, Jayanthi merekomendasikan untuk membangun alat semacam itu menggunakan campuran suite uji Hive dan Kurtosis.
Berbicara tentang alat pengujian baru untuk upgrade Cancun / Deneb, Jayanthi mencatat bahwa pengembang sedang mengerjakan alat untuk mengaktifkan reuni rantai dengan andal di Devnet dan testnet. Untuk memastikan bahwa alat ini berfungsi, Jayanthi meminta pengembang untuk membagikan rincian bug yang diketahui yang memicu reorg rantai di Ethereum. Jayanthi menjelaskan bahwa ia akan menggunakan bug ini untuk menguji alat dan memastikan bahwa alat tersebut dapat mengidentifikasi dengan andal kapan reorganisasi terjadi dan kapan diselesaikan.
Klarifikasi spesifikasi jaringan
Para pengembang secara singkat membahas permintaan tarik terbuka yang diusulkan oleh peneliti Ethereum Foundation Justin Traglia mengenai urutan tanggapan yang harus dikembalikan klien CL ketika menerima permintaan "BlockbyRoot" atau "BlobSidecarsByRoot". Ryan bertanya bagaimana tim klien CL yang berbeda sudah menerapkan fitur ini. Tak satu pun dari pengembang yang menelepon menjawab pertanyaan ini. Ryan menyarankan untuk menghidupkan kembali diskusi di saluran Ethereum Research &; Development Discord untuk melibatkan pengembang klien yang lebih luas. Ryan mengakui bahwa ada ambiguitas dalam spesifikasi dua permintaan, yang "mungkin menjadi penyebab masalah dan kasus tepi yang aneh" dan "layak untuk diklarifikasi dan diselesaikan," Ryan menegaskan.
Ryan juga menyebutkan bahwa ia akan merilis versi baru dari spesifikasi CL dalam beberapa hari ke depan. Versi terbaru secara signifikan menambahkan spesifikasi ketika klien CL dapat menyediakan blok dan blok melalui permintaan RPC "byRoot". Untuk latar belakang lebih lanjut tentang diskusi tentang mengambil blok dan blok yang hilang melalui permintaan RPC "byRoot", silakan merujuk ke log panggilan sebelumnya. Ryan menekankan bahwa penambahan baru pada spesifikasi CL yang disertakan dalam versi terbaru tidak akan memiliki perubahan yang melanggar pada kode yang memengaruhi kode untuk validator yang sudah berjalan di Devnet #11 atau #12.
Proses perencanaan upgrade
Selanjutnya, para pengembang membahas berbagai item proses yang diusulkan oleh Beiko. Beiko mengatakan bahwa posting blog yang memperingatkan pengguna testnet Goerli tentang penghentian yang akan datang dalam waktu 3 bulan setelah peningkatan Cancun / Deneb diaktifkan di Goerli, atau 1 bulan setelah peningkatan diaktifkan di mainnet Ethereum, mana saja yang lebih lambat, akan dipublikasikan di blog Ethereum Foundation pada 30 November. Sejak kesimpulan panggilan, posting blog di atas telah diterbitkan dan dapat dibaca di sini.
Beiko menyarankan untuk membuat folder khusus peningkatan di bawah repositori "pm" Ethereum untuk mengatur berbagai file yang terkait dengan peningkatan tertentu ke dalam satu folder untuk digunakan nanti. Pengembang di telepon setuju dengan saran Beiko.
Item proses kedua yang diusulkan oleh Beiko adalah tentang membuat dokumen "Meta EIP" untuk melacak cakupan penuh peningkatan jaringan yang telah diselesaikan di Ethereum. "Tidak ada tempat yang baik untuk melacak cakupan penuh peningkatan jaringan sebelum menyebarkan dan mengumumkannya dalam posting blog," tulis Beiko dalam sebuah posting tentang proposal Meta EIP-nya. "Untuk Dencun, kami memiliki EIP EL dalam file penurunan harga 7 yang sulit ditemukan, dan CL EIP adalah bagian dari Spesifikasi Rantai Suar 3. Ini tidak bagus, karena keduanya agak sulit ditemukan, mereka menggunakan 'format' yang berbeda, dan mereka mengarah pada duplikasi. Karena ERC dan EIP sekarang terpisah, saya sarankan (kembali) menggunakan Meta EIP untuk melacak EIP yang termasuk dalam peningkatan jaringan. Para pengembang mendukung pembuatan dokumen-dokumen ini. Beiko mengatakan dia akan menyusun dokumen untuk tinjauan peningkatan Cancun / Deneb minggu ini.
Akhirnya, Beiko mengajukan pertanyaan tentang kegunaan menandai perubahan kode yang diusulkan, Ethereum Improvement Proposals (EIPs), sebagai "Pertimbangkan Inklusi" (CFI). Menurut Beiko, CFI adalah status yang secara historis digunakan pengembang sebagai "sinyal lunak", yang menunjukkan bahwa penulis EIP harus terus mengerjakan proposal yang mungkin dimasukkan dalam hard fork di masa depan. Ini hanya digunakan untuk perubahan dan peningkatan kode yang berfokus pada EL. 「[CFI] lebih tinggi dari ide-ide acak dari orang-orang acak, tetapi sebelum mereka diterima di garpu," kata Beiko.
Di masa lalu, pelabelan CFI telah melakukan sedikit atau tidak ada upaya dalam menunjukkan EIP mana pada EL yang akan diterapkan dalam peningkatan, atau kapan. Ini telah diterapkan pada berbagai EIP dengan berbagai tingkat kesiapan kode dan dukungan dari tim klien. Dalam kasus proposal EVM Object Format (EOF), pengembang menggunakan tag ini untuk menunjukkan komitmen mereka untuk menerapkan EOF dalam peningkatan mendatang berikutnya, Cancun/Deneb. Namun, EOF, serta beberapa proposal lain yang juga ditandai sebagai CFI, telah ditolak dari Cancun / Deneb, dan tidak jelas status EIP ini ditandai sebagai CFI dalam peningkatan berikutnya Praha / Electra.
Beiko mengatakan bahwa jika keadaan ini tidak membantu, pengembang harus menghapusnya, tetapi jika mereka berniat untuk menyimpannya, pengembang CL juga harus menggunakan label yang sama pada perubahan kode yang mereka pertimbangkan untuk diterapkan dalam peningkatan CL. Tidak jelas sejauh mana proses peninjauan CL EIP mencerminkan proses peninjauan EL EIP dan apakah mereka harus berkembang dengan cara yang sama di masa depan. Biasanya, perubahan kode yang diusulkan pada spesifikasi CL dibahas pada panggilan konferensi ACDC, sementara EIP yang diusulkan ke spesifikasi EL dibahas pada panggilan konferensi ACDE.
Danno Ferrin dari Swirlds Labs juga datang dengan ide untuk membuat bidang placeholder untuk semua EIP, baik CL atau EL terkait, yang mengidentifikasi status mereka selama proses peninjauan, termasuk status CFI. Pada panggilan ini, tidak ada keputusan yang jelas tentang topik status EIP dan pelabelan CFI.