Ethereum'un Geleceği: The Surge

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgeni paradoksu, blok zincirinin merkeziyetsizleşme, ölçeklenebilirlik ve güvenlik gibi üç özelliği arasında bir çelişki bulunduğunu öne sürmektedir. Bu, katı bir teorem değil, bir sezgisel matematiksel argümandır: Eğer merkeziyetsiz dostu bir düğüm her saniye N işlem doğrulayabiliyorsa ve sizde her saniye k*N işlem işleyen bir zincir varsa, o zaman ya 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ü hedef alarak kötü niyetli bir işlem gerçekleştirebilir; ya da düğümleriniz güçlü hale gelecektir ve zinciriniz merkeziyetsiz olmayacaktır.

Yıllar boyunca, bazı yüksek performanslı zincirler, mimarilerini temelden değiştirmeden üçlü paradoksu çözdüklerini iddia etmiştir, 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.

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 miktar verinin mevcut olduğunu doğrulamalarına ve belirli bir miktar hesaplama adımının doğru bir şekilde gerçekleştirildiğini doğrulamalarına olanak tanır. SNARK'lar güvene dayanmayan bir yapıdır. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli sunar, ancak bu, ö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, kullanıcıların izleme verilerinin kullanılabilirliğini sağlamaya teşvik eden bir yöntemle sorumluluğu üstlenmelerini sağlayan akıllı teknolojiler kullanır. SNARK'ların yaygınlaşmasıyla birlikte, Plasma mimarisi daha önce olduğu gibi daha geniş kullanım senaryoları için daha uygulanabilir hale gelmiştir.

Veri kullanılabilirliği örneklemesi ile ilgili daha fazla ilerleme

Hangi sorunu çözüyoruz?

13 Mart 2024'te Dencun yükseltmesi çevrimiçi olduğunda, Ethereum blok zincirinde her 12 saniyede bir slotta 3 adet yaklaşık 125 kB blob olacak, yani her slot için veri kullanılabilir bant genişliği yaklaşık 375 kB. İş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'sını eklersek, 607 TPS'ye çıkacaktır. PeerDAS kullanarak, 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ükseltmedir, ancak yeterli değildir. Daha fazla ölçeklenebilirlik istiyoruz. Orta vadeli hedefimiz her slot için 16 MB'dir; Rollup veri sıkıştırma iyileştirmeleri ile birleştirildiğinde, yaklaşık ~58000 TPS sağlayacaktır.

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

PeerDAS, "1D sampling" için nispeten basit bir uygulamadır. Ethereum'da, her blob 253 bit asal alanında tanımlanan 4096. dereceden bir polinomdur. Polinomun paylarını yayınlıyoruz, burada her pay toplam 8192 koordinattan komşu 16 koordinat üzerindeki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden herhangi 4096'sı blob'u geri kazanmak 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 yayar ve ihtiyacı olan diğer alt ağlardaki blob'ları talep etmek için küresel p2p ağındaki eşlerden sorgulama yapar. Daha temkinli bir versiyon olan SubnetDAS, ek eş düzeyinde sorgulama olmaksızın yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, hisse kanıtına katılan düğümlerin SubnetDAS'ı, diğer düğümlerin ise PeerDAS'ı kullanmasıdır.

Teorik olarak, "1D örnekleme" ölçeğini oldukça büyük hale getirebiliriz: eğer blob'ların maksimum sayısını 256'ya çıkarırsak, 16MB hedefimize ulaşabiliriz ve veri kullanılabilirliği örneklemesinde her düğüm 16 örnek * 128 blob * her blob için her örnek 512 byte = her slot için 1 MB veri bant genişliği sağlıyor. Bu, dayanıklılık sınırlarımızın zar zor içinde: bu mümkün, ancak bu, 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 maliyetlerini daha yüksek hale getirecektir.

Bu nedenle, nihayet daha ileri gitmek istiyoruz ve 2D örnekleme yapmak istiyoruz. Bu yöntem, yalnızca blob içinde rastgele örnekleme yapmakla kalmaz, aynı zamanda bloblar arasında da rastgele örnekleme yapar. KZG taahhütlerinin lineer özelliklerinden yararlanarak, bir bloktaki blob kümesini yeni bir sanal blob seti ile genişletiyoruz; bu sanal bloblar, aynı bilgiyi gereksiz yere kodlamaktadı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üğümler yalnızca blob KZG taahhüdüne sahip olmalıdır ve veri bloklarının kullanılabilirliğini doğrulamak için veri kullanılabilirliği örneklemesini kullanabilirler. Tek boyutlu veri kullanılabilirliği örneklemesi de aslında 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. Ardından, PeerDAS üzerindeki blob sayısını sürekli artırırken, ağa dikkatlice göz kulak olmak 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 versiyonları ile çatallama seçim kuralları güvenliği gibi sorunların etkileşimini düzenlemek için daha fazla akademik çalışma 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ılmış blok inşasına dost olan adayların neler olduğu konusunda belirsizliklerimiz var. Pahalı "brute force" tekniklerini kullanmak, yani, satır ve sütunları yeniden inşa etmek için geçerlilik kanıtları oluşturmak üzere özyinelemeli STARK'ları kullanmak bile, ihtiyaçları karşılamak için yeterli değil; çünkü teknik olarak bir STARK'ın boyutu O(log(n) * log(log(n)) hash'idir, ancak pratikte STARK neredeyse tüm blob kadar büyüktür.

Uzun vadeli gerçeklik yolunun benim düşünceme göre:

1. İdeal 2D DAS'ı uygulamak;
2. 1D DAS kullanmaya devam edin, örnekleme bant genişliği verimliliğinden feragat edin, basitlik ve sağlamlık için daha düşük veri üst sınırını kabul edin.
3. DA'yı bırakıyoruz, Plasma'yı odaklandığımız ana Layer2 mimarisi olarak tamamen kabul ediyoruz.

Lütfen dikkat edin, L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçeneğin de mevcut olduğunu unutmayın. Bunun nedeni, L1 katmanı büyük bir TPS'yi işlemek zorunda kalırsa, L1 bloklarının oldukça büyük hale geleceği ve istemcilerin bunların doğruluğunu doğrulamak için verimli bir yöntem arayacaklarıdır, bu nedenle L1 katmanında Rollup ile aynı teknolojiyi kullanmak zorunda kalacağız.

Yol haritasının diğer bölümleriyle nasıl etkileşim kurabilirim?

Veri sıkıştırması gerçekleştirilirse, 2D DAS'a olan talep azalacak veya en azından ertelenecektir; 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 inşaya dosttur, ancak pratikte bu, paket dahil etme listesi önerisi ve etrafındaki çatallama seçimi mekanizması ile bir araya getirilmelidir.

Veri Sıkıştırma

Hangi problemi çözüyoruz?

Rollup'taki her işlem, büyük miktarda zincir üzerindeki veri alanı kaplar: 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, aşağıdakileri elde ederiz:

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, ne olur?

Bu 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ırma sırasında, her uzun sıfır baytı dizisini iki baytla değiştirerek kaç tane sıfır baytı olduğunu gösteriyoruz. Daha ileri giderek, 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 haline getirilebilmesidir, bu imza tüm orijinal imzaların geçerliliğini kanıtlayabilir. L1 katmanında, birleştirme yapılsa bile doğrulamanın hesaplama maliyeti yüksek olduğu için BLS imzasının kullanımı düşünülmemektedir. Ancak, veri kıtlığı olan L2 gibi ortamlarda, BLS imzasının kullanımı anlamlıdır. ERC-4337'nin birleştirme özelliği, bu işlevselliği sağlamak için bir yol sunmaktadır.

Adresleri pointer ile değiştirme: 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.

Özelleştirilmiş seri hale getirme------Çoğu işlem değerinin basamak sayısı azdır, örneğin, 0.25 Eter 250.000.000.000.000.000 wei olarak ifade edilir. Maksimum temel işlem ücreti ve öncelik ücreti de benzer şekilde. Bu nedenle, çoğu para değerini ifade etmek için özelleştirilmiş ondalık kayan nokta formatını kullanabiliriz.

ne yapılması gerekiyor, hangi dengelemeler var?

Sonraki adım, yukarıda belirtilen planı gerçekten uygulamak olacaktır. Ana dengelemeler şunlardır:

1. BLS imzasına geçmek büyük bir çaba gerektirir ve güvenliği artırabilen güvenilir donanım yongalarıyla uyumluluğu azaltır. Bunun yerine diğer imza şemalarının ZK-SNARK paketlerini kullanabilirsiniz.

2、Dinamik sıkıştırma ( Örneğin, adres ) yerine işaretçiler kullanmak istemci kodunu karmaşık hale getirecektir.

3. Durum farklılıklarını işlemler yerine zincire yayınlamak, denetlenebilirliği azaltacak ve birçok yazılım ( örneğin blok gezgini ) çalışamaz hale gelecektir.

Yol haritasının diğer bölümleriyle nasıl etkileşim kurabilirim?

ERC-4337'yi benimseyerek ve nihayetinde bazı içeriğini L2 EVM'ye dahil ederek, toplama teknolojisinin dağıtımını büyük ölçüde hızlandırabiliriz. ERC-4337'nin bazı içeriklerini L1 üzerinde tutmak, L2'deki dağıtımını hızlandırabilir.

Genelleşmiş Plasma

Hangi sorunu çözüyoruz?

16 MB'lık blob ve veri sıkıştırması kullanılsa bile, 58.000 TPS, tüketici ödemeleri, merkeziyetsiz sosyal medya veya diğer yüksek bant genişliği alanlarının ihtiyaçlarını tamamen karşılamak için yeterli olmayabilir, özellikle gizlilik faktörlerini düşündüğümüzde bu ölçeklenebilirliği 3-8 kat azaltabilir. Yüksek işlem hacmine sahip, düşük değerli uygulama senaryoları için mevcut bir seçenek Validium kullanmaktır; bu, verileri zincir dışında saklar ve ilginç bir güvenlik modeli benimser: operatörler kullanıcıların fonlarını çalamaz, ancak tüm kullanıcıların fonlarını geçici veya kalıcı olarak dondurabilirler. Ama daha iyisini yapabiliriz.

Bu nedir, nasıl çalışır?

Plasma, bir ölçeklenebilirlik çözümüdür ve bir operatörün blokları zincir dışında yayınlamasını ve bu blokların Merkle köklerini zincire yerleştirmesini içerir. Her blok için, operatör her kullanıcıya, kullanıcının varlıklarının ne şekilde değiştiğini veya değişmediğini kanıtlamak için bir Merkle dalı gönderir. Kullanıcılar, varlıklarını çekmek için Merkle dalını sağlayarak işlem yapabilirler. Önemli olan, bu dalın en güncel durum için kök olarak kullanılmasının gerekmediğidir. Bu nedenle, veri kullanılabilirliği sorunları olsa bile, kullanıcılar en son kullanılabilir durumu çekerek varlıklarını geri kazanabilirler. Eğer bir kullanıcı geçersiz bir dal sunarsa, varlıkların yasal mülkiyetini zincirdeki meydan okuma mekanizması ile belirlemek mümkündür.

Erken Plasma versiyonları yalnızca ödeme durumlarını işleyebiliyordu ve etkili bir şekilde daha fazla yaygınlaştırılamıyordu. Ancak, her kökün SNARK ile doğrulanmasını talep edersek, Plasma çok daha güçlü hale gelecektir. Her bir meydan okuma oyunu büyük ölçüde basitleştirilebilir,