Polygon PoS ağı üzerinde çalışan Bor ve Heimdall istemcilerinde, Austin ve Kyoto isimli iki koordineli hard fork hayata geçirildi. Bu güncellemeler, Polygon PoS istemci yığınına yönelik hizmet reddi (DoS), kaynak tükenmesi ve konsensüs sağlamlaştırma risklerini ortadan kaldırmayı hedefledi. Polygon forumunda 27 Ağustos’ta paylaşılan bilgilere göre, her iki güncelleme de önce özel olarak dağıtıldı ve Amoy testnet’inde doğrulandıktan sonra mainnet’te etkinleştirildi.
Austin güncellemesinin, tespit edilen zafiyetleri ele aldığı süreçte mainnet’te herhangi bir kesinti yaşanmadı. Kamuya duyurunun yapıldığı anda, her iki hard fork da hem Amoy testnet’inde hem de mainnet’te aktifti. Burada kritik olan, Polygon’un önce sorunları giderip ağı güvence altına alması, ardından düzeltilen açıkların detaylarını paylaşmasıydı.
Austin ve Kyoto’nun Teknik Etkileri
Austin, Bor blok işleme sürecinde iki DoS açığını kapattı. L1’den L2’ye köprü işlemlerini yöneten State-Sync olayları, akıllı sözleşme kodunu ve önceden derlenmiş işlemleri normal işlemler gibi çalıştırıyor. Ancak, bu işlemlerin işlem ücreti (Gas Fee) tüketimi, blok başına belirli bir üst sınırla sınırlandırılmıyordu. Çok sayıda veya yüksek işlem gücü gerektiren State-Sync olayları, blok işleme hızını ciddi şekilde yavaşlatıp zincirin geçici olarak durmasına yol açabilirdi. Austin, bu riskin önüne geçmek için blok başına açık bir işlem ücreti sınırı getirdi.
Austin’in ikinci düzeltmesiyle, Bor Wire protokolündeki “TxDependency” alanı tamamen kaldırıldı. Bu alan, paralel işlem yürütme için bir gösterge işlevi görüyordu ancak boyut sınırı yoktu. Bir blok üreticisi, bu alanı kullanarak çok büyük veri bloklarını geçerli bir kardeş bloğa ekleyebilir ve bu bloğu işlemek isteyen tüm düğümlerin çökmesine neden olabilirdi.
Paralel yürütme, üreticinin verdiği ipuçlarına güvenmek zorunda olmadığı için bu alanın kaldırılması, sonraki süreçlerde olumsuz bir etki yaratmadı. Kyoto’nun en kritik düzeltmesi ise Heimdall işlemlerinde derin şekilde iç içe geçmiş “google.protobuf.Any” alanlarını hedef aldı. Sınırlandırma olmadan, tek bir manipüle edilmiş işlem, tüm doğrulayıcıları orantısız derecede yüksek bir kod çözme yüküne maruz bırakabilirdi. Bu da, izin gerektirmeyen bir şekilde tüm doğrulayıcı setini aşırı zorlayabilirdi.
Kyoto, bu riski önlemek için hem mempool’a alınırken hem de konsensüs yolunda zorunlu olan bayt düzeyinde bir ön tarama getirdi. Böylece, bir işlem ilk aşamada onaylanıp sonraki aşamada reddedilemeyecek. Ayrıca Kyoto, ücret coin’leri için üst sınır, checkpoint imzalarının kurtarılması için normalize edilmiş baytlar, üretici kesintilerinde tekrarlanan mesajlara idempotent yaklaşım ve milestone oylarının imzalı parent-hash’e bağlanması gibi ek sağlamlaştırma önlemlerini de içeriyor. Checkpoint pencereleri için süreklilik kontrolleri ve L1 olayları için enjeksiyonlu replay anahtarları da eklendi.
Tüm bu değişiklikler, fork yüksekliğinin altında pasif durumda ve normal veri trafiği üzerinde herhangi bir davranış değişikliğine yol açmıyor. Bu çok katmanlı doğrulama yaklaşımı, sektörde işlem işleme süreçlerindeki uç durumları istismar edilmeden önce güvence altına alma yönündeki genel çabaların bir yansıması olarak öne çıkıyor.
Bor ve Heimdall’da Neden Ayrı Güncellemeler Gerekti?
Austin, Amoy testnet’inde blok 44.120.000’de ve mainnet’te blok 91.949.700’de etkinleştirildi. Kyoto ise Amoy’da 42.252.000 ve mainnet’te 51.533.000 blok yüksekliğinde devreye alındı. Bor, blok yürütmeden sorumluyken Heimdall konsensüs mekanizmasını yönetiyor. Kyoto’nun düzeltmeleri, ABCI, milestone, Bor, stake ve köprü işlemlerini kapsayarak checkpoint kesinliği, milestone muhasebesi ve L1 olaylarının tekrar oynatılması gibi süreçleri etkiledi.
Bor v2.10.0 tüm düğümler için zorunlu; Heimdall v0.11.0 ise tüm doğrulayıcılar ve tam düğümler için gerekli. Bu güncellemeler, yalnızca ikili dosya seviyesinde ve güncel durumda olan operatörler için herhangi bir durum geçişi veya genesis değişikliği gerektirmiyor.
Aktivasyon yüksekliğinden sonra hâlâ eski sürümle çalışan düğümler ise kanonik konsensüsten sapmış durumda. Bu düğümlerin, yalnızca güncelleme yapmak yerine, bir geri dönüş işlemiyle yeniden senkronize olmaları gerekiyor.
Bu tür koordineli istemci güncellemeleri, yüksek işlem hacmine sahip zincirlerde operasyonel riskler barındırıyor. Benzer dinamikler, ağlar durum büyümesi ve yürütme risklerini güncelleme sıklığıyla dengelemeye çalışırken, örneğin Ethereum’un Glamsterdam güncelleme yolunda da görülüyor. Polygon PoS için öne çıkan sonuç ise şu: Tespit edilen açıklar, kaynak tükenmesi ve konsensüs uç durumlarına dair risklerdi; doğruluk hatası değildi ve her iki açık da mainnet’te istismar edilmeden önce giderildi.
Bu içerik hazırlanırken faydalanılan kaynaklar: cryptonews.com
