Ethereum'in Olası Geleceği: The Surge

Ethereum'un yol haritası ilk olarak iki tür ölçeklendirme stratejisi içeriyordu: parçalama ve Layer2 protokolleri. Bu iki yol sonunda birleşerek 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ü ö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 mevcut: mahkeme sistemi (L1), sözleşmeleri ve mülkiyet haklarını korumak için var; girişimciler ise (L2) bu sağlam temel katmanın üzerinde inşa ederek insanlığın ilerlemesini sağlıyor.

Bu yıl, Rollup merkezli yol haritası önemli başarılar elde etti: EIP-4844 blobs'un piyasaya sürülmesiyle birlikte 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östermektedir, parça gerçekleştirme yöntemlerinin çeşitliliği ve çokluğunun artık bir gerçek haline geldiğini görmekteyiz. Ancak gördüğümüz gibi, bu yolu yürümek bazı benzersiz zorluklarla da karşı karşıya. Bu nedenle, şu anki görevimiz Rollup merkezli yol haritasını tamamlamak ve bu sorunları çözmek, aynı zamanda Ethereum L1'e özgü sağlamlık ve merkeziyetsizlikten ödün vermemektir.

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

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

4. Ethereum, 34 farklı blok zinciri yerine birleşik 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. 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

Skalabilite üçgen paradoksu, 2017'de öne sürülen bir fikirdir ve bununla birlikte blok zincirinin üç özelliği arasında bir çelişki olduğunu belirtir: 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ğa bağlı çok sayıda düğümü yok etmesi gerekir ).

Dikkate değer bir nokta, üçgen paradoksunun bir teorem olmamasıdır; üçgen paradoksunu tanıtan gönderiler de matematiksel bir kanıt içermemektedir. Bu, gerçekten de sezgisel bir matematiksel argüman sunmaktadır: Eğer merkeziyetsiz dostu bir düğüm ( örneğin bir tüketici dizüstü bilgisayarı kullanarak her saniye N işlem doğrulayabiliyorsa ve sizde her saniye k*N işlem işleyebilen bir zincir 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ü bozması yeterlidir ki bu da kötü niyetli bir işlemle sonuçlanır veya )ii( düğümünüz güçlü hale gelirken, 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 içerdiği düşünce çerçevesinin bir şekilde dışına çıkmayı gerektirdiğini göstermeyi amaçlamaktadır.

Yıllardır, bazı yüksek performanslı zincirler, mimariyi köklü bir şekilde değiştirmeden üçgen paradoksunu çözdüklerini iddia ediyorlar, 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ğinin Ethereum'u ölçeklendirmeye yetmeyeceğini inceleyecektir.

Ancak, veri kullanılabilirliği örneklemesi ve 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 miktarda verinin mevcut olduğunu ve belirli miktarda hesaplama adımının doğru bir şekilde gerçekleştirildiğini doğrulamalarına olanak tanır. SNARK'lar güvene ihtiyaç duymaz. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşır, ancak 51%'lik bir saldırının kötü blokların ağ tarafından kabul edilmesini zorlamayacağı temel özellikleri korur.

Üçlü zorlukları çözmenin bir diğer yolu Plasma mimarisidir; bu, izleme verilerinin erişilebilirliğinden sorumlu olmayı kullanıcıların üzerine akıllıca bir şekilde teşvik uyumlu bir yöntemle yıkar. 2017-2019 yıllarında, yalnızca dolandırıcılık kanıtına sahip olduğumuzda, Plasma güvenli yürütme açısından oldukça sınırlıydı, ancak SNARKs) sıfır bilgi sıkı etkileşimsiz kanıt(ın yaygınlaşmasıyla birlikte, Plasma mimarisi her zamankinden daha geniş kullanım senaryoları için daha uygulanabilir hale geldi.

![Vitalik yeni makalesi: Ethereum'un muhtemel geleceği, The Surge])https://img-cdn.gateio.im/webp-social/moments-6e846316491095cf7d610acb3b583d06.webp(

) Veri kullanılabilirliği örneklemesinin daha ileri gelişimi

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'sı ### teorik maksimum değeri eklersek: her slot 30 milyon Gas / her byte 16 gas = her slot 1,875,000 byte (, o zaman 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 iyileştirme, ancak yeterli değil. Daha fazla ölçeklenebilirlik istiyoruz. Orta vadeli hedefimiz, her slot için 16 MB ve Rollup veri sıkıştırma iyileştirmeleri ile birlikte, yaklaşık ~58000 TPS getirecek.

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

PeerDAS, "1D sampling" için nispeten basit bir uygulamadı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 koordinat arasından yan yana gelen 16 koordinattaki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden, mevcut önerilen parametrelere göre: 128 olası örnekten herhangi biri olan 64 tanesi ) blob'u geri kazanmak için kullanılabilir.

PeerDAS'ın çalışma prensibi, her 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 ( numaralı küresel p2p ağındaki eşlerden, hangi eşlerin farklı alt ağları dinleyeceğini sorgulayarak diğer alt ağlardaki blob'ları istemektedir. Daha temkinli bir versiyon olan SubnetDAS, ek eş katmanını sorgulamadan yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, stake eden düğümlerin SubnetDAS'ı, 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 blobları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 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 elde ederiz. Bu, sadece tolerans aralığımızda zorla duruyor: bu mümkündür, ancak bu, bant genişliği sınırlı 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 inşa maliyetlerini 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 da rastgele örnekleme yapar. KZG taahhüdünün lineer özelliklerini kullanarak, bir bloktaki blob kümesini genişletmek için yeni bir sanal blob seti kullanırız, bu sanal bloblar aynı bilgiyi fazladan 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 yapmak anlamına geliyor. KZG taahhüdünün lineer özellikleri, aynı bilgilere yönelik yedekleme kodlaması içeren yeni sanal blob listesinin yer aldığı bir bloktaki blob kümesini genişletmek için kullanılır.

Son derece önemlidir ki, taahhütlerin genişletilmesi için blob'a sahip olmak gerekmemektedir; 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ı ve veri kullanılabilirliği örneklemesi )DAS('ya güvenebilirler; bu, veri bloklarının kullanılabilirliğini doğrulamak için kullanılabilir. Tek boyutlu veri kullanılabilirliği örneklemesi )1D DAS( esasen dağıtılmış blok inşasına da dosttur.

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

)# Ne yapmalıyım? 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ğın dikkatlice gözlemlenmesi ve güvenliği sağlamak için yazılımın iyileştirilmesi gerekmektedir; bu, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümleri 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ışmamız gerekecek. Ayrıca, nihayetinde KZG'den kuantum güvenli ve güvenilir bir kurulum gerektirmeyen bir alternatif çözüme geçmeyi 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ı "brute force" teknolojisi kullanılsa bile, yani yeniden oluşturma için geçerlilik kanıtları üreten özyinelemeli STARK kullanılsa bile, ihtiyaçları karşılamak için yeterli değildir, çünkü teknik olarak bir STARK'ın boyutu O(log)n### * log(log(n)( hash değeridir ( STIR) kullanırken, gerçekte STARK neredeyse tüm blob kadar büyüktür.

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

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

Lütfen dikkat edin, L1 katmanında doğrudan genişleme yapmaya karar verirsek, bu seçeneğin mevcut olduğu. Bunun nedeni, L1 katmanının büyük miktarda TPS işlemesi gerektiğinde, L1 bloklarının çok büyük hale gelmesi ve istemcilerin bunların doğruluğunu doğrulamak için verimli bir yöntem arayacak olmalarıdır. Bu nedenle, L1 katmanında ZK-EVM ve DAS) gibi Rollup( ile aynı teknolojileri kullanmak zorunda kalacağız.

)# Harita üzerindeki diğer kısımlarla nasıl etkileşimde bulunabilirim?

Veri sıkıştırması gerçekleştirilirse, 2D DAS talebi azalacak veya en azından ertelenecektir. Plasma geniş çapta kullanılmaya başlanırsa, talep daha da azalacaktır. DAS ayrıca dağıtılmış blok oluşturma protokolleri ve mekanizmalarına meydan okumaktadır: teorik olarak, DAS dağıtılmış yeniden yapılandırmaya dost olsa da, bu uygulamada paket dahil etme listesi önerisi ve etrafındaki çatallama seçim mekanizması ile bir araya getirilmelidir.

veri sıkıştırma

(# Hangi problemi çözüyoruz?

Rollup içindeki her işlem, büyük miktarda zincir üzerindeki veri alanını kaplar: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirliği örneklemesine sahip olsak bile, bu Layer protokollerinin ölçeklenebilirliğini sınırlar. 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:

Sıfır bayt sıkıştırmasında, her uzun sıfır bayt dizisini ne kadar sıfır bayt olduğunu göstermek için iki bayt ile değiştiriyoruz. Daha da ileri giderek, işlemin belirli özelliklerinden yararlanıyoruz:

İmza Birleştirme: ECDSA imzasından BLS imzasına geçiyoruz. BLS imzasının özelliği, birden fazla imzanın tek bir imzaya birleştirilebilmesidir ve bu imza, tüm orijinal imzaların geçerliliğini kanıtlayabilir. L1 katmanında, birleştirme yapılsa bile doğrulama hesaplama maliyeti yüksek olduğundan BLS imzasının kullanılması düşünülmemektedir. Ancak L2 gibi veri kıtlığı olan ortamlarda BLS imzasının kullanılması anlamlıdır. ERC-4337'nin birleştirme özelliği, bu işlevin gerçekleştirilmesine bir yol sunmaktadır.

Adresleri pointers ile değiştir: Eğer Eter