Ethereum Yükseltmelerinin İç Yüzü: Hegotá

Ethlabs'ın Hegotá için önceliklendirdiği şeyler ve nedenleri.

Ethereum'un yönü, onun üzerine inşa edenler, onu kullananlar, ETH tutanlar veya sadece olabileceği şeye inanan herkes için önemlidir. Bu gelecek nihayetinde her gün Ethereum üzerinde inşa eden insanlar, uygulamalar ve topluluklar tarafından belirlenecek olsa da, ağ yükseltmeleri protokolün onların ihtiyaçlarını karşılamak için gelişmesinin birincil yollarından biridir. Hegotá, Glamsterdam'dan sonra planlanan bir sonraki Ethereum ağ yükseltmesidir ve bu belge, Ethlabs'ın Ethereum'un Hegotá için neye öncelik vermesi gerektiğine dair görüşünü ve nedenini paylaşmaktadır.

Ethlabs, Ethereum ve ETH için 8 haftalık, kâr amacı gütmeyen bir Ar-Ge laboratuvarıdır ve misyonumuz Ethereum'u küresel ekonominin mutabakat katmanı haline getirmektir. Gerçek dünyadaki Ethereum kullanımı ile protokol geliştirme arasında yer alıyoruz ve zamanımızı kullanıcıları, cüzdanları, uygulamaları, rollup'ları, kurumları, ETH sahiplerini, araştırmacıları ve istemci ekiplerini dinleyerek geçiriyoruz. Bazen zincir üzerinde bile inşa ediyoruz, çünkü bir arenaya katılmadan onu inşa edemezsiniz! Harika protokol mühendisliğinin harika ürünleri mümkün kılması gerektiğine ve harika ürünlerin de protokolün bir sonraki adımda nereye gideceğini belirlemeye yardımcı olması gerektiğine inanıyoruz.

Hegotá'nın kapsamı şu anda Ethereum'un açık teknik süreci aracılığıyla şekillendirilmenin erken aşamalarındadır ve aşağıdaki öneriler birçok birey ile araştırma ve istemci ekibinin çalışmalarını yansıtmaktadır. Bu belge, önceliklendirilmesini önerdiğimiz şeylerin ve görüşlerimizin hâlâ şekillenmekte olduğu konuların şeffaf bir hesabıdır. Bunlar, başkalarının değerlendirmesini, sorgulamasını ve iyileştirilmesine yardımcı olmasını çok isteyeceğimiz pozisyonlardır ve önümüzdeki günler ve haftalarda tartışıp daha fazla şey öğrendikçe onları güncelleyeceğiz.

Hegotá yükseltmesi için, önerilen tüm EIP'ler göz önüne alındığında, Ethereum için en yüksek öncelik olarak gördüğümüz alanlar şunlardır:

1. Daha güçlü sansür direnci: Kim olduklarına veya Ethereum'u ne için kullandıklarına bakılmaksızın herkes bir işlemin dahil edilmesini sağlayabilmelidir.
2. Daha hızlı Ethereum: Daha hızlı bloklar, daha hızlı onaylamalar, daha taze zincir içi fiyatlar ve daha hızlı kesinlik anlamına gelir.
3. Yerel hesap soyutlaması: Hesaplar; geçiş anahtarlarını, sponsorlu işlemleri, token cinsinden ödenen gazı, toplu işlemeyi ve daha güçlü gizliliği, kuantum sonrası anahtarlara giden bir yolla birlikte desteklemelidir.
4. Devam eden L1 ölçeklendirmesi: Uygulamalar, talep arttığında bile uygun fiyatlı ve öngörülebilir kalan kapasiteye ihtiyaç duyar.

Açık bir şekilde çalışmak Ethlabs için temel bir hedeftir, bu yüzden haftalık güncellemeler yazıyor ve bu gibi durumlarda düşüncelerimizi paylaşmak için çok uzun teknik yazılar yayınlıyoruz 😅. Ayrıca önümüzdeki haftalarda sadece öne çıkanları isteyenler için daha küçük parçalar halinde içerikler yayınlayacağız. Bundan sonrası uzun ve teknik olacak. Hepsini okuyanlara kolay gelsin!

İlk önce ilk şeyler: EIP süreci nasıl işliyor?

Tekliflerin kendilerine dalmadan önce önemli bir nokta: Hegotá'nın kapsam belirleme sürecinin ikinci aşaması daha yeni başladı. İlk aşama, FOCIL'i Hegotá'nın başlık maddesi olarak seçti. 6 Ağustos'ta başlık maddesi olmayan EIP'leri önermek için bir son tarih vardı ve ACD süreci şimdi Hegotá yükseltmesini bir bütün olarak değerlendirmeye geçecek.

Aşağıdaki tüm EIP'ler şu anda, başlık maddesi sürecinden geçen EIP'ler hariç, PFI (Dahil Edilmek Üzere Önerildi) aşamasındadır. Bir EIP'yi dahil edilmek üzere önermek izne tabi değildir ve çoğu asla nihai yükseltmeye dahil edilmez.

Spesifik olarak, uygulama çalışmaları ilerledikçe, teklifler aşamalı olarak daha güçlü inceleme ve nihayetinde yayınlanma güveni aşamalarından geçer:

• PFI (Dahil Edilmek Üzere Önerildi): Yükseltme için bir fikir önerilmiştir. Bu aşama izne tabi değildir ve istemci desteği veya nihai olarak dahil edileceği anlamına gelmez.
• CFI (Dahil Edilmesi Değerlendiriliyor): İstemci ekipleri teklifi incelemiş ve prototipini oluşturup test etmeyi planlamaktadır.
• SFI (Dahil Edilmesi Planlandı): Uygulama ve testlerin iyi gitmeye devam etmesi koşuluyla, dahil edilmesi yönünde geniş bir niyet vardır.

Bu sürecin nasıl işlediği hakkında daha fazla bilgi edinmek için Tim Beiko'nun hızlı özetini buradan izlemenizi öneririz.

Düzen: bu makalede nasıl gezinilir

Hegotá için EIP önceliklendirmesine ilişkin görüşümüzü ifade etmek için Forkcast'ın kademe listesini takip ediyoruz. Kararı en aza indirmek için, incelenen tüm EIP'leri aşağıdaki yorumlarla dört kademeye ayırıyoruz:

• [S-kademesi] dahil edilmesini şiddetle tavsiye ederiz.
• [A-kademesi] uygulama karmaşıklığı, etki analizi veya benimsenme gibi kalan engellerin çözülmesi halinde dahil edilmesini tavsiye ederiz.
• [B-kademesi] değerli, ancak bu yükseltme için zorlama.
• [D-kademesi] mevcut haliyle Hegotá'ya dahil edilmesini önermiyoruz.
• [görüş oluşturuyoruz] Bu EIP hakkında hâlâ görüş oluşturuyoruz.

Lütfen bunların Ethlabs'ın \tavsiyeleri\ olduğunu unutmayın. Her teklifi esas olarak amaç, teknik şartname ve makul uygulama karmaşıklığı anlayışımız açısından değerlendiriyoruz (Frames ve Quick Slots gibi daha fazla kesinliğe veya doğrudan katılıma sahip olduğumuz durumlar hariç) ve süreçte ilerledikçe ethPandaOps, test ekipleri ve istemcilerden gelen değerlendirmelere dayanarak görüşümüzü güncelleyeceğiz.

[CL], bir EIP'nin mutabakat katmanı istemcilerini etkilediği ve [EL] ise yürütme katmanı istemcilerini etkilediği anlamına gelir.

Birkaç EIP'nin (FOCIL, Frame Transactions ve Quick Slots dahil) ortak yazarları olduğumuzu ve bunlara dahil olduğumuzu unutmayın. Tüm EIP'leri katılımımızdan bağımsız olarak değerlendirmeye çalışsak da, pozisyonumuzu değerlendirirken lütfen bunu dikkate alın.

Özet

CL sıralaması

Bu belirli [CL] sıralaması üzerinde Forkcaster'da buradan değişiklik yapabilirsiniz.

EL sıralaması

Bu belirli [EL] sıralaması üzerinde Forkcaster'da buradan değişiklik yapabilirsiniz.

Daha fazla uzatmadan, işte Hegota yükseltmesi hakkında bugün itibarıyla bir bütün olarak görüşlerimiz:

Hegotá için Temalar

0. FOCIL: sansür direncini güçlendirin

EIP-7805: FOCIL zaten SFI olarak işaretlenmiş ve Hegotá'nın başlık maddesi olarak onaylanmıştır. Ethlabs ekibinin üç üyesi (Francesco, Barnabé ve Julian) ortak yazarları arasındadır ve dahil edilmesini güçlü bir şekilde destekliyoruz. Karar zaten kesinleştiği için bunu kısa tutuyoruz. Yalnızca herkese karşı tarafsız olan bir zincir, herkes için güvenin kökü haline gelebilir. Ethereum'un küresel ekonominin ve içindeki her bir bireyin gerçek mutabakat katmanı haline gelmesini sağlayan şey budur.

1. Quick Slots: Daha Hızlı Ethereum

Ethereum'un 12 saniyelik slotu, kullanıcı değerini düşüren bir gecikme maliyetidir. Bu nedenle, [CL] EIP-8198: Quick Slots'un [S-kademesi] Hegotá'ya dahil edilmesini dört nedenden dolayı şiddetle tavsiye ediyoruz:

1. Daha hızlı işlem onayı ile L1'de iyileştirilmiş kullanıcı deneyimi.
2. L1'deki zincir içi piyasalar daha taze fiyatlarla çalışır, spread'leri ve LP ekonomisini iyileştirir.
3. Kesinlik ve hızlı onay kuralı slot süresini devralır, bu nedenle daha hızlı bloklarla her ikisi de hızlanır ve Ethereum ile birlikte çalışabilirliği artırır.
4. Saniye başına daha fazla blok teklifçisi, ekonomik sansür direnci de dahil olmak üzere artan sansür direnci anlamına gelir: blokları belirli bir süre boş tutmak için ödemeniz gereken miktar.

Ethereum'un benzersiz merkeziyetsizliğini korurken daha hızlı hale gelmesi, Ethereum blok alanını daha değerli kılar ve bu değer ağa ve ETH'ye aktarılır. Her düşüş, kullanıcılarımıza anında iletilen daha fazla değerdir. Son olarak, daha hızlı bloklar, uygulama geliştiricilerinden en çok talep edilen değişikliklerden biridir.

Şimdi başlamanın gerekçesi, slot süresi azaltımının asla tek seferlik bir değişiklik olmayacağıdır. Ölçeklendirmede olduğu gibi, gerçekleştirilen azaltımlar uygulamalara yol haritası taahhütlerinden daha fazla kesinlik sağlar. 6 saniyenin altındaki slotlara giden yol, slot süresini değiştirilebilir hale getirmekle başlar, ardından yinelemeli olarak değiştirir. EIP-8198 işi ikiye böler:

• Slot süresini teknik şartnamelerde ve istemci kodunda güncellemeyi kolaylaştıran tek seferlik bir yeniden düzenleme.
• Yol haritası ilerledikçe ve güvenliğe dair ampirik kanıtlar elde edildikçe, Hegotá'da bir ilk azaltım, ardından sonraki fork'larda daha fazla azaltım.

Hegotá, tek seferlik maliyeti ödemek için doğru fork'tur. Glamsterdam'daki ePBS zaten slotu yeniden yapılandırıyor. Hegotá daha sonra mutabakat katmanı için nispeten hafif bir fork'tur; bu pencere, I*'daki ayrıştırılmış mutabakat ile kapanır, bu nedenle tek seferlik yeniden düzenleme için CL bant genişliği şu anda mevcuttur ve birkaç fork boyunca tekrar mevcut olmayacaktır.

Anlamı: Ya önümüzdeki en az iki yıl boyunca 12 saniyede kalmayı taahhüt ederiz ya da yaklaşık bir yıl içinde Hegotá'da 10 saniyeye ve muhtemelen bir sonraki yıl 10 saniyenin altına ineriz. Bu iki azaltım teorik iyileştirmeler değildir. Doğrudan artan kullanıcı değeri ve iyileştirilmiş ağ ekonomisi elde ederler. Başlamanın zamanı geldiğini düşünüyoruz.

En yaygın itirazlar

Burada, istemci geliştiricileri ve EF Protokolü ile yapılan ön görüşmeler sırasında gündeme getirilen 4 önemli noktayı tartışıyoruz:

1. Uygulama karmaşıklığı: Milisaniye hassasiyetinde slot zamanlaması, ePBS çalışmaları aracılığıyla mutabakat teknik şartnamelerine zaten birleştirilmiştir ve EIP-8198 için taslak CL ve EL teknik şartnameleri mevcuttur; temel ücret, gaz limiti ve blob programı, saniye başına davranışı korumak için yeniden ölçeklendirilmiştir. Geriye kalan maliyet, sabit bir slot süresi varsayan istemcilerdeki ve araçlardaki uç durumların bir kuyruğu artı testlerdir. Tek seferlik yeniden düzenleme tam olarak bu işi öne çıkarır. Sonrasında her azaltım bir parametre değişikliğidir.

2. zkEVM kanıtlama: İki ana konu, göreceli kanıtlama süresi ve sabit kanıtlama genel gideridir.

2.1 Göreceli kanıtlama süresi, slot süresinin kanıtlamaya ayrılan payını ve slot süresi değiştiğinde bu payın nasıl değiştiğini ölçer. İşte slottaki ilgili anların kısa bir açıklaması. Mevcut oluşturucular önceki yükün yayınlandığını gözlemler ve hemen oluşturmaya başlayabilir. Mevcut işaret bloğu daha sonra mevcut slotun yükünü taahhüt eder. Bu yük, bir sonraki işaret teklifçisinin blok yayınından önce kanıtlanmalıdır.

Kanıtlama için minimum göreceli süre, bir tam slot eksi bir işaret bloğu yayınının gecikmesidir. İşaret bloğu yayınının gecikmesi sıkıştırılamaz, ancak yapısı gereği kısadır, bu nedenle bu aşamada bizi temelde sınırlamaz. Ayrıca, optimize edilmiş oluşturucuların yük oluşturulurken onu birlikte kanıtlama olasılığı da vardır, bu da işaret bloğu teklifçisi tarafından kazanan yük taahhüt edilmeden önce kanıtlamaya başlamalarına olanak tanır.

2.2 zkEVM kanıtlama, bazı sabit genel giderler dışında çoğunlukla blok boyutuyla doğrusal olarak ölçeklenir. Daha hızlı slotlar, sabit genel giderin daha sık ödendiği anlamına gelir ve bu da aynı miktarda verim için daha fazla gecikme ekler. Sabit bir gecikme bütçesi göz önüne alındığında, yine de iyi bir verimin elde edilebilmesi sağlanmalıdır. Burada iki fırsat görüyoruz: Birincisi, mühendislik ilerlemesi bu sabit işlemlerin gecikmesini düşürmeye devam edecektir. İkincisi, EIP-7862 tarafından açıklandığı gibi durum kökü hesaplamasını geciktirmek, kanıtlamanın daha fazlasını kritik yolun dışına çıkarır; bu, sıkıştırılamaz işlemler için gecikme bütçemizi artırabileceğimiz anlamına gelir. Bu iki fırsatın yakınsaması bize daha hızlı slotların gelecekte bol miktarda verim artışını engellemeyeceğini söylüyor.

3. Kuantum sonrası geçiş: Ayrıştırılmış mutabakat yaklaşımı, gelecekteki mutabakat mimarisiyle ilgili olarak istikrarlı kabul edilecek kadar destek almıştır. Ayrıştırma, kesinlik oylamasını blok üretiminin kritik yolunun dışına taşımak anlamına gelir. Özellikle, PQ imzalarının büyük ölçekli toplaması ve ilgili tüm özyinelemeli STARK mekanizması kritik yolun dışında olacaktır. Blok üretmek ve ortaya çıkan zincirin başını takip etmek için bir fork seçim kuralı elde etmek için geriye kalan, şu anda 512 ve muhtemelen 256 doğrulayıcıdan oluşması beklenen bir alt komitedir. Kuantum sonrası imza boyutları daha büyüktür, ancak önerilen 10 saniyelik slot süresi ve muhtemelen gelecekte daha da kısa süreler içinde yayılmaya uygundur.

4. Akıllı sözleşmeler ve altyapı: Akıllı sözleşmelerdeki ve altyapıdaki slot süresine bağımlılık şu anda araştırılmaktadır. Akıllı sözleşmeler için, tüm doğrulanmış sözleşmeler üzerinde analiz yapmak üzere Sourcify ile ortaklık kurduk. EIP-4788: EVM'de işaret bloğu kökü uyarınca depolanan geçmiş işaret bloğu köklerine bir slot süresi güncellemesinin etkilerini inceliyoruz. Altyapı ile ilgili olarak, anekdot olarak Etherscan, bir slot süresi değişikliğinin muhtemelen daha fazla yüke yol açacağından, ancak altyapının İş Kanıtı'ndaki değişken slot süreleri zamanında inşa edildiğinden, fazla değişiklik gerektirmediğinden bahsetti.

2. Hesap Soyutlaması: kullanıcı deneyimini, güvenliği ve gizliliği iyileştirin

Ethereum ve daha geniş ekosistemi, geçiş anahtarı cüzdanları, sponsorlu işlemler, ERC20 gaz ödemeleri, işlem toplu işleme ve daha fazlası gibi kullanıcı deneyimi avantajları getirecek olan yerel AA için uzun süredir gecikmiştir.

Ancak, yerel AA'ya giden yol özellikle inişli çıkışlı olmuştur çünkü AA, istemciler, L2'ler, cüzdanlar, RPC'ler, geliştirici araçları vb. dahil olmak üzere Ethereum yığınının her parçasına dokunur, bu nedenle çok çeşitli paydaşlardan destek almayı gerektirir. Bu, herhangi bir AA EIP'sinin Ethereum'un mutabakat odaklı geliştirme sürecinden geçmesini ve ayrıca EIP yayınlandıktan sonra pratik benimsenmeyi başarmasını zorlaştırır.

Bu nedenle Hegotá'nın yerel AA teklifi olan Frame Transactions'ı A-kademesine koyuyoruz, teknik olarak S için yeterince iyi olmadığı için değil, çözmek için muazzam miktarda koordinasyon gerektirecek pratik benimsenme risklerini hesaba katmak istediğimiz için. Ekibimizin AA geçmişi göz önüne alındığında, Ethlabs, yerel AA için başarılı bir kullanıma sunma sağlamak üzere L2'ler ve cüzdanlar gibi paydaşlarla çalışarak Frame Transactions'ı piyasaya sürmede önemli bir rol oynamayı planlamaktadır.

Şimdi Hegotá için belirli AA tekliflerine geçelim.

[EL] EIP-8141: Frame Transactions [A-kademesi]

EIP-8141: Frame Transactions'ın Ethereum'un yerel AA sistemi için en iyi aday olduğuna inanıyoruz. Diğer yerel AA teklifleriyle karşılaştırıldığında, Frames, onu Ethereum'un CROPS yetkisiyle benzersiz bir şekilde uyumlu kılan bir dizi arzu edilen özelliğe sahiptir:

• İzne tabi olmayan hesap inovasyonu: doğrulama mantığı EVM kodu tarafından işlenir, bu nedenle geliştiriciler, bir doğrulama mantığı beyaz listesi zorunlu kılan diğer bazı AA yaklaşımlarının aksine, istedikleri herhangi bir doğrulama mantığını geliştirmekte özgürdür.
• Gizlilik protokolleri için birinci sınıf destek: ilk noktanın bir sonucu olarak, Railgun gibi bir gizlilik protokolü, çerçeve işlemlerinin doğrulama mantığını işleyebilir ve kullanıcıların bugün yaptıkları gibi herhangi bir merkezi aktarıcıya güvenmeden özel işlemler göndermelerine olanak tanır. Bu, gizlilik protokollerini önemli ölçüde daha özel ve sansürlenemez hale getirir.
• Kuantum sonrası güvenlik: çerçeve işlemleri, Ethereum'un daha geniş PQ yol haritası akılda tutularak geliştirilmiştir. Örneğin, çerçeve işlemleri, imzaların toplanabilmesi için açıkça tasarlanmıştır ve Ethereum'un, her bir imzayı ayrı ayrı doğrulamak çok pahalı olsa bile, sonunda PQ imzaları için düşük gaz ücreti talep etmesine olanak tanır.

Frame Transactions'ın ana zayıflığı aynı zamanda en büyük gücünden kaynaklanır: doğrulama EVM kodu tarafından işlendiğinden, doğrulama artık sabit bir maliyet yerine dinamik bir maliyet ortaya çıkarır ve bu da L2'ler gibi yüksek TPS'li zincirler için zorluklar oluşturabilir. Bu sorunun, işlemlerin doğrulama mantıklarını statik olarak gösterebildiği, böylece sıralayıcıların gerekirse yerel kodla doğrulamayı "kısa yoldan" yapabildiği EIP-7819 gibi çerçeve işlemlerinin üzerindeki daha fazla EIP veya ERC aracılığıyla çözülebileceği konusunda iyimseriz. Ayrıca, herhangi bir performans darboğazını belirlemek ve üstesinden gelmek için L2'ler ve EF ile çerçeve işlemleri üzerinde kıyaslamalar yapmayı planlıyoruz.

[CL][EL] Frame Transactions eklentileri

Frame işlemlerinin bir uzantısı olarak görülebilecek, yetenekleri üzerine inşa edilen bir dizi EIP bulunmaktadır.

[EL] [EIP-8250: Frame Transactions için Anahtarlı Nonce'lar](https://forkcast.org/eips/8250/) [A-kademesi]

• Bu EIP'yi kavramsal olarak EIP-8141: Frame Transactions'ın bir parçası olarak görüyoruz ve onunla birlikte yayınlanması gerektiğine inanıyoruz.
• Bu EIP, Frame işlemlerine 2D nonce'lar getiriyor. 2D nonce'lar, hesapların mempool'a paralel işlemler göndermesine ve ayrıca gizlilik protokollerinin geçersiz kılıcıları 2D nonce'lar olarak depolamasına olanak tanır. Bu önemlidir çünkü 2D nonce'lar, okuması ve depolaması çok az maliyetli olan özel depolama alanlarıdır, bu nedenle gizlilik işlemleri, geçersiz kılıcıları bugün olduğu gibi normal dinamik depolamada depolamalarına kıyasla gazdan önemli ölçüde tasarruf eder. Bu, özellikle Glamsterdam'ın depolama yeniden fiyatlandırması (EIP-8037: Durum Oluşturma Gaz Maliyeti Artışı) bağlamında önemlidir.

[EL] [EIP-8272: Frame Transactions için Son Kökler](https://forkcast.org/eips/8272/) [B-kademesi]

• Bu, Frame işlemleriyle gizlilik protokollerini kullanma deneyimini geliştiren başka bir EIP'dir. Gizlilik protokollerinin doğrulama sırasında son taahhüt köklerine erişmesi gerekir; bunlar normal depolamada depolanırsa yalnızca pahalı olmakla kalmaz, aynı zamanda Frames'in genel mempool kurallarıyla da çelişebilir. EIP-8272, bu kökleri eski kökleri otomatik olarak temizleyen bir halka tamponda depolamak için bir sistem sözleşmesi sunarak bu sorunları çözer.
• Bu EIP, belirli bir kullanım durumu için frames'e önemli bir karmaşıklık eklediğinden ve aynı hedefe ulaşmanın daha genel/zarif bir yolu olup olmadığından emin olmadığımız için B-kademesine koyuyoruz.

[CL] [EIP-8369: FOCIL Uygunluğu için VOPS Profilleri](https://forkcast.org/eips/8369/) [B-kademesi]

• Bu EIP, Frames ve VOPS (yalnızca geçerlilik kısmi durumsuzluk) arasındaki etkileşimi ele alır; bu, mempool düğümlerinin işlemleri doğrulamak için yeterli durumu depolamasına izin verme önerisidir, böylece durumsuzluk (zkEVM nedeniyle) dünyasında bile mempool sansüre dirençli kalabilir.
• Bu EIP, topluluğun henüz tam olarak üzerinde anlaşmaya varmadığı belirli bir durumsuzluk vizyonuna güçlü bir şekilde bağlı olduğu için B-kademesine koyuyoruz.

[EL] [EIP-7906: Durum Farkı Opcode'u ile İşlem İddiaları](https://forkcast.org/eips/7906/) [B-kademesi]

• Bu EIP, işlem sonuçlarının statik denetlenebilirliğini artırır. Kullanıcılar zaten ne olması gerektiğini iddia edebilir, ancak başka hiçbir şeyin olmadığını iddia edemez. Durum değişikliklerinin yokluğunu kanıtlamak yeni bir opcode gerektirir. Olumlu iddiaları (ör. WETH bakiyesi en az 1,5 arttı) olumsuz bir iddiayla (başka hiçbir durum değişmedi) birleştirmek, kullanıcıların bir işlemin tüm etkilerini simülasyon olmadan, yapı gereği sınırlamasına olanak tanır ve donanım cüzdanları açık bir yararlanıcıdır.
• Karmaşıklık göz önüne alındığında, onu hard fork'a dahil etmek çok bağlayıcı bir seçim olacaktır. Bunu yalnızca (a) istemci ekipleri bu belirli EIP'nin nüanslarını ve etkilerini gerçekten anlıyorsa ve (b) test yüzeyi ve karmaşıklıklar çok iyi anlaşılmışsa yapmayı öneriyoruz.

[EL] EOA geçişi [B-kademesi]

[EL] EIP-7851: Kod Kontrollü EOA Temsilciliği [B-kademesi] ve [EL] EIP-8151: Hesap Kodu Kısıtlı ecRecover [B-kademesi] en iyi, EOA'ların akıllı hesaplara nasıl geçiş yapabileceğine dair bir hikaye sunan eşleştirilmiş standartlar olarak görülür. Bu hikayede, bir EOA önce EIP-7702 aracılığıyla bir akıllı hesaba temsilci atar. Ardından, EIP-7851'in tanıttığı opcode, 7702 temsilciliğini kalıcı hale getirerek kök ECDSA anahtarını devre dışı bırakır. Öte yandan, EIP-8151, ecrecover'ı devre dışı bırakmanın farkında olacak şekilde yapacaktır, böylece eski anahtar Permit tarzı akışlar aracılığıyla fonları boşaltamaz.

Bu çifti B-kademesinde değerlendiriyoruz çünkü EOA'ları akıllı hesaplara geçirmek için birçok yaklaşımdan yalnızca biridir ve bu özel yaklaşım geniş bir inceleme veya destek almamıştır. Özellikle, bu yaklaşımın çok zincirli soruyu yanıtlamamasından endişe duyuyoruz: aynı EOA L2'lerde nasıl geçiş yapar? Kullanıcı, henüz var olmayan zincirler de dahil olmak üzere TÜM zincirlerde aynı eylemi gerçekleştirmek zorunda kalacak ve bu da kötü bir kullanıcı deneyimine yol açacaktır. L2'lerin EOA geçişi için L1'i "güven kökü" olarak kullanabileceği daha iyi bir yaklaşım olabileceğinden şüpheleniyoruz, bu nedenle kullanıcıların tüm EVM zincirleri için bir kez geçiş yapmasını sağlayacak yaklaşımlar için A/S-kademelerini ayırıyoruz.

[EL] PQ imza şeması [A-kademesi]

Hegotá, kuantum sonrası imzalara giden güvenilir bir yol oluşturmalıdır, ancak taahhütte bulunmadan önce doğru mekanizmayı onaylamalıyız.

• EIP-8355: ML-DSA doğrulaması ekleme ön derlemeleri, Frame Transactions ile birlikte kuantum sonrası hesap güvenliğini somut hale getirir.
• Alternatif: PQ desteğini etkinleştirmeden önceden kaydetmek veya daha sonra PQ anahtarlarını barındırabilecek bir türetme formatı tanımlamak.

[EL] EIP-7819: SETDELEGATE talimatı [A-kademesi]

• Yerel AA'nın Hegota'ya gelmesi muhtemel olduğundan, yeni akıllı hesaplar dağıtmanın maliyetinin düşük olması önemlidir, ancak EIP-8037 nedeniyle Glamsterdam'da hesap dağıtmak aslında daha pahalı hale gelecektir. EIP-7819 ile yeni hesaplar, proxy sözleşmeleri yerine basit temsilci işaretçileri kullanacak ve oluşturulması gereken yeni durum miktarını büyük ölçüde azaltarak dağıtım maliyetini düşürecektir.
• Bu EIP'yi A-kademesine koyuyoruz çünkü daha düşük bir hesap dağıtım maliyetinin AA'yı benimseme sürtünmesini önemli ölçüde azaltacağına inanıyoruz.

3. Performans mühendisliği: devam eden L1 ölçeklendirmesi

Glamsterdam, Ethereum'un Ar-Ge'ye yaklaşımında bir değişime işaret etti ve performans, hem protokol tasarımında hem de istemci çalışmalarında birinci sınıf bir Ar-Ge kısıtı olarak ele alındı. Gecikmeli yürütme, kaynak yeniden fiyatlandırmaları ve birçok istemci optimizasyon çalışması, son iki yılda 30M'den (en az) 200M'ye ölçeklendirmeye olanak tanıdı. Genel olarak, performans çalışmaları bize seçenek sunar: kazandığımız alan, ölçeklendirme, slotları kısaltma, düğüm gereksinimlerini düşürme veya bunların tümü için kullanılabilir.

Bugün, sürekli ölçeklendirmeyi hala bir zorunluluk olarak görüyoruz. Uygulamalar, yalnızca mevcut fiyatlara göre değil, aynı zamanda Ethereum'un blok alanı arzını zaman içinde öngörülebilir bir şekilde genişletip genişletemeyeceğine göre nerede inşa edeceklerine karar verir. Tutarlı bir şekilde artışlar sağlamak, yalnızca yol haritası taahhütlerinden daha fazla kesinlik sağlar. Ana ağ kapasitesi ayrıca talep artışlarını kaldırabilecek noktadan hala oldukça uzaktır: Ethereum'un on birinci yaş gününde, günlük medyan temel ücret yalnızca ~0,1 gwei iken, bir NFT basımı onu bir süreliğine 10 gwei'nin üzerine çıkardı ve medyan işlem maliyetleri yaklaşık 1 dolara ve 90. yüzdelik dilim 5 doların üzerine ulaştı. Bu nedenle Glamsterdam'ın ölçeklendirme hamlesi Hegotá'da da devam etmelidir.

Bir arada ele alındığında, aşağıdaki EIP'ler Glamsterdam'ın ölçeklendirme ivmesini sürdürürken, arkasındaki daha geniş ilkeyi pekiştiriyor: performans, hem istemci çalışmalarında hem de protokol tasarımında birinci sınıf bir endişe olarak kalmalıdır.

[EL] EIP-8131 ve EIP-8279 [S-kademesi]: Veri yeniden fiyatlandırma paketi

Glamsterdam'dan sonraki en önemli kısıtlama, yük aktarımı (payload propagation) olacak. Bunun nedeni, kısmen, farklı yük bayt kaynaklarının gaz muhasebesinde tutarsız bir şekilde yansıtılması veya hiç yansıtılmamasıdır. EIP-8131: Unified Transaction Content Floor, mevcut işlem tabanını (transaction floor) yürütme öncesinde bilinen içeriğe genişletirken, EIP-8279: Block Access List Byte Floor, yürütme sırasında dinamik olarak oluşturulan BAL baytlarını kapsar.

Bu dinamik ölçüm, EIP-8279'u ikisi arasında açık ara daha karmaşık hale getiriyor. Ancak, bunları bir paket olarak düşünmenizi öneririz. Birlikte ele alındıklarında, bir işlemle ilişkili baytlar için tutarlı bir muhasebe oluşturarak, en kötü durumdaki yükü sınırlarken, çoğu sıradan, veri yoğun olmayan işlemi etkilemezler. Bu, temel kaynak muhasebesi açığını giderir ve daha fazla gaz limiti artışının önünü açar.

[CL][EL] EIP-8146: Block Access List Sidecars [A-Seviyesi]

EIP-8146, kritik yolu (critical path) iyileştirerek yeniden fiyatlandırmaları tamamlar. BAL'ları yükten ayrı olarak yayar, bu da yayılımı iyileştirir ve yürütme istemcilerine durum ön getirme (state prefetching) ve işlem sonrası durum kökü hesaplaması (post-state-root computation) konusunda bir avantaj sağlar. Bunu, masada bırakmamamız gereken, kolayca elde edilebilecek bir optimizasyon türü olarak görüyoruz. Uygulama çalışması çoğunlukla tanıdık CL gossip mekanizmalarından oluşur ve bu da bunu, özellikle oldukça EL ağırlıklı olacağa benzeyen bir fork için, düşük eforlu, yüksek değerli bir EIP haline getirir.

İlgili Diğer EIP'ler

[EL] CPSB Yeniden Kalibrasyonu [A-Seviyesi]

• Çok basit değişiklikler, bunları pipeline'da tutmanızı ve planlanan gaz limiti artışlarına ve state ile yürütme gazının gözlemlenen kullanımına bağlı olarak gerekli görülmesi halinde ikisinden birini dahil etmenizi öneririz.
• EIP-8368: Yeni Gaz Limiti için CPSB Yeniden Kalibrasyonu: EIP-8037'nin önceden planlanmış bir takibidir. State baytı başına maliyetin (CSPB), gaz limitinin bir fonksiyonu olmak yerine, tamamen uygulama ve test basitleştirmesi olarak statik hale getirilmiş olmasını telafi eder. Fikir, blok blok ayarlamanın yerine, gaz limiti arttıkça state büyümesini hedefte tutmak için fork'larda gerektiği kadar tek seferlik ayarlamalar yapmaktı. Mevcut CPSB 150M gaz limitinde kalibre edildiğinden, Hegotá'da bir ayarlamanın gerekli olması muhtemeldir.
• EIP-8372: Normalleştirilmiş state gaz limiti: Hala EIP-8368'in oldukça minimal bir üst kümesidir. Sadece CPSB'den daha ince ayarlı bir düzenlemeye izin verir ve state büyüme hedefinin veya normal gaz hedefinin, göreceli yanlış fiyatlandırma nedeniyle hedefin altında kalmasını telafi eder.

[EL] EIP-7862: Gecikmeli State Root [B-Seviyesi]

• Belirtimi (spec) basittir, ancak istemci uygulamalarının karmaşıklığı bildiğimiz kadarıyla çok iyi anlaşılmamıştır. State root, kod tabanlarında yaygın olarak bulunur.
• Rekabetçi blok oluşturmaya (hızlı state root hesaplaması) erişim engelini düşürmede bir miktar fayda olsa da, EIP'nin en önemli avantajı bizce gelecektedir (state root hesaplamasını kanıtlamak için daha fazla zaman).
• EL zaten Hegotá'nın ağır tarafıdır.

[CL] EIP-8341: Kısmi Yürütme Yükü Taahhütleri [D-Seviyesi]

• Reddetmenizi öneririz: küçük fayda (state root hesaplamasını biraz geciktirir), acil değil ve yerini EIP-7862: Gecikmeli State Root'a bırakmıştır (bu çok daha fazla zaman sağlar).

Diğer EIP'ler

Şimdi, konularına göre gevşek bir şekilde gruplandırılmış diğer EIP'leri ele alıyoruz. Bazı EIP'ler hakkında hala fikir oluşturuyoruz. Önümüzdeki günler ve haftalarda istemci ekiplerinden ve EIP yazarlarından daha fazla şey öğrendikçe bu belgeyi güncelleyeceğiz.

Hegotá'nın EL ağırlıklı bir hard fork olması beklendiğinden, disiplinli kalmayı ve herhangi bir EL tarafı EIP'sinin geçmesi için yüksek bir çıta belirlemeyi öneriyoruz. Hegotá'yı FOCIL ve Quick Slots dışında nispeten CL hafif tutmanın arzu edilir olduğunu düşünüyoruz: daha dar bir kapsam, istemci ekiplerine daha büyük mimari geçişe hazırlanmaları için alan sağlamak üzere bant genişliğini korur.

[CL] Emisyon (Issuance)

EIP-8363: Konik Emisyon Yakımı (Tapered Issuance Burn)'e kasten bir seviye atamıyoruz. Emisyonun, çekirdek geliştiricilerin tek başlarına vermesi gereken bir karar olmadığını ve bir seviye listesinin çekirdek geliştiricilere açık bir tavsiye olduğunu düşünüyoruz. Çoğu EIP için ACD süreci iyi çalışır çünkü kararlar öncelikle tekniktir ve topluluk bunları etkili bir şekilde çekirdek geliştiricilere devretmiştir. Emisyon, topluluğun kendisinin kabaca bir fikir birliğine varması gereken bir para politikası sorusu olması bakımından farklıdır. Çekirdek geliştiricilerin görüşleri önemlidir, ancak bu kamu tartışmasına girdi olarak. EIP-8363'ü diğer EIP'lerle aynı kefeye koymak, onu normal bir ACD kararı olarak ele almak olur ki bizce öyle olmamalıdır.

Teknik olarak, emisyonu EIP-8363 ile uyumlu olarak değiştirmenin faydasını görüyoruz. Ele aldığı sorunlar gerçektir: daha fazla ETH stake edildikçe slashing'in güvenilirliği aşınır, yüksek staking oranları ödüllerin çoğunlukla enflasyonu dengelemesi anlamına gelir ve ölçek ekonomileri büyük operatörler ile bireysel stake edenler arasındaki farkı açmaya devam eder. Bir değişikliğin ayrıca, etkilerin belirsizliğinden stake dağılımına ve para politikası katılaşma (ossification) saatini sıfırlamaya kadar riskleri vardır. Ansgar'ın yazısı her iki tarafı da ortaya koyuyor ve bizim pozisyonumuzu yansıtıyor. Bazılarımız geçmişte emisyon değişikliklerini savundu ve bu yolda olmaya devam ediyor.

Emisyon kararının, diğer tüm Hegotá kapsam belirleme kararlarından sonra verilmesini öneriyoruz. Bu, topluluk tartışmasına ihtiyaç duyduğu zamanı verir ve kapsam belirleme sürecinin kendisinden dikkati dağıtmaz.

[CL] Staking Özellikleri

Staking iyileştirmeleri değerli olabilir, ancak kullanıcıya yönelik faydalar, kesinlikle gerekli olmadıkça, yalnızca altyapı değişikliklerine göre öncelikli olmalıdır.

[CL] EIP-8015: deposit ve eth1data alanlarını kaldırma [A-Seviyesi]

• Teknik borcun çok basit bir temizliği. EIP-7688: İleri uyumlu konsensus veri yapıları sayesinde, ilgisiz alanların Merkle kanıtları etkilenmez, bu nedenle zincir tüketicileri üzerinde hiçbir etkisi yoktur.

[EL][CL] EIP-8237: Bağımsız CL/EL Senkronizasyonu [B-Seviyesi]

• ePBS tarafından getirilen beacon bloğu ve yük ayrımı üzerine inşa edilerek EL ve CL'nin bağımsız olarak senkronize olmasını sağlar. Bunun, Ethereum istemcilerinin karmaşık bir bölümünü basitleştirme potansiyeline sahip olduğunu düşünüyoruz.

[CL] EIP-8205: Çekme kimlik bilgileri ön kaydı [D-Seviyesi]

• Reddetmenizi öneririz. EIP, devredilmiş staking'teki gerçek bir sorun için protokol içi bir çözüm sağlarken, mevcut para yatırma öncesi (pre-deposit) çözümünün yeterli olduğunu ve eklenen mekanizmanın karmaşıklığının şu anda haklı çıkarılmadığını düşünüyoruz.

[CL] EIP-8148: Doğrulayıcılar için özel süpürme eşiği [D-Seviyesi]

• Reddetmenizi öneririz. EIP'nin faydalarına kıyasla çok karmaşık olduğunu düşünüyoruz (yeni sistem sözleşmesi, yeni yürütme talebi, CL mekanizması). Bu faydaların, öncelikle ev operatörü havuzundan bir miktar marjinal ek konsolidasyonu teşvik etmek olduğunu görüyoruz. Stake'in nasıl dağıtıldığı göz önüne alındığında, bunun genel doğrulayıcı konsolidasyonu üzerinde çok fazla etkisi olacağını düşünmüyoruz.

[CL] EIP-8375: ePBS Zorunlu Yürütme Ödülleri Yakımı [D-Seviyesi]

• Reddetmenizi öneririz. Bunun muhtemelen sadece daha fazla yan kanal (side-channeling) oluşmasına yol açacağını düşünüyoruz. Dahası, MEB yakma stratejileri üzerine yıllarca süren tartışmalar, geniş bir araştırma fikir birliğine ulaşan herhangi bir öneriyle sonuçlanmadı.

[CL] EIP-7716: Korelasyon karşıtı onaylama cezaları [D-Seviyesi]

• Reddetmenizi öneririz. Staking teşviklerinde bu kadar büyük bir değişikliği haklı çıkaracak yeterince açık kanıt olduğunu düşünmüyoruz. Ayrıca, staking teşvikleri muhtemelen ayrıştırılmış konsensusun (decoupled consensus) bir parçası olarak yeniden düzenlenecektir.

[CL] EIP-8333: Kontrol Noktasını Epoch Sınır Bloğu ile Hizalama [D-Seviyesi]

• Reddetmenizi öneririz. Güzel bir temizlik olsa da, bunu yaklaşan büyük ayrıştırılmış konsensus geçişine ertelemenin faydalı olacağını düşünüyoruz.

[CL] EIP-8359: Beacon Blok Raporlama Alanı [fikir oluşturuyoruz]

[CL] Daha Fazla Kuantum Sonrası (PQ-prep) Hazırlık

Bu öneriler, gelecekteki bir kuantum sonrası geçiş öncesinde kalan BLS bağımlılıklarını azaltır.

[CL] EIP-8365: BLS çekme kimlik bilgisi emekliliği [A-Seviyesi]

• Eski bir çekme kimlik bilgisini emekliye ayırarak protokol basitleştirmelerinin ve gelecekteki PQ geçişinin basitleştirilmesinin önünü açar.
• Ne kadar basit olduğu göz önüne alındığında, şimdi dahil etmeye değer olduğunu düşünüyoruz.

[CL] EIP-8367: Emekli BLS doğrulayıcıları için bakiye gün batımı [D-Seviyesi]

• Reddetmenizi öneririz. Çoğu 0x0 doğrulayıcısının, EIP-8365: BLS çekme kimlik bilgisi emekliliği etkinleştirilmeden önce veya sonra, ya fonlarını çekmek ya da stake etmeye devam edebilmek için bir kimlik bilgisi değişikliği (BLSToExecutionChange) yapmasının muhtemel olduğunu düşünüyoruz. Kalan 0x0 stake'i ile başa çıkmak için bir mekanizma sunmak için büyük bir aciliyet olduğunu düşünmüyoruz. Sadece EIP-8365'i dahil etmenizi ve sonraki adımlara karar vermeden önce bunun sonucunu görmenizi öneririz.

[CL] EIP-8321: Hash-Zinciri RANDAO [D-Seviyesi]

• Reddetmenizi öneririz. RANDAO'yu tek başına kuantum sonrası güvenli hale getirmek, doğrulayıcı BLS anahtarları savunmasız kalmaya devam ederken çok az protokol düzeyinde güvenlik sağlar, ancak doğrulayıcı başına yaklaşık 32 bayt, yeni bir gizli yönetim mekanizması ve büyük ölçüde tek amaçlı bir mekanizma ekler. Daha geniş PQ konsensus tasarımı belirsizliğini koruyor. Yinelemeli bir geçişi destekliyoruz, ancak ilk adımı, nihai tasarım tarafından geçersiz kılınma riskini almak yerine, üzerinde anlaşmaya varılmış bir yol haritasını takip etmelidir.

[EL][CL] zkEVM Hazırlığı

Çoğu zkEVM hazırlığı, dar bir kullanıcı kitlesi için tam düğüm işletimini kolaylaştırmanın ötesinde sınırlı kısa vadeli faydalar sunarken, uygulama bant genişliği tüketir ve potansiyel olarak EVM'yi daha pahalı hale getirir. Yalnızca uzun vadeli değeri bu acil maliyetleri açıkça haklı çıkaran değişiklikleri dahil etmeliyiz.

[CL] EIP-8025: İsteğe Bağlı Yürütme Kanıtları [D-Seviyesi]

• EIP bir hard fork gerektirmez. Hegota ile birlikte paketleme önerisi tamamen bir önceliklendirme ifadesidir ve biz bu seçime katılmıyoruz. Üzerinde çalışmaya devam edilmesi gerektiğini düşünüyoruz, ancak Hegotá bunun için engellenmemelidir.
• İsteğe bağlı kanıtları göndermeden önce, önce nihai durumu tanımlamaya yönelik çalışmalı, ardından buna doğru hızlanmalıyız; uzun vadeli doğrulayıcı/state modeli hakkında net bir görüş olmadan isteğe bağlı kanıtları göndermemeliyiz.
• Temel açık soru, doğrulayıcıların state ile ilgili olarak nasıl bir role sahip olması gerektiğidir: tamamen statesiz hale gelmek yerine, state'in bir kısmına hizmet etmeye veya onu tutmaya devam etmeli mi? Doğrulayıcılar, gerçek donanım ve ağ değerine sahip temel bir düğüm grubu olduğundan, bu rolü zayıflatan değişiklikler daha yüksek bir çıtayı geçmelidir.

[EL] EIP-7666: identity ön derlemesini EVM'leştirme [A-Seviyesi]

• kullanışlı, küçük değişiklik

[EL] EIP-8200: EVMleştirme [B-Seviyesi]

• EIP-8200, üç yerel ön derlemeyi eşdeğer EVM bayt koduyla değiştirir. İkisi çok az kullanım görür ve taşınması basit görünmektedir. Üçüncüsü, SNARK doğrulamasında yaygın olarak kullanılır, bu nedenle kaldırılmasını desteklemeden önce bir etki değerlendirmesi isteriz.
• Etki analizi, etkilenen kullanıcılar için düşük taşıma maliyeti bulursa veya üçüncü ön derleme kapsam dışı bırakılırsa, EIP-8200'ü [A-Seviyesi]'ne taşırız.

[EL] EIP-7709: BLOCKHASH'ı Depolamadan Okuma ve Maliyet Güncellemesi [D-Seviyesi]

• Çok büyük gaz maliyeti artışı nedeniyle oldukça yıkıcı, acil değil
• Riski azaltmak, bir etki analizini veya bunu daha sonra bir tür blok düzeyinde ısıtma (veya bu değerlerin özel olarak ısıtılması) ile yaparak etkiyi azaltmayı içerebilir.

[EL] EIP-8268: Blok Erişim Listelerinde Depolama Kökleri [B-Seviyesi]

• BAL boyutları üzerindeki somut etkinin ve bununla ilgili işlem maliyetleri üzerindeki etkinin (EIP-8279 BAL baytları için ücretlendirme önermektedir) bir analizini gerektirebilir, çünkü dokunulan her hesap için BAL girişi ek bir depolama trie kökü alır.

[EL] EVM Özellikleri

Hegotá yine de bazı özel EVM kararları gerektirecektir. Hegotá'dan sonra Ethereum'un, daha geniş EVM ekosistemi tarafından şekillendirilen uzun vadeli bir EVM yol haritasına doğru çalışması gerektiğine inanıyoruz. Ethlabs buna katkıda bulunacaktır.

[EL] EIP-5920: PAY opcode'u [A-Seviyesi]

• Çok basit ve EVM'nin sahip olması gereken iyi bir temel yapı taşı olduğunu düşünüyoruz.
• Somut kullanım durumlarını daha iyi anlamak önemli olacaktır.

[EL] EIP-8163: EXTENSION (0xae) opcode'unu ayırma [A-Seviyesi]

• L2'ler için çok kullanışlı, L1 için gerçek bir maliyeti yok (sadece bilgilendirme amaçlı)

[EL] Kod yeniden kullanımı / tekilleştirme [B-Seviyesi]

• EIP-8058: Sözleşme Bayt Kodu Tekilleştirme İndirimi ve EIP-8298: SETCODEFROM Kod Yeniden Kullanım Talimatı, her ikisi de sözleşme kodunun, kod karmasının aralarında işaretçi olarak kullanıldığı, istemcilerde ilgili hesaptan ayrı olarak depolanması gerçeğinden yararlanmaya çalışır. Böylece özdeş paylaşılan kod, tekilleştirilmiş olarak depolanabilir. Her iki EIP de, hesap kod karmasını başka bir yerde bulunan bir kodun karmasına ucuza ayarlamanın bir yolunu sağlar.
• Bunu çekici bir genel fikir olarak değerlendiriyoruz, ancak ikili ağaçlara (binary trees) yönelik etkileri ve ileri uyumluluğu anlamak önemli olacaktır. Şimdilik ikisi arasında bir tercihimiz yok.

[EL] Bellek fiyatlandırma reformu [B-Seviyesi]

• Hegota'da bellek reformu yapmak isteyip istemediğimize karar vermemiz gerekiyor. Bu değerlendirmeyi yapmak için şu anda tasarım alanını yeterince anladığımız bizim için net değil.

EIP-7686: Doğrusal EVM bellek sınırları

• Daha küçük bir değişiklik, sadece ikinci dereceden (quadric) bellek genişletme maliyetinden kurtulur.

EIP-7923: Doğrusal, Sayfa Tabanlı Bellek Maliyetlendirmesi

• Daha derin, daha ilkeli bir yeniden çalışma, ancak daha karmaşık.

[EL] EIP-8219: Kontrollü Aritmetik Opcode'ları [B-Seviyesi]

• Genel olarak EVM'ye güvenli matematik eklemek faydalı görünüyor.
• Fiyatlandırmanın kıyaslamalarla (benchmarks) doğrulanması gerekir, bu ne kadar karmaşık?
• Kıyaslamalar ve bir etki analizi (kaç işlem faydalanabilir, ne kadar, hangi derleyiciler destek ekler?) ile A-Seviyesi olabilir.

[EL] EIP-8360: TCREATE Opcode'u [B-Seviyesi]

• EIP, işlem kapsamında geçici sözleşmeler oluşturma yeteneği getiriyor. Bu genel olarak sahip olunması güzel bir temel yapı taşıdır.
• EIP önemli bir karmaşıklık ekliyor. Daha kapsamlı bir uygulama ve test karmaşıklığı değerlendirmesi ile A-Seviyesi olabilir.

[EL] EIP-7645: ORIGIN'i SENDER ile takma adlandırma [D-Seviyesi]

• Reddetmenizi öneririz: Kırıcı değişiklik, ORIGIN'in uygunsuz kullanımı.

[EL] EIP-8182: Özel ETH ve ERC-20 Transferleri [D-Seviyesi]

• Reddetmenizi öneririz: Büyük değişiklik, zk bağımlılıkları ekler. Eğer bir gün tanıtılırsa, bunun bir başlık (headliner) olması gerektiğini düşünüyoruz.

[EL] EIP-2488: CALLCODE opcode'unu kullanımdan kaldırma [fikir oluşturuyoruz]

[EL] EIP-4758: SELFDESTRUCT'u devre dışı bırakma [fikir oluşturuyoruz]

[EL] EIP-7979: EVM için Çağrı ve Dönüş Opcode'ları [fikir oluşturuyoruz]

[EL] EIP-8173: EVM Kontrol Akışının Temelleri [fikir oluşturuyoruz]

[EL] EIP-8253: Sıfır-nonce depolama hesaplarının nonce'ını artırma [fikir oluşturuyoruz]

[EL] EIP-8030: P256 algoritma desteği [fikir oluşturuyoruz]

[EL] EVM Fiyatlandırması

Glamsterdam, genel verimi kısıtlayan düşük fiyatlı işlemlerin fiyatlarını yükseltti. Hegotá'nın EVM fiyatlandırma önerileri çoğunlukla diğer tarafı ele alıyor: mevcut maliyeti kullanımlarını sınırlayan, ancak ağ ölçeklenebilirliğini sınırlamayan bireysel işlemlerin fiyatlarını düşürmek. Bu nedenle bunlar, EIP başına daha düşük etkiye sahip, sahip olunması güzel şeylerdir. Hedefli yeniden fiyatlandırmaya açığız, ancak yeni ölçüm mekanizmaları getiren öneriler, yalnızca tasarımları sağlamsa ve kararlı bir şampiyon tarafından yeterince riski azaltılmışsa dahil edilmelidir.

[EL] EIP-8358: Hesap Değişiklikleri için Net Gaz Ölçümü [B-Seviyesi]

• Etkisine ikna olmadık. Örneklenen 900 ana ağ bloğunda, ~400k işlem: tüm işlemlerin %2,07'si gaz tasarrufu sağlarken, blok gazının %1,14'ü tasarruf edilecektir.

[EL] EIP-7973: Sıcak Hesap Yazma Ölçümü [fikir oluşturuyoruz]

[EL] EIP-7609: TLOAD/TSTORE temel maliyetini düşürme [fikir oluşturuyoruz]

[EL] EIP-7971: Geçici Depolama için Sert Sınırlar [fikir oluşturuyoruz]

[EL] EIP-3298: İadelerin kaldırılması [fikir oluşturuyoruz]

[EL] EIP-8374: Sıcak Erişim Kümelerini Geri Alma İşlemleri Arasında Kalıcı Yapma [fikir oluşturuyoruz]

[EL] EIP-8115: Blok sonunda toplu öncelik ücretleri [fikir oluşturuyoruz]

[EL] EIP-8188: Hesaplar ve Yuvalar için Son Yazılan Blok [fikir oluşturuyoruz]

[EL][CL] Yürütme verileri ve indeksleme

[EL][CL] EIP-7668: Bloom filtrelerini kaldırma [fikir oluşturuyoruz]

[EL][CL] EIP-7807: SSZ yürütme blokları [fikir oluşturuyoruz]

[EL] EIP-8116: Kümülatif makbuz alanlarını değiştirme [fikir oluşturuyoruz]

[EL] EIP-8304: Güvensiz log ve işlem indeksi [fikir oluşturuyoruz]

[EL][CL] Ağ Oluşturma

Ethereum'un P2P katmanı, özellikle işlemlerin, blob'ların ve onaylamaların ağ üzerinde nasıl yayıldığı konusunda hedefli iyileştirmeler için alana sahiptir.

[CL] EIP-8371: RowDAS - Dağıtık Blob Yeniden Yapılandırması [A-Seviyesi]

• Genellikle tam yeniden yapılandırmayı ve tam velayet düğümü performansını blob sayısını ölçeklendirmede bir darboğaz olarak önler.
• Değerli, sonunda bir tür dağıtık yeniden yapılandırma kesinlikle protokole girmelidir. Bu, doğrulayıcı velayetini kaldırmamızı sağlayabilir.
• Karmaşıklığı daha iyi anlamamız gerekiyor.

[CL] EIP-8142: Blob İçinde Blok (BiB) [D-Seviyesi]

• Erken, güçlü bir aciliyet yok, oldukça son dakika, birçok soru kaldı (KZG olsun mu olmasın mı? Yeni gossip konuları olsun mu olmasın mı?).
• Blok üretiminin kritik yoluna KZG'yi dahil etmek istemiyoruz, alternatifler belirsiz ve daha fazla karmaşıklık ekleyecektir.

[CL] EIP-8243: Kaynakta Onaylamaları Toplu Hale Getirme [D-Seviyesi]

• Bunun nihai olma süresini (time-to-finality) azaltmak için buna güvenip güvenemeyeceğimiz net değil, yük üzerinde net bir sınır koymuyor.
• Mekanizmanın DoS direnci tam olarak net değil.

[EL] EIP-8077: eth/XX - işlemleri nonce ile duyurma [fikir oluşturuyoruz]

[EL] EIP-8094: eth/vhash - Blob Farkındalıklı Mempool [fikir oluşturuyoruz]

[CL] EIP-8334: Paketlenmiş Onaylama Yayılımı [fikir oluşturuyoruz]

Eğer bir şekilde hala bizimleyseniz, sonuna kadar okuduğunuz için teşekkür ederiz. Herhangi bir sorunuz varsa yanıtlamaktan çekinmeyin, elimizden gelenin en iyisini yaparak size dönüş yapacağız! Eğer atladıysanız ve sadece buraya kaydırdıysanız çünkü devasa bir metin duvarını incelemek Pazar gününüzü geçirme şekliniz değildi, bir sonraki bölümün kısa olduğunu bilmek sizi memnun edecektir.

Birkaç (daha fazla) kelime...

Ethereum yükseltmeleri karmaşıktır çünkü riskler yüksektir. Dünyanın dört bir yanındaki binlerce düğüm, aynı slotta yeni kurallara geçer ve ağ, bu sırada bir saniye bile durmaz. Bu titizlik, Ethereum'un teslim ettiği her yükseltmeyi taşımış ve 11 yıldır %100 çalışma süresini kutlayan merkezi olmayan bir ağ ile sonuçlanmıştır.

Hegotá hakkındaki pozisyonlarımız bugün itibarıyla en iyi değerlendirmelerimizdir, ancak tartışmalardan veya uygulama çalışmalarından elde edilen yeni kanıtlar görüşümüzü değiştirdiğinde düşüncelerimizi güncelleyeceğiz.

Bu EIP'lerden bazıları Ethlabs üyeleri tarafından yazılmış veya ilerletilmiştir, diğerleri ise Ethereum genelindeki inanılmaz derecede geniş, yetenekli ve iyi niyetli araştırmacılardan, istemci geliştiricilerinden ve bireysel katkıda bulunanlardan gelmektedir. Ancak, hepsinin başarılı olması için istemci ekipleri, cüzdanlar, uygulamalar, L2'ler, altyapı sağlayıcıları, kurumlar, düğüm operatörleri ve nihayetinde kullanıcılar arasında iş birliği gerekecektir. Ethereum, dünyanın ortak projesidir ve anlamlı ağ ilerlemesi asla tek bir organizasyonun işi değildir.

Bu ekosistemin küçük bir parçası olmaktan minnettarız ve Ethereum'un potansiyelini gerçekleştirmesine yardımcı olmayı dört gözle bekliyoruz.

– Ethlabs