Ethereum'ın Olası Geleceği: The Surge

Ethereum'un yol haritasında başlangıçta iki genişleme stratejisi vardı: parçalama ve Layer2 protokolleri. Bu iki yol sonunda bir araya gelerek Rollup merkezli bir yol haritası oluşturdu ve bu hala Ethereum'un genişleme stratejisi. Rollup merkezli yol haritası, basit bir iş bölümü öneriyor: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olmasına odaklanırken, L2 ekosistemi genişletme görevini üstleniyor.

Bu yıl, Rollup merkezli yol haritasında önemli başarılar elde edildi: 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'un birinci aşamasına girdi. Her L2, kendi iç kuralları ve mantığına sahip "parçalar" olarak var olmaktadır, parçaların gerçekleştirilme biçimindeki çeşitlilik ve çok yönlülük artık bir gerçek haline geldi. Ancak bu yol, bazı benzersiz zorluklarla da karşı karşıya. Şu anki görevimiz, Rollup merkezli yol haritasını tamamlamak ve bu sorunları çözmek, 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'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üvenmemek, açık olmak, sansüre karşı koymak ) tamamen devralmıştır;

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

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgeni, 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ı çok ) ve güvenlik ( saldırganların bir işlemi başarısız kılmak için ağdaki büyük bir bölüm düğümü yok etmesi gerektiği ).

Dikkate değer bir nokta, üçgen paradoksunun bir teorem olmaması ve üçgen paradoksunu tanıtan gönderilerin matematiksel kanıtla birlikte gelmemesidir. Gerçekten de, 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 yalnızca birkaç düğümü yok ederek kötü niyetli bir işlem gerçekleştirebilir, ya da (ii) 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ğildir; aksine, üçlü paradoksu kırmanın zor olduğunu ve bu argümanın ima ettiği düşünce çerçevesinin bir şekilde dışına çıkmayı gerektirdiğini göstermektir.

Yıllar boyunca, bazı yüksek performanslı zincirler, mimarilerini temelde değiştirmeden üçlü paradoksu çö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, bunun neden böyle olduğunu ve yalnızca L1 istemci yazılım mühendisliğinin kendisinin Ethereum'u ölçeklendiremeyeceğini keşfedecektir.

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 kullanılabilir olduğunu ve belirli bir miktarda hesaplama adımının doğru bir şekilde gerçekleştirildiğini doğrulamasını sağlar. SNARK'lar güvene dayanmayan yapılardır. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşır, ancak kötü blokların ağ tarafından kabul edilmesini zorlaştıracak şekilde 51% saldırıları bile uygulanamaz olan temel özellikleri korur.

Üçlü zorlukları çözmenin bir diğer yolu Plasma mimarisidir; bu mimari, izleme verilerinin kullanılabilirliğini kullanıcıların sorumluluğuna akıllıca bir şekilde teşvik eden teknikler kullanır. 2017-2019 yıllarında, yalnızca dolandırıcılık kanıtı ile hesaplama kapasitesini genişletme yöntemimiz olduğunda, Plasma güvenli uygulama açısından oldukça sınırlıydı, ancak SNARKs( sıfır bilgi kısa etkileşimli kanıtlarının) yaygınlaşmasıyla birlikte, Plasma mimarisi daha önce olduğundan daha geniş kullanım senaryoları için daha uygulanabilir hale geldi.

Veri Erişilebilirliği Örneklemesinin İlerleyişi

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 byte 16 gas = her slot 1.875.000 byte), bu 607 TPS'ye dönüşür. PeerDAS kullanıldığında, 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 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, ~58000 TPS getirecektir.

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

PeerDAS, "1D sampling"in 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ıyoruz, burada her pay, toplam 8192 koordinattan yan yana gelen 16 koordinattaki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden, mevcut önerilen parametreye göre: 128 olası örnekten herhangi bir 64'ü ( blob'u geri kazandırabilir.

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 ), farklı alt ağları dinleyecek olanı sorgulayarak ihtiyaç duyduğu diğer alt ağlardaki blob'ları talep eder. Daha temkinli bir versiyon olan SubnetDAS sadece alt ağ mekanizmasını kullanır ve ek bir eş katmanını sorgulamaz. 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 ölçüde genişletebiliriz: Eğer blob'ların maksimum sayısını 256( hedefini 128)'e yükseltirsek, 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 sağlar. Bu, tolerans sınırlarımızda zar zor kalmaktadır: bu mümkündür, ancak bant genişliği kısıtlı istemcilerin örnekleme yapamayacağı anlamına gelir. Blob sayısını azaltarak ve blob boyutunu artırarak bunun belirli bir ölçüde optimize edilmesini sağlayabiliriz, ancak bu yeniden inşa maliyetlerini artıracaktı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 bloblar arasında da rastgele örnekleme yapar. KZG taahhüdünün lineer özelliklerini kullanarak, bir bloktaki blob kümesini yeni sanal blob seti ile genişletiyoruz; bu sanal bloblar, aynı bilgiyi gereksiz bir şekilde 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 yapmayı içeriyor. KZG taahhüdünün lineer özelliği, aynı bilgilere karşılık gelen yeni sanal blob listesinin fazla kodlama içerdiği bir blok içindeki blob kümesini genişletmek için kullanılır.

Son derece önemlidir ki, hesaplama taahhüdünün 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) aracılığıyla veri bloğunun kullanılabilirliğini doğrulamak için güvenebilirler. Tek boyutlu veri kullanılabilirliği örneklemesi (1D DAS) temelde dağıtılmış blok inşasına da dosttur.

( Daha 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özlemlemek ve yazılımı güvenliği sağlamak için geliştirmek, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS versiyonları ile fork seçim kurallarının güvenliği gibi konular arasındaki etkileşimleri 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 gerekiyor. Sonunda KZG'den kuantum güvenli ve güvenilir bir ayar gerektirmeyen bir alternatif çözüme geçmeyi umuyoruz. Şu anda, dağıtılmış blok inşası için hangi adayların dostça olduğunu henüz netleştirmiş değiliz. Pahalı "kaba kuvvet" tekniklerini kullanmak, yani yeniden yapılandırma satırları ve sütunlar için geçerlilik kanıtları oluşturmak üzere yinelemeli STARK kullanmak bile ihtiyaçları karşılamaya yetmiyor, çünkü teknik olarak bir STARK boyutu O)log###n( * log(log)n(( hash değeri ) STIR) ile kullanıldığında bile, pratikte STARK neredeyse bütün blob kadar büyük.

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

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

Lütfen dikkat edin, eğer L1 katmanında doğrudan genişleme kararı alırsak, bu seçeneğin var olduğu. 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ği ve istemcilerin bunların doğruluğunu doğrulamak için verimli bir yöntem istemesi olacaktır. Bu nedenle, L1 katmanında Rollup( ile aynı teknolojileri kullanmak zorunda kalacağız, ZK-EVM ve DAS) gibi.

( Yol haritasının diğer kısımlarıyla nasıl etkileşim kurabilirim?

Veri sıkıştırma gerçekleştirilirse, 2D DAS'a olan talep azalacak veya en azından ertelenecek, eğer Plasma yaygın olarak kullanılıyorsa, talep daha da azalacaktır. DAS ayrıca dağıtık blok inşa protokolleri ve mekanizmaları için zorluklar ortaya koymaktadır: teorik olarak DAS, dağıtık yeniden inşa için dosttur, ancak bu pratikte, paket dahil etme listesi önerisi ve etrafındaki çatallama seçim mekanizması ile bir araya getirilmelidir.

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

Veri Sıkıştırma

( Hangi sorunu çö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 örneklemesi olsa bile, bu Layer protokolünün ölçeklenebilirliğini sınırlar. Her slot 16 MB, elde ederiz:

16000000 / 12 / 180 = 7407 TPS

Eğer yalnızca payları değil, aynı zamanda paydaları da çözebilirsek ve her Rollup'taki işlemler zincir üzerinde daha az byte kaplarsa, 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 muhtemel geleceği, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###

Sıfır baytı sıkıştırma sırasında, her uzun sıfır baytı dizisini ne kadar sıfır baytı olduğunu belirtmek için iki baytla değiştiriyoruz. Daha ileri gidecek olursak, işlemin belirli özelliklerinden yararlandı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 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ğu için BLS imzasının kullanılması düşünülmemektedir. Ancak L2 gibi veri kıtlığı olan ortamlarda, BLS imzası kullanmak anlamlıdır. ERC-4337'nin birleştirme özelliği, bu işlevin gerçekleştirilmesi için bir yol sunmaktadır.

Adresleri pointer ile değiştirme: Eğer daha önce bir adres kullanmışsak, 20 baytlık adresi, geçmişteki bir konuma işaret eden 4 baytlık bir pointer ile değiştirebiliriz.

İşlem değerinin özel sırası