Yazan: Vitalik Buterin

Derleyen: Yangz, Techub Haberleri

Başlangıçta Ethereum’un yol haritasında iki ölçeklendirme stratejisi vardı. Bunlardan biri (2015'teki ilk tartışmaya bakın) "parçalama"dır: her düğümün tüm işlemler yerine yalnızca zincirdeki işlemlerin küçük bir kısmını doğrulaması ve saklaması gerekir. Diğer herhangi bir eşler arası ağ (BitTorrent gibi) bu şekilde çalışır, dolayısıyla blok zincirlerin kesinlikle aynı şekilde çalışmasını sağlayabiliriz. Diğer bir yaklaşım ise Ethereum'un üzerinde bir ağ kuran ve böylece verilerin ve hesaplamaların çoğunu ana zincirin dışında tutarken Ethereum'un güvenliğinden tam olarak yararlanabilen Katman 2 protokolüdür. "Katman 2 protokolü" 2015 yılında durum kanallarından , 2017'de Plazma'ya ve son olarak 2019'da Toplamalara dönüştü. Toplamalar ilk ikisinden daha güçlüdür ancak aynı zamanda çok fazla zincir içi veri bant genişliği gerektirir. Neyse ki 2019 yılına gelindiğinde parçalama araştırması, "veri kullanılabilirliğini" geniş ölçekte doğrulama sorununu çözdü . Yani bu iki yol birleşiyor ve Ethereum'un bugünkü ölçeklendirme stratejisi olan Toplama merkezli bir yol haritamız var.

Ethereum L1'in 2023 yol haritası sürümü The Surge, güçlü bir merkezi olmayan temel katman olmaya odaklanırken L2, ekosistemin genişlemesine yardımcı olma görevini üstleniyor. Bu model toplumun her yerinde görülebilir. Örneğin, mahkeme sistemi (L1) ultra yüksek dava yönetimi verimliliği için değil, sözleşmelerin ve mülkiyet haklarının korunması için mevcuttur, girişimciler (L2) ise bu uğruna mevcut değildir. Vaka işlemede yüksek verimlilik. Temel katmanın üstüne insanları Mars'a götürün. Bu yıl, Ethereum'un toplama merkezli yol haritası önemli bir başarı elde etti: Ethereum L1 veri bant genişliği, EIP-4844 bloblarının kullanımıyla önemli ölçüde arttı ve birden fazla EVM toplaması artık birinci aşamada . Ayrıca parçalamanın heterojen ve çeşitlendirilmiş uygulamaları da gerçeğe dönüştü. Her L2, kendi iç kuralları ve mantığı olan bir "parça" olarak kullanılabilir. Ancak gördüğümüz gibi, bu rotaya gitmenin kendine özgü zorlukları da var. Bu nedenle mevcut misyonumuz, Toplama merkezli yol haritasını tamamlamak ve Ethereum L1'in sağlamlığını ve merkezi olmayan yapısını korurken bu sorunları çözmektir. The Surge'ın ana hedefleri:

Blockchain'in "İmkansız Üçgeni" 2017'de önerdiğim bir bakış açısıdır. Blockchain'in üç özelliği arasında bir çelişki olduğuna inanıyorum: merkeziyetsizlik (düşük maliyetli düğüm çalıştırma), ölçeklenebilirlik (işlem işleme) çok sayıda) ve güvenlik (bir saldırganın tek bir işlemin başarısız olmasına neden olması için tüm ağdaki düğümlerin çoğunluğunu tehlikeye atması gerekir).

İmkansız Üçgen'in bir teorem olmadığını ve ikilemi ortaya koyan yazının matematiksel bir kanıtla birlikte gelmediğini belirtmekte fayda var. Buluşsal bir matematiksel argüman sunar: Merkezi olmayan bir düğüm (tüketicinin dizüstü bilgisayarı gibi) saniyede N işlemi doğrulayabiliyorsa ve ikinci zincir başına k*N işlemi işleyen bir ağınız varsa, o zaman her bir işlem yalnızca 1/k düğümler tarafından görülür, bu da bir saldırganın kötü bir işlemi dışarı itmek için yalnızca birkaç düğümü yok etmesi gerektiği anlamına gelir, aksi takdirde düğümler çok güçlü hale gelir ve zincir merkezileşme özelliği kaybolur. O zamanki gönderi, İmkansız Üçlemi kırmanın imkansız olduğunu iddia etmeyi amaçlamıyordu; daha ziyade, ikilemi kırmanın zor olduğunu ve bir şekilde argümanın önerdiği çerçevenin dışına çıkmayı gerektirdiğini iddia etmek istedim. Yıllar boyunca, bazı yüksek performanslı zincirler, imkansız üçgen problemini temel mimari düzeyde herhangi bir iyileştirme yapmadan (genellikle düğümleri optimize etmek için yazılım mühendisliği tekniklerini kullanarak) çözebileceklerini sıklıkla iddia ettiler. Bu ifade genellikle yanıltıcıdır ve böyle bir zincirde bir düğümü çalıştırmak aslında Ethereum'dan çok daha zordur. Bu makale , durumun neden böyle olduğuna dair pek çok inceliği ele alırken aynı zamanda neden L1 istemci yazılım mühendisliğinin tek başına Ethereum'u ölçekleyemeyeceğini de açıklıyor. Ancak veri kullanılabilirliği örneklemesi ve SNARK'ların birleşimi bu ikilemi çözmektedir. Bu ikisini birleştirerek, müşteri belirli miktarda verinin mevcut olduğunu ve belirli sayıda hesaplama adımının doğru şekilde gerçekleştirildiğini doğrulayabilir, bu arada verilerin yalnızca küçük bir kısmını indirebilir ve çok daha küçük miktarda hesaplama çalıştırabilir. SNARK güvenilmezdir; veri kullanılabilirliği örneklemesi ise incelikli bir N-birkaç güven modeline sahiptir, ancak ölçeklenemeyen zincirlerin temel özelliğini korur; yani %51 saldırısı bile ağı zararlı bölge parçasını kabul etmeye zorlayamaz. İmkansız üçgeni çözmenin bir başka yolu da, veri kullanılabilirliğini gözlemleme sorumluluğunu teşvikle uyumlu bir şekilde kullanıcıya iten akıllı teknikler kullanan Plazma mimarisidir. Hesaplamayı yalnızca dolandırıcılık kanıtlarıyla ölçeklendirebildiğimiz 2017-2019'da, Plasma'nın güvenli olarak yapabilecekleri çok sınırlıydı ancak SNARK'ların yaygınlaştırılması, Plazma mimarisini Veri Kullanılabilirliği öncesine göre daha geniş bir kullanım senaryosu yelpazesinde daha uygulanabilir hale getirdi Daha fazla ilerlemenin örneklenmesi.

Dencun yükseltmesinin çevrimiçi hale geldiği 13 Mart 2024 itibarıyla, Ethereum'da her 12 saniyede bir yaklaşık 125 kB boyutunda üç "blob" bulunur; bu, her yuvanın yaklaşık 375 kB veri kullanılabilirliği bant genişliğine sahip olduğu anlamına gelir. İşlem verilerinin doğrudan zincirde yayınlandığını varsayarsak, ERC20'nin iletim hacmi yaklaşık 180 bayttır, dolayısıyla Ethereum'daki Toplamaların maksimum TPS'si: 375000/12/180 = 173,6 TPS. maksimum değer: yuva başına 30 milyon gaz / bayt başına 16 gaz = yuva başına 1,875 milyon bayt), bu da 607 TPS olur. PeerDAS için planımız blob sayımı hedefini 8-16'ya çıkarmak, bu da bize 463-926 TPS çağrı verisi sağlayacak. Bu Ethereum L1'e göre büyük bir gelişme ama yeterli değil. Daha yüksek ölçeklenebilirlik istiyoruz. Orta vadeli hedefimiz yuva başına 16 MB'tır ve Toplama veri sıkıştırmasındaki iyileştirmelerle birleştiğinde yaklaşık 58.000 TPS'ye ulaşacağız.

PeerDAS, "1D örneklemenin" nispeten basit bir uygulamasıdır. Ethereum'daki her blob, 253 bitlik asal sayılardan oluşan bir alan üzerinde 4096 derecelik bir polinomdur. Her bir paylaşım, toplam 8192 koordinattan alınan 16 bitişik koordinatın 16 tahmininden oluşan polinomun "paylaşımlarını" yayınlıyoruz. 8192 değerlendirmeden herhangi 4096 atama (şu anda önerilen parametreler kullanılarak: 128 olası örnekten herhangi 64'ü) blobu kurtarabilir.

PeerDAS, her istemcinin bir avuç alt ağı dinlemesini sağlayarak çalışır; burada i'inci alt ağ, herhangi bir blobun i'inci örneğini yayınlar ve bildiklerini küresel p2p ağındaki eşlere (farklı alt ağları dinleyen eşler) blob'lara sorarak öğrenir. gerektiğinde diğer alt ağlarda. Daha muhafazakar bir sürüm SubnetDAS olup, ek sorgulama eşleri katmanı olmadan yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, Proof of Stake'e katılan düğümlerin SubnetDAS kullanması ve diğer düğümlerin PeerDAS kullanmasıdır. Teorik olarak 1 boyutlu örneklemeyi önemli bir aralığa genişletebiliriz. Maksimum blob sayısını 256'ya çıkarırsak (yani hedef 128 olur), 16 MB hedefine ulaşabiliriz ve veri kullanılabilirliği örneklemesinin maliyeti yuva başına yalnızca 1 MB'tır (düğüm başına 16 örnek * 128 blob * örnek başına blob başına 512 bayt) ) veri bant genişliği yeterlidir. Ancak bu bizim toleransımız dahilinde değil. Bunu yapabiliriz ancak bu, bant genişliği kısıtlı istemcilerin örnek alamayacağı anlamına gelir. Blob sayısını azaltarak ve blob boyutunu artırarak optimizasyon yapabiliriz ancak bu, yeniden yapılandırma maliyetini artıracaktır. Bu nedenle bir adım daha ileri giderek 2D örnekleme yani yalnızca blob içinde değil, bloblar arasında da rastgele örnekleme yapmak istiyoruz. KZG'nin, aynı bilgilerle yeni "sanal bloblar" listesini yedekli olarak kodlayarak bir bloktaki bloblar kümesini "genişletme" vaadinin doğrusal doğasından yararlanıyoruz.

2D örnekleme; Kaynak: a16z kripto En önemlisi, taahhütlerin ölçeklendirilmesinin hesaplanması bloblara sahip olmayı gerektirmez, bu nedenle şema temelde dağıtılmış blok oluşturmaya yardımcı olur. Bloğu gerçekten oluşturan düğümün yalnızca blob KZG taahhüdüne sahip olması gerekir ve blobun kullanılabilirliğini doğrulamak için DAS'a güvenebilir. 1D DAS aynı zamanda doğası gereği dağıtılmış blok inşasına da elverişlidir.

En büyük öncelik PeerDAS'ın uygulanmasını ve tanıtımını tamamlamaktır. Güvenliği sağlamak için ağı dikkatle izleyip yazılımı geliştirirken PeerDAS üzerindeki blob sayısını kademeli olarak artırmamız gerekiyor. Bu arada PeerDAS'ı ve DAS'ın diğer sürümlerini ve bunların çatal seçimi kuralı güvenliği gibi konularla etkileşimini resmileştirmek için daha fazla akademik çalışma yapmayı umuyoruz. Gelecekte 2D DAS'ın ideal versiyonunu bulmak ve güvenlik özelliklerini kanıtlamak için daha fazla çalışma yapmamız gerekiyor. Ayrıca eninde sonunda KZG'den kuantum dirençli, güvenilir olmayan bir kurulum alternatifine geçmeyi umuyoruz. Şu anda hangi adayların dağıtılmış blok oluşturmaya uygun olduğunu bilmiyoruz. Son derece pahalı "kaba kuvvet" teknikleri kullanılsa bile, satırları ve sütunları yeniden oluşturmak için geçerlilik kanıtları oluşturmak amacıyla özyinelemeli STARK'ları kullanmak bile yeterli değildir, çünkü teknik olarak bir STARK'ın boyutu (STIR kullanarak) O(log(n) * log(log()'dur. n)) hash değeri, ancak gerçekte bir STARK neredeyse tüm blob kadar büyüktür. Uzun vadede en gerçekçi yolun şöyle olduğunu düşünüyorum:

Bu sorunları aşağıdaki şemaya göre değerlendirebiliriz:

Yürütmeyi doğrudan L1'de ölçeklendirmeye karar versek bile bu seçeneğin mevcut olduğunu unutmayın. Çünkü, eğer L1 çok fazla TPS işleyecekse, o zaman L1 blokları çok büyüyecektir ve istemcinin bunların doğru olduğunu doğrulamak için etkili bir yola ihtiyacı vardır, dolayısıyla L1'de Toplama kullanmak zorundayız (ZK-EVM ve DAS) aynı teknoloji.

Yürütmeyi doğrudan L1'de ölçeklendirmeye karar versek bile bu seçeneğin mevcut olduğunu unutmayın. Çünkü, eğer L1 çok fazla TPS işleyecekse, o zaman L1 blokları çok büyüyecektir ve istemcinin bunların doğru olduğunu doğrulamak için etkili bir yola ihtiyacı vardır, dolayısıyla L1'de Toplama kullanmak zorundayız (ZK-EVM ve DAS) aynı teknoloji.

Veri sıkıştırma uygulanırsa (aşağıya bakınız), 2D DAS'a olan ihtiyaç azalacak veya en azından gecikecektir; Plazma yaygın olarak kullanılabilir hale gelirse buna olan ihtiyaç daha da azalacaktır. DAS ayrıca dağıtılmış blok oluşturma protokolleri ve mekanizmalarına da zorluklar getirmektedir: DAS teorik olarak dağıtılmış yeniden düzenlemeye uygun olsa da pratikte liste önerilerinin ve bunların etrafındaki çatal seçim mekanizmasının dahil edilmesiyle birleştirilmesi gerekir.

Toplamadaki her işlem zincirde büyük miktarda veri alanı kaplar: ERC20 iletimi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirliği örneklemesinde bile Katman 2 protokollerinin ölçeklenebilirliği konusunda sınırlamalar olacaktır. Her yuva 16 MB olduğundan şunu elde edebiliriz: 16000000/12/180 = 7407 TPS Pay problemini çözmenin yanı sıra payda problemini de çözebilirsek, Toplamadaki her işlem zincirde daha az bayt kaplar. Ne olacak?

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

En basit kazanç sıfır bayt sıkıştırmadır: her uzun sıfır bayt dizisinin, sıfır bayt sayısını temsil eden iki bayt ile değiştirilmesi. Bir adım daha ileri gitmek için işlemlerin özel özelliklerinden yararlanıyoruz:

Geriye yapılması gereken esas olarak yukarıdaki planın fiilen uygulanmasıdır. Başlıca takaslar şunlardır:

Geriye yapılması gereken esas olarak yukarıdaki planın fiilen uygulanmasıdır. Başlıca takaslar şunlardır:

ERC-4337'nin benimsenmesi ve sonunda bazı bölümlerinin L2 EVM'ye dahil edilmesi, birleşik teknolojilerin dağıtımını önemli ölçüde hızlandırabilir. ERC-4337'nin parçalarının L1'e dahil edilmesi, L2'deki dağıtımını hızlandırabilir.

16 MB bloblar ve veri sıkıştırma teknolojisiyle bile 58.000 TPS, tüketici ödemelerini, merkezi olmayan sosyal alanları veya diğer yüksek bant genişliğine sahip alanları tamamen devralmak için yeterli olmayabilir. Bu, özellikle ölçeklenebilirlikten ödün verebilecek gizlilik sorunlarını dikkate almaya başladığımızda doğru olur. 3-8 kat azaltın. Yüksek trafikli, düşük değerli uygulamalar için geçerli seçeneklerden biri, verileri zincir dışında tutan ve ilginç bir güvenlik modeline sahip olan Validium'dur; yani operatörler kullanıcıların fonlarını çalamaz ancak ortadan kaybolabilir ve geçici olarak veya Tüm kullanıcı fonları kalıcı olarak dondurulur. . Ancak daha iyisini yapabiliriz.

Plazma, operatörlerin blokları zincir dışında yayınlamasını ve bu blokların Merkle köklerini zincire koymasını içeren bir ölçeklendirme çözümüdür (tüm bloğu zincire yerleştiren Rollup'tan farklı olarak). Her blok için operatör, her kullanıcıya, o kullanıcının varlıklarına ne olduğunu veya olmadığını kanıtlayan bir Merkle şubesi gönderir. Kullanıcılar Merkle çatalı sağlayarak varlıkları çekebilirler. Daha da önemlisi, bu dalın en son durumda köklenmesine gerek yoktur. Bu nedenle, veri kullanılabilirliği başarısız olsa bile kullanıcılar, mevcut en son durumu alarak varlığı kurtarabilirler. Bir kullanıcı geçersiz bir dal işlemi gerçekleştirirse (örneğin, başkalarına gönderilen bir varlığı geri çekmek veya operatörün kendisi yoktan bir varlık oluşturmak), zincir içi sorgulama mekanizması varlığın yasal mülkiyetine karar verebilir.

Plazma Nakit zinciri şeması Plazma'nın ilk sürümleri yalnızca ödeme kullanım durumlarını ele alıyordu ve daha fazla etkili bir şekilde tanıtılamıyordu. Ancak her kökün SNARK tarafından doğrulanmasını istersek Plazma daha güçlü hale gelir. Operatörlerin hile yapabileceği olası yolların çoğunu ortadan kaldırdığımız için her zorluk büyük ölçüde basitleştirilebilir. Ayrıca Plazma teknolojisini daha geniş varlık sınıflarına ölçeklendirmenin yeni yollarını da açıyoruz. Son olarak operatörün hile yapmadığı durumlarda kullanıcılar bir hafta süren sorgulama süresini beklemeye gerek kalmadan parayı hemen çekebilmektedir.

EVM plazma zinciri oluşturmanın bir yolu (tek yol değil): EVM tarafından yapılan denge değişikliklerini yansıtan ve tarihin farklı anlarında "aynı para biriminin" benzersiz eşlemesini tanımlayan paralel bir UTXO ağacı oluşturmak için ZK-SNARK'ı kullanın. Plazma yapısı daha sonra bu temel üzerine inşa edilir. Plazma sistemlerinin mükemmel olmasına gerek olmadığını unutmamak önemlidir. Varlıkların yalnızca bir alt kümesini koruyabilseniz bile, hiper ölçeklenebilir EVM'lerin durumunu büyük ölçüde iyileştirmiş olursunuz ve bu etkilidir. Diğer bir yapı türü ise Intmax gibi hibrit Plazma ve Toplamadır. Bu yapılar her kullanıcı için çok küçük miktarlarda veriyi (örneğin 5 bayt) zincire yerleştirir, böylece Plazma ve Toplama arasındaki özelliklere ulaşırsınız: Intmax'ta son derece yüksek ölçeklenebilirlik ve gizlilik elde edersiniz, ancak 16 MB'lık bir dünyada bile teorik kapasite sınırı vardır yalnızca 16.000.000 / 12 / 5 = 266.667 TPS civarındadır.

Geriye kalan asıl görev Plazma sistemini üretime geçirmektir. Yukarıda belirtildiği gibi, Plazma ve validium ikili zıtlıklar değildir: herhangi bir validium, çıkış mekanizmasına Plazma özellikleri ekleyerek güvenlik performansını en azından bir dereceye kadar artırabilir. Araştırma çabaları, EVM için en uygun özelliklerin (güven gereksinimleri, en kötü durum L1 gaz maliyeti ve DoS güvenlik açığı açısından) yanı sıra diğer uygulamaya özel yapılar elde edilmesine odaklanmaktadır. Ek olarak Plazma, Rollup'a göre daha yüksek kavramsal karmaşıklığa sahiptir ve bunun doğrudan araştırma yoluyla ele alınması ve daha iyi bir genel çerçeve oluşturulması gerekir. Plazma tasarımlarını kullanmanın ana maliyeti, bunların operatöre daha bağımlı olması ve evrensel olarak uygulanmasının daha zor olmasıdır; ancak Plazma ve Rollup'ın hibrit tasarımları genellikle bu zayıflığı ortadan kaldırır.

Plazma çözümü ne kadar etkili olursa, L1'in üzerinde yüksek performanslı veri kullanılabilirliği yeteneklerine sahip olma yönündeki baskı da o kadar az olur. Faaliyetleri L2'ye kaydırmak aynı zamanda L1 üzerindeki MEV basıncını da azaltır.

Günümüzde çoğu toplama aslında güvenilmez değildir; güvenlik komitesi sistemin davranışını (iyimser veya geçerli) kanıtlama yeteneğine sahiptir. Bazı durumlarda ispat sistemi mevcut bile değildir, olsa bile sadece “tavsiye” işlevi görmektedir. Şu anda en ileri gidenler, Yakıt gibi güvenilmez uygulamalara yönelik bazı toplamalardır; ikincisi, bu makalenin yazıldığı an itibariyle, Optimism ve Arbitrum, her iki EVM toplaması da kısmi güvensizliğin dönüm noktasına ulaşmıştır; , "1. aşama" dediğimiz şey. Rollup'ın güvensizliği daha fazla uygulamamasının nedeni, koddaki hatalarla ilgili endişelerdir. Güvenilir bir yükseltmeye ihtiyacımız var, bu yüzden bu konuyu doğrudan ele almamız gerekiyor.

Öncelikle başlangıçta tanıtılan "aşama" sistemini gözden geçirelim. Genel durum şu şekildedir:

Hedefimiz 2. etaba ulaşmak. Asıl zorluk, sistemin gerçekten güvenilir olduğuna dair yeterli güveni kazanmaktır. Bunu yapmanın iki ana yolu vardır:

İyimser kanıt sistemini, geçerlilik kanıt sistemini ve güvenlik komitesini birleştiren çoklu doğrulayıcı stil grafiği

Resmi doğrulama için hâlâ yapacak çok işimiz var. EVM için tüm SNARK doğrulayıcının resmi olarak doğrulanmış bir versiyonunu oluşturmamız gerekiyor. Bu çok karmaşık bir proje, ancak biz bunu uygulamaya başladık ve görevi büyük ölçüde basitleştiren küçük bir numara var: Minimal bir sanal makine için ( RISC-V veya Kahire gibi) resmi olarak doğrulanmış bir SNARK doğrulayıcı oluşturabiliriz, ve ardından bu minimal sanal makinede EVM'nin bir uygulamasını yazın (ve diğer EVM özelliklerine eşdeğerliğini resmi olarak kanıtlayın). Çoklu doğrulayıcılar için geri kalan odak noktası iki bölümden oluşur. İlk olarak, en az iki farklı kanıt sistemine, her birinin makul ölçüde güvenli olduğuna ve aynı zamanda başarısız olmaları durumunda başarısızlığın nedenlerinin farklı ve ilgisiz olduğuna (böylece başarısızlık meydana gelmeyeceğine) inanacak kadar güven duymamız gerekir. aynı anda). İkincisi, birleştirme kanıt sisteminin temelindeki mantık açısından son derece yüksek garantilere ihtiyacımız var. Bu çok daha küçük bir kod parçasıdır ve onu çok küçük hale getirmenin yolları vardır (fonları çeşitli kanıt sistemlerinin sözleşmelerini temsil eden imzalayanlarla birlikte Güvenli çoklu imza sözleşmesinde saklamak yeterlidir), ancak bu, Yüksek on-on'un maliyetine neden olur. zincir gazı maliyetleri. Verimlilik ve güvenlik arasında bir denge bulmamız gerekiyor.

Faaliyetleri L2'ye kaydırmak L1 üzerindeki MEV basıncını azaltabilir.

Şu anda, L2 ekosisteminin karşı karşıya olduğu en büyük zorluk, kullanıcıların L2 genelinde birlikte çalışmasının zor olması ve en basit yöntemlerin genellikle merkezi zincirler arası köprüler, RPC istemcileri vb. dahil olmak üzere güven varsayımlarını yeniden uygulamaya koymasıdır. "L2'nin Ethereum'un bir parçası olması" fikrini ciddiye alırsak, L2 ekosistemini kullanmayı birleşik Ethereum ekosistemini kullanıyormuş gibi hissettirmemiz gerekir.

Son derece zayıf çapraz L2 kullanıcı deneyimine bir örnek (Yanlış zincir seçimi nedeniyle kişisel olarak 100 $ kaybettim): Bu Polymarket'in hatası olmasa da, çapraz L2 birlikte çalışabilirliği cüzdanın ve Ethereum Standard (ERC) topluluğunun sorumluluğunda olmalıdır. İyi işleyen bir Ethereum ekosisteminde, L1'den L2'ye veya bir L2'den diğerine token göndermek, aynı L1 içinde token göndermek gibi hissettirmelidir.

L2 genelinde birlikte çalışabilirliği geliştirmenin birçok yolu vardır. Genel olarak konuşursak, teoride Toplama merkezli Ethereum'un parçalama gerçekleştiren L1 ile aynı şey olduğunun farkına varın ve ardından mevcut Ethereum L2'nin pratikte bu idealin ne kadar gerisinde kaldığını gözlemleyin. İşte bazı örnekler:

Hafif istemciler Ethereum başlık zincirini nasıl günceller: Başlık zincirine sahip olduğunuzda, herhangi bir durum nesnesini doğrulamak için Merkle kanıtlarını kullanabilirsiniz. Doğru L1 durum nesnesine sahip olduğunuzda, L2'deki herhangi bir durum nesnesini doğrulamak için Merkle kanıtlarını (ve ön onayı kontrol etmek istiyorsanız imzaları) kullanabilirsiniz. Helios ilkini halihazırda uyguluyor ve ikincisine doğru ilerlemek bir standardizasyon zorluğudur. Anahtar Depolama Cüzdanları: Bugün, bir akıllı sözleşme cüzdanını kontrol eden anahtarı güncellemek istiyorsanız, onu o cüzdanın bulunduğu tüm N zincirlerinde güncellemelisiniz. Anahtar depolama cüzdanları, anahtarların tek bir yerde (L1'de veya muhtemelen daha sonra L2'de) bulunmasına ve daha sonra cüzdanın bir kopyasına sahip herhangi bir L2'den okunmasına olanak tanıyan bir teknolojidir. Bu, güncellemenin yalnızca bir kez yapılması gerektiği anlamına gelir. Verimliliği artırmak için, anahtar depolama cüzdanları L2'nin L1'i ucuza okumak için standartlaştırılmış bir yola sahip olmasını gerektirir; bunun için iki öneri vardır: L1SLOAD ve REMOTESTATICCALL .

Anahtar depolama cüzdanının çalışma prensibinin şematik diyagramı Daha radikal bir "Paylaşılan Token Köprüsü" çözümü: Tüm L2'nin geçerlilik kanıtı Toplama olduğu ve her yuvanın Ethereum'a gönderileceği, ardından varlıkların " Aktarılıyor bir L2'den diğerine geçiş de para çekme ve yatırma gerektirir ve büyük miktarda L1 gazının ödenmesi gerekir. Bu sorunu çözmenin bir yolu, tek işlevi L2'nin kaç tokena sahip olduğu dengesini korumak ve bu dengelerin herhangi bir L2 tarafından başlatılan bir dizi çapraz L2 gönderme işlemi aracılığıyla ölçekte güncellenmesine izin vermek olan paylaşılan bir minimum toplama oluşturmaktır. bir L2. Bu, transfer başına L1 gazı ödemek zorunda kalmadan ve likidite sağlayıcı tabanlı teknolojileri (ERC-7683 gibi) kullanmadan çapraz L2 transferlerine olanak tanıyacaktır. Eşzamanlı şekillendirilebilirlik: Belirli bir L2 ile L1 arasında veya birden fazla L2 arasında eşzamanlı çağrılara izin verir. Bu, DeFi protokollerinin finansal verimliliğinin artırılmasına yardımcı olur. İlki herhangi bir L2 arası koordinasyon olmadan yapılabilir; ikincisi ise ortak sıralamayı gerektirir. Tabanlı Toplamalar tüm bu teknolojilerle otomatik olarak çalışır.

Yukarıdaki örneklerin çoğu, ne zaman standartlaştırılacağı ve hangi katmanın standartlaştırılacağı ikilemiyle karşı karşıyadır. Eğer çok erken standartlaşırsanız, kalitesiz çözümleri sağlamlaştırma riskiyle karşı karşıya kalırsınız. Eğer çok geç standartlaştırırsanız gereksiz parçalanma yaratma riskiyle karşı karşıya kalırsınız. Bazı durumlarda, zayıf ancak uygulaması kolay kısa vadeli çözümler ve "nihayetinde doğru" olan ancak uygulanması yıllar süren uzun vadeli çözümler vardır. Bu bölümün benzersiz bir özelliği, bu görevlerin sadece teknik sorunlar olmaması, aynı zamanda (belki de öncelikli olarak!) sosyal sorunlar olmasıdır. L2, cüzdan ve L1'in işbirliğini gerektirirler. Bu sorunu başarıyla çözüp çözemeyeceğimiz, topluluk olarak birlikte çalışma yeteneğimizi test edecek.

Bu tekliflerin çoğu "üst düzey" yapılardır ve bu nedenle L1 üzerinde çok az etkisi vardır. MEV üzerinde büyük etkisi olan paylaşılan sipariş bir istisnadır.

L2'nin ölçeklenebilirliği ve başarı oranı yüksekse ancak L1 hala yalnızca çok az sayıda işlemi gerçekleştirebiliyorsa Ethereum bir dizi riskle karşı karşıya kalabilir:

Bu nedenlerden dolayı L1'in kendisini ölçeklendirmeye devam etmek ve artan sayıda kullanım senaryosunu desteklemeye devam etmesini sağlamak son derece değerlidir.

En basit ölçeklendirme yöntemi gaz limitini arttırmaktır. Ancak bunu yapmak L1'i merkezileştirme riskini taşır ve böylece Ethereum'un L1 gücünün bir başka önemli özelliği olan sağlam bir temel katman olarak güvenilirliğini zayıflatır. Gaz üst sınırının ne kadar artırılmasının sürdürülebilir olduğu ve daha büyük blokların doğrulanmasını kolaylaştırmak için uygulanan diğer teknolojilere (ör. geçmişin sona ermesi, vatansızlık, L1 EVM geçerlilik kanıtı) bağlı olarak bunun nasıl değişeceği konusunda devam eden bir tartışma var. Sürekli iyileştirilmesi gereken bir diğer önemli husus, bugün beş yıl öncesine göre çok daha fazla optimize edilen Ethereum istemci yazılımının verimliliğidir. Etkili bir L1 gaz limiti artırma stratejisi, bu doğrulama tekniklerinin hızlandırılmasını içerecektir. Başka bir ölçeklendirme stratejisi, ağın merkezi olmamasından veya güvenlik özelliklerinden ödün vermeden, onu daha ucuz hale getirecek belirli yeteneklerin ve hesaplama türlerinin tanımlanmasını içerir. Bunun örnekleri şunları içerir:

Bu iyileştirmeler Splurge ile ilgili gelecekteki bir makalede ayrıntılı olarak tartışılacaktır. Son olarak, üçüncü strateji yerel toplama veya "kutsal toplamalardır": esas olarak EVM'nin paralel çalışan birçok kopyasını oluşturmak, toplamanın sağlayabileceği şeye eşdeğer, ancak protokole daha doğal olarak entegre edilmiş bir modelle sonuçlanır.

Bu iyileştirmeler Splurge ile ilgili gelecekteki bir makalede ayrıntılı olarak tartışılacaktır. Son olarak, üçüncü strateji yerel toplama veya "kutsal toplamalardır": esas olarak EVM'nin paralel çalışan birçok kopyasını oluşturmak, toplamanın sağlayabileceği şeye eşdeğer, ancak protokole daha doğal olarak entegre edilmiş bir modelle sonuçlanır.

L1'i genişletmek için ayrı ayrı veya aynı anda gerçekleştirilebilecek üç strateji vardır:

Bu teknolojilerin her birinin farklı olduğunu ve her birinin kendine göre artıları ve eksileri olduğunu belirtmekte fayda var. Örneğin, yerel Toplama, normal Toplama ile aynı şekillendirilebilirlik zayıflıklarının çoğuna sahiptir. Gas limitinin yükseltilmesi, L1'in doğrulanmasını kolaylaştırarak elde edilebilecek diğer faydaları da etkiler; örneğin, doğrulama düğümlerini çalıştıran kullanıcıların oranının artması ve tekli stakerların artması gibi. EVM'deki belirli bir işlemin maliyetini azaltmak (nasıl gerçekleştirildiğine bağlı olarak), EVM'nin genel karmaşıklığını artırır. L1 ölçeklendirme yol haritalarının yanıtlaması gereken büyük soru şudur: Neler L1'e ve neler L2'ye ait olmalıdır? Açıkçası her şeyi L1'e koymak saçma. Saniyede yüz binlerce işleme kadar potansiyel kullanım durumları, L1'i tamamen doğrulanamaz hale getirecektir (yerel Toplama yoluna gitmediğimiz sürece). Gas limitini 10 kat artırıp Ethereum L1'in merkeziyetsizliğini ciddi şekilde kırıp aktivitenin sadece %90'ını L2'de gerçekleştirdiğimiz bir durum yaratmamamızı sağlamak için gerçekten bazı yönergelere ihtiyacımız var. %99 yerine sonuçlar, Ethereum L1'in çoğu özelliğini geri dönülemez şekilde kaybetmesi dışında neredeyse aynı görünüyor.

Bazı insanlar L1 ve L2 arasında bir "iş bölümü" olduğuna inanıyor Kaynak: @0xBreadguy;

Daha fazla kullanıcının L1'i kullanmasını sağlamak, yalnızca ölçeğin değil, aynı zamanda L1'in diğer yönlerinin de gelişeceği anlamına gelir. Bu, daha fazla MEV'nin L1'de kalacağı anlamına gelir (yalnızca L2 sorunu olmaktan ziyade), dolayısıyla MEV'yi açıkça ele alma ihtiyacı daha da acil olacaktır. Bu, L1 hızlı slot süresinin değerini büyük ölçüde artıracaktır. Ve bu aynı zamanda büyük ölçüde L1 doğrulamasının (Verge) sorunsuz ilerleyip ilerlemediğine de bağlıdır. İlgili okuma: Vitalik'in yeni çalışması: Ethereum'un The Merge sonrası yol haritasının potansiyel teknik rotaları