Orijinal Yazar: @VitalikButerin
Çeviren: Peggy, BlockBeats
Editörün Notu: Ethereum ekosistemi genişledikçe, ağın ölçeklendirilmesinin güvenlik ve merkeziyetsizlikten ödün vermeden nasıl gerçekleştirileceği ana konu haline gelmiştir. Bu makalede, Vitalik Buterin Ethereum'un ölçeklendirme yolunu daha ileri bir şekilde ele alarak, ağın kapasitesini artırmak için Gas mekanizması optimize edilmesi, blok doğrulamasının paralelleştirilmesi ve diğer teknik geliştirmeler gibi kısa vadeli yaklaşımlarla verimliliği artırmayı ve uzun vadede ise ZK-EVM ve blobs veri yapısı aracılığıyla ağın ölçeğini genişletmeyi planladığını açıklamaktadır.
Genel olarak, bu yol haritası, Ethereum'un önümüzdeki yıllarda ağ kapasitesini sürekli olarak genişletmesine olanak tanıyacak aşamalı bir ölçeklendirme planı sunmaktadır.
Aşağıda orijinal metin yer almaktadır:
Şimdi ölçeklendirme konusuna değinelim. Burada genellikle iki kısma ayrılır: kısa vadeli ölçeklendirme ve uzun vadeli ölçeklendirme.
Kısa vadeli ölçeklendirme hakkında başka yerlerde de bazı yazılar kaleme aldım. Temel yaklaşım şöyle bir şeydir:
· Blok düzeyinde erişim listeleri (block-level access lists) (Glamsterdam güncellemesi ile sunulacak) blok doğrulamasını paralelleştirmeyi sağlayabilir.
· ePBS (aynı zamanda Glamsterdam'da sunulacak) birkaç özelliğe sahiptir, bunlardan biri de: Her slot içinde blok doğrulamak için kullanılan zamanın daha büyük bir yüzdesini güvenli bir şekilde kullanmamızı sağlar, şu anda olduğu gibi sadece yüzlerce milisaniye kullanmamız gerekmez.
· Gaz yeniden fiyatlandırma (gas repricing), çeşitli işlemlerin gaz maliyetinin gerçek yürütme süresiyle (ve getirdikleri diğer maliyetlerle) tutarlı olmasını sağlar. Aynı zamanda çok boyutlu gaz (multidimensional gas) mekanizmasını da erken aşamada araştırıyoruz, böylece farklı kaynakların ayrı ayrı bir üst sınır belirlemesine olanak tanır. Bu iki unsur bir araya geldiğinde, karşılaşılacak aşırı durumlar konusunda endişelenmeden blok doğrulamak için daha büyük slot zamanı kullanabiliriz.
Çok boyutlu gaz ile ilgili olarak, aşamalı bir yol haritası oluşturduk. İlk aşama, Glamsterdam güncellemesinde, "durum oluşturma maliyeti" ile "yürütme ve calldata maliyeti"ni ayırmaktır.
Örneğin, şu anda: Bir SSTORE işlemi, depolama yuvasını sıfırdan olmayan bir değere değiştirirse, ücret 5000 gaz iken, sıfırdan olmayan bir değerden sıfıra değiştirirse ücret 20000 gazdır.
Glamsterdam'daki bir gaz fiyatı ayarlama işleminde, bu ek maliyet önemli ölçüde artırılacaktır (örneğin 60000'e yükseltilebilir). Bu, gaz üst sınırını artırırken, yürütme kapasitesinin durum ölçeğinin genişleme hızından çok daha hızlı genişlemesini sağlamanın amaçlanmıştır.
Nedeni hakkında daha önce yazdım: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
Bu nedenle, Glamsterdam'da: Bu SSTORE işlemi "normal gaz" olan 5000'i (örneğin "durum oluşturma gazı" olan 55000'i) tüketir
Dikkat edilmesi gereken bir nokta: Durum oluşturma gazı, yaklaşık 16 milyonluk işlem gazı üst sınırına dahil edilmez.
Bu şu anlama gelir: Şu an mümkünden daha büyük kontratlar oluşturmak mümkün hale gelecektir.
Burada bir sorun ortaya çıkıyor: EVM'nin tasarımı varsayılan olarak gazın yalnızca bir boyuta sahip olduğunu, örneğin GAS, CALL vb. opcode'ların bu varsayıma dayandığını varsayar.
Çözümümüz iki değişmez tutmak üzerinedir:
Bir CALL başlattığınızda X gaz kullandıysanız, bu CALL X gazla, "normal işlemler" veya "durum oluşturma" veya gelecekte eklenen diğer boyutlar için kullanılabilir.
Eğer GAS opcode size mevcut olarak Y gaz olduğunu söyler ve sonra X gaz tüketen bir CALL başlatırsanız, çağrı geri döndükten sonra en azından Y − X gazınızın olduğunu ve sonraki işlemler için kullanılabileceğini belirtir.
Belirli bir uygulama yöntemi şudur: Biz N+1 gaz boyutu tanıttık. Varsayılan olarak N = 1'dir (durum oluşturma), ek bir boyut rezervuar olarak adlandırılır.
EVM'nin yürütme mantığı şöyledir:
Mümkünse, özel boyutta gazı öncelikli olarak tüketin
Eğer yetersizse, rezervuardan tüket.
Örneğin, şuna sahipseniz: (100000 durum oluşturma gazı, 100000 rezervuar)
Eğer SSTORE kullanarak üç kez yeni durum oluşturursanız, gazın değişim süreci şöyle olacaktır: (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000)
Bu tasarımda:
GAS opcode'unun döndürdüğü şey rezervuardır
CALL, belirli bir miktarda gazı rezervuardan iletecek ve aynı zamanda rezervuar olmayan tüm gazı iletecektir
Daha sonra çok boyutlu fiyatlandırmayı (multi-dimensional pricing) tanıtacağız; böylece farklı kaynak boyutları farklı dalgalanma gaz fiyatlarına sahip olacaktır.
Bu şunları sağlayacaktır:
Daha iyi uzun vadeli ekonomik sürdürülebilirlik
Daha iyi kaynak tahsisi verimliliği
Ayrıntılar için bakınız: https://vitalik.eth.limo/general/2024/05/09/multidim.html
Ayrıca rezervuar mekanizması, o makalede bahsedilen Alt Çağrı (sub-call) sorununu çözer.
Uzun vadeli genişleme genellikle iki yönde olacaktır: ZK-EVM ve Blobs.
Blobs için, PeerDAS'ı sürekli olarak geliştirmeyi planlıyoruz ve nihayetinde yaklaşık 8 MB/saniye veri işleme kapasitesine ulaşmayı umuyoruz.
Bu ölçek:
Ethereum'un kendi ihtiyaçlarını karşılamak için yeterli olacaktır
Ve bir "küresel veri tabanı" olmayı amaçlamamaktadır.
Şu anda, blob'lar genellikle L2 için kullanılmaktadır. Gelecekteki plan, Ethereum blok verilerini blob'lara doğrudan yazmaktır.
Bunun amacı, insanların geniş ölçekli bir Ethereum ağını indirmeden ve yeniden yürütmeden doğrulamasına izin vermektir:
ZK-SNARK'lar yeniden yürütme ihtiyacını ortadan kaldırır
PeerDAS + blob'lar, veri erişilebilirliğini indirmeden doğrulamayı mümkün kılar
ZK-EVM için hedefimiz, ağın buna olan bağımlılığını giderek artırmaktır.
2026: ZK-EVM'yi destekleyen istemciler ortaya çıkacak ve düğümler ZK-EVM'yi kullanarak tanıklık yapabilecek. Ancak bunlar henüz yeterince güvenli değil ve ağın tamamen ona güvenerek çalışmasına izin veremez. Bununla birlikte, ağın yaklaşık %5'i tarafından kullanıldığında kabul edilebilir olacaktır. (ZK-EVM bir sorunla karşılaşırsa, teminatınızı çekilmezsiniz ancak geçersiz bloklara kurulduğunuzdan dolayı ödeme kaybına uğrayabilirsiniz.)
2027: Daha büyük bir düğüm yüzdesinin ZK-EVM çalıştırmasını önermeye başlayacağız, aynı zamanda formal doğrulamaya ve güvenliğin artırılmasına odaklanacağız. Ağın yalnızca %20'si bile ZK-EVM'yi kullanıyorsa, solo staker'lar için düşük maliyetli bir doğrulama yolunu mümkün hale getireceğinden, gas limitini önemli ölçüde artırabiliriz; bu da aynı zamanda solo staker'ların oranının %20'nin altında olduğu anlamına gelir.
Teknoloji olgunlaştığında: 3'ten 5'e zorunlu bir ispat mekanizması tanıtacağız. Yani, bir blok, geçerli kabul edilebilmesi için en az 3 farklı ispat sisteminden en az 3 ispat içermelidir. Bu zamana kadar, indeksleme yapılması gereken düğümlerin dışında, çoğu düğümün ZK-EVM ispatlarına güveneceğini tahmin ediyoruz.
Uzun vadeli: ZK-EVM'yi sürekli olarak iyileştirerek daha sağlam hale getireceğiz ve daha sıkı formal doğrulama yapacağız. Bu aşamada ayrıca, RISC-V gibi yönlere benzer şekilde, sanal makine seviyesinde değişiklikler yapılabilir.
Detaylar için: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
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