Ethereum Cancun yükseltmesi yaklaşıyor, Cancun yükseltmesinin geçmişini, bugününü ve geleceğini gözden geçiriyor

Yazar: Fat Bird Finans

geçmiş yaşamlar

Cancun yükseltmesi neden gerekli?

Ethereum'un vizyonu, ademi merkeziyet öncülü altında daha ölçeklenebilir ve daha güvenli hale gelmektir. Ethereum'un mevcut yükseltmesi de bu ikilemi çözmeye kararlı, ancak büyük zorluklarla karşı karşıya.

Ethereum ile ilgili sorunlar:

Şu anda, düşük TPS ve performans, yüksek gaz ücretleri ve ciddi tıkanıklık var.Aynı zamanda, bir Ethereum istemcisini çalıştırmak için gereken disk alanı da hızla artıyor.En altta, Ethereum güvenliğini ve ademi merkeziyetçiliği sağlama iş yükü Etkisi tüm çevre üzerindeki mutabakat algoritması da giderek daha önemli hale geliyor.

Bu nedenle, ademi merkeziyet öncülü altında, ölçeklenebilirliği artırmak için daha fazla verinin nasıl iletileceği ve gazın nasıl azaltılacağı ve güvenliği sağlamak için fikir birliği algoritmasının nasıl optimize edileceği, Ethereum'un şu anda yaptığı çabalardır.

Güvenlik, ademi merkeziyetçilik ve ölçeklenebilirlik üçlemesini çözmek için Ethereum, düğüm eşiğini daha da azaltmak için PoW-to-PoS mekanizmasını kullandı ve ayrıca güvenliği optimize etmek için doğrulayıcıları rastgele atamak için işaret zincirini kullanmayı planlıyor. ölçeklenebilirlik konusunda Ethereum, düğümlerin iş yükünü azaltmak için parçalamayı kullanmayı düşünür, bu da Ethereum'un aynı anda birden fazla blok oluşturmasını ve ölçeklenebilirliğini geliştirmesini sağlar.

Şu anda, her bir Ethereum bloğunun alanı yaklaşık 200~300 KB, her işlemin minimum boyutu yaklaşık 100 bayt, yaklaşık 2000 işlem, 12 saniyelik blok süresine bölünür, Ethereum TPS'sinin üst sınırı şu şekilde sınırlıdır: yaklaşık 100 Bu veriler açıkça Ethereum'un ihtiyaçlarını karşılayamaz.

Bu nedenle, Ethereum Layer 2, büyük miktarda verinin blok uzayına nasıl yerleştirileceğine ve sahtekarlık kanıtları ve geçerlilik kanıtları yoluyla güvenliğin nasıl sağlanacağına odaklanır.Bu nedenle DA katmanı, aynı zamanda temel içeriği olan güvenliğin üst sınırını belirler. Cancun yükseltmesi.

Ethereum ekolojisinin yinelemeli rotası, kıyaslama noktası Solana'nın performansını (gecikme ve verim açısından) oluşturamaz ve Near'ın parçalanma performansı veya Sui ve Aptos'un paralel yürütme performansı kısa vadede görülmeyecektir. kısa vadede, Ethereum yalnızca Rollup'ın çekirdek olduğu çok katmanlı bir yapı inşa edebilir, bu nedenle TPS, gasfee ve geliştirici deneyimini çözmek için Cancun yükseltmesi Ethereum yol haritası için çok önemlidir.

Ethereum yol haritası nasıl planlanıyor?

Son önemli güncellemeler ve hedefleri

1 Aralık 2020'de işaret zinciri resmi olarak piyasaya sürüldü ve POS yükseltmelerinin önünü açtı

5 Ağustos 2021'de Londra yükseltmesi, EIP1559, Ethereum'un ekonomik modelini değiştirdi;

15 Eylül 2022'de Paris yükseltmesi (TheMerge), POW'un POS'a geçişini tamamladı;

12 Nisan 2023'te Şanghay, rehin geri çekme sorununu çözmek için yükseltildi;

Ekonomik model ve POS ile ilgili yükseltmeler tamamlandı ve sonraki birkaç yükseltme, Ethereum'un performansı, TPS ve geliştirici deneyimi sorunlarını çözdü;

Bir sonraki adım, Ethereum yol haritasındaki TheSurge'a odaklanıyor.

Hedef: Toplama'da 100.000+ TPS elde etmek.

Zincir içi ve zincir dışı olmak üzere başlıca 2 çözüm vardır:

Zincir dışı çözüm: toplama vb. dahil olmak üzere Layer2'yi ifade eder.

On-chain şeması: popüler bir sharding şeması olan L1'de doğrudan değişiklik yapmayı ifade eder.Sharding'in basit bir şekilde anlaşılması, tüm düğümleri farklı alanlara bölmek ve her alandaki görevleri tamamlamaktır, bu da hızı etkili bir şekilde artıracaktır;

Parçalanma şeması analizi:

Parçalama şemasının ikilemi: Parçalama, durum parçalama, işlem parçalama vb. içerirdi, ancak farklı parçalar arasındaki senkronizasyon bir sorundur. Şu anda, büyük ölçekli bir ağ düğümü veri senkronizasyonunu tamamlamak teknik olarak zordur. MEV'in durumunu çözemez mi, aynı zamanda kısa vadede gerçekleştirilemeyen çeşitli sorunları telafi etmek için çok sayıda yama gerekebilir.

Danksharding, Ethereum için önerilen yeni bir parçalama tasarımıdır. Temel fikri, merkezi blok üretimi + merkezi olmayan doğrulama + sansür direncidir. Bu aynı zamanda aşağıda belirtilen veri kullanılabilirliği örneklemesi (DAS) ve blok üreticileri ile de ilgilidir. - Paketleyici Ayırma (PBS) ve Sansür Dirençli Listeler (Crlist) ile ilgili. Danksharding'in temel fikrinin en büyük önemi, Ethereum L1'i birleşik bir yerleşim ve veri kullanılabilirliği (DataAvailability) katmanına dönüştürmektir.

Sharding şeması 2 adıma ayrılmıştır.Şu anda Proto-danksharding ve Fully-Rollup olarak bölünmüştür.

Proto-danksharding：

Giriş: L2'nin ücretleri düşürmesine ve iş hacmini artırmasına yardımcı olmak için bloblar sunarak, danksharding için bir ön şema olarak tam parçalamanın da yolunu açar. Proto-danksharding'den sonra danksharing'in uygulanmasının 2-5 yıl sürmesi bekleniyor.

İçerik: Proto-danksharding'in ana özelliği, yeni bir blob işlemi türü tanıtmaktır. Blob, büyük kapasite ve düşük maliyet özelliklerine sahiptir. Bu tür veri paketlerini Ethereum'a eklemek, tüm toparlama verilerinin blob'ta depolanmasına izin vererek, büyük ölçüde azaltılabilir. ana zincir Basıncının depolanması, aynı zamanda toplama maliyetini de azaltır.

Tam Toplama

Giriş: Toplama, veri kullanılabilirliğinin kullanımına odaklanarak kapasiteyi tamamen genişletir.

içerik:

DAS'ın P2P tasarımı: Veri paylaşımı ağ bağlantısı sorunu ile ilgili bazı çalışmalar ve araştırmalar;

Veri kullanılabilirliği örnekleme istemcisi: birkaç kilobayt rastgele örnekleme yaparak verilerin kullanılabilir olup olmadığını hızlı bir şekilde belirleyebilen hafif bir istemci geliştirin;

Verimli DA kendi kendini iyileştirme: en kötü ağ koşullarında (örn.

Ethereum Çekirdek Geliştiricileri Toplantısı

Ethereum'un her yükseltmesi, temel katkıda bulunanların ortak tartışması yoluyla çekirdek geliştirici toplantısına bağlıdır ve geliştiricilerden gelen bir dizi teklife göre, gelecekteki geliştirme yönü belirlenir.

Tanım: Temel Geliştirici Toplantısı, Ethereum geliştirme topluluğu tarafından düzenlenen ve farklı kuruluşlardan temel katılımcıların teknik sorunları tartışmak ve Ethereum üzerinde gelecekteki çalışmaları koordine etmek için bir araya geldiği haftalık bir konferans görüşmesidir. Ethereum protokolünün gelecekteki teknik yönünü belirlerler ve ayrıca Ethereum'un yükseltilmesi hakkında fiilen karar veren otoritedirler.EIP'nin yükseltmeye dahil edilip edilmeyeceğine, yol haritasının değiştirilmesi gerekip gerekmediğine ve diğer önemli hususlara karar vermekten sorumludurlar. önemli.

Çekirdek süreç: EIP merkezli yükseltme süreci kabaca şu şekildedir: İlk olarak, çekirdek geliştirici konferansında (kısaca ACD) bir EIP kabul edilir ve ardından müşteri ekibi, EIP'nin yükseltmeye dahil olup olmadığına bakılmaksızın bunu test eder. Son testten sonra tekrar gözden geçirin ve ardından tartışmaya dayalı olarak gerçek yükseltmeye dahil edilip edilmeyeceğine karar verin.

İki haftada bir dönüşümlü olarak yapılan mutabakat katmanı toplantısı ve yürütme katmanı toplantısı olmak üzere iki tür toplantı vardır:

Ethereum'un fikir birliği katmanına (Proof of Stake, Beacon Chain, vb.) odaklanan Consensus Layer Konferansı (AllCore Developers Consensus - ACDC);

Ethereum'un yürütme katmanına (EVM, Gaz programı vb.) odaklanan yönetici katmanı konferansı (AllCore Developers çözümü - ACDE).

Teklifleri tartışan başlıca resmi kuruluşlar veya gönüllü forumlar olmak üzere üç tür Ethereum temel sağlayıcısı vardır:

AllCoreDevs: ETH1 ağ istemcisinden sorumlu kod bakım görevlileri, yükseltme, Ethereum kodunu ve çekirdek mimarisini sürdürme;

"Proje Yönetimi" bölümü: Ethereum geliştiricilerini destekleyin, hard forkları koordine edin, EIP'yi izleyin, vb. ve AllCoreDev'lere iletişim ve operasyonlarda doğrudan yardım edin;

EthereumMagicians: EIP ve diğer teknik konular hakkında tartışma isteyen bir "forum".

Cancun Yükseltmeyle İlgili Toplantıların Zaman Çizelgesi

Tartışmanın içeriğine göre, bu Cancun yükseltmesi kabaca beş aşamaya ayrılabilir.

İlk aşama - yükseltme temasının tanıtılması

Yeni görevler proto-danksharding, EOF ve "selfdestruct" işlem kodlarını tanıtın, Şangay yükseltme içeriğini kısaca tartışın

15 Eylül 22'de Ethereum birleşmesi tamamlandıktan sonra, geliştirici toplantısı 4 hafta süreyle askıya alındı ve geliştiricilerin sonraki yükseltmede tartışılan EIP'yi bir ay boyunca kontrol etmesine izin verildi;

28 Ekim 22'de, birleşmeden sonraki ilk geliştirici toplantısı, proto-danksharding, EOF ve "selfdestruct" opcode'un ilk kez uygulanmasını önerdi. Şu anda, proto-danksharding'in özel kapsamı belirlenmedi ve bazı geliştiriciler başlangıçta Şangay yükseltmesinin birkaç küçük yükseltmeye bölünebileceğini düşünüyor, örneğin önce taahhütlü ETH çekme işlemlerinin etkinleştirilmesi ve ardından EIP4844'ün yükseltilmesi gibi, ancak bazı geliştiriciler daha büyük bir yükseltmeyi tek adımda uygulamanın daha anlamlı olduğunu düşünüyor.

2. Aşama - Zaman çerçevesinin belirlenmesi ve KZG töreni için hazırlık

2022'nin sonunda, Ethereum konferansı esas olarak EOF ve EIP4844'e odaklanacak. Aynı zamanda, EIP4844'ün gerektirdiği önceden güvenilir kurulum törenini - KZG töreni - tanıtmaya devam edeceğiz. Geliştiriciler, 4844'ün hangi yükseltmede kullanılacağını resmi olarak belirleyecek. 23 Ocak'ta görünür

22 Kasım'da, EOF veya proto-danksharding, Ethereum'un tüm temel geliştiricilerinin 149 numaralı konferans görüşmesinde zaten bahsedilmişti.Şu anda, geliştiriciler hala onu Şanghay yükseltmesine yerleştirmeyi düşünüyorlar;

12/02/22 tarihli Mutabakat Katmanı toplantısında, Ethereum ekosisteminin başkanı Trent Van Epps, kullanılacak bir güvenli kod parçası oluşturmayı amaçlayan EIP4844'ün uygulanması için gerekli olan güvenilir kurulum töreninin ilerleyişi hakkında bilgi verdi. EIP4844'te kullanılır. VanEpps, törenin 8.000 ila 10.000 katkı toplayarak kripto alanında şimdiye kadarki en büyük törenlerden biri olacağını umuyor.Törenin kamu katkı dönemi yaklaşık 2 ay sürecek ve Aralık ayında başlayacak;

Aynı gün yapılan çekirdek geliştirici toplantısında, EOF ve kendi kendini yok etme işlem kodunun devre dışı bırakılması hakkında bazı tartışmalar oldu.Ethereum Foundation'ın belirli bir geliştiricisi, EOF'nin Cancun'a ertelenmesine itiraz etti ve kod değişikliklerinin Şangay'a dahil olmaması durumunda, Cancun'a girme olasılığı çok düşük. Kendini yok etme koduyla ilgili olarak, bazı geliştiriciler o sırada EIP4758'in geliştirilmesini savundu, ancak bu işlem kodunu doğrudan devre dışı bırakmanın bazı uygulamaları bozacağına inanıyor. Geliştiriciler, bu tür bir sözleşmeyi korumak için bir uç durum oluşturmadan önce, Bu EIP bir süre tekrar tartılmalıdır;

9 Aralık 22'deki çekirdek geliştirici toplantısında, Cancun yükseltmesi ile ilgili olarak KZG töreninin uygulanması tanıtıldı.Şu anda, EIP4844'ün gerektirdiği güvenilir ayar töreni hazır;

EIP4844 konulu 16/12/22 tarihli Mutabakat Katmanı toplantısında, geliştiriciler iki farklı çekme isteğini (PR'ler) proto-danksharding spesifikasyonunda birleştirmeyi tartıştılar; belirli bir blokta lekeler hakkında bilgi eksik olduğunda, uyarı düğümlerine yeni bir hata kodu eklenir;

5 Ocak 23'teki çekirdek geliştirici toplantısında geliştiriciler, Şangay yükseltmesinden EOF uygulamasıyla ilgili kod değişikliklerinin kaldırılması konusunda fikir birliğine vardılar.Bu sırada Beiko, EOF'nin iki hafta sonra engele dahil edilip edilmeyeceğine karar vermeyi önerdi. Kun yükseltiliyor;

3. Aşama - Teklif Kapsamının Ön Görüşmesi

23 Ocak sonunda, EOF, Şangay'dan kaldırıldıktan sonra yükseltme için Cancun'a taşındı. Sonraki iki ay içinde, tartışmalar ağırlıklı olarak EOF ve EIP4844 dışındaki diğer tekliflere odaklandı. Aynı zamanda, EOF'un Cancun'dan taşınması önerildi. . Bu süre, esas olarak Cancún'un yükseltilmesi için tekliflerin kapsamını belirlemek için harcandı.

20 Ocak 23'teki çekirdek geliştirici toplantısında EOF, yükseltme için Cancun'a taşındı;

6 Mart 23'teki çekirdek geliştirici toplantısında, Cancun yükseltmesi için ön teklifler şunlardı: EIP4788 (genel işaret zinciri durum kökü), EIP2537 (BLS imza doğrulaması ve SNARK doğrulaması gibi işlemleri verimli bir şekilde gerçekleştirin), EIP-5920 (yeni giriş opcode PAY) ve EIP6189 (SELFDESTRUCT'ı Verkle ağaçlarıyla uyumlu hale getirmek için) ve EIP-6190'ın (SELFDESTRUCT işlevini yalnızca sınırlı sayıda durum değişikliğine neden olacak şekilde değiştirmek) birleşik uygulaması;

16, 23 Mart'ta yapılan çekirdek geliştirici toplantısında, EOF ve EIP4844'e ek olarak, Cancun'a dahil edilmesi için aşağıdaki teklifler değerlendirildi: SSZ formatı, SELFDESTRUCT silme, EIP2537, EVMMAX, EIP1153, sınırsız SWAP ve DUP talimatları, PAY Beacon'un tanıtımı kodda ve EVM'de durum kökü;

30 Mart 23'teki çekirdek geliştirici toplantısında, EIP-6780'in SELFDESTRUCT'ı devre dışı bırakma önerisi ilk kez sunuldu, bu aynı zamanda Cancun'un sonunda kullanmaya karar verdiği SEFDESTRUCT'ı devre dışı bırakma önerisidir. Ancak EOF'nin uygulanmasıyla ilgili olarak, Erigon(EL) müşteri ekibinden bir geliştirici, EOF'nin Cancun Uygulamasında yükseltilmesi önerilen yaklaşan Cancun yükseltmesinde Ethereum iyileştirme teklifi EIP4844 ile birleştirilemeyecek kadar "çok değiştiğini" belirtti. Kısa bir süre sonra sert çatalda EOF;

Dördüncü aşama - teklif yükseltmesinin net yönünü belirleyin ve alakasız teklifleri silin

23 Nisan'da, Cancun yükseltmesinin kapsaması gereken teklifler için net bir yön vardı. Kilit düğüm, 13 Nisan'daki geliştirici toplantısıydı. Bu toplantı 9 EIP önerdi ve Tim'in kendisi de, alternatif öneriler Tartışma, 27 Nisan'daki toplantıda EIP6780, EIP6475 ve EIP1153'ün Cancun'a dahil edilmesi belirlenirken, EOF ve EVMMAX (EOF uygulamasıyla ilgili EIP alt kümeleri) Cancun yükseltmesinden çıkarıldı, EOF yükseltmesi esas olarak yardımcı olabilir EVM Sürüm kontrolü ve birden fazla sözleşme kuralı seti aynı anda çalıştırılabilir, bu da Ethereum'un müteakip genişlemesine elverişlidir.Bununla birlikte, tüm yükseltmenin fizibilitesi göz önüne alındığında, EOF yükseltmesi, takip eden günlerde günlük yükseltmelerle desteklenebilir. yukarı

12 Nisan 23'te Ethereum Shanghai'ın yükseltmesi tamamlandı;

13.04.23 tarihinde geliştiricilerin EIP4844'ü (EL'deki CL durum kökü hakkındaki verileri ifşa etmek için) tartıştığı çekirdek geliştirme toplantısına ek olarak, yükseltme için düşünülen en az dokuz EIP daha var. EIP-6780, EIP4758, EIP6046, EIP6190), EIP5920, EIP1153, EIP2537, EIP4788, EVMMAXEIP'ler (EIP6601 ve EIP6690), SSZ değişiklikleri (EIP6475, EIP6493, EIP 6465, EIP6404 ve EIP6466 ), EIP 5656 ve EIP6193;

27, 23 Nisan'daki çekirdek geliştirici toplantısında, çeşitli ilerlemeler ve ödünleşimler üzerinde duruldu. İlk olarak, EIP4844, Cancun yükseltmesine dahil edilmek üzere tanımlanmaya devam ederken, aşağıdaki EIP'ler eklenmiştir: EIP6780 (SELFDESTRUCT işlem kodunun işlevselliğini değiştirir), EIP6475 (isteğe bağlı değerleri temsil eden yeni bir Basit Serileştirme (SSZ) türü), EIP1153 ( ikinci olarak yeni ekler, dikkate alınan ancak resmi olarak yükseltmeye dahil edilmeyen EIP'ler şunlardır: EIP6913 (SETCODE komutunu tanıtır), EIP6493 (SSZ kodlu işlemler için imza şemasını tanımlar), EIP4788 (EL bloğundaki işaret zinciri kökünü ifşa eder) başlık), EIP2537 (BLS12-381 eğrisini ön derleme olarak ekler) ve EIP5656 (bellek bölgelerini kopyalamak için yeni EVM talimatları sunar); son olarak, EOF ve EVMMAX (EOF uygulamasıyla ilgili EIP alt kümesi) Cancun yükseltmesinden kaldırıldı. EOF yükseltmesi, Ocak 2023'ün başlarında Ethereum Geliştiricileri Konferansı'ndaki Şanghay yükseltmesinden kaldırıldı ve Ocak 2023'ün sonundan Nisan 2023'ün başına kadar Cancun yükseltmesinde görünmesi varsayılan olarak yapıldı, ancak geliştirme 29, 23 Nisan'da yapıldı. Yazarlar toplantısında EOF tekrar kaldırılır.

Beşinci aşama - nihai teklif belirleme ve detay iyileştirme

23 Mayıs'ta, nihai teklif ayrıntıları büyük ölçüde kolaylaştırıldı ve iyileştirildi.SSZ->RLP değişikliği, Cancun'daki iki SSZEIP'ye artık ihtiyaç duyulmayacağı anlamına gelecek, bu nedenle EIPs6475 ve 6493, yükseltme için Cancun'dan taşınacak. Ayrıca 26'sındaki toplantıda Tim Beiko, Cancun'un kapsamının genişletilmesiyle ilgili gelecekteki konuşmaların şu beş EIP ile sınırlandırılmasını önerdi: EIP-5920, 5656, 7069, 4788 ve 2530. Geliştiriciler artık Cancun yükseltmesinin tam kapsamını belirlediler.

5 Mayıs 23'teki Ethereum Çekirdek Konsensus Toplantısı, geçen sefer bahsedilen EIP4788'i tartıştı ve sırasıyla doğrulayıcılar ve SSZ işlemleriyle ilgili olan EIP6987 ve EIP6475 hakkında tartışmalar ekledi;

11 Mayıs 23'teki 161. Ethereum yönetici katmanı toplantısında TimBeiko, Cancun yükseltmesinin kapsamının önümüzdeki birkaç hafta içinde hala değiştirilebileceğini, ancak geliştiriciden net bir öneri gelmezse Cancun yükseltmesinin kapsamının değiştirilebileceğini söyledi. "varsayılan" durumu koruyun ve EIP-4844 ile ilgili tartışma, geliştiricilerin SSZ'yi EIP-4844'ün EL uygulamasından çıkarmayı kabul ettiğini, ancak bunun 6475'in devam eden ilerlemesini etkilemediğini gösteriyor. Ek olarak, geliştiriciler Cancun'da değerlendirilmek üzere iki EIP'yi de kısaca tartıştılar: EIP6969 (EIP1559'un değiştirilmiş bir versiyonu) ve EIP5656 (bellek bölgelerini kopyalamak için verimli EVM talimatları);

4844'ün geliştirilmesi, 18.05.23 tarihindeki Geliştirici Uzlaşması toplantısında kısaca tartışıldı, örneğin EL'deki akıllı sözleşme uygulamalarının CL durumunun kanıtlarını doğrulamasına izin verilmesi;

25 Mayıs 2023'teki 162. Ethereum Core toplantısında SEFDESTRUCT'ın devre dışı bırakılması, EIP-4844 spesifikasyon değişiklikleri, işlem kodu yönetimi ve potansiyel nihai Cancun eklemeleri tartışıldı. Tim Beiko, Cancun'un kapsamını genişletmekle ilgili gelecekteki konuşmaların şu beş EIP ile sınırlandırılmasını önerdi: EIP-5920, 5656, 7069, 4788 ve 2530. Geliştirici, önümüzdeki birkaç hafta içinde tüm Dencun (Deneb+Cancun) serisini belirleyecek;

1 Haziran 2023'teki 110. Ethereum Mutabakat Katmanı Toplantısında, Ethereum Vakfı'ndan bir araştırmacı, Ethereum ana ağ düğümlerinin büyük miktarda veri yayma kabiliyetine ilişkin bir veri deneyinin sonuçlarını açıkladı. Bu sonuçtan, araştırmacı EIP4844'ü önerdi. spesifikasyon, blok başına maksimum 4 blobtan 6'ya çıkarıldı. Aynı zamanda, geliştiriciler EIP4788'i Cancun yükseltmesine dahil etmeyi düşünüyor;

13 Haziran 2023'teki temel geliştirici toplantısında geliştiriciler, EIP4844, EIP1153, EIP5656, EIP6780 ve EIP4788 dahil olmak üzere yükseltmenin kapsamını resmi olarak onayladılar;

15 Haziran 2023 tarihinde yapılan mutabakat toplantısında, Deneb'e hangi CL merkezli EIP'lerin dahil edileceği tartışılmış, bunlara EIP-6988, EIP-7044, EIP-7045 eklenmesi önerilmiş ve CL müşteri ekibi üzerinde anlaşmaya varmıştır. EIP-4844 test ağı Devnet6 üzerinde artan blob sayısını test edin ve iki hafta içinde bu konuda nihai bir karar verin.Aynı zamanda Ethereum Vakfı'nda araştırmacı olan Michael Neuder, 32 ETH'yi iptal etmeyi teklif etti. aktif doğrulayıcı setinin büyümesini azaltmaya yardımcı olmak için taahhüt limiti;

22 Haziran 2023'teki toplantıda Tim, önceden derlenmiş 4844 adresinin 0xA'ya taşınmasını, paketlenmesini ve BLS'nin başka bir adrese taşınmasını önerdi, ancak bu önceden derlenmiş EIP2537 aracılığıyla tanıtıldı, Cancun planında dikkate alınmayacak;

29 Haziran 2023'teki mutabakat toplantısında geliştiriciler blob sayısını tartışmaya devam ettiler, hedef blob limitini 2'den 3'e ve maksimum blob limitini 4'ten 6'ya çıkardılar. Aynı zamanda 4844 testnet Devnet #7 yakında piyasaya sürülecek.

bu hayat

Temel içerik EIP4844, Proto-Danksharding'dir.

Cancun yükseltmesi için son EIP aralıkları şunlardır: EIP4844, EIP1153, EIP5656, EIP6780 ve EIP4788. Aynı zamanda, 19 Haziran'daki 111. Ethereum ACDC toplantısında geliştiriciler, Deneb'e dahil edilmek üzere EIP6988, EIP7044 ve EIP7045'i tartışmaya devam ettiler. Geliştiriciler, önümüzdeki haftalarda yukarıda bahsedilen üç EIP'yi Deneb spesifikasyonuyla birleştirmeyi planladıklarını söylediler.

Önemli EIP'lerin analizi

EIP4844

Giriiş:

EIP4844 teklifinin adı, Danksharding'in tam sürümü için ön parçalama çözümü olan Proto-Danksharding'dir. Parçalama şemalarının tamamı, aslında zincir üzerinde genişleme için Toplama etrafında döner. Çözümün amacı, tam parçalamanın yolunu açarken L2'nin ücretleri azaltmasına ve verimi artırmasına yardımcı olarak katman 2 Toplamasını genişletmektir.

23 Şubat'ta yapılan konferans görüşmesinde Ethereum geliştiricileri EIP4844'ü yükselterek Cygnus'ta birinci sınıf bir yıldızın adı olan Deneb adını verdiler. 1 Mart'ta yapılan toplantıda CL tarafında Deneb, EL tarafında Cancun olarak isimlendirilen Ethereum'un bir sonraki upgrade spesifikasyonunda bazı değişiklikler oldu;

23 Haziran'daki geliştirici toplantısında, geliştiriciler EIP4844'ün önceden derlenmiş adresini güncelleyeceklerdi. Şu anda çekirdek geliştiriciler, EVM'ye 9 ön derleme eklediler ve sırasıyla EIP4844 ve 4788'i etkinleştirerek "0xA" ve "0xB" adresleri altında iki ön derleme oluşturacaklar. 29 Haziran'daki fikir birliği toplantısında, EIP4844 için özel bir kısa vadeli test ağı olan Devnet#7 hazırlandı.

EIP-4844, yepyeni bir işlem türü olan BlobTranscation'ı sunar.

Bloblara giriş:

Bir eklenti veri paketine benzeyen Blob, başlangıçta sadece 128KB depolama alanına sahip.Teklif tartışmasının başında Blob'un hedefi ve limiti 2/4 idi.9 Haziran'daki geliştirici toplantısında , 23, 3/6 olarak ayarlandı. Yani, şu anda Ethereum'daki her işlem, 384KB olan üç adede kadar Blob işlemi taşıyabilir ve her bloğun targetBlob kapasitesi 6, yani 768KB ve maksimum 16 Blob işlemi, yani 2MB taşıyabilir;

Ağ kararlılığı üzerinde belirli bir etkisi olabilir, ancak Ethereum geliştirme ekibi, blob bloğunu genişletmek için sonraki hard forklara ihtiyaç duymamak için önce onu test etmeye karar verdi.

Blob, veri doğrulama için Merkle'ye benzer şekilde KZGcommit Hash'i Hash olarak kullanır;

Düğüm zincirdeki BlobTransaction'ı senkronize ettikten sonra, Blob bölümünün süresi dolar ve belirli bir süre sonra silinir ve depolama süresi üç haftadır.

Blob'un rolü - maliyetleri düşürürken Ethereum'un TPS'sini iyileştirin

Şu anda, tüm Ethereum'un toplam veri hacmi yalnızca yaklaşık 1TB'dir ve Blob, Ethereum'a her yıl 2,5-5TB ek veri hacmi getirebilir, bu da doğrudan defterin kendisini birkaç kez aşar;

Düğümler için blok başına 1 MB ila 2 MB blob verisi indirmek bant genişliği yüküne neden olmaz ve depolama alanı yalnızca sabit miktarda blob verisini ayda yaklaşık 200~400 GB artırır; Ethereum düğümü, ancak Rollup etrafındaki genişleme büyük ölçüde geliştirildi;

Ve düğümün kendisinin tüm blob verilerini depolaması gerekmez, çünkü blob aslında geçici bir veri paketidir, dolayısıyla aslında düğümün yalnızca üç hafta boyunca sabit miktarda veri indirmesi gerekir.

EIP-4844'ün rolü - Danksharding anlatısının ilk bölümünü açıyor

Yüksek genişleme: Şu anda, EIP-4844 başlangıçta L2 kapasitesini genişletebilir.Danksharding'in tam sürümü, EIP-4844'teki Blob veri hacmini 1MB'den 2MB'ye, 16MB'den 32MB'ye genişletebilir.Yüksek genişleme;

Düşük ücretler: Bernstein analistlerine göre, Proto-dank-sharding, katman 2 ağının ücretlerini mevcut düzeyin 10-100 katına kadar azaltabilir;

gerçek veriler:

Opside test ağı 4844'ü konuşlandırdı ve mevcut gözlem, toplama maliyetini %50 azaltabilir;

EigenLayer'ın DA teknik çözümü, verilerini değerlendirmek için çok fazla açıklama yapmaz;

Açıkça söylemek gerekirse, Celestia'nın Ethereum ile çok az ilgisi var ve belirli teknik çözümlerine bağlı olarak DA maliyeti şu anda değerlendirilemez;

Ethstorage'ın çözümü, Layer2 depolama sertifikasını yüklemektir ve DA maliyeti orijinalin %5'ine düşürülebilir;

Topia, maliyetleri 100 ila 1000 kat azaltmayı bekliyor, çünkü Danksharding ana ağının ayrıca Katman 1 P2P ağ yayını ile güvenlik ve uyumluluğu da hesaba katması gerekiyor.

DA çözümü: Danksharding (Ethereum genişlemesi için bir parçalama çözümü), genişlemeye devam ederse şu anda aşırı düğüm yükü (16 mb'nin üzerinde) ve yetersiz veri kullanılabilirliği (30 günlük geçerlilik süresi) ile ilgili sorunlar yaşayabilir. Çözüm:

DataAvailability Örnekleme - düğüm yükünü azaltır

Blob'taki verileri veri parçalarına ayırın ve düğümlerin Blob verilerini indirmekten Blob veri parçalarını rastgele kontrol etmeye geçmesine izin verin, böylece Blob veri parçaları Ethereum'un her bir düğümüne dağılır, ancak Blob verilerinin tamamı depolanır tüm Ethereum In Fang defterinde, öncül, düğümlerin yeterli ve merkezi olmayan olması gerektiğidir;

DAS iki teknoloji kullanır: silme kodlaması (ErasureCoding) ve KZG polinom taahhüdü (KZGCommitment);

Önerici-paketleyici ayrımı (PBS) - düğümler arasındaki işbölümü sorununu çözerek, yüksek performanslı yapılandırmalara sahip düğümlerin kodlama ve dağıtım için tüm verileri indirmekten sorumlu olmasına ve düşük performanslı yapılandırmalara sahip düğümlerin anlık kontrollerden sorumlu olmasına izin verir ve doğrulamalar.

Yüksek performanslı yapılandırmalara sahip düğümler oluşturucu haline gelebilir. Oluşturucuların yalnızca kodlama için blob verilerini indirmesi ve bloklar oluşturması ve ardından nokta kontrolleri için diğer düğümlere yayınlaması gerekir. Oluşturucular için, senkronizasyon veri hacmi ve bant genişliği gereksinimleri yüksek olduğundan, nispeten merkezi;

Düşük performanslı yapılandırmaya sahip bir düğüm, bir teklif sahibi (Teklif Sahibi) olabilir. Teklif sahibinin yalnızca verilerin geçerliliğini doğrulaması ve blok başlığını (BlockHeader) oluşturup yayınlaması gerekir. Ancak, teklif sahibi (Teklif Sahibi) için, senkronize veri miktarı ve bant genişliği gereksinimleri nispeten yüksektir.Düşük, bu nedenle merkezi olmayan olacaktır.

Anti-sansür listesi (crList) - paketleyicilerin aşırı inceleme güçleri nedeniyle belirli işlemleri kasıtlı olarak göz ardı edebilmeleri ve MEV elde etmek istedikleri işlemleri eklemeleri sorununu çözer.

Oluşturucu (Oluşturucu) blok işlemlerini paketlemeden önce, teklif sahibi (Teklif Sahibi) mempool'daki tüm işlemleri içeren incelemeye dayanıklı bir liste (crList) yayınlayacaktır;

Kurucu (Kurucu) yalnızca işlemleri crList'te paketlemeyi ve sıralamayı seçebilir; bu, oluşturucunun MEV elde etmek için kendi özel işlemini ekleyemeyeceği veya bir işlemi kasten reddedemeyeceği anlamına gelir (Gaslimit dolu olmadığı sürece);

Paketlemeden sonra Oluşturucu, Karma işlem listesinin son sürümünü Teklif Sahibine yayınlar ve Teklif Sahibi, bir blok başlığı (BlockHeader) oluşturmak ve yayınlamak için işlem listelerinden birini seçer;

Düğüm verileri senkronize ettiğinde, blok gövdesinin seçilen nihai sürüm olduğundan emin olmak için teklif sahibinden (Teklif Sahibi) blok başlığını alacak ve ardından paketleyiciden (Oluşturucu) blok gövdesini alacaktır.

Çift yuvalı PBS - merkezi paketleyicilerin MEV'yi alarak giderek daha merkezi hale gelmesi sorununu çözer

Bloğu belirlemek için teklif verme modunu kullanın:

Oluşturucu (Builder), crList ve teklifleri aldıktan sonra işlem listesinin blok başlığını oluşturur;

Teklif sahibi (Teklif Sahibi), sonunda başarılı bir şekilde teklif veren blok başlığını ve oluşturucuyu (Yapıcı) seçer ve teklif sahibi koşulsuz olarak kazanan teklif ücretini alır (geçerli bir bloğun oluşturulup oluşturulmadığına bakılmaksızın);

Doğrulama komitesi (Komiteler) kazanan blok başlığını onaylar;

Oluşturucu, kazanan bloğun gövdesini açıklar;

Doğrulama komitesi (Komiteler) kazanan bloğun gövdesini onaylar ve bir doğrulama oylaması gerçekleştirir (blok geçilirse, blok üretilir ve paketleyici kasten blok Gövdesini vermezse, bloğun vermediği kabul edilir. var olmak).

önemi:

Her şeyden önce, oluşturucunun (Builder) işlemleri paketlemek için daha fazla gücü vardır, ancak yukarıda bahsedilen crList, öncelikle işlemleri geçici olarak ekleme olasılığını sınırlar ve ikinci olarak, oluşturucu (Builder) işlem sırasını değiştirerek kar etmek istiyorsa, Blok başkanı kalifikasyonunu elde edebilmesi için başlangıçta büyük bir teklif maliyeti ödemesi gerekir, ardından elde ettiği MEV karı daha da azalır ve genel olarak elde etmenin araçları ve gerçek değeri üzerinde bir etkisi olur. MEV;

Bununla birlikte, erken aşamada, (düğüm performans sorunları dikkate alındığında) yalnızca az sayıda insan paketleyici olabilirken, çoğu kişi yalnızca teklif veren olur, bu da daha fazla merkezileşmeye yol açabilir.Aynı zamanda, paketleyicilerin sayısı çok fazla olduğunda küçük Belirli koşullar altında, MEV yeteneklerine sahip bazı deneyimli madencilerin başarılı bir şekilde teklif verme olasılığı daha yüksek olacak ve bu da gerçek MEV çözümünün etkisini daha da etkileyecektir;

Bunun, MEV açık artırmalarını kullanan bazı MEV çözümleri için etkileri vardır.

önemi:

EIP4844 aslında Danksharding'in süper basitleştirilmiş bir sürümüdür: DataHash adlı yeni bir işlem kodu ve BinaryLarge Objects adlı Blob adlı yeni bir veri nesnesi dahil olmak üzere Danksharding ile aynı uygulama arayüzünü sağlar;

proto-danksharding, Danksharding spesifikasyonunun tamamını uygulamak için bir "parantez" (yani, işlem formatı ve doğrulama kuralları) önerisidir: ancak, henüz hiçbir parçalama uygulanmadı ve tüm doğrulayıcılar ve kullanıcıların yine de tam verilerin kullanılabilirliğini doğrudan doğrulaması gerekiyor ;

Gelecekte tam bir shard'a yükseltirken yalnızca küçük bir ayarlama gerektiğinden, uzun vadede katman2 ücretini doğrudan düşürmek için neden EIP4488 yerine proto-danksharding'i seçiyorsunuz:

EIP4488 ve proto-danksharding arasındaki temel pratik fark, EIP-4488'in Ethereum'un bugün yapması gereken değişiklikleri en aza indirmeye çalışması, proto-danksharding'in ise gelecekte Ethereum'a yükseltmek için bugün Ethereum'da daha fazla değişiklik yapmasıdır. tam sürüm parçalama için gereklidir;

Tam sharding'i uygulamak (veri kullanılabilirliği örneklemesi vb. ile) karmaşık bir görev olmasına ve proto-danksharding'i uyguladıktan sonra hala yapılması gereken karmaşık işler olmasına rağmen, bu karmaşıklıklar fikir birliği katmanında kontrol edilecektir. Proto-danksharding dağıtıldıktan sonra yönetici katmanı istemci ekibi, toplama geliştiricileri ve kullanıcıların tam parçalamaya geçerken herhangi bir ek iş yapmaları gerekmez.

Eksiksiz parçalama elde etmek için, PBS'nin gerçek uygulamasını, yetki verilmiş kanıtı ve veri kullanılabilirliği örneklemesini tamamlamak gerekir, ancak bu tür değişiklikler CL katmanı üzerinde yoğunlaşacaktır ve geliştiricilerin yeniden ayarlama yapmasına gerek yoktur: şu anda 4844 yeni bir işlem türü uyguluyor Tam bir parçada gerekli olan işlem biçimi, mutabakat çapraz doğrulama mantığı ve yürütme katmanı mantığı tamamen aynıdır ve bloblar için kendi kendini ayarlayan bağımsız gas fiyatlandırması da türetilmiştir. Gelecekte, PBS ve yetkilendirilmiş kanıtların tamamlanması ve veri kullanılabilirliği örneklemesinin gerçek uygulamasının tamamlanması gerekir, ancak bu değişiklikler yalnızca CL katmanındadır ve EL katmanı veya geliştiriciler için uygun olan toplama geliştiricileri tarafından değişiklik yapılmasını gerektirmez.

SELFDESTRUCTremoval'ın ardından EIP-6780'in en uygun çözüm olduğu nihayet belirlendi, ancak 26'sındaki geliştirici toplantısında Tim, programatik hesapların güncellenmesine izin vermek için bu teklife başka bir işlem kodu SETCODE eklemeyi önerdi.

SELFDESTRUCTkaldırma EIP-6780：X

arka plan:

21 Mart'ta Vitalik, SELFDESTRUCT'un Ethereum ekolojisine yarardan çok zarar verdiğini öne sürdü.Bunun ana nedeni, tek bir blokta sonsuz sayıda durum nesnesini değiştirebilen ve sözleşme kodu değişikliklerine neden olan tek kişi olmasıdır. hesabın izni olmadan değiştirilemez.Hesap bakiyesinin işlem kodu, Ethereum'un güvenliği için büyük bir gizli tehlike içerir;

Zincir üzerinde bir sözleşmeyi kaldırmanın tek yolu SEFDESTRUCT'tur. Sözleşmede kendi kendini yok etme işlevini çağırırsanız, sözleşmeyi kendi kendini yok edebilirsiniz. Sözleşmede depolanan Ethereum, tasarlanan adrese gönderilecektir. Kalan kod ve depolama değişkenleri, durum makinesinde kaldırılacaktır. Aslında, sözleşmeyi bozma eylemi teoride kulağa hoş geliyor ama aslında çok tehlikeli. Kendini yok etme işlevi, geliştiricilerin akıllı sözleşmeyi silmesine ve acil bir durumda sözleşmedeki bakiyeyi belirtilen adrese aktarmasına yardımcı olsa da, bu özellik suçlular tarafından da kullanılarak bir saldırı aracı haline geliyor.

13 Nisan 23'teki çekirdek geliştirici toplantısında, tartışmaya katılmak üzere SEFDESTRUCT ile ilgili dört teklif, yani 6780, 4758, 6046 ve 6190 sunuldu ve takip eden EIP6780 nihai teklif olarak belirlendi.

Giriş: selfdestruct, sözleşmeyi yok eden ve kalan ETH'yi belirlenen hesaba aktaran akıllı sözleşmenin acil durum düğmesidir.

EIP6780: Sözleşmede aynı işlemde olmadıkça SEFDESTRUCT'ı devre dışı bırakın.

GÜNCELLEME: 26 Mayıs'ta tim, programlı hesapların güncellenmesine izin vermek için SEFDESTRUCT'ı kaldırmanın yanı sıra başka bir işlem kodu - SETCODE eklemeyi önerdi. (Yani, güncelleme işlevi eklenir ve akıllı sözleşmedeki özellik güncelleme/yükseltme yoluyla güncellenir), işte EIP4758'in avantajı, dapp'in yükseltme için yer açmasına izin verir.

Sebep: SELFDESTRUCT kodunun manipüle edilmesi başlangıçta hesap durumunda tüm kodların ve depolamanın silinmesi gibi kapsamlı değişiklikler gerektirdi. Bu, gelecekte Verkle ağaçlarını kullanmak için zorluklar yaratır: her hesap, açıkça kök hesaba bağlanmayacak birçok farklı hesap anahtarında saklanacaktır.

DEĞİŞTİRİLMİŞ: Bu EIP, aşağıdaki iki istisna dışında SEFDESTRUCT'ı kaldıran bir değişiklik uygular.

Yalnızca SEFDESTRUCT'tan para çekmek için kullanılan uygulamalar çalışmaya devam edecektir;

Sözleşmede aynı işlemde kullanılan SEFDESTRUCT'ın da değiştirilmesine gerek yoktur.

Önem: Güvenliği artırın

Daha önce, ana ağ üzerinde, sözleşme aracılığıyla kimlerin işlem başlatabileceğini kısıtlamak için SEFDESTRUCT kullanan bir sözleşme vardı;

Kullanıcıların SEFDESTRUCT'tan sonra bir kasada para yatırmaya ve ticaret yapmaya devam etmesini önlemek için bu kasa, tekrarlanan kullanım sırasında herhangi birinin kasadaki jetonları çalmasına neden olabilir.

Aşağıdaki üç teklif, daha sonra silinen SELFDESTRUCT ile ilgili tekliflerdir. 6780, 28 Nisan 23'teki çekirdek geliştirici toplantısında resmi olarak seçildi ve kalan üç teklif, Ethereum geliştirme ekibi sonunda SELFDESTRUCT işlem kodunu tamamen silmek istediği için terk edildi. ve aşağıdaki üç teklif daha ikame yoluyla değiştirilmiştir.

EIP-4758 (KALDIRILMIŞ): SEFDESTRUCT'ı SENDALL olarak değiştirerek devre dışı bırakın; bu, arayana tüm fonları geri yükler (hesaptaki tüm eteri arayana gönderir), ancak herhangi bir kodu veya depolamayı silmez.

Sebep: Yukarıdakiyle aynı, daha önce SEFDESTRUCT kodlarının manipüle edilmesi, hesap durumunda tüm kodların ve depolamanın silinmesi gibi kapsamlı değişiklikler gerektiriyordu. Bu, gelecekte Verkle ağaçlarını kullanmak için zorluklar yaratır: her hesap, açıkça kök hesaba bağlanmayacak birçok farklı hesap anahtarında saklanacaktır.

Değiştirmek:

SENDALL olarak yeniden adlandırılan SEFDESTRUCT işlem kodu, artık yalnızca hesaptaki tüm ETH'yi arayana taşıyor, şema artık kodu ve depolamayı bozmaz veya sıfırları değiştirmez;

İlgili tüm geri ödemeler SEFDESTRUCT silindi

önemi:

EIP-6780'e kıyasla orijinal işlevsellik korunur, çünkü bazı uygulamalar hala SEFDSTRUCT kodunu kullanmaya/kullanmaya ihtiyaç duyar.

EIP-6046 (kullanımdan kaldırıldı): SEFDESTRUCT'ı DEVRE DIŞI BIRAK ile değiştirin. Depolama anahtarını silmemek için SEFDESTRUCT'ı değiştirin ve devre dışı bırakmayı belirtmek için nonce hesabında özel bir değer kullanın

Sebep: Yukarıdakiyle aynı, Verkle ağaçları ile hesaplar farklı şekilde düzenlenecektir: hesap özellikleri (depolama dahil) ayrı anahtarlara sahip olacaktır, ancak çapraz geçiş yapmak ve kullanılan tüm anahtarları bulmak imkansız olacaktır. Daha önce SELFDESTRUCT kodlarını manipüle etmek, hesap durumunda kapsamlı değişiklikler gerektirdi ve bu da Verkle ağaçlarında SEFDESTRUCT kullanmaya devam etmeyi çok zorlaştırdı.

Değiştirmek:

EIP-2681 tarafından getirilen kuralları, normal olmayan artışların 2^64-1 yerine 2^64-2 ile sınırlandırılacağı şekilde değiştirin;

SEFDESTRUCT şu şekilde değiştirildi:

Herhangi bir depolama anahtarını silmeyin ve hesabı yerinde bırakmayın;

Hesap bakiyesini hedefe aktarın ve hesap bakiyesini 0 olarak ayarlayın.

nonce hesabını 2^64-1 olarak ayarlayın.

EIP-3529'dan beri geri ödeme yok;

EIP-2929'un ilgili SEFDESTRUCT kuralı değişmeden kalır.

önemi:

Bu teklif, SEFDESTRUCT'u doğrudan silen diğer davranışlardan daha fazla esnekliğe sahiptir.

EIP-6190 (kullanımdan kaldırıldı): Verkle ile uyumlu SEFDESTRUCT'ı yalnızca sınırlı sayıda durum değişikliğine neden olacak şekilde değiştirin

Sebep: Yukarıdakiyle aynı, Verkle ağaçları ile hesaplar farklı şekilde düzenlenecektir: hesap özellikleri (depolama dahil) ayrı anahtarlara sahip olacaktır, ancak çapraz geçiş yapmak ve kullanılan tüm anahtarları bulmak imkansız olacaktır. Daha önce SELFDESTRUCT kodlarını manipüle etmek, hesap durumunda kapsamlı değişiklikler gerektirdi ve bu da Verkle ağaçlarında SEFDESTRUCT kullanmaya devam etmeyi çok zorlaştırdı.

Değişiklik: İşlemin sonunda sözleşmeyi yok etmek yerine, onu çağıran işlemin sonunda aşağıdakiler gerçekleşir:

Sözleşme kodu 0x1 olarak ayarlanır ve rastgele sayı 2^64-1 olarak ayarlanır.

Sözleşmenin 0. slotu, sözleşme CREATE opcode (keccak256(contractAddress, nonce)) kullandığında yayınlanacak adrese ayarlanır. Rastgele sayı her zaman 2^64-1'dir.

Çağrı bir veya daha fazla takma ad sözleşmesi tarafından yönlendirildikten sonra sözleşme kendi kendini imha ederse, takma ad sözleşmesinin 0. depolama alanını 2. adımda hesaplanan adrese ayarlayın;

Sözleşme bakiyesinin tamamı yığının en üstündeki adrese aktarılacak;

Yığının üstü açılır.

önemi:

SEFDESTRUCT'ın daha sonra minimum değişikliklerle Verkle ağaçlarını oluşturmasına izin verecek şekilde tasarlanmıştır;

Uygulanan EIP-2929 ile gaz maliyeti arttı.

Ardından, gaz tasarrufu sağlayan ve gelecekteki depolama tasarımının önünü açan EIP1153 var.

EIP1153X

Özet: Geçici mağaza işlem kodları, depolarla aynı şekilde davranan ancak her işlemden sonra atılan durumu işlemek için işlem kodları ekleyin.

sebep:

Ethereum'da bir işlem çalıştırmak, her biri bir CALL (veya benzeri) talimatı tarafından oluşturulan birden çok iç içe yürütme çerçevesi oluşturabilir. Sözleşmeler aynı işlemde yeniden girilebilir, bu durumda birden fazla çerçeve bir sözleşmeye aittir.

Şu anda, bu çerçeveler iki şekilde iletişim kurabilir: CALL talimatları aracılığıyla giriş/çıkış ve mağaza güncellemeleri aracılığıyla. Güvenilmeyen başka bir sözleşmeye ait bir ara çerçeve varsa, G/Ç yoluyla iletişim güvenli değildir.

Reentrancylock'u örnek olarak alırsak, kilidin durumunu iletmek için ara çerçevelere güvenemez: Depolama yoluyla SSTORE iletişimi SLOAD pahalıdır ve geçici depolama, çerçeveler arası iletişim sorununa özel ve gaz açısından verimli bir çözümdür.

Değiştirildi: EVM'ye TLOAD (0xb3) ve TSTORE (0xb4) olmak üzere iki yeni işlem kodu eklendi.

Geçici depolama, kendisine sahip olan sözleşmeye özeldir ve kalıcı depolama gibi, geçici depolamaya yalnızca sahip olan sözleşme çerçevesi erişebilir. Depolamaya erişirken, tüm çerçeveler aynı kısa ömürlü depolamaya kalıcı depolamayla aynı şekilde, ancak bellekten farklı olarak erişir.

Potansiyel kullanım durumları:

yeniden giriş kilidi;

Zincir üzerinde hesaplanabilir CREATE2 adresleri: yapıcı parametreleri, başlatma kodu karmasının bir parçası olarak geçirilmek yerine fabrika sözleşmesinden okunur;

Tek işlem EIP-20 onayı, örneğin #temporaryApprove(addressspender, uint256 miktarı);

Transfer ücreti sözleşmesi: işlemler sırasında transferlerin kilidini açmak için token sözleşmesine bir ücret ödeyin;

"Till" modu: Kullanıcının geri aramanın bir parçası olarak tüm işlemleri gerçekleştirmesine izin verir ve sonunda "till"in dengelenip dengelenmediğini kontrol eder;

Proxy çağrısı meta verileri: Sabit proxy oluşturucu parametrelerinin değerleri gibi çağrı verilerini kullanmadan sözleşmeleri uygulamak için ek meta verileri iletin.

önemi:

Gazdan tasarruf edin ve daha basit gaz faturalandırma kurallarına sahip olun;

Çerçeveler arası iletişim sorununu çözün;

mevcut işlemlerin anlamını değiştirmez;

Kullanımdan sonra depolama yuvasını temizlemeye gerek yoktur;

Gelecekteki depolama tasarımlarının (Verkle ağaçları gibi) anlık depolama için ters ibraz konusunu dikkate almasına gerek yoktur.

Ardından, rehin havuzunun güven varsayımını azaltabilecek 4788 var.

EIP4788：X

Özet: EVM'deki işaret bloğu kökleri.

Güncelleme: 15.06.23 tarihindeki geliştirici toplantısında, geliştiriciler staker deneyimini iyileştirmek için kod değişiklikleri yapmayı teklif ettiler, bu EIP, DApp geliştiricilerinin güveni için EVM dahili zincir durum bilgilerini içeren beacon chain bloğunun kökünü ifşa edecek. erişim en aza indirildi.

Değiştirildi: Karşılık gelen yürütme yükü başlığındaki her işaret zinciri bloğunun karma köklerini gönderin, bu kökleri yürütme durumundaki bir sözleşmede saklayın ve bu sözleşmeyi okumak için yeni bir işlem kodu ekleyin.

Önem: Bu, farklı protokoller oluşturabilen yürütme katmanındaki (EL) sözleşme katmanı (CL) durum kökünün verilerini ifşa edebilmesi için Ethereum Sanal Makinesini (EVM) değiştirmeyi öneren bir kod değiştirme önerisidir. Ethereum ağındaki uygulamalar Programlar arasındaki iletişim daha verimli ve güvenlidir. Staking havuzları, köprü oluşturma ve protokolleri yeniden paylaşma için daha güvenilir tasarımlara izin verin.

Son olarak, verimli yeni bir bellek kopyalama işlem kodu sağlayan, ancak şu anda test bant genişliği nedeniyle bir yükseltmeye geçici olarak dahil edilme durumunda olan 5656 var.

EIP5656X

Giriş: MCOPY- bellek kopyalama talimatı.

GÜNCELLEME: 09.06.23 tarihinde, geliştirme ekibi, güvenlik sorununu çözerken, yükseltmeye eklemek için gereken uygulama + test bant genişliği konusunda endişe duydukları, ancak sonunda EIP'yi dahil etmeyi kabul ettikleri için MCOPY konusunda başlangıçta bölünmüş olduklarını belirtti. , Ancak, geliştirici test sırasında veya istemci tarafında kapasite sorunlarıyla karşılaşırsa, kaldırma işlemi dikkate alınacaktır. Bu nedenle, MCOPY, Cancun yükseltmesine geçici olarak dahil edilme durumundadır.

Değiştirildi: Bellek bölgelerini kopyalamak için verimli bir EVM talimatı sağlandı.

Önem: Bellek kopyalama temel bir işlemdir, ancak bunu EVM'de uygulamanın bir maliyeti vardır.

MCOPY komutunun mevcudiyetiyle, kod sözcükleri ve cümleler daha doğru bir şekilde kopyalanabilir, bu da bellek kopyalama performansını yaklaşık %10,5 oranında artırır, bu da hesaplama açısından yoğun çeşitli işlemler için çok yararlıdır;

Derleyicilerin daha verimli ve daha küçük bayt kodu oluşturması da yararlı olacaktır;

Kimlik ön derlemesi için belirli bir miktar gaz maliyetinden tasarruf sağlayabilir, ancak bu kısmın gerçekleştirilmesini fiilen teşvik edemez.

Aday listesi EIP

15 Haziran 23 tarihinde, geliştirici mutabakat toplantısında Deneb'e hangi CL merkezli EIP'lerin dahil edileceği tartışıldı ve bunlara EIP6988, EIP7044 ve EIP7045'in eklenmesi önerildi.

EIP6988：X

Özet: Kesikli doğrulayıcıların blok teklifçileri olarak seçilmesini engeller.

Önem: İhlal eden düğümler için artan cezalar, DVT'ye fayda sağlayacaktır.

EIP7044：X

Özet: İmzalı doğrulayıcı çıkışlarının kalıcı olarak geçerli olmasını sağlamak.

Önem: Staker deneyimini bir dereceye kadar iyileştirebilir.

EIP7045：X

Özet: Tasdik yuvası dahil etme aralığını bir çağlık hareketli bir pencereden iki çağa genişletin.

Önem: Ağ güvenliğini geliştirin.

EIP analizini silin

29, 23 Nisan'daki 160. Ethereum ACDE toplantısında, EVMMAX ve EOF'un bu yükseltmeden çıkarılacağı doğrulandı ve sonraki günlük yükseltmelerde EOF ile ilgili değişiklikler getirilebilir.

EVMMAXEIP'ler:

Özet: EVMMAX, Ethereum'daki aritmetik işlemlere ve imza şemalarına daha fazla esneklik getirmeyi amaçlamaktadır. Şu anda, biri EOF'lu ve biri EOF'siz olmak üzere iki EVMMAX teklifi var.

EIP6601: EVM Modüler Aritmetik Uzantılar (EVMMAX)

Değişiklik: EIP5843'ün yinelemesidir, EIP5843'ten farkı şudur:

6601, modülü, önceden hesaplanan Montgomery parametresini, kullanılacak değerlerin sayısını depolayan yeni bir EOF bölüm tipi sunar (çalışma zamanı yapılandırılabilir modülü hala desteklenmektedir);

6601, EVM<->EVMMAX belleği arasında değerleri taşımak için yeni yükleme/depolama işlem kodlarıyla EVMMAX değerleri için ayrı bir bellek alanı kullanır;

6601, 4096 bit'e kadar modüllerdeki işlemleri destekler (EIP'de belirtilen geçici sınır).

Önem: EIP-5843, Ethereum Sanal Makinesi için verimli modüler toplama, çıkarma ve çarpma işlemlerini sunar ve EIP-6601, bir kurulum bölümü, ayrı bir bellek alanı ve modüler aritmetik işlemler için yeni işlem kodları sunarak bunun üzerine inşa eder Daha iyi organizasyon ve esneklik sağlar daha büyük modülleri desteklerken ve EVM performansını artırırken.

BLS12-381 dahil olmak üzere çeşitli eğrilerde eliptik eğri aritmetik işlemleri sağlayan bir EVM sözleşmesi olarak;

MULMOD, 256 bit'e kadar olan değerlerde çalışmanın gaz maliyetini mevcut ADDMOD işlem kodlarına kıyasla %90-95 oranında azaltır;

Modexp ön derlemesinin EVM sözleşmeleri olarak uygulanmasına izin verir;

Cebirsel karma işlevlerde (MiMC/Poseidon gibi) ve EVM'de ZKP doğrulamasının maliyetini önemli ölçüde azaltın.

EIP6690：

Değişiklik: EIP-6990, EOF'ye dayanmadan EVM'ye optimize edilmiş modüler aritmetik işlemleri tanıtmak için EIP-6601'den uyarlanmış bir tekliftir. EIP-6601, bağımlılık olarak EIP-4750 ve EIP-3670 gerektirirken, EIP-6990 daha bağımsız bir çözüm sunar. EOF bağımlılığını ortadan kaldırarak daha basitleştirilmiş bir yaklaşım sağlar.

Önem: 4096 bit'e kadar tek modüllerde optimize edilmiş modüler aritmetik işlemler gerçekleştirmek için EIP-6601'in temel işlevselliğini korur; bu sadeleştirme, EIP-6601 ile ilişkili faydaları sağlamaya devam ederken daha verimli uygulama ve benimsemeye izin verir.

EOF değişiklikleri：

Giriş: EOF, yeni sözleşme standartlarını ve bazı yeni işlem kodlarını tanıtan bir EVM yükseltmesidir.Geleneksel EVM bayt kodu (bayt kodu), yapılandırılmamış bir talimat bayt kodu dizisidir. EOF, yapılandırılmış bayt kodunu uygulayan bir konteyner kavramını sunar. Kapsayıcı, bayt kodunu yapılandırmak için bir başlık ve birkaç bölümden oluşur. Yükseltmeden sonra EVM, sürüm kontrolü gerçekleştirebilecek ve aynı anda birden çok sözleşme kuralı grubunu çalıştırabilecektir.

EIP663：

Özet: Sınırsız SWAP ve DUP talimatları

Önem: Yığın derinliğini 16 öğeden 256 öğeye çıkararak SWAP ve DUP'tan farklı olan iki yeni talimat sunarak: SWAPN ve DUPN

EIP3540：

Giriiş:

Geçmişte, zincirde dağıtılan EVM bayt kodu önceden tanımlanmış bir yapıya sahip değildi ve kod yalnızca istemcide çalıştırılmadan önce doğrulanıyordu.Bu yalnızca dolaylı bir maliyet değil, aynı zamanda geliştiricilerin yeni işlevler sunmasını da engelliyor. Veya eski işlevleri kullanımdan kaldırın.

Bu EIP, EVM için genişletilebilen ve sürüm kontrollü bir kapsayıcı sunar ve EOF sözleşmesinin formatını bildirir. EOF formatına uyan makul olmayan Sözleşmelerin dağıtılmasını önleyebilir.Bu değişiklik, mevcut EVM talimatlarını devre dışı bırakmaya veya gelecekte büyük ölçekli işlevleri (hesap soyutlama gibi) sunmaya yardımcı olacak EOF sürüm kontrolünü uygular.

önemi:

Sürüm kontrolü, gelecekte yeni işlevlerin tanıtılmasına veya kullanımdan kaldırılmasına (hesap soyutlamanın getirilmesi gibi) elverişlidir;

Sözleşme kodunun ve verilerin ayrılması, L2 doğrulaması (op) için faydalıdır ve L2 doğrulayıcıların gas maliyetini düşürür.Aynı zamanda, sözleşme kodu ve verilerin ayrılması da zincirdeki veri analiz araçları için daha uygundur.

EIP3670：

Giriş: EIP-3540'a göre amaç, EOF sözleşmesinin kodunun formata uygun ve geçerli olmasını sağlamaktır.Formata uymayan sözleşmeler için dağıtımı önlenecek ve Legacybytecode etkilenmeyecektir.

Önem: 3540 tarafından tanıtılan kapsayıcıya bağlı olarak, EIP-3670, EOF sözleşmesindeki kodun geçerli olmasını sağlar veya konuşlandırılmasını engeller. Bu, tanımlanmamış işlem kodlarının, eklenmesi gereken EOF sürümlerinin sayısını azaltma avantajına sahip olan EOF sözleşmelerinde konuşlandırılamayacağı anlamına gelir.

EIP4200:

Giriiş:

EOF'ye özgü ilk işlem kodları tanıtıldı: hedefleri imzalanmış anlık değerler olarak kodlayan RJUMP, RJUMPI ve RJUMPV. Derleyiciler, mevcut JUMP ve JUMPI işlem kodları için jumpdestanalysis yapmak için gereken çalışma süresini ortadan kaldırdıkları için JUMP'u dağıtmanın ve yürütmenin gaz maliyetini optimize etmek için bu yeni JUMP işlem kodlarını kullanabilir. Bu EIP, dinamik atlamanın bir tamamlayıcısıdır.

Geleneksel JUMP işlemiyle karşılaştırıldığında, fark, RJUMP gibi işlemlerin belirli bir ofset konumu belirtmemesi, ancak göreli bir ofset konumu belirtmesidir (dinamik atlamalardan -> statik atlamalardan), çünkü statik atlamalar genellikle yeterlidir.

Önem: ağı optimize edin ve maliyetleri azaltın.

EIP4750：

4200'ün işlevini bir adım öteye taşıyın: CALLF ve RETF'in iki yeni işlem kodunun tanıtılmasıyla, RJUMP, RJUMPI ve RJUMPV ile değiştirilemeyen durum için alternatif bir çözüm gerçekleştirilir, böylece EOF sözleşmesinde JUMPDEST'e artık gerek kalmaz, yani, Bu nedenle dinamik atlama devre dışıdır.

Önem: Kodu birkaç parçaya bölerek kodu optimize edin.

EIP5450：

Arka plan: Arka plan hala Ethereum sözleşmesinin konuşlandırıldığında kontrol edilmediği ve çalışırken sadece bir dizi kontrol yapıldığı, yığının taşıp taşmadığı (üst limit 1024'tür), gas'ın yeterli olup olmadığı ve yakında.

İçerik: EOF sözleşmeleri için başka bir geçerlilik kontrolü eklendi, bu sefer yığının etrafında. Bu EIP, EOF sözleşme dağıtımlarının yığın taşmalarına/taşmalarına yol açabileceği durumları önler. Bu şekilde müşteriler, EOF sözleşmelerinin yürütülmesi sırasında yaptıkları geçerlilik kontrollerinin sayısını azaltabilir.

Önem: Büyük bir gelişme, yürütme sırasında gerçekleşen bu kontrolleri mümkün olduğunca az yapmak ve sözleşme dağıtıldığında daha fazla kontrol yapmaktır.

26 Mayıs'taki geliştirici toplantısı güncellemesinden sonra, EIP4844 ile ilgili işlem türünün SSZ'den RLP'ye değiştirilmesi, Cancun'daki iki SSZEIP'ye artık ihtiyaç olmadığı anlamına geliyordu, bu nedenle EIPs6475 ve 6493, yükseltme için Cancun'dan taşındı

EIP6475X

Giriş: EIP4844'e eşlik eden teklif. Proto-danksharding, diğer işlem türleri tarafından kullanılan RLP kodlaması yerine SSZ kodlamasını kullanan yeni bir işlem türü sunar.

GÜNCELLEME: 161. Ethereum Yürütme Katmanı Çekirdek Geliştiriciler Toplantısı sırasında, EIP4844 için SSZ serileştirme formatı hakkındaki tartışmalar, başlangıçta geliştiricilerin SSZ formatının erken yinelemelerini blob işlemleri yoluyla EL'e sunma eğiliminde olduğunu ve sonunda geliştiricilerin tüm işlem türünü getirmeyi planladığını ortaya çıkardı. RLP'den SSZ'ye yükseltildi, ancak geliştiriciler, belirsiz yolu ve kesinlikle Cancun yükseltmesinde uygulayamaması nedeniyle SSZ'yi EIP-4844'ten kaldırmayı değerlendiriyorlar. Pek çok tartışmadan sonra, geliştiriciler SSZ'yi EIP-4844'ün EL uygulamasından kaldırmayı kabul ettiler, ancak henüz EIP6475'i kaldırmadılar. 26 Mayıs güncellemesinden sonra, SSZ->RLP değişikliği, Cancun'daki iki SSZEIP'ye artık ihtiyaç olmadığı anlamına gelecektir: bu nedenle EIP'ler 6475 ve 6493, yükseltmeler için Cancun'dan taşınacaktır.

EIP6493X

Giriş: SSZ işlem imza şeması. Bu EIP, Basit Serileştirme (SSZ) ile kodlanmış işlemler için bir imza şeması tanımlar ve düğümlerin CL'de SSZ biçiminde biçimlendirilmiş ancak EL'de farklı şekilde kodlanmış blob işlem türlerini nasıl işlemesi gerektiğini ele alacaktır. Bu EIP, katmanlar arası tutarlılık için Ethereum serileştirme biçimindeki bir güncellemenin parçasıdır;

Arka plan: SSZ değişiklikleri

Giriş: SimpleSerialiZe, işaret zincirinde kullanılan serileştirme yöntemidir.

SSZchanges ayrıca üç destekleyici teklif daha içeriyor, bu sefer sadece 6465 tanıtıldı.

EIP6465: Mevcut Merkle-PatriciaTrie (MPT) taahhütlerinin Basit Serileştirme (SSZ) geri çekme işlemlerine geçiş sürecini tanımlayan SSZ geri çekme kökü;

EIP6404/ EIP6466：

Her ikisi de mevcut Merkle-PatriciaTrie (MPT) taahhütlerini Basit Serileştirmeye (SSZ) geçirmek için bir süreç tanımlar.

EIP-6404— SSZ işlem kökü

EIP-6466— SSZ Makbuz Tabanı

Tim Beiko, 26 Mayıs'taki çekirdek geliştirici toplantısında, Cancun'un kapsamının genişletilmesiyle ilgili gelecekteki konuşmaların şu beş EIP ile sınırlandırılmasını önerdi: EIP5920, 5656, 7069, 4788 ve 2537 ve sonraki teklifler bu kapsamda üretilecek. Sonraki EIP5656 ve EIP4788, resmi yükseltme teklifleri olarak onaylandı ve 5920, 7069 ve 2537 kaldırıldı. Bunların arasında EIP5920, geliştiricilerin ETH aktarma yolunun potansiyel yan etkileri ve ayrıca tamamlanmamış muhakeme, test etme, ve güvenlik çalışması.Yükseltmeden kaldırıldı.

EIP5920：X

Giriş: ödeme işlem kodu. Ether'i işlevlerinden herhangi birini çağırmadan bir adrese gönderen Ethereum transferleri için yeni işlem kodu PAY'i sunar.

Sebep: Şu anda, bir adrese eter göndermek, kullanıcının bu adreste birkaç sorunu olan bir işlevi çağırmasını gerektiriyor:

İlk olarak, alıcı göndericiyi geri arayabileceğinden yeniden giriş saldırıları için bir vektör açar;

İkincisi, bir DoS vektörü açar, bu nedenle ana işlev, alıcının gazının bitebileceğinin veya geri arama yapılabileceğinin farkında olmalıdır;

Son olarak, CALL işlem kodu, basit eter transferleri için gereksiz yere pahalıdır, çünkü belleğin ve yığının genişletilmesini, kod ve bellek dahil olmak üzere alıcının tüm verilerinin yüklenmesini ve son olarak bir arama gerçekleştirmesini, muhtemelen diğer kasıtsız işlemleri gerçekleştirmesini gerektirir.

Değiştirmek:

Yeni bir işlem kodu kullanıma sunuldu: (PAY)PAY_OPCODE, burada:

Yığından iki değer çıkar: addrthenval.

Wei'yi yürütme adresinden val adresine aktarın. Eğer adres sıfır adres ise, valwei yürütme adresinden programlanacaktır.

Potansiyel tuzaklar: Mevcut sözleşmeler, cüzdanlarının gerçek bakiyesinden bağımsız olarak kullanılacaktır, çünkü bir adrese çağırmadan ether göndermek zaten mümkün.

Önemi: gazdan tasarruf edin.

GÜNCELLEME: 09.06.23 tarihinde, ETH'nin aktarılma biçiminde var olabilecek olası yan etkiler ve teklifi geçmek için gereken muhakeme, test ve güvenlik çalışmasıyla ilgili endişeler nedeniyle PAY yükseltmeden kaldırıldı.

EIP7069X

Giriş: Değiştirilmiş CALL komutu

Değişiklik: Semantiği basitleştirme etkisine sahip üç yeni çağrı talimatı CALL2, DELEGATECALL2 ve STATICCALL2 eklendi. Gaz gözlemlenebilirliğini yeni direktiften çıkarmayı ve yeniden fiyatlandırmadan etkilenmeyen yeni bir sözleşme sınıfına kapı açmayı hedefliyor.

arka plan:

63/64. kural: arama derinliğini sınırlayın ve arayan geri döndükten sonra durum değişikliği yapmak için arayan kişinin kalan gazı olduğundan emin olun;

63/64 sayılı kurallar getirilmeden önce, arayanın kullanabileceği gazın bir şekilde doğru bir şekilde hesaplanması gerekiyordu. Solidity, makul bir gas değeri ayarlamak için aramayı kendisi yürütmenin arayan tarafında maliyetini tahmin etmeye çalışan karmaşık bir kurala sahiptir.

63/64 kuralı şu anda tanıtıldı:

Çağrı derinliği incelemesi kaldırıldı;

Çağrılan davranışı gerçekleştirmeden önce en az 5000 gaz ayırdığınızdan emin olun;

Çağrılan davranış için en az 2300 gazın mevcut olduğundan emin olun.

Teşvik kuralları: iyi bilinen 2300 sübvansiyonu gibi, bir sözleşme başka bir sözleşmeyi çağırdığında, çağrılan sözleşme çok sınırlı işlemleri gerçekleştirmek için 2300gas alır (küçük bir hesaplama yapmak ve bir günlük oluşturmak için yeterli, ancak bir depolama alanını doldurmak için yeterli değil) ), sabit bir gaz miktarı belirlediği için, gaz fiyatı ayarlanabildiği sürece, insanların bu gazın ne tür bir hesaplamayı destekleyebileceğini belirlemesinin bir yolu yoktur.

Önem: Gelecekte EOF'nin tanıtılmasının önünü açın ve büyük sözleşmelerin yürütülmesini kolaylaştırın.

Gaz isteğe bağlılığını kaldırın: yeni komut, gaz limitinin belirlenmesine izin vermez, ancak "63/64 kuralına" dayanır (esas olarak EIP-150'de çok sayıda IO operasyonu için kullanılan ve belirli operasyonların gaz tüketimi) Gazın sınırlandırılması, bu önemli iyileştirme "sübvansiyon" ile ilgili kuralları basitleştirmek içindir, değer gönderilip gönderilmediğine bakılmaksızın, arayanın gazla ilgili hesaplamalar yapmasına gerek yoktur;

Yeni teklifin sunulmasıyla birlikte kullanıcılar, işlemde daha fazla gaz göndererek (elbette blok gaz limitine tabi olarak) Gaz Bitti hatasını her zaman aşabilirler.

Çağrılarına yalnızca sınırlı miktarda gaz gönderen bazı sözleşmeler, daha önce depolama maliyetlerini yükseltirken (örneğin, belirli işlem kodları için EIP-1884 artırılmış gaz) yeni maliyet mekanizması tarafından bozuldu. Daha önce bazı sözleşmelerde, harcayabilecekleri gaz miktarını kalıcı olarak sınırlayan bir benzin üst sınırı vardı, bunu alt aramalarına gönderseler bile, ne kadar fazladan benzin gönderirlerse göndersinler işe yaramıyordu, çünkü arama sınırlayacaktı. gönderilen miktar

EOF'nin tanıtılmasının önünü açın: EVM Nesne Formatı (EOF) tanıtıldıktan sonra, eski arama talimatları EOF sözleşmesinde reddedilebilir ve gaz fiyatı değişikliklerinden büyük ölçüde etkilenmezler. Bu işlemler gaz gözlemlenebilirliğini ortadan kaldırmak için gerekli olduğundan, EOF mevcut talimatların yerine bunları gerektirecektir;

Daha Fazla Kolay Durum Dönüş Kodu: Daha ayrıntılı durum kodları döndüren kolaylık işlevleri sunulmuştur: başarı (0), geri alma (1), başarısızlık (2) ve gelecekte genişletilebilir.

EIP2537：X

Özet: BLS12-381 eğri manipülasyonunun bir ön derlemesi.

DEĞİŞTİRİLMİŞ: BLS imza doğrulaması ve SNARK doğrulaması gibi işlemleri verimli bir şekilde gerçekleştirmek için gerekli kümeye ön derlemeler olarak BLS12-381 eğrisine işlemler eklendi.

Önem: Ethereum, daha güvenli kriptografik kanıtlar oluşturabilir ve işaret zinciri ile daha iyi birlikte çalışabilirlik sağlayabilir.

PR3175'ten bahsedildi, ancak hiçbir zaman kısa listeye alınmadı, daha fazla tartışma yok

PR3175：X

Özet: Bu teklif, cezalandırılan doğrulayıcıların kuyruktan çıkarıldığında blok teklif etmesini engelleyecektir. Doğrulayıcıların %50'den fazlası kötü niyetli davranış nedeniyle cezalandırılırsa, bu doğrulayıcılar ağdan zorla kaldırılırken yine de bloklar önerebilir. Geliştiriciler, bu mantığı değiştirmenin, "yüksek hata modlarına" karşı koruma sağlayan nispeten küçük bir CL katmanı değişikliği olduğunu söylüyor.

4 Mayıs'taki 108. Ethereum Çekirdek Geliştiriciler Konsensüs Toplantısına göre, PR3175, EIP olarak biçimlendirilme sürecindedir ve EIP-6987 olarak değiştirilecektir, yani güvenlik nedenleriyle, kesikli doğrulama düğümlerinin seçilmesini önlemek için EIP-6987 olarak değiştirilecektir. öneren blok

gelecek

Yukarıdaki bilgilere dayanarak, aşağıdaki sonuçlara ulaştık:

1. Cancun yükseltmesinin ana hedefleri, öncelik sırasına göre, genişletme, güvenlik, gaz tasarrufu ve birlikte çalışabilirliktir:

Hiç şüphe yok ki genişleme birinci önceliktir (4844);

Güvenlik ve gaz tasarrufu ikinci önceliktir (6780, 1153, 5656 ve 7045), belirli bir geliştirici deneyimi dikkate alınırken;

Üçüncüsü, dapp'ler (4788, 7044 ve 6988) arasındaki bağlantı, iletişim ve birlikte çalışabilirliği optimize etmek gibi birlikte çalışabilirlik;

Beklenen veriler: Testnet 4844, opsiderollup maliyetini %50 azaltabilir; EigenLayer ve Celestia'nın teknik çözümleri çok fazla ifşa etmemiştir ve verileri değerlendirilemez; Ethstorage, DA'nın maliyetinin orijinalin %5'ine düşeceğini tahmin ediyor Topia'nın maliyeti 100~1000 kat düşürmesi bekleniyor.

2. Cancun'un Danksharding'e yükseltildiği sonraki 2 ila 5 yıl, DA katman projeleri için altın geliştirme dönemidir

Katman 2'nin güvenlik üst sınırı, benimsediği DA katmanına bağlıdır.Proto-Danksharding, daha ucuz durum veri depolaması yoluyla depolama protokollerine, modüler protokollere ve L1 depolama genişletme ağlarına fayda sağlayacaktır.

İlk olarak Danksharding, Ethereum durum makinesinin özüne geri döner. V God, Ethereum konsensüs protokolünün amacının tüm tarihsel verilerin kalıcı olarak depolanmasını garanti etmek olmadığından bahsetti. Bunun yerine amaç, oldukça güvenli bir gerçek zamanlı bülten panosu sağlamak ve daha uzun süreli depolama için diğer merkezi olmayan protokollere yer bırakmaktır (Ethereum konsensüs protokolünün amacı, tüm geçmiş verilerin sonsuza kadar saklanmasını garanti etmek değildir. Bunun yerine, amaç yüksek düzeyde güvenli bir gerçek zamanlı duyuru panosu sağlamak ve diğer merkezi olmayan protokollerin daha uzun süreli depolama yapması için yer bırakmaktır. );

İkincisi, Danksharding, DA'nın maliyetini düşürür, ancak gerçek iniş süresi ve veri kullanılabilirliği sorunlarının da çözülmesi gerekir.

DA maliyeti azaltma: Bu güncellemeden önce, toplamadan Ethereum ana zincirine verileri serbest bırakmak için calldata'yı çağırmak gerekliydi ve bu kodu çağırmak için gas ücreti çok pahalıydı, bu da katman2'deki en büyük harcamaydı. toparlamalar Eşsiz ek veri alanı, depolama maliyetlerini büyük ölçüde azaltacak ve böylece DA maliyetlerini azaltacaktır.

Gerçek iniş süresi uzundur ve iyileştirilebilecek TPS ve azaltılabilecek gaz hala sınırlıdır, bu nedenle gelecekte DA katman projelerinin sürekli gelişimi için iyidir:

Polynya'nın danksharding ile ilgili iablesecurity data sharding makalesinde, uygulamanın 2-5 yıl süreceğini gösteriyor;

Yere inse bile artırabileceği TPS ve azaltabileceği gaz seviyesi sınırlıdır:

EIP4844 şu anda 6 blob'u desteklemektedir ve gelecekteki genişleme sorunu yalnızca Danksharding tarafından çözülebilir;

Mevcut Ethereum blok alanı yaklaşık 200 KB'dir. Danksharding'den sonra, şartnamede planlanan boyut 32 megabayt, yani yaklaşık 100 kat iyileştirme. Şu anda, Ethereum'un TPS'si yaklaşık 15'tir ve idealleştirilmiş bir durumda, 100 kat artırıldıktan sonra yaklaşık 1500 olacaktır, bu büyüklük açısından büyük bir gelişme değildir.

Bu nedenle, uzun uygulama süresi + sınırlı fiili değişiklikler, DA katmanı projelerine fayda sağlayacaktır. Celestia ve Eigenda gibi bazı DA projeleri, daha ucuz maliyetler ve daha hızlı TPS ile Danksharding ile rekabet edebilir. ETHstoragetopia gibi yeni DA projeleri de önceki pazar boşluğunu doldurabilir.

Veri depolama ve veri kullanılabilirliği sorunları gibi teknik sorunların da ele alınması gerekir:

DA'nın iki ana maliyeti vardır, biri ağ bant genişliği maliyeti, diğeri depolama maliyeti ve 4844'ün kendisi depolama problemini ve blok zincirinin bant genişliği problemini çözmez.

Blob, yaklaşık 3 hafta boyunca Ethereum mutabakat katmanında depolanacak ve ardından silinecektir. Tüm geçmiş kayıtları saklamak ve tüm verileri kullanılabilir kılmak istiyorsanız, mevcut çözümler şunları içerir: Dapp'in kendisi, kendisiyle ilgili verileri depolar ve Ethereum portal ağı (şu anda geliştirme aşamasında) geliştirme aşamasında) veya blok gezginleri, BitTorrent'teki geçmiş veriler veya bireysel kullanıcılar tarafından kendiliğinden depolama gibi üçüncü taraf protokolleri.

Bu nedenle Proto-Danksharding, depolama protokollerine, modüler protokollere ve L1 depolama genişletme ağlarına fayda sağlayacaktır:

Geçmiş verileri çağırma talebi, merkezi olmayan depolama protokolleri veya üçüncü taraf indeks protokolleri için yeni bir geliştirme kanalına yol açacaktır;

Müteakip modüler anlaşmalar, işlemleri yüksek hızlı Toplama yoluyla gerçekleştirebilir, güvenli bir yerleşim katmanı yerleşimden ve düşük maliyetli ve yüksek kapasiteli bir veri kullanılabilirliği katmanı garanti etmekten sorumludur;

Daha düşük bir depolama maliyetiyle programlanabilir depolama için ikinci katman bir çözüm sağlayabilen Ethstorage gibi L1 depolama genişletme ağı için iyidir.

3. Cancun yükseltmesi, L2 çeşitliliği, L3, RAAS ve veri kullanılabilirliği ve diğer parçalar için iyidir

L2 parça analizi:

Top Layer 2, ArbitrumOrbit, OPStack, Polygon2.0, FractalScaling (StarkWare altında) ve HyperChain (zkSync altında) gibi beş proje faydalanacak. Blob tarafından getirilen depolama ücreti indirimi, katman 2'nin gelişimini sınırlayan önceki maliyet ve ölçeklenebilirlik sorunları serisini büyük ölçüde iyileştirecek ve veri akışını büyük ölçüde artıracaktır. fonksiyonlar, üst düzey Özelleştirilmiş çok zincirli eşzamanlı L3 ekolojisi;

İkinci katman Katman 2 ile ana akım Katman 2 arasındaki işletme maliyetleri farkı azaltılarak Aztek, Metis, Boba, ZKspace, katman2.finance vb. gibi bazı küçük projelere geliştirme için daha fazla fırsat tanınacaktır;

Modüler blockchain projelerinin gerçek ihtiyaçları hala doğrulanacak olsa da, Starkware'in Cario'su, Move serisi dilleri, Wasm destekli C, c++, C# ve Go serisi dilleri gibi daha birçok web2'yi tanıtabilen çeşitli programlama dilleri hala mümkün. geliştiriciler.

Raas parça analizi:

Raas'ın avantajı, yüksek derecede özelleştirme, özelleştirilmiş gereksinimler > saf maliyet ve verimlilikte yatmaktadır, bu nedenle maliyet azaltma, özelleştirilmiş Toplama'nın büyük bir avantajıdır.

Ancak RAAS iziyle ilgili sorun, OverHype olabileceği ve hatta RAAS izinin kendisi hakkında şüpheler olması. İlk 5 katman 2'den gelen rekabet ve çeşitli yeni DA'ların ortaya çıkması karşısında, yeni projelerin bir yol oluşturup oluşturamayacağına bir soru işareti koymalıyız.

Her şeyden önce, ana katman2 uygulama zincirinin konuşlandırılmasının avantajı, ağ çerçevesinin bütünlüğünde ve zincirler arası ekolojinin güvenliğinde yatmaktadır ve RAAS'ın avantajı, özelleştirmesinde ve özgürlüğünde yatmaktadır;

Ancak OP ve ZK serisinin RAAS teknik engelleri şu anda güçlü değil ve kısa vadede hala testnet aşamasındalar ve gerçek bir ürün etkileşimi yok.RAAS'ın fiili ilerlemesi, teknik formlar ve Gelecekte katman3'ün ekolojik avantajları, RAAS'a olan gerçek talep şüphelidir.

OP serisi: OP yığınının temel yükseltmesi +4844, maliyet ve verimlilikte bazı küçük iyileştirmeler getirmiş olsa da, iyileştirmelerin getirdiği çekicilik güçlü değil;

ZK serisi: Şu anda birçok önde gelen proje ZKEVM rotasını izliyor ve Ethereum ile uyumluluğa daha fazla dikkat ediyor, bu nedenle devre tasarımı belirli bir verimliliği feda edecek ve OP serisi kadar hedefli değil. Bununla birlikte, şu anda piyasada bulunan ZKRAAS'ın çoğu, zinciri çatallamak için hala önde gelen projeleri (ZkSync gibi) kullanıyor ve engeller hala güçlü değil.

Bu nedenle, kısa vadede, OPRAAS'ın katman3'e ulaşmasından önce hala biraz gelişme alanı vardır.Uzun vadede, ZKRAAS ve katman3 gelecekteki trend olabilir.

ZKRAAS, 4844'ten sonra daha büyük bir maliyet dezavantajına sahiptir ve OP'den çok daha fazla bilgi işlem gücü tüketir.L1'e yükleme maliyeti OP'den daha düşük olmasına rağmen, bu, prova işleminin maliyetine kıyasla sadece kovada bir düşüştür, OP'nin avantajı, kısa sürede hızlı bir şekilde bir ekoloji oluşturabilmesi ve katman3 topraklarına ulaşmadan önce hala geliştirme için yer olmasıdır;

Geleneksel DeFi uygulamaları ve NFT pazarları için toplama dönüşümü katı bir gereklilik değildir.Yalnızca yüksek verimlilik gerektiren ödeme uygulamaları veya oyunlar, toplama için daha güçlü bir talebe sahiptir. Gelecekte, defi projeleri l2'de olabilir, sosyal projeler l3'te veya zincir dışı olabilir ve son olarak temel veriler ve ilişkiler l2'de yer alabilir.Oyun projelerinin l3'e veya toplamaya gitmesi gerekir, ancak mevcut çoğu zincir oyunlar temelde Fonlardır ve jetonların harici olarak dolaşamaması geliştirme darboğazları getirdi, oyunların tüm zincirde ortaya çıkmasıyla birleştiğinde, l3'ün kendisinin ekolojik çekiciliği toplamanınkinden çok daha fazladır.

4. Cancun yükseltmesi, geliştirici ve kullanıcı deneyimini iyileştirir

Cancun güncellemesinin ikinci önemli önerisi olan SEFDESTRUCTremoval, Ethereum'un güvenliğini daha da artıracaktır.Aynı zamanda silme işleminden sonra oluşabilecek prosedürel hesap güncelleme sorunu için bu durumu iyileştirmek amacıyla yeni bir işlem kodu SETCODE hazırlanmıştır;

Cancun tarafından yükseltilen üçüncü teklif EIP1153, ilk olarak gaz tasarrufu yapabilen, ikinci olarak çerçeveler arası iletişim sorununu çözebilen ve son olarak Verkle ağacının geri ödemeyi dikkate alması gerekmeyecek gibi gelecekteki depolama tasarımının önünü açabilen geçici depolama işlem kodlarını ekler. geçici depolama sorusu;

Cancun yükseltmesinin dördüncü önerisi olan EIP5656, kod sözcüklerini ve cümleleri daha doğru bir şekilde kopyalayabilen ve bellek kopyalama performansını yaklaşık %10 artıracak olan MCOPY bellek kopyalama talimatını sunar;

Cancun yükseltmesinin beşinci önerisi, Ethereum ağındaki farklı protokoller ve uygulamalar arasındaki iletişimi daha verimli ve güvenli hale getirebilen ve ayrıca staking havuzları, köprüleme ve yeniden paylaştırma protokolleri için daha güvenilir tasarımlara olanak tanıyan EIP4788'dir;

En son Cancun yükseltmesi (15 Haziran 23), CL-merkezli EIP yükseltmelerinin eklenmesini öneriyor: Ethereum'un güvenliğini ve kullanılabilirliğini, teminat veren Deneyimini iyileştirmek ve ağ güvenliğini iyileştirmek gibi ayrıntılarla geliştiren EIP6988, EIP7044 ve EIP7045

Silinen teklifler arasında SSZ->RLP geçişi, iki SSZEIP'nin (EIP6475 ve EIP6493) Cancun yükseltmesinden kaldırılmasına neden oldu; EOF ile ilgili teklifler, Şangay yükseltmesinden çıkarıldıktan sonra tekrar Cancun yükseltmesinden kaldırıldı ve şu anda değerlendiriliyor mümkün Daha sonraki günlük yükseltmelerde doğrudan uygulanacaktır; EVMMAX, EOF uygulamasıyla ilgili EIP'nin bir alt kümesi olduğu için EOF ile birlikte yükseltmeler için Cancun'dan da kaldırılmıştır; ETH aktarma biçiminde var olabilecek olası yan etkiler göz önünde bulundurularak, ve gerekçelendirme, test ve güvenlik çalışmaları, EIP5920 yükseltmesinden çıkarılma teklifini geçme ihtiyacı.

5. zkml ve hesap soyutlama ile ilişki

zkml üzerinde çok az etki

ZKML, Zero Knowledge Proof (ZeroKnowledge) ve Machine Learning'in (Machine Learning) birleşimidir; blockchain ve ML modelinin birleşimi, makine öğreniminin gizlilik koruma ve doğrulanabilirlik sorunlarını çözer:

Mahremiyetin korunması: girdi verilerinin gizliliği, örneğin eğitim için makineleri beslemek için büyük miktarda kişisel bilgi kullanmak gibi, kişisel bilgilerin gizliliği önemli bir gerekliliktir; veya projenin temel rekabet gücü olarak model parametreleri de gereklidir rekabet engellerini korumak için şifrelenecek. Bunlar gibi güven sorunları ortaya çıktığında, makine öğrenimi modellerinin daha büyük ölçekli veri ve uygulamalar elde etmesi engellenecektir.

Doğrulanabilirlik: Sıfır bilgi kanıtı teknolojisinin geniş bir uygulama yelpazesi vardır ve ZKP, kullanıcıların bilgilerin doğruluğunu doğrulamadan bilmesini sağlar. Makine öğrenimi modeli çok fazla hesaplama gerektirdiğinden, ML modeli ZK-SNARK aracılığıyla kanıtlar üreterek kanıt boyutunu azaltabilir ve makine öğreniminin bilgi işlem gücü talebini azaltabilir.

ZKML'nin depolama gereksinimlerinin DA ile çok az ilgisi vardır: Uzay ve Zaman gibi ayrı bir depolama yapısı gerekir ve temel teknolojisi yeni güvenlik protokolü "SQL Proof"tur. Veya zincir içi ve zincir dışı verileri basit bir şekilde bağlayın SQL formatı ve sonuçları doğrudan akıllı sözleşmelere yükleyin;

ZK-SNARK'lar, ZKML'deki ana ZK biçimidir ve zincirdeki ML'nin bilgi işlem gücü gereksinimlerine uyum sağlayabilir. Kriptografinin gelişmesiyle birlikte, özellikle özyinelemeli SNARK kanıtları, ZKML'nin zincir üzerinde uygulanmasına fayda sağlayacaktır:

ZK-SNARK'lar yüksek kompaktlıkla karakterize edilir. ZK-SNARK'ların kullanılması, kanıtlayıcının kısa bir kanıt oluşturmasına olanak tanır ve doğrulayıcının etkileşime girmesi gerekmez ve geçerliliğini doğrulamak için yalnızca küçük bir hesaplama yapması gerekir. Bu, yalnızca bir kanıtlayıcı gerektirir Doğrulayıcılarla etkileşimin doğası, ZK-SNARK'ları pratik uygulamalarda verimli ve pratik kılar ve makine öğreniminin zincir üstü bilgi işlem gücü gereksinimleri için daha uygundur.

Şu anda zincir üzerinde eğitim yapmak imkansızdır ve zincirde yalnızca zincir dışı hesaplamaların sonuçları saklanabilir:

Mevcut makine öğrenimi sorunu, daha çok yetersiz bilgi işlem gücü gereksinimlerinden ve algoritma sınırlamalarının neden olduğu düşük performanstan kaynaklanmaktadır (paralel olarak hesaplanamaz). ZK-SNARK'lar yalnızca küçük ölçekli ML sıfır bilgi kanıtını ve küçük miktarda hesaplamayı destekler, yani bilgi işlem gücünün sınırlandırılması, ZKML blok zinciri uygulamalarının gelişimini etkileyen önemli bir faktördür ve zincir yalnızca kapalı sonuçları depolayabilir. -zincir hesaplamaları.

İyi hesap soyutlaması

Her şeyden önce, Cancun yükseltmesi, ZKrollup kanıtının maliyetini bir dereceye kadar azaltabilir:

Mevcut zkSync işlem ücreti 3 hususa bağlıdır:

SNARK sertifikasını oluşturmak ve doğrulamak için doğrulayıcı tarafından tüketilen sabit kaynak maliyeti nispeten yüksektir;

Doğrulayıcı, SNARK kanıtını Ethereum ana ağına gönderdiğinde gas ücreti, ücretin bu kısmı, ana ağdaki tıkanıklık nedeniyle buna göre artacaktır;

İşlem onayı, mesaj yayını vb. dahil olmak üzere kullanıcı tarafından doğrulayıcıya ödenen hizmet bedeli.

Bu nedenle 4844'ün getirilmesi durumunda ana şebeke sıkışıklığından kaynaklanan artan gas ücretleri sorunu hafifleyecek ve ZKP kanıtlarının maliyeti bir ölçüde düşebilecektir.ZK serisinin gelişme eğilimi hafife alınmamalıdır.

İkincisi, hesap soyutlama, geleneksel tx işlemlerini kullanıcı işlemlerine dönüştürür ve ardından kullanıcı işlemlerini, zincirde eskisinden daha fazla depolama alanı kaplayan ECDSA ile bloklara paketler, böylece depolama gereksinimleri daha yüksektir;

Ardından, hesap soyutlama ve ZKrollup birbirini tamamlayabilir:

Şu anda, hesap soyutlama sorunu, GasFee'nin pahalı olmasıdır.Çok fazla adım olduğundan ve akıllı sözleşmeler söz konusu olduğundan, çok fazla veri vardır, bu da GasFee'yi pahalı kılar.ZKRollup'ın avantajı, verileri azaltabilmesidir;

Hesap soyutlama, güvenliği garanti etmeyi zorlaştırıyor: AA birden fazla sözleşme içerdiğinden güvenlik bir sorundur.Ancak, gelecekte L2 kademeli olarak oluşturulduktan sonra, fikir birliği katmanı artık değiştirilmeyecek, akıllı sözleşmelerin daha fazla kullanımı olacak ve güvenlik hesap soyutlama oranı da artacaktır.Garanti edilebilir ve ZKrollup'ın güvenilir doğrulaması ile güvenlik daha da geliştirilecektir.

Son olarak, AI teknolojisinin yükselişi göz önüne alındığında, zincir üstü sözleşmelerin güvenliğini artırmaya ve zincir üstü işlemleri veya faaliyet adımlarını optimize etmeye yardımcı olabilir:

AI ve güvenlik: AI teknolojisi, zincir üstü işlemlerin güvenliğini ve gizlilik korumasını geliştirmek için kullanılabilir. Örneğin, Web3 güvenlik platformu SeQure, kötü niyetli saldırıları, dolandırıcılığı ve veri sızıntısını tespit etmek ve önlemek için yapay zekayı kullanır ve zincirdeki işlemlerin güvenliğini ve istikrarını sağlamak için gerçek zamanlı izleme ve alarm mekanizmaları sağlar;

AI ve zincir üstü faaliyetlerin optimizasyonu: Blok zincirindeki faaliyetler, işlemleri, sözleşme yürütmeyi ve veri depolamayı içerir. Yapay zekanın akıllı analiz ve tahmin yetenekleri sayesinde, zincir üstü faaliyetler daha iyi optimize edilebilir ve genel verimlilik ve performans iyileştirilebilir. AI, veri analizi ve model eğitimi yoluyla işlem modellerini belirlemeye, olağandışı etkinliği tespit etmeye ve blok zincir ağları için kaynak tahsisini optimize etmek için gerçek zamanlı öneriler sağlamaya yardımcı olabilir.

Bu nedenle, Cancun yükseltmesi, depolama alanının genişletilmesinden ZKrollup ile tamamlayıcılığa ve ardından AI teknolojisi ile kombinasyona kadar gelecekteki hesap soyutlama gelişimine kademeli olarak fayda sağlayacaktır.

6. Ethereum yol haritasına baktığımızda sırada ne var?

Şu anda Layer2, Solana'ya benzer bir performansa (gecikme ve verim açısından), Near gibi parçalanma performansına veya Sui ve Aptos gibi paralel yürütme performansına sahip değildir.Cancun yükseltmesi, Ethereum liderliğini geliştirmiştir. Önder;

Cancun yükseltmesinden sonra, birkaç büyük geliştirme süresinin tamamen danksharding (2~5 yıl), MEV ve PBS iniş (1~3 yıl), hesap soyutlama (1~2 yıl), ZK her şey (3~) olacağı tahmin edilmektedir. 6 yıl) ), EOF ve geliştirici deneyimi (uzantıyı kaç kez gördünüz?).

Bela

Hedef: MEV problemlerini çözmeye odaklanın.

Çözüm: MEV'yi uygulama katmanında "Teklif Sahibi-Oluşturucu Ayırma (PBS)" yoluyla en aza indirin. Bu sırada, bloblar optimize edilebilir ve ön onay hizmetleri veya ön alım koruması sunulabilir.

PBS, blok oluşturucuların ve sıralayıcıların ayrılmasıdır. Sıralayıcı, zincirden bağımsız olarak sadece sıralamadan sorumludur ve blok oluşturucu işlemle ilgilenmez ve sıralayıcı tarafından yapılan paketi doğrudan seçer ve zincire koyar. Bu süreç, tüm süreci daha adil hale getirecek ve MEV'in dışsallaştırılması fikri olan MEV sorununu hafifletecektir.

PBS'nin tamamlanma derecesi şu anda hala çok düşük ve daha olgun olanı, harici MEV çözümleriyle işbirliği - flashbotların mevboost'u.

"Enshrined Proposer-Builder Separation (ePBS)"nin gelişmiş versiyonu daha düşük tamamlanma derecesine ve daha uzun bir döngüye sahiptir ve kısa vadede hayata geçirilemeyeceği tahmin edilmektedir.Ayrıca PEPC'nin aşamalı versiyonları vardır ve PBS çerçevesinin esnekliğini ve uyarlanabilirliğini artıran Optimistic Relaying

Sınır

Hedef: Merkle'nin yerine Verkel ağacını kullanın, güveni en aza indirgeyen bir çözüm getirin, hafif düğümlerin tam düğümlerle aynı güvenliği elde etmesini sağlayın ve blok doğrulamayı olabildiğince basit ve taşınabilir hale getirin.

Aynı zamanda, L1'in ZKizasyonu, Verge yol haritasına açıkça eklendi.ZK, gelecekteki genişleme ve hızlanmanın genel eğilimi olacak;

Çözüm: SNARK tabanlı hafif istemciler, mutabakat durum değişiklikleri içeren SNARK'lar ve EnshrinedRollups dahil olmak üzere eski ispat sistemini değiştirmek için zk-SNARK'ları tanıtın.

Verkle ağaçları, her bir kardeş düğümden (aynı ebeveyni paylaşan düğümler) seçilen düğüme giden bir yol sağlaması gerekmeyen, ancak kanıt olarak yalnızca yolun kendisinin olması gereken duruma özgü Merkle ağaçlarına göre daha verimli bir alternatiftir Kısmen, Verkle kanıtları Merkle kanıtlarından 3 kat daha etkilidir.

EnshrinedRollup, L1'de bir tür mutabakat entegrasyonuna sahip bir Toplama anlamına gelir. Avantajı, L1'in mutabakatını devralması ve toplu yükseltmeleri gerçekleştirmek için yönetişim belirteçlerine ihtiyaç duymamasıdır. Aynı zamanda, zincir dışında hesaplamalar yaparak ve yalnızca yayınlayarak Blok zinciri sonuçları, işlem sayısını artırabilir, ancak uygulamanın teknik zorluğu nispeten büyüktür. Gelecekte bu toplamaların kombinasyonu, önümüzdeki birkaç on yıl içinde blockchain ekosisteminin ihtiyaçlarının çoğunu karşılayabilecektir.

Arınma

Arındırma, ağın doğrulanmasına katılmak için depolama gereksinimlerini azaltarak protokolü basitleştirme hedefini ifade eder. Bu, öncelikle hazırda bekletme ve tarih ve durumun yönetimi yoluyla elde edilir. Geçmiş veri atıllığı (EIP-4444), müşterilerin bir yıldan eski geçmiş verileri budamasına ve P2P düzeyinde hizmet sağlamayı durdurmasına olanak tanır.

devlet uykuda. Durum büyümesini ele almaya gelince, iki ana hedef vardır: durumu yalnızca bloklar oluşturmak için kullanma ama bunu doğrulamama hedefine atıfta bulunan zayıf vatansızlık; Erişilen durum. Durum hazırda bekletme, durum düğümlerinin saklaması gereken toplam 20-50 GB azaltmalıdır.

Arındırmanın beşinci aşamasında, EIP4444 açıkça Yol Haritasına yazılır. EIP-4444, istemcinin bir yıldan daha eski verileri temizlemesini gerektirir. Aynı zamanda, bu aşamada, mekanizmanın basitleştirilmesi gibi bazı EVM optimizasyon görevleri vardır. GAS ve EVM ön derlemesi vb.;

Splurge

Splurge'nin son altıncı aşamasında EIP4337'den de bahsedildi.Cüzdan ekolojisi için uzun vadeli bir düzen önerisi olarak hesap soyutlama, gaz ve sosyal kurtarma cüzdanları için ödeme yapmak için sabit paraların kullanılması da dahil olmak üzere gelecekte cüzdanların kullanım kolaylığını daha da artıracaktır. , vesaire.;