Ethereum'in Olası Geleceği: The Surge

Ethereum'un yol haritası başlangıçta iki tür ölçeklenme stratejisi içeriyordu: parçalama ve Layer2 protokolleri. Bu iki yol sonunda birleştirilerek Rollup merkezli bir yol haritası oluşturdu ve bu hala Ethereum'un genişleme stratejisidir. Rollup merkezli yol haritası basit bir iş bölümü öneriyor: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olmayı hedeflerken, L2 ekosistemin genişlemesine yardımcı olma görevini üstleniyor.

Bu yıl, Rollup merkezli yol haritası önemli sonuçlar elde etti: EIP-4844 blobs'un piyasaya sürülmesiyle birlikte Ethereum L1'in veri bant genişliği büyük ölçüde arttı ve birçok Ethereum Sanal Makinesi Rollup'ı ilk aşamaya girdi. Her L2, kendi iç kuralları ve mantığına sahip bir "parça" olarak var olmaktadır; parça uygulama çeşitliliği ve çok yönlülüğü artık bir gerçek haline geldi. Ancak bu yol bazı benzersiz zorluklarla da karşı karşıya. Bu nedenle, şu anda görevimiz Rollup merkezli yol haritasını tamamlamak ve bu sorunları çözmek, aynı zamanda Ethereum L1'in kendine özgü sağlamlığı ve merkeziyetsizliğini korumaktır.

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ı koruyun;

3. En azından bazı L2'ler Ethereum'un temel özelliklerini tamamen devraldı ( güvene dayalı, açık, sansüre dayanıklı );

4. Ethereum, 34 farklı blok zinciri değil, birleşik bir ekosistem gibi hissettirmelidir.

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

1. Ölçeklenebilirlik Üçgen Paradoksu
2. Veri erişilebilirliği örneklemesinin daha ileri ilerlemesi
3. Veri Sıkıştırma
4. Genelleştirilmiş Plasma
5. Olgun L2 kanıt sistemi
6. L2'ler arası etkileşim iyileştirmeleri
7. L1 üzerinde genişletilmiş yürütme

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgeni paradoksu, blok zincirinin üç özelliği arasında bir çelişki olduğunu savunur: merkeziyetsizlik ( daha spesifik olarak: çalışan düğümlerin maliyeti düşük ), ölçeklenebilirlik ( işlenen işlem sayısı fazla ) 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ü devre dışı bırakması gerektiği ).

Dikkate değer bir nokta, üçgen paradoksunun bir teorem olmaması ve üçgen paradoksunu tanıtan gönderilerin matematiksel bir kanıtla birlikte gelmemesidir. Ancak, şunu açıkça belirtiyor: Eğer bir merkeziyetsiz dostu düğüm ( örneğin bir tüketici dizüstü bilgisayarı ) her saniye N adet işlem doğruluyorsa ve sizde her saniye k*N adet işlem işleyen bir blok zinciri varsa, o zaman (i) her işlem yalnızca 1/k düğüm tarafından görülebilir, bu da demektir ki, saldırganlar sadece birkaç düğümü hedef alarak kötü niyetli bir işlem gerçekleştirebilir veya (ii) düğümünüz güçlü hale gelecek ve zinciriniz merkeziyetsiz olmayacaktır. Bu makalenin amacı, üçgen paradoksunu kırmanın imkansız olduğunu kanıtlamak değildir; aksine, üçlü paradoksu kırmanın zor olduğunu ve bu argümanın içerdiği düşünce çerçevesinin bir ölçüde dışına çıkılmasını gerektirdiğini göstermektir.

Yıllardır, bazı yüksek performanslı zincirler, mimarilerini temelinden değiştirmeden üçlü tezatı çözdüklerini iddia etmektedir, genellikle yazılım mühendisliği tekniklerini kullanarak düğümleri optimize ederek. Bu her zaman yanıltıcıdır, çünkü bu zincirlerde düğüm çalıştırmak, Ethereum'da düğüm çalıştırmaktan çok daha zordur. Bu makale, bunun neden böyle olduğunu ve sadece L1 istemci yazılım mühendisliğinin Ethereum'u ölçeklendiremeyeceğini neden açıklayacaktır?

Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleştirilmesi gerçekten üçgen paradoksunu çözmektedir: Bu, istemcilerin yalnızca az miktarda veri indirerek ve çok az hesaplama yaparak belirli bir miktardaki verinin mevcut olduğunu ve belirli bir miktardaki hesaplama adımının doğru bir şekilde yürütüldüğünü doğrulamasına olanak tanır. SNARK'lar güvene dayanmayan yapılardır. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeline sahiptir, ancak 51% saldırısının kötü blokların ağ tarafından kabul edilmesini zorlamayacağı temel özellikleri korur.

Üç zorluk sorununu çözmenin bir diğer yolu Plasma mimarisidir; bu, gözetim verilerinin kullanılabilirliğini kullanıcıların sorumluluğuna aktaran akıllı bir teknoloji kullanarak uyumlu bir şekilde teşvik eder. 2017-2019 yılları arasında, yalnızca dolandırıcılık kanıtı gibi bir araçla hesaplama kapasitesini genişletmeye çalıştığımızda, Plasma güvenli uygulama açısından oldukça sınırlıydı. Ancak SNARKs( sıfır bilgi kısa etkileşimsiz kanıt)nin yaygınlaşmasıyla birlikte, Plasma mimarisi daha önce hiç olmadığı kadar geniş bir kullanım senaryosu için uygulanabilir hale geldi.

Veri Erişilebilirliği Örneklemesinde İleri Gelişmeler

Hangi sorunu çözüyoruz?

13 Mart 2024'te Dencun yükseltmesi çevrimiçi olduğunda, Ethereum blok zincirinin her 12 saniyelik slotunda 3 adet yaklaşık 125 kB blob veya her slot için verinin kullanılabilir bant genişliği yaklaşık 375 kB olacaktır. İşlem verilerinin doğrudan zincir üzerinde yayınlandığını varsayarsak, ERC20 transferi yaklaşık 180 bayt olduğundan, Ethereum üzerindeki Rollup'un maksimum TPS'si: 375000 / 12 / 180 = 173.6 TPS

Eğer Ethereum'un calldata( teorik maksimum değeri eklenirse: her slot 30 milyon Gas / her byte 16 gas = her slot 1.875.000 byte), bu 607 TPS'ye dönüşür. 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 iyileştirme, ancak yeterli değil. Daha fazla ölçeklenebilirlik istiyoruz. Orta vadeli hedefimiz her bir slot için 16 MB, eğer Rollup veri sıkıştırma iyileştirmeleriyle birleştirilirse, yaklaşık ~58000 TPS sağlayacak.

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 çoktanrılıktır. (prime field). Polinomun paylarını yayınlıyoruz, burada her pay, toplam 8192 koordinattan yan yana olan 16 koordinat üzerindeki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden, mevcut önerilen parametrelere göre, 128 olası örnekten herhangi bir 64'ü ( blob'u geri yüklemek için kullanılabilir.

PeerDAS'ın çalışma prensibi, her istemcinin az sayıda alt ağı dinlemesini sağlamaktır. Burada i. alt ağ herhangi bir blob'un i. örneğini yayınlamakta ve küresel p2p ağındaki eşler )'den, farklı alt ağları dinleyecek olanları sorgulayarak ihtiyaç duyduğu diğer alt ağlardaki blob'ları talep etmektedir. Daha temkinli bir versiyon olan SubnetDAS, ek eş katman sorguları olmaksızın yalnızca alt ağ mekanizmasını kullanmaktadır. Mevcut öneri, hisse kanıtına katılan düğümlerin SubnetDAS kullanması, diğer düğümlerin ise ( 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'ların maksimum sayısını 256( hedefine 128) artırı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 byte = her slot için 1 MB veri bant genişliği elde ederiz. Bu, tolerans aralığımızın sınırlarında zorla kalıyor: 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ıracaktır.

Bu nedenle, nihayet daha ileri gitmek istiyoruz, 2D örnekleme (2D sampling), bu yöntem yalnızca blob içinde rastgele örnekleme yapmakla kalmaz, aynı zamanda bloblar arasında rastgele örnekleme de yapar. KZG taahhüdünün lineer özelliklerini kullanarak, bir bloktaki blob kümesini genişletmek için yeni sanal blob seti aracılığıyla, bu sanal bloblar aynı bilgiyi gereksiz yere kodlamaktadır.

Bu nedenle, nihayetinde daha ileri gitmek istiyoruz, 2D örnekleme yapmak istiyoruz, bu hem blob içinde hem de bloblar arasında rastgele örnekleme yapmayı içeriyor. KZG taahhüdünün lineer özelliği, aynı bilgiyi fazla kodlayan yeni sanal blob listesini içeren bir bloğun blob setini genişletmek için kullanılır.

Son derece önemlidir ki, taahhütlerin genişletilmesi için blob'a ihtiyaç yoktur, 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üdüne sahip olmalıdır ve veri kullanılabilirliği örneklemesi (DAS) üzerinden 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.

( Ne yapmamız gerekiyor? Hangi dengelemeler var?

Sonraki adım, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Daha sonra, PeerDAS üzerindeki blob sayısını sürekli artırırken, ağı dikkatlice gözlemleyip yazılımı geliştirmek, güvenliği sağlamak için kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS versiyonları ile fork seçim kuralları güvenliği gibi konuların etkileşimlerini düzenlemek için 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, sonunda KZG'den kuantum güvenli ve güvenilir bir kurulum gerektirmeyen bir alternatif çözüme geçmeyi umuyoruz. Şu anda, dağıtık blok inşasına dost olan hangi adayların bulunduğuna dair net bir bilgiye sahip değiliz. Pahalı "kaba kuvvet" teknolojisi kullanarak, yani yeniden oluşturma işlemleri için geçerlilik kanıtları üretmek amacıyla yinelemeli STARK kullanmak bile talebi 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ıyor olsa da, 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'ı uygulayın;
2. 1D DAS kullanmaya devam edin, örnekleme bant genişliği verimliliğinden feragat edin, basitlik ve dayanıklılık için daha düşük veri üst sınırını kabul edin.
3. DA'yı bırakıyoruz ve Plasma'yı odaklandığımız ana Layer2 mimarisi olarak tamamen kabul ediyoruz.

Lütfen dikkat edin, eğer L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçeneğin mevcut olduğu. Bunun nedeni, eğer L1 katmanı yüksek bir TPS işlemek zorundaysa, L1 bloklarının çok büyük hale geleceği ve istemcilerin bunların doğruluğunu verimli bir şekilde doğrulamak için bir yöntem arayacağıdır, bu nedenle L1 katmanında Rollup) gibi ZK-EVM ve DAS) ile aynı teknolojileri kullanmak zorunda kalacağız.

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

Veri sıkıştırması gerçekleştirilirse, 2D DAS'a olan talep azalacaktır veya en azından ertelenecektir. Plasma yaygın olarak kullanılıyorsa, talep daha da azalacaktır. DAS, dağıtılmış blok inşa protokollerine ve mekanizmalarına da zorluklar getirmektedir: Teorik olarak DAS, dağıtılmış yeniden yapılandırmaya dosttur, ancak pratikte bu, paket dahil etme listesi önerisi ve etrafındaki fork seçim mekanizması ile bir araya getirilmelidir.

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

Veri Sıkıştırma

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

Rollup'taki her işlem büyük miktarda zincir üzerindeki veri alanını tüketir: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirliği örneklemesi olsa bile, bu Layer protokollerinin ölçeklenebilirliğini sınırlamaktadır. Her slot 16 MB, elde ettiğimiz:

16000000 / 12 / 180 = 7407 TPS

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

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

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

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

Sıfır bayt sıkıştırmasında, her uzun sıfır bayt dizisini temsil etmek için iki bayt kullanılarak kaç tane sıfır bayt olduğu belirtilir. Daha da ileri giderek, işlemlerin avantajını sağladık.