Bir başka @ethereum #AllCoreDevs toplantısı 15 Eylül'de sona erdi: geliştirme ağındaki güncellemeler, Dencun'a eklemeler ve Reth'e kapsamlı bir genel bakış tartışıldı!
Gündem: Canlı bağlantı:
Aşağıda @TimBeiko tarafından yapılan toplantının bir özeti bulunmaktadır.
1. Devnet-8 durum güncellemesi
İlk olarak, devnet-8'e ilişkin bir durum güncellemesi: Ağ son geliştirme sürecinden geçiyor ve birçok müşteri halihazırda ağa yeni güncellemeler gönderdi. Bu arada MEV/block build sürecini @KurtosisTech kullanarak test etmeye başladık. @NethermindEth, blob işlem havuzlarının artık hazır olduğunu ve tek bir düğüm üzerinde birkaç gün süren testlerin ardından bunu tüm Dencun test düğümlerine dağıttıklarını belirtti.
Geth'in blob işlem havuzu da neredeyse tamamlandı. Besu, bir sonraki sürümde piyasaya sürülmesi beklenen işlem havuzunda (blob ve blob olmayan işlemlerin toplam boyutunu sınırlayan) kapsamlı iyileştirmeler yapıyor. Erigon işlem havuzunu geliştirmeye devam ediyor ve devnet-9'a hazır olmayı umuyor. Prysm ayrıca blob sepetlerinin alınmasında bir miktar gecikme olduğunu da belirtiyor ve bunların genellikle bloktan sonra yaklaşık 500 milisaniyelik bir gecikmeyle geldiğini söylüyorlar (bloğun işlenmesi yaklaşık 15 milisaniye sürüyor).
Blob ve öbek ithalatı arasındaki yarış durumundan kaynaklanıp kaynaklanmadığını belirlemek için bu sorunu araştırıyorlar. Ekip, hard fork öncesi bellek havuzunda blob işlemlerinin desteklenmesine izin verilip verilmeyeceği sorusuyla ilgili olarak oybirliğiyle bunu yapmamayı kabul etti.
2, EIP-7514
Daha sonra, doğrulayıcı aktivasyon kuyruğuna sabit bir üst sınır eklenip eklenmeyeceğine ilişkin geçen haftaki ACDC çağrısındaki tartışmaya devam ettik. Bu teklif resmi olarak EIP-7514 olarak oluşturulmuştur. Kısacası bu, en kötü senaryoda ETH stake etme yüzdesindeki büyümeyi yavaşlatacaktır. Dankrad, çağrı sırasında teklife desteğini ifade ederek, bunun doğrulayıcı ödüllerinde potansiyel olarak daha karmaşık değişiklikler yapmak için bize zaman kazandıracağını söyledi.
Tüm CL takımları bu değişiklikten yana; bunun yalnızca para yatırma kuyruğu için geçerli olduğu ve para çekme kuyruğu için geçerli olmadığı uyarısında bulunuyor. Biraz daha tartıştıktan sonra sınırı 8 olarak belirlemeye karar verdik. Bu nedenle EIP-7514, Dencun yükseltmesinin bir parçası olacak! Önümüzdeki birkaç gün içinde EIP ve ilgili CL spesifikasyonu PR'nin bu değişikliği yansıtacak şekilde güncellenmesi bekleniyor.
3. EVM ve Blob
Daha sonra başka bir geçici öneriyi tartıştık: Blob taban ücretlerini açığa çıkarmak için Ethereum Sanal Makinesine (EVM) bir işlem kodu eklemek. Bu teklif, Arbitrum'dan @PlasmaPower0 tarafından ileri sürüldü ve bu haftanın başlarında Ar-Ge Discord'unda bunun kendileri (ve diğer Katman 2 çözümleri) için yararlı olacağını söyledi. EIP'nin etkinleştirilmesiyle aynı anda tanıtılan EIP-1559'da BASEFEE'yi ortaya çıkaran benzer bir işlem kodumuz zaten var. Bu, Katman 2 çözümlerinin kullanıcılardan L1 veri maliyetlerine göre ücretlendirmek için doğru gaz fiyatını belirlemesini kolaylaştırır.
Optimism'den @protolambda da toplantıya katıldı ve L2 için blob tabanı ücretini almanın tek yolunun bu olmadığını, çünkü blok başlığına (blob tabanı ücretini hesaplamak için kullanılan değerleri içeren) bakabileceklerini ve Merkle'nin bu değerleri ispat etmesini sağlayın. Yine de bunun güzel bir özellik olduğu konusunda hemfikir. Arbitrum şu anda blok başlığı ayrıştırma işlemini gerçekleştirmiyor ve buna güvenmek, değişmez Katman 2 çözümleri için sorunlu olabilir; çünkü blok başlığı formatı değişirse bu soruna neden olabilir.
EIP-4844 yazarlarından biri @adietrichs, bu işlem kodunun orijinal spesifikasyona dahil edilmediğini, çünkü blok başlık bilgisine erişim için (tek seferlik bir işlem kodu eklemek yerine) daha genel bir yol geliştirme isteğinin bulunduğunu belirtti. Yine de bu daha iddialı değişikliği benimsemek, bu işlem kodunu uygulamaya koymaktan daha iddialı bir görev olacaktır.
Bu işlem kodunun açığa çıkardığı bilgiler zaten EL istemcisinin hesaplaması gereken bilgilerdir ve anlamsal olarak BASEFEE işlem koduyla neredeyse aynıdır. Müşteri ekibi, BASEFEE ile tutarlı olması açısından bu işlem kodunu eklememiz gerektiğine oy birliğiyle karar verdi. Gelecekte "daha ince" bir mekanizma geliştirirsek, bu yeni işlem kodundaki herhangi bir gereksiz işlevsellik, blok başlığı bilgilerini kullanan diğer işlem kodları için de sorun haline gelecektir. Ayrıca bunun çok küçük bir değişiklik olduğunu vurgulamakta fayda var: @vdWijden bunu EIP ortaya çıkmadan önce Geth'de uyguladı, sadece 20 dakika sürdü ve Reth ekibi ACD çağrısı PR sırasında bu konuda bir değişiklik yaptı.
4, EIP-4788
Daha sonra, işaret köklerini Ethereum ana zincirindeki sözleşmelerde saklama önerisi olan EIP-4788'e yönelik bazı güncellemeleri tartıştık. Geçtiğimiz birkaç hafta boyunca sözleşme üzerinde çok sayıda denetim ve bulanıklık testi gerçekleştirdik ve bunun sonucunda bu PR'de açıklanan bazı küçük değişiklikler yapıldı. Tüm denetimler tamamlanmamasına ve raporlar henüz yayınlanmamasına rağmen @lightclients şu ana kadar düşünülen değişikliklere ilişkin bir genel bakış sundu. İlk değişiklik, 0 zaman damgasını açıkça ele almaktır, böylece 0 döndürmek yerine geri alma işlemine (tıpkı diğer geçersiz zaman damgaları gibi) neden olurlar. İkinci değişiklik arabellek boyutuyla ilgilidir. Aralık süresinin değiştiğini varsayarsak, orijinal sözleşme, modüler aritmetiğin çalışma şekli nedeniyle depolamanın boşa harcanmasına neden olacaktır.
5. Gaz optimizasyonu
Son olarak CALLDATA'nın yüklenme sayısını azaltan bir gaz optimizasyonu var. Denetçiler bu değişiklikleri gözden geçirecek ve nihai raporlarını bir sonraki ACDE toplantısından önce almayı bekliyoruz. Fuzz testi ve uygulama çalışmasının ilerlemesini sağlamak için önerilen değişiklikleri şimdi birleştirmeye karar verdik.
@shemnon ayrıca bu değişikliklerin gerçek EIP'de belgelenmesi gerektiğini de belirtti - bunun üzerinde çalışıyoruz! Daha sonra, sistem sözleşmesi adresi durumun bir parçasıysa ancak yürütmenin sonunda boşsa müşterilerin bunu nasıl ele alması gerektiğini tartıştık. Bunun aslında ana ağda gerçekleşmesi pek olası olmasa da (anladığım kadarıyla!), bu, genetik bloktaki adresin ayarlanmasıyla yapılan testlerde meydana gelen uç bir durumdur.
Bunun oldukça özel bir durum olduğu ve net bir kanonik davranış olmadığı göz önüne alındığında, bu konu hakkında düşünmeye daha fazla zaman ayırmaya ve önümüzdeki hafta yapılacak test toplantısında tartışmaya devam etmeye karar verdik. Teknik özelliklerdeki değişiklikler bu kadar! Yukarıdakilerin hepsinin devnet-9'a dahil edilmesi planlanmaktadır. Müşteri ekibi her şeyin gelecek haftaki ACDC'den önce uygulanması ve test edilmesi gerektiği konusunda hemfikir. Bu görüşme üzerine devnet-9'un lansman tarihi üzerinde anlaşacağız.
Bir sonraki ACDE'nin 28 Eylül 14:00 UTC saatinde yapılması planlanıyor. O zamana kadar test toplantısı özetleri için @terencechain'i, ACDC toplantı bilgileri için @benjaminion_xyz'i ve tüm etkinliğin daha ayrıntılı kapsamı için @christine_dkim'i takip edin.
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.
EIP-7514, Ethereum Dencun yükseltmesinin bir parçası olacak
Yazar: @TimBeiko Çeviri: Huohuo/Yerel Blockchain
Bir başka @ethereum #AllCoreDevs toplantısı 15 Eylül'de sona erdi: geliştirme ağındaki güncellemeler, Dencun'a eklemeler ve Reth'e kapsamlı bir genel bakış tartışıldı!
Gündem: Canlı bağlantı:
Aşağıda @TimBeiko tarafından yapılan toplantının bir özeti bulunmaktadır.
1. Devnet-8 durum güncellemesi
İlk olarak, devnet-8'e ilişkin bir durum güncellemesi: Ağ son geliştirme sürecinden geçiyor ve birçok müşteri halihazırda ağa yeni güncellemeler gönderdi. Bu arada MEV/block build sürecini @KurtosisTech kullanarak test etmeye başladık. @NethermindEth, blob işlem havuzlarının artık hazır olduğunu ve tek bir düğüm üzerinde birkaç gün süren testlerin ardından bunu tüm Dencun test düğümlerine dağıttıklarını belirtti.
Geth'in blob işlem havuzu da neredeyse tamamlandı. Besu, bir sonraki sürümde piyasaya sürülmesi beklenen işlem havuzunda (blob ve blob olmayan işlemlerin toplam boyutunu sınırlayan) kapsamlı iyileştirmeler yapıyor. Erigon işlem havuzunu geliştirmeye devam ediyor ve devnet-9'a hazır olmayı umuyor. Prysm ayrıca blob sepetlerinin alınmasında bir miktar gecikme olduğunu da belirtiyor ve bunların genellikle bloktan sonra yaklaşık 500 milisaniyelik bir gecikmeyle geldiğini söylüyorlar (bloğun işlenmesi yaklaşık 15 milisaniye sürüyor).
Blob ve öbek ithalatı arasındaki yarış durumundan kaynaklanıp kaynaklanmadığını belirlemek için bu sorunu araştırıyorlar. Ekip, hard fork öncesi bellek havuzunda blob işlemlerinin desteklenmesine izin verilip verilmeyeceği sorusuyla ilgili olarak oybirliğiyle bunu yapmamayı kabul etti.
2, EIP-7514
Daha sonra, doğrulayıcı aktivasyon kuyruğuna sabit bir üst sınır eklenip eklenmeyeceğine ilişkin geçen haftaki ACDC çağrısındaki tartışmaya devam ettik. Bu teklif resmi olarak EIP-7514 olarak oluşturulmuştur. Kısacası bu, en kötü senaryoda ETH stake etme yüzdesindeki büyümeyi yavaşlatacaktır. Dankrad, çağrı sırasında teklife desteğini ifade ederek, bunun doğrulayıcı ödüllerinde potansiyel olarak daha karmaşık değişiklikler yapmak için bize zaman kazandıracağını söyledi.
Tüm CL takımları bu değişiklikten yana; bunun yalnızca para yatırma kuyruğu için geçerli olduğu ve para çekme kuyruğu için geçerli olmadığı uyarısında bulunuyor. Biraz daha tartıştıktan sonra sınırı 8 olarak belirlemeye karar verdik. Bu nedenle EIP-7514, Dencun yükseltmesinin bir parçası olacak! Önümüzdeki birkaç gün içinde EIP ve ilgili CL spesifikasyonu PR'nin bu değişikliği yansıtacak şekilde güncellenmesi bekleniyor.
3. EVM ve Blob
Daha sonra başka bir geçici öneriyi tartıştık: Blob taban ücretlerini açığa çıkarmak için Ethereum Sanal Makinesine (EVM) bir işlem kodu eklemek. Bu teklif, Arbitrum'dan @PlasmaPower0 tarafından ileri sürüldü ve bu haftanın başlarında Ar-Ge Discord'unda bunun kendileri (ve diğer Katman 2 çözümleri) için yararlı olacağını söyledi. EIP'nin etkinleştirilmesiyle aynı anda tanıtılan EIP-1559'da BASEFEE'yi ortaya çıkaran benzer bir işlem kodumuz zaten var. Bu, Katman 2 çözümlerinin kullanıcılardan L1 veri maliyetlerine göre ücretlendirmek için doğru gaz fiyatını belirlemesini kolaylaştırır.
Optimism'den @protolambda da toplantıya katıldı ve L2 için blob tabanı ücretini almanın tek yolunun bu olmadığını, çünkü blok başlığına (blob tabanı ücretini hesaplamak için kullanılan değerleri içeren) bakabileceklerini ve Merkle'nin bu değerleri ispat etmesini sağlayın. Yine de bunun güzel bir özellik olduğu konusunda hemfikir. Arbitrum şu anda blok başlığı ayrıştırma işlemini gerçekleştirmiyor ve buna güvenmek, değişmez Katman 2 çözümleri için sorunlu olabilir; çünkü blok başlığı formatı değişirse bu soruna neden olabilir.
EIP-4844 yazarlarından biri @adietrichs, bu işlem kodunun orijinal spesifikasyona dahil edilmediğini, çünkü blok başlık bilgisine erişim için (tek seferlik bir işlem kodu eklemek yerine) daha genel bir yol geliştirme isteğinin bulunduğunu belirtti. Yine de bu daha iddialı değişikliği benimsemek, bu işlem kodunu uygulamaya koymaktan daha iddialı bir görev olacaktır.
Bu işlem kodunun açığa çıkardığı bilgiler zaten EL istemcisinin hesaplaması gereken bilgilerdir ve anlamsal olarak BASEFEE işlem koduyla neredeyse aynıdır. Müşteri ekibi, BASEFEE ile tutarlı olması açısından bu işlem kodunu eklememiz gerektiğine oy birliğiyle karar verdi. Gelecekte "daha ince" bir mekanizma geliştirirsek, bu yeni işlem kodundaki herhangi bir gereksiz işlevsellik, blok başlığı bilgilerini kullanan diğer işlem kodları için de sorun haline gelecektir. Ayrıca bunun çok küçük bir değişiklik olduğunu vurgulamakta fayda var: @vdWijden bunu EIP ortaya çıkmadan önce Geth'de uyguladı, sadece 20 dakika sürdü ve Reth ekibi ACD çağrısı PR sırasında bu konuda bir değişiklik yaptı.
4, EIP-4788
Daha sonra, işaret köklerini Ethereum ana zincirindeki sözleşmelerde saklama önerisi olan EIP-4788'e yönelik bazı güncellemeleri tartıştık. Geçtiğimiz birkaç hafta boyunca sözleşme üzerinde çok sayıda denetim ve bulanıklık testi gerçekleştirdik ve bunun sonucunda bu PR'de açıklanan bazı küçük değişiklikler yapıldı. Tüm denetimler tamamlanmamasına ve raporlar henüz yayınlanmamasına rağmen @lightclients şu ana kadar düşünülen değişikliklere ilişkin bir genel bakış sundu. İlk değişiklik, 0 zaman damgasını açıkça ele almaktır, böylece 0 döndürmek yerine geri alma işlemine (tıpkı diğer geçersiz zaman damgaları gibi) neden olurlar. İkinci değişiklik arabellek boyutuyla ilgilidir. Aralık süresinin değiştiğini varsayarsak, orijinal sözleşme, modüler aritmetiğin çalışma şekli nedeniyle depolamanın boşa harcanmasına neden olacaktır.
5. Gaz optimizasyonu
Son olarak CALLDATA'nın yüklenme sayısını azaltan bir gaz optimizasyonu var. Denetçiler bu değişiklikleri gözden geçirecek ve nihai raporlarını bir sonraki ACDE toplantısından önce almayı bekliyoruz. Fuzz testi ve uygulama çalışmasının ilerlemesini sağlamak için önerilen değişiklikleri şimdi birleştirmeye karar verdik.
@shemnon ayrıca bu değişikliklerin gerçek EIP'de belgelenmesi gerektiğini de belirtti - bunun üzerinde çalışıyoruz! Daha sonra, sistem sözleşmesi adresi durumun bir parçasıysa ancak yürütmenin sonunda boşsa müşterilerin bunu nasıl ele alması gerektiğini tartıştık. Bunun aslında ana ağda gerçekleşmesi pek olası olmasa da (anladığım kadarıyla!), bu, genetik bloktaki adresin ayarlanmasıyla yapılan testlerde meydana gelen uç bir durumdur.
Bunun oldukça özel bir durum olduğu ve net bir kanonik davranış olmadığı göz önüne alındığında, bu konu hakkında düşünmeye daha fazla zaman ayırmaya ve önümüzdeki hafta yapılacak test toplantısında tartışmaya devam etmeye karar verdik. Teknik özelliklerdeki değişiklikler bu kadar! Yukarıdakilerin hepsinin devnet-9'a dahil edilmesi planlanmaktadır. Müşteri ekibi her şeyin gelecek haftaki ACDC'den önce uygulanması ve test edilmesi gerektiği konusunda hemfikir. Bu görüşme üzerine devnet-9'un lansman tarihi üzerinde anlaşacağız.
Bir sonraki ACDE'nin 28 Eylül 14:00 UTC saatinde yapılması planlanıyor. O zamana kadar test toplantısı özetleri için @terencechain'i, ACDC toplantı bilgileri için @benjaminion_xyz'i ve tüm etkinliğin daha ayrıntılı kapsamı için @christine_dkim'i takip edin.