Ethereum'un yol haritasında başlangıçta iki ölçeklendirme stratejisi vardı: parçalama ve Layer2 protokolleri. Araştırmaların derinleşmesiyle, bu iki yol bir araya gelerek Rollup merkezli bir yol haritası oluşturdu, bu hala Ethereum'un mevcut genişleme stratejisidir.
Rollup merkezli yol haritası, basit bir iş bölümü öneriyor: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olma üzerine odaklanırken, L2 ekosistemi genişletme görevini üstleniyor. Bu model toplumda oldukça yaygındır: Mahkeme sistemi ( L1 )'in varlığı, verimlilik peşinde koşmak için değil, sözleşmeleri ve mülkiyet haklarını korumak içindir; girişimciler ( L2 ) ise bu sağlam temel üzerinde inşa ederek insan gelişimini ileriye taşımaktadır.
Bu yıl, Rollup merkezli yol haritasında önemli ilerlemeler kaydedildi: EIP-4844 bloblarının piyasaya sürülmesi, Ethereum L1'in veri bant genişliğini önemli ölçüde artırdı, birden fazla EVM Rollup ilk aşamaya girdi. Her L2, kendi kuralları ve mantığına sahip bir "parça" olarak var olmaktadır ve parça uygulamalarının çeşitliliği artık bir gerçek haline gelmiştir. Ancak bu yol bazı benzersiz zorluklarla da karşı karşıya. Şu anki görevimiz, Rollup merkezli yol haritasını tamamlamak, bu sorunları çözmek ve aynı zamanda Ethereum L1'e özgü sağlamlık ve merkeziyetsizlik özelliklerini korumaktır.
The Surge: Ana Hedefler
Gelecekte Ethereum, L2 aracılığıyla 100.000'in üzerinde TPS'ye ulaşabilir;
L1'in merkeziyetsizliğini ve dayanıklılığını korumak;
En azından bazı L2'ler, Ethereum'un temel özelliklerini ( güvenilmez, açık, sansüre dayanıklı ) tamamen miras alır;
Ethereum, 34 farklı blok zinciri değil, tek bir ekosistem gibi hissettirmelidir.
Ölçeklenebilirlik Üçgen Paradoksu
Ölçeklenebilirlik üçgeni paradoksu, blok zincirinin merkeziyetsizliği, ölçeklenebilirliği ve güvenliği arasındaki çelişkiyi belirtir. Bu bir teorem değil, bir sezgisel görüştür. Yıllar boyunca, bazı yüksek performanslı zincirler üçlü paradoksu çözdüğünü iddia etti, ancak bu genellikle yanıltıcıdır.
Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten üçgen paradoksunu çözüyor: Bu, istemcilerin yalnızca az miktarda veri indirip çok az 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ğrulamasına olanak tanır.
Üçlü zorluk sorununu çözmenin bir diğer yolu Plasma mimarisidir; bu, kullanıcıların veri kullanılabilirliğini izlemekle ilgili sorumluluğu teşvik uyumlu bir şekilde üstlenmelerini sağlar. SNARK'ların yaygınlaşmasıyla birlikte, Plasma mimarisi daha geniş kullanım senaryoları için daha uygulanabilir hale gelmiştir.
Veri Erişilebilirliği Örneklemesi Üzerine Daha Fazla Gelişme
Hangi sorunu çözmeye çalışıyoruz?
2024'ün 13 Martında Dencun yükseltmesi çevrimiçi olduktan sonra, Ethereum'un her 12 saniyede bir slotunda 3 adet yaklaşık 125 kB blob olacak veya her slotun veri kullanılabilir bant genişliği yaklaşık 375 kB olacaktır. İşlem verilerinin doğrudan zincir üzerinde yayımlandığını varsayarsak, ERC20 transferi yaklaşık 180 bayt olduğundan, Ethereum'daki Rollup'ın maksimum TPS'si 173.6 TPS'dir.
Ethereum'un calldata'sı eklendiğinde, 607 TPS olur. PeerDAS kullanıldığında, blob sayısı 8-16'ya çıkabilir, bu da calldata'ya 463-926 TPS sağlayacaktır.
Bu, Ethereum L1 için büyük bir geliştirme, ancak yeterli değil. 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"in nispeten basit bir uygulamasıdır. Ethereum'da, her blob 253 bit asal alanında 4096. dereceden bir polinomdur. Polinomun paylarını yayarız, burada her pay toplam 8192 koordinattan komşu olan 16 koordinatın 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden herhangi 4096'sı blob'u geri yüklemek için kullanılabilir.
PeerDAS'ın çalışma prensibi, her bir istemcinin az miktarda alt ağı dinlemesini sağlamaktır; burada i. alt ağ, herhangi bir blob'un i. örneğini yayar ve ihtiyaç duyduğu diğer alt ağlardaki blob'lar için küresel p2p ağındaki eşlerden talep eder. Daha muhafazakar bir versiyon olan SubnetDAS ise, ek bir eş katmanı sorgulaması olmaksızın yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, staking'e katılan düğümlerin SubnetDAS kullanmasını, diğer düğümlerin 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 sayısını maksimum 256'ya çıkarırsak, 16MB hedefine ulaşabiliriz ve veri kullanılabilirliği örneklemesinde her düğümün her slot için yalnızca 1 MB veri bant genişliğine ihtiyacı vardır. Bu, bizim tolerans aralığımızda zar zor kalmaktadır: Bu mümkündür, ancak bu durum bant genişliği kısıtlı istemcilerin örnekleme yapamayacağı anlamına gelir. Blob sayısını azaltıp blob boyutunu artırarak optimizasyon yapabiliriz, ancak bu yeniden inşa maliyetlerini daha yüksek hale getirecektir.
Bu nedenle, nihayet daha ileri gitmek ve 2D örnekleme yapmak istiyoruz, bu sadece blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmaktadır. KZG taahhüdünün lineer özelliklerinden yararlanarak, bir bloktaki blob kümesini yeni sanal blob seti ile genişletiyoruz; bu sanal bloblar aynı bilgiyi fazladan kodlamaktadır.
Son derece önemlidir ki, taahhütlerin genişletilmesi için blob'a ihtiyaç yoktur, bu nedenle bu çözüm temelde dağıtık blok inşa etmeye dosttur. Gerçekten blok inşa eden düğümler yalnızca blob KZG taahhüdüne sahip olmalıdır ve veri kullanılabilirliği örneklemesi (DAS) üzerinden veri bloklarının kullanılabilirliğini doğrulamak için güvenebilirler. Bir boyutlu veri kullanılabilirliği örneklemesi (1D DAS) esasen dağıtık blok inşasına dosttur.
Ne yapmamız gerekiyor? Hangi dengelemeler var?
Sonraki aşama, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Ardından, PeerDAS üzerindeki blob sayısını sürekli olarak artırmak ve güvenliği sağlamak için ağı dikkatle gözlemlemek ve yazılımı geliştirmek, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümlerinin, fork seçim kuralları güvenliği gibi konularla etkileşimlerini standartlaştırmak 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 gerekecek. Ayrıca, KZG'den güvenilir bir ayar gerektirmeyen ve kuantum güvenli bir alternatif çözüme geçmeyi umuyoruz. Şu anda, dağıtık blok inşasına dost olan hangi aday çözümlerin mevcut olduğunu henüz net olarak bilmiyoruz.
Uzun vadeli gerçek yolun şöyle olduğunu düşünüyorum:
İdeal 2D DAS'ı uygulamak;
1D DAS kullanmaya devam edin, basitlik ve dayanıklılık için daha düşük veri üst sınırını kabul ederek örnekleme bant genişliği verimliliğinden feragat edin.
DA'dan vazgeçip, Plasma'yı ana Layer2 mimarimiz olarak tamamen kabul ediyoruz.
Lütfen dikkat edin, eğer L1 katmanında doğrudan genişlemeye karar verirsek, bu seçenek de mevcuttur. Bunun nedeni, eğer L1 katmanı yüksek miktarda TPS işlemesi gerekiyorsa, L1 bloklarının çok büyük hale gelmesidir. İstemcilerin bu blokların doğruluğunu doğrulamak için verimli bir yönteme ihtiyaç duyacaklardır, bu nedenle L1 katmanında Rollup( ile ZK-EVM ve DAS) ile aynı teknolojileri kullanmak zorunda kalacağız.
Yol haritasının diğer bölümleriyle nasıl etkileşimde bulunulur?
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ırsa, talep daha da azalacaktır. DAS, dağıtık blok inşa protokolleri ve mekanizmalarına da zorluklar getirmektedir: teorik olarak DAS, dağıtık yeniden inşaya 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'taki her bir işlem, büyük miktarda zincir üzerindeki veri alanını kaplar: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirliği örneklemesi olsa bile, bu, Layer protokolünün ölçeklenebilirliğini sınırlar. Her slot 16 MB, elde ettiğimiz:
16000000 / 12 / 180 = 7407 TPS
Eğer yalnızca payın sorununu değil, aynı zamanda paydanın sorununu da çözebilirsek ve her Rollup'taki işlemlerin zincirde daha az bayt kaplamasını sağlayabilirsek, o zaman ne olur?
Bu nedir, nasıl çalışır?
Sıfır bayt sıkıştırma sırası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ş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ğrulama hesaplama maliyeti yüksek olduğu için BLS imzasının kullanılması düşünülmemektedir. Ancak L2 gibi veri kıtlığı olan bir ortamda, 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 sunmaktadır.
Adresleri pointer ile değiştirme: Eğer daha önce belirli bir adres kullanmışsak, 20 baytlık adresi, geçmişteki bir konuma işaret eden 4 baytlık bir pointer ile değiştirebiliriz.
Özelleştirilmiş işlemler değerinin serileştirilmesi: Çoğu işlem değeri az sayıda basamağa sahiptir; örneğin, 0.25 ETH 250,000,000,000,000,000 wei olarak gösterilir. Maksimum temel işlem ücreti ve öncelik ücreti de benzer şekilde. Bu nedenle, çoğu para birimi değerini göstermek için özelleştirilmiş ondalık kayan nokta formatını kullanabiliriz.
ne yapılması gerekiyor, hangi dengeler var?
Sonraki adım, yukarıda belirtilen planın gerçeklenmesini sağlamaktır. Ana ticaretler şunlardır:
BLS imzasına geçmek büyük çaba gerektirir ve güvenliği artırabilecek güvenilir donanım yongalarıyla uyumluluğu azaltır. Bunun yerine diğer imza şemalarının ZK-SNARK paketleri kullanılabilir.
Dinamik sıkıştırma (. Örneğin, adres ) yerine işaretçiler kullanmak istemci kodunu karmaşık hale getirecektir.
Durum farklarını zincire yayınlamak yerine işlem yapmak, denetlenebilirliği azaltacak ve birçok yazılım ( örneğin blok gezgini ) çalışamaz hale getirecektir.
Harita üzerindeki diğer bölümlerle nasıl etkileşim kurabilirim?
ERC-4337'yi benimseyerek ve nihayetinde bazı içeriklerini L2 EVM'ye entegre ederek, agregasyon teknolojisinin dağıtımını önemli ölçüde hızlandırmak mümkündür. ERC-4337'nin bazı içeriklerini L1'de tutmak, L2'deki dağıtımını hızlandırabilir.
Genelleşmiş Plasma
Hangi sorunu çözmeye çalışıyoruz?
16 MB'lık blob ve veri sıkıştırması kullanılsa bile, 58.000 TPS tüketici ödemeleri, merkeziyetsiz sosyal ağlar veya diğer yüksek bant genişliği alanlarının ihtiyaçlarını tamamen karşılamak için yeterli olmayabilir; özellikle de gizlilik faktörlerini düşünmeye başladığımızda, bu ölçeklenebilirliği 3-8 kat azaltabilir. Yüksek işlem hacmine sahip, düşük değerli uygulama senaryoları için şu anda
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Ethereum The Surge: 100,000 TPS ölçekleme hedefi ve teknik ilerlemeler
Ethereum'ın Olası Geleceği: The Surge
Ethereum'un yol haritasında başlangıçta iki ölçeklendirme stratejisi vardı: parçalama ve Layer2 protokolleri. Araştırmaların derinleşmesiyle, bu iki yol bir araya gelerek Rollup merkezli bir yol haritası oluşturdu, bu hala Ethereum'un mevcut genişleme stratejisidir.
Rollup merkezli yol haritası, basit bir iş bölümü öneriyor: Ethereum L1, güçlü ve merkeziyetsiz bir temel katman olma üzerine odaklanırken, L2 ekosistemi genişletme görevini üstleniyor. Bu model toplumda oldukça yaygındır: Mahkeme sistemi ( L1 )'in varlığı, verimlilik peşinde koşmak için değil, sözleşmeleri ve mülkiyet haklarını korumak içindir; girişimciler ( L2 ) ise bu sağlam temel üzerinde inşa ederek insan gelişimini ileriye taşımaktadır.
Bu yıl, Rollup merkezli yol haritasında önemli ilerlemeler kaydedildi: EIP-4844 bloblarının piyasaya sürülmesi, Ethereum L1'in veri bant genişliğini önemli ölçüde artırdı, birden fazla EVM Rollup ilk aşamaya girdi. Her L2, kendi kuralları ve mantığına sahip bir "parça" olarak var olmaktadır ve parça uygulamalarının çeşitliliği artık bir gerçek haline gelmiştir. Ancak bu yol bazı benzersiz zorluklarla da karşı karşıya. Şu anki görevimiz, Rollup merkezli yol haritasını tamamlamak, bu sorunları çözmek ve aynı zamanda Ethereum L1'e özgü sağlamlık ve merkeziyetsizlik özelliklerini korumaktır.
The Surge: Ana Hedefler
Ölçeklenebilirlik Üçgen Paradoksu
Ölçeklenebilirlik üçgeni paradoksu, blok zincirinin merkeziyetsizliği, ölçeklenebilirliği ve güvenliği arasındaki çelişkiyi belirtir. Bu bir teorem değil, bir sezgisel görüştür. Yıllar boyunca, bazı yüksek performanslı zincirler üçlü paradoksu çözdüğünü iddia etti, ancak bu genellikle yanıltıcıdır.
Ancak, veri kullanılabilirliği örneklemesi ile SNARK'ların birleşimi gerçekten üçgen paradoksunu çözüyor: Bu, istemcilerin yalnızca az miktarda veri indirip çok az 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ğrulamasına olanak tanır.
Üçlü zorluk sorununu çözmenin bir diğer yolu Plasma mimarisidir; bu, kullanıcıların veri kullanılabilirliğini izlemekle ilgili sorumluluğu teşvik uyumlu bir şekilde üstlenmelerini sağlar. SNARK'ların yaygınlaşmasıyla birlikte, Plasma mimarisi daha geniş kullanım senaryoları için daha uygulanabilir hale gelmiştir.
Veri Erişilebilirliği Örneklemesi Üzerine Daha Fazla Gelişme
Hangi sorunu çözmeye çalışıyoruz?
2024'ün 13 Martında Dencun yükseltmesi çevrimiçi olduktan sonra, Ethereum'un her 12 saniyede bir slotunda 3 adet yaklaşık 125 kB blob olacak veya her slotun veri kullanılabilir bant genişliği yaklaşık 375 kB olacaktır. İşlem verilerinin doğrudan zincir üzerinde yayımlandığını varsayarsak, ERC20 transferi yaklaşık 180 bayt olduğundan, Ethereum'daki Rollup'ın maksimum TPS'si 173.6 TPS'dir.
Ethereum'un calldata'sı eklendiğinde, 607 TPS olur. PeerDAS kullanıldığında, blob sayısı 8-16'ya çıkabilir, bu da calldata'ya 463-926 TPS sağlayacaktır.
Bu, Ethereum L1 için büyük bir geliştirme, ancak yeterli değil. 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"in nispeten basit bir uygulamasıdır. Ethereum'da, her blob 253 bit asal alanında 4096. dereceden bir polinomdur. Polinomun paylarını yayarız, burada her pay toplam 8192 koordinattan komşu olan 16 koordinatın 16 değerlendirme değerini içerir. Bu 8192 değerlendirme değerinden herhangi 4096'sı blob'u geri yüklemek için kullanılabilir.
PeerDAS'ın çalışma prensibi, her bir istemcinin az miktarda alt ağı dinlemesini sağlamaktır; burada i. alt ağ, herhangi bir blob'un i. örneğini yayar ve ihtiyaç duyduğu diğer alt ağlardaki blob'lar için küresel p2p ağındaki eşlerden talep eder. Daha muhafazakar bir versiyon olan SubnetDAS ise, ek bir eş katmanı sorgulaması olmaksızın yalnızca alt ağ mekanizmasını kullanır. Mevcut öneri, staking'e katılan düğümlerin SubnetDAS kullanmasını, diğer düğümlerin 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 sayısını maksimum 256'ya çıkarırsak, 16MB hedefine ulaşabiliriz ve veri kullanılabilirliği örneklemesinde her düğümün her slot için yalnızca 1 MB veri bant genişliğine ihtiyacı vardır. Bu, bizim tolerans aralığımızda zar zor kalmaktadır: Bu mümkündür, ancak bu durum bant genişliği kısıtlı istemcilerin örnekleme yapamayacağı anlamına gelir. Blob sayısını azaltıp blob boyutunu artırarak optimizasyon yapabiliriz, ancak bu yeniden inşa maliyetlerini daha yüksek hale getirecektir.
Bu nedenle, nihayet daha ileri gitmek ve 2D örnekleme yapmak istiyoruz, bu sadece blob içinde değil, aynı zamanda bloblar arasında rastgele örnekleme yapmaktadır. KZG taahhüdünün lineer özelliklerinden yararlanarak, bir bloktaki blob kümesini yeni sanal blob seti ile genişletiyoruz; bu sanal bloblar aynı bilgiyi fazladan kodlamaktadır.
Son derece önemlidir ki, taahhütlerin genişletilmesi için blob'a ihtiyaç yoktur, bu nedenle bu çözüm temelde dağıtık blok inşa etmeye dosttur. Gerçekten blok inşa eden düğümler yalnızca blob KZG taahhüdüne sahip olmalıdır ve veri kullanılabilirliği örneklemesi (DAS) üzerinden veri bloklarının kullanılabilirliğini doğrulamak için güvenebilirler. Bir boyutlu veri kullanılabilirliği örneklemesi (1D DAS) esasen dağıtık blok inşasına dosttur.
Ne yapmamız gerekiyor? Hangi dengelemeler var?
Sonraki aşama, PeerDAS'ın uygulanması ve piyasaya sürülmesidir. Ardından, PeerDAS üzerindeki blob sayısını sürekli olarak artırmak ve güvenliği sağlamak için ağı dikkatle gözlemlemek ve yazılımı geliştirmek, kademeli bir süreçtir. Aynı zamanda, PeerDAS ve diğer DAS sürümlerinin, fork seçim kuralları güvenliği gibi konularla etkileşimlerini standartlaştırmak 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 gerekecek. Ayrıca, KZG'den güvenilir bir ayar gerektirmeyen ve kuantum güvenli bir alternatif çözüme geçmeyi umuyoruz. Şu anda, dağıtık blok inşasına dost olan hangi aday çözümlerin mevcut olduğunu henüz net olarak bilmiyoruz.
Uzun vadeli gerçek yolun şöyle olduğunu düşünüyorum:
Lütfen dikkat edin, eğer L1 katmanında doğrudan genişlemeye karar verirsek, bu seçenek de mevcuttur. Bunun nedeni, eğer L1 katmanı yüksek miktarda TPS işlemesi gerekiyorsa, L1 bloklarının çok büyük hale gelmesidir. İstemcilerin bu blokların doğruluğunu doğrulamak için verimli bir yönteme ihtiyaç duyacaklardır, bu nedenle L1 katmanında Rollup( ile ZK-EVM ve DAS) ile aynı teknolojileri kullanmak zorunda kalacağız.
Yol haritasının diğer bölümleriyle nasıl etkileşimde bulunulur?
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ırsa, talep daha da azalacaktır. DAS, dağıtık blok inşa protokolleri ve mekanizmalarına da zorluklar getirmektedir: teorik olarak DAS, dağıtık yeniden inşaya 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'taki her bir işlem, büyük miktarda zincir üzerindeki veri alanını kaplar: ERC20 transferi yaklaşık 180 bayt gerektirir. İdeal veri kullanılabilirliği örneklemesi olsa bile, bu, Layer protokolünün ölçeklenebilirliğini sınırlar. Her slot 16 MB, elde ettiğimiz:
16000000 / 12 / 180 = 7407 TPS
Eğer yalnızca payın sorununu değil, aynı zamanda paydanın sorununu da çözebilirsek ve her Rollup'taki işlemlerin zincirde daha az bayt kaplamasını sağlayabilirsek, o zaman ne olur?
Bu nedir, nasıl çalışır?
Sıfır bayt sıkıştırma sırası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ş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ğrulama hesaplama maliyeti yüksek olduğu için BLS imzasının kullanılması düşünülmemektedir. Ancak L2 gibi veri kıtlığı olan bir ortamda, 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 sunmaktadır.
Adresleri pointer ile değiştirme: Eğer daha önce belirli bir adres kullanmışsak, 20 baytlık adresi, geçmişteki bir konuma işaret eden 4 baytlık bir pointer ile değiştirebiliriz.
Özelleştirilmiş işlemler değerinin serileştirilmesi: Çoğu işlem değeri az sayıda basamağa sahiptir; örneğin, 0.25 ETH 250,000,000,000,000,000 wei olarak gösterilir. Maksimum temel işlem ücreti ve öncelik ücreti de benzer şekilde. Bu nedenle, çoğu para birimi değerini göstermek için özelleştirilmiş ondalık kayan nokta formatını kullanabiliriz.
ne yapılması gerekiyor, hangi dengeler var?
Sonraki adım, yukarıda belirtilen planın gerçeklenmesini sağlamaktır. Ana ticaretler şunlardır:
BLS imzasına geçmek büyük çaba gerektirir ve güvenliği artırabilecek güvenilir donanım yongalarıyla uyumluluğu azaltır. Bunun yerine diğer imza şemalarının ZK-SNARK paketleri kullanılabilir.
Dinamik sıkıştırma (. Örneğin, adres ) yerine işaretçiler kullanmak istemci kodunu karmaşık hale getirecektir.
Durum farklarını zincire yayınlamak yerine işlem yapmak, denetlenebilirliği azaltacak ve birçok yazılım ( örneğin blok gezgini ) çalışamaz hale getirecektir.
Harita üzerindeki diğer bölümlerle nasıl etkileşim kurabilirim?
ERC-4337'yi benimseyerek ve nihayetinde bazı içeriklerini L2 EVM'ye entegre ederek, agregasyon teknolojisinin dağıtımını önemli ölçüde hızlandırmak mümkündür. ERC-4337'nin bazı içeriklerini L1'de tutmak, L2'deki dağıtımını hızlandırabilir.
Genelleşmiş Plasma
Hangi sorunu çözmeye çalışıyoruz?
16 MB'lık blob ve veri sıkıştırması kullanılsa bile, 58.000 TPS tüketici ödemeleri, merkeziyetsiz sosyal ağlar veya diğer yüksek bant genişliği alanlarının ihtiyaçlarını tamamen karşılamak için yeterli olmayabilir; özellikle de gizlilik faktörlerini düşünmeye başladığımızda, bu ölçeklenebilirliği 3-8 kat azaltabilir. Yüksek işlem hacmine sahip, düşük değerli uygulama senaryoları için şu anda