Ethereum'ın Olabilecek Geleceği: The Surge

Ethereum'un yol haritası başlangıçta iki tür ölçeklenme stratejisi içeriyordu: parçalama ve Layer2 protokolleri. Araştırmaların derinleşmesiyle, bu iki yol bir araya gelerek Rollup merkezli bir yol haritası oluşturdu ve bu hala Ethereum'un mevcut genişleme stratejisidir.

Rollup merkezli yol haritası, basit bir iş bölümünü öneriyor: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olmaya odaklanırken, L2 ekosistemi genişletme görevini üstleniyor. Bu model, toplumda her yerde mevcut: Mahkeme sistemi ( L1), aşırı hızlı ve verimli olmayı amaçlamak için değil, sözleşmeleri ve mülkiyet haklarını korumak için var; girişimciler ( L2) ise bu sağlam temel katman üzerinde inşa ederek insanlığın ilerlemesini teşvik ediyor.

Bu yıl, Rollup merkezli yol haritası önemli başarılara imza attı: EIP-4844 blobs'un 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 birinci aşamaya girdi. Her L2, kendi iç kuralları ve mantığına sahip bir "parça" olarak var olmaktadır; parça uygulama çeşitliliği ve çok yönlülüğü artık bir gerçek haline gelmiştir. Ancak bu yol, bazı benzersiz zorluklarla da karşı karşıya. Şu anda görevimiz, Rollup merkezli yol haritasını tamamlamak ve bu sorunları çözmek, aynı zamanda Ethereum L1'in kendine özgü sağlamlığı ve merkeziyetsizliğini korumaktır.

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ından bazı L2'ler Ethereum'un temel özelliklerini tamamen devraldı ( güven, açık, sansüre dayanıklı );
4. Ethereum, 34 farklı blok zinciri değil, bir bütünleşik ekosistem gibi hissettirmelidir.

Bu makalenin içeriği

1. Ölçeklenebilirlik Üçgen Paradoksu
2. Veri erişilebilirliği örneklemesinin daha fazla ilerlemesi
3. Veri Sıkıştırma
4. Genelleşmiş Plasma
5. Olgun L2 kanıt sistemleri
6. L2ler arası etkileşim iyileştirmesi
7. L1 üzerinde genişletilmiş yürütme

Ölçeklenebilirlik Üçgen Paradoksu

Ölçeklenebilirlik üçgeni paradoksu, blok zincirinin üç özelliği arasında bir çelişki olduğunu savunur: merkeziyetsizlik (, düşük maliyetli çalışan düğümler ), ölçeklenebilirlik (, işlenebilecek işlem sayısı ) ve güvenlik (, bir saldırganın tek bir işlemi başarısız kılmak için ağdaki çok sayıda düğümü yok etmesi gerektiğini belirtir ).

Üçgen paradoksu bir teorem değildir, bu, bir sezgisel matematiksel argüman sunar: Eğer merkeziyetsiz dostu bir düğüm her saniye N işlemi doğrulayabiliyorsa ve sizin k*N işlem işleyen bir zinciriniz varsa, o zaman (i) her bir 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, ya da (ii) düğümünüz güçlenecek, ancak zinciriniz merkeziyetsiz olmayacaktır.

Yıllardır, bazı yüksek performanslı zincirler, temelde mimariyi değiştirmeden üçlü ikilemi çözdüklerini iddia ediyor, genellikle düğümleri optimize etmek için yazılım mühendisliği teknikleri kullanarak. Bu her zaman yanıltıcıdır; bu zincirler üzerinde düğüm çalıştırmak, Ethereum üzerinde 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 çözmektedir: Bu, istemcilerin yalnızca az miktarda veri indirerek ve çok az hesaplama yaparak belirli bir miktar verinin kullanılabilir olduğunu 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 dayalı değildir. Veri kullanılabilirliği örneklemesi, ince bir few-of-N güven modeli taşır, ancak bu, 51%'lik bir saldırının kötü blokların ağ tarafından kabul edilmesini zorlayamayacağı, ölçeklenemez zincirlerin sahip olduğu temel özellikleri korur.

Üçlü zorlukların çözülmesine yönelik bir diğer yöntem Plasma mimarisidir; bu, kullanıcıların izleme veri kullanılabilirliğinin sorumluluğunu teşvik edici bir şekilde devralmalarını sağlamak için zekice bir teknoloji kullanır. 2017-2019 yıllarında, yalnızca sahtekarlık kanıtları ile hesaplama kapasitesini genişletme yöntemimiz varken, Plasma güvenli uygulama açısından oldukça sınırlıydı. Ancak, SNARKs( sıfır bilgi kanıtlarının) yaygınlaşmasıyla birlikte, Plasma mimarisi daha önceki kullanım senaryolarına göre çok daha geniş bir uygulama yelpazesi için uygulanabilir hale gelmiştir.

Veri Erişilebilirliği Örneklemesi ile İlgili İlerlemeler

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

2024 yılının 13 Mart'ında, Dencun güncellemesi devreye girdiğinde, Ethereum blok zincirinin her 12 saniyelik slotunda 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ığı 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ına ( teorik maksimum değerini 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 kadar artabilir, bu da calldata için 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, eğer Rollup veri sıkıştırma iyileştirmeleri ile birleştirilirse, yaklaşık ~58000 TPS getirecek.

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. derece bir çok terimli (polynomial)dır. Çok terimli paylarını yayınlıyoruz; bu paylardan her biri toplamda 8192 koordinattan yan yana olan 16 koordinattaki 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden, mevcut sunulan parametrelere göre: 128 olası örnekten herhangi biri 64 tanesi ( blob'u geri kazanmak için kullanılabilir.

PeerDAS'ın çalışma prensibi, her istemcinin az sayıda alt ağ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ı sorarak ihtiyaç duyduğu diğer alt ağlardaki blob'ları talep eder. Daha temkinli bir versiyon olan SubnetDAS, ek bir eş katmanı sorgulaması olmadan yalnızca alt ağ mekanizmasını kullanır. Mevcut teklif, stake eden düğümlerin SubnetDAS kullanmasını, diğer düğümlerin ise ( yani istemcilerin ) 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( hedefini 128)'e artırı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 örnek 512 bayt = her slot için 1 MB veri bant genişliği elde ederiz. Bu, sınırlarımızın zar zor içinde: bu mümkün, ama bu, bant genişliği sınırlı istemcilerin örnekleme yapamayacağı anlamına geliyor. Blob sayısını azaltarak ve blob boyutunu artırarak bu durumu bir dereceye kadar optimize edebiliriz, ancak bu, yeniden yapılandırma maliyetlerini artıracaktı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 doğrusal özelliğinden yararlanarak, bir bloktaki blob kümesini genişletmek için yeni sanal bloblar grubuyla, bu sanal bloblar aynı bilgiyi gereksiz yere kodlar.

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

( Ne yapmamız gerekiyor? Hangi dengeler var?

Sonraki adım, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Bunun 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 gerekmektedir; bu, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümleri ile fork seçim kuralları güvenliği gibi konular arasındaki etkileşimi düzenlemek için daha fazla akademik çalışmanın olmasını umuyoruz.

Gelecekte daha uzak aşamalarda, 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 ayarlara ihtiyaç duymayan bir alternatife geçmeyi umuyoruz. Şu anda, dağıtık blok inşası için hangi adayların dostane olduğunu tam olarak bilmiyoruz. Pahalı "kaba kuvvet" teknolojisini kullanmak, yani yeniden yapılandırma satırları ve sütunlar için geçerlilik kanıtları oluşturmak üzere yinelemeli STARK kullanmak, talebi karşılamak için yeterli değil, çünkü teknik olarak bir STARK'ın boyutu O)log###n( * log(log)n(( hash değeri ) STIR) ile kullanılsa da, gerçekte STARK neredeyse tüm blob kadar büyüktür.

Uzun vadeli gerçek yolunun benim düşündüğüm şekli:

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

Lütfen dikkat edin, L1 katmanında doğrudan genişletme yapmaya karar verseniz bile, bu seçenek mevcuttur. Bunun nedeni, L1 katmanı büyük miktarda TPS işlemek zorunda kalırsa, L1 bloklarının çok büyük hale geleceğidir; istemciler bunların doğruluğunu doğrulamak için verimli bir yöntem istemek isteyecektir. 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şim kurulur?

Veri sıkıştırmasının gerçekleştirilmesi durumunda, 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ık blok inşa protokolü ve mekanizmalarına da zorluklar çıkarmaktadır: teorik olarak DAS, dağıtık yeniden yapılandırmaya dost olsa da, bu pratiğe döküldüğünde paket dahil etme listesi önerisi ve çevresindeki çatallanma seçim mekanizması ile birleştirilmesi gerekmektedir.

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

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ılabilirlik örneklemesi olsa bile, bu Layer protokollerinin ölçeklenebilirliğini sınırlar. Her slot 16 MB, elde ediyoruz:

16000000 / 12 / 180 = 7407 TPS

Eğer sadece paydaki sorunları değil, aynı zamanda paydadaki sorunları da çözebilirsek ve her Rollup'taki işlemlerin zincirde daha az byte kaplamasını sağlayabilirsek, ne olur?

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

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 ileri giderek, işlemlerin belirli özelliklerinden yararlandık:

İ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ğundan BLS imzası 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şlevselliği sağlamak için bir yol sunmaktadır.

Adresleri pointer ile değiştirme: Daha önce bir adres kullanıldıysa, 20 baytlık adresi tarihçede bir konuma işaret eden 4 baytlık bir pointer ile değiştirebiliriz.

Özel Serileştirme için İşlem Değeri ------ Ç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 öncelikli ücret de benzer şekilde. Bu nedenle, çoğu para birimi değerini ifade etmek için özel ondalık kayan nokta formatı kullanabiliriz.

ne yapmalı, hangi dengeleri gözetmeli?

Sonraki adım, yukarıda belirtilen planı gerçek hayatta uygulamaktır. Ana dengeler şunlardır:

1. BLS imzasına geçmek büyük çaba gerektirir ve güvenliği artırabilenlerle olan ilişkiyi zayıflatır.