- Topic
89k Popularity
42k Popularity
14k Popularity
4k Popularity
5k Popularity
29k Popularity
16k Popularity
22k Popularity
13k Popularity
3k Popularity
- Pin
89k Popularity
42k Popularity
14k Popularity
4k Popularity
5k Popularity
29k Popularity
16k Popularity
22k Popularity
13k Popularity
3k Popularity
Ethereum The Surge vizyonu: 100.000 TPS genişleme yolu ve zorlukları
Ethereum'in Olası Geleceği: The Surge
Ethereum'un yol haritası ilk başta iki tür ölçeklenebilirlik stratejisi içeriyordu: parçalama ve Layer2 protokolleri. Parçalama, her düğümün yalnızca bir kısmını doğrulayıp saklamasını sağlarken, Layer2 protokolleri Ethereum'un üzerinde bir ağ kurarak güvenliğini kullanırken çoğu veri ve hesaplamayı ana zincir dışında tutar. Araştırmalar derinleştikçe, bu iki yol nihayetinde bir araya geldi ve Rollup merkezli bir yol haritası oluşturdu, bu da hâlâ Ethereum'un genişleme stratejisi olarak kalmaktadır.
Rollup merkezli yol haritası, basit bir iş bölümünü öne sürüyor: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olmayı hedeflerken, L2 ekosistemi genişletme görevini üstleniyor. Bu model toplumsal olarak her yerde bulunuyor: Mahkeme sistemi ( L1 ), süper hızlı ve verimli olmayı değil, sözleşmeleri ve mülkiyet haklarını korumak için var; girişimciler ( L2 ) ise bu sağlam temel katman üzerinde inşa ederek insanlığın ilerlemesini sağlıyor.
Bu yıl, Rollup merkezli yol haritası önemli sonuçlar elde etti: EIP-4844 blobs'unun piyasaya sürülmesiyle, Ethereum L1'in veri bant genişliği büyük ölçüde artırıldı, 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österiyor; parça uygulama yöntemlerinin ç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 anki görevimiz Rollup merkezli yol haritasını tamamlamak ve bu sorunları çözmek, aynı zamanda Ethereum L1'in kendine özgü sağlamlığını ve merkeziyetsizliğini korumaktır.
The Surge: Ana Hedefler
Gelecekte Ethereum L2 aracılığıyla 100.000'in üzerinde TPS'ye ulaşabilir;
L1'in merkeziyetsizliğini ve dayanıklılığını koruyun;
En azından bazı L2'ler Ethereum'un temel özelliklerini ( güvenilmez, açık, sansüre dayanıklı ) tam olarak miras almıştır;
Ethereum, 34 farklı blockchain değil, birleşik bir ekosistem gibi hissettirmelidir.
Bu bölümün içeriği
ölçeklenebilirlik üçgen paradoksu
Ölçeklenebilirlik üçgeni paradoksu, 2017 yılında ortaya atılan bir düşüncedir. Bu, blockchain'in üç özelliği arasında bir çelişki olduğunu öne sürer: merkeziyetsizlik ( daha spesifik olarak: çalışan düğümlerin maliyetinin düşük olması ), ölçeklenebilirlik ( işlenebilen işlem sayısının çok olması ) ve güvenlik ( bir saldırganın tek bir işlemi başarısız kılmak için ağdaki büyük bir kısmı yok etmesi gerektiği ).
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. Gerçekten de, bir merkeziyetsiz dostu düğüm ( örneğin, tüketici sınıfı dizüstü bilgisayar ) 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ü bozması gereken bir kötü niyetli işlem ile gerçekleştirebilir veya (ii) düğümünüz güçlü hale gelecek, 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 içerdiği düşünce çerçevesinin bir ölçüde dışına çıkmayı gerektirdiğini göstermeyi amaçlamaktadır.
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 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çeklendirilemeyeceğini araştıracaktır.
Ancak, veri kullanılabilirliği örneklemesinin SNARK'lar ile birleştirilmesi gerçekten üçgen paradoksunu çözüyor: Bu, istemcilerin yalnızca az miktarda veri indirdikleri ve çok az hesaplama yaptıkları durumlarda belirli bir miktarda verinin kullanılabilir olduğunu ve belirli bir miktardaki hesaplama adımının doğru bir şekilde gerçekleştirildiğini doğrulamalarına olanak tanır. SNARK'lar güvene dayalı değildir. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşır, ancak ölçeklenemez zincirlerin sahip olduğu temel özellikleri korur; yani, %51'lik bir saldırı bile kötü blokların ağ tarafından kabul edilmesini zorlayamaz.
Üç zorluk sorununu çözmenin bir diğer yolu Plasma mimarisidir, bu mimari kullanıcıların izleme veri kullanılabilirliği sorumluluğunu teşvik edici bir şekilde üstlenmelerini sağlamak için akıllı teknolojiler kullanır. 2017-2019 yıllarında, sadece 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şimsiz kanıtlarının) yaygınlaşmasıyla birlikte, Plasma mimarisi daha önce hiç olmadığı kadar geniş bir kullanım senaryosuna uygun hale geldi.
Veri kullanılabilirliği örneklemesinin daha fazla ilerlemesi
Hangi sorunu çözüyoruz?
2024年3月13日,当Dencun升级上线时, Ethereum blok zincirinde her 12 saniyede bir slotta 3 adet yaklaşık 125 kB blob bulunacak veya her slotun veri kullanılabilir bant genişliği yaklaşık 375 kB olacaktır. Eğer işlem verileri doğrudan zincir üzerinde yayınlanırsa, ERC20 transferi yaklaşık 180 bayt olduğundan, Ethereum üzerindeki Rollup'un maksimum TPS'si: 375000 / 12 / 180 = 173.6 TPS
Ethereum'un calldata( teorik maksimum değeri eklediğimizde: her slot 30 milyon Gas / her byte 16 gas = her slot 1,875,000 byte), bu 607 TPS'ye dönüşüyor. PeerDAS kullanarak, blob sayısı 8-16'ya kadar çıkabilir, bu da calldata için 463-926 TPS sağlayacaktır.
Bu, Ethereum L1 için büyük bir iyileştirme, 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ında 4096 dereceli bir polinomdur. Polinomun paylarını yayınlıyoruz, burada her pay, toplamda 8192 koordinattan bitişik 16 koordinattaki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden, mevcut önerilen parametreye göre: 128 olası örnekten herhangi 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'nci alt ağ, herhangi bir blob'un i'nci örneğini yayınlar ve küresel p2p ağı içindeki ( eşlerden, farklı alt ağları dinleyecek olanları sorgulayarak ihtiyaç duyduğu diğer alt ağlardaki blobları talep eder. Daha muhafazakar bir versiyon olan SubnetDAS, ek bir eş katman sorgulaması olmaksızın yalnızca alt ağ mekanizmasını kullanır. 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 örnekleme" ö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'lık hedefe ulaşabiliriz; veri kullanılabilirliği örneklemesinde her bir 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. Bu, tolerans sınırlarımızın zorlandığı bir durum: bu uygulanabilir ancak bant genişliği sınırlı istemcilerin örnekleme yapamayacağı anlamına geliyor. Blob sayısını azaltarak ve blob boyutunu artırarak bunu bir ölçüde optimize edebiliriz, ancak bu yeniden inşa maliyetini artırır.
Bu nedenle, nihayet daha ileri gitmek ve 2D örnekleme )2D sampling( gerçekleştirmek istiyoruz. 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 özelliklerinden yararlanarak, bir bloktaki blob kümesini genişletmek için yeni sanal bloblar seti kullanılır; bu sanal bloblar, aynı bilgiyi gereksiz bir şekilde kodlar.
Bu nedenle, nihayet daha ileri gitmek ve 2D örnekleme yapmak istiyoruz; bu, yalnızca blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmaktı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, hesaplama taahhüdünün genişletilmesi için blob'a ihtiyaç yoktur, bu nedenle bu çözüm temelde dağıtık blok inşası açısından dostudur. Gerçek blok inşa eden düğümlerin yalnızca blob KZG taahhüdüne sahip olmaları gerekir ve bunlar veri kullanılabilirliği örnekleme )DAS( kullanarak veri bloklarının kullanılabilirliğini doğrulayabilirler. Tek boyutlu veri kullanılabilirliği örnekleme )1D DAS( esasen dağıtık blok inşası için de dosttur.
)# Ne daha 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 gözlemlemek ve güvenliği sağlamak için yazılımı geliştirmek, ilerleyici bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümleri ile çatallama seçim kuralları güvenliği gibi konular arasındaki etkileşimleri düzenlemek için daha fazla akademik çalışma 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 kurulum gerektirmeyen bir alternatife geçmeyi umuyoruz. Şu anda, dağıtılmış blok inşasına dost olan adayların neler olduğunu henüz bilmiyoruz. Pahalı "kaba kuvvet" tekniklerini kullanmak, yani yeniden yapılandırma için geçerlilik kanıtları oluşturmak üzere 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 ( kullanılarak STIR( ile hesaplanabilir, ancak pratikte STARK neredeyse tüm blob ile aynı boyuttadır.
Uzun vadeli gerçeklik yolunun şöyle olduğunu düşünüyorum:
Lütfen unutmayın, L1 katmanında doğrudan genişleme yapmaya karar verirsek, bu seçeneğin de mevcut olduğunu. Bunun nedeni, L1 katmanının büyük miktarda TPS işlemesi gerekirse, 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 isteyeceğidir. Bu nedenle, L1 katmanında Rollup) ile ZK-EVM ve DAS( gibi aynı teknikleri kullanmak zorunda kalacağız.
(# Yol haritasının diğer bölümleriyle nasıl etkileşim kurulur?
Veri sıkıştırmasının gerçekleştirilmesi durumunda, 2D DAS'a olan talep azalacak ya da 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ına da zorluklar getirmektedir: teorik olarak DAS dağıtık yeniden inşa için dost olsa da, bu uygulamada paket dahil etme listesi önerisi ve çevresindeki çatallama seçim mekanizması ile bir araya getirilmelidir.
) veri sıkıştırma
)# Hangi sorunu çözüyoruz?
Rollup içindeki her işlem, büyük miktarda zincir üstü veri alanı kaplar: ERC20 transferi yaklaşık 180 bayt gerektirir. Ideal veri kullanılabilirlik örneklemesi olsa bile, bu Layer protokollerinin ölçeklenebilirliğini sınırlar. Her slot 16 MB, elde ederiz:
16000000 / 12 / 180 = 7407 TPS
Eğer sadece payda sorununu değil, aynı zamanda pay sorununu da çözebilirsek ve her Rollup'taki işlemlerin zincirde daha az bayt kaplamasını sağlayabilirsek, ne olur?
O nedir, nasıl çalışır?
Bana göre, en iyi açıklama iki yıl önceki bu resim:
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 gösteriyoruz. Daha ileri giderek, işlemin belirli özelliklerinden faydalandık:
İmza Birleştirme: ECDSA imzasından BLS imzasına geçiyoruz.