30 Kasım 2023'te Ethereum geliştiricileri, Tüm Çekirdek Geliştiriciler Konsensüsü (ACDC) çağrısı #122 toplantısı için Zoom'da bir araya geldi. ACDC konferans görüşmesi, Ethereum Vakfı araştırmacısı Danny Ryan tarafından yönetilen, geliştiricilerin Ethereum'un konsensüs katmanındaki (CL) değişiklikleri tartıştığı ve koordine ettiği iki haftada bir yapılan bir dizi toplantıdır. Bu hafta geliştiriciler, aşağıdakiler de dahil olmak üzere Cancun/Deneb testindeki en son gelişmelere odaklandı:
· Devnet #12'nin lansmanı: Teku, Lodestar ve Lighthouse istemci yazılımlarının Devnet #12'de test edilmesinin yanı sıra tüm yürütme katmanı (EL) istemci yazılımları devam ediyor. Prysm ekibi, yazılımlarının en son Devnet'te iki ila üç hafta içinde teste hazır olmasını bekliyor.
· Devnet #11'de Doğrulayıcı Çıkış Sorunu: Devnet #11'de geliştiriciler, şu anda Nimbus istemci ekibi tarafından çözülmekte olan doğrulayıcı çıkışıyla ilgili bir sorun tespit etti. Devnet #11, sorun çözülene kadar normal şekilde çalışmaya devam edecektir.
· Ağ Spesifikasyonu Açıklaması: Geliştiriciler, "BlockByRoot" ve "BlobSidecarsByRoot" istekleri için spesifikasyonu açıklığa kavuşturmayı tartıştı ve konsensüs katmanı (CL) düğümlerinin bu isteklere belirli bir sırayla yanıt vermesi gerekip gerekmediğini açıklığa kavuşturdu.
Cancun/Deneb güncellemesine ek olarak geliştiriciler, Ethereum yükseltmesinin koordinasyonunu iyileştirmek için Ethereum Vakfı'nın Protokol Destek Başkanı Tim Beiko tarafından gündeme getirilen bazı süreç sorunlarını tartıştılar.
Geliştirici #12
30 Kasım 2023 Çarşamba günü, Cancun/Deneb yükseltmesi Devnet #12'de resmi olarak başlatıldı. Ethereum Vakfı'nın test ekibinden Mario Vega, şu anda test ağında çalışan üç CL istemcisinde "bugüne kadar önemli bir sorun tespit edilmediğini" söyledi. Vakıfta DevOps mühendisi olan Barnabas Busa, Lighthouse, Teku ve Lodestar arasında üç düğüme yayılmış toplam 225 doğrulayıcı olduğunu belirtti. Devnet #12'nin kararlılığı nedeniyle, Foundation'da bir DevOps mühendisi olan Parithosh Jayanthi, geliştiricilere Cancun/Deneb'i daha fazla test etmek için bir Goerli gölge çatalı planlamaya başlamaları gerekip gerekmediğini sordu. Bununla birlikte, şu anda en popüler CL istemcisi olan Prysm'in henüz Devnet #12'ye katılmadığını göz önünde bulundurarak, geliştiriciler, Prysm istemci yazılımı test için hazır olana kadar bir Goerli gölge çatalı için planları beklemeye almaya karar verdiler. Beiko, yıl sonundan bir süre önce Goerli gölge çatalına geçmeyi öneriyor. Devnet #12'nin kararlılığı nedeniyle, Prysm istemci yazılımı test için hazır olana kadar planlar beklemeye alınır.
Geliştirici #11
"Dustin" ekran adını kullanan Nimbus geliştiricisi, ekibinin üzerinde çalıştığı Devnet #11 sayısının detaylarını paylaşıyor. Bu sorunlar ilk olarak bir geliştirici, Devnet #12'de kullanılmak üzere Devnet #11'in doğrulayıcılarının üçte birinden çıktığında keşfedildi. Ryan, Dustin'e ek testlerle bu sorunları tespit edip edemeyeceğini sorar. Dustin, kendi görüşüne göre, bu hataların doğasının, fikir birliği spesifikasyonunun kapsamı dışındaki uygulama ayrıntılarından kaynaklandığını söyledi. Bununla birlikte, kapsamın faydalarını test etmek için istemci yazılımını kesinlikle CL spesifikasyonuna yazmak ile daha iyi düğüm performansı elde etmek için spesifikasyonun gri alanlarına girmek arasında "açık bir gerilim" olduğunu da kabul ediyor.
"Demek istediğim, daha fazla test her zaman iyidir, ancak daha fazla istemci tarafı işlevselliğinin çalışan testlere nasıl dahil edileceğini daha sistematik bir şekilde bulmak, ister Hive ister Basıklık veya her neyse, belki daha otomatiktir. Bu sorunların çözülebilmesinin veya bu görevlerin daha fazlasını dahil edebilecek kadar güzel bir şekilde parçalanabilmesinin kesinlikle yararlı olacağını düşünüyorum," diye ekledi Dustin, CL geliştiricilerinin ele almayı düşünmesi gereken bir diğer zorluğun, CL spesifikasyonunun düğüm davranışını dikte etmesi ve standartlaştırması gereken ayrıntı düzeyini bulmak olduğunu da sözlerine ekledi. "Buradaki diğer zorluk, gerçekten sadece bir yazılım mühendisliği sorunu olmayan standardizasyon derecesidir, davranış ne kadar standartlaştırılmalıdır?" Diye sordu Dustin. Tüm CL istemcileri, temel davranışı denetleyen testlerden geçer, ancak bu testlerin kapsamı dışındaki davranışlar belirsizdir. "Bunlar kasıtlı olarak belirsiz şeyler mi? Norm tarafından gerçekten açık olan ve kasıtlı olarak belirsiz olan nedir?" Diye sordu Dustin.
En azından geliştiriciler, Cancun/Deneb'deki çok sayıda doğrulayıcı çıkışı için gelecekteki Devnet'lere ve test ağlarına daha fazla test eklemeyi kabul etti. Ryan ayrıca, CL istemcileri ve CL spesifikasyon uygulaması söz konusu olduğunda daha titiz ve kapsamlı test kapsamı için yer olduğunu da kabul ediyor. Vega, Dustin'in endişelerini detaylandıran bir HackMD gönderisi oluşturmasını ve konuyu bir sonraki Cancun/Deneb test görüşmesinde tartışmasını önerdi. Jayanthi, Cancun/Deneb Devnets'te yakın zamanda tespit edilen bazı sorunlara dayanarak, geliştiricilerin ETH para çekme işlemleri, doğrulayıcı para çekme işlemleri vb. gibi belirli sayıda zincir içi entegrasyonla ilgili davranışları sistematik olarak gerçekleştirebilecek araçlara sahip olmalarına açık bir ihtiyaç olduğunu da sözlerine ekledi. Bunu yapmak için Jayanthi, Hive ve Basıklık test paketlerinin bir karışımını kullanarak böyle bir araç oluşturmanızı önerir.
Cancun/Deneb yükseltmesi için yeni test aracı hakkında konuşan Jayanthi, geliştiricilerin Devnet'lerde ve test ağlarında zincir birleşmelerini güvenilir bir şekilde etkinleştirmek için bir araç üzerinde çalıştıklarını belirtti. Bu aracın çalıştığından emin olmak için Jayanthi, geliştiricilerden Ethereum'da zincir yeniden düzenlemelerini tetikleyen bilinen hataların ayrıntılarını paylaşmalarını istedi. Jayanthi, aracı test etmek ve bir yeniden yapılanmanın ne zaman gerçekleştiğini ve ne zaman çözüldüğünü güvenilir bir şekilde belirleyebilmesini sağlamak için bu hataları kullanacağını açıkladı.
Ağ özelliklerinin açıklığa kavuşturulması
Geliştiriciler, Ethereum Vakfı araştırmacısı Justin Traglia tarafından CL istemcilerinin bir "BlockbyRoot" veya "BlobSidecarsByRoot" isteği aldıklarında döndürmeleri gereken yanıtların sırasına ilişkin olarak önerilen açık bir çekme isteğini kısaca tartıştılar. Ryan, farklı CL müşteri ekiplerinin bu özelliği nasıl uyguladığını soruyor. Görüşmedeki geliştiricilerin hiçbiri bu soruyu yanıtlamadı. Ryan, Ethereum Araştırma ve Geliştirme Discord kanalındaki tartışmayı daha geniş bir müşteri geliştirici yelpazesini dahil etmek için yeniden canlandırmayı önerdi. Ryan, iki talebin özelliklerinde "sorunların ve garip uç durumların nedeni olabilecek" ve "açıklığa kavuşturulmayı ve çözülmeyi hak eden" belirsizlikler olduğunu kabul ediyor.
Ryan, önümüzdeki birkaç gün içinde CL spesifikasyonunun yeni bir sürümünü yayınlayacağını da belirtti. En son sürüm, bir CL istemcisinin bir "byRoot" RPC isteği aracılığıyla ne zaman blok ve blok sağlayabileceğine ilişkin özellikleri önemli ölçüde ekler. Eksik blokları ve blokları "byRoot" RPC istekleri aracılığıyla alma tartışması hakkında daha fazla bilgi için lütfen önceki çağrı günlüğüne bakın. Ryan, en son sürümde yer alan CL spesifikasyonuna yapılan yeni eklemelerin, halihazırda Devnet #11 veya #12'de çalışan doğrulayıcıların kodunu etkileyen kodda herhangi bir hataya neden olan değişiklik olmayacağını vurguluyor.
Yükseltme planlama süreci
Daha sonra, geliştiriciler Beiko tarafından önerilen çeşitli süreç maddelerini tartıştılar. Beiko, Goerli test ağı kullanıcılarını Cancun/Deneb yükseltmesinin Goerli'de etkinleştirilmesinden sonraki 3 ay içinde veya yükseltmenin Ethereum ana ağında etkinleştirilmesinden sonraki 1 ay içinde (hangisi daha sonraysa) yaklaşan kullanımdan kaldırma konusunda uyaran bir blog gönderisinin 30 Kasım'da Ethereum Vakfı blogunda yayınlanacağını söyledi. Görüşmenin sona ermesinden bu yana, yukarıdaki blog yazısı yayınlandı ve buradan okunabilir.
Beiko, belirli bir yükseltmeyle ilgili çeşitli dosyaları daha sonra kullanmak üzere tek bir klasörde düzenlemek için Ethereum "pm" deposu altında yükseltmeye özel bir klasör oluşturmayı önerir. Görüşmedeki geliştiriciler Beiko'nun önerisini kabul etti.
Beiko tarafından önerilen ikinci işlem maddesi, Ethereum'da tamamlanan ağ yükseltmelerinin tam kapsamını izlemek için bir "Meta EIP" belgesi oluşturmakla ilgilidir. Beiko, Meta EIP teklifiyle ilgili bir gönderide, "Bir ağ yükseltmesini dağıtmadan ve bir blog gönderisinde duyurmadan önce tam kapsamını izlemek için iyi bir yer yok" diye yazdı. "Dencun için, bulunması zor bir işaretleme dosyası 7'de EL EIP'lerimiz var ve CL EIP'ler Beacon Chain Spesifikasyonu 3'ün bir parçası. Bu harika değil, çünkü her ikisini de bulmak biraz zor, farklı 'formatlar' kullanıyorlar ve çoğaltmaya yol açıyorlar. ERC ve EIP'ler artık ayrı olduğundan, ağ yükseltmesine dahil olan EIP'leri izlemek için Meta EIP'leri kullanmanızı öneririm (geri dönerek). Geliştiriciler bu belgeleri oluşturmaktan yanaydı. Beiko, bu hafta Cancun/Deneb yükseltme incelemesi için bir belge hazırlayacağını söyledi.
Son olarak Beiko, önerilen kod değişikliklerini, Ethereum İyileştirme Önerilerini (EIP'ler) "Dahil Etmeyi Düşünün" (CFI) olarak işaretlemenin yararlılığı hakkında bir soru yöneltti. Beiko'ya göre CFI, geliştiricilerin tarihsel olarak "yumuşak bir sinyal" olarak kullandıkları bir durumdur ve bu da EIP'nin yazarlarının gelecekteki hard fork'lara dahil edilebilecek teklifler üzerinde çalışmaya devam etmesi gerektiğini gösterir. Yalnızca EL odaklı kod değişiklikleri ve yükseltmeleri için kullanılır. 「[CFI] rastgele insanlardan gelen rastgele fikirlerden daha yüksek, ancak çatalda kabul edilmeden önce, "dedi Beiko.
Geçmişte, CFI'leri etiketlemek, yükseltmede EL'deki hangi EIP'lerin uygulanacağını veya ne zaman uygulanacağını belirtmek için çok az çaba sarf etti veya hiç çaba göstermedi. Farklı derecelerde kod hazırlığı ve müşteri ekiplerinden destek alan çok çeşitli EIP'lere uygulanmıştır. EVM Nesne Formatı (EOF) önerisi söz konusu olduğunda, geliştiriciler bu etiketi, bir sonraki yaklaşan yükseltme olan Cancun/Deneb'de EOF'yi uygulama taahhütlerini belirtmek için kullanır. Bununla birlikte, EOF'nin yanı sıra CFI olarak işaretlenen diğer bazı teklifler de Cancun/Deneb'den reddedildi ve bir sonraki yükseltme Prag/Electra'da CFI olarak işaretlenen bu EIP'lerin durumu belirsiz.
Beiko, bu durum yardımcı olmazsa, geliştiricilerin onu kaldırması gerektiğini, ancak bunu korumak istiyorlarsa, CL geliştiricilerinin CL yükseltmelerinde uygulamayı düşündükleri kod değişikliklerinde de aynı etiketi kullanmaları gerektiğini söyledi. CL EIP inceleme sürecinin EL EIP inceleme sürecini ne ölçüde yansıttığı ve gelecekte aynı şekilde gelişmesi gerekip gerekmediği belirsizdir. Tipik olarak, CL spesifikasyonunda önerilen kod değişiklikleri ACDC konferans görüşmesinde tartışılırken, EL spesifikasyonunda önerilen EIP'ler ACDE konferans görüşmesinde tartışılır.
Swirlds Labs'tan Danno Ferrin, CL veya EL ile ilgili olsun, tüm EIP'ler için CFI durumu da dahil olmak üzere inceleme sürecindeki durumlarını tanımlayan bir yer tutucu alan oluşturma fikrini de ortaya attı. Bu çağrıda, EIP statüsü ve CFI etiketlemesi konusunda net bir karar alınmadı.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Ethereum çekirdek geliştiricilerinin en son toplantısının özeti: Devnet #12启动, yükseltme planlama süreci
30 Kasım 2023'te Ethereum geliştiricileri, Tüm Çekirdek Geliştiriciler Konsensüsü (ACDC) çağrısı #122 toplantısı için Zoom'da bir araya geldi. ACDC konferans görüşmesi, Ethereum Vakfı araştırmacısı Danny Ryan tarafından yönetilen, geliştiricilerin Ethereum'un konsensüs katmanındaki (CL) değişiklikleri tartıştığı ve koordine ettiği iki haftada bir yapılan bir dizi toplantıdır. Bu hafta geliştiriciler, aşağıdakiler de dahil olmak üzere Cancun/Deneb testindeki en son gelişmelere odaklandı:
· Devnet #12'nin lansmanı: Teku, Lodestar ve Lighthouse istemci yazılımlarının Devnet #12'de test edilmesinin yanı sıra tüm yürütme katmanı (EL) istemci yazılımları devam ediyor. Prysm ekibi, yazılımlarının en son Devnet'te iki ila üç hafta içinde teste hazır olmasını bekliyor.
· Devnet #11'de Doğrulayıcı Çıkış Sorunu: Devnet #11'de geliştiriciler, şu anda Nimbus istemci ekibi tarafından çözülmekte olan doğrulayıcı çıkışıyla ilgili bir sorun tespit etti. Devnet #11, sorun çözülene kadar normal şekilde çalışmaya devam edecektir.
· Ağ Spesifikasyonu Açıklaması: Geliştiriciler, "BlockByRoot" ve "BlobSidecarsByRoot" istekleri için spesifikasyonu açıklığa kavuşturmayı tartıştı ve konsensüs katmanı (CL) düğümlerinin bu isteklere belirli bir sırayla yanıt vermesi gerekip gerekmediğini açıklığa kavuşturdu.
Cancun/Deneb güncellemesine ek olarak geliştiriciler, Ethereum yükseltmesinin koordinasyonunu iyileştirmek için Ethereum Vakfı'nın Protokol Destek Başkanı Tim Beiko tarafından gündeme getirilen bazı süreç sorunlarını tartıştılar.
Geliştirici #12
30 Kasım 2023 Çarşamba günü, Cancun/Deneb yükseltmesi Devnet #12'de resmi olarak başlatıldı. Ethereum Vakfı'nın test ekibinden Mario Vega, şu anda test ağında çalışan üç CL istemcisinde "bugüne kadar önemli bir sorun tespit edilmediğini" söyledi. Vakıfta DevOps mühendisi olan Barnabas Busa, Lighthouse, Teku ve Lodestar arasında üç düğüme yayılmış toplam 225 doğrulayıcı olduğunu belirtti. Devnet #12'nin kararlılığı nedeniyle, Foundation'da bir DevOps mühendisi olan Parithosh Jayanthi, geliştiricilere Cancun/Deneb'i daha fazla test etmek için bir Goerli gölge çatalı planlamaya başlamaları gerekip gerekmediğini sordu. Bununla birlikte, şu anda en popüler CL istemcisi olan Prysm'in henüz Devnet #12'ye katılmadığını göz önünde bulundurarak, geliştiriciler, Prysm istemci yazılımı test için hazır olana kadar bir Goerli gölge çatalı için planları beklemeye almaya karar verdiler. Beiko, yıl sonundan bir süre önce Goerli gölge çatalına geçmeyi öneriyor. Devnet #12'nin kararlılığı nedeniyle, Prysm istemci yazılımı test için hazır olana kadar planlar beklemeye alınır.
Geliştirici #11
"Dustin" ekran adını kullanan Nimbus geliştiricisi, ekibinin üzerinde çalıştığı Devnet #11 sayısının detaylarını paylaşıyor. Bu sorunlar ilk olarak bir geliştirici, Devnet #12'de kullanılmak üzere Devnet #11'in doğrulayıcılarının üçte birinden çıktığında keşfedildi. Ryan, Dustin'e ek testlerle bu sorunları tespit edip edemeyeceğini sorar. Dustin, kendi görüşüne göre, bu hataların doğasının, fikir birliği spesifikasyonunun kapsamı dışındaki uygulama ayrıntılarından kaynaklandığını söyledi. Bununla birlikte, kapsamın faydalarını test etmek için istemci yazılımını kesinlikle CL spesifikasyonuna yazmak ile daha iyi düğüm performansı elde etmek için spesifikasyonun gri alanlarına girmek arasında "açık bir gerilim" olduğunu da kabul ediyor.
"Demek istediğim, daha fazla test her zaman iyidir, ancak daha fazla istemci tarafı işlevselliğinin çalışan testlere nasıl dahil edileceğini daha sistematik bir şekilde bulmak, ister Hive ister Basıklık veya her neyse, belki daha otomatiktir. Bu sorunların çözülebilmesinin veya bu görevlerin daha fazlasını dahil edebilecek kadar güzel bir şekilde parçalanabilmesinin kesinlikle yararlı olacağını düşünüyorum," diye ekledi Dustin, CL geliştiricilerinin ele almayı düşünmesi gereken bir diğer zorluğun, CL spesifikasyonunun düğüm davranışını dikte etmesi ve standartlaştırması gereken ayrıntı düzeyini bulmak olduğunu da sözlerine ekledi. "Buradaki diğer zorluk, gerçekten sadece bir yazılım mühendisliği sorunu olmayan standardizasyon derecesidir, davranış ne kadar standartlaştırılmalıdır?" Diye sordu Dustin. Tüm CL istemcileri, temel davranışı denetleyen testlerden geçer, ancak bu testlerin kapsamı dışındaki davranışlar belirsizdir. "Bunlar kasıtlı olarak belirsiz şeyler mi? Norm tarafından gerçekten açık olan ve kasıtlı olarak belirsiz olan nedir?" Diye sordu Dustin.
En azından geliştiriciler, Cancun/Deneb'deki çok sayıda doğrulayıcı çıkışı için gelecekteki Devnet'lere ve test ağlarına daha fazla test eklemeyi kabul etti. Ryan ayrıca, CL istemcileri ve CL spesifikasyon uygulaması söz konusu olduğunda daha titiz ve kapsamlı test kapsamı için yer olduğunu da kabul ediyor. Vega, Dustin'in endişelerini detaylandıran bir HackMD gönderisi oluşturmasını ve konuyu bir sonraki Cancun/Deneb test görüşmesinde tartışmasını önerdi. Jayanthi, Cancun/Deneb Devnets'te yakın zamanda tespit edilen bazı sorunlara dayanarak, geliştiricilerin ETH para çekme işlemleri, doğrulayıcı para çekme işlemleri vb. gibi belirli sayıda zincir içi entegrasyonla ilgili davranışları sistematik olarak gerçekleştirebilecek araçlara sahip olmalarına açık bir ihtiyaç olduğunu da sözlerine ekledi. Bunu yapmak için Jayanthi, Hive ve Basıklık test paketlerinin bir karışımını kullanarak böyle bir araç oluşturmanızı önerir.
Cancun/Deneb yükseltmesi için yeni test aracı hakkında konuşan Jayanthi, geliştiricilerin Devnet'lerde ve test ağlarında zincir birleşmelerini güvenilir bir şekilde etkinleştirmek için bir araç üzerinde çalıştıklarını belirtti. Bu aracın çalıştığından emin olmak için Jayanthi, geliştiricilerden Ethereum'da zincir yeniden düzenlemelerini tetikleyen bilinen hataların ayrıntılarını paylaşmalarını istedi. Jayanthi, aracı test etmek ve bir yeniden yapılanmanın ne zaman gerçekleştiğini ve ne zaman çözüldüğünü güvenilir bir şekilde belirleyebilmesini sağlamak için bu hataları kullanacağını açıkladı.
Ağ özelliklerinin açıklığa kavuşturulması
Geliştiriciler, Ethereum Vakfı araştırmacısı Justin Traglia tarafından CL istemcilerinin bir "BlockbyRoot" veya "BlobSidecarsByRoot" isteği aldıklarında döndürmeleri gereken yanıtların sırasına ilişkin olarak önerilen açık bir çekme isteğini kısaca tartıştılar. Ryan, farklı CL müşteri ekiplerinin bu özelliği nasıl uyguladığını soruyor. Görüşmedeki geliştiricilerin hiçbiri bu soruyu yanıtlamadı. Ryan, Ethereum Araştırma ve Geliştirme Discord kanalındaki tartışmayı daha geniş bir müşteri geliştirici yelpazesini dahil etmek için yeniden canlandırmayı önerdi. Ryan, iki talebin özelliklerinde "sorunların ve garip uç durumların nedeni olabilecek" ve "açıklığa kavuşturulmayı ve çözülmeyi hak eden" belirsizlikler olduğunu kabul ediyor.
Ryan, önümüzdeki birkaç gün içinde CL spesifikasyonunun yeni bir sürümünü yayınlayacağını da belirtti. En son sürüm, bir CL istemcisinin bir "byRoot" RPC isteği aracılığıyla ne zaman blok ve blok sağlayabileceğine ilişkin özellikleri önemli ölçüde ekler. Eksik blokları ve blokları "byRoot" RPC istekleri aracılığıyla alma tartışması hakkında daha fazla bilgi için lütfen önceki çağrı günlüğüne bakın. Ryan, en son sürümde yer alan CL spesifikasyonuna yapılan yeni eklemelerin, halihazırda Devnet #11 veya #12'de çalışan doğrulayıcıların kodunu etkileyen kodda herhangi bir hataya neden olan değişiklik olmayacağını vurguluyor.
Yükseltme planlama süreci
Daha sonra, geliştiriciler Beiko tarafından önerilen çeşitli süreç maddelerini tartıştılar. Beiko, Goerli test ağı kullanıcılarını Cancun/Deneb yükseltmesinin Goerli'de etkinleştirilmesinden sonraki 3 ay içinde veya yükseltmenin Ethereum ana ağında etkinleştirilmesinden sonraki 1 ay içinde (hangisi daha sonraysa) yaklaşan kullanımdan kaldırma konusunda uyaran bir blog gönderisinin 30 Kasım'da Ethereum Vakfı blogunda yayınlanacağını söyledi. Görüşmenin sona ermesinden bu yana, yukarıdaki blog yazısı yayınlandı ve buradan okunabilir.
Beiko, belirli bir yükseltmeyle ilgili çeşitli dosyaları daha sonra kullanmak üzere tek bir klasörde düzenlemek için Ethereum "pm" deposu altında yükseltmeye özel bir klasör oluşturmayı önerir. Görüşmedeki geliştiriciler Beiko'nun önerisini kabul etti.
Beiko tarafından önerilen ikinci işlem maddesi, Ethereum'da tamamlanan ağ yükseltmelerinin tam kapsamını izlemek için bir "Meta EIP" belgesi oluşturmakla ilgilidir. Beiko, Meta EIP teklifiyle ilgili bir gönderide, "Bir ağ yükseltmesini dağıtmadan ve bir blog gönderisinde duyurmadan önce tam kapsamını izlemek için iyi bir yer yok" diye yazdı. "Dencun için, bulunması zor bir işaretleme dosyası 7'de EL EIP'lerimiz var ve CL EIP'ler Beacon Chain Spesifikasyonu 3'ün bir parçası. Bu harika değil, çünkü her ikisini de bulmak biraz zor, farklı 'formatlar' kullanıyorlar ve çoğaltmaya yol açıyorlar. ERC ve EIP'ler artık ayrı olduğundan, ağ yükseltmesine dahil olan EIP'leri izlemek için Meta EIP'leri kullanmanızı öneririm (geri dönerek). Geliştiriciler bu belgeleri oluşturmaktan yanaydı. Beiko, bu hafta Cancun/Deneb yükseltme incelemesi için bir belge hazırlayacağını söyledi.
Son olarak Beiko, önerilen kod değişikliklerini, Ethereum İyileştirme Önerilerini (EIP'ler) "Dahil Etmeyi Düşünün" (CFI) olarak işaretlemenin yararlılığı hakkında bir soru yöneltti. Beiko'ya göre CFI, geliştiricilerin tarihsel olarak "yumuşak bir sinyal" olarak kullandıkları bir durumdur ve bu da EIP'nin yazarlarının gelecekteki hard fork'lara dahil edilebilecek teklifler üzerinde çalışmaya devam etmesi gerektiğini gösterir. Yalnızca EL odaklı kod değişiklikleri ve yükseltmeleri için kullanılır. 「[CFI] rastgele insanlardan gelen rastgele fikirlerden daha yüksek, ancak çatalda kabul edilmeden önce, "dedi Beiko.
Geçmişte, CFI'leri etiketlemek, yükseltmede EL'deki hangi EIP'lerin uygulanacağını veya ne zaman uygulanacağını belirtmek için çok az çaba sarf etti veya hiç çaba göstermedi. Farklı derecelerde kod hazırlığı ve müşteri ekiplerinden destek alan çok çeşitli EIP'lere uygulanmıştır. EVM Nesne Formatı (EOF) önerisi söz konusu olduğunda, geliştiriciler bu etiketi, bir sonraki yaklaşan yükseltme olan Cancun/Deneb'de EOF'yi uygulama taahhütlerini belirtmek için kullanır. Bununla birlikte, EOF'nin yanı sıra CFI olarak işaretlenen diğer bazı teklifler de Cancun/Deneb'den reddedildi ve bir sonraki yükseltme Prag/Electra'da CFI olarak işaretlenen bu EIP'lerin durumu belirsiz.
Beiko, bu durum yardımcı olmazsa, geliştiricilerin onu kaldırması gerektiğini, ancak bunu korumak istiyorlarsa, CL geliştiricilerinin CL yükseltmelerinde uygulamayı düşündükleri kod değişikliklerinde de aynı etiketi kullanmaları gerektiğini söyledi. CL EIP inceleme sürecinin EL EIP inceleme sürecini ne ölçüde yansıttığı ve gelecekte aynı şekilde gelişmesi gerekip gerekmediği belirsizdir. Tipik olarak, CL spesifikasyonunda önerilen kod değişiklikleri ACDC konferans görüşmesinde tartışılırken, EL spesifikasyonunda önerilen EIP'ler ACDE konferans görüşmesinde tartışılır.
Swirlds Labs'tan Danno Ferrin, CL veya EL ile ilgili olsun, tüm EIP'ler için CFI durumu da dahil olmak üzere inceleme sürecindeki durumlarını tanımlayan bir yer tutucu alan oluşturma fikrini de ortaya attı. Bu çağrıda, EIP statüsü ve CFI etiketlemesi konusunda net bir karar alınmadı.