27 Şubat 2026 tarihinde Vitalik Buterin, Ethereum Research üzerinde «Hyper-scaling state by creating new forms of state» başlıklı uzun bir makale yayınladı.
Bu makalede Vitalik Buterin, Ethereum'un ölçeklendirme yolunu daha da netleştirdi. Bu yazı, Ethereum'un ölçeklendirilmesini sadece teknik bir açıdan değil, aynı zamanda bütüncül bir mimari bakış açısıyla, Ethereum'un gelecek birkaç yıl boyunca ağ kapasitesini sürekli genişletmesi için bir aşama bazlı ölçeklendirme planı sunuyor.
Ayrıca, X üzerinde bir tweet paylaşarak makaleyi daha da açıkladı. Vitalik'in bu yeni genişletme önerisinin tam olarak ne olduğunu ve neden bunu yaptığını basit bir dille anlamaya çalışıyoruz.
Kısa ve uzun vadeli kaynak ve veri kaynakları genişletme
Vitalik, uzun yazısının başında, "Ethereum'u önümüzdeki beş yıl içinde ölçeklendirmek için üç kaynak ölçeklendirilmelidir" diye belirtiyor.
- Kaynak yürütme: EVM hesaplama, imza doğrulama vb.
- Veri kaynakları: İşlemin göndereni, alıcısı, imzası vb.
- Durum Kaynakları: Hesap bakiyesi, kod, depolama
İkisi de kısa ve uzun vadeli genişleme planlarına sahiptir.
İşlem kaynakları için kısa vadeli olarak blok erişim listesi (BAL), ePBS ve gaz ücreti yeniden fiyatlandırma ile yaklaşık 10-30 kat artış sağlanacak; uzun vadeli olarak ise ZK-EVM ile yaklaşık 1000 kat artış hedeflenmektedir. Ayrıca bazı özel hesaplama türleri (imza, SNARK/STARK) için dışarıda birleştirme, performansı yaklaşık 10000 kat artırabilir.
Veri kaynakları için kısa vadeli olarak P2P iyileştirmeleri ve çok boyutlu Gas ile yaklaşık 10-20 kat artış, uzun vadeli olarak Blobs + PeerDAS ile yaklaşık 500 kat artış sağlanacaktır.
Kısa vadeli genişleme, Ethereum'un daha hızlı çalışmasını hedefliyor. Şu anda Ethereum'un yavaş olmasının nedeni, geçerli doğrulama yönteminin sıralı olması—yani işlemler birbirini takip ederek kontrol ediliyor. Bir işlem takılırsa, tüm doğrulama süreci durur.
Bu nedenle bu yılki Glamsterdam yükseltmesi, blok erişim listesi (BAL) ve ePBS'yi sunacaktır.
Blokların erişim listesi, blok paketleyicilerinin doğrulayıcılara önceki olarak şunu söylemesini sağlar: “Bu bloktaki işlemler, bu hesapları ve depolama konumlarını kullanacaktır.” Bu bilgiyle doğrulayıcılar, bu verileri diskten belleğe yüklemek için önceden hazırlanabilir. Ardından, doğrulayıcılar işlemleri tek tek değil, aynı anda birden fazla işlemi kontrol edebilir. Bir fabrikanın üretim hattı gibi: eskiden bir işçinin tüm ürünü tek başına tamamlaması gerekirken, şimdi birçok işçi aynı anda farklı kısımları işliyor.
ePBS, blok paketleme ve doğrulama süreçlerini ayırır—blok oluşturucular işlem paketlemeyi, önericiler blok önerisini, doğrulayıcılar ise blok doğrulamasını yapar. Her rol kendi görevini yerine getirir, böylece blok oluşturucular, önericilerin ve doğrulayıcıların kontrolü sayesinde güvenlik endişesi olmadan daha agresif şekilde daha fazla işlem paketleyebilir.
Gas ücreti yeniden fiyatlandırma + çok boyutlu Gas, temel beceri olarak adlandırılabilir. Şu anda Ethereum'daki tüm işlemler aynı Gas ücretini kullanmaktadır. Ancak Vitalik'in fikri, farklı işlemlerin farklı fiyatlara sahip olmasıdır.
Özellikle, yeni durumlar oluşturmak (örneğin, yeni bir hesap oluşturmak veya yeni bir sözleşme dağıtmak) özel bir «durum oluşturma ücreti» gerektirmelidir. Çünkü yeni durum oluşturmak en maliyetli işlemdir. Hem hesaplama kaynaklarını hem de depolama kaynaklarını tüketir. Ayrıca, bu maliyet kalıcıdır—bir kez oluşturulduğunda, bu durum kalıcı olarak varlığını sürdürecektir.
Yani Vitalik'in fikri, yeni durum oluşturmayı daha pahalı hale getirmek ama normal işlemlerini daha ucuz hale getirmektir.
Yöntem, "havuz mekanizması"dır. İki kova düşünün; biri "durum oluşturma ücreti" için, diğeri "normal gaz ücreti" için. Sözleşmeler birbirini çağırırken, gaz otomatik olarak bu iki havuzdan ödünç alınır ve karışıklık önlenir.
Normal kullanıcıların işlemlerinde “durum oluşturma ücreti” uygulanmayacağı için işlemler daha ucuza mal olacak. Yeni durumlar oluşturmak isteyen geliştiriciler ise daha yüksek ücretler ödeyecek. Bu sayede ağın toplam kapasitesi büyük ölçüde artarken, durum büyümesi kontrol altında tutulacak ve tam düğümlerin diskleri patlamayacak.
Uzun vadeli genişleme, ana ağı kendi içinde güçlendirmek ve Layer 2'e olan bağımlılığı azaltmaktır. Bu, Blobs + PeerDAS ve ZK-EVM'in aşamalı olarak piyasaya sürülmesini içerir.
Blobs, geçici büyük dosya depolama, şu anda ana olarak Layer 2 tarafından kullanılmaktadır. Gelecekte, Ethereum ana ağı da verileri depolamak için Blobs kullanacaktır. Ancak bu durumda bir sorun ortaya çıkıyor—her düğümün tüm Blobs'leri indirmesi gerekirse, ağ patlayacaktır.
Burada PeerDAS gerekiyor—tüm verileri indirmek yerine sadece bir kısmını indirin. Bir anket gibi, herkesi sormak gerekmez, sadece küçük bir grup sorulursa, tüm grubun durumu tahmin edilebilir. ZK kanıtlarıyla birleştirildiğinde, tüm verilerin yalnızca 1/16’sını indirseniz bile veri bütünlüğünü doğrulayabilirsiniz.
Ardından, bir bloğun doğrulanması için blok içindeki tüm işlemlerin yeniden yürütülmesine gerek kalmadan, düğümlerin doğrudan ZK kanıtlarına güvenmesini sağlayan ZK-EVM'nin aşamalı olarak başlatılması; doğrulama maliyetini "tüm işlemleri yürütmek"ten "bir ZK kanıtını doğrulamak" haline getirir.
Vitalik'in planına göre, 2026 yılında bazı düğümler ZK doğrulamasını deneyimleyecektir. 2027 yılına kadar daha fazla düğümün kullanımını teşvik etmek amaçlanmaktadır. Sonunda, bir bloğun geçerli olabilmesi için farklı kanıt sistemlerinden beş kanıt türünden üçünün dahil edilmesi gerekecektir. O, tüm düğümlerin (endeks düğümleri hariç) nihayetinde ZK-EVM kanıtlarına dayanmasını bekliyor.
İlaç gibi bir çözüm yok
Şimdi kısa ve uzun vadeli genişleme kapsamında henüz ele alınmayan “durum kaynakları”na bakalım. Kısa vadeli olarak, blok erişim listesiyle senkronizasyon, p2p iyileştirmeleri ve veritabanı optimizasyonu yoluyla yaklaşık 5-30 kat artış elde edilebilir, ancak uzun vadeli olarak?
Vitalik'in cevabı hayır.
Neden durum kaynakları bu kadar genişletme zorluğu yaşıyor? Ethereum durumu, devasa bir veritabanı gibidir. Bu veritabanı, tüm hesap bakiyelerini, tüm akıllı sözleşmelerin kodlarını ve tüm depolama konumlarının verilerini içerir.
Şu anda veritabanı henüz küçük, yaklaşık 100 GB boyutunda, ancak durum 20 kat genişletilirse 2 TB olur. Daha uzun bir süre sonra ne olur? 8 TB?
Sorun sabit diskin yer olmadığını değil,而是:
Veritabanı verimliliği etkileniyor: Modern veritabanları, verileri düzenlemek için ağaç yapıları (örneğin Merkle ağaçları) kullanır. Yeni bir veri yazıldığında, tüm ağaç güncellenmelidir. Bu, X kez güncelleme yaparsanız, veritabanı düzeyinde X kez işlem yapılması gerektiği anlamına gelir; bir kez güncelleme yaparak veritabanı işlemini tek seferde tamamlamak mümkün değildir. Daha fazla güncelleme, daha fazla işlem demektir ve yazma işlemleri patlayacak kadar yavaşlar.
Senkronizasyon zorluğu: Ethereum ağına yeni katılan bir düğüm, yeni blokları doğrulamak için tüm durumu indirmelidir. Veri boyutu 8 TB'a ulaştığında, çoğu kişinin mevcut internet hızıyla uzun bir süre beklemesi gerekir.
Çözümler var, ancak Vitalik bunların hepsinde sorunlar olduğunu düşünüyor:
- "Kuvvetli Durumsuzluk": Düğüm, tam durumu depolamak zorunda değildir, yalnızca kullanıcıların Merkle kanıtlarını sağlaması yeterlidir. Vitalik, bu çözümün durum depolamanın merkezileştirilmesi, dinamik depolama erişiminin işlem başarısızlığına neden olması ve bant genişliği maliyetleri sorunlarını içerdiğini düşünmektedir.
- "Durum süresi doldu": Nadiren erişilen durumlar, aktif durumlardan otomatik olarak kaldırılır. Düğüm sadece en son erişilen durumları saklamak zorunda kalır, bu da depolama alanını büyük ölçüde azaltır. Vitalik, yeni bir durum oluşturulduğunda, bir durumun "asla var olmamış" olduğunu nasıl kanıtlayacağınız konusunda temel bir "problem" olduğunu düşünür. Yeni bir hesap oluşturulduğunda, bu yeni hesap adresinin Ethereum üzerinde hiç oluşturulmamış olduğunu kanıtlamak gerekir. Bu, her yeni hesap oluştururken 10 yıllık geçmiş verileri kontrol etmek anlamına gelir ve yeni hesap oluşturmak karmaşık ve maliyetli hale gelir.
Vitalik, bu iki çözümü birleştirerek, Ethereum durum kaynakları mimarisine genel bir değişiklik olan birkaç yeni durum biçimi öneriyor:
- Geçici depolama: Otomatik olarak süresi dolan bir depolama türüdür. Örneğin, her ay otomatik olarak sıfırlanan yeni bir ağaç oluşturulabilir. Bu depolama, sipariş defteri, likidite havuzları, geçici sayaçlar gibi kalıcı olarak saklanmasına gerek olmayan geçici veriler için kullanılabilir. Bir ay sonra eski siparişler süresi dolar, yeni likidite havuzları oluşturulur.
- Periyodik depolama: Geçici depolamaya benzer, ancak daha uzun periyotlar, örneğin 1 yıl.
- Sınırlı depolama: Bazı depolamalara yalnızca belirli yöntemlerle erişilebilir. Örneğin, bir ERC20 token bakiyesi depolaması, yalnızca belirli bir arayüz üzerinden erişilebilir. Bu sayede sistem bu tür depolamaları optimize edebilir.
Aynı zamanda mevcut durumları koruyun. Bu sayede yürütme 1000 kat daha ucuz olabilir (ZK-EVM aracılığıyla), ancak yeni durum oluşturma sadece 20 kat daha ucuz olabilir.
Vitalik, yeni bir durum biçimiyle geliştiricilerin seçim sahibi olduğunu düşünüyor. Mevcut durum biçimini kullanmaya devam edip daha yüksek ücretler ödemek ya da uygulamayı yeniden tasarlayıp yeni durum biçimini kullanarak daha düşük ücretler elde etmek. Yaygın kullanım durumları için (örneğin ERC20 bakiyeleri, NFT’ler) standartlaştırılmış iş akışları olacakken, daha karmaşık kullanım durumları için (örneğin DeFi) geliştiricilerin kendi kendilerine iyileştirme yolları bulmaları gerekecek.
Bu strateji oldukça ilginç, bir nevi geliştiricilerin zekâsıyla maliyetleri düşürmesi ve geniş Ethereum kullanıcılarının bundan faydalanması gibi bir anlam taşımaktadır.
Dinamik BlockBeats'ta açık pozisyonları öğrenmek için tıklayın
Lüket BlockBeats resmi topluluğuna katılın:
Telegram abone grubu: https://t.me/theblockbeats
Telegram iletişim grubu: https://t.me/BlockBeats_App
Twitter resmi hesabı: https://twitter.com/BlockBeatsAsia

