Vitalik'in Yeni Makalesi: Ethereum'un Olası Geleceği, The Surge
Ethereum'un yol haritasında başlangıçta iki tür ölçeklendirme stratejisi vardı: parçalama ve Layer2 protokolleri. Bu iki strateji sonunda bir araya gelerek 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 olmaya odaklanırken, L2 ekosistemin genişlemesine yardımcı olma görevini üstleniyor. Bu model toplumda her yerde mevcut: Mahkeme sistemi (L1), süper hızlı ve verimli olmak için değil, sözleşmeleri ve mülkiyet haklarını korumak için var; girişimciler (L2) ise bu sağlam temel katmanın üzerinde inşa etmeli ve insanları Mars'a götürmelidir.
Bu yıl, Rollup merkezli yol haritasında önemli başarılar elde edildi: EIP-4844 blobs'un tanıtımıyla, Ethereum L1'in veri bant genişliği büyük ölçüde arttı, birçok Ethereum sanal makinesi (EVM) Rollup birinci aşamaya girdi. Her L2, kendi iç kuralları ve mantığına sahip bir "parça" olarak varlık gösteriyor; parçaların uygulanma biçimlerinin çeşitliliği ve çok yönlülüğü artık bir gerçek haline geldi. 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ı çözmektir, aynı zamanda Ethereum L1'e özgü sağlamlık ve merkeziyetsizlik özelliklerini 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ı korumak;
En az bazı L2, Ethereum'un temel özelliklerini (, güven duyulmaz, 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
Veri kullanılabilirliği örneklemesi ile ilgili daha fazla gelişme
Veri Sıkıştırma
Genelleştirilmiş Plasma
Olgun L2 kanıt sistemi
L2'ler arası birlikte çalışabilirlik iyileştirmeleri
L1 üzerinde genişletme gerçekleştirme
ölçeklenebilirlik üçgen paradoksu
Ölçeklenebilirlik üçgeni paradoksu, 2017 yılında ortaya atılan bir fikirdir. Bu fikir, blok zincirinin üç özelliği arasında bir çelişki olduğunu öne sürmektedir: merkeziyetsizlik (, daha spesifik olarak: çalıştırma düğümlerinin maliyeti düşük ), ölçeklenebilirlik (, işlenen işlem sayısı fazla ) ve güvenlik (, saldırganların bir işlemi başarısız kılmak için ağdaki çok sayıda düğümü yok etmesi gerektiğini belirtmektedir ).
Dikkate değer bir noktadır ki, üçgen paradoksu bir teorem değildir, üçgen paradoksunu tanıtan bir gönderi de matematiksel bir kanıt sunmamaktadır. Bununla birlikte, bir sezgisel matematiksel argüman sunmaktadır: eğer merkeziyetsiz bir dost düğüm ( örneğin bir tüketici dizüstü bilgisayar ) her saniyede N adet işlemi doğrulayabiliyorsa ve sizin her saniyede k*N adet işlemi işleyen bir zinciriniz varsa, o zaman (i) her işlem yalnızca 1/k kadar düğüm tarafından görülebilir, bu da demektir ki saldırganların sadece birkaç düğümü yok etmesi yeterli olacaktır ve kötü niyetli bir işlem aracılığıyla, ya da (ii) düğümünüz güçlü hale gelecektir, ve zinciriniz merkeziyetsiz olmayacaktır. Bu makalenin amacı, üçgen paradoksunu aşmanın imkansız olduğunu kanıtlamak değildir; aksine, üçlü paradoksu aşmanın zorluğunu göstermek ve bu argümanın içerdiği düşünce çerçevesinin bir dereceye kadar dışına çıkmayı gerektirdiğini belirtmektir.
Yıllardır, bazı yüksek performanslı zincirler, mimariyi temelde değiştirmeden üçlü paradoksu çözdüklerini iddia ediyorlar, genellikle düğümleri optimize etmek için yazılım mühendisliği becerilerini kullanarak. Bu her zaman yanıltıcıdır, çünkü bu zincirlerde düğüm çalıştırmak, Ethereum'da düğüm çalıştırmaktan çok daha zor. Bu makalede neden böyle olduğuna ve yalnızca L1 istemci yazılım mühendisliğinin kendisinin Ethereum'u ölçeklendiremeyeceğine dair nedenlere bakacağız.
Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten de üçgen paradoksunu çözüyor: Bu, istemcilerin yalnızca az miktarda veri indirip çok az hesaplama yaparak belirli bir miktarda verinin mevcut olduğunu ve belirli bir miktardaki hesaplama adımının doğru bir şekilde gerçekleştirildiğini doğrulamasını sağlıyor. SNARK'lar güvene dayalı değildir. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşır, fakat ölçeklenemez blok zincirinin sahip olduğu temel özellikleri korur; yani, %51 saldırısı 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ı arası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şimsiz kanıtlarının) yaygınlaşmasıyla birlikte, Plasma mimarisi her zamankinden daha geniş kullanım senaryoları için daha uygulanabilir hale geldi.
Veri kullanılabilirliği örneklemesi ile ilgili daha fazla gelişme
Hangi sorunu çözüyoruz?
2024 yılının 13 Mart'ında, Dencun yükseltmesi çevrimiçi olduğunda, Ethereum blok zincirindeki her 12 saniyelik slotta 3 adet yaklaşık 125 kB blob olacak veya 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 byte olduğundan, Ethereum üzerindeki Rollup'un maksimum TPS'si: 375000 / 12 / 180 = 173.6 TPS
Eğer Ethereum'un calldata( teorik maksimum değeri eklenirse: 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 çıkabilir, bu da calldata'ya 463-926 TPS sağlar.
Bu, Ethereum L1 için büyük bir iyileşme, 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 beraber, yaklaşık ~58000 TPS sağlayacak.
Bu nedir? Nasıl çalışır?
PeerDAS, "1D sampling" için görece basit bir uygulamadır. Ethereum'da, her blob, 253 bit asal alan (prime field) üzerindeki 4096. dereceden bir çoktandır (polynomial). Paylaşımlarını, toplam 8192 koordinattan ardışık 16 koordinattaki 16 değerlendirme değerini içeren paylaşımlar olarak yayınlıyoruz. Bu 8192 değerlendirme değerinden, mevcut önerilen parametrelere 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ğındaki ) eşlerden, farklı alt ağları dinleyecek olanların kim olduğunu sorgulayarak 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 olarak eş katmanından sorgulama yapmaz. Mevcut öneri, staking'e katılan düğümlerin SubnetDAS kullanmasını, diğer düğümlerin ise ( yani müşterilerin ) PeerDAS kullanmasını sağlamaktır.
Teorik olarak, "1D sampling" ölçeğini oldukça büyük bir şekilde genişletebiliriz: Eğer blob'un maksimum sayısını 256(, hedefimizi ise 128)'e çıkarırsak, 16MB'lık bir hedefe 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 içinde zar zor kalır: bu mümkün, 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 buna bir ölçüde optimizasyon yapabiliriz, ancak bu, yeniden inşa maliyetini artırır.
Bu nedenle, nihayetinde daha ileri gitmek istiyoruz ve 2D örnekleme (2D sampling) yapı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 doğrusal özelliklerinden yararlanarak, bir blok içindeki blob kümesini genişletmek için yeni sanal blob grubunu kullanarak, bu sanal bloblar aynı bilgiyi gereksiz yere kodlar.
Bu nedenle, nihayetinde daha ileri gitmek istiyoruz ve 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 özellikleri, aynı bilgilere yönelik yedekleme kodlaması içeren yeni sanal blob listesinin bulunduğu bir blok içindeki 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 temelde dağıtılmış blok inşasına dosttur. Gerçek blokları inşa eden düğümlerin yalnızca blob KZG taahhüdüne sahip olmaları gerekir ve veri kullanılabilirliği örneklemesi (DAS) üzerinden veri bloklarının 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 dosttur.
(# 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 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ümleri ile fork seçim kuralları güvenliği gibi konuların etkileşimlerini 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 gerekecek. Ayrıca, nihayetinde KZG'den kuantum güvenli ve güvenilir bir ayar gerektirmeyen bir alternatif çözüme geçiş yapabilmeyi umuyoruz. Şu anda, dağıtılmış blok inşasına dost olan hangi adayların olduğunu henüz netleştirmiş değiliz. Pahalı "kaba kuvvet" tekniklerini kullanmak, yani satır ve sütunları yeniden inşa etmek için geçerlilik kanıtları üretmek için yineleme 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 ) STIR) kullanılarak hesaplanmasına rağmen, pratikte STARK neredeyse tüm blob kadar büyüktür.
Uzun vadeli gerçek yolun benim düşündüğüm şekli şudur:
İdeal 2D DAS'ı uygulama;
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.
DA'yı bırakın, Plasma'yı ana Layer2 mimarimiz olarak tamamen kabul edin.
Lütfen dikkat edin, eğer L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçeneğin mevcut olduğu da bir gerçektir. Bunun nedeni, L1 katmanının yüksek miktarda TPS işlemesi durumunda, 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 arayacak olmalarıdır; bu nedenle L1 katmanında Rollup( ile ZK-EVM ve DAS) ile aynı teknolojileri kullanmak zorunda kalacağız.
(# Yol haritasının diğer bölümleriyle nasıl etkileşimde bulunulur?
Eğer veri sıkıştırması uygulanırsa, 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ılmış blok inşa protokolleri ve mekanizmaları için zorluklar ortaya koymaktadır: teorik olarak DAS, dağıtılmış yeniden yapılandırmaya dost olsa da, bu pratikte paket dahil etme listesi önerisi ve çevresindeki dal seçme 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 üzerindeki veri alanını kaplar: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirliği örneklemesi olsa bile, bu Layer protokollerinin ölçeklenebilirliğini kısıtlar. Her slot 16 MB, elde ettiğimiz:
16000000 / 12 / 180 = 7407 TPS
Eğer sadece payın sorununu değil, aynı zamanda paydanın sorununu da çözebilirsek ve her Rollup içindeki 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 resimdir:
![Vitalik 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ı sırasında, her uzun sıfır bayt dizisini iki baytla değiştirerek kaç tane sıfır bayt olduğunu belirtiriz. Daha da ileri giderek, işlemin belirli özelliklerinden yararlandık:
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.
22 Likes
Reward
22
8
Repost
Share
Comment
0/400
BearHugger
· 08-19 09:26
Kazanmanın yolu budur.
View OriginalReply0
MEVSupportGroup
· 08-17 12:40
Merkezi L2 beni güldürüyor, bu sadece kendi veritabanını oluşturmak değil mi?
View OriginalReply0
GasWaster
· 08-17 00:14
hala köprüye 500 gwei ödüyorum... when moon ser?
View OriginalReply0
ForkPrince
· 08-16 19:07
Yükseltme yolları, nihayetinde kripto dünyası emiciler tarafından oyuna getirilmek için değil mi?
View OriginalReply0
OnchainDetective
· 08-16 19:06
V Tanrısı'nın bu makalesindeki cüzdan adresinin işlem modeli çok şüpheli olduğunu kim fark etti? Bir meslektaşın analizini bekliyorum.
View OriginalReply0
ProveMyZK
· 08-16 19:04
Vitalik Buterin web3'ü geliştirmek için yol açıyor
Vitalik, Ethereum The Surge'ü analiz ediyor: 100.000 TPS hedefi ve L2 genişleme yolculuğu
Vitalik'in Yeni Makalesi: Ethereum'un Olası Geleceği, The Surge
Ethereum'un yol haritasında başlangıçta iki tür ölçeklendirme stratejisi vardı: parçalama ve Layer2 protokolleri. Bu iki strateji sonunda bir araya gelerek 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 olmaya odaklanırken, L2 ekosistemin genişlemesine yardımcı olma görevini üstleniyor. Bu model toplumda her yerde mevcut: Mahkeme sistemi (L1), süper hızlı ve verimli olmak için değil, sözleşmeleri ve mülkiyet haklarını korumak için var; girişimciler (L2) ise bu sağlam temel katmanın üzerinde inşa etmeli ve insanları Mars'a götürmelidir.
Bu yıl, Rollup merkezli yol haritasında önemli başarılar elde edildi: EIP-4844 blobs'un tanıtımıyla, Ethereum L1'in veri bant genişliği büyük ölçüde arttı, birçok Ethereum sanal makinesi (EVM) Rollup birinci aşamaya girdi. Her L2, kendi iç kuralları ve mantığına sahip bir "parça" olarak varlık gösteriyor; parçaların uygulanma biçimlerinin çeşitliliği ve çok yönlülüğü artık bir gerçek haline geldi. 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ı çözmektir, aynı zamanda Ethereum L1'e özgü sağlamlık ve merkeziyetsizlik özelliklerini 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ı korumak;
En az bazı L2, Ethereum'un temel özelliklerini (, güven duyulmaz, 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, 2017 yılında ortaya atılan bir fikirdir. Bu fikir, blok zincirinin üç özelliği arasında bir çelişki olduğunu öne sürmektedir: merkeziyetsizlik (, daha spesifik olarak: çalıştırma düğümlerinin maliyeti düşük ), ölçeklenebilirlik (, işlenen işlem sayısı fazla ) ve güvenlik (, saldırganların bir işlemi başarısız kılmak için ağdaki çok sayıda düğümü yok etmesi gerektiğini belirtmektedir ).
Dikkate değer bir noktadır ki, üçgen paradoksu bir teorem değildir, üçgen paradoksunu tanıtan bir gönderi de matematiksel bir kanıt sunmamaktadır. Bununla birlikte, bir sezgisel matematiksel argüman sunmaktadır: eğer merkeziyetsiz bir dost düğüm ( örneğin bir tüketici dizüstü bilgisayar ) her saniyede N adet işlemi doğrulayabiliyorsa ve sizin her saniyede k*N adet işlemi işleyen bir zinciriniz varsa, o zaman (i) her işlem yalnızca 1/k kadar düğüm tarafından görülebilir, bu da demektir ki saldırganların sadece birkaç düğümü yok etmesi yeterli olacaktır ve kötü niyetli bir işlem aracılığıyla, ya da (ii) düğümünüz güçlü hale gelecektir, ve zinciriniz merkeziyetsiz olmayacaktır. Bu makalenin amacı, üçgen paradoksunu aşmanın imkansız olduğunu kanıtlamak değildir; aksine, üçlü paradoksu aşmanın zorluğunu göstermek ve bu argümanın içerdiği düşünce çerçevesinin bir dereceye kadar dışına çıkmayı gerektirdiğini belirtmektir.
Yıllardır, bazı yüksek performanslı zincirler, mimariyi temelde değiştirmeden üçlü paradoksu çözdüklerini iddia ediyorlar, genellikle düğümleri optimize etmek için yazılım mühendisliği becerilerini kullanarak. Bu her zaman yanıltıcıdır, çünkü bu zincirlerde düğüm çalıştırmak, Ethereum'da düğüm çalıştırmaktan çok daha zor. Bu makalede neden böyle olduğuna ve yalnızca L1 istemci yazılım mühendisliğinin kendisinin Ethereum'u ölçeklendiremeyeceğine dair nedenlere bakacağız.
Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten de üçgen paradoksunu çözüyor: Bu, istemcilerin yalnızca az miktarda veri indirip çok az hesaplama yaparak belirli bir miktarda verinin mevcut olduğunu ve belirli bir miktardaki hesaplama adımının doğru bir şekilde gerçekleştirildiğini doğrulamasını sağlıyor. SNARK'lar güvene dayalı değildir. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşır, fakat ölçeklenemez blok zincirinin sahip olduğu temel özellikleri korur; yani, %51 saldırısı 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ı arası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şimsiz kanıtlarının) yaygınlaşmasıyla birlikte, Plasma mimarisi her zamankinden daha geniş kullanım senaryoları için daha uygulanabilir hale geldi.
Veri kullanılabilirliği örneklemesi ile ilgili daha fazla gelişme
Hangi sorunu çözüyoruz?
2024 yılının 13 Mart'ında, Dencun yükseltmesi çevrimiçi olduğunda, Ethereum blok zincirindeki her 12 saniyelik slotta 3 adet yaklaşık 125 kB blob olacak veya 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 byte olduğundan, Ethereum üzerindeki Rollup'un maksimum TPS'si: 375000 / 12 / 180 = 173.6 TPS
Eğer Ethereum'un calldata( teorik maksimum değeri eklenirse: 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 çıkabilir, bu da calldata'ya 463-926 TPS sağlar.
Bu, Ethereum L1 için büyük bir iyileşme, 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 beraber, yaklaşık ~58000 TPS sağlayacak.
Bu nedir? Nasıl çalışır?
PeerDAS, "1D sampling" için görece basit bir uygulamadır. Ethereum'da, her blob, 253 bit asal alan (prime field) üzerindeki 4096. dereceden bir çoktandır (polynomial). Paylaşımlarını, toplam 8192 koordinattan ardışık 16 koordinattaki 16 değerlendirme değerini içeren paylaşımlar olarak yayınlıyoruz. Bu 8192 değerlendirme değerinden, mevcut önerilen parametrelere 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ğındaki ) eşlerden, farklı alt ağları dinleyecek olanların kim olduğunu sorgulayarak 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 olarak eş katmanından sorgulama yapmaz. Mevcut öneri, staking'e katılan düğümlerin SubnetDAS kullanmasını, diğer düğümlerin ise ( yani müşterilerin ) PeerDAS kullanmasını sağlamaktır.
Teorik olarak, "1D sampling" ölçeğini oldukça büyük bir şekilde genişletebiliriz: Eğer blob'un maksimum sayısını 256(, hedefimizi ise 128)'e çıkarırsak, 16MB'lık bir hedefe 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 içinde zar zor kalır: bu mümkün, 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 buna bir ölçüde optimizasyon yapabiliriz, ancak bu, yeniden inşa maliyetini artırır.
Bu nedenle, nihayetinde daha ileri gitmek istiyoruz ve 2D örnekleme (2D sampling) yapı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 doğrusal özelliklerinden yararlanarak, bir blok içindeki blob kümesini genişletmek için yeni sanal blob grubunu kullanarak, bu sanal bloblar aynı bilgiyi gereksiz yere kodlar.
Bu nedenle, nihayetinde daha ileri gitmek istiyoruz ve 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 özellikleri, aynı bilgilere yönelik yedekleme kodlaması içeren yeni sanal blob listesinin bulunduğu bir blok içindeki 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 temelde dağıtılmış blok inşasına dosttur. Gerçek blokları inşa eden düğümlerin yalnızca blob KZG taahhüdüne sahip olmaları gerekir ve veri kullanılabilirliği örneklemesi (DAS) üzerinden veri bloklarının 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 dosttur.
(# 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 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ümleri ile fork seçim kuralları güvenliği gibi konuların etkileşimlerini 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 gerekecek. Ayrıca, nihayetinde KZG'den kuantum güvenli ve güvenilir bir ayar gerektirmeyen bir alternatif çözüme geçiş yapabilmeyi umuyoruz. Şu anda, dağıtılmış blok inşasına dost olan hangi adayların olduğunu henüz netleştirmiş değiliz. Pahalı "kaba kuvvet" tekniklerini kullanmak, yani satır ve sütunları yeniden inşa etmek için geçerlilik kanıtları üretmek için yineleme 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 ) STIR) kullanılarak hesaplanmasına rağmen, pratikte STARK neredeyse tüm blob kadar büyüktür.
Uzun vadeli gerçek yolun benim düşündüğüm şekli şudur:
Lütfen dikkat edin, eğer L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçeneğin mevcut olduğu da bir gerçektir. Bunun nedeni, L1 katmanının yüksek miktarda TPS işlemesi durumunda, 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 arayacak olmalarıdır; bu nedenle L1 katmanında Rollup( ile ZK-EVM ve DAS) ile aynı teknolojileri kullanmak zorunda kalacağız.
(# Yol haritasının diğer bölümleriyle nasıl etkileşimde bulunulur?
Eğer veri sıkıştırması uygulanırsa, 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ılmış blok inşa protokolleri ve mekanizmaları için zorluklar ortaya koymaktadır: teorik olarak DAS, dağıtılmış yeniden yapılandırmaya dost olsa da, bu pratikte paket dahil etme listesi önerisi ve çevresindeki dal seçme 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 üzerindeki veri alanını kaplar: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirliği örneklemesi olsa bile, bu Layer protokollerinin ölçeklenebilirliğini kısıtlar. Her slot 16 MB, elde ettiğimiz:
16000000 / 12 / 180 = 7407 TPS
Eğer sadece payın sorununu değil, aynı zamanda paydanın sorununu da çözebilirsek ve her Rollup içindeki 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 resimdir:
![Vitalik 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ı sırasında, her uzun sıfır bayt dizisini iki baytla değiştirerek kaç tane sıfır bayt olduğunu belirtiriz. Daha da ileri giderek, işlemin belirli özelliklerinden yararlandık:
İmza Birleştirme: Biz