Vitalik'in Yeni Yazısı: Ethereum'un Olası Geleceği, The Surge

Ethereum'un yol haritası başlangıçta iki genişleme stratejisi içeriyordu: parçalama ve Layer2 protokolleri. Parçalama, her bir düğümün yalnızca kısmi işlemleri doğrulayıp saklamasını sağlarken, Layer2 Ethereum'un üzerinde bir ağ inşa eder, güvenliğinden yararlanırken çoğu veriyi ve hesaplamayı ana zincir dışında tutar. Araştırmalar derinleştikçe, bu iki yol bir araya geldi ve Rollup merkezli bir yol haritası oluşturdu; bu, günümüzde hâlâ 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 model, toplumda her yerde mevcuttur: Mahkeme sistemi (L1), süper hızlı ve verimli olma amacı taşımaktan çok, sözleşmeleri ve mülkiyet haklarını korumak içindir, girişimciler (L2) ise bu sağlam temel katmanın üzerine inşa ederek insanlığı Mars'a götürmeye çalışıyor.

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 büyük ölçüde arttı, birçok Ethereum sanal makinesi (EVM) Rollup ilk aşamaya geçti. Her L2, kendine özgü iç kuralları ve mantığı olan "parçalar" olarak varlık gösteriyor, parça uygulama yöntemlerinin çeşitliliği ve çok çeşitliliği artık bir gerçek haline geldi. Ancak gördüğümüz gibi, bu yolda bazı benzersiz zorluklarla karşılaşmak da kaçınılmaz. Bu nedenle, şu anki görevimiz Rollup merkezli yol haritasını tamamlamak ve bu sorunları çözerken Ethereum L1'in kendine özgü sağlamlığı ve merkeziyetsizliğini korumaktır.

The Surge: Ana Hedefler

1. Gelecekte Ethereum L2 ile 100.000'in üzerinde TPS'ye ulaşabilir;

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

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

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

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

1. Ölçeklenebilirlik Üçgen Paradoksu
2. Veri kullanılabilirliği örneklemesinin daha fazla ilerlemesi
3. Veri Sıkıştırma
4. Genel Plasma
5. Olgun L2 kanıt sistemi
6. L2 arasında etkileşim iyileştirmeleri
7. L1 üzerinde genişletme yürütme

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgen paradoksu, 2017'de ortaya atılan bir fikir olup, blok zincirinin üç özelliği arasında çelişki olduğunu ileri sürmektedir: merkeziyetsizlik ( daha spesifik olarak: çalışan düğümlerin maliyeti düşük ), ölçeklenebilirlik ( işlenen işlem sayısı çok ) ve güvenlik ( saldırganların bir işlemi başarısız kılmak için ağdaki çok büyük bir kısmı hedef alması gerekmektedir ).

Dikkate değer bir nokta, üçgen paradoksunun bir teorem olmaması ve üçgen paradoksunu tanıtan gönderinin matematiksel bir kanıtla birlikte gelmemesidir. Gerçekten de, bir merkeziyetsiz dostu düğüm ( örneğin bir tüketici dizüstü bilgisayarı ) her saniyede N işlemi doğrulayabiliyorsa ve senin her saniyede k*N işlem işleyebilen bir zincirin varsa, o zaman (i) her işlem yalnızca 1/k kadar düğüm tarafından görülebilir, bu da demektir ki, bir saldırgan yalnızca birkaç düğümü yok ederek kötü niyetli bir işlem gerçekleştirebilir, veya (ii) senin düğümün güçlü hale gelirken zincirin merkezileşmeyecektir. Bu makalenin amacı, üçgen paradoksunu çiğnemenin imkansız olduğunu kanıtlamak değildir; aksine, üçlü paradoksu çiğnemenin zor olduğunu ve belirli bir ölçüde bu argümanın içerdiği düşünce çerçevesinin dışına çıkmayı gerektirdiğini göstermektir.

Yıllardır, bazı yüksek performanslı zincirler, mimariyi temelden değiştirmeden üçlü paradoksu çözdüklerini iddia ediyorlar, genellikle düğümleri optimize etmek için yazılım mühendisliği teknikleri uygulayarak. 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, bunun neden böyle olduğunu ve yalnızca L1 istemci yazılım mühendisliğinin kendisinin Ethereum'u ölçeklendiremeyeceğini araştıracaktır.

Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten üçgen paradoksunu çözüyor: Bu, istemcilerin yalnızca az miktarda veri indirerek ve çok az miktarda 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ına olanak tanır. SNARK'lar güvenilmezdir. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeline sahiptir, ancak ölçeklenemez zincirlerin sahip olduğu temel özellikleri korur; yani, %51 saldırıları bile kötü blokların ağ tarafından kabul edilmesini zorlayamaz.

Üçlü zorlukları çözmenin bir diğer yolu Plasma mimarisidir; bu mimari, kullanıcıların veri kullanılabilirliğini izleme sorumluluğunu teşvik edici bir şekilde üstlenmelerini sağlamak için zekice bir teknoloji kullanır. 2017-2019 yıllarında, yalnızca dolandırıcılık kanıtı ile hesaplama kapasitesini genişletme imkanımız olduğunda, Plasma güvenli uygulama açısından oldukça sınırlıydı; ancak SNARKs( sıfır bilgi kısa etkileşimsiz kanıtlarının) yaygınlaşmasıyla birlikte, Plasma mimarisi daha önceki kullanım senaryolarına göre daha geniş bir yelpazede uygulanabilir hale geldi.

Veri Erişilebilirliği Örnekleme ile İlgili İlerlemeler

Hangi sorunu çözüyoruz?

2024年3月13日,当Dencun升级上线时, Ethereum区块链每12秒的slot有3个约125 kB blob, 或每个slot的数据可用带宽约375 kB。假设交易数据直接在链上发布, 则ERC20转账约为180字节, 因此Ethereum上Rollup的最大TPS为: 375000 / 12 / 180 = 173.6 TPS

Eğer Ethereum'un calldata( teorik maksimum değerini eklersek: her slot 30 milyon Gas / her bayt 16 gas = her slot 1.875.000 bayt), bu durumda 607 TPS olur. PeerDAS kullanıldığında, blob sayısı 8-16'ya kadar çıkabilir, bu da calldata için 463-926 TPS sağlayacaktır.

Bu, Ethereum L1 için önemli bir yükseltme, ancak 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ştirmeleriyle birleştirilirse, yaklaşık ~58000 TPS getirecektir.

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

PeerDAS, "1D sampling"ın nispeten basit bir uygulamasıdır. Ethereum'da, her blob, 253 bit asal alan (prime field) üzerindeki 4096. dereceden bir polinomdur (polynomial). Polinomun paylarını yayınlıyoruz, burada her pay, toplam 8192 koordinattan komşu 16 koordinattaki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinin herhangi bir 4096'ı (, mevcut sunulan parametreye 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'inci alt ağ, herhangi bir blob'un i'inci örneğini yayınlar ve küresel p2p ağındaki eşlerden (, dinleyecekleri farklı alt ağları sorduğunda, ihtiyaç duyduğu diğer alt ağlardaki blob'ları talep eder. Daha temkinli bir versiyon olan SubnetDAS yalnızca alt ağ mekanizmasını kullanır ve ek bir eş katmanına sorgulama yapmaz. Mevcut öneri, hisse kanıtına katılan düğümlerin SubnetDAS'ı kullanması, diğer düğümlerin ise ), yani müşterilerin (, PeerDAS'ı kullanmasıdır.

Teorik olarak, "1D sampling" ölçeğini oldukça büyük ölçüde genişletebiliriz: Eğer blob'ların maksimum sayısını 256) hedefi 128('e çıkarırsak, o zaman 16MB hedefine ulaşabiliriz ve veri kullanılabilirliği örneklemesinde her düğüm 16 örnek * 128 blob * her blob başına her örnek 512 bayt = her slot için 1 MB veri bant genişliği sağlar. Bu, yalnızca tolerans aralığımızda zorla kalmaktadır: 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 bir dereceye kadar optimize edebiliriz, ancak bu yeniden yapılandırma maliyetini artıracaktır.

Bu nedenle, nihayet daha ileri gitmek istiyoruz, 2D örnekleme )2D sampling(, bu yöntem sadece blob içinde rastgele örnekleme yapmakla kalmıyor, aynı zamanda bloblar arasında da rastgele örnekleme yapıyor. KZG taahhüdünün lineer özelliklerinden faydalanarak, bir bloktaki blob kümesini genişletmek için yeni bir sanal blob seti kullanıyoruz, bu sanal bloblar aynı bilgiyi gereksiz yere kodluyor.

Bu nedenle, nihayetinde daha ileri gitmek istiyoruz, 2D örnekleme yapmak istiyoruz, bu sadece blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmaktır. KZG taahhüdünün lineer özelliği, aynı bilgiyi yedek kodlama yapan yeni sanal blob listesinin bulunduğu bir bloğun blob kümesini genişletmek için kullanılır.

Son derece önemlidir ki, hesaplama taahhütlerinin genişletilmesi için blob'a ihtiyaç yoktur, bu nedenle bu çözüm temelde dağıtık blok inşasına dosttur. Gerçekten blok inşa eden düğümler yalnızca blob KZG taahhüdüne sahip olmalıdır ve veri kullanılabilirliği örneklemesi )DAS( kullanarak veri bloklarının kullanılabilirliğini doğrulayabilirler. Tek boyutlu veri kullanılabilirliği örneklemesi )1D DAS( esasen dağıtık blok inşasına dosttur.

) Ne yapmamız gerekiyor? Hangi dengeler mevcut?

Sonraki adım, 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özlemleyerek yazılımı geliştirmek, kademeli bir süreçtir. Bu arada, PeerDAS ve diğer DAS sürümleri ile fork seçim kuralları güvenliği gibi sorunların 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ışma yapmamız gerekecek. Ayrıca, nihayetinde KZG'den kuantum güvenli ve güvenilir bir ayar gerektirmeyen bir alternatife geçebilmeyi umuyoruz. Şu anda, dağıtılmış blok inşası için hangi adayların dostça olduğu konusunda belirsiziz. Pahalı "brute force" tekniklerini kullanmak, yani yeniden yapılandırma için geçerlilik kanıtları oluşturmak üzere yineleyici STARK kullanmak bile, 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 hesaplanabilir, ancak pratikte STARK neredeyse tüm blob kadar büyüktür.

Uzun vadeli gerçek yolunun şu olduğunu düşünüyorum:

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 bir veri üst sınırını kabul edin.
3. DA'dan vazgeçin, Plasma'yı ana Layer2 mimarimiz olarak tamamen kabul edin.

Lütfen dikkat edin, L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçeneğin de mevcut olduğunu. Bunun nedeni, eğer L1 katmanı çok sayıda 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ı teknolojiyi kullanmak zorunda kalacağız.

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

Veri sıkıştırması gerçekleştirilirse, 2D DAS'a olan talep azalacak ya da en azından ertelenecek; eğer Plasma yaygın olarak kullanılıyorsa, talep daha da azalacak. DAS ayrıca dağıtılmış blok inşa protokollerine ve mekanizmalarına meydan okumaktadır: teorik olarak DAS, dağıtılmış yeniden inşa için dosttur, ancak bu uygulamada paket dahil etme listesi önerisi ve çevresindeki fork seçim mekanizması ile bir araya getirilmesi gerekmektedir.

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

Veri Sıkıştırma

) Hangi problemi çözüyoruz?

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

16000000 / 12 / 180 = 7407 TPS

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

O 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-5d1a322bd6b6dfef0dbb78017226633d.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 belirtiriz. Daha ileri giderek, işlemin belirli özelliklerinden yararlandık:

İmza Birleşimi: ECD'den