Glamsterdam yükseltmesi, Ethereum'un L1 ölçeklendirme çözümü

Orijinal | Odaily Planet Daily jk

Ethereum için yakında gerçekleşecek olan Glamsterdam yükseltmesi, çekirdek geliştiriciler tarafından The Merge'den bu yana en büyük protokol düzeyindeki yeniden yapılandırma olarak kabul ediliyor. İsim, iki parçanın birleşiminden geliyor: yürütme katmanı yükseltmesi, önceki Devconnect etkinliklerinin yapıldığı yerin adından esinlenerek "Amsterdam" adını koruyor; konsensüs katmanı yükseltmesi ise bir yıldızdan esinlenerek "Gloas" adını alıyor. Önceki Fusaka yükseltmesinin ardından Glamsterdam, ağın işlemleri nasıl işlediğini ve büyüyen veritabanını nasıl yönettiğini yeniden düzenleyerek L1 ölçeklenebilirliğini geliştiriyor ve Ethereum'un blok oluşturma ve doğrulama yöntemini temelden güncelliyor.

Bu güncelleme üç temel hedef etrafında şekilleniyor:

• Hızlandırılmış İşleme (Paralelleştirme): Ağın veri bağımlılıklarını kaydetme biçimini yeniden düzenleyerek, işlemleri tek tek yavaşça işlemek yerine, çok sayıda işlemi aynı anda güvenli bir şekilde işlemesine olanak tanır.
• Ölçeklenebilirlik: Blok oluşturma ve doğrulama gibi ağır iş yükünü bölerek, ağın yavaşlamadan daha büyük miktarda veriyi yayması için daha fazla zaman sağlar.
• Sürdürülebilirlik: Yeni verilerin depolanmasının uzun vadeli donanım maliyetlerini doğru bir şekilde yansıtacak şekilde ağ ücretlerini ayarlamak, donanım performansında bozulmayı önlerken gelecekteki Gas limitlerindeki artışların önündeki engelleri kaldırmak.

Yükseltmenin iki ana önerisi, mutabakat katmanı ve yürütme katmanına odaklanmaktadır:

İki önemli Headliner önerisi var. Kaynak: Ethereum

Birinci Ana Öneri: ePBS, "Dış Kaynaklı Aracıları" "Dahili Kurallara" Dönüştürmek

Öncelikle, protokol içinde öneri sunanları ve oluşturanları birbirinden ayıran, İngilizce kısaltması ePBS olan (EIP-7732) konsensus katmanına ilişkin en önemli öneriyi ele alalım.

Ethereum her blok ürettiğinde, aslında iki adım söz konusudur: bir kişi "hangi bloğun seçileceğini" belirlemekten (öneren), diğer kişi ise "bloktaki işlemleri gerçekten bir araya getirmekten" (oluşturucu) sorumludur. Şu anda, bu iş bölümü Ethereum protokolü tarafından belirtilmemekte, ancak süreci kolaylaştırmak için zincir dışı bir grup "aracı şirkete" (genellikle röleler olarak adlandırılır) dayanmaktadır. Bu zincir dışı ilişki, blok doğrulama sırasında da bir yol oluşturarak, doğrulayıcıları 2 saniyelik kısa bir süre içinde işlem yayınlama ve yürütmeyi aceleyle tamamlamaya zorlar ve ağın işleyebileceği veri miktarını sınırlar. Örneğin, bu, sipariş ve pişirme süreçlerinin yemeklerin teslimatını koordine etmek için bağımsız bir dış aracıya bağlı olduğu bir restorana benzer; bu aracı başarısız olursa, mutfak ve ön büro uyumlu olmayabilir.

ePBS'nin yaptığı şey, bu "sipariş-pişirme" iş bölümünü restoranın kendi operasyonel kılavuzuna yazmak ve artık harici aracı kurumlara güvenmemektir. Sonuç olarak, güvenilir bir zincir içi blok teslimi ve ödeme mekanizması doğrudan protokolün içine entegre edilerek üçüncü taraf ara yazılımlara olan ihtiyacı ortadan kaldırır. Bununla birlikte, her iki taraf da protokolde henüz belirtilmemiş bazı karmaşık işlevleri kullanmak isterse, yine de harici aracı kurumları kullanmaya geri dönebilirler. Ek olarak, "teslimat" aşamasında karmaşayı önlemek için ePBS, "siparişi kimin verdiğini" ve "yemeğin zamanında hazırlanıp hazırlanmadığını" kontrol etmek üzere bir "yemek doğrulama ekibi" kurmuştur; böylece orijinal 2 saniyelik teslimat süresi yaklaşık 9 saniyeye çıkarılmış ve restoranın aynı anda daha fazla siparişi işlemesine olanak sağlanmıştır; bu da Ethereum'un Katman 2'ye yönelik daha fazla veriyi işleyebileceği anlamına gelir.

Ana Öneri İki: BAL'lar, Yola Çıkmadan Önce "Alışveriş Listesi" Hazırlıyor

Şimdi de yürütme katmanı için öne çıkan öneriyi, yani kısaltılmış haliyle BAL (EIP-7928) olarak adlandırılan blok düzeyinde erişim listesini ele alalım.

Şu anda Ethereum'un işlemleri işleme şekli, gözleri kapalı bir şekilde süpermarkette alışveriş yapan birine benziyor: önce bir ürünü hissetmeli, ne olduğunu doğrulamalı ve ardından nasıl devam edeceğine karar vermeli; bu da onları her seferinde bir ürünü sıraya koymaya zorluyor. Sistem, bir işlemin hangi verileri kullanacağını (örneğin hangi hesapların involved olduğunu) önceden bilmediği için, işlemleri kesinlikle sırayla işlemelidir; aksi takdirde, iki işlem yanlışlıkla aynı veriyi (aynı adresin bakiyesi gibi) değiştirmeye çalışabilir ve bu da çakışmalara neden olabilir.

BAL'ler, bu kişinin yola çıkmadan önce "hangi raflara gidileceğini ve hangi ürünlerin alınacağını" açıkça belirten bir alışveriş listesi edinmesini sağlar. Bu liste ile sistem, hangi işlemlerin birbiriyle "çarpışmayacağını" önceden görebilir; bu da ilgisiz işlemlerin tek tek kuyruğa alınması yerine gruplandırılıp paralel olarak işlenmesine olanak tanır. Bu listenin ek bir avantajı daha vardır: ağa yeni düğümler katıldığında, tüm karmaşık geçmiş işlemleri yeniden hesaplamak zorunda kalmadan bu listede kaydedilen nihai sonuçları doğrudan kopyalayabilirler; bu da yeni düğümler için senkronizasyon sürecini önemli ölçüde hızlandırır. Bu listenin ağ içinde dolaşımını kolaylaştırmak için Glamsterdam, düğümlerin bu erişim listelerini paylaşmasını sağlayan ilgili bir iletim protokolü yükseltmesi de paketlemiştir; bu da artık tüm yürütme katmanı istemcileri için zorunlu bir gereklilik haline gelmiştir.

Destekleyici Öneriler: "Uzay İşgal" Operasyonlarının Yeniden Değerlendirilmesi

Bu iki ana teklife ek olarak, Glamsterdam ayrıca fiyatlandırmaya yönelik iki destekleyici teklif daha hazırladı; bunlar, ağın "depolama ücretleri" ve "sorgulama ücretleri" için fiyat listesinin ayarlanması olarak anlaşılabilir.

• İlk öneri, ağda "kalıcı olarak yer kaplayacak" yeni hesaplar oluşturma ve sözleşmeleri dağıtma gibi işlemleri ele alıyor. Daha önce, alınan ücretler fiilen kullanılan alanla orantılı değildi; şimdi ise, ağın genel veri büyüme hızını yılda 120 GiB gibi güvenli ve öngörülebilir bir seviyede kontrol etmeyi amaçlayan "kullanılan her alan birimi için ücretlendirme" esasına göre yeniden hesaplanacak ve ağın sıradan donanım üzerinde çalışmaya devam edebilmesi sağlanacaktır. Ayrıca, bu depolama ücreti artık işlem ücretleriyle karıştırılmayacak, ayrı olarak hesaplanacaktır. Geliştiriciler depolama ücretlerinde biraz daha fazla ödeme yapmaya istekli oldukları sürece, genel Gas limitine hemen takılmadan daha büyük ve daha karmaşık uygulamaları dağıtmaya devam edebilirler.
• İkinci öneri, daha önce düşük fiyatlandırılan ve veri hacmi arttıkça gerçek sorgu maliyetlerine ayak uyduramayan ağdaki mevcut verileri sorgulama ve okuma gibi işlemleri ele alıyor. Bu kez, bu işlem kodları için fiyatlandırma standartları, modern donanımın gerçek yük koşullarını daha iyi yansıtacak şekilde yükseltilecek ve aynı zamanda bireylerin düşük ücretlerden yararlanarak ağı kasıtlı olarak aşırı sorgu istekleriyle tıkamasını önleyecektir.

Ana ağın lansman tarihi: Henüz belirlenmedi.

Zaman çizelgesi açısından Glamsterdam şu anda oldukça hassas bir aşamada. Resmi olarak, yürütme katmanı (ACDE) için tüm çekirdek geliştiricilerin en son doğrulanabilir toplantısı, 16 Temmuz'da düzenlenen 241. toplantıydı ve ana gündem maddeleri arasında Glamsterdam Devnet aşamasına ilişkin güncellemeler ve bir sonraki yükseltme olan Hegota için öne çıkan önerilerin seçilmesi yer alıyordu. Sektörde yaygın olarak referans alınan bir takvime göre, Devnet aşaması 0'dan 7'ye kadar sekiz yinelemeden geçti ve 28 Mart 2026'dan 8 Temmuz'a kadar sürdü; ardından aslen 3 Ağustos 2026 için planlanan Sepolia test ağı çatallanması ve aslen 17 Ağustos 2026 için planlanan Hoodi test ağı çatallanması geldi ve ana ağın etkinleştirilmesi için hedef tarih 16 Eylül 2026 olarak belirlendi.

Orijinal plan 2026 yılının ilk yarısı içindi. Kaynak: Ethereum

Ancak, son gelişmeler ışığında, bu takvimin ertelenmesi muhtemel görünüyor. EthPandaOps ekibi yakın zamanda Plataberget adında yeni bir test ağı başlattı; bu, Glamsterdam için özel olarak tasarlanmış ilk kısa vadeli halka açık test ağıdır. Sepolia ve Hoodi'nin resmi dağıtımlarının Eylül ayına kadar ertelenmesi bekleniyor ve ana ağın lansmanı için hedef tarih de buna bağlı olarak 2026'nın dördüncü çeyreğine kaydırıldı. Bu, Glamsterdam'ın zaman çizelgesinin ikinci kez kayması anlamına geliyor; daha önce de orijinal olarak planlanan 2026 yılının ilk yarısından ertelenmişti. Çekirdek geliştiriciler, yükseltmenin doğruluğunun belirli bir tarihe uyulmasından daha öncelikli olduğunu defalarca vurguladılar; bu nedenle, resmi ACD toplantısında belirli blok yüksekliği kesinleşene kadar, bu yükseltmeyi dördüncü çeyreğe veya hatta yıl sonuna kadar göremeyebiliriz.