Orijinal başlık: Ethereum Fusaka Hard Fork: Neler Değişiyor?

Orijinal yazar: Sahil Sojitra

Orijinal çeviri Golem, Odaily Planet Daily tarafından yapılmıştır

3 Aralık 2025'te aktif hale gelmesi planlanan Fusaka hard fork'u, Ethereum için Pectra'dan sonra bir diğer büyük ağ yükseltmesi olup, kripto devinin ölçeklenmeye doğru attığı önemli bir adım daha anlamına geliyor.

Pectra'nın güncellenen EIP'si performans, güvenlik ve geliştirici araçlarını iyileştirmeye odaklanırken, Fusaka'nın güncellenen EIP'si ölçeklendirmeye, işlem kodu güncellemelerine ve yürütme güvenliğine vurgu yapıyor.

PeerDAS (EIP-7594), düğümlerin tüm verileri indirmeden blob'ları doğrulamasına olanak tanıyarak veri kullanılabilirliğini artırır. ModExp'i sınırlama (EIP-7823), işlem gazı limitlerini sınırlama (EIP-7825) ve ModExp gaz maliyetlerini güncelleme (EIP-7883) gibi çeşitli yükseltmeler, yürütme güvenliğini de artırır. Bu Fusaka yükseltmesi ayrıca, belirleyici bir teklif sağlayıcısı ileriye dönük mekanizması (EIP-7917) aracılığıyla blok üretimini iyileştirir ve yürütme maliyetlerine bağlı bir "rezervasyon fiyatı" belirleyerek istikrarlı blob ücretlerini korur (EIP-7918).

Diğer geliştirmeler arasında RLP formatının blok boyutunun sınırlandırılması (EIP-7934), bit işlemlerini hızlandırmak için yeni bir CLZ opcode'unun eklenmesi (EIP-7939) ve modern kriptografi ve donanım güvenlik anahtarlarıyla daha iyi uyumluluk için secp256r1 ön derlemesinin (EIP-7951) tanıtılması yer alıyor.

Fusaka, Fulu (yürütme katmanı) ve Osaka'nın (mutabakat katmanı) birleşik adıdır. Ethereum için, Katman 2 Toplamalarının daha düşük maliyetlerle ve daha yüksek hızlarda çalışabileceği, son derece ölçeklenebilir ve veri açısından zengin bir geleceğe doğru atılmış bir adım dahadır.

Bu makale, Fusaka hard forkunun dokuz temel EIP önerisinin derinlemesine bir analizini sunacaktır.

EIP-7594: PeerDAS - Düğüm Veri Kullanılabilirliği Örneklemesi

Ethereum'un bu teklife ihtiyacı var çünkü ağ, özellikle Rollup kullanıcıları olmak üzere kullanıcılara daha fazla veri erişilebilirliği sağlamak istiyor.

Ancak mevcut EIP-4844 tasarımında, her düğümün yayınlanıp yayınlanmadığını doğrulamak için büyük miktarda blob verisi indirmesi gerekiyor. Bu durum ölçeklenebilirlik sorunlarına yol açıyor çünkü tüm düğümlerin tüm verileri indirmesi gerekiyorsa, ağın bant genişliği ve donanım gereksinimleri artıyor ve merkeziyetsizlik derecesi etkileniyor. Bu sorunu çözmek için Ethereum'un, düğümlerin verilerin tamamını indirmeden erişilebilirliğini doğrulamasını sağlayacak bir yola ihtiyacı var.

Veri Kullanılabilirliği Örneklemesi (DAS), düğümlerin yalnızca küçük miktarda rastgele veriyi incelemesine izin vererek bu sorunu çözer.

Ancak Ethereum'un, mevcut Gossip ağıyla uyumlu ve blok üreticilerine ağır bir hesaplama yükü getirmeyen bir DAS yöntemine de ihtiyacı var. PeerDAS, bu ihtiyaçları karşılamak ve düğüm gereksinimlerini düşük tutarken blob verimini güvenli bir şekilde artırmak için oluşturuldu.

PeerDAS, düğümlerin verilerin tamamının yayınlanıp yayınlanmadığını doğrulamak için yalnızca küçük veri parçalarını indirmesine olanak tanıyan bir ağ sistemidir . Düğümler, tüm verileri indirmek yerine, hangi düğümlerin verilerin belirli bir bölümünü tuttuğunu keşfetmek ve yalnızca gerekli küçük örneği istemek için normal dedikodu ağı paylaşımını kullanır. Temel fikir, bir düğümün bir veri parçasının yalnızca rastgele küçük bir bölümünü indirerek, tüm parçanın varlığından emin olabilmesidir. Örneğin, bir düğüm 256 KB'lık parçanın tamamı yerine yalnızca yaklaşık 1/8'ini indirebilir; ancak birçok düğüm farklı bölümleri örnekleyeceği için, eksik veriler hızla tespit edilecektir.

Örneklemeyi gerçekleştirmek için PeerDAS, EIP-4844'teki her veri segmentini genişletmek üzere temel bir silme kodlama yöntemi kullanır. Silme kodlaması, bazı veri segmentleri eksik olsa bile orijinal verilerin kurtarılabilmesi için fazladan yedekli veri ekleyen bir tekniktir; tıpkı bazı parçalar eksik olsa bile bir araya getirilebilen bir yapboz bulmacası gibi.

Blob, orijinal verileri ve daha sonraki veri yeniden yapılandırmasına olanak sağlamak için bazı ek kodlanmış verileri içeren bir "satıra" dönüştürülür. Bu satır daha sonra, bir KZG taahhüdüyle ilişkili en küçük doğrulama birimleri olan "hücreler" adı verilen daha küçük parçalara bölünür. Tüm "satırlar" daha sonra, her biri tüm satırlardaki aynı konumlardan hücreleri içeren "sütunlar" halinde yeniden düzenlenir. Her sütun belirli bir dedikodu alt ağına atanır.

Her düğüm, düğüm kimliğine göre belirli sütunları depolamaktan ve her zaman aralığında eşlerinden bazı sütunları örneklemekten sorumludur. Bir düğüm sütunların en az %50'sini toplarsa, verileri tamamen yeniden oluşturabilir. %50'den az toplarsa, eksik sütunları eşlerinden talep etmesi gerekir. Bu, veriler gerçekten yayınlandıysa, her zaman yeniden oluşturulabileceğini garanti eder. Kısacası, toplam 64 sütun varsa, bir düğümün eksiksiz bir veri bloğunu yeniden oluşturmak için yalnızca yaklaşık 32 sütuna ihtiyacı vardır. Bazı sütunları kendisi tutar ve diğerlerini eşlerinden indirir. Sütunların yarısı ağda mevcut olduğu sürece, bazı sütunlar eksik olsa bile bir düğüm her şeyi yeniden oluşturabilir.

Ayrıca, EIP-7594 önemli bir kural getirir: hiçbir işlem 6'dan fazla blob içeremez . Bu kısıtlama, işlem doğrulama, dedikodu yayılımı, blok oluşturma ve blok işleme sırasında uygulanmalıdır. Bu, tek bir işlemin blob sistemini aşırı yükleyebileceği uç durumların azaltılmasına yardımcı olur.

PeerDAS, "hücre KZG kanıtı" adlı bir özellik ekledi. Hücre KZG kanıtı, bir KZG taahhüdünün blob'daki belirli bir hücreyle (küçük bir birim) gerçekten eşleştiğini gösterir. Bu, düğümlerin yalnızca örneklemek istedikleri hücreleri indirmelerine olanak tanır. Veri bütünlüğünü koruyarak tüm blob'u elde etmek, veri kullanılabilirliği örneklemesi için çok önemlidir.

Ancak, tüm bu birim kanıtlarını oluşturmak maliyetlidir. Blok üreticilerinin bu kanıtları birçok blok üzerinde tekrar tekrar hesaplaması gerekir ve bu da çok yavaştır. Ancak, kanıt doğrulamanın maliyeti çok düşüktür; bu nedenle, EIP-7594, blok işlem göndericilerinin tüm birim kanıtlarını önceden oluşturmasını ve bunları işlem paketine eklemesini gerektirir.

Bu nedenle, işlem dedikodusu (PooledTransactions) artık değiştirilmiş bir sarmalayıcı kullanıyor:

「rlp([tx_payload_body, wrapper_version, blob'lar, taahhütler, hücre_kanıtları])」

Yeni sarmalayıcıda, `cell_proofs`, her bir blob'un her hücresi için tüm kanıtları içeren bir listedir (örneğin, `[cell_proof_0, cell_proof_1, ...]`). Diğer alanlar `tx_payload_body`, `blobs` ve `commitments`, EIP-4844'teki alanlarla aynıdır. Aradaki fark, orijinal tek "proofs" alanının kaldırılıp yerine yeni bir `cell_proofs` listesi konulmuş olması ve mevcut sarmalayıcı biçimini belirtmek için `wrapper_version` adlı yeni bir alanın eklenmiş olmasıdır.

PeerDAS, Ethereum'un düğüm iş yükünü artırmadan veri kullanılabilirliğini iyileştirmesini sağlar . Şu anda, bir düğümün toplam verinin yalnızca yaklaşık 1/8'ini örneklemesi yeterlidir. Gelecekte, bu oran 1/16 veya 1/32'ye düşerek Ethereum'un ölçeklenebilirliğini artırabilir. Sistem, her düğümün çok sayıda eşinin olması nedeniyle iyi çalışır; böylece bir eş gerekli verileri sağlayamazsa, düğüm diğer eşlerden talep edebilir. Bu, doğal olarak yedeklilik sağlar ve güvenliği artırır. Düğümler ayrıca gerçekte ihtiyaç duyulandan daha fazla veri depolamayı seçebilir ve bu da ağ güvenliğini daha da artırır.

Doğrulayıcı düğümler, normal tam düğümlerden daha fazla sorumluluk taşır. Doğrulayıcı düğümler daha güçlü donanımlarda çalıştığı için, PeerDAS, toplam doğrulayıcı düğüm sayısına bağlı olarak bunlara karşılık gelen bir veri barındırma yükü tahsis eder. Bu, daha fazla veriyi depolamak ve paylaşmak için her zaman kararlı bir düğüm grubunun mevcut olmasını sağlayarak ağ güvenilirliğini artırır. Kısacası, 900.000 doğrulayıcı düğüm varsa, her doğrulayıcı düğüme depolama ve bakım için toplam verinin küçük bir kısmı tahsis edilebilir. Doğrulayıcı düğümler daha güçlü makinelere sahip olduğundan, ağ veri kullanılabilirliğini sağlamak için onlara güvenebilir.

PeerDAS, veri yeniden yapılandırmasını büyük ölçüde kolaylaştırdığı için satır örneklemesi yerine sütun örneklemesi kullanır. Bir düğüm bir satırın tamamını (blobun tamamını) örneklerse, başlangıçta mevcut olmayan ek bir "genişletilmiş blob" oluşturması gerekir ve bu da blok üreticilerini yavaşlatır.

Sütun örnekleme, düğümlerin ek satır verilerini önceden hazırlamasına olanak tanır ve gerekli kanıtlar (blok üreticisi yerine) işlem gönderici tarafından hesaplanır. Bu, blok oluşturmanın hızını ve verimliliğini korur. Örneğin, bir blob'un 4x4'lük bir hücre ızgarası olduğunu varsayalım. Satır örnekleme, bir satırdaki dört hücrenin tamamının alınması anlamına gelir, ancak bazı genişletilmiş satırlar henüz hazır değildir, bu nedenle blok üreticisi bunları anında oluşturmalıdır. Sütun örnekleme ise her satırdan (her sütundan) bir hücre çıkarır ve yeniden yapılandırma için gereken ek hücreler önceden hazırlanabilir, bu da düğümlerin blok oluşturmayı yavaşlatmadan verileri doğrulamasına olanak tanır.

EIP-7594, EIP-4844 ile tamamen uyumludur, bu nedenle Ethereum'daki mevcut işlevlerin hiçbirini bozmaz. Tüm testler ve ayrıntılı kurallar, mutabakat ve uygulama spesifikasyonlarına dahildir.

Herhangi bir DAS sisteminin birincil güvenlik riski, bir blok üreticisinin verilerin erişilebilir olduğunu iddia edip aslında bazı kısımlarını gizlediği "veri gizleme saldırısı"dır . PeerDAS, rastgele örnekleme kullanarak bunu önler: Düğümler verilerin rastgele kısımlarını inceler. Ne kadar çok düğüm örneklenirse, bir saldırganın hile yapması o kadar zorlaşır. EIP-7594, toplam düğüm sayısına (n), toplam örnek sayısına (m) ve düğüm başına örnek sayısına (k) göre böyle bir saldırının başarılı olma olasılığını hesaplamak için bir formül bile sunar. Yaklaşık 10.000 düğüme sahip Ethereum ana ağında, başarılı bir saldırı olasılığı son derece düşüktür, bu nedenle PeerDAS güvenli kabul edilir.

EIP-7823: MODEXP için maksimum boyutu 1024 bayt olarak ayarlar

Bu önerinin gerekliliği, Ethereum'un mevcut MODEXP ön derleme mekanizmasının yıllar içinde çok sayıda mutabakat zafiyetine yol açmış olmasından kaynaklanmaktadır. Bu zafiyetler büyük ölçüde MODEXP'in son derece büyük ve pratik olmayan miktarda girdi verisine izin vermesinden ve istemcileri sayısız istisna ile uğraşmaya zorlamasından kaynaklanmaktadır.

Her düğümün bir işlem tarafından sağlanan tüm girdileri işlemesi gerektiğinden, bir üst sınırın olmaması MODEXP'in test edilmesini zorlaştırır, hatalara daha yatkın hale getirir ve farklı istemcilerde farklı davranma olasılığını artırır. Aşırı büyük girdi verileri, veri hacmi sonsuza dek artabildiğinde fiyatlandırmayı zorlaştırdığından, gaz maliyeti formüllerinin tahmin edilmesini de zorlaştırır. Bu sorunlar ayrıca, sabit kısıtlamalar olmadan geliştiricilerin güvenli ve optimize edilmiş yürütme yolları oluşturamayacakları için, gelecekte MODEXP'in EVMMAX gibi araçlar kullanılarak EVM düzeyinde kodla değiştirilmesini de zorlaştırır.

Bu sorunları azaltmak ve Ethereum'un kararlılığını artırmak için EIP-7823, MODEXP giriş verilerinin miktarına sıkı bir sınır ekleyerek ön derleme sürecini daha güvenli, test edilmesi daha kolay ve daha öngörülebilir hale getiriyor.

EIP-7823 basit bir kural getirir: MODEXP tarafından kullanılan üç uzunluk alanının (taban, üs ve modül) tamamı 8192 bit veya 1024 bayttan küçük veya ona eşit olmalıdır . MODEXP girişi, EIP-198'de tanımlanan biçimi izler: <len(TABAN)> <len(ÜS)> <len(MODULUS)> <TABAN> <ÜS> <MODULUS>, bu nedenle bu EIP yalnızca uzunluk değerlerini kısıtlar. Herhangi bir uzunluk 1024 baytı aşarsa, ön işleme derhal durur, bir hata döndürür ve tüm gazı tüketir.

Örneğin, birisi 2000 baytlık bir taban sağlamaya çalışırsa, herhangi bir çalışma başlamadan önce çağrı başarısız olur. Bu sınırlar yine de tüm pratik uygulama senaryolarını karşılar. RSA doğrulaması genellikle 1024 bit, 2048 bit veya 4096 bit anahtar uzunlukları kullanır ve bunların tümü yeni sınırlar dahilindedir. Eliptik eğri işlemleri genellikle 384 bitten daha küçük giriş boyutları kullanır ve bu nedenle etkilenmez.

Bu yeni sınırlamalar, gelecekteki yükseltmeleri de kolaylaştırıyor. MODEXP, gelecekte EVMMAX kullanılarak EVM kodu olarak yeniden yazılırsa, geliştiriciler yaygın giriş boyutları (256 bit, 381 bit veya 2048 bit gibi) için optimize edilmiş yollar ekleyebilir ve nadir durumlarda daha yavaş geri dönüş şemaları kullanabilirler. Maksimum giriş boyutunu sabitleyerek, geliştiriciler çok yaygın modüller için özel işleme bile ekleyebilirler. Daha önce, giriş boyutu sınırsız olduğu ve aşırı büyük ve güvenli olmayan bir şekilde yönetilebilen bir tasarım alanı ortaya çıktığı için bu mümkün değildi.

Bu değişikliğin geçmiş işlemleri aksatmayacağını doğrulamak için yazarlar, 5.472.266. bloktan (20 Nisan 2018) 21.550.926. bloğa (4 Ocak 2025) kadar tüm MODEXP kullanımını analiz ettiler. Sonuçlar, tarihsel olarak başarılı MODEXP çağrılarının hiçbirinin 513 bayttan fazla girdi kullanmadığını, yani yeni 1024 bayt sınırının oldukça altında olduğunu gösterdi. Gerçek çağrıların çoğu 32 bayt, 128 bayt veya 256 bayt gibi daha kısa uzunluklar kullanmıştır.

Boş girdi, yinelenen baytlarla doldurulmuş girdi ve çok büyük ancak geçersiz girdi gibi bazı geçersiz veya bozuk çağrılar mevcuttur. Bu çağrılar, kendi içlerinde geçersiz oldukları için yeni kısıtlamalar altında da geçersiz davranırlar. Bu nedenle, EIP-7823 önemli bir teknik değişiklik olsa da, geçmiş işlemlerin sonucunu fiilen değiştirmez.

Güvenlik açısından, izin verilen girdi boyutunun azaltılması yeni riskler doğurmaz. Aksine, daha önce istemciler arasında hatalara ve tutarsızlıklara yol açan gereksiz aşırı durumları ortadan kaldırır. MODEXP girdisini makul bir aralıkla sınırlayarak, EIP-7823 sistemi daha öngörülebilir hale getirir, beklenmedik aşırı durumları azaltır ve farklı uygulamalar arasında hata olasılığını düşürür. Bu sınırlamalar ayrıca, gelecekteki yükseltmelerin (EVMMAX gibi) optimize edilmiş yürütme yolları sunması durumunda daha sorunsuz bir geçişe hazırlanmaya yardımcı olur.

EIP-7825: 16,7 milyon Gaz işlem limiti

Ethereum'un bu teklife gerçekten ihtiyacı var, çünkü şu anda tek bir işlem neredeyse bloğun tüm gas limitini tüketebiliyor.

Bu durum çeşitli sorunlara yol açar: tek bir işlem bloğun kaynaklarının çoğunu tüketebilir ve DoS saldırısına benzer yavaş gecikmelere neden olabilir; çok fazla gaz tüketen işlemler Ethereum'un durum güncellemelerini çok hızlı bir şekilde artıracaktır; ve blok doğrulama hızı yavaşlayacak ve düğümlerin ayak uydurmasını zorlaştıracaktır.

Bir kullanıcı, gazın neredeyse tamamını tüketen büyük bir işlem gönderirse (örneğin, 40 milyon gazlık bir blokta 38 milyon gaz tüketen bir işlem), diğer sıradan işlemler bu bloğa dahil edilemez ve her düğüm, bloğu doğrulamak için ekstra zaman harcamak zorunda kalır. Bu durum, ağın istikrarını ve merkeziyetsizliğini tehdit eder, çünkü daha yavaş doğrulama, zayıf düğümlerin geride kalması anlamına gelir. Bu sorunu çözmek için Ethereum'un, tek bir işlemin kullanabileceği gaz miktarını sınırlayacak güvenli bir gaz sınırına ihtiyacı vardır. Bu sayede blok yükü daha öngörülebilir hale gelir, DoS saldırıları riski azalır ve düğümler üzerindeki yük daha dengeli hale gelir.

EIP-7825, katı bir kural getirir: hiçbir işlem 16.777.216 (2²⁴) Gas'tan fazla tüketmemelidir . Bu, protokol düzeyinde bir sınır haline gelir; yani tüm aşamalar için geçerlidir: işlem gönderen kullanıcılar, işlemleri kontrol eden işlem havuzları ve işlemleri bloklara paketleyen doğrulayıcılar. Birisi bu Gas sınırını aşan bir işlem gönderirse, istemci işlemi derhal reddetmeli ve MAX_GAS_LIMIT_EXCEEDED gibi bir hata döndürmelidir.

Bu sınır, blok gaz sınırından tamamen bağımsızdır. Örneğin, blok gaz sınırı 40 milyon olsa bile, herhangi bir tek işlemin gaz tüketimi 16,7 milyonu geçmemelidir. Amaç, tek bir işlemin tüm bloğu kaplamasına izin vermek yerine, her bloğun birden fazla işlemi barındırabilmesini sağlamaktır.

Bunu daha iyi anlamak için, bir bloğun 40 milyon Gaz tutabileceğini varsayalım. Bu sınır olmadan, biri 35 milyon ila 40 milyon Gaz tüketen bir işlem gönderebilir. Bu işlem, tıpkı birinin bir otobüsü kiralayıp başka kimsenin binmesini engellemesi gibi, bloğu tekeline alarak başka işlemlere yer bırakmayacaktır. Yeni 16,7 milyon Gaz sınırı, blokların doğal olarak birden fazla işlemi barındırmasına olanak tanıyarak bu tür suistimallerin önüne geçecektir.

Öneri ayrıca, müşterilerin işlemleri nasıl doğrulayacaklarına dair belirli gereklilikler de ortaya koyuyor. Bir işlemin gas değeri 16.777.216'yı aşarsa, işlem havuzu bunu reddetmeli, yani bu tür işlemler sıraya bile alınmamalıdır. Blok doğrulaması sırasında, bir blok limiti aşan işlemler içeriyorsa, bloğun kendisi reddedilmelidir.

16.777.216 (2²⁴) sayısı, 2'nin net bir sınırını temsil ettiği ve bu sayede uygulanmasını kolaylaştırdığı için seçildi. Ayrıca, akıllı sözleşme dağıtımları, karmaşık DeFi etkileşimleri veya çok adımlı sözleşme çağrıları gibi çoğu gerçek dünya işlemini karşılayacak kadar büyük . Bu değer, tipik blok boyutunun yaklaşık yarısı kadardır; yani en karmaşık işlemler bile bu sınır içinde kolayca tutulabilir.

Bu EIP, mevcut gaz mekanizmalarıyla uyumluluğunu da korur. Çoğu kullanıcı bu değişikliği fark etmeyecektir çünkü mevcut işlemlerin neredeyse tamamı 16 milyonun altında gaz tüketmektedir. Doğrulayıcılar ve blok oluşturucular, her işlem yeni sınıra uyduğu sürece, toplam gaz miktarı 16,7 milyonu aşan bloklar oluşturmaya devam edebilirler.

Etkilenen tek işlemler, daha önce yeni limitleri aşmaya çalışıp aşırı büyük boyutlara ulaşan işlemlerdir. Bu işlemler artık, çok büyük bir dosya yüklemesini iki küçük dosyaya bölmeye benzer şekilde, birden fazla küçük işleme bölünmelidir. Teknik olarak, bu değişiklik bu nadir ve aşırı işlemlerle geriye dönük uyumlu değildir, ancak etkilenen kullanıcı sayısının çok düşük olması beklenmektedir.

Güvenlik açısından, gaz sınırı, Ethereum'u gaz tabanlı DoS saldırılarına karşı daha dirençli hale getirir, çünkü saldırganlar artık doğrulayıcıları aşırı büyük işlemleri işlemeye zorlayamaz . Ayrıca, blok doğrulama sürelerinin öngörülebilirliğini koruyarak düğümlerin senkronize kalmasını kolaylaştırır. En uç durum, birkaç çok büyük sözleşme dağıtımının sınır gereksinimlerini karşılayamaması ve yeniden tasarım veya birden fazla dağıtım adımına bölünmesini gerektirmesidir.

Genel olarak EIP-7825, ağ korumasını kötüye kullanıma karşı güçlendirmeyi, makul düğüm talebini sürdürmeyi, blok alanı kullanımının adilliğini iyileştirmeyi ve gaz sınırı arttıkça blok zincirinin hızlı ve istikrarlı bir şekilde çalışmaya devam etmesini sağlamayı amaçlamaktadır.

EIP-7883: ModExp Gaz Oranları Artıyor

Ethereum'un bu teklife ihtiyacı var çünkü önceden derlenmiş ModExp'in (modüler üs alma için kullanılır) fiyatı, gerçekte tükettiği kaynaklara kıyasla sürekli olarak düşük olmuştur.

Bazı durumlarda, bir ModExp işleminin hesaplama gereksinimleri, kullanıcıların şu anda ödediği ücretlerin çok ötesine geçer. Bu uyumsuzluk bir risk oluşturur: Karmaşık ModExp çağrıları çok düşük fiyatlandırılırsa, darboğazlara dönüşebilir ve ağın gaz limitlerini güvenli bir şekilde artırmasını zorlaştırabilir. Bunun nedeni, blok üreticilerinin çok düşük maliyetlerle son derece ağır işlemleri yönetmek zorunda kalabilmesidir.

Bu sorunu çözmek için Ethereum, ModExp fiyatlandırma formülünü, gaz tüketiminin istemci tarafından gerçekleştirilen iş miktarını doğru bir şekilde yansıtacak şekilde ayarlamalıydı. Bu nedenle, EIP-7883, minimum gaz maliyetini ve toplam gaz maliyetini artıran ve büyük girdi veri hacimlerine sahip işlemleri (özellikle 32 baytı aşan üs alma, taban veya modül işlemleri) daha pahalı hale getiren yeni kurallar getirdi ve böylece gaz fiyatlandırmasını gerçek hesaplama talepleriyle eşleştirdi.

Öneri, maliyetleri birkaç önemli yoldan artırıyor ve dolayısıyla EIP-2565'te başlangıçta tanımlanan ModExp fiyatlandırma algoritmasını değiştiriyor.

Öncelikle, minimum gaz tüketimi 200'den 500'e çıkarıldı ve toplam gaz tüketimi artık 3'e bölünmüyor, yani toplam gaz tüketimi fiilen üç katına çıktı. Örneğin, bir ModExp çağrısı daha önce 1200 gaz tüketiyorsa, yeni formüle göre artık yaklaşık 3600 gaz tüketecek.

İkinci olarak, çarpan 8'den 16'ya çıktığı için 32 bayttan uzun üsler için hesaplama maliyeti iki katına çıkar. Örneğin, üs uzunluğu 40 baytsa, EIP-2565 yineleme sayısını 8 × (40 − 32) = 64 artırırken, EIP-7883 artık 16 × (40 − 32) = 128 kullanır ve maliyeti iki katına çıkarır.

Üçüncüsü, fiyatlandırma artık minimum 32 baytlık bir taban/modül boyutu varsayıyor ve bu değerler 32 baytı aştıkça hesaplama maliyetleri önemli ölçüde artıyor. Örneğin, modül 64 baytsa, yeni kural önceki daha basit formül yerine iki kat karmaşıklık (2 × kelime²) uygulayarak büyük sayı işlemlerinin gerçek maliyetini yansıtıyor. Bu değişiklikler toplu olarak, küçük ModExp işlemlerinin makul bir minimum ücret ödemesini ve büyük, karmaşık işlemlerin maliyetinin boyutlarına göre uygun şekilde ayarlanmasını sağlıyor.

Bu öneri, yeni bir Gas hesaplama fonksiyonu tanımlıyor ve karmaşıklık ve yineleme sayısı kurallarını güncelliyor. Çarpma karmaşıklığı artık 32 bayt veya daha az taban/modül uzunlukları için varsayılan 16 değerini kullanırken, daha büyük girdiler için daha karmaşık bir formül olan 2 × words²'ye geçiyor; burada "words", 8 baytlık blok sayısını ifade ediyor. Yineleme sayısı da güncellendi, böylece 32 bayt veya daha az üsler karmaşıklığı belirlemek için bit uzunluklarını kullanırken, 32 bayttan büyük üsler daha büyük bir Gas cezasına maruz kalıyor.

Bu, hesaplama açısından maliyetli olan çok büyük üslerin artık daha yüksek gaz maliyetlerine sahip olmasını sağlar. Daha da önemlisi, minimum geri dönen gaz maliyeti artık önceki 200 yerine 500'e düşürülüyor ve bu da en basit ModExp çağrısını bile daha makul hale getiriyor.

Bu fiyat artışları, ModExp önceden derlenmiş fiyatlandırmasının birçok durumda önemli ölçüde düşük değerlendirildiğini gösteren kıyaslama testlerinden kaynaklanmaktadır. Gözden geçirilmiş formül, gaz maliyetlerini küçük operasyonlar için %150, tipik operasyonlar için yaklaşık %200 ve büyük veya dengesiz operasyonlar için üs, taban veya modülün boyutuna bağlı olarak bazen 80 katı aşan oranlarda, birçok kat daha fazla artırmaktadır.

Bu hamlenin amacı ModExp'in çalışma şeklini değiştirmek değil, aşırı kaynak yoğun koşullar altında bile ağ istikrarını tehdit etmemesini veya blok gas sınırındaki gelecekteki artışları engellememesini sağlamaktır. EIP-7883, ModExp için gereken gas miktarını değiştirdiği için geriye dönük uyumlu değildir, ancak Ethereum'da gas fiyatlandırması birçok kez gerçekleşmiştir ve iyi bilinmektedir.

Test sonuçları, gaz maliyetlerindeki artışın oldukça önemli olduğunu gösteriyor. Geçmişteki ModExp çağrılarının yaklaşık %99,69'u artık 500 Gaz (önceden 200 Gaz) veya önceki fiyatın üç katı gerektiriyor. Ancak, gaz maliyetindeki artış bazı yüksek yük testlerinde daha da fazla. Örneğin, "üstel hesaplama yoğunluklu" bir testte, gaz tüketimi 215'ten 16.624'e fırladı; bu da yaklaşık 76 katlık bir artışa denk geliyor, çünkü aşırı büyük üsler için fiyatlandırma artık daha makul.

Güvenlik açısından, bu öneri yeni saldırı vektörleri getirmez veya herhangi bir hesaplamanın maliyetini düşürmez. Bunun yerine, önemli bir riski azaltmaya odaklanır: Aşırı düşük fiyatlı ModExp işlemleri, saldırganların blokları çok düşük maliyetle aşırı yoğun hesaplamalarla doldurmasına olanak tanıyabilir. Tek olası dezavantaj, bazı ModExp işlemlerinin çok pahalı hale gelebilmesidir, ancak bu, mevcut aşırı düşük fiyatlandırma sorunundan çok daha iyidir. Öneri herhangi bir arayüz değişikliği veya yeni özellik getirmediğinden, mevcut aritmetik davranış ve test vektörleri geçerliliğini korur.

EIP-7917: Bir Sonraki Teklif Sahibinin Doğru Tahmini

Ethereum'un bu teklife ihtiyacı var çünkü ağın bir sonraki dönemi için teklif sahiplerinin takvimi tam olarak tahmin edilemiyor. N+1. dönem için RANDAO tohumu N. dönemde bilinse bile, N. dönemdeki etkin bakiye (EB) güncellemeleri nedeniyle gerçek teklif sahiplerinin listesi yine de değişebilir.

Bu EB değişiklikleri, kesintilerden, cezalardan, 1 ETH'yi aşan ödüllerden, doğrulayıcı konsolidasyonundan veya özellikle EIP-7251'in maksimum etkin bakiyeyi 32 ETH'nin üzerine çıkarmasından sonra gelen yeni yatırımlardan kaynaklanabilir. Bu belirsizlik, bir sonraki teklif sahibini önceden bilmeye dayanan (önceden onaylanmış protokoller gibi) ve sorunsuz çalışması için istikrarlı ve öngörülebilir zaman çizelgelerine ihtiyaç duyan sistemler için bir sorun teşkil eder. Doğrulayıcılar, bir sonraki dönemin teklif sahibini etkilemek için etkin bakiyelerini "pompalamayı" veya manipüle etmeyi bile deneyebilirler.

Bu sorunlar nedeniyle Ethereum'un, teklif verenin zaman çizelgesini önümüzdeki birkaç dönem için tamamen kesin hale getirmenin bir yoluna ihtiyacı var; böylece son dakika EB güncellemeleri nedeniyle değişmeyecek ve uygulama katmanı tarafından kolayca erişilebilir olacak.

Bunu başarmak için EIP-7917, her dönemin başında bir sonraki MIN_SEED_LOOKAHEAD + 1 dönemi için öneren zamanlamasını önceden hesaplayan ve depolayan kesin bir öneren ileriye dönük mekanizması sunar . Basitçe söylemek gerekirse, işaret durumu artık her zaman iki tam döngü (toplam 64 yuva) için önerenleri kapsayan `prosoperer_lookahead` adlı bir liste içerir.

Örneğin, N dönemi başladığında, liste N dönemi ve N+1 dönemindeki her bir yuva için teklif verenleri zaten içerir. Ardından, ağ N+1 dönemine girdiğinde, liste ileri kaydırılır: N dönemi için teklif veren girişi kaldırılır, N+1 dönemi için giriş listenin başına taşınır ve listenin sonuna N+2 dönemi için yeni bir teklif veren girişi eklenir. Bu, zamanlamayı sabit ve öngörülebilir hale getirir ve istemciler, her yuva için teklif verenleri yeniden hesaplamadan doğrudan okuyabilir.

Listeyi güncel tutmak için her dönem sınırında ilerler: önceki dönemden veriler kaldırılır ve bir sonraki dönem için yeni bir teklifçi endeksi kümesi hesaplanarak listeye eklenir. Bu işlem, öncekiyle aynı başlangıç ​​ve etkin denge kurallarını kullanır, ancak zamanlama artık daha erken hesaplanır ve böylece başlangıç ​​belirlendikten sonra etkin denge değişikliklerinin etkisi önlenir. Çatallanmadan sonraki ilk blok, tüm gelecek dönemlerin zamanlamasının doğru şekilde başlatıldığından emin olmak için tüm ileriye dönük aralığı da doldurur.

Basitlik açısından, her dönem için 32 yerine 8 yuva olduğunu varsayalım. Bu EIP olmadan, 5. dönem boyunca, 6. dönemin tohumunu bilseniz bile, 6. dönemdeki 2. yuva için gerçek teklif sahibi, bir doğrulayıcı cezalandırılırsa veya 5. dönemde etkin bakiyesini değiştirecek kadar ödül alırsa yine de değişebilir. EIP-7917 ile Ethereum, 5. dönemin başında 5., 6. ve 7. dönemler için tüm teklif sahiplerini önceden hesaplar ve bunları sırayla `prosopers_lookahead` içinde depolar. Bu nedenle, bakiye 5. dönemin ilerleyen dönemlerinde değişse bile, 6. dönemin teklif sahiplerinin listesi sabit ve öngörülebilir kalır.

EIP-7917, Beacon Zinciri tasarımında uzun süredir devam eden bir kusuru giderir. Önceki bir dönemin RANDAO'su mevcut olduğunda, gelecek dönemler için doğrulayıcı seçiminin değiştirilemeyeceğini garanti eder. Bu ayrıca, doğrulayıcıların bir sonraki dönemin teklif listesini etkilemek için RANDAO'yu gördükten sonra bakiyelerini ayarlamaya çalıştığı "etkili bakiye karıştırma"yı da önler. Bu deterministik ileriye dönük mekanizma, tüm saldırı vektörünü ortadan kaldırarak güvenlik analizini önemli ölçüde basitleştirir. Ayrıca, fikir birliği istemcilerinin yaklaşan blokları kimin önereceğini önceden bilmesini sağlayarak uygulamayı kolaylaştırır ve uygulama katmanlarının, işaret köküne ait Merkle kanıtları aracılığıyla teklifçi programlarını kolayca doğrulamasına olanak tanır.

Bu tekliften önce, müşteriler yalnızca geçerli zaman aralığı için teklif verenleri hesaplıyordu. EIP-7917 ile artık, her dönem geçişinde bir sonraki dönemin tüm zaman aralıkları için teklif verenlerin listesini tek seferde hesaplıyorlar. Bu, az miktarda iş yükü getirse de, teklif veren endeksinin hesaplanması oldukça basit bir işlemdir ve çoğunlukla doğrulayıcı listesinin bir başlangıç noktası kullanılarak örneklenmesini gerektirir. Ancak, müşterilerin bu ek hesaplamanın performans sorunlarına yol açmamasını sağlamak için kıyaslama yapmaları gerekir.

EIP-7918: Blob taban ücretleri yürütme maliyetleriyle sınırlıdır.

Ethereum'un bu teklife ihtiyacı var çünkü mevcut Blob ücret sistemi (EIP-4844'ten türetilmiştir) gazın çevrimin ana maliyeti haline gelmesiyle başarısız oluyor.

Şu anda, çoğu Rollup tarafından ödenen yürütme gazı (bir Blob işlemini bir bloğa dahil etmenin maliyeti), gerçek Blob ücretinden çok daha yüksek. Bu bir sorun yaratıyor: Ethereum temel Blob ücretini sürekli olarak düşürse bile, bir Rollup'ın toplam maliyeti aslında değişmiyor çünkü en yüksek maliyet yürütme gazı olarak kalıyor. Bu nedenle, temel Blob ücreti mutlak bir minimuma (1 wei) ulaşana kadar azalmaya devam edecek ve bu noktada protokol artık talebi kontrol etmek için Blob ücretlerini kullanamayacak. Ardından, Blob kullanımı aniden arttığında, Blob ücretinin normal seviyelere ulaşması birçok blok alıyor. Bu durum, fiyatları kullanıcılar için istikrarsız ve öngörülemez hale getiriyor.

Örneğin, bir Rollup'ın verilerini yayınlamak istediğini varsayalım: yürütme gazı olarak yaklaşık 25.000.000 gwei ödemesi gerekiyor (yaklaşık 1.000.000 gaz 25 gwei gerektirir), ancak Blob ücreti yalnızca yaklaşık 200 gwei. Bu, toplam maliyetin yaklaşık 25.000.200 gwei olduğu ve maliyetin neredeyse tamamının Blob ücretinden değil, yürütme gazından kaynaklandığı anlamına gelir. Ethereum, Blob ücretini örneğin 200 gwei'den 50 gwei'ye, ardından 10 gwei'ye ve son olarak 1 gwei'ye düşürmeye devam ederse, toplam maliyet neredeyse hiç değişmeyecek ve 25.000.000 gwei'de kalacaktır.

EIP-7918, yürütme temel maliyetlerine dayalı bir asgari "rezervasyon fiyatı" sunarak bu sorunu ele alıyor ve böylece Blob fiyatlarının çok düşük olmasını engelliyor ve Rollup'un Blob fiyatlandırmasını daha istikrarlı ve öngörülebilir hale getiriyor.

EIP-7918'in temel fikri basittir: Bir blob'un fiyatı, belirli bir yürütme gazı maliyetinden (BLOB_BASE_COST olarak adlandırılır) asla düşük olmamalıdır . calc_excess_blob_gas() fonksiyonu 2¹³ olarak ayarlanır ve bu mekanizma, calc_excess_blob_gas() fonksiyonunda küçük bir değişiklik yapılarak uygulanır.

Genellikle bu işlev, blok tarafından kullanılan blob gazının hedef değerin üstünde veya altında olmasına bağlı olarak Blob taban ücretini artırır veya azaltır. Bu öneriye göre, blob yürütme gazına göre "çok düşük" hale gelirse, işlev hedef blob gazını çıkarmayı durduracaktır. Bu, fazla blob gazının daha hızlı artmasını sağlayarak Blob taban ücretinin daha fazla azalmasını önler. Dolayısıyla, Blob taban ücreti artık BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB değerine eşit bir minimum değere sahiptir.

Bunun neden gerekli olduğunu anlamak için, blob talebine bakalım. Toplamalar, ödedikleri toplam maliyete odaklanır: yürütme maliyeti artı blob maliyeti. Yürütme gazı maliyeti çok yüksekse, örneğin 20 gwei ise, blob maliyeti 2 gwei'den 0,2 gwei'ye düşse bile, toplam maliyet neredeyse hiç değişmez. Bu, bir blob'un temel maliyetini düşürmenin talep üzerinde neredeyse hiçbir etkisi olmadığı anlamına gelir. Ekonomide buna "maliyet esnekliği" denir. Bu durum, talep eğrisinin neredeyse dikey olduğu bir durum yaratır: fiyatı düşürmek talebi artırmaz.

Bu senaryoda, Blob taban ücreti mekanizması körelir; talep yanıt vermese bile fiyatı düşürmeye devam eder. Bu nedenle blob taban ücreti genellikle 1 gwei'ye düşer. Daha sonra, gerçek talep arttığında, protokolün ücreti makul bir seviyeye çıkarmak için bir saat veya daha uzun süre neredeyse dolu bloklara ihtiyacı vardır. EIP-7918, yürütme gazına bağlı bir rezerv fiyatı oluşturarak bu sorunu çözer ve yürütme maliyetleri baskın olsa bile Blob ücretinin anlamlı kalmasını sağlar.

Bu rezervasyon fiyatının eklenmesinin bir diğer nedeni de, düğümlerin blob verilerinin KZG kanıtlarını doğrulamak için çok fazla ek iş yapması gerekmesidir. Bu kanıtlar, blob'daki verilerin vaat ettikleriyle uyuştuğunu garanti eder. EIP-4844 kapsamında, düğümlerin her blob için yalnızca bir kanıtı doğrulaması yeterlidir ve bu da uygun maliyetlidir. Ancak EIP-7918 kapsamında, düğümlerin çok daha fazla sayıda kanıtı doğrulaması gerekir. Bunun nedeni tamamen EIP-7594'te (PeerDAS), blob'ların her biri kendi kanıtına sahip hücre adı verilen birçok küçük parçaya bölünmesi ve bu durumun doğrulama iş yükünü önemli ölçüde artırmasıdır.

Uzun vadede, EIP-7918, Ethereum'un geleceğe hazırlanmasına da yardımcı oluyor. Teknoloji ilerledikçe, veri depolama ve paylaşım maliyeti doğal olarak azalacak ve Ethereum'un zamanla daha fazla Blob verisinin depolanmasına olanak sağlaması bekleniyor. Blob kapasitesi arttıkça, Blob ücretleri (ETH cinsinden) doğal olarak azalacaktır. Bu öneri, tutma fiyatının sabit bir değer yerine yürütme gazı fiyatına sabitlenmesi ve böylece ağ büyüdükçe ayarlanabilmesi nedeniyle bunu destekliyor.

Blob alanı ve yürütme blok alanı genişledikçe, fiyat ilişkileri dengeli kalacaktır. Yalnızca nadir durumlarda, Ethereum'un yürütme gaz kapasitesini artırmadan Blob kapasitesini önemli ölçüde artırdığı durumlarda, rezerv fiyatı aşırı yüksek olabilir. Böyle bir senaryoda, Blob ücretleri nihayetinde gerçek ihtiyaçları aşabilir. Ancak Ethereum'un bu şekilde genişleme planı yoktur; Blob alanı ve yürütme blok alanının birlikte büyümesi beklenmektedir. Bu nedenle, seçilen değer (BLOB_BASE_COST = 2¹³) güvenli ve dengeli kabul edilir.

Yürütme gazı ücretleri aniden yükseldiğinde, dikkat edilmesi gereken küçük bir ayrıntı vardır. Bir blob'un fiyatı temel yürütme maliyetine bağlı olduğundan, yürütme maliyetlerindeki ani bir artış, blob ücretini geçici olarak yürütme maliyetlerinin hakim olduğu bir duruma sokabilir. Örneğin, yürütme gazı ücretinin bir blok içinde aniden 20 gwei'den 60 gwei'ye yükseldiğini varsayalım. Bir blob'un fiyatı bu değere sabitlendiğinden, blob ücreti yeni ve daha yüksek seviyenin altına düşemez. Blob hala kullanılıyorsa, ücreti normal şekilde artmaya devam eder, ancak protokol, daha yüksek yürütme maliyetlerini karşılayacak kadar artana kadar düşmesine izin vermez. Bu, birkaç blok içinde blob ücretinin yürütme maliyetinden daha yavaş artabileceği anlamına gelir. Bu geçici gecikme zararsızdır; aslında blob fiyatındaki ani dalgalanmaları önler ve sistemi daha sorunsuz hale getirir.

Yazarlar ayrıca, Kasım 2024'ten Mart 2025'e kadar gerçek blok işlem aktivitesinin rezerv fiyat kuralını uygulayarak ampirik bir analizini gerçekleştirdiler. Yüksek işlem ücreti dönemlerinde (ortalama yaklaşık 16 gwei), rezerv eşiği, temel blok ücretini eski mekanizmaya kıyasla önemli ölçüde artırdı. Düşük işlem ücreti dönemlerinde (ortalama yaklaşık 1,3 gwei), hesaplanan temel blok ücreti rezerv fiyatından düşük olmadığı sürece blok ücretleri neredeyse sabit kaldı. Yazarlar binlerce bloğu karşılaştırarak, yeni mekanizmanın talebe doğal bir tepki verirken daha istikrarlı bir fiyatlandırma yarattığını göstermektedir. Dört aylık blok ücreti histogramı, rezerv fiyatının blok ücretlerinin 1 gwei'ye düşmesini engellediğini ve böylece aşırı oynaklığı azalttığını göstermektedir.

Güvenlik açısından bu değişiklik herhangi bir risk oluşturmaz. Temel blok ücreti, gaz yürütmenin BLOB_BASE_COST birim maliyetine her zaman eşit veya daha yüksek olacaktır. Bu güvenlidir çünkü mekanizma yalnızca minimum ücreti artırır ve taban fiyat belirlemek protokolün doğruluğunu etkilemez. Sadece sağlıklı bir ekonomik işleyişi garanti eder.

EIP-7934: RLP, blok boyutu sınırlarını uygular

EIP-7934 öncesinde, Ethereum'un RLP ile kodlanmış yürütme bloklarının boyutu konusunda katı bir üst sınırı yoktu. Teorik olarak, bir blok çok sayıda işlem veya çok karmaşık veriler içeriyorsa, boyutu aşırı büyük olabilirdi. Bu durum iki temel soruna yol açıyordu: ağ istikrarsızlığı ve hizmet reddi (DoS) saldırıları riski.

Bir blok çok büyükse, düğümlerin onu indirip doğrulaması daha uzun sürecek, bu da blok yayılımını yavaşlatacak ve geçici blok zinciri çatallanmalarının olasılığını artıracaktır. Daha da kötüsü, bir saldırgan düğümleri aşırı yüklemek için kasıtlı olarak son derece büyük bir blok oluşturabilir, bu da gecikmelere ve hatta çevrimdışı kalmalarına neden olabilir; bu da klasik bir hizmet reddi saldırısıdır. Dahası, Ethereum'un konsensüs katmanı (CL) Gossip protokolü zaten 10 MB'tan büyük herhangi bir bloğu yaymayı reddediyor; bu da aşırı büyük yürütme bloklarının ağda yayılamayacağı ve zincir içi parçalanmaya veya düğümler arasında anlaşmazlıklara neden olabileceği anlamına geliyor. Bu riskler göz önüne alındığında, Ethereum'un aşırı büyük blokları önlemek ve ağ istikrarını ve güvenliğini sağlamak için net bir protokol düzeyinde kurala ihtiyacı vardır.

EIP-7934, blok boyutu sınırını zorunlu kılmak için protokol düzeyinde bir RLP kodlaması sunarak bu sorunu çözer. İzin verilen maksimum blok boyutu (MAX_BLOCK_SIZE) 10 MiB (10.485.760 bayt) olarak belirlenmiştir, ancak Ethereum, işaret blokları da bir miktar yer kapladığı için (SAFETY_MARGIN) bu sınıra 2 MiB (2.097.152 bayt) ekler.

Bu, izin verilen maksimum RLP kodlanmış blok boyutunun MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN olduğu anlamına gelir. Kodlanmış blok bu sınırı aşarsa geçersiz sayılır ve düğüm tarafından reddedilir. Bu kuralla, blok üreticileri oluşturdukları her bloğun kodlanmış boyutunu kontrol etmeli ve doğrulayıcılar blok doğrulaması sırasında bu sınırı doğrulamalıdır. Bu boyut sınırı, gaz sınırından bağımsızdır; yani bir blok "gaz sınırının altında" olsa bile, kodlanmış boyutu çok büyükse yine de reddedilecektir. Bu, hem gaz kullanımı hem de gerçek bayt boyutu sınırlarına uyulmasını sağlar.

10 MiB'lık bir sınır değeri seçimi, konsensüs katmanının dedikodu protokolündeki mevcut sınırlarla uyumlu olduğu için kasıtlıdır . 10 MiB'dan büyük veriler ağ üzerinden yayınlanmayacaktır, bu nedenle bu EIP, yürütme katmanının konsensüs katmanının sınırlarıyla tutarlı kalmasını sağlar. Bu, tüm bileşenler arasında tutarlılığı sağlar ve CL'nin yayılmayı reddetmesi nedeniyle geçerli yürütülen blokların "görünmez" hale gelmesini önler.

Bu değişiklik, yeni sınırdan daha büyük bloklarla geriye dönük uyumlu değildir; bu da madencilerin ve doğrulayıcıların kurala uymak için istemcilerini güncellemeleri gerektiği anlamına gelir. Ancak, büyük bloklar doğası gereği sorunlu olduğundan ve pratikte yaygın olmadığından, etkisi minimumdur.

Güvenlik açısından EIP-7934, hiçbir katılımcının ağı çökertecek bloklar oluşturmasını engelleyerek Ethereum'un belirli blok boyutlarını hedef alan DoS saldırılarına karşı koyma yeteneğini önemli ölçüde artırır . Özetle, EIP-7934 önemli bir güvenlik sınırı ekler, kararlılığı artırır, Yürütme Mantığı (EL) ve CL'nin davranışını standartlaştırır ve aşırı büyük blokların oluşturulması ve yayılmasıyla ilgili çeşitli saldırıları önler.

EIP-7939: Öndeki Sıfırları Hesapla (CLZ) İşlem Kodu

Bu EIP'den önce, Ethereum'da 256 bitlik bir sayıdaki baştaki sıfır sayısını hesaplamak için yerleşik işlem kodları bulunmuyordu. Geliştiricilerin, çok sayıda bitsel işlem ve karşılaştırma gerektiren CLZ işlevini Solidity kullanarak manuel olarak uygulamaları gerekiyordu.

Bu önemli bir sorundur çünkü özel uygulamalar yavaş, maliyetlidir ve büyük miktarda bayt kodu tüketerek Gaz tüketimini artırır. Sıfır bilgi kanıtlı sistemler için maliyet daha da yüksektir; sağa kaydırma işlemlerinin kanıt maliyeti son derece yüksektir, bu nedenle CLZ gibi işlemler sıfır bilgi kanıtlı devreleri önemli ölçüde yavaşlatır. CLZ, matematik kütüphanelerinde, sıkıştırma algoritmalarında, bit eşlemlerinde, imza şemalarında ve birçok kriptografik veya veri işleme görevinde yaygın olarak kullanılan çok yaygın bir düşük seviyeli fonksiyon olduğundan, Ethereum'un daha hızlı ve daha ekonomik bir hesaplama yöntemine ihtiyacı vardır.

EIP-7939, CLZ (0x1e) adlı yeni bir işlem kodu sunarak bu sorunu çözer. Bu işlem kodu, yığından 256 bitlik bir değer okur ve baştaki sıfır sayısını döndürür. Giriş sayısı sıfırsa, işlem kodu 256 değerini döndürür çünkü 256 bitlik bir sıfırın başında 256 sıfır bulunur .

Bu, CLZ işlemlerinin yerel olarak desteklendiği ARM ve x86 gibi birçok CPU mimarisinde CLZ'nin çalışma şekliyle tutarlıdır. CLZ eklemek, birçok algoritmanın ek yükünü önemli ölçüde azaltabilir: lnWad, powWad, LambertW gibi işlemler, çeşitli matematiksel fonksiyonlar, bayt dizisi karşılaştırmaları, bitmap taramaları, veri sıkıştırma/sıkıştırmayı açma çağrıları ve kuantum sonrası imza şemaları, daha hızlı sıfır-önceden algılamadan faydalanabilir.

CLZ'nin gaz maliyeti, düşük fiyatlandırma nedeniyle hizmet reddi (DoS) saldırıları riskini önlemek için ADD ile benzer şekilde 5 olarak ve önceki MUL fiyatından biraz daha yüksek olarak belirlenmiştir. Karşılaştırmalar, CLZ'nin hesaplama maliyetinin ADD ile hemen hemen aynı olduğunu ve SP1 rv32im kanıt ortamında CLZ'nin kanıt maliyetinin ADD'den daha düşük olduğunu, dolayısıyla sıfır bilgi kanıtlarının maliyetini düşürdüğünü göstermektedir.

EIP-7939, yeni bir işlem kodu sunduğu ve mevcut davranışları değiştirmediği için tamamen geriye dönük uyumludur.

Genel olarak, EIP-7939, modern CPU'lar tarafından zaten desteklenen basit ve etkili bir ilkel ekleyerek Ethereum'u daha hızlı, daha ucuz ve geliştirici dostu hale getiriyor; gaz ücretlerini düşürüyor, bayt kodu boyutunu küçültüyor ve birçok yaygın işlem için sıfır bilgi kanıtlarının maliyetini düşürüyor.

EIP-7951: Modern donanımlar için imzaları destekler.

Bu EIP'den önce Ethereum, secp256r1 (P-256) eğrisi kullanılarak oluşturulan dijital imzaları doğrulamanın güvenli ve yerel bir yolundan yoksundu.

Bu eğri, Apple Secure Enclave, Android Keystore, HSM, TEE ve FIDO2/WebAuthn güvenlik anahtarları gibi modern cihazlar tarafından kullanılan standarttır. Bu destek olmadan, uygulamalar ve cüzdanlar cihaz düzeyinde donanım güvenliği kullanarak kolayca imza oluşturamaz. Önceki bir denemede (RIP-7212), sonsuz nokta işleme ve hatalı imza karşılaştırmalarıyla ilgili iki ciddi güvenlik açığı vardı. Bu sorunlar, doğrulama hatalarına ve hatta fikir birliği başarısızlıklarına yol açabilirdi. EIP-7951, bu güvenlik sorunlarını ele alır ve güvenli, yerel, önceden derlenmiş bir protokol sunarak Ethereum'un modern donanımlardan gelen imzaları güvenli ve verimli bir şekilde desteklemesini sağlar.

EIP-7951, 0x100 adresine P256VERIFY adlı yeni bir önceden derlenmiş sözleşme ekler ve bu sözleşme, secp256r1 eğrisini kullanarak ECDSA imza doğrulaması gerçekleştirir. Bu, imza doğrulamasını algoritmayı doğrudan Solidity'de uygulamaya kıyasla daha hızlı ve daha ucuz hale getirir.

EIP-7951 ayrıca katı giriş doğrulama kuralları da tanımlar. Herhangi bir geçersiz durum varsa, ön derleme geri alma işlemi yapmadan başarısızlığı döndürür ve başarılı bir çağrıyla aynı gazı tüketir. Doğrulama algoritması standart ECDSA algoritmasını izler: s⁻¹ mod n'yi hesaplar, R' imza noktasını yeniden oluşturur, R' sonsuzdaysa reddeder ve son olarak R'nin x koordinatının r (mod n) ile eşleşip eşleşmediğini kontrol eder. Bu, r'yi önce modül n'e göre basitleştirmek yerine doğrudan karşılaştıran RIP-7212'deki bir hatayı düzeltir.

Bu işlem için gaz ücreti, RIP-7212 sürümünden daha yüksek olan 6900 gaz olarak belirlenmiştir, ancak secp256r1 tarafından doğrulanan gerçek performans kıyaslamasıyla tutarlıdır. Daha da önemlisi, bu arayüz, RIP-7212'yi (aynı adres, aynı giriş/çıkış biçimi) zaten dağıtmış olan 2. Katman ağlarıyla tamamen uyumludur, bu nedenle mevcut akıllı sözleşmeler herhangi bir değişiklik olmadan normal şekilde çalışmaya devam edecektir. Tek fark, revize edilmiş davranış ve daha yüksek gaz ücretidir.

Güvenlik açısından bakıldığında, EIP-7951, ECDSA'nın doğru davranışını geri kazandırır, önceden derlenmiş düzeydeki esneklik sorunlarını ortadan kaldırır (isteğe bağlı kontrolleri uygulamaya bırakır) ve ön derlemenin sabit zamanlı yürütme gerektirmediğini açıkça belirtir. secp256r1 eğrisi 128 bit güvenlik sağlar ve yaygın bir güven ve analiz kazanarak Ethereum'da kullanımını güvenli hale getirir.

Kısacası, EIP-7951, Ethereum'a modern donanım destekli kimlik doğrulamayı güvenli bir şekilde getirmeyi, önceki tekliflerdeki güvenlik sorunlarını düzeltmeyi ve ekosistem genelinde P-256 imzalarını doğrulamak için güvenilir ve standartlaştırılmış bir yol sağlamayı amaçlıyor.

Özetle

Aşağıdaki tablo, farklı Fusaka EIP'leri için hangi Ethereum istemcilerinin değişiklik gerektirdiğini özetlemektedir. "Konsensüs İstemcisi" altındaki onay işareti, EIP'nin konsensüs katmanı istemcisini güncellemesi gerektiğini, "Yürütme İstemcisi" altındaki onay işareti ise yükseltmenin yürütme katmanı istemcisini etkilediğini gösterir. Bazı EIP'ler hem konsensüs hem de yürütme katmanlarında güncelleme gerektirirken, diğerleri yalnızca bunlardan birinde güncelleme gerektirir.

Özetle, Fusaka hard fork'una dahil edilen temel EIP'ler şunlardır. Bu yükseltme, gaz ayarlamalarından ve işlem kodu güncellemelerinden yeni önceden derlenmiş sürümlere kadar fikir birliği ve yürütme istemcilerinde çeşitli iyileştirmeler içerse de, bu yükseltmenin özü, ağ genelinde Blob verilerinin daha verimli ve merkezi olmayan bir şekilde işlenmesini sağlayan eşler arası veri kullanılabilirliği örneklemesini sunan PeerDAS'tır.

Orijinal bağlantı

BlockBeats Resmi Topluluğuna Katılın:

Telegram Abonelik Grubu: https://t.me/theblockbeats

Telegram Sohbet Grubu: https://t.me/BlockBeats_App

Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia