Vitalik'in Yeni Makalesi: Ethereum'un 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. Bu iki yol 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ü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 yıl, Rollup merkezli yol haritası önemli başarılar elde etti: EIP-4844 bloblarının piyasaya sürülmesiyle, Ethereum L1'in veri bant genişliği büyük ölçüde arttı, birçok Ethereum sanal makinesi (EVM) Rollup ilk aşamaya girdi. Her L2, kendi iç kuralları ve mantığına sahip "parçalar" olarak var olmaktadır; 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 yolda bazı özel zorluklarla karşılaşmaktayız. Bu nedenle, şu anki görevimiz Rollup merkezli yol haritasını tamamlamak ve bu sorunları çözmektir; aynı zamanda Ethereum L1'in kendine özgü sağlamlığı ve merkeziyetsizliğini korumaktır.

The Surge: Ana Hedefler

1. Gelecekte Ethereum L2 ile 100.000'in üzerinde TPS'ye ulaşabilir;

2. L1'in merkeziyetsizliğini ve dayanıklılığını koruyun;

3. En azından bazı L2, Ethereum'un temel özelliklerini ( güven duymak, açık, sansüre dayanıklı ) tamamen devralmıştır;

4. Ethereum, 34 farklı blok zinciri değil, bir bütünleşik ekosistem gibi hissettirmelidir.

Bu bölümün içeriği

1. Ölçeklenebilirlik Üçgen Paradoksu
2. Veri kullanılabilirliği örneklemesinin daha fazla ilerlemesi
3. Veri Sıkıştırma
4. Genelleştirilmiş Plasma
5. Olgun L2 kanıt sistemi
6. L2'ler arası etkileşim iyileştirmeleri
7. L1 üzerinde genişletme yürütme

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgeni paradoksu, 2017 yılında ortaya atılan bir düşüncedir ve blok zincirinin üç özelliği arasında çelişki olduğunu öne sürmektedir: merkeziyetsizlik ( daha spesifik olarak: çalıştırılan düğümlerin maliyetinin düşük olması ), ölçeklenebilirlik ( işlenen 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 büyük bir kısmı yok etmesi gerektiği ).

Dikkate değer olan, üçgen paradoksunun bir teorem olmadığıdır; üçgen paradoksunu tanıtan gönderiler de matematiksel bir kanıtla birlikte gelmemektedir. Bu, bir sezgisel matematik argümanı sunmaktadır: Eğer merkeziyetsiz dostu bir düğüm ( örneğin bir tüketici dizüstü bilgisayarı ) her saniye N işlem doğrulayabiliyorsa ve sizin k*N işlem işleyebilen 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ın yalnızca birkaç düğümü bozması yeterlidir ki kötü niyetli bir işlem gerçekleştirebilsin, ya da (ii) düğümünüz güçlü hale gelecektir, ancak zinciriniz merkeziyetsiz olmayacaktır. Bu makalenin amacı, üçgen paradoksunu kırmanın imkansız olduğunu kanıtlamak değildir; bunun yerine, üçlü paradoksu kırmanın zor olduğunu ve belirli bir ölçüde bu argümanın içerdiği düşünce çerçevesinden çıkmayı gerektirdiğini göstermektir.

Yıllardır, bazı yüksek performanslı zincirler, temelde mimariyi değiştirmeden üçlü paradoksu çözdüklerini iddia ediyorlar, genellikle düğümleri optimize etmek için yazılım mühendisliği teknikleri uygulayarak. 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 zordur. Bu makalede neden böyle olduğuna ve neden yalnızca L1 istemci yazılım mühendisliğinin kendisinin Ethereum'u ölçeklendiremeyeceğine değinilecektir.

Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten üçgen paradoksunu çözmektedir: bu, istemcilerin yalnızca az miktarda veri indirerek ve çok az hesaplama yaparak belirli bir miktarda verinin mevcut 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üvenmeye gerek olmadan çalışır. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşırken, 51%'lik bir saldırının kötü blokların ağ tarafından kabul edilmesini zorlamayacağı temel özellikleri korur.

Üç zorluk sorununu çözmenin bir başka yolu Plasma mimarisidir; bu mimari, izleme verilerinin kullanılabilirliğini kullanıcıların sorumluluğuna devretmek için akıllı teknolojiler kullanarak uyumlu bir şekilde teşvik eder. 2017-2019 yıllarında, yalnızca sahtecilik kanıtı gibi bir aracımız varken, Plasma güvenli yürütme 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 Erişilebilirliği Örneklemesinin İleri Gelişmeleri

Hangi sorunu çözüyoruz?

13 Mart 2024'te Dencun güncellemesi devreye girdiğinde, Ethereum blockchain'inde her 12 saniyede 3 adet yaklaşık 125 kB blob olacak, yani her slot için veri kullanılabilir bant genişliği yaklaşık 375 kB. Eğer işlem verileri doğrudan zincir üzerinde yayınlanırsa, ERC20 transferi yaklaşık 180 bayt olur, 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'ye dönüşür. 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 önemli bir yükseltme, ama 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ştirmeleri ile birleştirilirse, ~58000 TPS getirecek.

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

PeerDAS, "1D sampling"ın göreceli olarak basit bir uygulamasıdır. Ethereum'da, her blob, 253 bit asal alan (prime field) üzerindeki 4096. dereceden bir polinomdur (polynomial). Polinomun paylarını yayıyoruz, her pay toplamda 8192 koordinattan ardışık 16 koordinatta 16 değerlendirme değeri içermektedir. Bu 8192 değerlendirme değerinden, herhangi bir 4096'ı ( mevcut parametreler doğrultusunda: 128 olası örnekten herhangi bir 64'ü ) blob'u kurtarmak için kullanılabilir.

PeerDAS'ın çalışma prensibi, her bir istemcinin az sayıda alt ağı dinlemesini sağlamaktır. Burada i'nci alt ağ, herhangi bir blob'un i'nci örneğini yayınlamakta ve küresel p2p ağındaki eşlerden (, farklı alt ağları dinleyecek olanı sormaktadır ), böylece ihtiyaç duyduğu diğer alt ağlardaki blob'ları talep edebilmektedir. Daha temkinli bir versiyon olan SubnetDAS, ek bir eş katmanına sorgulama olmadan yalnızca alt ağ mekanizmasını kullanmaktadı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 sampling" ölçeğini oldukça büyük bir şekilde genişletebiliriz: Eğer blob'un maksimum sayısını 256( hedefi 128)'e çıkarırsak, o zaman 16MB'lık 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 byte = her slot için 1 MB veri bant genişliği elde ederiz. Bu, tolerans aralığımızın sınırlarında zar zor kalıyor: bu uygulanabilir, ancak bu, bant genişliği kısıtlı istemcilerin örnekleme yapamayacağı anlamına geliyor. Blob sayısını azaltarak ve blob boyutunu artırarak bunu belli bir ölçüde optimize edebiliriz, ancak bu yeniden oluşturma maliyetini artıracaktır.

Bu nedenle, nihayetinde daha ileri gitmek ve 2D örnekleme (2D sampling) yapmak istiyoruz. Bu yöntem sadece 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 grubunu kullanarak, bu sanal bloblar aynı bilgiyi gereksiz bir şekilde kodlar.

Bu nedenle, nihayetinde daha ileri gitmek istiyoruz, 2D örnekleme yaparak, bu yalnızca blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmaktır. KZG taahhüdünün doğrusal özellikleri, aynı bilgilere yönelik yedekleme kodlaması yapan yeni sanal blob listesinin bulunduğu 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 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ı ve veri kullanılabilirliği örnekleme (DAS) ile veri bloklarının kullanılabilirliğini doğrulamak için güvenebilirler. Tek boyutlu veri kullanılabilirliği örneklemesi (1D DAS) esasen dağıtılmış blok inşasına da dosttur.

Ne 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, aşamalı bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümleri ile bunların çatallama seçim kuralları güvenliği gibi sorunlarla etkileşimini düzenlemek için daha fazla akademik çalışmanın olmasını umuyoruz.

Gelecekteki 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, nihayetinde KZG'den kuantum güvenli ve güvenilir bir kurulum gerektirmeyen bir alternatif çözüme geçebilmeyi umuyoruz. Şu anda, dağıtılmış blok inşasına dost olan adayların neler olduğunu tam olarak bilmiyoruz. Pahalı "kaba kuvvet" teknolojisini kullanmak, yani yeniden yapılandırma için geçerlilik kanıtı üretmek üzere yineleme STARK kullanmak bile, talebi 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çek yolun benim düşündüğüm şekli şudur:

1. İdeal 2D DAS uygulaması;
2. 1D DAS kullanmaya devam edin, örnekleme bant genişliği verimliliğinden feragat edin, basitlik ve dayanıklılık amacıyla daha düşük veri üst sınırını kabul edin.
3. DA'dan vazgeçmek ve Plasma'yı ana Layer2 mimarisi olarak tamamen kabul etmek.

Lütfen dikkat edin, L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçenek de mevcuttur. Bunun nedeni, L1 katmanının büyük bir TPS'yi işlemek zorunda kalması durumunda, L1 bloklarının çok büyük hale gelmesidir; istemciler bunların doğruluğunu doğrulamak için verimli bir yönteme ihtiyaç duyacaklardır. Bu nedenle, L1 katmanında Rollup( gibi ZK-EVM ve DAS) ile aynı teknolojileri kullanmak zorunda kalacağız.

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

Eğer veri sıkıştırması uygulanırsa, 2D DAS'a olan ihtiyaç azalacak veya en azından gecikecek, Plasma yaygın olarak kullanılıyorsa, ihtiyaç daha da azalacaktır. DAS, dağıtılmış blok oluşturma protokolleri ve mekanizmalarına da zorluklar getirmektedir: teorik olarak DAS, dağıtılmış yeniden inşaya dost olsa da, bu pratikte paket dahil etme listesi önerisi ve etrafındaki çatallama seçim mekanizması ile birleştirilmesi gerekmektedir.

Veri Sıkıştırma

Hangi sorunu çözüyoruz?

Rollup'taki her işlem, büyük miktarda zincir üstü veri alanı kullanır: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirlik örneklemesi olsa bile, bu Layer protokollerinin ölçeklenebilirliğini kısıtlar. Her slot 16 MB, elde ediyoruz:

16000000 / 12 / 180 = 7407 TPS

Eğer sadece payın 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 resim:

Sıfır bayt sıkıştırmasında, her uzun sıfır bayt dizisini ne kadar sıfır bayt olduğunu göstermek için iki baytla değiştiriyoruz. 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ğrulama hesaplama maliyeti yüksek olduğu için BLS imzasının kullanılması düşünülmemektedir. Ancak, L2 gibi veri kıtlığı olan bir ortamda BLS imzasının kullanılması anlamlıdır. ERC-4337'nin birleştirme özelliği bu işlevi gerçekleştirmenin bir yolunu sunmaktadır.

Kullanmak