Ethereum'un Geleceği: The Surge

Ethereum'un yol haritası başlangıçta iki tür ölçeklendirme stratejisi içeriyordu: parçalama ve Layer 2 protokolleri. Araştırmalar derinleştikçe, bu iki yol bir araya geldi ve Rollup merkezli bir yol haritası oluşturdu, bu hala Ethereum'un mevcut genişleme stratejisidir.

Rollup merkezli bir yol haritası, basit bir iş bölümünü önermektedir: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olma üzerine odaklanırken, L2, ekosistemi genişletme görevini üstlenmektedir. Bu model toplumda oldukça yaygındır: Mahkeme sistemi ( L1), aşırı hız ve verimlilik peşinde değil, sözleşmeleri ve mülkiyet haklarını korumak için var olmaktadır; girişimciler ( L2) ise bu sağlam temel katman üzerinde inşa etmeli ve insan gelişimini ilerletmelidir.

Bu yıl, Rollup merkezli yol haritası önemli başarılar elde etti: EIP-4844 blobs'un piyasaya sürülmesiyle birlikte, Ethereum L1'in veri bant genişliği büyük ölçüde arttı, birden fazla Ethereum sanal makinesi (EVM) Rollup birinci aşamaya girdi. Her L2, kendi iç kuralları ve mantığına sahip bir "parçacık" olarak varlık gösterir, parçacıkların uygulanma çeşitliliği ve çeşitliliği artık bir gerçek haline geldi. Ancak gördüğümüz gibi, bu yolu takip etmek bazı benzersiz zorluklarla karşı karşıya kalmaktadır. 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ığını 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'ler Ethereum'un temel özelliklerini tam olarak devraldı ( güven, açık, sansüre dayanıklı );

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

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

1. Ölçeklenebilirlik Üçgen Paradoksu
2. Veri kullanılabilirliği örneklemesindeki ilerlemeler
3. Veri Sıkıştırma
4. Genelleştirilmiş Plasma
5. Olgun L2 kanıt sistemi
6. L2'ler Arası Operasyonel İyileştirme
7. L1 üzerinde genişletme işlemi

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgeni paradoksu, 2017 yılında ortaya atılan bir fikirdir. Bu, blockchain'in üç özelliği arasında bir çelişki olduğunu öne sürmektedir: merkeziyetsizlik (, daha spesifik olarak, çalışan düğümlerin maliyetinin düşük olması ), ölçeklenebilirlik (, işlenen işlem sayısının fazla olması ) ve güvenlik (, saldırganların bir işlemi başarısız kılmak için ağdaki çok büyük bir bölümdeki düğümleri yok etmesi gerektiğini belirtmektedir ).

Dikkate değer olan, üçgen paradoksunun bir teorem olmamasıdır; üçgen paradoksunu tanıtan gönderiler de matematiksel bir kanıtla birlikte değildir. Gerçekten de, bir merkeziyetsiz dostu düğüm ( örneğin bir tüketici dizüstü bilgisayarı ) her saniye N işlem doğrulayabiliyorsa ve sizde her saniye k*N işlem işleyebilen bir zincir 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 sadece birkaç düğümü yok ederek kötü niyetli bir işlem gerçekleştirebilir, ya da (ii) düğümünüz güçlü hale gelirken, zinciriniz merkeziyetsiz olmayacaktır. Bu makalenin amacı, üçgen paradoksunu çiğnemenin imkansız olduğunu kanıtlamak değildir; aksine, üçlü paradoksu çiğnemenin zor olduğunu, bunun da söz konusu argümanın içerdiği düşünce çerçevesinden bir şekilde çıkmayı gerektirdiğini göstermektir.

Yıllar boyunca, bazı yüksek performanslı zincirler, mimariyi temelden değiştirmeden üçlü çelişkiyi çö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; bu zincirlerde düğüm çalıştırmak, Ethereum'da düğüm çalıştırmaktan çok daha zordur. Bu makalede bunun neden böyle olduğu ve yalnızca L1 istemci yazılım mühendisliğinin Ethereum'u ölçeklendiremeyeceği nedenleri araştırılacaktır.

Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten de üçgen paradoksunu çözmektedir: Bu, istemcilerin yalnızca az miktarda veri indirip çok az hesaplama yaparak belirli bir miktarda verinin kullanılabilir olduğunu ve belirli bir miktarda işlem adımının doğru bir şekilde gerçekleştirildiğini doğrulamasına olanak tanır. SNARK'lar güven gerektirmeyen bir yapıdır. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşır, ancak ölçeklenemez zincirlerin sahip olduğu temel özellikleri korur; bu da, %51'lik saldırıların kötü blokların ağ tarafından kabul edilmesini zorlayamayacağı anlamına gelir.

Üç zorluk sorununu çözmenin bir başka yolu Plasma mimarisidir; bu, kullanıcıların izleme veri kullanılabilirliği sorumluluğunu teşvik edici bir şekilde üstlenmeleri için akıllıca bir teknoloji kullanır. 2017-2019 yıllarında, yalnızca dolandırıcılık kanıtı ile hesaplama kapasitesini genişletme yöntemimiz olduğunda, Plasma’nın güvenli yürütme konusunda çok sınırlıydı; ancak SNARKs( sıfır bilgi 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 Düzey Gelişmeleri

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

13 Mart 2024'te Dencun yükseltmesi çevrimiçi olduğunda, Ethereum blok zincirinde her 12 saniyede 3 adet yaklaşık 125 kB blob içeren slotlar 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ığı varsayıldığında, 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ı ( teorik maksimum değeri eklersek: 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 için 463-926 TPS sağlayacaktır.

Bu, Ethereum L1 için büyük 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, 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 (prime field) üzerinde 4096. dereceden bir polinomdur (polynomial). Polinomun paylarını yayınlıyoruz, burada her pay, toplam 8192 koordinattan komşu olan 16 koordinattaki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden, mevcut önerilen parametrelere göre: 128 olası örnekten herhangi biri olan 64 tane ( 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 yayınlar ve küresel p2p ağındaki eşlerden ) farklı alt ağları dinleyecek olanları sorgulayarak ihtiyaç duyduğu diğer alt ağlardaki blob’ları talep eder. Daha ihtiyatlı bir versiyon olan SubnetDAS, ek bir eş katman sorgulaması olmaksızın yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, hisse kanıtına katılan düğümlerin SubnetDAS kullanmasını, diğer düğümlerin ( 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( hedefi 128)'e çıkartırsak, 16MB hedefine ulaşabiliriz ve veri kullanılabilirliği örneklemesinde her düğüm için 16 örnek * 128 blob * her blob için her örnekte 512 bayt = her slot için 1 MB veri bant genişliği elde ederiz. Bu, yalnızca kabul edilebilir sınırlarımızda bir zorlamadır: 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 bunu bir ölçüde optimize edebiliriz, ancak bu yeniden yapılandırma maliyetlerini artırır.

Bu nedenle, nihayet daha ileri gitmek istiyoruz, 2D örnekleme (2D sampling), 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 özelliklerini kullanarak, bir bloktaki blob kümesini yeni sanal blob seti ile genişletiyoruz, bu sanal bloblar aynı bilgiyi gereksiz yere kodlamaktadır.

Bu nedenle, nihayetinde daha ileri gitmek istiyoruz, 2D örnekleme yapmak, bu sadece blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmak. KZG taahhüdünün lineer özellikleri, aynı bilgiye yönelik yedekleme kodlaması yapan yeni sanal blob listesini içeren bir bloktaki blob setini genişletmek için kullanılır.

Son derece önemlidir ki, hesaplama taahhüdünün genişletilmesi için blob'a ihtiyaç yoktur, bu nedenle bu yaklaşım temelde dağıtık 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 kullanılabilirliği örnekleme (DAS)'ya güvenerek veri bloklarının kullanılabilirliğini doğrulayabilirler. Tek boyutlu veri kullanılabilirliği örnekleme (1D DAS) esasen dağıtık blok inşası için de dosttur.

( Daha ne yapılması gerekiyor? Hangi dengeler var?

Sonraki adım, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Ardından, PeerDAS üzerindeki blob sayısını sürekli artırmak ve güvenliği sağlamak için ağı dikkatle gözlemleyip yazılımı geliştirmek, aşamalı 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 standartlaştırmak için daha fazla akademik çalışmanın olmasını umuyoruz.

Geleceğin daha ileriki aşamalarında, 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 ayar gerektirmeyen bir alternatife geçebilmemizi umuyoruz. Şu anda, dağıtık blok inşası için hangi adayların dostça olduğu konusunda net bir bilgiye sahip değiliz. Pahalı "kaba kuvvet" teknolojisi kullanılsa bile, yani satır ve sütunların yeniden inşası için geçerlilik kanıtları üretmek için yinelemeli STARK kullanılsa da, ihtiyaçları 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, gerçekte STARK neredeyse tüm blob kadar büyüktür.

Uzun vadeli gerçekçi yolun şöyle olduğunu düşünüyorum:

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

Lütfen dikkat edin, eğer L1 katmanında doğrudan genişletme yapmaya karar verirsek, bu seçeneğin mevcut olduğu anlamına gelir. Bunun nedeni, L1 katmanı yüksek TPS miktarını işlemek zorunda kalırsa, L1 bloklarının çok büyük hale gelmesi ve istemcilerin bunların doğruluğunu doğrulamak için verimli bir yöntem arayışında olmalarıdır. Bu nedenle, L1 katmanında ZK-EVM ve DAS( gibi Rollup) ile aynı teknolojileri kullanmak zorunda kalacağız.

( Yol haritası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, eğer Plasma yaygın olarak kullanılıyorsa, talep daha da azalacaktır. DAS, dağıtılmış blok inşa protokolleri ve mekanizmaları için de zorluklar ortaya koymaktadır: teorik olarak DAS, dağıtılmış yeniden inşaya dosttur, ancak bu pratikte, paket dahil etme listesi önerisi ve etrafındaki çatallama seçim mekanizması ile bir araya getirilmesi gerekmektedir.

![Vitalik yeni yazısı: Ethereum'un olası geleceği, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###

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ılabilirliği örneklemesi olsa bile, bu Layer protokollerinin ölçeklenebilirliğini kısıtlar. Her slot 16 MB, şöyle hesaplıyoruz:

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 zincir üzerindeki boyutunu daha az byte 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ırmasında, her uzun sıfır bayt dizisini iki baytla değiştirerek kaç tane sıfır bayt olduğunu gösteriyoruz. Daha da ileri giderek, işlemin belirli özelliklerinden yararlandık:

İmza Birleştirme: Biz