Ethereum'un Geleceği: The Surge

Ethereum'un yol haritası başlangıçta iki tür ölçeklendirme stratejisi içeriyordu: parçalama ve Layer2 protokolleri. Bu iki yol nihayet birleşerek, Rollup merkezli bir yol haritası oluşturdu ki bu hala Ethereum'un mevcut genişletme stratejisidir.

Rollup merkezli yol haritası, basit bir iş bölümü öneriyor: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olmaya odaklanırken, L2 ekosistemin genişlemesine yardımcı olma görevini üstleniyor. Bu model toplumda her yerde mevcut: Mahkeme sistemi ( L1 )'in varlığı, aşırı hızlı ve verimli olma arzusuyla değil, sözleşmeleri ve mülkiyet haklarını korumak için vardır. Girişimciler ( L2 ) ise bu sağlam temel katmanın üstünde inşa etmelidir, insanları Mars'a götürmelidir.

Bu yıl, Rollup merkezli yol haritasında önemli başarılar elde edildi: EIP-4844 blobs'un piyasaya sürülmesiyle, Ethereum L1'in veri bant genişliği önemli ölçüde arttı, birçok Ethereum sanal makinesi(EVM)Rollup ilk aşamaya girdi. Her L2, kendi iç kuralları ve mantığına sahip bir "parça" olarak varlık gösteriyor, parça uygulama çeşitliliği ve çokluğu artık bir gerçek haline geldi. Ancak gördüğümüz gibi, bu yolu izlemek bazı benzersiz zorluklarla karşı karşıya. Bu nedenle, şu anki görevimiz Rollup merkezli yol haritasını tamamlamak ve bu sorunları çözmektir, aynı zamanda Ethereum L1'e özgü sağlamlık ve merkeziyetsizlikten ödün vermemek.

The Surge: Ana Hedefler

1. Gelecekte Ethereum, L2 aracılığıyla 100.000'in üzerinde TPS'ye ulaşabilir;

2. L1'in merkeziyetsizliğini ve dayanıklılığını korumak;

3. En azından bazı L2'ler, Ethereum'un temel özelliklerini ( güvenilmezlik, açıklık, sansüre dayanıklılık ) tamamen miras almıştır;

4. Ethereum, 34 farklı blok zinciri değil, bir bütünleşik ekosistem gibi hissettirmelidir.

Bu bölümün içeriği

1. Ölçeklenebilirlik Üçgen Paradoksu
2. Veri kullanılabilirliği örneklemesi ile ilgili daha fazla ilerleme
3. Veri Sıkıştırma
4. Genelleştirilmiş Plasma
5. Olgun L2 kanıt sistemi
6. L2'ler Arası İşlem Geliştirmeleri
7. L1 üzerinde genişletme yürütme

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgeni paradoksu, 2017 yılında ortaya atılan bir fikirdir. Bu fikir, blok zincirinin üç özelliği arasında bir çelişki olduğunu öne sürer: merkeziyetsizlik ( daha spesifik olarak: çalışan düğümlerin maliyeti düşük ), ölçeklenebilirlik ( işlenen işlem sayısı çok ) ve güvenlik ( bir saldırganın tek bir işlemi başarısız kılmak için ağdaki çok sayıda düğümü yok etmesi gerektiğini belirtir ).

Dikkate değer bir nokta, üçgen paradoksunun bir teorem olmamasıdır; üçgen paradoksunu tanıtan gönderiler de matematiksel bir kanıt eklememiştir. Bu, bir sezgisel matematik argümanı sunar: Eğer merkeziyetsiz dostu bir düğüm ( örneğin bir tüketici dizüstü bilgisayarı ) her saniyede N işlem doğrulayabiliyorsa ve sizin k*N işlem işleyebilen bir zinciriniz varsa, o zaman (i) her işlem yalnızca 1/k düğüm tarafından görülebilir, bu da demektir ki, saldırganların yalnızca birkaç düğümü yok etmesi yeterlidir, böylece bir kötü niyetli işlem gerçekleştirebilir, ya da (ii) düğümünüz güçlü hale gelecek, ancak zinciriniz merkeziyetsiz olmayacaktır. Bu makalenin amacı, üçgen paradoksunu kırmanın imkansız olduğunu kanıtlamak değildir; aksine, üçgen paradoksunu kırmanın zor olduğunu ve bu argümanın ima ettiği düşünce çerçevesinden bir şekilde çıkmayı gerektirdiğini göstermektir.

Uzun yıllardır, bazı yüksek performanslı zincirler, temelde mimarilerini değiştirmeden üçlü sorununu çözdüklerini iddia ediyorlar, genellikle düğümleri optimize etmek için yazılım mühendisliği becerileri kullanarak. Bu her zaman yanıltıcıdır; bu zincirler üzerinde düğüm çalıştırmak, Ethereum üzerinde düğüm çalıştırmaktan çok daha zordur. Bu makale, neden böyle olduğunu ve yalnızca L1 istemci yazılım mühendisliğinin Ethereum'u ölçeklendiremeyeceğini araştıracaktır.

Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleştirilmesi gerçekten de üçgen paradoksunu çözüyor: Bu, istemcilerin yalnızca az miktarda veri indirerek ve çok az hesaplama yaparak belirli bir miktarda verinin mevcut olduğunu ve belirli bir miktarda hesaplama adımının doğru bir şekilde gerçekleştirildiğini doğrulamasını sağlıyor. SNARK'lar güven gerektirmiyor. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşırken, 51% saldırılarının kötü blokların ağ tarafından kabul edilmesini zorlamadığı temel özellikleri koruyor.

Üçlü zorlukları çözmenin bir diğer yolu Plasma mimarisidir; bu, kullanıcıların veriye erişim sorumluluklarını teşvik edici bir şekilde üstlenmeleri için kurnaz bir teknoloji kullanır. 2017-2019 yıllarında, yalnızca dolandırıcılık kanıtı ile hesaplama kapasitesini genişletebildiğimiz zamanlarda, Plasma güvenli uygulama açısından oldukça sınırlıydı. Ancak SNARKs( sıfır bilgi, kısa, etkileşimli olmayan kanıtların) yaygınlaşmasıyla birlikte, Plasma mimarisi her zamankinden daha geniş kullanım senaryoları için daha uygulanabilir hale geldi.

Veri kullanılabilirliği örneklemesindeki daha fazla gelişme

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

2024 yılının 13 Mart'ında, Dencun güncellemesi çevrimiçi olduğunda, Ethereum blok zincirinin her 12 saniyede bir slotunda 3 adet yaklaşık 125 kB blob bulunacak veya her slotun veri kullanılabilir bant genişliği yaklaşık 375 kB olacak. Eğer işlem verileri doğrudan zincir üzerinde yayınlanırsa, ERC20 transferi yaklaşık 180 bayt olduğundan, Ethereum üzerindeki Rollup'un maksimum TPS'si şöyle hesaplanır: 375000 / 12 / 180 = 173.6 TPS

Eğer Ethereum'un calldata( teorik maksimumunu eklersek: her slot 30 milyon Gas / her byte 16 gas = her slot 1,875,000 byte), bu durumda 607 TPS olur. PeerDAS kullanarak, blob sayısı 8-16'ya çıkabilir, bu da calldata için 463-926 TPS sağlayacaktır.

Bu, Ethereum L1 için önemli bir geliştirme, ancak yeterli değil. Daha fazla ölçeklenebilirlik istiyoruz. Orta vadeli hedefimiz her slot için 16 MB'tır, eğer Rollup veri sıkıştırma iyileştirmeleriyle birleştirilirse, yaklaşık ~58000 TPS sağlayacaktır.

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

PeerDAS, "1D sampling" için nispeten basit bir uygulamadır. Ethereum'da, her blob 253 bit asal alanında 4096. dereceden bir polinomdur. Polinomun paylarını yayınlıyoruz, her pay toplam 8192 koordinattan komşu 16 koordinat üzerindeki 16 değerlendirme değerini içermektedir. Bu 8192 değerlendirme değerinden, mevcut sunulan parametreye göre: 128 olası örnekten herhangi 64'ü blob'u geri kazanmak için kullanılabilir.

PeerDAS'ın çalışma mantığı, her istemcinin az sayıda alt ağı dinlemesini sağlamaktır; burada i'nci alt ağ, herhangi bir blob'un i'nci örneğini yayınlar ve küresel p2p ağı içindeki eşler ('den, farklı alt ağları dinleyecek olanları sorgulayarak ihtiyaç duyduğu diğer alt ağlardaki blob'ları talep eder. Daha temkinli bir versiyon olan SubnetDAS, ek bir eş katman sorgulaması olmaksızın yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, paylaşımlı doğrulama (proof of stake) katılımcı düğümlerinin SubnetDAS kullanması, diğer düğümlerin ) yani istemcilerin ( PeerDAS kullanmasıdır.

Teorik olarak, "1D sampling" ölçeğini oldukça büyük bir şekilde genişletebiliriz: Eğer blob'un maksimum sayısını 256) hedef olarak 128('e çıkarırsak, o zaman 16MB'lık bir hedefe 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, tam olarak tolerans sınırlarımızda: bu mümkündür, ancak bu, bant genişliği kısıtlı istemcilerin örnekleme yapamayacağı anlamına gelir. Blob sayısını azaltarak ve blob boyutunu artırarak bunu belirli bir ölçüde optimize edebiliriz, ancak bu yeniden yapılandırma maliyetlerini artırır.

Bu nedenle, nihayetinde daha ileri gitmek istiyoruz, 2D örnekleme )2D sampling(, bu yöntem yalnızca blob içinde rastgele örnekleme yapmakla kalmaz, aynı zamanda blob'lar arasında da rastgele örnekleme yapar. KZG taahhüdünün lineer özelliklerinden yararlanarak, bir bloktaki blob kümesini yeni sanal blob'lar seti ile genişletiyoruz; bu sanal blob'lar aynı bilgiyi gereksiz yere kodlamaktadır.

Bu nedenle, nihayetinde daha ileri gitmek istiyoruz ve yalnızca blob içinde değil, bloblar arasında rastgele 2D örnekleme yapmak istiyoruz. KZG taahhüdünün lineer özellikleri, aynı bilgilere yönelik yedekleme kodlaması içeren yeni sanal blob listesinin bulunduğu bir bloktaki blob kümesini genişletmek için kullanılmaktadır.

Son derece önemlidir ki, taahhütlerin genişletilmesi için blob'a ihtiyaç yoktur; bu nedenle bu çözüm temel olarak dağıtılmış blok inşasına dosttur. Gerçek blokları inşa eden düğümlerin yalnızca blob KZG taahhüdüne sahip olmaları gerekmekte ve veri kullanılabilirliği örneklemesi )DAS( ile veri bloklarının kullanılabilirliğini doğrulamak için güvenebilirler. Tek boyutlu veri kullanılabilirliği örneklemesi )1D DAS( esasen dağıtılmış blok inşasına da dosttur.

) Daha ne yapmalıyız? Hangi dengelemeler var?

Sonraki aşama, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Ardından, PeerDAS üzerindeki blob sayısını sürekli artırmak ve güvenliği sağlamak için ağı dikkatlice gözlemleyip yazılımı geliştirmek, aşamalı bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS versiyonlarının standartlaştırılması ve fork seçim kuralları güvenliği gibi konularla etkileşimleri üzerine daha fazla akademik çalışma yapılması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ışma yapmamız gerekiyor. Ayrıca, nihayetinde KZG'den kuantum güvenli ve güvenilir bir kurulum gerektirmeyen bir alternatife geçebilmemizi umuyoruz. Şu anda, dağıtılmış blok inşası için hangi adayların dostça olduğu konusunda net bir bilgiye sahip değiliz. Pahalı "kaba kuvvet" teknolojisi kullanılsa bile, yani, satır ve sütunları yeniden inşa etmek için geçerlilik kanıtı oluşturmak üzere yinelemeli STARK kullanılsa bile, bu ihtiyaçları karşılamak için yeterli değil; çünkü teknik olarak bir STARK'ın boyutu O(log)n( * log)log(n)### hash değeri ( STIR( kullanılarak oluşturulmasına rağmen, gerçekte STARK neredeyse tüm blob kadar büyüktür.

Uzun vadeli gerçek yol olarak düşündüğüm şey şudur:

1. İdeal 2D DAS'ı uygulamak;
2. 1D DAS kullanmaya devam edin, örnekleme bant genişliği verimliliğinden feragat edin, basitlik ve sağlamlık için daha düşük veri sınırını kabul edin.
3. DA'yi bırakıp, Plasma'yı ana Layer2 mimarimiz olarak tamamen kabul ediyoruz.

Lütfen dikkat edin, L1 katmanında doğrudan genişleme yapmaya karar verirsek, bu seçeneğin de mevcut olduğunu unutmayın. Bunun nedeni, eğer L1 katmanı büyük miktarda TPS ile başa çıkmak zorundaysa, L1 bloklarının çok büyük hale geleceğidir; istemciler bunların doğruluğunu doğrulamak için verimli bir yöntem arayacaktır, bu nedenle L1 katmanında Rollup) ile ZK-EVM ve DAS( ile aynı teknolojileri kullanmak zorunda kalacağız.

( Yol haritasının diğer bölümleriyle nasıl etkileşimde bulunabilirim?

Veri sıkıştırması gerçekleştirilirse, 2D DAS'a olan talep azalacak veya en azından ertelenecektir; Plasma yaygın olarak kullanılıyorsa, talep daha da azalacaktır. DAS, dağıtık blok inşa protokolleri ve mekanizmaları için de zorluklar ortaya koymaktadır: teorik olarak DAS, dağıtık yeniden yapılandırmaya dost olsa da, bu pratikte paket dahil etme listesi önerisi ve çevresindeki çatallama seçim mekanizması ile birleştirilmesi gerekmektedir.

Veri Sıkıştırma

) Hangi sorunu çözüyoruz?

Rollup içindeki her işlem büyük miktarda zincir üstü veri alanı kullanır: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirlik örneklemesi olsa bile, bu Layer protokolünün ölçeklenebilirliğini kısıtlar. Her slot 16 MB, şöyle elde ediyoruz:

16000000 / 12 / 180 = 7407 TPS

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

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

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

![Vitalik yeni makalesi: Ethereum'un olası geleceği, The Surge])