Ethereum'ın Olası 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 yöntem sonunda birleştirildi ve Rollup merkezli bir yol haritası oluşturdu, bu hala Ethereum'un mevcut genişleme stratejisidir.

Rollup merkezli yol haritası, basit bir iş bölümünü öne sürüyor: 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 oldukça yaygındır: Mahkeme sistemi (L1), sözleşmeleri ve mülkiyet haklarını korumak için varken, girişimciler (L2) bu temelin üzerine inşa ederek insan gelişimini ilerletiyor.

Bu yıl, Rollup merkezli yol haritasında önemli ilerlemeler kaydedildi: EIP-4844 bloblarının piyasaya sürülmesiyle birlikte Ethereum L1'in veri bant genişliği büyük ö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 var olmaktadır, parça uygulama çeşitliliği ve çokluğu artık bir gerçek haline geldi. Ancak bu yol 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'in kendine özgü sağlamlık ve merkeziyetsizlik özelliklerini korumaktır.

The Surge: Ana Hedefler

1. Gelecekte Ethereum, L2 üzerinden 100.000'den fazla 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üvensiz, açık, sansüre dayanıklı ) 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 örneklemesindeki daha fazla ilerleme
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ş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ürmektedir: merkeziyetsizlik ( işletim düğümlerinin düşük maliyeti ), ölçeklenebilirlik ( işlenen işlem sayısının fazla olması ) ve güvenlik ( saldırganların bir işlemi başarısız hale getirmek için ağdaki çok sayıda düğümü yok etmesi gerektiği ).

Dikkate değer bir nokta, üçgen paradoksunun bir teorem olmadığı ve matematiksel bir kanıtının bulunmadığıdır. Bu, şu sezgisel matematik argümanını sunmaktadır: Eğer merkeziyetsiz dostu bir düğüm her saniyede N işlem doğrulayabiliyorsa ve sizin her saniyede 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, bu da demektir ki saldırganların yalnızca birkaç düğümü yok etmesi yeterlidir ki kötü niyetli bir işlem gerçekleştirebilsin, veya (ii) sizin düğümünüz güçlü hale gelecektir, ancak zinciriniz merkeziyetsiz olmayacaktır. Bu makalenin amacı, üçgen paradoksunu kırmanın imkansız olduğunu kanıtlamak değil; aksine, üçlü paradoksu kırmanın zor olduğunu ve bu argümanın ima ettiği düşünce çerçevesinin bir tür dışına çıkmayı gerektirdiğini göstermektir.

Yıllar boyunca, bazı yüksek performanslı zincirler, mimarilerini temelden değiştirmeden üçlü ikilem sorununu çö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'da 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ği ile Ethereum'un nasıl ölçeklenemeyeceğini keşfedecektir.

Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten de üçgen paradoksunu çözmektedir: 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ğrulamaları için olanak tanır. SNARK'lar güvene ihtiyaç duymamaktadır. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşır, ancak ölçeklenemez zincirlerin sahip olduğu temel özelliği korur; bu da, %51'lik bir saldırının kötü blokların ağ tarafından kabul edilmesini zorlayamayacağı anlamına gelir.

Üçlü zorlukları çözmenin bir diğer yolu Plasma mimarisidir, bu akıllı teknikleri kullanarak izleme verilerinin erişilebilirliği sorumluluğunu kullanıcıya uyumlu bir şekilde aktarmaktadır. 2017-2019 yıllarında, yalnızca dolandırıcılık kanıtı gibi bir aracımız olduğunda, Plasma'nın güvenli yürütme konusunda çok sınırlıydı, ancak SNARKs( sıfır bilgi kanıtlarının) yaygınlaşmasıyla, Plasma mimarisi daha önce hiç olmadığı kadar geniş bir kullanım senaryosu için daha uygulanabilir hale geldi.

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

Hangi sorunu çözüyoruz?

2024年3月13日,当Dencun升级上线时, Ethereum区块链 her 12 saniyede 3 yaklaşık 125 kB blob içeren slotlara sahip olacak, ya da her slotun veri kullanılabilir bant genişliği yaklaşık 375 kB olacaktır. İşlem verilerinin doğrudan zincir üzerinde yayınlandığını varsayalım, ERC20 transferi yaklaşık 180 byte olduğundan, Ethereum üzerindeki Rollup'un maksimum TPS'i: 375000 / 12 / 180 = 173.6 TPS.

Eğer Ethereum'un calldata( teorik maksimum değeri eklenirse: her slot 30 milyon Gas / her bayt 16 gas = her slot 1.875.000 bayt), bu durumda 607 TPS olur. PeerDAS kullanarak, blob sayısı 8-16'ya çı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 hedefimiz her slot için 16 MB, eğer Rollup veri sıkıştırma iyileştirmeleri ile 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 (prime field) üzerinde bir 4096. derece polinomudur(polynomial). Polinomun paylarını yayımlıyoruz; her pay, toplam 8192 koordinat arasından bitişik 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 bir 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ğındaki eşlerden ), farklı alt ağları dinleyecek olanları sorgulayarak, ihtiyaç duyduğu diğer alt ağlardaki blob'u talep eder. Daha temkinli bir versiyon olan SubnetDAS, ek eş sorgulamaları olmadan yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, iştirak eden hisse kanıtı düğümlerinin SubnetDAS kullanması ve diğer düğümlerin ( yani müşterilerin ) 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( hedefini 128) olarak artırırsak, o zaman 16MB hedefini yakalayabiliriz ve veri kullanılabilirliği örneklemesinde her düğüm 16 örnek * 128 blob * her blob için her örnek 512 bayt = her slot için 1 MB veri bant genişliğine ulaşırız. Bu, sınırlarımızın neredeyse içinde: bu mümkündür, ama 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 bir miktar optimize edebiliriz, ama bu yeniden inşa maliyetini daha yüksek hale getirir.

Bu nedenle, nihayet daha ileri gitmek istiyoruz, 2D örnekleme (2D sampling), bu yöntem sadece blob içinde rastgele örnekleme yapmakla kalmaz, aynı zamanda bloblar arasında rastgele örnekleme de gerçekleştirir. KZG taahhüdünün lineer özelliklerini kullanarak, bir bloktaki blob kümesini genişletmek için yeni bir 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 yalnızca blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapılmasıdır. 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ı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 sadece blob KZG taahhüdüne sahip olmalı ve veri kullanılabilirliği örneklemesi (DAS)'ya dayanarak veri bloklarının kullanılabilirliğini doğrulayabilirler. Bir boyutlu veri kullanılabilirliği örneklemesi (1D DAS) esasen dağıtılmış blok inşasına da dosttur.

( Ne yapılması gerekiyor? Hangi dengelemeler var?

Sonraki adım, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Ardından, PeerDAS üzerindeki blob sayısını sürekli artırırken, ağı dikkatlice izlemek ve güvenliği sağlamak için yazılımı geliştirmek gerekmektedir. Bu, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS versiyonlarının, çatallama seçim kuralları güvenliği gibi konularla etkileşimini düzenlemek için daha fazla akademik çalışmanın yapılmasını umuyoruz.

Gelecekte daha ileri aşamalarda, 2D DAS'ın ideal versiyonunu belirlemek ve güvenlik özelliklerini kanıtlamak için daha fazla çalışma yapmamız gerekecek. Ayrıca, nihayetinde KZG'den, kuantum güvenli ve güvenilir bir ayar gerektirmeyen bir alternatife geçmeyi umuyoruz. Şu anda, dağıtılmış blok inşasına dost olan adayların neler olduğunu henüz net bir şekilde bilmiyoruz. Pahalı "brute force" tekniklerini kullanarak, yani satır ve sütunları yeniden oluşturmak için geçerlilik kanıtları üretmek üzere yinelemeli STARK kullanmak bile talepleri karşılamak için yeterli değil, çünkü teknik olarak bir STARK'ın boyutu O)log###n( * log(log)n(( hash değeri ) kullanarak STIR) olmasına rağmen, pratikte STARK neredeyse tüm blob kadar büyük.

Uzun vadeli gerçeklik yolunun şöyle olduğunu düşünüyorum:

1. İdeale uygun 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 ü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şletmeyi seçersek, bu seçenek yine de mevcuttur. Bunun nedeni, eğer L1 katmanı büyük miktarda TPS'yi 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 bir yönteme ihtiyaç duyacağıdı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 kısımlarıyla nasıl etkileşimde bulunabilirim?

Eğer veri sıkıştırması gerçekleştirilirse, 2D DAS'a olan talep azalacak veya en azından ertelenecektir, eğer Plasma yaygın olarak kullanılıyorsa, talep daha da azalacaktır. DAS ayrıca dağıtılmış blok yapılandırma protokolleri ve mekanizmalarına da zorluklar getirmektedir: teorik olarak DAS, dağıtılmış yeniden inşa için dosttur, ancak bu pratikte paket dahil etme listesi önerisi ve çevresindeki çatallanma seçim mekanizması ile bir araya getirilmelidir.

Veri Sıkıştırma

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

Rollup içindeki her işlem büyük miktarda zincir üstü veri alanı kaplar: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirlik örneklemesi olsa bile, bu Layer protokollerinin ölçeklenebilirliğini kısıtlar. Her slot 16 MB, 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?

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

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

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

Sıfır bayt sıkıştırması sırasında, her uzun sıfır bayt dizisini iki bayt ile değiştirerek kaç tane sıfır bayt olduğunu belirtiriz. Daha ileri giderek, işlemin belirli özelliklerinden faydalandı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; bu imza, tüm orijinal imzaların geçerliliğini kanıtlayabilir. L1 katmanında, birleştirme yapılsa bile doğrulamanın hesaplama maliyeti yüksek olduğu için BLS imzasının kullanılması düşünülmemektedir.