27 Şubat 2026'da Vitalik Buterin, Ethereum Araştırması'nda "Yeni State Türleri Oluşturarak Durumu Hiper-Ölçeklendirme" başlıklı bir uzun makale yayınladı.

Bu makalede, Vitalik Buterin Ethereum'un ölçeklendirme yolunu daha da detaylandırdı. Bu makale sadece Ethereum'un teknik açıdan ölçeklendirilmesini tartışmaktan ibaret değil, aynı zamanda bütünsel bir mimari perspektiften, Ethereum'un ağ kapasitesini gelecek yıllarda sürekli genişletmek için bir aşamalı genişleme planı sunuyor.

Aynı zamanda, konuyla ilgili olarak X'te bir tweet yayınladı ve bu makaleyi daha da açıkladı. Biz de Vitalik'in bu yeni önerdiği ölçeklendirme planını anlamanın ve neden bunu yapmak istediğinin derinlemesine ve anlaşılır bir şekilde anlaşılmasına çalışıyoruz.

Yürütme Kaynağı ve Veri Kaynağının Kısa ve Uzun Vadeli Genişlemesi

Vitalik, uzun makalenin başında, "Ethereum'u beş yıl içinde genişletmek için üç kaynağı genişletmek gerektiğini" belirtti:

- Yürütme Kaynağı: EVM hesaplama, imza doğrulama, vb.

- Veri Kaynağı: İşlem gönderen, alıcı, imza vb.

- Durum Kaynağı: Hesap bakiyesi, kod, depolama

İlk ikisi için kısa ve uzun vadeli genişleme planları bulunmaktadır.

Yürütme kaynağı için, kısa vadede Blok Erişim Listesi (BAL), ePBS ve Gaz Ücreti Yeniden Fiyatlandırma ile yaklaşık 10-30 kat büyüme, uzun vadede ZK-EVM ile yaklaşık 1000 kat büyüme ve belirli hesaplama türleri (imza, SNARK/STARK) için, zincir dışı toplama performansı yaklaşık 10000 kat artış sağlayabilir.

Veri kaynağı için, kısa vadede p2p iyileştirmeleri ve çok boyutlu Gaz ile yaklaşık 10-20 kat büyüme, uzun vadede Blobs + PeerDAS ile yaklaşık 500 kat büyüme sağlanabilir.

Kısa vadeli genişleme, Ethereum'un daha hızlı çalışmasını sağlamayı amaçlar. Şu anda Ethereum'un yavaş olmasının nedeni, mevcut doğrulama yönteminin işlemleri seri olarak kontrol etmesidir - bir işlemi diğerinden sonra kontrol eder. Bir işlem takılırsa, tüm doğrulama süreci takılır.

Bu nedenle önümüzdeki Glamsterdam güncellemesi, Blok Erişim Listesi (BAL) ve ePBS'yi tanıtacaktır.

Blok Erişim Listesi, blok üreticisinin doğrulayıcıya önceden söylediği bir bilgidir: "Bu bloktaki işlemler, bu hesapları ve depolama konumlarını ziyaret edecek". Bu bilgi sayesinde doğrulayıcı önceden hazırlık yapabilir, bu verileri diskindeki hafızaya yükleyebilir. Sonra doğrulayıcı, işlemleri tek tek kontrol etmek yerine paralel olarak birden fazla işlemi kontrol edebilir. Adeta bir fabrikanın montaj hattı gibidir: Eskiden bir işçi tüm üründen sorumlu olurken, şimdi birden fazla işçi farklı bölümleri aynı anda işler.

ePBS, blokun paketlenme ve doğrulama sürecini ayırır - blok oluşturucu işlemleri paketler, önerici blok önerir, doğrulayıcı bloğu doğrular. Her rol kendi işini yapar, bu nedenle blok oluşturucu daha fazla işlemi paketleyebilir çünkü önerici ve doğrulayıcı ona yardımcı olur, güvenlik endişesi olmadan.

Gas Ücreti Yeniden Fiyatlandırma + Çokboyutlu Gas, "temel hareket" olarak adlandırılabilir. Şu anda, Ethereum'daki tüm işlemler aynı Gas ücretini kullanır. Ancak Vitalik'in düşüncesi, farklı işlemlerin farklı fiyatlara sahip olması gerektiğidir.

Özellikle, yeni bir durum oluşturma (örneğin yeni bir hesap oluşturma, yeni bir akıllı kontrat dağıtma) özel bir "durum oluşturma ücreti" gerektirmelidir. Çünkü yeni bir durum oluşturmak en pahalı işlemdir. Bu sadece hesaplama kaynaklarını değil, aynı zamanda depolama kaynaklarını da kullanır. Ve bu maliyet kalıcıdır - bir kere oluşturulduğunda, bu durum sürekli olarak var olacaktır.

Bu nedenle, Vitalik'in düşüncesi şudur: Yeni bir durum oluşturmayı daha pahalı hale getirirken, normal işlemleri daha ucuz hale getirmektir.

Bunun uygulama yöntemi ise "rezervuar mekanizması"dır. İki kovayı hayal edin, bir kova "durum oluşturma ücreti"ni içerirken diğer kova "normal Gas ücreti"ni içerir. Akıllı kontratlar birbirlerini çağırdığında, Gas otomatik olarak iki kovadan ödünç alır ve düzensiz hale gelmez.

Normal kullanıcı işlemleri daha ucuz hale gelecek çünkü bu işlemlerin "durum oluşturma ücreti" ödemesi gerekmez. Yeni bir durum oluşturmak isteyen geliştiriciler ise daha yüksek ücret ödemek zorunda kalacak. Böylece, ağın genel kapasitesi artar ancak durum büyümesi kontrol altında tutulur ve tam düğümlerin diskleri patlamaz.

Uzun vadeli genişleme, ana ağı daha güçlendirmek ve 2. Katmana olan bağımlılığı azaltmaktır. Bunlar Blobs + PeerDAS ve ZK-EVM'nin aşamalı olarak devreye alınmasını içerir.

Blobs, şu anda çoğunlukla 2. Katman için kullanılan geçici büyük dosya depolamasıdır. Gelecekte, Ethereum ana ağı da verileri depolamak için Blobs kullanacaktır. Ancak sorun şudur - her düğümün tüm Blobs'u indirmesi durumunda ağ zorlanır.

Burada PeerDAS devreye girer - tüm verileri indirmeniz gerekmez, sadece küçük bir kısmını indirmeniz yeterlidir. Anket örneği gibi, herkese sormak zorunda değilsiniz, sadece birkaç kişiye sormak, tüm grubun durumu hakkında çıkarımda bulunmanıza olanak tanır. ZK kanıtlarıyla birleştirildiğinde, tüm verilerin sadece 1/16'sını indirmiş olsanız bile verilerin bütünlüğünü doğrulayabilirsiniz.

Sonraki adım ZK-EVM'nin aşamalı olarak devreye alınmasıdır, bu da bir bloğun doğrulanmasının artık bloktaki tüm işlemleri yeniden yürütme gerektirmemesini sağlar, düğümler doğrudan ZK kanıtına güvenmeye başlar, doğrulamanın maliyeti artık "tüm işlemleri yürütme"den "bir ZK kanıtını doğrulama"ya düşer.

Vitalik'in planı, 2026 yılında bazı düğümlerin ZK doğrulamasını denemesidir. 2027 yılına gelindiğinde, daha fazla düğümün kullanması teşvik edilecektir. Son olarak, bir bloğun geçerli olabilmesi için 5 farklı kanıt sistemi arasından 3 farklı kanıt türünü içermesi gerekir. O, tüm düğümlerin (dizin düğümleri hariç) sonunda ZK-EVM kanıtlarına dayanacağını tahmin etmektedir.

Çözüm Değil, Genişletmeye Dayalı Bir Durum

Şimdi, kısa ve uzun vadeli genişleme sürecinde henüz "durum kaynakları" hakkında konuşulmamış olanı ele alalım. Kısa vadede, blok erişim listesi senkronizasyonu, p2p geliştirmeleri ve veritabanı optimizasyonu gibi yöntemlerle yaklaşık olarak 5 ila 30 kat performans artışı elde etmek mümkün olabilir, ancak uzun vadede?

Vitalik'in cevabı, hayır.

Neden durum kaynaklarının genişletilmesi bu kadar zor? Ethereum'un durumu, sanki devasa bir veritabanıymış gibi. Bu veritabanında tüm hesapların bakiyeleri, tüm akıllı sözleşmelerin kodları, tüm depolama alanlarının verileri bulunmaktadır.

Şu anda bu veritabanı küçük değil, yaklaşık 100 GB, ancak durumu 20 kat genişletirsek, o zaman 2 TB olacaktır. Peki, zaman daha da ilerlerse? 8 TB mı?

Sorun, sabit diske sığmamasına değil, şurada yatmaktadır:

- Veritabanı verimliliği etkilenir: Modern veritabanları verileri düzenlemek için ağaç yapısı kullanır (örneğin Merkle ağacı). Yeni bir veri yazarken, tüm ağacı güncellemek gerekir. Bu, X sayısında güncelleme yapmanız gerekiyorsa, veritabanı seviyesinde X işlem yapmanız gerektiği anlamına gelir, tek seferlik bir güncelleme yapmanız yerine, veritabanı her seferinde bu işlemi tekrarlar. Daha fazla güncelleme yapılırsa, daha fazla işlem yapılması gerekeceği ve yazmanın patlayıcı bir şekilde yavaşlayacağı anlamına gelir.

- Senkronizasyon zorlukları: Ethereum ağına yeni katılan bir düğüm, yeni bir bloğu doğrulayabilmek için tüm durumu indirmek zorundadır. Veri boyutu 8 TB'ye ulaştığında, çoğu insanın mevcut internet hızları bu işlemi gerçekleştirmek için oldukça uzun süre alacaktır.

Çözüm önerileri mevcuttur, ancak Vitalik'e göre hepsinde sorunlar vardır:

- "Güçlü Duruma Sahip Durumsuzluk": Düğümlerin tam durumu depolamalarına gerek yoktur, sadece kullanıcıların Merkle kanıtını sağlamaları yeterlidir. Vitalik, bu yaklaşımın merkezi durum depolaması, dinamik durum erişimi nedeniyle işlemlerin başarısız olması ve bant genişliği maliyeti sorunlarına yol açabileceğini düşünmektedir.

- "Durumun Geçerliliği": Sık kullanılmayan durumlar, etkin durumdan otomatik olarak kaldırılır. Düğümler, yalnızca en son erişilen durumu saklarsa, depolama alanını büyük ölçüde azaltabilirler. Vitalik, bir temel "varlık problemi" olduğuna inanmaktadır, yani yeni bir durum oluşturulduğunda, belirli bir durumun "hiç var olmadığını" nasıl kanıtlanacağı. Yeni bir hesap oluşturulursa, o zaman bu yeni hesap adresinin Ethereum'da hiç oluşturulmadığını kanıtlamak gerekmektedir. Bu, her yeni hesap oluşturmada, 10 yıllık geçmiş verilerin incelenmesi gerektiği anlamına gelir, yeni hesap oluşturma işlemi karmaşık ve pahalı hale gelecektir.

Vitalik'in nihai yöntemi, bu iki yaklaşımı birleştirerek Ethereum'un durum kaynakları mimarisinde genel bir değişiklik olan bazı yeni durum biçimleri önermektir:

- Geçici depolama: Otomatik olarak süresi dolan bir depolama türü. Örneğin, her ay sıfırlanan yeni bir ağaç oluşturulabilir. Bu tür depolama, geçici veriler, sipariş defterleri, likidite havuzları, geçici sayaçlar vb. gibi genellikle kalıcı depolamaya ihtiyaç duyulmayan veriler için kullanılabilir; bir ay sonra eski siparişler geçersiz hale gelirken yeni likidite havuzları oluşturulur.

- Periyodik depolama: Geçici depolamaya benzer ancak periyot daha uzundur, örneğin 1 yıl.

- Kısıtlı depolama: Bazı depolamalara yalnızca belirli bir şekilde erişilebilir. Örneğin, bir ERC20 jetonunun bakiye depolamasına yalnızca belirli bir arayüz aracılığıyla erişilebilir olabilir. Bu sayede sistem bu tür depolamayı optimize edebilir.

Aynı zamanda mevcut durum biçimlerini korumak. Bu sayede yürütme maliyeti 1000 kat daha ucuz olabilir (ZK-EVM aracılığıyla), ancak yeni durum oluşturma maliyeti yalnızca 20 kat daha ucuz olabilir.

Vitalik'e göre, yeni durum biçimleriyle geliştiricilere seçenekler sunulmuş olacak. Mevcut durum biçimlerini kullanmaya devam ederek daha yüksek ücretler ödemek veya uygulamayı yeniden tasarlayarak yeni durum biçimlerini kullanarak daha düşük ücretler elde etmek. Yaygın kullanılan durumlar için (örneğin, ERC20 bakiyesi, NFT), standartlaştırılmış bir iş akışı olacaktır, ancak daha karmaşık kullanımlar için (örneğin, DeFi) geliştiricilerin kendi optimizasyonlarını yapmaları gerekecektir.

Bu strateji oldukça ilginçtir, çünkü bu, geliştiricilerin maliyetleri düşürmek için kafa yorması ve geniş Ethereum kullanıcı tabanının bundan faydalanması anlamına gelir.

BlockBeats Resmi Topluluğuna Katılın:

Telegram Abonelik Grubu: https://t.me/theblockbeats

Telegram Sohbet Grubu: https://t.me/BlockBeats_App

Twitter Resmi Hesabı: https://twitter.com/BlockBeatsAsia