Ethereum'in Olası Geleceği: The Surge

The Surge: Ana Hedefler

1. Gelecekte Ethereum, L2 aracılığıyla 100.000'den fazla TPS'ye ulaşabilir;

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

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

4. Ethereum, 34 farklı blok zinciri yerine tek bir bütünleşik ekosistem gibi hissettirmelidir.

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

1. Ölçeklenebilirlik Üçgen Paradoksu
2. Veri erişilebilirliği örneklemesi ile ilgili daha fazla ilerleme
3. Veri Sıkıştırma
4. Genelleştirilmiş Plasma
5. Olgun L2 kanıt sistemleri
6. L2 çapraz 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. Bu düşünceye göre, blok zincirinin üç özelliği arasında bir çelişki vardır: merkeziyetsizlik (daha spesifik olarak: düğümlerin işletim maliyetinin düşük olması), ölçeklenebilirlik (işlem sayısının yüksek olması) ve güvenlik (saldırganların tek bir işlemi başarısız kılmak için ağdaki çok sayıda düğümü devre dışı bırakması gerekmektedir).

Dikkate değer olan, üçgen paradoksunun bir teorem olmaması ve üçgen paradoksunu tanıtan gönderilerin herhangi bir matematiksel kanıtla birlikte gelmemesidir. Bu, gerçekten de bir sezgisel matematiksel argüman sunar: Eğer merkeziyetsiz dostu bir düğüm (örneğin, bir dizüstü bilgisayar) her saniye N işlem doğrulayabiliyorsa ve senin 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 gerçekleştirebilir, veya (ii) düğümlerin güçlü hale gelecektir, ancak zincirin merkeziyetsiz olmayacaktır. Bu makalenin amacı, üçgen paradoksunu kırmanın imkansız olduğunu kanıtlamak değildir; aksine, üçlü paradoksu kırmanın zor olduğunu ve bu argümanın içerdiği düşünce çerçevesinin bir yerinde sıçramayı gerektirdiğini göstermektir.

Yıllar boyunca, bazı yüksek performanslı zincirler, mimariyi temelden değiştirmeden üçlü paradoksu çözdüklerini iddia ettiler, genellikle düğümleri optimize etmek için yazılım mühendisliği tekniklerini 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. Bu makalede, bunun neden böyle olduğunu ve yalnızca L1 istemci yazılım mühendisliğinin kendisinin Ethereum'u ölçeklendiremeyeceğini araştıracağız.

Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleştirilmesi gerçekten üçgen paradoksunu çözmektedir: Bu, istemcilerin yalnızca az miktarda veri indirerek ve çok az sayıda 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ğrulamalarını sağlar. SNARK'lar güvene dayanmadan çalışır. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeline sahiptir, ancak 51%'lik bir saldırının kötü blokların ağ tarafından kabul edilmesini zorlamayacağı temel özellikleri korur.

Üç zorluğun üstesinden gelmenin bir diğer yolu Plasma mimarisidir. Bu mimari, izleme veri kullanılabilirliğinin sorumluluğunu kullanıcıya aktaran akıllı bir teknik kullanarak uyumlu bir şekilde teşvik eder. 2017-2019 yılları arasında, yalnızca dolandırıcılık kanıtı ile hesaplama gücünü genişletme yöntemimiz olduğunda, Plasma, güvenli bir şekilde uygulanması açısından oldukça sınırlıydı. Ancak SNARKs (sıfır bilgi kanıtı) popülaritesinin artmasıyla birlikte, Plasma mimarisi daha önceki kullanım senaryolarına kıyasla çok daha geniş bir yelpazede uygulanabilir hale geldi.

Veri erişilebilirliği örneklemesinin daha fazla ilerlemesi

Hangi sorunu çözüyoruz?

2024 yılında 13 Mart'ta Dencun yükseltmesi çevrimiçi olduğunda, Ethereum blok zinciri her 12 saniyede 3 adet yaklaşık 125 kB blob içeren slotlar sunacak, 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ğu için Ethereum üzerindeki Rollup'ın maksimum TPS'si: 375000 / 12 / 180 = 173.6 TPS'dir.

Eğer Ethereum'un calldata'sını (teorik maksimum değer: her slot için 30 milyon Gas / her byte için 16 gas = her slot için 1.875.000 byte) eklersek, 607 TPS olacaktır. PeerDAS kullanarak, blob sayısı 8-16'ya çıkabilir, bu da calldata'ya 463-926 TPS sağlayacaktır.

Bu, Ethereum L1 için önemli bir yükseltme, ancak yeterli değil. Daha fazla ölçeklenebilirlik istiyoruz. Orta vadeli hedefimiz, her slot için 16 MB, Rollup veri sıkıştırma iyileştirmeleri ile birleştirildiğinde ~58000 TPS getirecek.

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) üzerinde 4096. dereceden bir polinom (polynomial) olarak tanımlanır. Paylaşımını yaptığımız polinomun payları, toplam 8192 koordinattan bitişik 16 koordinat üzerindeki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden herhangi 4096'sı (mevcut önerilen parametreye göre: 128 olası örnekten herhangi 64'ü) blob'u geri kazanmak için kullanılabilir.

PeerDAS'ın çalışma prensibi, her bir istemcinin, i. alt ağın herhangi bir blob'unun i. örneğini yayınladığı ve global p2p ağındaki eşlerle (farklı alt ağları dinleyecek olanlar) ihtiyaç duyduğu diğer alt ağlardaki blob'ları istemek için sorgulama yaparak dinlemesi için az sayıda alt ağı dinlemesini sağlamaktır. Daha temkinli bir versiyon olan SubnetDAS, ek bir sorgulama eş katman olmaksızın yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, stake eden düğümlerin SubnetDAS kullanmasını, diğer düğümlerin (yani istemcilerin) ise 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'ların maksimum sayısını 256'ya (hedef 128) çıkarırsak, 16MB hedefimize 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 edilir. Bu, zar zor tolerans sınırlarımız içinde kalır: 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ırır.

Bu nedenle, nihayet daha ileri gitmek istiyoruz ve 2B örnekleme (2D sampling) yapmak istiyoruz. Bu yöntem, yalnızca blob içerisinde rastgele örnekleme yapmakla kalmaz, aynı zamanda bloblar arasında da rastgele örnekleme yapar. KZG taahhüdünün doğrusal özelliklerinden yararlanarak, bir bloktaki blob kümesini genişletmek için yeni sanal blob seti kullanarak, bu sanal bloblar aynı bilgiyi fazladan 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 yapıyor. KZG taahhüdünün doğrusal özelliği, aynı bilgilere ait yeni sanal blob listesinin fazla kodlaması ile içeren bir bloktaki blob kümesini genişletmek için kullanılır.

Son derece önemlidir ki, hesaplama taahhüdünün genişletilmesi için bir 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üğümlerin yalnızca blob KZG taahhüdüne sahip olmaları gerekir ve veri kullanılabilirliği örneklemesine (DAS) güvenerek veri bloklarının kullanılabilirliğini doğrulayabilirler. Tek boyutlu veri kullanılabilirliği örneklemesi (1D DAS) özünde dağıtık blok inşasına da dosttur.

Ne yapmam gerekiyor? Hangi dengeleri gözetmeliyim?

Sonraki aşama, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Ardından, PeerDAS üzerindeki blob sayısını sürekli artırırken, ağı dikkatle izlemek 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 çatallama seçim kuralları güvenliği gibi konuların etkileşimini standartlaştırmak için daha fazla akademik çalışmanın yapılmasını 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, nihayetinde KZG'den kuantum güvenli ve güvenilir bir kurulum gerektirmeyen bir alternatif çözüme geçmeyi umuyoruz. Şu anda, dağıtık blok inşası için hangi adayların dostça olduğuna dair net bir bilgimiz yok. Pahalı "zorla" tekniklerini kullanmak, yani geri döngü STARK kullanarak satır ve sütunları yeniden oluşturmak için geçerlilik kanıtları üretmek bile ihtiyaçları karşılamaya yetmiyor, çünkü teknik olarak bir STARK'ın boyutu O(log(n) * log(log(n)) hash değeri (STIR kullanarak) olmasına rağmen, gerçekte STARK neredeyse tüm blob kadar büyüktür.

Uzun vadeli gerçekçi yolun benim düşünceme göre şu şekildedir:

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 sınırını kabul edin.
3. DA'dan vazgeçin, Plasma'yı ana Layer2 mimarimiz olarak tamamen kabul edin.

Lütfen dikkat edin, eğer L1 katmanında doğrudan genişleme yapmaya karar verirsek, bu seçeneğin var olduğu. Bunun nedeni, eğer L1 katmanı büyük miktarda TPS ile başa çıkmak zorundaysa, L1 bloklarının çok büyük hale gelmesidir. İstemcilerin bunların doğruluğunu doğrulamak için etkili bir yöntem arayacakları için, L1 katmanında Rollup'lar (ZK-EVM ve DAS gibi) 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ırsa, talep daha da azalacaktır. DAS ayrıca dağıtık blok inşa protokolleri ve mekanizmaları için zorluklar ortaya çıkarmaktadır: teorik olarak DAS dağıtık yeniden inşa ile dost olsa da, bu pratikte paket dahil etme listesi önerisi ve çevresindeki çatallama seçim mekanizması ile birleştirilmesi gerekmektedir.

Veri Sıkıştırma

Hangi sorunu çözüyoruz?

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

16000000 / 12 / 180 = 7407 TPS

Eğer sadece payda sorununu değil, aynı zamanda pay sorununu da çözersek ve her Rollup'taki işlemler zincir üzerinde 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ırmasında, her uzun sıfır bayt dizisini değiştirmek için iki bayt kullanarak, sıfır bayt sayısını gösteriyoruz. Daha da ileri giderek, işlemin belirli özelliklerinden yararlanıyoruz:

İmza birleştirme: ECDSA imzasından BLS imzasına geçiyoruz. BLS imzasının özelliği, birden fazla imzanın tek bir imzada birleştirilebilmesidir; 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ılması düşünülmemektedir. Ancak L2 gibi veri kıtlığı olan ortamlarda BLS imzası kullanmak anlamlıdır. ERC-4337'nin birleştirme özelliği bu işlevi gerçekleştirmek 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 konumu işaret eden 4 baytlık bir pointer ile değiştirebiliriz.

İşlem değerinin özel serileştirilmesi------Çoğu işlem değerinin haneleri azdır, örneğin, 0.25 ETH 250,000,000,000,000,000 wei olarak ifade edilir. Maksimum temel el