Geliştiriciler, Glamsterdam geçişinde staking ETH’sinin builder hesabına yazılmasını önleyen değişikliği kabul etti. İstemci güncellemeleri ve ağda etkinleştirme ayrı adımlar.
Ethereum geliştiricileri, Glamsterdam yükseltmesinde staking için gönderilen ETH’nin yanlış hesaba yazılmasını önleyen bir değişikliği kabul etti. 5736 numaralı değişiklik, 26 Ekim saat 22.16 TSİ’de ağın ortak kurallarını tanımlayan kaynakların ana dalına eklendi. Eski kurallar, aynı açık anahtarı kullanan doğrulayıcı ile blok hazırlayan “builder” için gönderilmiş, henüz işlenmemiş yatırımları birleştirebiliyordu. İstemci ekiplerinin değişikliği kendi yazılımlarına uygulaması ve ağda etkinleştirmesi ayrı adımlar.
Staking için gönderilen ETH nasıl başka hesaba gidebilirdi?
12 Ekim’de hata bildirimini açan avsetsin, staking için parayı sağlayan taraf ile doğrulayıcıyı işleten kişinin farklı olabileceğini belirtti. Bir staking protokolü, düğüm işletmecisinin ilk doğrulayıcı yatırımını finanse edebilir; kalan ETH’yi göndermeden önce de doğrulayıcının, protokolün belirlediği çekim bilgileriyle oluştuğunu kanıtlamasını isteyebilir. Örnekte doğrulayıcı için 0x02, builder için 0xB0 öneki kullanılıyor; çekim bilgileri, türün yanında ETH’nin gönderileceği adresi de içeriyor.
Glamsterdam’ın konsensüs bölümünün adı Gloas. Eski Gloas kuralına göre işletmeci, yeni bir anahtar için önce kendi çekim adresini içeren geçerli bir builder yatırımı gönderebiliyordu. Ardından protokol aynı anahtara doğrulayıcı yatırımı yaptığında, iki kayıt da yükseltme anında hâlâ kuyrukta bekliyorsa tutarlar builder bakiyesinde birleşiyordu. İşletmeci protokolün gönderdiği ETH’yi de çekebiliyor, doğrulayıcı kaydı ise oluşmuyordu. Sorun, yükseltme sırasında bekleyen yatırımlardan builder kaydı oluşturulan tek seferlik aşamada ortaya çıkıyordu.
Doğrulayıcı oluşmayınca protokol, çekim bilgilerinin doğru ya da yanlış olduğunu kanıtlayacak kaydı bulamıyor. Protokol, kullandığı tasarıma bağlı olarak bakiyeleri yanlış hesaplayabiliyor, sonraki yatırım için ayırdığı parayı serbest bırakamayabiliyor veya olağan yöntemle geri alamayabiliyor. Bildirimi yapan avsetsin, bazı protokoller için sıraladığı örneklerin yapay zekâ destekli ön araştırma olduğunu, hata içerebileceğini ve çalışan yazılımların farklı olabileceğini açıkça belirtti. Lido, Origin ve Rocket Pool örneklerini doğrulanmış saldırı veya kalıcı olarak kilitlenmiş para vakaları olarak sunmadı.
“Gerçekleştiği doğrulanmış saldırılar değil.”
Yeni kural doğrulayıcı ve builder yatırımlarını ayırıyor
Düzeltme, yatırımları yalnız açık anahtara bakarak yönlendirmek yerine çekim bilgilerindeki türe göre ayırıyor. Builder, blokta yer alacak işlemleri hazırlayan aktör; doğrulayıcı ise blokları önerip oylayarak ağın ortak geçmiş üzerinde anlaşmasına katılıyor. Yeni kurallarda yazılım, anahtar aynı olsa da doğrulayıcıya gönderilen parayı builder bakiyesine eklemeyecek.
| Bekleyen yatırım | Nasıl işlenecek? |
|---|---|
| Doğrulayıcıya ait yatırım | Aynı anahtarlı builder bulunsa da doğrulayıcı kuyruğunda kalır. |
| Geçerli builder yatırımı | Aynı anahtarlı doğrulayıcı bulunsa da builder oluşturur veya mevcut bakiyeyi artırır. |
| Mevcut builder’a ek yatırım | Builder türündeki yatırım, imzadan bağımsız olarak mevcut builder bakiyesine eklenir. |
| Builder yokken geçersiz builder yatırımı | Aynı anahtarlı doğrulayıcı varsa veya daha önce geçerli doğrulayıcı yatırımı kuyruğa alınmışsa korunur; aksi halde atılır. |
Geliştiriciler, son satırdaki istisnayla mevcut doğrulayıcıya ek para gönderilebilmesini korudu. Builder bulunmadığında bütün geçersiz builder kayıtlarının atılması, açıklamalarına göre yeni bir para kaybına yol açabilir. İlk builder kaydını açarken geçerli imza gerekiyor. Zaten kayıtlı builder’a para eklerken ise yukarıdaki ayrı kural uygulanıyor.
Geliştiriciler, EIP-8282’de builder ile doğrulayıcı için birbirinden bağımsız kayıtlar tanımlıyor. EIP, Ethereum geliştirme önerisi anlamına geliyor. Öneri, yükseltmeden sonra builder yatırımları ve çıkışları için ayrı sözleşmeler öngörüyor. Yazılım, geçiş öncesinde gönderilmiş builder yatırımlarını bir defaya mahsus kayda alarak ilk slottan, yani ilk blok üretim aralığından itibaren builder bulunmasını sağlıyor. Yeni düzeltme, o anda bekleyen doğrulayıcı yatırımlarını ayrı tutuyor.
Geliştiriciler ertelemeden sonra düzeltmeye döndü
Justin Traglia, istemci ekiplerinden yeterli destek gelmediğini belirterek bildirimi 19 Ekim’de kapattı. Dmitry Gusakov, Glamsterdam takvimi değişince 23 Ekim’de konunun yeniden açılmasını istedi. 26 Ekim’deki All Core Devs Testing toplantısında Gusakov, Lido’nun doğrulayıcı kaydının mutlaka oluşacağı varsayımına dayandığını açıkladı; diğer protokoller için ayrıntılı önem derecesi analizi yapmadığını da söyledi.
Resmî Ethereum kanalındaki 26 Ekim toplantısının 25.22–32.17 arasındaki bölümü, yatırım sorununun ve önerilen değişikliğin tartışmasına ayrılıyor. Toplantı dökümünde Traglia, değişikliği birleştirip hafta içinde bir sürüm hazırlamayı öneriyor. Aynı akşam değişikliği kabul etti. Görüşmede bütün istemci ekiplerinin güncellemeyi dağıttığına ilişkin bir açıklama yapılmadı.
İnceleyen geliştiriciler, yatırımların farklı sıralarla geldiği ve mevcut doğrulayıcılarla aynı anahtarı kullandığı durumlar için ek testler istedi. avsetsin testleri değişikliğe ekledi. Lodestar geliştiricisi Nico Flaig, kendi dalının yeni testleri geçtiğini ve uygulamaları karşılaştıran testlerde sorun bulmadıklarını bildirdi. Potuz ise sıfırlanmış çekim adresi ve geçersiz imza gönderen araçlarla builder’a ek yatırım yapmanın para kaybına yol açabileceğini hatırlattı. İşletmecilerin kullandığı araçların da doğru türü, çekim adresini ve gerektiğinde geçerli imzayı göndermesi gerekiyor.
Hoodi ertelemesi ayrı bir incelemeye bağlı
Ethereum Vakfı, 22 Ekim duyurusunda Hoodi’de 26 Ekim için planlanan Glamsterdam etkinleştirmesini ertelemişti. Gerekçe, EIP-8037’nin mevcut ana ağ sözleşmeleriyle etkileşiminin incelenmesiydi. Staking yatırımı hatası, o duyuruda ertelemenin nedeni olarak gösterilmedi. Yeni Hoodi tarihi henüz belirlenmedi; eski etkinleştirme takvimi ve 200 milyon gas limiti artışı yeni istemci sürümlerinden çıkarıldı, zincirin geçmişi geri alınmadı.
Flaig, Sepolia geçişinde builder kayıtlarının bu yöntemle oluşturulmadığını, çünkü yatırım sözleşmesinin özel bir token gerektirdiğini açıkladı. Bu nedenle aynı geçiş kuralının değiştirilmesinin Sepolia geçmişinde farklı bir sonuç üretmesini beklemiyor. Vakfın erteleme duyurusunda ana ağdaki ETH sahiplerinden işlem yapmaları istenmedi; Hoodi düğüm ve doğrulayıcı işletmecilerine ise güncel istemci sürümlerini takip etmeleri söylendi.
Protokolün kontrolleri de belirleyici: avsetsin, ilk doğrulayıcı yatırımından önce aynı anahtar için builder yatırımı bulunup bulunmadığını denetleyen bir protokolün örnekteki sıralamayı engelleyebileceğini belirtti. Para kilitlenirse kurtarmanın mümkün olup olmadığı, yeni yatırım ve yönetici müdahalesi gibi protokole özgü yolların varlığına bağlı. Bildirim, her protokolde kalıcı kayıp olduğunu ileri sürmüyor.
