- Topic
116k Popularity
26k Popularity
7k Popularity
29k Popularity
17k Popularity
23k Popularity
14k Popularity
3k Popularity
14k Popularity
155k Popularity
- Pin
116k Popularity
26k Popularity
7k Popularity
29k Popularity
17k Popularity
23k Popularity
14k Popularity
3k Popularity
14k Popularity
155k Popularity
Ethereum The Surge planı: Ölçeklenebilirlik üçlüsünü kırmak ve L2 performansını 100,000 TPS'ye yükseltmek.
Ethereum'in Olası Geleceği: The Surge
Ethereum'un yol haritası başlangıçta iki tür ölçeklendirme stratejisi içeriyordu: parça ve Layer2 protokolleri. Bu iki yol nihayetinde bir araya gelerek Rollup merkezli bir yol haritası oluşturdu, bu hala Ethereum'un mevcut ölçeklendirme stratejisidir.
Rollup merkezli yol haritası, basit bir iş bölümünü önermektedir: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olmaya odaklanırken, L2 ekosistemin genişlemesine yardımcı olma görevini üstlenmektedir. Bu model toplumda oldukça yaygındır: mahkeme sisteminin (L1) varlığı sözleşmeleri ve mülkiyet haklarını korumak içindir, girişimciler ise (L2) bu temel üzerinde inşa ederek gelişmeyi teşvik etmektedir.
Bu yıl, Rollup merkezli yol haritasında önemli ilerlemeler kaydedildi: EIP-4844 blobs'un piyasaya sürülmesiyle, Ethereum L1'in veri bant genişliği büyük ölçüde arttı ve birden fazla Ethereum Sanal Makinesi Rollup'ın birinci aşamaya girdi. Her L2, kendi kuralları ve mantığı olan bir "parça" olarak var olmaktadır; parça uygulama biçimlerinin ç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. Şu anki görevimiz, Rollup merkezli yol haritasını tamamlamak, bu sorunları çözmek ve aynı zamanda Ethereum L1'in 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üvensiz, açık, sansüre dayanıklı ) tamamen miras almıştır;
Ethereum, 34 farklı blok zinciri yerine, tek bir birleşik ekosistem gibi hissettirmelidir.
Bu bölümün içeriği
Ölçeklenebilirlik Üçgen Paradoksu
Ölçeklenebilirlik üçgeni paradoksu, blok zincirinin üç özelliği arasında bir çelişki olduğunu öne sürmektedir: merkeziyetsizlik (, çalıştırma düğümlerinin maliyetinin düşük olması ), ölçeklenebilirlik (, işlenebilen işlem sayısının fazla olması ) ve güvenlik (, saldırganların tek bir işlemi başarısız kılmak için ağdaki çok sayıda düğümü yok etmesi gerektiği ).
Dikkate değer olan, üçgen paradoksunun bir teorem olmamasıdır; üçgen paradoksunu tanıtan yazılar da matematiksel bir kanıt sunmamaktadır. Bir sezgisel matematiksel argüman sunar: Eğer merkeziyetsiz dostu bir düğüm her saniye N işlem doğrulayabiliyorsa ve senin k*N işlem işleyen bir zincirin varsa, o zaman (i) her işlem yalnızca 1/k kadar düğüm tarafından görülebilir, bu da saldırganın yalnızca birkaç düğümü hedef alarak kötü niyetli bir işlem gerçekleştirebileceği anlamına gelir, ya da (ii) düğümün güçlü hale gelecek, ancak zincirin merkeziyetsiz olmayacaktır. Bu makalenin amacı, üçgen paradoksunun kırılmasının imkansız olduğunu kanıtlamak değildir; aksine, üçlü paradoksu kırmanın zor olduğunu ve belirli bir ölçüde bu argümanın ima ettiği düşünce çerçevesinin dışına çıkmayı gerektirdiğini göstermektir.
Yıllar boyunca, bazı yüksek performanslı zincirler, mimarilerini temelden değiştirmeden üçlü ikilemi çö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 zincirler üzerinde düğüm çalıştırmak, Ethereum üzerinde düğüm çalıştırmaktan çok daha zordur.
Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten üçgen paradoksunu çözmektedir: Bu, istemcilerin yalnızca az miktarda veri indirip ç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ına olanak tanır. SNARK'lar güvenilir olmayanlardır. 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; bu da, %51'lik bir saldırının bile kötü blokların ağ tarafından kabul edilmesini zorlayamayacağıdır.
Üçlü zorlukları çözmenin bir diğer yolu Plasma mimarisidir; bu mimari, gözlem verilerinin kullanılabilirliğini kullanıcılara aktarmak için akıllıca bir teknik kullanarak uyumlu bir şekilde teşvik eder. 2017-2019 yılları arasında, hesaplama yeteneklerini genişletmek için yalnızca dolandırıcılık kanıtına sahip olduğumuzda, Plasma güvenli yürütme konusunda oldukça sınırlıydı, ancak SNARK'ların yaygınlaşmasıyla birlikte Plasma mimarisi, her zamankinden daha geniş bir kullanım senaryosu için daha uygulanabilir hale geldi.
Veri Erişilebilirliği Örneklemenin Daha Fazla Gelişmesi
Hangi problemi çözüyoruz?
2024 yılının 13 Mart'ında, Dencun yükseltmesi devreye girdiğinde, Ethereum blok zincirinde her 12 saniyede 3 adet yaklaşık 125 kB blob bulunan slot olacak, yani her slotun veri kullanılabilir bant genişliği yaklaşık 375 kB olacak. Eğer işlem verileri doğrudan zincir üzerinde yayınlanırsa, ERC20 transferi yaklaşık 180 bayttır, bu nedenle Ethereum üzerindeki Rollup'ın maksimum TPS'si: 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 durumda 607 TPS olur. 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 ve Rollup veri sıkıştırma iyileştirmeleri ile birlikte, ~58000 TPS sağlamaktır.
O nedir? Nasıl çalışır?
PeerDAS, "1D sampling"in nispeten basit bir uygulamasıdır. Ethereum'da, her blob, 253 bit asal alanında 4096. dereceden bir çok terimlidir. Paylaşım bilgilerini yayınlıyoruz, bu paylaşımların her biri toplam 8192 koordinattan komşu 16 koordinattaki 16 değerleme değerini içerir. Bu 8192 değerleme değerinden, herhangi 4096'sı ( mevcut önerilen parametrelere göre: 128 olası örnekten herhangi 64'ü ) blob'u geri yükleyebilir.
PeerDAS'ın çalışma prensibi, her müşterinin 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ı sormak suretiyle 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 sorgulaması yapmaz. Mevcut öneri, stake eden düğümlerin SubnetDAS kullanmasını, diğer düğümlerin ) yani müşterilerin ( PeerDAS kullanmasını sağlamaktır.
Teorik olarak, "1D örnekleme" ölçeğini oldukça büyük bir hale getirebiliriz: Eğer blob'ların maksimum sayısını 256) hedefini 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, sınırlarımızın zorlanmasıdır: uygulanabilir, 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 buna bir dereceye kadar optimizasyon yapabiliriz, ancak bu yeniden yapılandırma maliyetini daha yüksek hale getirir.
Bu nedenle, nihayet daha ileri gitmek istiyoruz ve 2D örnekleme yapmayı planlıyoruz. 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 faydalanarak, bir bloktaki blob kümesini genişletmek için yeni sanal bloblardan oluşan bir set kullanıyoruz; bu sanal bloblar aynı bilgiyi gereksiz yere kodlamaktadır.
Bu nedenle, nihayetinde daha ileri gitmek istiyoruz, 2D örnekleme yapmak, bu sadece blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmak. KZG taahhüdünün lineer özellikleri, aynı bilgiye karşılık gelen yeni sanal blob listelerini içeren bir bloktaki blob kümesini genişletmek için kullanılır.
Son derece önemlidir ki, taahhüt genişletme işlemi bir blob gerektirmediğinden, bu çözüm temel olarak dağıtık blok inşasına dosttur. Blokları gerçek anlamda inşa eden düğümler yalnızca blob KZG taahhütlerine sahip olmalı 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 da dosttur.
![Vitalik yeni makale: Ethereum'un olası geleceği, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
) ne yapılması gerekiyor? Hangi dengelemeler var?
Sonraki aşama, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Ardından, PeerDAS üzerindeki blob sayısını sürekli artırırken, ağı dikkatlice izleyip yazılımı iyileştirerek güvenliği sağlamak, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümleri ile fork seçim kuralları gibi güvenlik sorunları arasındaki etkileşimleri düzenlemek için daha fazla akademik çalışmanın 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ışma yapmamız gerekiyor. 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ık blok inşası için hangi adayların uygun olduğunu henüz net bir şekilde bilemiyoruz. Pahalı "kaba kuvvet" tekniklerini kullanmak, yani geri döngü STARK kullanarak satır ve sütunları yeniden inşa etmek için geçerlilik kanıtları üretmek yeterli değil, çünkü teknik olarak bir STARK'ın boyutu O###log(n( * log)log(n() hash değeri ) STIR( kullanılarak elde edilir, ancak pratikte STARK neredeyse tüm blob kadar büyüktür.
Benim düşündüğüm uzun vadeli gerçeklik yolu şudur:
Lütfen unutmayın, eğer L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçenek de mevcuttur. Bunun nedeni, eğer L1 katmanı büyük miktarda TPS işlemesi gerekiyorsa, L1 bloklarının çok büyük hale geleceği ve istemcilerin bunların doğruluğunu doğrulamak için verimli bir yola ihtiyaç duyacak olmalarıdır; bu nedenle L1 katmanında ZK-EVM ve DAS) gibi Rollup( ile aynı teknolojileri kullanmak zorunda kalacağız.
) Yol haritasının diğer bölümleriyle nasıl etkileşim kurabilirim?
Eğer veri sıkıştırması gerçekleştirilirse, 2D DAS'a olan talep azalacak veya en azından gecikecektir. Plasma geniş çapta 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 dosttur, ancak bu pratikte paket dahil etme listesi önerisi ve çevresindeki çatallama seçim mekanizması ile birleştirilmesi gerekmektedir.
![Vitalik yeni makale: 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 üstü veri alanı 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 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, bu ne anlama gelir?
Bu nedir, nasıl çalışır?
Bana göre, en iyi açıklama iki yıl önceki bu resimdir:
![Vitalik’in 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ında, her uzun sıfır bayt dizisini iki bayt ile değiştirerek kaç tane sıfır bayt olduğunu belirtiriz. Dahası, işlemlerin 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 imza halinde birleştirilebilmesidir; bu imza, tüm orijinal imzaların geçerliliğini kanıtlayabilir. L1 katmanında, birleştirme gerçekleştirildiğinde bile doğrulama hesaplama maliyetinin yüksek olması nedeniyle BLS imzası kullanılması düşünülmemektedir. Ancak verinin kıt olduğu L2 gibi ortamlarda BLS imzası kullanmak anlamlıdır. ERC-4337'nin birleştirme özelliği, bu işlevselliği sağlamak için bir yol sunmaktadır.
po kullan