Ethereum geliştiricileri, gas hesabındaki değişikliklerin mevcut akıllı sözleşmelere etkisini incelemek için Hoodi testini erteledi. Düğüm işletmecilerinin 26 Ekim’den önce yazılımlarını güncellemesi gerekiyor.
Ethereum geliştiricileri, 26 Ekim 2026’da Hoodi test ağında devreye girmesi planlanan Glamsterdam yükseltmesini erteledi. Ethereum Vakfının 22 Ekim duyurusuna göre ekipler, EIP-8037’nin gas hesabını değiştirmesi halinde mevcut ana ağ akıllı sözleşmelerinin nasıl çalışacağını inceliyor. Yeni test tarihi belirlenmedi; Hoodi düğümlerini çalıştıranların eski etkinleştirme ayarlarını kaldıran yazılım sürümlerine geçmesi gerekiyor.
Karar, 22 Ekim’deki 248’inci All Core Devs Execution toplantısında alındı. Hoodi için daha önce 26 Ekim saat 17.42.48 UTC, Türkiye saatiyle 20.42.48 ve 132.352 numaralı epoch belirlenmişti. Epoch, doğrulayıcıların görevlerinin düzenlendiği zaman dilimi. Erteleme, o tarihte devreye girecek 200 milyon gas blok sınırı artışını da kapsıyor.
Hoodi’deki ayarlar kaldırıldı, ana ağ tarihi yok
Hoodi deposunda 22 Ekim’de birleştirilen değişiklik, yürütme katmanındaki Amsterdam zamanını, mutabakat katmanındaki Gloas ayarlarını ve Gloas’a bağlı gas sınırı takvimini kaldırdı. Değişiklik yalnız gelecekte devreye girecek kuralları kaldırıyor; daha önce işlenmiş blokları koruyor. Amsterdam ile Gloas, birlikte Glamsterdam adı verilen yükseltmenin iki parçası.
Glamsterdam’ın eylülde duyurulan Sepolia testi 6 Ekim’de gerçekleştirildi. 16 Ekim tarihli Hoodi duyurusunun başına erteleme uyarısı eklendi; eski yazıdaki tarih ve istemci tablosu artık yükseltmeyi uygulama talimatı olarak kullanılamaz. Ethereum ana ağı için kesin tarih henüz açıklanmadı. ETH sahipleri ile ana ağ kullanıcılarından erteleme nedeniyle işlem yapmaları istenmiyor.
Hoodi işletmecileri erteleme için de güncelleme yapmalı. Hoodi’de 26 Ekim ayarı hâlâ açık olan bir istemci, diğer düğümlerle aynı kuralları izlemeyebilir. İşletmeciler yalnız sürüm numarasına bakmak yerine, kullandıkları sürümün notlarında eski Hoodi etkinleştirmesinin kaldırıldığını doğrulamalı. Özel ağ ayarı kullananlar da yapılandırmalarını güncellemeli.
Gas hesabı sözleşmelerin davranışını nasıl değiştirebilir?
Gas, Ethereum’da işlemin hesaplama ve veri kullanımı için harcadığı kaynakları ölçüyor. EIP-8037, yeni hesap, sözleşme kodu ve depolama kaydı oluşturmanın maliyetini yükseltmeyi ve yürütme maliyetinden ayrı ölçmeyi öneriyor. Amaç, blokların daha fazla işlem almasına izin verirken düğümlerin sakladığı verinin aşırı büyümesini sınırlamak. Kullanıcı her iki maliyeti de ödüyor. Ethereum geliştirme önerisi anlamına gelen EIP, burada henüz değerlendirilmekte olan teknik değişikliği tarif ediyor.
Öneride işlem yine tek bir gas limitiyle gönderiliyor, ancak yazılım bütçeyi yürütme gas’ı ve yeni veri oluşturmak için ayrılan gas rezervi olarak izliyor. Yeni veri oluşturulurken önce rezerv kullanılıyor; rezerv biterse kalan maliyet yürütme bütçesinden düşülüyor. Bir alt sözleşme çağrısına aktarılabilecek yürütme gas’ına uygulanan 63/64 sınırı rezervi kapsamıyor. Sözleşmenin kalan gas’ı sorguladığı gasleft() ise yalnız yürütme tarafını görüyor.
Öneriye göre yeni veri oluşturulup aynı işlem sırasında silinirse, veri için ayrılan gas geri veriliyor. Önce yürütme bütçesinden karşılanmış ve henüz geri ödenmemiş miktar o bütçeye dönüyor; kalanı rezerve ekleniyor. Dolayısıyla sözleşmenin okuyabildiği yürütme gas’ı, bir komut çalıştıktan sonra artabilir. İşlem başında boş olan bir depolama alanına değer yazılıp yeniden sıfırlanması örneğinde, iki gas ölçümü arasındaki fark negatif çıkabilir. Negatif fark, kullanılan sayı hesabına göre işlemi durdurabilir ya da sayıyı geçerli aralığının dışına taşırabilir. Risk, sözleşmenin ölçümü nerede yaptığına ve sonucu nasıl kullandığına bağlı.
ChainSecurity’nin 13 Ekim tarihli teknik incelemesi, başka bir sözleşmeye yapılan çağrının neden başarısız olduğunu yalnız kalan gas’a bakarak anlamaya çalışan uygulamalara odaklanıyor. Bazı hata durumlarında eskiden gas yetmediği için duran kod, yeni hesapla çalışmayı sürdürebilir ve uygulama yanlış karar verebilir. Çağrıdan önce yeterli bütçe ayıran kontroller bütünüyle geçersiz sayılmıyor; bütçenin yeni maliyetleri, çağrının bütün olası adımlarını ve ek giderlerini kapsaması gerekiyor.
“Daha önce geri çevrilen bir hata yolu artık tamamlanabilir.”
ChainSecurity 13 gerçek örnek bulduğunu açıkladı
ChainSecurity, 22 Ekim’deki paylaşımında 13 gerçek örnek bulduğunu ve sorunları kamuya açıklamadan önce ilgili proje ekipleriyle çalıştığını belirtti. Şirket, Ethereum Vakfının kaç sözleşmenin hangi biçimde etkilendiğini araştırdığını söyleyerek geliştiricilerden kodlarını kontrol etmelerini istedi. Paylaşımda proje isimleri, gerçekleşmiş saldırı veya kayıp tutarı açıklanmadı.
ChainSecurity’nin 22 Ekim tarihli açıklaması
Gönderi, açtığınızda X üzerinden yüklenir.
Vakfın 24 Ağustos tarihli test rehberi, geçmiş ana ağ işlemlerinin yeni maliyetlerle yeniden çalıştırıldığını anlatıyor. Sonuçlar dört gruba ayrılıyor: etkilenmeyenler, farklı miktarda gas harcayarak başarılı olanlar, limiti yükseltilince çalışabilenler ve daha yüksek limit verilse de bozulabilecekler. Son grupta sabit gas gönderilen çağrılar, kalan gas’a göre karar veren kodlar ve limiti önceden imzalanmış işlemler bulunuyor. Vakfın ağustos sonuçları, uygulama ekiplerinin incelemesi gereken kod örneklerini gösteriyor.
Uygulama ekiplerinin yalnız başarılı işlemleri değil, başarısız çağrıdan sonra ne olduğunu da sınaması gerekiyor. Cüzdanların ve uygulamaları ağa bağlayan RPC hizmetlerinin eth_estimateGas tahminleri, öneriye göre hem yürütme hem veri oluşturma maliyetlerini hesaba katmalı. Eski sabit değerlerle yapılan hesap, yetersiz gas ayrılmasına ve işlemin başarısız olmasına yol açabilir. Ekipler, önerinin sonraki sürümlerini de izlemeli.
İşletmeciler hangi güncellemeleri kontrol etmeli?
Hoodi’de düğüm çalıştıranların yürütme istemcisi ile mutabakat istemcisini birlikte kontrol etmesi gerekiyor. Doğrulayıcı işletenler için blokları ve oyları izleyen beacon node ile doğrulayıcının imzalarını yöneten validator client yazılımları güncel olmalı. Blok oluşturma hizmeti veya başka altyapı sağlayıcısı kullananlar da sağlayıcının Hoodi talimatlarını izlemeli. Vakfın güncel duyurusu, istemci ekiplerinin ertelemeyi içeren sürümlerine bağlantı veriyor.
| İstemci | Sürüm | Yayımlanan talimat |
|---|---|---|
| Lighthouse — mutabakat | v8.3.2 | Hoodi’de eski 26 Ekim saatinden önce beacon node, validator client ve yürütme istemcisini güncelleyin. |
| Besu — yürütme | 26.10.1 | Hoodi işletmecileri, Amsterdam etkinleştirmesini kaldıran sürüme geçmeli. |
23 Ekim’de yayımlanan Lighthouse v8.3.2, v8.3.0 ve v8.3.1’deki Hoodi talimatlarının yerini alıyor. v8.2.x veya daha eski bir sürümden gelenlerin, veritabanı taşıma ve sistem gereksinimleri için v8.3.0 notlarını da okuması isteniyor. 22 Ekim tarihli Besu 26.10.1 ise Hoodi etkinleştirmesinin kaldırılması dışında 26.10.0 ile aynı. Her iki ekip de ana ağ kullanıcıları için yalnız bu erteleme nedeniyle güncelleme gerekmediğini belirtiyor.
Glamsterdam’ın diğer başlıca hedefleri arasında blok öneren doğrulayıcıyla bloğu hazırlayan aktörün görevlerini protokol içinde ayıran ePBS ve paralel işlem doğrulamasını kolaylaştıran blok erişim listeleri bulunuyor. Geliştiriciler, sözleşmelere etkisini inceledikten sonra Hoodi için yeni takvimi ayrıca duyuracak.
Ethereum’un 22 Ekim tarihli ACDE 248 toplantı kaydı, erteleme kararının alındığı geliştirici toplantısına ait. Resmî gündemde EIP-8037 ve EIP-8038’in sözleşmeler üzerindeki etkileri yer alıyor. Bağlantı yaklaşık 97 dakikalık kaydı açıyor.
