Orijinal başlık: "Ethereum All Core Developers Execution Call #189 Writeup" Orijinal yazar: Christine Kim Orijinal derleme: Luccy, BlockBeats Editörün notu: Ethereum All Core Developers Execution Call (ACDE), esas olarak tartışma ve koordinasyon amacıyla iki haftada bir yapılır. Ethereum Yürütme Katmanı (EL). Bu, ACDE'nin 189. konferans görüşmesidir. Bu toplantıda geliştiriciler, EOF ve EIP 7702 gibi değişiklikler, Pectra kapsamının iyileştirilmesi ve Verkle geçişi için hazırlıklar da dahil olmak üzere Pectra yükseltmesindeki bazı önemli konuları tartıştılar. Toplantıda ayrıca EOF ve diğer Pectra EIP'lerin nasıl paketlendiği ve bu kod değişikliklerinin nasıl test edildiği de tartışıldı. Ek olarak, ACD konferans görüşmesi konu tartışmalarının sıklığında ayarlamalar ve yeni EIP etiketi önerileri de dahil olmak üzere Ethereum ağ yükseltme sürecini iyileştirmek için bazı öneriler sunuldu. Ayrıca EIP 4444 ve Portal Ağının entegrasyon sürecine de değinildi. Galaxy Digital Araştırmadan Sorumlu Başkan Yardımcısı Christine Kim, bu toplantının kilit noktalarını detaylı bir şekilde kaydetti. BlockBeasts, orijinal metni şu şekilde derledi:

6 Haziran 2024'te Ethereum geliştiricileri, All Core Developers Execution (ACDE) çağrı #189 toplantısına katılmak için Zoom'da toplandı. ACDE Konferans Çağrısı, geliştiricilerin Ethereum Yürütme Katmanındaki (EL) değişiklikleri tartıştığı ve koordine ettiği, Ethereum Vakfı Protokol Desteği Başkanı Tim Beiko'nun ev sahipliği yaptığı, iki haftada bir düzenlenen bir dizi toplantıdır. Bu hafta geliştiriciler, Pectra yükseltmesine EOF ve EIP 7702'yi dahil etmeyi kabul etti. Bu kod değişiklikleri nedeniyle çok istemcili test yükseltmelerinde gecikmeleri önlemek için geliştiriciler, tıpkı geliştiricilerinPeerDAS'ı test etmeyi planladığı gibi, muhtemelen diğer EIP'lerden farklı bir etkinleştirme döngüsünde, geliştirme sonrası bir ağda EOF'yi etkinleştirmeyi kabul etti. Ayrıca Verkle'ye hazırlık amacıyla Osaka yükseltmesinde EIP 158'in nasıl devre dışı bırakılacağını ve Portal Ağı ile entegrasyon yoluyla EIP 4444'ün uygulanmasına yönelik sonraki adımları da tartıştılar. Son olarak Beiko ve EF Geliştirici Operasyonları (DevOps) ekibi, Ethereum yükseltmelerini planlamak için yönetim süreçleri ve iletişim kanallarına ilişkin en son güncellemeleri paylaştı.

Pektra'nın Kapsamı

Bu haftaki ACD toplantısı öncesinde çeşitli EL müşteri ekipleri ve EF DevOps ekipleri Pectra'nın kapsamı hakkındaki düşüncelerini paylaştı.

Toplantı öncesinde paylaşılan görüşlere göre müşteri ekiplerinin çoğunluğunun EOF'nin Pectra'ya dahil edilmesini desteklediği açıktır. EOF'ye şiddetle karşı çıkan tek müşteri ekibi Geth'tir. Geth geliştiricisi Guillaume Ballet şunları söyledi: "Ne kadar uzun süre beklersek, Verkle'nin geçiş sürecinin de o kadar uzun süreceğinden endişeleniyorum. EOF gerçekten bu kadar acil mi? Ben öyle düşünmüyorum. Prag. Ne kadar çok okursam, EOF'nin gerçekten gerekli olduğunu kanıtlayan hiçbir şeyin olmadığını o kadar çok fark ettim." Birkaç geliştirici buna itiraz etti.

"Kamil Sliwak" adlı bir geliştirici, EOF'nin, Ethereum akıllı sözleşme programlama dili Solidity'nin derleyicisi ile etkileşime giren kullanıcılar açısından "büyük bir gelişme" olacağını söyledi. Reth geliştiricisi Dragan Rakita, EOF'un Verkle geçişlerini önemli ölçüde geciktireceğini düşünmenin samimiyetsiz olacağını ekledi. Rakita, "Geçiş süresinin %10 ila %20 oranında uzatılmasından bahsediyoruz. EOF, durumu artırmayacak ve ek kısmi çatalların serbest bırakılması için ilave üç ay, Verkle'yi önemli ölçüde geciktirmeyecektir." dedi. EOF'nin ne olduğu ve Ethereum Sanal Makinesini (EVM) nasıl geliştireceği hakkında daha fazla bilgi için Infinite Jungle podcast'inin bu bölümünü dinleyin.

Beiko, geliştiricilere EOF'yi diğer Pectra EIP'leriyle birleştirmeyi mi yoksa Pectra'nın EIP'sini iki hard fork'a bölmeyi mi tercih edeceklerini sordu. Erigon geliştiricisi Andrew Ashikhmin, geliştiricilerin Pectra'nın tüm EIP'lerini birlikte yayınlamaya çalışması veya EOF'yi Verkle geçişi sonrasına ertelemesi gerektiğine inandığını söyledi. "İstediğim son şey, Pectra ve Verkle arasında bir çatalın EOF'yi serbest bırakması. Çünkü Guillaume ile eyaletin büyüdüğü konusunda hemfikirim, bence Verkle, EOF'den daha önemli. Yani bence bu, olabilecek en kötü sonuç. " dedi Aşikhmin. Beiko, EOF dahil tüm Pectra EIP'lerinin tek bir istemci sürümünde yayınlanmasını öneriyor. Ancak test amacıyla geliştiricilerin bu kod değişikliklerini aşamalı olarak uygulamak için bir geliştirme ağı kullanmayı düşünmeleri gerektiğini söyledi. Beiko, "Geliştirme ağını, çok müşterili testler açısından önceliklendirmemizin bir yolu olarak kullanıyoruz ve ardından EOF'nin işleri uzun süre geciktirdiğini görürsek, onu bölmeye karar verebiliriz" dedi.

EOF'un Pectra'ya nasıl dahil edileceğine ilişkin bu tartışmaların ortasında Geth geliştiricileri, Zoom sohbetinde ve toplantı boyunca EOF'un yükseltmeye dahil edilip edilmeyeceği konusundaki şüphelerini dile getirmeye devam etti. Geth ekibinin EOF konusunda devam eden tartışmasına yanıt olarak Reth geliştiricisi George Konstantinopoulos şunları söyledi: "Hadi yapalım. Konuşmanın nereye varacağı biraz kafa karıştırıcı. Verkle geçişini birkaç gün uzatmaktan çekinmeyiz. Veriler gösteriyor ki durum düşüyor, yani bu kafa karıştırıcı bir argüman ve size bunun iyi bir özellik olduğunu söyleyen bir sürü uygulamanız var, o halde çoğu insan bunu desteklerken neden bunu yapmamayı düşünelim ki?

Beiko, EOF'nin Pectra'ya dahil edilmesi ancak geliştirme ağında aşamalı olarak test edilmesi gerektiğini kabul etti ve yineledi; bu, müşteri ekiplerinin halihazırda Devnet 0'da uygulanan Devnet 1 EIP'leri üzerinde test etmesi gerektiği anlamına geliyor. Daha sonra gelecekteki geliştirme ağına test için EOF ekleyin. Bu strateji, müşteri ekibinin Pectra'nın EIP'sinin bir kısmını aynı zaman çizelgesinde yayınlamaya odaklanmasını ve çok müşterili geliştirme ağında ilerleme kaydetmeye devam edebilmesini sağlayacaktır. Ethereum Vakfı (EF) DevOps mühendisi Mario Vega, EOF'un yürütme katmanı (EL) spesifikasyon testlerinin iki ay içinde hazır olmasını beklediğini söyledi. EF DevOps mühendisi Parithosh Jayanthi, EOF'nin Pectra'daki diğer yürütme katmanı (EL) EIP'lerinden ayrı olarak test edilebileceğini söyledi. Ancak Pectra'daki konsensüs katmanı (CL) EIP'leri arasındaki karşılıklı bağımlılıklar ve bu kod değişikliklerini test etmenin karmaşıklığı konusunda endişeli.

Vyper derleyici geliştiricisi Charles Cooper, kendi görüşüne göre EOF'nin, yeniden giriş saldırılarına karşı korumayı ucuz ve yaygın hale getirmek için önerdiği kod değişiklikleri kadar acil olmadığını söyledi. Beiko, Cooper'a, EOF konusunda geniş fikir birliğinin açık olmasına rağmen, müşteri ekiplerinin yeniden giriş saldırılarıyla ilgili olanlar gibi daha fazla kod değişikliği eklemek için yeterli enerjiye sahip olup olmadıklarının belirsiz olduğunu hatırlattı. Beiko, "EOF ile ilerlemeye devam edersek, başka şeyler yapmak için çok az enerji kalacağının açık olduğunu düşünüyorum. Bu şimdiden bugüne kadarki en büyük çatallanma olacak" dedi.

Geliştiriciler, EOF'yi dahil etmenin yanı sıra, EIP 3074'ün yerine EIP 7702'yi de kabul etti. Geliştiriciler hala ayrı grup toplantılarında EIP 7702 spesifikasyonlarını tartışıyorlar. Beiko, EIP 7702 için EOF'ye benzer bir yaklaşım öneriyor. "Bunu çatala dahil ederdim, ancak eğer spesifikasyondan memnun kalmazsak, bunu Devnet 1 veya 2'nin parçası haline getirmeyin ve ardından gelecek ayı spesifikasyonu gerçekten düzenleyerek geçirin, böylece daha iyi bir iptal elde edebiliriz. Beiko, şu anda önerilenden çok daha büyük olmayan bir EIP mekanizmasının daha sonra ekleneceğine dikkat çekti. Geth geliştiricisi "Lightclient", müşteri ekibi hazırsa EIP 7702'yi mümkün olan en kısa sürede uygulamaya koymaları gerektiğini söyledi. EIP 7702'nin bir sonraki acil Pectra geliştirme ağı Devnet 1'e dahil edilmesine herhangi bir itiraz yoktur.

Pektra spesifikasyonu

Daha sonra Teku geliştiricisi Mikhail Kalinin, mevcut Pectra EIP spesifikasyonuna ilişkin bazı güncellemeleri paylaştı. Bunlardan ilki, tetikleyici konsensüs katmanı (CL) isteklerini doğrudan yürütme katmanı (EL) bloğu yerine bir yardımcı mekanizma yoluyla ele alma önerisidir. Prysm geliştiricisi "Potuz", bu stratejinin gelecekteki kod değişiklikleri için gerekli olan mantığı, yani açık teklif veren-oluşturucu ayrımını (ePBS) bozacağına dikkat çekti. Potuz, "İşaret bloğu, halihazırda orada bulunan yüke bağlı olmamalıdır. Dolayısıyla, ister para çekme ister para yatırma olsun, işaret bloğunun yükte bulunanlara güvenmesini istemezsiniz çünkü bu, ePBS'nin akışını kesecektir." söz konusu. Bu sorun nedeniyle Kalinin, tavsiyesini geri çekmeyi ve GitHub'daki çekme isteğini kapatmayı kabul etti.

Kalinin, Pectra'nın EL ve motor API spesifikasyonlarında birkaç değişiklik daha paylaştı; bunlardan biri, EIP 7251 altında EL ile tetiklenen birleştirmeyi etkinleştirerek MAX_EFFECTIVE_Balance'ı artırmaktı. Beiko, geliştiricilerin bu değişiklikleri bir sonraki ACD çağrısından önce gözden geçirmelerini, böylece bunların Devnet 1'de tamamlanıp teste hazır hale getirilmesini öneriyor.

Verkle hazırlığı

Verkle geçişi üzerine yaptığı çalışmaya dayanarak Ballet, EIP 158'in kullanımdan kaldırılan SELFDESTRUCT işlem koduyla benzer sorunlara neden olacağını söyledi. Geçiş sonrasında ağdaki komplikasyonları önlemek için Ballet, Pectra yükseltmelerinde EIP 158'in devre dışı bırakılmasını öneriyor. Ancak Pectra'da EIP 7702'nin uygulanmasına ince ayar yapılması durumunda EIP 158'in kullanımdan kaldırılmasının gecikebileceğini ve Verkle geçişiyle aynı zamana denk gelebileceğini belirtti. Beiko, Guillaume'un EIP 158'i devre dışı bırakma önerisini hazırlamaya başlamasını önerdi.

Geçmişin sona ermesi

Pectra ve Verkle'nin yanı sıra Ethereum protokol geliştiricileri de tarihi bir son kullanma tarihi olan EIP 4444 üzerinde çalışıyor. Bu kod değişikliğinin nedeni , EIP 4444 plan ve özet belgesinde de belirtildiği gibi "blok geçmişinin düğümde çok fazla yer kaplaması ve blok tamamlandıktan sonra yalnızca sınırlı fikir birliği olmayan durumlarda ihtiyaç duyulması"dır. Kritik kullanım durumları." Belge şöyle devam ediyor : "Blok geçmişi artık tam düğümler tarafından kalıcı olarak saklanmayacak. Bir süre sonra düğümden kaldırılacak ve buna ihtiyaç duyan varlıkların onu sorgulaması gerekecek. Portal Ağı, düğümler tarafından Ethereum'un geçmiş verilerini sorgulamak için kullanılan alternatif, merkezi olmayan bir Ağdır.

Merriam, ekibinin EL hesap ekiplerine Portal Ağı ile entegrasyon desteği sağlama konusundaki istekliliğini yineledi. Herhangi bir destek olmazsa entegrasyonun gelişmesinin yaklaşık altı ay süreceğini söyledi. Ancak rehberlik ve yakın işbirliğiyle önümüzdeki iki ay içinde EIP 4444 konusunda anlamlı ilerleme kaydedilebileceği konusunda iyimser. Jayanthi, Portal Ağı spesifikasyonunun güvenlik denetiminin yapılıp yapılmadığını sordu. Merriam hayır dedi. Ethereum Vakfı araştırmacısı Ansgar Dietrichs, müşteri ekiplerinin, mevcut müşterilerle entegrasyonları gruplandırmak, yeni müşteriler oluşturmak veya herhangi bir entegrasyon yapmamak da dahil olmak üzere ağ ile nasıl arayüz oluşturacaklarına kendilerinin karar verip veremeyeceğini sordu. Merriam, bu kararın müşteri ekibinin takdirinde olduğunu doğrular.

Merriam, görüşme sırasında EL hesap ekibine EIP 4444 ile ilgili ilerlemeleri ve niyetleri hakkında sorular sordu. Nethermind geliştiricisi Łukasz Rozmej şunları söyledi: "Genel olarak bu bir öncelik. Hatta dün Portal ekibiyle bir toplantı yaptık. Sorun şu ki, çok fazla öncelik var. Bazen her şeyi doğru şekilde dengelemek zor oluyor. Bu nedenle, bu daha az acil bir öncelik. Diyelim ki bir hard fork, ancak Nethermind bunun üzerinde çalışacak ve biz buna öncelik vereceğiz." Besu geliştiricisi Matt Nelson da aynı şekilde hissettiğini söyledi. Geth geliştiricisi Guillaume Ballet, ekibinin Portal Ağ entegrasyonunu tartışmadığını söyledi.

ACD süreç iyileştirmesi

ACD Süreç İyileştirmeleri Daha sonra Beiko, Ethereum ağ yükseltme sürecini iyileştirmek için birkaç öneri paylaştı. İlk olarak, hesap ekibinin henüz ayrıntılı olarak incelemediği konulara ilişkin ACD çağrılarıyla ilgili tartışma sıklığının azaltılmasını önerdi. Beiko, geliştiricilerin profesyonel tartışmalara katılmasına izin vermeden önce bu konuların ACD çağrısında incelenmek üzere işaretlenmesini ve daha sonra gerektiğinde sonraki ACD çağrılarında bunların daha ayrıntılı olarak tartışılmasını öneriyor.

Beiko'nun yaptığı ikinci öneri, genellikle hard fork'a dahil edilmesi düşünülen Ethereum İyileştirme Tekliflerine (EIP'ler) eklenen "Dahil Edilme Değeri" (CFI) durumunu içeriyor. Bu durum, tarihsel olarak hangi EIP'lerin hard fork'a dahil edilme olasılığının daha yüksek olduğunu gösteren yararlı bir gösterge olmamıştır. Beiko, geliştiricilerin hangi EIP'lerin hard fork'a dahil edilme olasılığının daha yüksek olduğunu ve hangilerinin olmadığını daha iyi ayırt edebilmesi için "Eklenmeyi Bekliyor" (PFI) adında başka bir etiket oluşturmayı önerdi.

Ethereum Vakfı araştırmacısı Ansgar Dietrichs, Zoom sohbetinde EIP için yeni bir etiket oluşturmanın "yanlış yön" olduğunu ve yalnızca CFI etiketinin "tamamen işe yaramaz" hale gelmesine yol açacağını yazdı. Beiko, geliştiricilerin GitHub ve EthMagicians'ta ağ yükseltme sürecini iyileştirmeyi tartışmaya devam edebileceklerini söyledi.

Ayrıca Ethereum Vakfı'nda DevOps mühendisi olan Mario Vega, testle ilgili güncellemeler için yeni bir Discord alt kanalı oluşturmayı umduğunu söyledi. Vega, şu anda Ethereum Ar-Ge Discord'unda test sürümü bilgilerinin birden fazla kanala dağıldığını söyledi. Ancak yeni forumun, müşteri ekiplerinin Ethereum Vakfı'nın DevOps ekibinden test güncellemelerini alması için "tek noktadan" bir referans haline gelmesini umuyor. Hesap ekibinden bu konuda geri bildirim sağlamasını istedi.

Beiko son olarak geliştiricilere önümüzdeki birkaç gün için biri 7 Haziran'da ePBS'de, diğeri 11 Haziran'da PeerDAS'ta olmak üzere iki grup toplantısı planlandığını hatırlattı.