Ethereum'un yol haritası başlangıçta iki tür ölçeklendirme stratejisi içeriyordu: parçalama ve Layer2 protokolleri. Parçalama, her düğümün yalnızca kısmi işlemleri doğrulaması ve depolamasını sağlar, Layer2 ise Ethereum'un üzerine bir ağ inşa eder, güvenliğinden yararlanır ancak çoğu veri ve hesaplamayı ana zincir dışında tutar. Bu iki yöntem nihayetinde Rollup merkezli bir yol haritasında birleşti ve bu gün itibarıyla Ethereum'un ölçeklenme stratejisi olmaya devam ediyor.
Rollup merkezli yol haritası, basit bir iş bölümü öneriyor: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olmaya odaklanırken, L2 ekosistemi genişletme görevini üstleniyor. Bu model, toplumda oldukça yaygındır: Mahkeme sistemi (L1), sözleşme ve mülkiyet haklarını korumak için varken, girişimciler (L2) bu temelin üzerine inşa ederek insan gelişimini ilerletiyor.
Bu yıl, Rollup merkezli yol haritasında önemli ilerlemeler kaydedildi: EIP-4844 blobs'un piyasaya sürülmesi, Ethereum L1'in veri bant genişliğini önemli ölçüde artırdı, birçok Ethereum sanal makinesi (EVM) Rollup birinci aşamaya girdi. Her L2, kendi kuralları ve mantığına sahip bir "parça" olarak varlık gösteriyor, parça uygulama çeşitliliği artık bir gerçeklik 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 sayesinde 100,000'in üzerinde TPS'ye ulaşacak;
L1'in merkeziyetsizliğini ve dayanıklılığını korumak;
En azından bazı L2, Ethereum'un temel özelliklerini ( güvenilirlik, açıklık, sansüre dayanıklılık ) tamamen miras alır;
Ethereum, 34 farklı blok zinciri yerine tek bir birleşik ekosistem gibi hissettirmelidir.
Ölçeklenebilirlik Üçgen Paradoksu
Ölçeklenebilirlik üçgen paradoksu, blok zincirinin üç özelliği arasında bir çelişki olduğunu öne sürüyor: merkeziyetsizlik (, çalıştırma düğüm maliyetinin düşük olması ), ölçeklenebilirlik (, işlem sayısının çokluğu ) 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 gerekiyor ).
Üçgen paradoks bir teorem değildir, onu tanıtan gönderide matematiksel bir kanıt da yoktur. Bu, sezgisel bir matematiksel argüman sunar: Eğer merkeziyetsiz dostu bir düğüm saniyede N işlem doğrulayabiliyorsa ve sizin 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 bir saldırgan yalnızca birkaç düğümü yok ederek kötü niyetli bir işlemle başarılı olabilir, ya da (ii) düğümünüz güçlü hale gelirken, zinciriniz merkeziyetsiz olmayacaktır. Bu makale, üçlü paradoksu kırmanın zor olduğunu ve bu argümanın içerdiği düşünce çerçevesinin bir dereceye kadar dışına çıkmayı gerektirdiğini göstermeyi amaçlamaktadır.
Yıllar boyunca, bazı yüksek performanslı zincirler, mimarileri temelde değiştirmeden üçlü paradoksu çözdüklerini iddia ettiler, genellikle düğümleri optimize ederek. 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.
Ancak, veri kullanılabilirliği örneklemesi ile 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 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üven gerektirmeyen bir yapıdı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 zorlamanın mümkün olmadığı, ölçeklenemez zincirlerin sahip olduğu temel özellikleri korur; yani, %51'lik bir saldırı bile bunu gerçekleştiremez.
Üçlü zorluğun çözümünün bir diğer yolu Plasma mimarisidir; bu mimari, kullanıcıların izleme veri kullanılabilirliği sorumluluğunu teşvik edici bir şekilde üstlenmesi için akıllı teknikler kullanır. 2017-2019 yılları arasında yalnızca dolandırıcılık kanıtı ile hesaplama gücünü genişletme imkanı varken, 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ş kullanım senaryoları için daha uygulanabilir hale geldi.
Veri Erişilebilirliği Örneklemesi Üzerine İlerlemeler
Hangi sorunu çözüyoruz?
13 Mart 2024'te, Dencun güncellemesi çevrimiçi olduğunda, Ethereum blok zincirinde her 12 saniyede 3 adet yaklaşık 125 kB blob bulunan slot mevcut olacak, yani her slotun veri kullanılabilir bant genişliği yaklaşık 375 kB olacaktır. İşlem verilerinin doğrudan zincir üzerinde yayınlandığını varsayarsak, ERC20 transferi yaklaşık 180 bayt olduğundan, 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), o zaman 607 TPS'ye dönüşür. 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, eğer Rollup veri sıkıştırma iyileştirmeleriyle birleştirilirse, ~58000 TPS getirecek.
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 paylaşımını yayınlıyoruz, burada her paylaşım toplam 8192 koordinattan komşu 16 koordinatın 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden herhangi 4096'ı ( mevcut olarak önerilen parametreye göre: 128 olası örnekten herhangi 64'ü ) blob'u geri kazanabilir.
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ğındaki eşlerden ( başka alt ağlardaki blob'ları almak için hangi eşlerin farklı alt ağları dinleyeceğini sormaktadır. Daha ihtiyatlı bir versiyon olan SubnetDAS, ek bir eş katmanı sorgulaması olmaksızın yalnızca alt ağ mekanizmasını kullanmaktadır. Mevcut öneri, hisse kanıtına katılan düğümlerin SubnetDAS'ı, diğer düğümlerin ise ) yani istemcilerin ( PeerDAS'ı kullanmasıdır.
Teorik olarak, "1D örnekleme" ölçeğini oldukça büyütebiliriz: Eğer blob'ların maksimum sayısını 256) hedefi için 128('e çıkarırsak, o zaman 16MB'lık bir hedefe 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ğine ulaşır. Bu, tolerans aralığımızın sınırlarında sadece zor bir şekilde duruyor: 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 buna belirli bir ölçüde optimizasyon yapabiliriz, ancak bu yeniden yapılandırma maliyetini daha yüksek hale getirecektir.
Bu nedenle, nihayet 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 rastgele örnekleme de yapar. KZG taahhüdünün lineer özelliklerinden yararlanarak, bir blok içindeki blob kümesini yeni sanal blob seti ile genişletiyoruz, bu sanal bloblar aynı bilgiyi fazladan kodlamaktadır.
Bu nedenle, nihayetinde daha ileri gitmek ve 2D örnekleme yapmak istiyoruz. Bu, yalnızca blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmaktadır. KZG taahhüdünün lineer özelliği, aynı bilgilere ilişkin yedek kodlamaya sahip yeni sanal blob listesini içeren bir bloktaki blob kümesini genişletmek için kullanılır.
Son derece önemlidir ki, taahhütlerin genişletilmesi için blob'a ihtiyaç yoktur, bu nedenle bu çözüm temel olarak dağıtık blok inşasına dosttur. Gerçek blokları inşa eden düğümler sadece blob KZG taahhüdüne sahip olmalıdır ve veri parçalarının kullanılabilirliğini doğrulamak için veri kullanılabilirliği örnekleme )DAS('a güvenebilirler. Tek boyutlu veri kullanılabilirliği örnekleme )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-71424e26868ad99f2adda7a27447820a.webp(
) Ne yapmamız gerekiyor? Hangi dengeleri sağlamalıyız?
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, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümlerinin, fork seçim kuralları güvenliği gibi konularla etkileşimlerini düzenlemek için daha fazla akademik çalışmaya sahip olmayı umuyoruz.
Gelecekte daha ileri aşamalarda, 2D DAS'ın ideal versiyonunu belirlemek ve güvenlik özelliklerini kanıtlamak için daha fazla çalışma yapmamız gerekecek. Ayrıca, 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ğuna dair bir belirsizlik var. Pahalı "kaba kuvvet" teknikleri kullanılsa bile, yani, satır ve sütunları yeniden oluşturmak için geçerlilik kanıtları üretmek amacıyla yinelemeli STARK kullanmak 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ğeri ) STIR( kullanılarak elde edilse de, aslında STARK neredeyse tüm blob kadar büyüktür.
Uzun vadeli gerçeklik yolunun şöyle olduğunu düşünüyorum:
İdeal 2D DAS'ı uygulamak;
1D DAS kullanmaya devam edin, basitlik ve dayanıklılık için daha düşük veri üst sınırını kabul ederek örnekleme bant genişliği verimliliğinden feragat edin.
DA'yı terk edin, Plasma'yı odaklandığımız ana Layer2 mimarisi olarak tamamen kabul edin.
Lütfen dikkat edin, L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçeneğin mevcut olduğudur. Bunun nedeni, eğer L1 katmanı çok sayıda TPS işlemesini gerektiriyorsa, L1 bloklarının çok büyük hale gelmesidir. İstemciler, bunların doğruluğunu doğrulamak için verimli bir yol arayacaktır; bu nedenle L1 katmanında Rollup) ile ZK-EVM ve DAS( ile aynı teknolojileri kullanmak zorunda kalacağız.
![Vitalik yeni makalesi: Ethereum'un olası geleceği, The Surge])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp(
) Yol haritasının diğer bölümleriyle nasıl etkileşimde bulunulur?
Veri sıkıştırması 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, dağıtık blok inşa protokolleri ve mekanizmaları için de zorluklar ortaya koymaktadır: teorik olarak DAS, dağıtık yeniden inşaya dost olsa da, bu uygulamada inclusion list önerisi ve çevresindeki fork seçim mekanizması ile birleştirilmesi gerekmektedir.
![Vitalik yeni yazısı: Ethereum'un olası geleceği, The Surge]###https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp(
Veri Sıkıştırma
) Hangi sorunu çözmeye çalışıyoruz?
Rollup içindeki her işlem büyük miktarda zincir üzerindeki veri alanını kaplayacaktır: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirlik ö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 yalnızca payda sorunlarını değil, aynı zamanda pay sorunlarını da çözebilirsek ve her Rollup içindeki işlemlerin zincirde daha az bayt kaplamasını sağlarsak, bu 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 olası geleceği, The Surge]###https://img-cdn.gateio.im/webp-social/moments-a04daca8af5d6af3c06b77a97aae477d.webp(
Sıfır bayt sıkıştırması sırasında, her uzun sıfır bayt dizisini değiştirmek için iki bayt kullanılır ve kaç tane sıfır bayt olduğunu belirtir. 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 imzaya birleştirilebilmesidir, bu imza tüm orijinal
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
6 Likes
Reward
6
4
Share
Comment
0/400
FloorSweeper
· 08-04 04:06
Nedenini sorma, L2 harika.
View OriginalReply0
RamenDeFiSurvivor
· 08-04 04:05
Vala L2 gerçekten güzel
View OriginalReply0
ShadowStaker
· 08-04 04:02
hmm mev verimliliği l2'lerde hala çalışmaya ihtiyaç duyuyor açıkçası... ağ topolojisi henüz orada değil
Ethereum ölçeklenme yeni aşaması: The Surge yol haritasının Derinlik analizi
Ethereum'in Olası Geleceği: The Surge
Ethereum'un yol haritası başlangıçta iki tür ölçeklendirme stratejisi içeriyordu: parçalama ve Layer2 protokolleri. Parçalama, her düğümün yalnızca kısmi işlemleri doğrulaması ve depolamasını sağlar, Layer2 ise Ethereum'un üzerine bir ağ inşa eder, güvenliğinden yararlanır ancak çoğu veri ve hesaplamayı ana zincir dışında tutar. Bu iki yöntem nihayetinde Rollup merkezli bir yol haritasında birleşti ve bu gün itibarıyla Ethereum'un ölçeklenme stratejisi olmaya devam ediyor.
Rollup merkezli yol haritası, basit bir iş bölümü öneriyor: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olmaya odaklanırken, L2 ekosistemi genişletme görevini üstleniyor. Bu model, toplumda oldukça yaygındır: Mahkeme sistemi (L1), sözleşme ve mülkiyet haklarını korumak için varken, girişimciler (L2) bu temelin üzerine inşa ederek insan gelişimini ilerletiyor.
Bu yıl, Rollup merkezli yol haritasında önemli ilerlemeler kaydedildi: EIP-4844 blobs'un piyasaya sürülmesi, Ethereum L1'in veri bant genişliğini önemli ölçüde artırdı, birçok Ethereum sanal makinesi (EVM) Rollup birinci aşamaya girdi. Her L2, kendi kuralları ve mantığına sahip bir "parça" olarak varlık gösteriyor, parça uygulama çeşitliliği artık bir gerçeklik 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
Ölçeklenebilirlik Üçgen Paradoksu
Ölçeklenebilirlik üçgen paradoksu, blok zincirinin üç özelliği arasında bir çelişki olduğunu öne sürüyor: merkeziyetsizlik (, çalıştırma düğüm maliyetinin düşük olması ), ölçeklenebilirlik (, işlem sayısının çokluğu ) 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 gerekiyor ).
Üçgen paradoks bir teorem değildir, onu tanıtan gönderide matematiksel bir kanıt da yoktur. Bu, sezgisel bir matematiksel argüman sunar: Eğer merkeziyetsiz dostu bir düğüm saniyede N işlem doğrulayabiliyorsa ve sizin 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 bir saldırgan yalnızca birkaç düğümü yok ederek kötü niyetli bir işlemle başarılı olabilir, ya da (ii) düğümünüz güçlü hale gelirken, zinciriniz merkeziyetsiz olmayacaktır. Bu makale, üçlü paradoksu kırmanın zor olduğunu ve bu argümanın içerdiği düşünce çerçevesinin bir dereceye kadar dışına çıkmayı gerektirdiğini göstermeyi amaçlamaktadır.
Yıllar boyunca, bazı yüksek performanslı zincirler, mimarileri temelde değiştirmeden üçlü paradoksu çözdüklerini iddia ettiler, genellikle düğümleri optimize ederek. 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.
Ancak, veri kullanılabilirliği örneklemesi ile 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 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üven gerektirmeyen bir yapıdı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 zorlamanın mümkün olmadığı, ölçeklenemez zincirlerin sahip olduğu temel özellikleri korur; yani, %51'lik bir saldırı bile bunu gerçekleştiremez.
Üçlü zorluğun çözümünün bir diğer yolu Plasma mimarisidir; bu mimari, kullanıcıların izleme veri kullanılabilirliği sorumluluğunu teşvik edici bir şekilde üstlenmesi için akıllı teknikler kullanır. 2017-2019 yılları arasında yalnızca dolandırıcılık kanıtı ile hesaplama gücünü genişletme imkanı varken, 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ş kullanım senaryoları için daha uygulanabilir hale geldi.
Veri Erişilebilirliği Örneklemesi Üzerine İlerlemeler
Hangi sorunu çözüyoruz?
13 Mart 2024'te, Dencun güncellemesi çevrimiçi olduğunda, Ethereum blok zincirinde her 12 saniyede 3 adet yaklaşık 125 kB blob bulunan slot mevcut olacak, yani her slotun veri kullanılabilir bant genişliği yaklaşık 375 kB olacaktır. İşlem verilerinin doğrudan zincir üzerinde yayınlandığını varsayarsak, ERC20 transferi yaklaşık 180 bayt olduğundan, 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), o zaman 607 TPS'ye dönüşür. 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, eğer Rollup veri sıkıştırma iyileştirmeleriyle birleştirilirse, ~58000 TPS getirecek.
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 paylaşımını yayınlıyoruz, burada her paylaşım toplam 8192 koordinattan komşu 16 koordinatın 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden herhangi 4096'ı ( mevcut olarak önerilen parametreye göre: 128 olası örnekten herhangi 64'ü ) blob'u geri kazanabilir.
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ğındaki eşlerden ( başka alt ağlardaki blob'ları almak için hangi eşlerin farklı alt ağları dinleyeceğini sormaktadır. Daha ihtiyatlı bir versiyon olan SubnetDAS, ek bir eş katmanı sorgulaması olmaksızın yalnızca alt ağ mekanizmasını kullanmaktadır. Mevcut öneri, hisse kanıtına katılan düğümlerin SubnetDAS'ı, diğer düğümlerin ise ) yani istemcilerin ( PeerDAS'ı kullanmasıdır.
Teorik olarak, "1D örnekleme" ölçeğini oldukça büyütebiliriz: Eğer blob'ların maksimum sayısını 256) hedefi için 128('e çıkarırsak, o zaman 16MB'lık bir hedefe 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ğine ulaşır. Bu, tolerans aralığımızın sınırlarında sadece zor bir şekilde duruyor: 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 buna belirli bir ölçüde optimizasyon yapabiliriz, ancak bu yeniden yapılandırma maliyetini daha yüksek hale getirecektir.
Bu nedenle, nihayet 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 rastgele örnekleme de yapar. KZG taahhüdünün lineer özelliklerinden yararlanarak, bir blok içindeki blob kümesini yeni sanal blob seti ile genişletiyoruz, bu sanal bloblar aynı bilgiyi fazladan kodlamaktadır.
Bu nedenle, nihayetinde daha ileri gitmek ve 2D örnekleme yapmak istiyoruz. Bu, yalnızca blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmaktadır. KZG taahhüdünün lineer özelliği, aynı bilgilere ilişkin yedek kodlamaya sahip yeni sanal blob listesini içeren bir bloktaki blob kümesini genişletmek için kullanılır.
Son derece önemlidir ki, taahhütlerin genişletilmesi için blob'a ihtiyaç yoktur, bu nedenle bu çözüm temel olarak dağıtık blok inşasına dosttur. Gerçek blokları inşa eden düğümler sadece blob KZG taahhüdüne sahip olmalıdır ve veri parçalarının kullanılabilirliğini doğrulamak için veri kullanılabilirliği örnekleme )DAS('a güvenebilirler. Tek boyutlu veri kullanılabilirliği örnekleme )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-71424e26868ad99f2adda7a27447820a.webp(
) Ne yapmamız gerekiyor? Hangi dengeleri sağlamalıyız?
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, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümlerinin, fork seçim kuralları güvenliği gibi konularla etkileşimlerini düzenlemek için daha fazla akademik çalışmaya sahip olmayı umuyoruz.
Gelecekte daha ileri aşamalarda, 2D DAS'ın ideal versiyonunu belirlemek ve güvenlik özelliklerini kanıtlamak için daha fazla çalışma yapmamız gerekecek. Ayrıca, 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ğuna dair bir belirsizlik var. Pahalı "kaba kuvvet" teknikleri kullanılsa bile, yani, satır ve sütunları yeniden oluşturmak için geçerlilik kanıtları üretmek amacıyla yinelemeli STARK kullanmak 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ğeri ) STIR( kullanılarak elde edilse de, aslında STARK neredeyse tüm blob kadar büyüktür.
Uzun vadeli gerçeklik yolunun şöyle olduğunu düşünüyorum:
Lütfen dikkat edin, L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçeneğin mevcut olduğudur. Bunun nedeni, eğer L1 katmanı çok sayıda TPS işlemesini gerektiriyorsa, L1 bloklarının çok büyük hale gelmesidir. İstemciler, bunların doğruluğunu doğrulamak için verimli bir yol arayacaktır; bu nedenle L1 katmanında Rollup) ile ZK-EVM ve DAS( ile aynı teknolojileri kullanmak zorunda kalacağız.
![Vitalik yeni makalesi: Ethereum'un olası geleceği, The Surge])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp(
) Yol haritasının diğer bölümleriyle nasıl etkileşimde bulunulur?
Veri sıkıştırması 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, dağıtık blok inşa protokolleri ve mekanizmaları için de zorluklar ortaya koymaktadır: teorik olarak DAS, dağıtık yeniden inşaya dost olsa da, bu uygulamada inclusion list önerisi ve çevresindeki fork seçim mekanizması ile birleştirilmesi gerekmektedir.
![Vitalik yeni yazısı: Ethereum'un olası geleceği, The Surge]###https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp(
Veri Sıkıştırma
) Hangi sorunu çözmeye çalışıyoruz?
Rollup içindeki her işlem büyük miktarda zincir üzerindeki veri alanını kaplayacaktır: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirlik ö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 yalnızca payda sorunlarını değil, aynı zamanda pay sorunlarını da çözebilirsek ve her Rollup içindeki işlemlerin zincirde daha az bayt kaplamasını sağlarsak, bu 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 olası geleceği, The Surge]###https://img-cdn.gateio.im/webp-social/moments-a04daca8af5d6af3c06b77a97aae477d.webp(
Sıfır bayt sıkıştırması sırasında, her uzun sıfır bayt dizisini değiştirmek için iki bayt kullanılır ve kaç tane sıfır bayt olduğunu belirtir. 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 imzaya birleştirilebilmesidir, bu imza tüm orijinal