Ethereum'in Olası Geleceği: The Surge

The Surge: Ana Hedefler

1. Gelecekte Ethereum, L2 aracılığıyla 100.000'in üzerinde TPS'ye ulaşabilir;

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

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

4. Ethereum, 34 farklı blok zinciri değil, birleşik bir ekosistem gibi hissettirmelidir.

Bu Bölümün İçeriği

1. Ölçeklenebilirlik Üçgen Paradoksu
2. Veri Erişilebilirliği Örneklemesi ile İlgili Daha Fazla Gelişme
3. Veri Sıkıştırma
4. Genelleşmiş Plasma
5. Olgun L2 kanıt sistemi
6. L2'ler Arası İşlem Geliştirmeleri
7. L1 üzerinde genişletme yürütme

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgeni paradoksu, 2017 yılında ortaya atılmış bir fikir olup, blok zincirinin üç özelliği arasında bir çelişki olduğunu öne sürmektedir: merkeziyetsizlik (daha spesifik olarak: düğüm çalıştırmanın maliyeti düşük), ölçeklenebilirlik (işlem sayısının yüksek olması) ve güvenlik (bir saldırganın tek bir işlemi başarısız kılmak için ağdaki çok büyük bir kısmı yok etmesi gerekir).

Dikkate değer olan, üçgen paradoksunun bir teorem olmamasıdır; üçgen paradoksunu tanıtan gönderiler de matematiksel bir kanıt sunmamaktadır. Bu gerçekten de sezgisel bir matematiksel argüman ortaya koymaktadır: Eğer merkeziyetsiz dostu bir düğüm (örneğin, bir tüketici dizüstü bilgisayarı) saniyede N işlem doğruluyorsa ve senin saniyede k*N işlem işleyen bir zincirin 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şlem yapabilir veya (ii) düğümleriniz 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 bu argümanın içerdiği düşünce çerçevesinin bir şekilde dışına çıkmayı gerektirdiğini göstermek amaçlanmaktadır.

Yıllar boyunca, bazı yüksek performanslı zincirler, mimarilerini köklü bir şekilde değiştirmeden üçlü paradoksu çö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, çünkü bu zincirlerde düğüm çalıştırmak, Ethereum'da düğüm çalıştırmaktan çok daha zordur. Bu makale, neden böyle olduğunu ve yalnızca L1 istemci yazılım mühendisliğinin Ethereum'u ölçeklendiremeyeceğini araştıracaktır.

Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleştirilmesi gerçekten üçgen paradoksunu çözer: Bu, istemcilerin sadece 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ğrulamalarına olanak tanır. SNARK'lar güvene dayanmayan yapılardır. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşır, ancak 51% saldırısının kötü blokların ağ tarafından kabul edilmesini zorlayamayacağı, ölçeklenemez zincirlerin sahip olduğu temel özellikleri korur.

Üçlü zorlukları çözmenin bir diğer yolu Plasma mimarisidir. Bu mimari, verilerin kullanılabilirliğini izleme sorumluluğunu kullanıcıya teşvik edici bir şekilde devretmek için akıllıca bir teknoloji kullanır. 2017-2019 yılları arasında, yalnızca dolandırıcılık kanıtlarına sahip olduğumuzda, Plasma'nın güvenli uygulama konusundaki sınırlamaları oldukça fazlaydı; ancak SNARK'ların (sıfır bilgi kısa etkileşimsiz kanıtlar) yaygınlaşmasıyla birlikte, Plasma mimarisi daha önce hiç olmadığı kadar geniş kullanım senaryoları için daha uygulanabilir hale geldi.

Veri Erişilebilirliği Örneklemesindeki İlerlemeler

Hangi sorunu çözmeye çalışıyoruz?

2024 yılının 13 Martında, Dencun güncellemesi çevrimiçi olduğunda, 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. Eğer işlem verileri doğrudan zincir üzerinde yayınlanırsa, ERC20 transferi yaklaşık 180 bayt olduğu için Rollup üzerindeki maksimum TPS: 375000 / 12 / 180 = 173.6 TPS.

Eğer eklediğimiz calldata (teorik maksimum değer: her slot için 30 milyon Gas / her bayt için 16 Gas = her slot için 1,875,000 bayt) olursa, 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, 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ştirmeleri ile birleştirilirse, ~58000 TPS getirecektir.

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

PeerDAS, "1D sampling" için nispeten basit bir uygulamadır. Burada, her blob 253 bitlik asal alan (prime field) üzerinde 4096. dereceden bir çokterimlidir (polynomial). Polinomun paylarını yayı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 bir 4096'sı (önerilen parametrelere göre: 128 olası örnekten herhangi bir 64'ü) blob'u geri kazandırabilir.

PeerDAS'ın çalışma prensibi, her istemcinin belirli bir sayıda alt ağa dinlemesi ve i'inci alt ağda herhangi bir blob'un i'inci örneğini yayınlaması ve küresel p2p ağındaki eşlerden (farklı alt ağları dinleyecek olanlar) ihtiyaç duyduğu diğer alt ağlardaki blob'u istemek için sorgulama yapmasıdır. Daha temkinli bir versiyon olan SubnetDAS, ek bir eş katmanını sorgulamadan yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, stake eden düğümlerin SubnetDAS'ı kullanması, diğer düğümlerin (yani istemcilerin) ise PeerDAS'ı kullanmasıdır.

Teorik olarak, "1D sampling" ölçeğini oldukça büyük bir şekilde genişletebiliriz: Eğer blob'ların maksimum sayısını 256'ya (hedef 128) çıkarırsak, 16MB'lık hedefe ulaşabiliriz ve veri kullanılabilirliği örneklemesinde her düğüm 16 örnek * 128 blob * her blob başına her örnek 512 byte = her slot için 1 MB veri bant genişliği sağlar. Bu, bizim tolerans aralığımızın zorlukla içinde: 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 bu durumu belirli bir ölçüde optimize edebiliriz, ancak bu, yeniden inşa maliyetlerini artıracaktır.

Bu nedenle, nihayet daha ileri gitmek istiyoruz ve 2D örnekleme (2D sampling) gerçekleştirmek istiyoruz. 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 yararlanarak, bir bloktaki blob kümesini genişletmek için yeni sanal bloblar seti kullanılır; bu sanal bloblar, aynı bilgiyi gereksiz yere kodlamaktadır.

Bu nedenle, nihayetinde daha ileri gitmek istiyoruz ve hem blob içinde hem de bloblar arasında rastgele örnekleme yaparak 2D örnekleme gerçekleştirmek istiyoruz. KZG taahhüdünün doğrusal özellikleri, aynı bilgiyi yedek kodlama yapan yeni sanal blob listesini içeren bir bloktaki blob kümesini genişletmek için kullanılır.

Son derece önemlidir ki, hesaplamalı taahhütlerin genişletilmesi blob gerektirmemektedir, bu nedenle bu plan temelde dağıtılmış blok inşasına dosttur. Gerçek blok inşa eden düğümlerin yalnızca blob KZG taahhüdüne sahip olmaları gerekir ve veri kullanılabilirliği örneklemesine (DAS) güvenerek veri parçalarının kullanılabilirliğini doğrulayabilirler. Tek boyutlu veri kullanılabilirliği örneklemesi (1D DAS) esasen dağıtılmış blok inşasına da 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ğı dikkatlice izlemek ve güvenliği sağlamak için yazılımı geliştirmek, aşamalı bir süreçtir. Bu arada, PeerDAS'ı ve diğer DAS sürümlerini standartlaştırmak ve bunların fork seçim kuralları güvenliği gibi konulardaki etkileşimleri için daha fazla akademik çalışma yapılmasını umuyoruz.

Gelecekte daha ileri 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 kurulum gerektirmeyen bir alternatife geçmeyi umuyoruz. Şu anda, dağıtılmış blok inşasına dost olan hangi adayların mevcut olduğunu net bir şekilde bilmiyoruz. Pahalı "brute force" tekniklerini kullanmak, yani yeniden yapılandırma satır ve sütunları için geçerlilik kanıtları üretmek amacıyla yinelemeli STARK 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 değeri (STIR kullanarak) olsa da, gerçekte STARK neredeyse tüm blob kadar büyüktür.

Uzun vadeli gerçeklik yolunun şöyle olduğunu düşünüyorum:

1. İdeal 2D DAS'ı uygulamak;
2. 1D DAS kullanmaya devam edin, örnekleme bant genişliği verimliliğinden feragat edin, basitlik ve dayanıklılık için daha düşük veri üst sınırını kabul edin.
3. DA'dan vazgeçin, Plasma'yı 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 de var olduğunu. Bunun nedeni, L1 katmanı çok sayıda TPS işlemek zorunda kalırsa, L1 bloklarının çok büyük hale gelmesidir; istemciler bunların doğruluğunu doğrulamak için etkili bir yöntem arayacaklardır. Bu nedenle, L1 katmanında Rollup (ZK-EVM ve DAS gibi) ile aynı teknolojiyi kullanmak zorunda kalacağız.

Harita'nın diğer bölümleriyle nasıl etkileşime geçilir?

Eğer veri sıkıştırması gerçekleştirilirse, 2D DAS’a olan talep azalacak veya en azından ertelenecektir. 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 yapılandırma için dost olsa da, pratikte bu, paket dahil etme listesi önerisi ve etrafındaki çatallama seçim mekanizması ile bir araya getirilmelidir.

Veri Sıkıştırma

Hangi sorunu çözüyoruz?

Rollup içindeki her işlem büyük miktarda zincir içi veri alanı 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 payda problemlerini değil, aynı zamanda pay problemlerini de çözebilirsek ve her Rollup içindeki işlemler zincirde daha az bayt kaplarsa, ne olur?

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

Bana göre en iyi açıklama iki yıl önceki bu resimdir:

Sıfır baytı sıkıştırmada, her uzun sıfır bayt dizisini kaç tane sıfır baytı olduğunu belirtmek için iki bayt ile değiştiriyoruz. Daha da 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ğundan BLS imzasının kullanılması düşünülmemektedir. Ancak L2 gibi veri kıtlığı olan ortamlarda BLS imzasının kullanılması anlamlıdır. ERC-4337'nin birleştirme özelliği bu işlevi gerçekleştirmek için bir yol sağlar.