Ethereum'in Olası Geleceği: The Surge

Ethereum'un ölçeklenme stratejileri başlangıçta ikiye ayrılıyordu: parçalama ve Layer2 protokolleri. Parçalama, her düğümün yalnızca kısmi işlemleri doğrulamasını ve depolamasını sağlarken, Layer2 ise Ethereum'un üzerinde bir ağ inşa eder. Bu iki strateji nihayetinde birleştirilerek Rollup merkezli bir yol haritası oluşturdu ve bu gün itibarıyla Ethereum'un genişleme stratejisi olmaya devam ediyor.

Rollup merkezli yol haritası basit bir iş bölümü öneriyor: Ethereum L1 güçlü ve merkeziyetsiz bir temel katman olmaya odaklanırken, L2 ekosistemi genişletme görevini üstleniyor. Bu model toplumda yaygın olarak bulunuyor, örneğin mahkeme sistemi (L1) sözleşmeleri ve mülkiyet haklarını korurken, girişimciler (L2) bu temelin üzerine inşa ediyor.

Bu yıl, Rollup merkezli yol haritası önemli başarılar elde etti: EIP-4844 blobs, Ethereum L1'in veri bant genişliğini önemli ölçüde artırdı, birçok Ethereum sanal makinesi Rollup birinci aşamaya girdi. Her L2, kendi kuralları ve mantığı olan bir "parça" olarak varlığını sürdürmektedir; parça uygulama yöntemlerinin çeşitliliği ve çok yönlülüğü gerçeklik haline geldi. Ancak bu yol bazı benzersiz zorluklarla karşı karşıyadır. Şu anda görevimiz, Rollup merkezli yol haritasını tamamlamak, bu sorunları çözmek ve aynı zamanda Ethereum L1'in sağlamlığını ve merkeziyetsizliğini korumaktır.

The Surge: Ana Hedefler

1. Gelecekte Ethereum, L2 üzerinden 100.000'den fazla TPS'ye ulaşacak;
2. L1'in merkeziyetsizliğini ve dayanıklılığını koruyun;
3. En az bazı L2'ler Ethereum'un temel özelliklerini tamamen devralır: ( güven, açıklık, sansüre dayanıklılık );
4. Ethereum, 34 farklı blok zinciri yerine tek bir ekosistem gibi hissettirmelidir.

İçerik Özeti

1. Ölçeklenebilirlik Üçgen Paradoksu
2. Veri erişilebilirliği örneklemesi ile ilgili daha fazla gelişme
3. Veri Sıkıştırma
4. Genelleşmiş Plasma
5. Olgun L2 kanıtlama sistemi
6. L2'ler arası etkileşim geliştirmeleri
7. L1 üzerinde genişletme yürütme

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgeni paradoksu, blok zincirinin üç özelliği arasında bir çelişki olduğunu öne sürer: merkeziyetsizlik (, işletim düğüm maliyetinin düşük olması ), ölçeklenebilirlik (, işlem sayısının yüksek olması ) ve güvenlik (, saldırganların tek bir işlemi başarısız kılmak için büyük bir oranı hedef düğümleri yok etmesi gerektiği ).

Üçgen paradoksu bir teorem değildir, onu tanıtan gönderide de matematiksel bir kanıt eklenmemiştir. Heuristik bir argüman sunmaktadır: Eğer merkeziyetsiz dost düğümler her saniyede N işlem doğruluyorsa, k*N işlem işleyen bir zinciriniz varsa, o zaman: (i) her işlem yalnızca 1/k düğümü tarafından görülebilir, bir saldırgan yalnızca birkaç düğümü yok ederek kötü niyetli işlemler gerçekleştirebilir, veya (ii) düğümleriniz güçlenecek, zincir merkeziyetsiz olmayacaktır. Bu makale, üçgen paradoksunu kırmanın imkansız olduğunu kanıtlamak istememektedir, bunun yerine bunun zor olduğunu ve bu argümanın gizli düşünce çerçevesinin dışına çıkılması gerektiğini göstermektedir.

Yıllar boyunca, bazı yüksek performanslı zincirler, altyapıyı temelden değiştirmeden üçlü paradoksu çözdüklerini iddia ettiler, genellikle düğümleri optimize etmek için yazılım mühendisliği teknikleri kullanarak. Bu her zaman yanıltıcıdır; bu zincirlerde düğüm çalıştırmak, Ethereum'dan daha zordur. Bu makale, bunun nedenini ve yalnızca L1 istemci yazılım mühendisliğiyle Ethereum'un neden ölçeklenemeyeceğini araştıracaktır.

Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten de üçgen paradoksunu çözüyor: Bu, istemcilerin yalnızca az miktarda veri indirmesine ve çok az hesaplama yaparak belirli miktarda verinin kullanılabilir olduğunu ve belirli hesaplama adımlarının doğru bir şekilde gerçekleştirildiğini doğrulamasına olanak tanır. SNARK'lar güvene dayalı değildir. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli sunar, ancak ölçeklenemez zincirin temel özelliklerini korur; bu, %51 saldırılarının kötü blokların ağ tarafından kabul edilmesini zorlaştıramayacağı anlamına gelir.

Üç zorluk durumunu çözmenin bir diğer yolu Plasma mimarisidir; bu, kullanıcıların veri kullanılabilirliğini denetleme sorumluluğunu ustaca üstlenmesini sağlar. 2017-2019 yılları arasında, yalnızca dolandırıcılık kanıtları ile hesaplama kapasitesini genişletebildiğimizde, Plasma güvenli yürütme açısından oldukça sınırlıydı, ancak SNARK'ların yaygınlaşmasıyla birlikte Plasma mimarisi daha geniş kullanım senaryoları için daha uygulanabilir hale geldi.

Veri Erişilebilirliği Örneklemesinin Daha Fazla Gelişimi

Hangi sorunu çözmeye çalışıyoruz?

2024 yılının 13 Mart'ında, Dencun yükseltmesi çevrimiçi olduğunda, Ethereum blok zincirinde her 12 saniyede 3 adet yaklaşık 125 kB blob bulunmaktadır; yani her slot için veri kullanılabilir bant genişliği yaklaşık 375 kB'dir. İşlem verilerinin doğrudan zincir üzerinde yayınlandığını varsayarsak, ERC20 transferi yaklaşık 180 bayt olduğuna göre, Ethereum üzerindeki Rollup maksimum TPS'si: 375000 / 12 / 180 = 173.6 TPS.

Ethereum calldata( teorik maksimum değeri: her slot 30 milyon Gas / her byte 16 gas = her slot 1,875,000 byte), bu da 607 TPS'ye dönüşüyor. PeerDAS kullanarak, blob sayısı 8-16'ya kadar çıkabilir, bu da calldata'ya 463-926 TPS sağlayacaktır.

Bu, Ethereum L1 için önemli bir yükseltme, ama yeterli değil. Daha fazla ölçeklenebilirlik istiyoruz. Orta vadeli hedef, her slotta 16 MB olup, Rollup veri sıkıştırma iyileştirmeleri ile birlikte yaklaşık ~58000 TPS getirecektir.

Bu nedir? Nasıl çalışır?

PeerDAS, "1D sampling" için nispeten basit bir uygulamadır. Ethereum'da, her blob 253 bit asal alan üzerinde 4096. dereceden bir polinomdur. Polinomun paylarını yayıyoruz, her pay toplam 8192 koordinattan komşu 16 koordinattaki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden, herhangi bir 4096 ( mevcut teklif parametrelerine göre: 128 olası örnekten herhangi bir 64 ) blob'u geri kazanılabilir.

PeerDAS'ın çalışma prensibi, her bir istemcinin az sayıda alt ağı dinlemesini sağlamaktır; i'inci alt ağ, herhangi bir blob'un i'inci örneğini yayar ve global p2p ağındaki eşlerden ('e, farklı alt ağları dinleyecek olanları sorduğunda ihtiyaç duyduğu diğer alt ağlardaki blob'u talep eder. Daha temkinli bir versiyon olan SubnetDAS, yalnızca alt ağ mekanizmasını kullanır ve ek bir eş katmanına soru sormaz. Mevcut öneri, hisse kanıtı düğümlerinin SubnetDAS'ı kullanmasını sağlarken, diğer düğümler ) yani ( müşterileri PeerDAS'ı kullanır.

Teorik olarak, "1D sampling" ölçeğini oldukça genişletebiliriz: Eğer blob maksimum sayısını 256) hedefi 128('e çıkarırsak, 16MB hedefine ulaşabiliriz, ve veri kullanılabilirliği örneklemesinde her düğüm için 16 örnek * 128 blob * her blob için her örnek 512 bayt = her slot için 1 MB veri bant genişliği. Bu, sadece zaruri tolerans aralığında: uygulanabilir, ancak bant genişliği kısıtlı istemcilerin örnekleme yapamayacağı anlamına gelir. Blob sayısını azaltıp blob boyutunu artırarak optimize edebiliriz, ancak bu yeniden yapılandırma maliyetini daha yüksek hale getirir.

Bu nedenle, nihayetinde daha ileri gitmek istiyoruz ve 2D örnekleme yapmak istiyoruz; bu, yalnızca blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmayı da içeriyor. KZG taahhüdünün lineer özelliklerinden faydalanarak, bir bloktaki blob kümesini yeni sanal blob kümesi ile genişletiyoruz; bu sanal bloblar aynı bilgiyi fazla kodlamaktadır.

Önemli olan, hesaplama taahhüt genişletmelerinin blob'a ihtiyaç duymadığıdır, bu nedenle bu çözüm temelde dağıtılmış blok inşasına dosttur. Gerçek blokları inşa eden düğümler yalnızca blob KZG taahhütlerine sahip olmalıdır, bunlar veri kullanılabilirliği örneklemesi ile veri bloklarının kullanılabilirliğini doğrulamak için güvenebilirler. Tek boyutlu veri kullanılabilirliği örneklemesi de esasen dağıtılmış blok inşasına dosttur.

![Vitalik yeni makale: Ethereum'un olası geleceği, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(

) Ne yapılması gerekiyor? Hangi dengeler var?

Sonraki adım, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Sonrasında, PeerDAS üzerindeki blob sayısını sürekli artırmak, aynı zamanda ağı dikkatlice gözlemlemek ve güvenliği sağlamak için yazılımı geliştirmek gerekecek; bu, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümleri ile bunların fork seçim kuralları gibi güvenlik sorunlarıyla etkileşimini düzenlemek için daha fazla akademik çalışmanın olmasını umuyoruz.

Gelecekte daha uzak bir aşamada, 2D DAS'ın ideal versiyonunu belirlemek ve güvenlik özelliklerini kanıtlamak için daha fazla çalışmaya ihtiyacımız var. Ayrıca, KZG'den kuantum güvenli ve güvenilir bir kurulum gerektirmeyen alternatiflere geçmeyi umuyoruz. Şu anda, dağıtık blok inşasına dost olan hangi adayların olduğu net değil. Pahalı "kaba kuvvet" teknolojisini kullansak bile, yani tekrar eden STARK'ı satır ve sütunların yeniden inşası için geçerlilik kanıtları oluşturmak amacıyla kullansak bile, bu ihtiyaçları karşılamaya yetmiyor, çünkü teknik olarak STARK boyutu O###log(n( * log)log(n() hash değeri ) ile STIR( kullanılsa da, gerçekte STARK neredeyse tüm blob kadar büyüktür.

Uzun vadeli gerçek yolun şöyle olduğunu düşünüyorum:

1. İdeal 2D DAS uygulaması;
2. Basitlik ve sağlamlık için daha düşük veri üst sınırını kabul ederek, 1D DAS kullanmaya devam edin, örnekleme bant genişliği verimliliğinden ödün verin.
3. DA'yı terk et, Plasma'yı ana Layer2 mimarimiz olarak tamamen kabul et.

Lütfen dikkat edin, L1 katmanında doğrudan genişletme kararını alsak bile, bu seçeneğin var olduğu. Bunun nedeni, eğer L1 katmanı büyük miktarda TPS işlemek zorundaysa, L1 bloklarının çok büyük hale geleceği ve istemcilerin bunların doğruluğunu doğrulamak için verimli yöntemlere ihtiyaç duyacağıdır. Bu nedenle, L1 katmanında Rollup) ile ZK-EVM ve DAS( gibi aynı teknolojileri kullanmak zorunda kalacağız.

) Yol haritasının diğer bölümleriyle nasıl etkileşim kurabilirim?

Eğer veri sıkıştırması gerçekleştirilirse, 2D DAS'a olan talep azalacak veya en azından gecikecek; eğer Plasma yaygın olarak kullanılırsa, talep daha da azalacaktır. DAS ayrıca dağıtık blok inşa protokolleri ve mekanizmaları için de zorluklar ortaya koymaktadır: Teorik olarak DAS, dağıtık yeniden inşaya dost olsa da, bu pratikte paket dahil etme listesi önerileri ve etrafındaki çatallama seçim mekanizması ile birleştirilmesi gerekmektedir.

![Vitalik yeni makale: Ethereum'un olası geleceği, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(

Veri Sıkıştırma

) Hangi sorunu çözüyoruz?

Rollup'taki her işlem büyük miktarda zincir üstü veri alanı kaplar: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirliği örneklemesi olsa bile, bu Layer protokollerinin ölçeklenebilirliğini kısıtlar. Her slot 16 MB, şunu elde ederiz:

16000000 / 12 / 180 = 7407 TPS

Eğer sadece payda problemlerini değil, aynı zamanda pay problemlerini de çözebilirsek ve her Rollup'taki işlemlerin zincirde daha az bayt kaplamasını sağlayabilirsek, ne olur?

Bu nedir, nasıl çalışır?

Bana göre, en iyi açıklama bu resim iki yıl önce:

![Vitalik yeni makale: Ethereum'un olası geleceği, The Surge]###https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp(

Sıfır bayt sıkıştırmasında, her uzun sıfır bayt dizisini iki bayt ile değiştirerek kaç tane sıfır bayt olduğunu gösteriyoruz. Daha da ileri giderek, işlemle ilgili belirli özellikleri kullandık:

İmza Birleştirme: ECDSA imzasından BLS imzasına geçiyoruz. BLS imzasının özelliği, birden fazla imzanın tek bir imzada birleştirilebilmesidir ve bu imza, tüm orijinal imzaların geçerliliğini kanıtlayabilir. L1 katmanında, birleştirme olsa bile doğrulama hesaplama maliyeti yüksek olduğundan BLS imzasının kullanılması düşünülmüyor. Ancak L2 gibi veri kıtlığı ortamlarında BLS imzasının kullanılması anlamlıdır. ERC-4337 birleştirme özelliği, bu işlevselliği gerçekleştirmek için bir yol sağlamaktadır.

Adresleri pointer ile değiştirme: Eğer daha önce belirli bir adres kullanıldıysa, 20 baytlık adresi tarih kaydındaki bir konuma işaret eden 4 baytlık pointer ile değiştirebiliriz.

İşlem değeri özelleştirilmiş seri hale getirme: Çoğu işlem değeri çok az basamağa sahiptir, örneğin, 0.25 ETH 250.000.000.000.000.000 wei olarak temsil edilir. Maksimum temel işlem ücreti ve öncelikli işlem ücreti de benzer şekilde. Bu nedenle, çoğu para birimi değerini temsil etmek için özelleştirilmiş ondalıklı kayan nokta formatını kullanabiliriz.

) daha ne yapılması gerekiyor, hangi dengeler var?

Bir sonraki aşamada, yukarıdaki planı gerçeğe dönüştürmek için ana olarak yapılması gerekenlerdir. Ana dengeler şunlardır:

1. BLS imzasına geçmek büyük çaba gerektirecek ve güvenliği artıran güvenilir donanım çipleri ile uyumluluğu azaltacaktır. Bunun yerine diğer imza şemalarının ZK-SNARK paketleri kullanılabilir.

2. Dinamik sıkıştırma ### Örneğin, adresleri ( ile işaretleyicilerle değiştirmek istemci kodunu karmaşıklaştırır.

3. Durum farklarını işlemler yerine zincire yayınlamak, denetlenebilirliği azaltır ve birçok yazılım ) gibi blok gezginleri ( çalışamaz hale getirir.

) Yol haritasının diğer bölümleriyle nasıl etkileşim kurabilirim?

ERC-4337'yi benimseyerek, nihayetinde içeriğinin bir kısmını dahil edecek.